Barbara - sorry, I wasn't clear. I think we're in agreement. The router at the edge of a subscriber network does not need the relay function.
There are other network architectures where the relay function is likely to be needed. It's not clear a single RFC 2119 recommendation is adequate. - Ralph On May 27, 2011, at 11:20 AM 5/27/11, STARK, BARBARA H (ATTSI) wrote: >> +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 ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
