1. Discussion on DHCPv6 Routing Configuration
Zhen Cao
Wojciech Dec
Behcet

2. DHCPv6 Route Option Basic Scenario – Multi-homed MIF Client
(Access-network not shown)
IP Subnet X/Y
Router A
DHCP Client
Host
DHCP Server
Router B
Internet
Dual links (physical or logical) from Host to Router A and B
It is desired that Host uses Router B as its default gateway (0/0)
It is desired that Host uses Router A as its primary gateway for destination subnet X/Y. More specific route to X/Y via RouterA is thus required.
It is required to operate in an environment where per client configuration on the Router is not possible
Additional scenarios in draft-troan-multihoming-without-nat66

3. DHCPv6 Route Option Motivation
Today’s IGPs solve the problem but are often not feasible for deployment
Not supported on host or increased CPE cost
Added operational complexity for the SP to manage on 1000s of devices
Challenging to scale (an IP Edge may interface with 1000s of CPEs)
Simple on-demand configuration is preferred
ICMPv6 (rfc4191) presents an RA based solution however:
Does not differentiate between clients that know what to do with the info and those that don’t.
Using DHCP allows operator to restrict address assignment (of additional prefixes) only to hosts that support more advanced next-hop and address selection requirements
It requires provisioning of the edge router (not always possible, eg when router is operated by a different organization).
Seen as unnecessary when DHCPv4 RFC3442 practice is already used

4. DHCPv6 Route Option Joint agreement from 3 solution proposals
[1]
[2]
[3]
Joint agreement on what needs to be sent from a DHCPv6 server to the client (following a route Option Request from the client) :
IPv6 Prefix – Specifies the destination
Next-hop-address – Specifies the next-hop address for that destination
Metric – Provides a way to compare multiple routes for the same destination (possibly across other interfaces)
Routes added to a hosts’ route table in coexistence with other routes (and route sources)
In terms of DHCPv6 there is also common agreement on:
A Hierarchical DHCPv6 option approach
Extensible - Possible to define future options (MTU, TOS, etc.)
Nested format following proven DHCPv6 options design (eg IA_NA, IA_PD)
Feedback from WG?
Ok to progress into common draft?

5. Input from WG needed on main differences
DSCP/TOS Routing
Sent from server to client
Intended for application specific routing based on DSCP/TOS
Interface-info
Sent from the client to the server and returned by the server
Route info is interface dependent
multiple interfaces (multi-homed) that are simultaneously connected
Feedback from the WG?
Should the above be added to the common draft as options?

6. Backup slides

7. Scenario #1 for Routing Metric Configuration
DHCP Server1
WLAN
Internal Srv
DHCP
Client
Host
Wired Interface
DHCP Server2
Normally, metric for the wired interface is lower than that of WLAN, given more preference
But however some servers are only accessible via the WLAN
Wlan should configure a static route with a lower metric toward the internal server

8. Scenario #2 for Routing Metric Configuration, High speed wlan
DHCP Server1
WLAN
Internet Srv
DHCP
Client
Host
Wired Interface
DHCP Server2
Normally, metric for the wired interface is lower than that of WLAN, given more preference
But with the advance of ad (high speed wlan), WLAN is preferred over wired

9. Scenario #3 for Routing Metric Configuration, traffic offload
WLAN
DHCP
Client
DHCP
Server
Internal Srv
Host
3G Network
Operator controlled manner
Offload traffic from 3G to WLAN with DHCP conveying the information of the metric on different interface

10. Interface Info
Hosts with multiple interfaces (multi-homed) that are simultaneously connected (which is mif WG interest area)
Hosts needing route info signal DHCP server by sending DHCP Request message
Route info is interface dependent
Hosts need to provide interface info in DHCP Request
That is the reason why we called multi-homed routing policy entry option 10

11. DHCPv6 – Proposed Route Option http://tools. ietf
IA_RT
Wrapper for route sub-options
Can group one or more NEXT_HOP options
NEXT_HOP
Defines IPv6 next hop address. Can group multiple RT_PREFIX sub-options
RT_PREFIX
Defines the destination prefix
Allows further per destination sub-options (tags, timers, etc)
Borrows from RFC4191 in using the Reserved and Prf values