Subject: DHCPv6 Input from Francis Dupont

From: Jim Bound <[email-masked]>
Date: Tue, 16 Nov 1999 14:52:47 -0500 (EST)

Forwarded with permission from Francis...
Can we discuss this please...

thanks
the authors

------- Forwarded Message

From: Francis Dupont <[email-masked]>
To: Jim Bound <[email-masked]>, Charles Perkins <[email-masked]>,
        Mike Carney <[email-masked]>
Cc: Yanick Pouffary <[email-masked]>
Subject: DHCPv6 flawns with fixes
Date: Mon, 15 Nov 1999 16:27:28 +0100
Sender: [email-masked]

I've read again technical reports from my students, current I-Ds
(dhcpv6-14 and v6exts-11) and ND/autoconf RFCs.
There are still minor problems in I-Ds, perhaps some of them are already
fixed, and a major problem with multiple prefixes (I believe I've found
a nice way to fix it).

First some obvious minor bugs in dhcpv6-14:
 - minimal MTU for IPv6 is 1280, not 1500 (annexe B, pages 35-36)
   (the discussion is still valid, only the value is wrong)
 - transaction ID threshold is 1024, not 1000, and clients use the >= 1024,
   not the <= 1000 (2.2 page 4, 4.3 page 12, 5.7 page 21)
   (fix 2.2)

Lacks of documentation:
 - dhcpv6-14 should explain which kinds of extensions can be in advertise
   messages, I believe only security extensions are useful there
 - DHCPv6 is link-oriented, ie. a multi-homed client should deal with
   autoconfiguration independently on each link
 - I'd like to get more text about renumbering and DHCPv6 servers,
   for instance I believe DHCPv6 servers should be targets of the router
   renumbering protocol/process (verify with Matt if this can be a problem,
   I believe this should work fine). Another interaction is for DHCPv6
   clients which are routers too.
 - v6exts-11 should mention address extension as the only defined releasable
   resource (then you can defer releable resource issue solution :-)

A potential problem in dhcpv6-14:
 - IPv6 address fields should be aligned on 64 bit boundaries in headers
 - the use of prefix-size is still not clear for me
 - I prefer to have a 32 bit interface index (relative to the agent)
   in place of the agent address + prefix-size. I am not convinced
   address + prefix-size is enough for all topologies, an interface index
   is clearer and easier to use (as a scope ID). This solves the alignement
   problem to if link-local addresses are replaced by interface index +
   link-local address.

Multiple prefix problem:
 - summary: my idea is to enforce one-for-one extension in request/reply
   and to use reconfigure in order to add extra prefixes.
 - the real source of the problem is in RFC 2462 5.5.3 "Router
   Advertisement Processing" page 17 where you can find after two paragraphs
   about M (managed) and O (other) bits this statement:
   "For each Prefix-Information option in the Router Advertisement: a-e)"
   obviously the text after this statement and the 5.6 "Configuration
   Consistency" section next page (with "hosts accept the union of all
   information ..." are misleading in the stateful autoconf context.
 - if the stateful autoconf *only* is used for address management then
   the good way to change a prefix on clients (for new prefixes, lifetime
   changes, ...) is to use the reconfiguration facility.

Proposed stateful address management:
 - at boot time a stateful client will request an address to its server.
 - a server should reserved an address per prefix to a new client,
   sends the first address in the reply and sends reconfigure messages
   for extra addresses. At the end of this phased an address per prefix
   is allocated/configurated.
 - on a prefix change, a server sends reconfigure messages to its clients
   (it may use multicast if available) in order to reflect the change.
 - a client can look at prefix-infos in router advertisements but should
   not use them directly if a stateful server is available. For instance
   if a router advertisement shows a change for a prefix, a stateful
   client MUST NOT apply the change but MAY send a request to its server
   in order to validate the change after a random delay (in order to avoid
   many requests at the same time and to give the time for a reconfigure).

Proposed new mode of autoconfiguration:
 - today we have stateless (use router advertisements) and stateful
   (use DHCPv6). If we make stateful stronger then we have to deal with
   the case where stateful is selected but no stateful service is available.
 - in this case (named ?) stateless rules will apply and from time to
   time an attempt should be done in order to find a stateful server.
 - if one is found the standard revalidation process should be done
   (same case than the current server is lost) and the client should
   enter in the "strong" stateful mode.
 - the same process should apply when the managed flag changes from
   false to true the first time.
 - another view of this can be:
   * strong stateful is "stateful enabled, stateless disabled"
   * weak stateful is "stateful and stateless enabled", ie.
     when the stateful mode is enabled and a stateful service is available
     then the stateless mode is disabled.
   this can make the wording of RFC 2462 update easier, ie. the only thing
   needed is an addition of "when the stateless mode is available" at
   the middle of 5.5.3 section (For each Prefix-Information option...).
   The conflicting 5.6 will need near no clarification too!

