Subject: RE: DHCPv6 address model proposal...

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

>Jim asked us to contribute actual verbiage for any
>changes we want to the current spec, so I'm expecting to contribute
>verbiage for the address model proposal, but I don't feel confident
>that I could word this part correctly.   Could you do that?

Hm. I'm using my IPv6 knowledge that's several years old. From what I
understand, it is hopefully still valid. I can certainly try, but there may
be little need as this concept (requesting an address with a specific
prefix) is already in the DHCPv6 draft.

>I'm afraid I don't know what you mean by a "basic" address request.
>Can you expand on this?

Sure. What I meant was the request the system generates when it comes up,
instead of an application or otherwise requested allocation. All systems are
likely to request this whenever DHCP is enabled on an interface, so rather
than having them supply an identifier, make this the no (or null)
identifier. That way, a simple client that only supports "one" allocation
never has to deal with this identifier.

- Bernie Volz

-----Original Message-----
From: Ted Lemon [mailto:[email-masked]]
Sent: Wednesday, September 06, 2000 4:33 PM
To: DHCPv6 discussion list
Subject: Re: DHCPv6 address model proposal...

> I also think that a client should be able to ask for "specific" addresses.
> The way it does this is that is supplies the "address" option but provides
> an INCOMPLETE address (for IPv6, this is one with a prefix length of less
> than 128; for IPv4, this is one with a mask length of less than 32?).
Since
> these are incomplete addresses, the server knows that this is a "subnet
> selection" type request and can supply those addresses (if available to
the
> client); the server MAY supply any number of other addresses it deems the
> client should have.

Hm.   Missed this part.   I agree that this makes sense, although I
don't grok IPv6 addressing well enough to understand exactly how this
would work.   Jim asked us to contribute actual verbiage for any
changes we want to the current spec, so I'm expecting to contribute
verbiage for the address model proposal, but I don't feel confident
that I could word this part correctly.   Could you do that?

> I also believe that we should have a "magic" address assignment ID such
that
> a server knows that this is the "basic" set of addresses for the client.
> This could be the "null" (or absent) address assignment ID. I think this
has
> value in that a server may want to know to give out single addresses for
> non-"magic" address assignment IDs since these are likely for application
> specific purposes and thus a single address likely suffices. I'm not
> suggesting that we require this; just that it would be helpful for the
> client and server to agree on what is a "basic" address request.

I'm afraid I don't know what you mean by a "basic" address request.
Can you expand on this?

> A request should either renew one or more addresses or request "new"
> addresses, not both.

Good point.   However, I'm not sure we actually need to add anything
to support this - really, if you want a "new" address, you're
generating a new identity association.   So the server will have to
allocate it a new address, because it never previously allocated it an
address.   If you have an old identity association, that fact in
itself means you're hoping to get back an old address, doesn't it?
Do we need to make an explicit distinction here between "new" and
"renew"?

			       _MelloN_

---

From: Ted Lemon <[email-masked]>
Date: Wed, 06 Sep 2000 14:24:42 -0700

> never has to deal with this identifier.

But there *has* to be an identifier.  Right now it's the local link
address, but as we discussed last week, this doesn't work well,
because the local link address can change arbitrarily based on
swapping hardware.  I think we need this the *most* in the simple
case, actually.

			       _MelloN_

---

From: "Barr Hibbs" <[email-masked]>
Date: Wed, 6 Sep 2000 15:41:25 -0700

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
|     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
|     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:03:18 -0400

Bernie,

>prefix) is already in the DHCPv6 draft.

We need to recall that we today permit two ways to give out addresses.
In dhcpv6 of course.

#1.  Send the client 128bit address in total.
#2.  Send the client prefixes and they use their link-local.
     (this is how stateless works).

This is not a problem to write up if we understand our own model it will
work both ways above again I assume.

>never has to deal with this identifier.

I don't think a null identifier is wise.  Recall one of the goals.
These need to be used for security.  I think the IESG will barf all over
any identifiers that also are used to determine security associations
and then we permit it to be null.  At least I would if on the IESG.

If we go with teds model I don't see any overhead using the identifier
and their is minimal performance gain vs the functionality we get by
saying you must use the identifier.  We have an opportunity with this
model to also make dhcpv6 very "secure" ""in a cost efficienct manner".

regards,
/jim