Subject: RE: DHCPv6 Relay Changes

From: Bernie Volz <[email-masked]>
Date: Thu, 14 Sep 2000 15:35:20 -0400

I agree with Ralph - I was imagining the same.

I don't believe we want to do IP layer encapsulation since the DHCP relay
agent has typically run above the IP layer (above UDP) and I don't think we
want to change that. Especially when you consider the kinds of things that
Relay Agents might be doing these days (CMTS devices). Keeping relay agents
at the application layer is the right thing to do.

-----Original Message-----
From: Ralph Droms [mailto:[email-masked]]
Sent: Thursday, September 14, 2000 3:02 PM
To: DHCPv6 discussion list
Subject: Re: DHCPv6 Relay Changes

At 02:59 AM 9/7/00 -0400, you wrote:
>Barr/folks,
>
>Is this really encapsulation?
>
>or
>
>A new relay extension msg type to encapsulate client solicits and
>requests.
>
>At the design meeting I was thinking real encapsulation.

I was imagining a new message extension type that carries the client 
message in another DHCP message between the relay and the server.

- Ralph

---

From: Ted Lemon <[email-masked]>
Date: Thu, 14 Sep 2000 14:13:32 -0700

> at the application layer is the right thing to do.

Right, that was what I was thinking too - that's why I suggested
encapsulating the client's entire message in a DHCPv6 extension of a
new DHCP Relay message.   The relay agent can then optionally sign the
message or include additional information.

			       _MelloN_

---

From: Jim Bound <[email-masked]>
Date: Fri, 15 Sep 2000 00:31:46 -0400

>at the application layer is the right thing to do.

Hmm?  I have lots of code that knows nothing about the kernel that does
encap and decap.  Also lots of VPNs are built in user space and one just
sets up the routing table correctly.  No big deal.

More importantly what is wrong with the way dhcpv4 and dhcpv6 do it
today again?

regards,
/jim

---

From: Jim Bound <[email-masked]>
Date: Fri, 15 Sep 2000 01:02:18 -0400

>message or include additional information.

If we do this then that will work.  I did not get this out of Barr's
message but this will work I agree.

I would argue encapsulation is the wrong word but append is the correct
term.

IPv6 Header
UDP
-->DHCPv6 New Extension Relay Msg
----> Original DHCPv6 Msg Header + Data

You could simply say following this extension exists the orginal message
and then the server does not have to deal with decap or encap.

If the relay puts the server address in the IPv6 DST addr which it
should there will be no more need for any encap operation.

If the relay puts another relay in the IPv6 header in the DST address
which I think we should disallow then the best way to do this would be
to use the IPv6 Route Option and put the servers address in the Routing
option.

But we should design this so nested levels are not required.  I think
that can be done.

regards,
/jim

---

From: Ted Lemon <[email-masked]>
Date: Thu, 14 Sep 2000 22:33:24 -0700

> I would argue encapsulation is the wrong word but append is the correct

IP-in-IP encapsulation is wrong.   Append is also wrong, though.   We
really are encapsulating it, not appending some stuff onto the end, or
appending it to the end of some stuff.   At least, I'd rather do it
that way - it makes things more explicit, and thus (IMHO) easier to
specify.

			       _MelloN_

---

From: Jim Bound <[email-masked]>
Date: Fri, 15 Sep 2000 02:35:21 -0400

>that way - it makes things more explicit, and thus (IMHO) easier to

I don't agree with you.  Lets hear from others I will support consensus.

regards,
/jim