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
pgpDw7V4b7hOT.pgp
Description: PGP signature
-------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
