Re: [dhcwg] Remote DHCPv6 configuration

["David W. Hankins" <[e-mail]>]

On Thu, Oct 28, 2010 at 12:49:32PM -0400, Ted Lemon wrote:
> The server uses the location of the client to make the address allocation
> decision.

Yes, in the case where the server is permitting incoming Unicasts, it
uses the source IPv6 address of the DHCPv6 packet from the client to
fill in the blanks and understand where the client is connected.  This
works because even if the client isn't actually connected to the
network they are using as a source address, they will not receive the
server's reply as it will be routed elsewhere.


I think however if you extend DHCPv6 relay agents to allow unicasts
from clients, and list relay agents as the neighbor addresses in
Tomasz' neighbors option, that the relay agent would fill the link-
address field correctly, and the peer-address would be the client's
working global IPv6 address on the previous broadcast domain.  So it
would work trivially; the query and reply would follow the usual relay
semantics except the reply would be unicast from the final relay to
the client on its old network.

This is even preferable because sometimes DHCPv6 state is snooped in
Relay Agent implementations for beneficial operational purposes.  It
would be better to include the new Relay Agent in the exchange than
to try and rebuild state around Confirm/Reply messages when the client
makes the hand-over (such as through Lease-Query).

If there is no relay agent, however, there comes a problem.  I think
various extensions are possible (the most obvious to me is a new
message ("Remote-Forward"?) to replicate the Relay-Forward link-
address field, and then encapsulate the client's Solicit or Request
or others under that.

But I wonder if this may be over-complete:

1) There is no reason why a relay agent may not be co-resident on a
   system with a DHCPv6 server that desires this "remote mode"
   deployment.  It could be configured to listen on a specific unicast
   IPv6 address, and not the servers-and-agents multicast address.

2) Mobile IPv6 deployments seem unlikely to me to connect DHCPv6
   servers to many (if any) actual client-loaded broadcast domains
   directly.


Also, this doesn't seem to solve for ICMPv6 Router Advertisement
pre-loading.  The client would have a /128 allocated by DHCPv6, but
would not know the local prefix or what default routers are present.

I think there would have to be some other extensions to pre-load this
information as well.

Another alternative is to allow the client to establish a tunnel to
the new network (presented as being bridged into the new network's
broadcast domain), perform configuration, and then transfer state from
the tunnel interface to the physical interface at a hand-off.

-- 
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