Discussion on DHCPv6 Routing Configuration Zhen Cao (zehn.cao@gmail.com) Wojciech Dec (wdec@cisco.com) Behcet Sarikaya(sarikaya@ieee.org)

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

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

DHCPv6 Route Option Joint agreement from 3 solution proposals [1] http://tools.ietf.org/html/draft-sun-mif-route-config-dhcp6-02 [2] http://tools.ietf.org/html/draft-dec-dhcpv6-route-option [3] http://tools.ietf.org/html/draft-sarikaya-mif-dhcpv6solution 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?

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?

Backup slides

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

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 802.11ad (high speed wlan), WLAN is preferred over wired

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

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

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