Subject: RE: DHCPv6 Relay Changes

From: Bernie Volz <[email-masked]>
Date: Wed, 6 Sep 2000 21:28:46 -0400

Barr:

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?

If you allow the multiple encapsulations (one for each relay), how does the
reverse traffic occur? It goes to the relay nearest the client since it is
the only one that can communicate with the client? Why then include
information about the other relays along the forward (to server) path (I
guess this in case of IPsec? But why re-encapsulate?).

Perhaps I missed something in the write up? Please see two comments
(prefixed by >>>) in the original message below.

Have a good time on your vacation.

- Bernie

-----Original Message-----
From: Barr Hibbs [mailto:[email-masked]]
Sent: Wednesday, September 06, 2000 6:41 PM
To: DHCPv6 discussion list
Subject: RE: DHCPv6 Relay Changes

I had only this one work item following the interim DHCPv6 Working Group
meeting on 31 August.  After reviewing the task and the protocol draft, I'm
offering the following wording changes.  I have not proposed a specific
value for the proposed Encapsulated Message Extension, nor for the new
Relayed message type, believing that such details follow, almost
mechanically, once the principles are agreed.

The many other sections which mention or discuss Relay behavior could remain
untouched, as I believe the sections I'm offering below are the crucial
ones.

Please have a lively discussion about this, and reword or rework as you see
fit -- I'm going to be on vacation beginning tomorrow until the 24th,
sampling the food and wine of the Champagne and Burgundy regions of France,
all without my laptop!

--Barr Hibbs
  UltraDNS Corporation

"Relay agents should simply encapsulate the clilent message
in a DHCPv6 Extension;  the relay message should have its
own type."

Internet Draft           DHCP for IPv6           5 May 2000

8.3.  What if the client and server(s) are on different
      links?

      Use of DHCP in such environments requires one or more
      DHCP relays be set up on the client's link, because a
      client may only have a link-local address.  Relays pick
      up the Solicit and Request messages from the client and
      forward them to some set of servers within the DHCP
|     domain, after encapsulating the entire received Solicit
|     or Request message in an extension (number to be
|     determined) -- the Relay then forwards the encapsulated
|     message on towards its destination as a new message of
|     type Relay (number to be determined).

|     Upon receipt of a relayed message, the client looks in
>>> Isn't "client" in the above line "server"?
|     the extension for the complete, original message, and
|     acts upon it appropriately.  Replies to relayed
|     messages are first constructed as if they were being
|     sent directly to the originating server, then
>>> Isn't "server" in the above line "client"? (servers don't originate
messages)
|     encapsulated in an extension and sent to the Relay from
|     which the message was received.

      In the case where multiple Relays are in the path
      between client and server, each Relay encapsulates
      messages to forward, so that multiple layers of nesting
      are possibly where multiple Relays are traversed.

      A relay will include one of its own addresses (of
      sufficient scope) of the interface on the same link as
      the client. The relay also includes the subnet prefix
      length of that address in the client's messages.
      Servers receiving the forwarded traffic use this
      information to aid in selecting configuration
      parameters appropriate to the client's link.  The
      servers also use the relay's address as the destination
      to forward client-destined messages for final delivery
      by the relay.  Relays forward client messages to
      servers using some combination of the FF05::1:3(All
      Servers) site-local multicast address, some other
      (perhaps a combination) of site-local multicast
      addresses set up within the DHCP domain to include the
      servers in that domain, or a list of unicast addresses
      for servers.  The network administrator makes relay
      configuration decisions based upon the topological
      requirements (scope) of the DHCP domain they are
      managing.  Note that if the DHCP domain spans more than
      the site-local scope, then the relays MUST be
      configured with global addresses for the client's link
      so as to be reachable by servers outside the relays'
      site-local environment.

10.4. Relay Behavior

      For this discussion, the Relay is assumed to have been
      configured with some list of server destination
      addresses, which may be unicast, the FF05::1:3 (All
      DHCP Servers) multicast address, or some other
      multicast address selected by the network
      administrator.

10.4.1. Relaying of Solicit messages

      When a Relay receives a valid Solicit message, it
|     first encapsulates the entire received Solicit
|     message in a new Extension (number to be
|     determined), then the Relay
|     places the IP address of the interface upon which it
|     received the Solicit message in the ``relay-address''
|     field of the new (outer) message which
|     encapsulates the Solicit. The Relay also places the
      number of bits of that make up the subnet prefix for
      this address in the ``prefix-len'' field of the
