Subject: [dhcwg] Remote DHCPv6 configuration

From: Tomasz Mrugalski <[email-masked]>
Date: Mon, 25 Oct 2010 23:11:13 +1300

Hi,
Currently DHCPv6 protocol assumes that client is attached to the link, which
is used to communicate with server (or relay). In some mobility scenarios it
may be beneficial to contact with a server before client is attached to the
link. Such ability to know address and other configuration parameters before
actually moving to a specific location may be very useful.

Such remote communication is a simple extension to unicast communication, so
only minor change (or no change at all) is required for servers.

I wrote a simple draft that underlines the basic concepts:
https://datatracker.ietf.org/doc/draft-mrugalski-remote-dhcpv6/

I'd like to ask for review and suggestions.

Regards,
Tomasz

---

From: Ted Lemon <[email-masked]>
Date: Mon, 25 Oct 2010 09:56:43 -0400

On Oct 25, 2010, at 6:11 AM, Tomasz Mrugalski wrote:
> Such remote communication is a simple extension to unicast communication, so only minor change (or no change at all) is required for servers.

It seems to me that it would be difficult for the DHCP server to make the address assignment decision in this situation.

---

From: Tomasz Mrugalski <[email-masked]>
Date: Thu, 28 Oct 2010 00:45:14 +1300

Not at all. Server should process the request as usual, i.e. should assign
address and other requested options as if the client was connected locally.

That is the expected behavior anyway. My understanding is that unless there
is a specific policy implemented, server should handle client's requests in
the same way, regardless if it was received over multicast or unicast.

Tomasz

On Tue, Oct 26, 2010 at 2:56 AM, Ted Lemon <[email-masked]> wrote:

> > Such remote communication is a simple extension to unicast communication,
> so only minor change (or no change at all) is required for servers.
>
> It seems to me that it would be difficult for the DHCP server to make the
> address assignment decision in this situation.
>

---

From: Ted Lemon <[email-masked]>
Date: Thu, 28 Oct 2010 12:49:32 -0400

On Oct 27, 2010, at 7:45 AM, Tomasz Mrugalski wrote:
> That is the expected behavior anyway. My understanding is that unless there is a specific policy implemented, server should handle client's requests in the same way, regardless if it was received over multicast or unicast.

The server uses the location of the client to make the address allocation decision.

---

From: "David W. Hankins" <[email-masked]>
Date: Thu, 28 Oct 2010 14:52:38 -0700

> The server uses the location of the client to make the address allocation

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