Wrt: >I'm sorry - this is a DHCPv6 protocol mechanic, something only a DHCP geek would know.
>The relay messages' 'link-address' field is central to the server's calculation of the client's location (which "broadcast domain" >they're attached to). >Basically it's how you know which addresses are appropriate for the client, based on what network they're attached to. David is correct about use of Link-addr by server above. Link-addr is the equivalent of giaddr in DHCPv4. Hemant -----Original Message----- From: David W. Hankins [mailto:[EMAIL PROTECTED] Sent: Wednesday, August 15, 2007 1:52 PM To: [EMAIL PROTECTED] Cc: ipv6@ietf.org Subject: Re: [dhcwg] Re: prefix length determination for DHCPv6 On Wed, Aug 15, 2007 at 10:33:16AM -0400, James Carlson wrote: > > and it needs to be able to Confirm the use of addresses, which it > > may not have allocated. > > That doesn't make sense to me. The DHCPv6 Confirm message is for > confirming an address lease. If the server hasn't allocated the > lease, then it _cannot_ confirm anything about the address and must > Nak in response. If it does confirm addresses it hasn't allocated, > then it's just broken. I'm not sure where you got that idea - certainly not from RFC3315 section 18.2.2 ("Receipt of Confirm Messages" under "Server Behavior"). I'll spare pasting the content to the lists - please have a read and let me know if you still disagree. > > - Have a list of all the 'link-address' fields that all > > operating DHCPv6 relays will use to identify a link. > > I'm confused. Why would relays be confirming anything? I'm sorry - this is a DHCPv6 protocol mechanic, something only a DHCP geek would know. The relay messages' 'link-address' field is central to the server's calculation of the client's location (which "broadcast domain" they're attached to). Basically it's how you know which addresses are appropriate for the client, based on what network they're attached to. So this is a server inspecting a chain of relayed messages and finding the link-address(es) it thinks are relevant to the client. Then using that as a key to find the address(es) it needs to deliver to the client. One way to do this is to find a prefix that contains the selected link-address (masking and comparing) and work outwards. One other way to do this is to index the link-addresses specifically, or some approximation of the same. Does that make more sense now? > > 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. > > Surely, there must also be some need to perpetuate two protocols, > > other than to simply perpetuate the need not to duplicate their > > contents? > > If you're going to deprecate DHCPv6 for address assignment and fold it > into the RA mechanism, then I'd be (somewhat weakly) in favor of that. > > If you're just going to duplicate things, then I'm very much opposed. Neither of those really sound like a good idea to me, but then I'm also lacking the power to do either of them. I guess the grass is not always greener on the other side. But let's save this discussion for a draft. Rumor has it, someone is writing one on this topic (or at least exploring the issues), and I want to read what they have to say. > > Even if you delegate a prefix, you still need to know your > > customer's address so that you might route packets to them. > > I don't understand that. > > If you delegate a prefix, then you route to the prefix -- best match. Yes, but how does that route get in the table, and what next-hop is set? You have to know your customer's address eventually. -- Ash bugud-gul durbatuluk agh burzum-ishi krimpatul. -- David W. Hankins "If you don't do it right the first time, Software Engineer you'll just have to do it again." Internet Systems Consortium, Inc. -- Jack T. Hankins -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------