Regards

[email-masked]

PS: I can send Jean-Jacques'report (in French) to Yannick if you'd like,
his major comment is the current ID should enforce the "no user config
on client" principle, ie. the state should be on servers.

------- End of Forwarded Message

---

From: Erik Nordmark <[email-masked]>
Date: Thu, 18 Nov 1999 22:20:12 -0500 (EST)

>    problem to if link-local addresses are replaced by interface index +

If we go the above path this implies that a client will be inentified
by the ifindex on the relay plus the client's link-local address.
This implies that if a relay fails (and there is a second relay on the link)
the client will be viewed as a new client - it will have a new identity from
the perspective of the server. Likewise if the relay reboots since interface
indicies are not required to be the same after a reboot.

Thus I think we need to first decide what the desired behavior is
in the above two cases and from that derive what should identify the client.
Then we can decide what should go in the packet.

>    information ..." are misleading in the stateful autoconf context.

What is misleading?
The intent is that if the M bit is set and the router advertisements
contain e.g. 2 prefixes with the A flag set then the host will 
use stateless addrconf to form two addresses, and invoke DHCP to ask for
addresses and other configuration.

But typically I assume that if the routers send the M bit they wouldn't
set the A flag in any prefix advertisements meaning that all addresses
come from DHCP.

>    the middle of 5.5.3 section (For each Prefix-Information option...).

But isn't "stateless mode is available" the same as "one or more prefixes
have the A bit set"?
Thus I think we already have the necessary knobs.

   Erik

---

From: Jim Bound <[email-masked]>
Date: Thu, 18 Nov 1999 23:31:22 -0500 (EST)

>indicies are not required to be the same after a reboot.

This is a problem.  We need to have as consistent state for a client in
the server database as possible to find them.

   A server maintains a collection of client records, called
   ``bindings''.  Each binding is uniquely identifiable by the ordered
   pair <link-local address, agent-address>, since the link-local
   address is guaranteed to be unique [20] on the link identified by the
  agent-address and prefix.  An implementation MUST support bindings
   consisting of at least a client's link-local address, agent-address,
  preferred lifetime and valid lifetime [20] for each client address.

If the agent address is replaced by interface-id how do we make sure it is 
unique on another lan where the link-local address is duplicated and in
fact the interface ID?  I don't think this will work and we should leave
the bindings to be what they are now.

But this may raise a bug in the specs.  It could be we need to state
that the agent-address-prefix is a global one as even a site-local
agent address prefix could theoretically be duplicated though not probable.
We can fix this by simply saying the agent-address must be a global
address.

>Then we can decide what should go in the packet.

I think first it should be discussed what is wrong with the spec first
before we say it needs changing.  I don't think Francis was saying there
is an issue with the specs behavior but you are I think?

Can you articulate what is wrong with the spec as is presently on this
topic?

>set the A flag in any prefix advertisements meaning that all addresses

If they don't do this typically it is an implementation issue how
statless and stateful addresses are managed on the end node and this has
always been the case in discussions in addrconf.  I asked for this to be
resolved as you may recall but we decided to permit the behavior of the
union Francis is speaking of and I agree with him, but believe we must
just live with it.  In my approach I will mask stateless and stateful
addresses as stateless or stateful and will take care of it as an end
node.  So I think Francis is correct, but I don't think its misleading
its just the way the addrconf spec left the issue.  Which is fine with
me and I think most implementors of Ipv6 stateless addrconf.

thanks
/jim

---

From: Erik Nordmark <[email-masked]>
Date: Fri, 19 Nov 1999 23:38:12 -0500 (EST)

> Can you articulate what is wrong with the spec as is presently on this

*If* we agree that a client should be identified as the same client
by a server independent of the relay agent it is using on the link
then I think the spec needs a slight tweak.
It currently says that the client is identified by <link-local address,
agent-address> and I think this should be <link-local address, agent-prefix>.
(where agent-prefix could also be called link-prefix since it is the prefix of
the client's link that matters).

In addition to clarifying the scope (site-local vs. global) for
the agent-prefix as you point out we also need to make sure that
two agents on a link pick the same prefix as agent-prefix,
since there can be multiple global prefixes assigned to the link.
I think some simple rules (pick the numerically largest prefix)
would suffice.

  Erik

---

From: Jim Bound <[email-masked]>
Date: Sat, 20 Nov 1999 23:10:48 -0500 (EST)

Hi Erik,

>then I think the spec needs a slight tweak.

I think we all agreed long ago that a client needs to be identified as
you very nicely stated, if anyone does not agree I would be surprised.

>the client's link that matters).

It should say agent-prefix that was a typo in draft-14 for some reason,
the authors agree with you, and there are other places where we speak of
prefix for sure, but this is an edit error in the spec presently.

>I think some simple rules (pick the numerically largest prefix)

I agree.  We need to add that and the scope issue.

thanks
/jim