Subject: RE: DHCPv6 Relay Changes

From: Ralph Droms <[email-masked]>
Date: Fri, 20 Oct 2000 12:30:15 -0400

Here's my summary of consensus on DHCPv6 relay agent function...

Issue:

         23. Relay agents - adopt DHCPv4 function: relay agents insert
             interface address in 'giaddr' and forward to DHCP servers
         26. Relay agents should simply encapsulate the client message
             in a DHCPv6 extension; the relay message should have its
             own type.

DHCPv6 relay agents will forward messages beetween clients and servers
using "DHCP-in-DHCP encapsulation".

Forwarding messages from clients to servers:

The relay agent creates a new DHCP message and encapsulates the entire
DHCP message from the client in a "Relayed Data" option in this new
message.  The relay agent may also add other options (an example from
DHCPv4 would be the "relay agent information" option) and may use DHCP
authentication.  The relay agent then sends the new message to the
destinations in the relay agent's forwarding list.

This mechanism is applied recursively if a relay agent forwards a
message to another relay agent; the second relay agent encapsulates
the received relay agent message (which, in turn, contains the
encapsulated message from the client) and forwards the new message to
its list of destinations.

The server unwraps each of the encapsulated messages to recover the
original client message.  The server must record the information from
each of the relay agents so it can properly form the response to the
client.  The server processes the client message and any agent options
from the encapsulating messages.

Forwarding from a server to a client:

The server first forms the response message to the client.  Then, the
server wraps that message in encapsulating message(s) to the relay
agent(s) that forwarded the original client message.  For example, if
client C's message had been forwarded through relay agents R1 and R2,
the server would form a message to R2 that carried an encapsulated
message for R1, which would in turn carry an encapsulated message for
C.

The server includes any responses to the relay agent(s) and uses
appropriate authentication for each of the encapsulated messages.

---

From: Erik Nordmark <[email-masked]>
Date: Fri, 20 Oct 2000 16:42:36 -0700 (PDT)

> using "DHCP-in-DHCP encapsulation".

If the configuration of the relay(s) is incorrect, you could potential
end up with recursive encapsulation.
It would probably make sense to prevent this e.g. with an upper bound on
the message size.

  Erik

---

From: Thomas Narten <[email-masked]>
Date: Mon, 23 Oct 2000 06:40:57 -0400

What is the benefit in allowing recursive enacapsulation through
multiple relay agents? Would it make sense to simplify things and
simply say there can be at most one relay agent in the path, and the
relay agent always forwards the packet to a DHCP server (or an entity
that looks like the server from a protocol perspective)?

Thomas

---

From: "Ralph E. Droms" <[email-masked]>
Date: Mon, 23 Oct 2000 06:54:47 -0400 (EDT)

> that looks like the server from a protocol perspective)?

Oops.  I've been looking at relay agents with my DHCPv4 hat on.  In
DHCPv6, the relay agent forwards messages to a multicast group that
includes all DHCP servers.  So, a relay agent will always forward DHCP
messages directly to a DHCP server...

- Ralph