Subject: Re: DHCPv6 issues status

From: Francis Dupont <[email-masked]>
Date: Fri, 17 Dec 1999 05:10:15 -0500 (EST)

In your previous mail you wrote:

   1) General Releasable resources
   
=> Address extension should have a type in the reserved area because
it is a releasable resource (ie. its type should be something like 57344).

   2) Multiple Addresses, Multiple servers
   
   	- Simple clients do not include the prefix request ERE, and thus
   	  only care to get *some* set of one or more IP addresses
   	  returned by the server.

=> I don't know if we can be simpler for simple clients: I believe
a simple client will care to get only one address because it is the
simplest thing and the simple client is not smart enough to know
the number of prefixes (what happens when the client askes for too
many addresses?).

          They make the number of IP addresses
   	  known by including empty IP address extensions in their DHCP
   	  request.
   
=> the next I-D should defined what is an empty IP address extension
(zero/undefined address and zero prefix size for instance).

   3) Router Advertisements
   
=> I'd like to get the comment about A bits (ie. A bits are for
stateless autoconf then they should be zero when the M bit is set to one)
in a rationate/explanation statement.

   4) Reconfigure/Renumbering
   
=> reconfigure seems to be the right way to deal with this and
it is an essential new feature of DHCPv6 over DHCP. I am eager to
read the separate E-mail message about it.
   
   6) API interface for clients
   
   I proposed an informational RFC which would describe an API which could
   be used by applications to make requests to and retrieve data from a
   DHCPv6 client. The other authors thought this was a good idea. What do
   you think?
   
=> this is a good idea because DHCPv6 is more complex than DHCP,
for instance we need something like a daemon with a thread per interface
in order to deal with reconfigure (ie. a simple RPC is not enough).

   7) Multiple Interfaces, multiple choices for application layer extensions.
   
   Erik raised a concern about how a client would present a coherent view
   of the data returned from multiple interfaces when such data might
   conflict. I suggested we use the method the Solaris DHCPv4 client uses
   to resolve the conflict - the user picks a "primary" interface, and the
   data associated with that interface is authoritative. I've heard no
   comment for or against this proposal. Your input is welcomed.
   
=> this seems to be a reasonable way to solve this issue (see previous
point too).

Regards

[email-masked]

PS: I'd like to have a clarification about how the server recognizes
a client when the client can directly talk to the server without a
relay (ie. how the client fills address fields in Request messages
in such a case and how the server deals with this).
Proposal: the client fills Request messages as it does when it uses
a relay but sends packets directly to the server: client identification
and message delivery are two different things and some fields in
messages are used by both functions and others by only one (as interface
index and prefix-size). This should work but needs clarification.

---

From: Mike Carney - SNT Internet Engineering <[email-masked]>
Date: Fri, 17 Dec 1999 13:55:18 -0500 (EST)

Greetings, Francis -

> it is a releasable resource (ie. its type should be something like 57344).

Good point, we might as well be consistent right from the beginning.

> the number of prefixes (what happens when the client askes for too

Exactly the point. We want to allow for clients that run the gamut from
very simple (accept what the server gives them) to sophisticated (request
addresses as needed). For the more sophisticated client which asks for too
many addresses, that would be addressed through a policy setting in the server
implementation - max number of addresses per client per network, for example.

> (zero/undefined address and zero prefix size for instance).

Yes, we plan on being explicit in the IP address extension material on how
prefixes are encoded.

> in a rationate/explanation statement.

Agreed. We ensure we haven't left any inconsistencies at the interface where
stateless meets stateful. Continuing the discussion thread on this exact issue
would help us accomplish this.

> read the separate E-mail message about it.

Should go out today, if we (authors) reach consensus on the note.

> in order to deal with reconfigure (ie. a simple RPC is not enough).

We've found it critical to do this for DHCPv4 as well for our own
applications. It may be worthwhile covering a similar interface for v4 as well
as v6, whether it be in the same document or a separate document.

> => this seems to be a reasonable way to solve this issue (see previous

Thanks for verifying this.

> index and prefix-size). This should work but needs clarification.

Yes, the discussion between you and Erik regarding the use of interface indexes
and relay agents wasn't part of this note. We need to address your concerns.

Two things:

1) interface indexes can change if the router is reconfigured differently.
Thus, I don't think they're consistent enough to rely on.

Example: the following is from a machine where I configured le1 first, when
before, le0 was configured first. Note that index 2 is now le1, when before I
rebooted, it was le0.

lo0: flags=1000849<UP,LOOPBACK,RUNNING,MULTICAST,IPv4> mtu 8232 index 1
        inet 127.0.0.1 netmask ff000000 
le1: flags=1004843<UP,BROADCAST,RUNNING,MULTICAST,DHCP,IPv4> mtu 1500 index 2
        inet 192.168.252.251 netmask ffffff00 broadcast 192.168.252.255
        ether 8:0:20:11:df:30 
lo0: flags=2000849<UP,LOOPBACK,RUNNING,MULTICAST,IPv6> mtu 8252 index 1
        inet6 ::1/128 
le0: flags=2000841<UP,RUNNING,MULTICAST,IPv6> mtu 1500 index 3
        ether 8:0:20:11:df:30 
        inet6 fe80::a00:20ff:fe11:df30/10 
le0:1: flags=2080841<UP,RUNNING,MULTICAST,ADDRCONF,IPv6> mtu 1500 index 3
        inet6 fec0:0:ac17:8000:a00:20ff:fe11:df30/64 
le0:2: flags=2080841<UP,RUNNING,MULTICAST,ADDRCONF,IPv6> mtu 1500 index 3
        inet6 2000:0:ac17:8000:a00:20ff:fe11:df30/64

2) Clarification regarding the agent address field never made it into the
current draft. It's the prefix that's sent, not the agent address. The
combination of the prefix, client's link-local address, and one or more IP
address extensions referring to the precise IP address(es) is enough for the
server to identify the client's binding (unless I'm missing something).

Mike Carney
SNT Internet Engineering
Sun Microsystems, Inc.
Mailstop UBUR02-212
One Network Drive
Burlington, MA 01803

---

From: Francis Dupont <[email-masked]>
Date: Fri, 17 Dec 1999 16:47:14 -0500 (EST)

Two things:

=> my idea is the relay adds the index of the interface where it has
received the packet from the client then it can use it in order to
forward the answer from the server to the client. The interface index
should not be used for other things (it should be only copied) then
if the relay reboots at most a packet can have a bad interface index.
 I think we need it in the case a prefix is shared between several
interfaces on the relay with only one global address for the whole set
of interfaces (for instance links are "unnumbered" point-to-points,
ie. they have only link-local addresses and one global address
to make DHCPv6 happy. If the relay looks at allocated addresses
it can add a host route per client)
 Of course I no more want to use the interface index for client
identification in the server (cf discussion with Erik).

Thanks

[email-masked]