Re: [dhcwg] Changes to remove "client-link-local-address" from the DHCPv6 header

> I believe if the relay is using the simple API and it must specify the right
> source address, then the relay will need to send through a socket which is
> bound to the desired local address.  I believe it will also receive its
> response through that bound socket, so learning the responses packet's
> destination address is accomplished by noticing the socket through which it
> arrived.  So, its doable with the simple API, though I think its a bit more
> complexity than you'd want relays to have to implement.
> 
> As you note below, if using the advanced API, then specifying the source
> address on sending and learning the destination address on receiving is
> easier, and is almost as easy as writing a the relay's local address into a
> fixed place in the packet, but not quite.

This is kind of a strange thing.  If you need the functionality of the
advanced API, why not use the advanced API?

> I think the explicit specification of a relay-address is needed in cases
> where either the relay has no global address on the proper interface (and
> thus needs to indicate a prefix-only address, which should work just fine),
> or where specifying the source address may complicate the packet's route out
> of the relay (this is speculation).  If a relay must detect one of these
> conditions, then it complicates the relay, or encourages relay authors to
> opt for the safer solution and always use the option (in which case it isn't
> optional in a practical sense).

I think the DHCP server should be using the prefix that the relay
reports when doing address assignments, not the IP address that the
relay reports.   Maybe I'm missing something here - are we back to
overloading these two functions?

			       _MelloN_

_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
http://www1.ietf.org/mailman/listinfo/dhcwg