David W. Hankins writes:
> 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 don't see how the server could possibly construct a valid Reply
message otherwise. It needs to include IA Address options, and those
need to have preferred-lifetime and valid-lifetime.
I'd agree that the language seems incomplete.
> > > - 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.
You're pardoned. I've only implemented one commercially-shipping
and deployed DHCPv6 client implementation. ;-}
> 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).
The link-address is:
link-address A global or site-local address that will be used by
the server to identify the link on which the client
is located.
I expect that to be the relay's global IPv6 address on the link on
which the client is located, if there is such an address.
> Basically it's how you know which addresses are appropriate for the
> client, based on what network they're attached to.
It's how you (as a relay) know where the client is located so that you
can reach it again when the server sends back the responses.
The server itself _can_ use link-address to determine where in the
world the client is located, but that doesn't mean that the relay is
doing this validation (which is what I had thought you were saying),
and it also doesn't mean that the client itself is on the same prefix.
Note that link-address can be 0, if the relay doesn't have a global
address on that interface, and the server will have to choose a
different means to get the information it needs. So, it's not an
absolute identifier of the prefix.
> Does that make more sense now?
Yes.
> > 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.
If there's a delegated prefix, I'd _assume_ that there's a router in
the way. Otherwise, delegating a prefix is a little strange.
If there's a router in the way, then it's the router's link-local
address that you need, not the customers end-node assigned addresses.
--
James Carlson, Solaris Networking <[EMAIL PROTECTED]>
Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