|     encapsulating message.

|     The Relay then forwards the encapsulating message to
      the list of server destination addresses that it has
      been configured with.

10.4.2. Relaying of Advertise messages

      When a Relay receives a valid Advertise message, it
      unicasts the message to the link-local address found
      in the ``client's link-local address'' field by way of
      the appropriate network interface.

|     The Relay need not encapsulate the Advertise message.

11.5. Relay Behavior

11.5.1. Relaying of Request or Release messages

      When a Relay receives a valid Request or Release
      message, it forwards it to the IP address found in the
      ``server-address'' field of the message.

|     The Relay encapsulates the received message in an Extension
|     (number to be determined) and forwards the new message.

---

From: Jim Bound <[email-masked]>
Date: Thu, 07 Sep 2000 02:59:48 -0400

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.

So the entire Ipv6 would be encapsulated by the relay and sent to the
server in the various ways as Barr noted (multicast/unicast).

We would have a new protocol-id for IPv6 that says inside this IPv6
header is a dhcpv6 message proto-id ??? TBD.

The server upon receiving this at the IPv6 net layer would decapsulate
move the relay address into the giaddr or whatever field, then deliver
it via udp to the server.

The server then would respond directly back to the relay as it does now
in dhcpv4 or dhcpv6.  

This model would need no nested encaps or decaps as the routing would
take care of getting the packet to the server from the relay based on
the dst address in IPv6 header.

If one wants to use a new extension to do this then the question is the
clients Ipv6 header kept in tact behind the relay UDP data (where the
new extension will exist)?

But even in that case it is not necessary to nest the extension or the
encap/decap as this is handled by the routing fabric for IPv6.

regards,
/jim

---

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

>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: Jim Bound <[email-masked]>
Date: Fri, 15 Sep 2000 00:11:46 -0400

>message in another DHCP message between the relay and the server.

Real encapsulation eliminates any new security for the payload.
A new extension changes the payload and the security mechanisms would
have to be rehashed or whatever.

How do we resolve this.

But either way we can avoid nested encapsualtion is my strong
suggestion.  Another way to do it is that relays set the IPv6 HOP-BY-HOP
option and say don't look at this just forward it.

regards,
/jim

- Ralph

---

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

> have to be rehashed or whatever.

Both kinds of encapsulation being discussed here are real.  Nobody is
proposing a BOOTP-style operation where the relay agent modifies the
contents of the payload from the client.  It sounds like you're
proposing IP-in-IP encapsulation, but that can't work, because
IP-in-IP encapsulation doesn't allow the relay agent to add its
information to the payload - only to the header.

A very large portion of the DHCP application space is the cable
modem/DSL provider who very much wants the relay agent to add
additional payload that *can't* go in the IP header - information
about the cable modem head end system, the remote site id, and stuff
like that.   In DHCPv4 we use the relay agent information option, but
this is really ugly - we're only doing it because we have to.

We can't use IPsec for DHCPng, because of the chicken-and-egg startup
problem, so we're not losing anything by not using IP-in-IP
encapsulation.   The relay agent actually *could* use IPsec to the
server, since *it* can establish a security association with the
server, but its IPsec would sign its packet and the entire payload -
the signature on the DHCP client's packet would not be in the header,
and therefore would not be lost.

			       _MelloN_

---

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

>information to the payload - only to the header.

Not proposing anything yet.  Just discussing.  But yes IP-in-IP.

Sure it will.  We just have UDP and the extension barr proposed within
the outer IP.  That will work for sure.  I have made it work a long time
ago when dhcpv6 was I think 19 pages.   A long time ago.  Also IPsec
(not saying use that OK) will work too.  The trick is that you now need
security associations btw the relay and server.

You would have to deliver two UDP packets to the server and what I don't
like about it.

>this is really ugly - we're only doing it because we have to.

Good input.

>and therefore would not be lost.

Not proposing IPsec but I will say for the record dhcpv6 should do
nothing to prevent using IPsec and I don't believe we did in the current
design.

The market will decide security mechanisms not us.

regards,
/jim

			       _MelloN_

---

From: Ted Lemon <[email-masked]>
Date: Thu, 14 Sep 2000 23:45:00 -0700

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