I personally think all this discussion is much ado about nothing. It's incorrect thinking to deploy an IPv6 router without RA. RA supports all of prefix information and on-link determination, so why have DHCPv6 duplicate that functionality? Bernie already mentioned why it's dangerous if two entities in DHCPv6 server and IPv6 router issue duplicate information one of which could be different. I also feel DHCPv6 WG should not take up any work item to start working on supporting any new option that duplicates PIO of RA nor work on a default router option. As many folks have said, please don't think IPv6 like IPv4. Also, aside of SLAAC where a default prefix length can be assumed but cannot be used for on-link determination, no other IPv6 deployment make sense to assume any default prefix length. This is the new property of an IPv6 network for the router to be able to assign any prefix length to nodes the router serves.
The other discussion about routers in broadband residential homes etc., can be a separate discussion held in dhcpwg. IPv6 data WG has other important problems to consider like something as basic as a host data forwarding is broken due to misconceptions about on- vs. off-link determination. Hemant -----Original Message----- From: JINMEI Tatuya / ???? [mailto:[EMAIL PROTECTED] Sent: Thursday, August 16, 2007 4:56 AM To: David W. Hankins Cc: [EMAIL PROTECTED]; [email protected] Subject: Re: [dhcwg] Re: prefix length determination for DHCPv6 At Wed, 15 Aug 2007 10:51:40 -0700, "David W. Hankins" <[EMAIL PROTECTED]> wrote: > > > I think that you will find realistically, DHCPv6 servers will know > > > prefix lengths. > > > > None that I've worked with (including the WIDE server) seems to care. > > What's needed are assignment ranges, not prefixes. > > I'm familiar with half of the story here, and uncomfortable with > speaking about a specific competitor's product (but it appears I will > do it anyway). My opinion of WIDE's Confirm message processing is > that it does know the prefix length: it assumes all prefixes are /64, > by comparing the first 8 bytes of addresses. > > I make no judgement here of the efficacy or correctness of this > implementation. > > If there is an expert on WIDE's implementation that can describe how > it reaches a dynamic pool from relays (without relays, it appears to > follow interface definitions), I'm curious to know the rest of the > story. I'm not an "expert" on the WIDE implementation (any more), but I know the implementation well enough that I can clarify the points, so... Your understanding about the Confirm message processing of the WIDE server is correct. (And I don't think this way of handling Confirm is really an appropriate behavior). The WIDE server implementation doesn't care about the link prefix when assigning an address from a pool. This is also not an appropriate behavior because it could assign an address that is not valid for the link to which the client is attached. So, I think you're right in that realistically the DHCPv6 server operator needs to understand the link prefixes of the addresses assigned via DHCPv6. This also means the DHCPv6 server will realistically be able to provide this information for the clients. (The server might still work properly just based on the knowledge about its own local links and on the content of 'link address' information of relayed messages. But such an operation does not seem "realistic" to me). But I don't think this immediately justifies the introduction of an on-link prefix option to DHCPv6. To rely on this feature, the DHCPv6 operator would need to know all on-link prefixes including ones that are not used for DHCP-based address assignment, and would need to configure them on the server. Although the additional overhead is minor, it can still be an unnecessary operational cost and can cause configuration inconsistency that could actually avoided. On the other hand, routers should inherently know the on-link prefix information to route packets appropriately, so providing this information via RA still looks better than the DHCP-based approach. IMO, this discussion is going to miss the point. The problem is not whether we can provide on-link prefix information via DHCPv6 (yes we can) or whether it's reasonable per se (it might), but whether we should do this while RA already has this provision and would actually be better than DHCPv6-based approach. A new draft from the dhc group will reportedly (hopefully?) answer this main question, so, again, I think we should hold off for a while. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. [EMAIL PROTECTED] -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
