> +1. It's highly unlikely that an SP wants to field DHCPv6 transactions > from all the devices in a subscriber network. We have adequate > mechanisms in place to get delegated prefixes and other config > information to the DHCPv6 server in the subscriber network without the > DHCPv6 relay function. > > I recommend "routers SHOULD support relay agent functionality of DHCPv6 > [RFC3315]." As Ray Hunter pointed out, the market will drive > implementation where needed: "I won't buy a router without a DHCPv6 > relay function."
Hmm. I think maybe I need to be just a little stronger in my opposition to elevating the language around DHCPv6 Relay Agent. From a mass market service provider perspective, there are many cons to DHCPv6 Relay Agent, and no pros. In the world of mass market, scalability and capacity are very important. DHCP servers are scaled (and have the capacity) to function properly when there is a mass restoral of power after an outage that impacts many subscribers. If the number of devices sending DHCPv6 queries were increased many-fold, then this would increase the cost of DHCPv6 servers. In addition, the queries from hosts would likely get in the way of queries from routers requesting PDs. The routers need those PDs, and slowing down the PD process with lots of unnecessary and unwanted queries from hosts is a Bad Thing. Furthermore, if a router inside the home network requests a PD (many SPs will probably restrict PD assignment to 1 PD per subscriber) before the customer edge router does, then the customer's home network could end up in pretty bad shape. As evidenced by BBF and CableLabs docs, service providers are designing address assignment architecture around PD. Also, many end users (like me) would be very uncomfortable with having addresses for home network assigned directly from a service provider. Personally, I like to think I have some control over my home network. So DHCPv6 Relay Client for purpose of address assignment may actually be considered undesirable (by all parties involved) in a mass market environment. Furthermore, there is no need for DHCPv6 Relay Client for passing through options. The mechanisms that most service providers expect to see in routers is evident in RFC 6204: "L-12: The IPv6 CE router SHOULD make available a subset of DHCPv6 options (as listed in Section 5.3 of [RFC3736]) received from the DHCPv6 client on its WAN interface to its LAN-side DHCPv6 server." And TR-124i2: "LAN.DHCPv6S.10 The device SHOULD support Reconfigure Accept (RFC 3315) and pass the additional set of DHCP options received from the DHCP client on its WAN interface to IPv6 hosts." Given the above points, it's likely that many mass market service providers will actively prohibit DHCPv6 Relay Client from existing in the routers that they procure. You could argue that they could just disable it. But the reality is, that there is no need for it, and there could be harm if it were enabled (subscriber: "Ooh, what does this button do?"), so it's best not to have it at all. That saves on coding, testing, and risk of accidental enablement. For the IETF to strongly recommend implementing a function that a large segment of implementers is likely to actively prohibit doesn't seem like the right thing to do. And mandate of such a function, IMO, wouldn't serve the IETF well, at all. Barbara -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
