Subject: RE: DHCPv6 Relay Changes

From: Ralph Droms <[email-masked]>
Date: Thu, 14 Sep 2000 15:00:21 -0400

At 09:28 PM 9/6/00 -0400, you wrote:
>While I understand the forward (client to relay to server) message traffic,
>the reverse traffic isn't clear. I assume the server sends back the message
>to the relay without having to encapsulate it?

For simplicity and security, I would guess the return traffic is 
encapsulated as well.

>If you allow the multiple encapsulations (one for each relay), how does the
>reverse traffic occur?

I didn't see any reference to multiple encapsulations in Barr's note - did 
I miss it?  In any event, we probably need multiple encapsulations to 
accommodate authenticated relay options.

>  It goes to the relay nearest the client since it is
>the only one that can communicate with the client?

In case of multiple relays - note that processing a DHCP message in 
multiple realy agents is an unusual event - I would guess we want to unwrap 
the messages one at a time through the reverse path.

- Ralph

---

From: Bernie Volz <[email-masked]>
Date: Fri, 15 Sep 2000 09:01:51 -0400

I agree with Ted's proposal that the entire DHCPv6 (UDP data portion) is
encapsulated in a "Relayed Data" option. The DHCPv6 relay can add other
options to the "new" DHCPv6 message, such as relay agent options, etc.

So, a relay receives a DHCPv6 message (UDP data portion only), creates a new
message that it sends to the server, that message contains:
	DHCPv6 header
	DHCPv6 relay added options
	DHCPv6 "Relayed Data" option which contains the original DHCPv6
message received from the client
	DHCPv6 relay added options

(We could require the relay added options to appear either before or after
the relayed data option or allow the relay to add some before and some
after.)

- Bernie Volz

-----Original Message-----
From: Ted Lemon [mailto:[email-masked]]
Sent: Friday, September 15, 2000 2:45 AM
To: DHCPv6 discussion list
Subject: Re: DHCPv6 Relay Changes

> The market will decide security mechanisms not us.

*smile*  There are some things that not even the Omniscient Hand of
the Market can make happen.   :')

We talked about how to use IPsec for DHCP authentication, and came up
with some theories, but all of them involved extra packet exchanges,
and ultimately we decided we didn't want that.   If the market really,
*really* wants it, I guess it'll happen, but I'm not placing any bets
on it.   That's between the client and server, of course - as you say,
IPsec between the relay and the server is fairly easy, and eminently
plausible, particularly in the cable modem environment where you want
to stuff additional options into the Relay message.

			       _MelloN_