Subject: [dhcwg] Zero-conf DHCPv6 relaying: what do you think?

From: Gabor Retvari <[email-masked]>
Date: Tue, 10 Nov 2009 18:26:06 +0100

Dear all,

As part of a larger effort to automate address allocation in IPv6 networks, we 
have been thinking about how to minimize the configuration needs of DHCPv6 
relay agents. Currently, you need to specify at least the list of interfaces 
the relay agent listens at and the exact address/interface messages are 
relayed to. This can quickly become tedious and error-prone, especially in 
sites that do not run multicast routing. Easily, a DHCPv6 relay agent that 
requires no configuration at all would hugely ease network administration and 
maintenance, especially in small sites (think of the scale of SOHO or Home 
Entertainment), where technical assistance is particularly scarce.

We have experimented with different approaches to zero-conf DHCPv6 relaying, 
the dumbest of which is basically loop-free broadcasting what we call, 
somewhat paradoxically, Smart Relaying: A relay agent listens on all physical 
interfaces and broadcasts an incoming DHCPv6 message to all interfaces except 
of the one the message was received at. Loops are broken by the relay agent 
putting its Relay-Id (as of RFC5460) into forwarded DHCPv6 messages and 
dropping a message if it already contains its own Relay-Id. This eliminates 
all configuration in DHCPv6 relaying.

Smart Relaying is now briefly specified, implemented and, according to our 
preliminary tests, works quite reliably. See the project page and download the 
code at:

http://qosip.tmit.bme.hu/~retvari/autonomic_dhcp.html#smart_relaying

Before taking this further, we'd like to hear your opinion. Were there other 
efforts at zero-conf DHCP relaying we don't know of? Does such an extension 
have enough use cases/impact/etc to substantiate a separate draft?

Best regards,
Gabor

------------
Gábor Rétvári
BME-TMIT
Phone: +36-1-463-1060
Fax: +36-1-463-1763

---

From: Ted Lemon <[email-masked]>
Date: Wed, 11 Nov 2009 08:37:30 +0900

> have enough use cases/impact/etc to substantiate a separate draft?

It seems to me that the motivation for this proposal is to avoid supporting multicast routing, because DHCPv6 is already completely automatic if you have multicast routing. But not supporting multicast routing is a terrible idea.   Why would you not support multicast routing?

So I have to say, wearing my opinionated IETF participant hat, not my wg co-chair hat, that this seems unnecessary - you are trading one very useful complexity for another complexity that is much less useful.

---

From: Gabor Retvari <[email-masked]>
Date: Wed, 11 Nov 2009 13:44:49 +0100

On Wednesday 11 November 2009 00:37:30 Ted Lemon wrote:
> > Before taking this further, we'd like to hear your opinion. Were there
> > other efforts at zero-conf DHCP relaying we don't know of? Does such an
> > extension have enough use cases/impact/etc to substantiate a separate
> > draft?
> 
> It seems to me that the motivation for this proposal is to avoid supporting
>  multicast routing, because DHCPv6 is already completely automatic if you
>  have multicast routing. But not supporting multicast routing is a terrible
>  idea.   Why would you not support multicast routing?
> 
> So I have to say, wearing my opinionated IETF participant hat, not my wg
>  co-chair hat, that this seems unnecessary - you are trading one very
>  useful complexity for another complexity that is much less useful.

It is important to emphasize that this proposal is not aimed at knowledgeable 
networking staff at, say, an ISP, who know how to set up multicast routing. 
For them, DHCPv6 relaying over multicast routing is clearly _the_ option. We 
are concentrating on SOHO or Home Entertainment, consisting of just a few IPv6 
routers, and managed by untrained personnel. Here multicast routing is an 
overkill, and it is a beast to configure. Heck, even the term "multicast 
routing" would sound miraculous in such an environment. Instead, a sane 
default for DHCP relaying, which adds minimal complexity but works without 
prior configuration of any kinds, seems much more advantageous.

Please, let us know what do you think.

Best regards,
Gabor

---

From: "David W. Hankins" <[email-masked]>
Date: Wed, 11 Nov 2009 15:15:41 -0800

> prior configuration of any kinds, seems much more advantageous.

The problem becomes cloudier when the relay agents are not necessarily
separated from their neighbors by broadcast domain; some SOHO devices
that implement DHCPv6 relay agent software may in fact be media
switches, and may not authoritatively be aware of what 'link-address'
should be used to identify the broadcast domain (they may not wish to
have an IP address aside from their link-local address).

In this case multicasting to the All_DHCP_Servers address is not
helpful even if that works because the packet must first pass through
a peer relay agent to populate a meaningful link-address field.

I think this is closer to the root problem you are identifying?

I hope there is an more elegant solution than replicating the Ethernet
flooding algorithm.

For one thing, point-to-point links are not universal, so it may not
in fact always be possible to de-select the source interface,
guaranteeing DHCPv6 relay loops in the general case if the
All_DHCP_Relay_Agents_and_Servers address is used.

> Please, let us know what do you think.

It would be nice if routing (multicast as well) could be zero-conf in
the SOHO environment.  I can conceive of systems to permit this, but I
can understand the opinion that they are complicated to implement and
would be a great amount of new software implementing unproven ideas at
best.

Not to mention that most homes prefer a single broadcast domain due to
the installed base of software, greatly diminishing the rewards of
automatic routing.

But even if that could be done, a DHCPv6 relay agent residing in a
network that has multicast routing properly configured still wants to
know what interfaces it should not receive client packets on; it wants
to de-select 'upstream' interfaces that are closer to the DHCPv6
server so as not to amplify client load.  This avoids a degenerate
condition where many relay agents, only 1 of which is in the DHCPv6
server's path (usually), relay-forward copies of the client's message.

You could again use multicast routing state to determine this;
whatever the local routing software, pose the hypothetical question
"To what interface(s) do you direct packets destined to
All_DHCP_Servers?"

These are your 'upstreams', which you shouldn't provide relay service
for, but the answer to that question can change dynamically, and it
may be overly difficult to query the system in this way.

If, as you said, multicast routing is even reliable.

So it is possible a solution that identifies the 'upstream
interface(s) towards a DHCPv6 server' could be complimentary even in
environments where multicast routing is in use; it could simplify the
de-selection of interfaces to relay for.

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