Subject: Re: DHCPNACK for DHCPv6 [Proposed Draft Changes]

From: Ralph Droms <[email-masked]>
Date: Thu, 19 Jul 2001 16:54:46 -0400

At 10:01 AM 7/18/2001 -0500, Bernie Volz (EUD) wrote:

>Ralph, et al:
>
>Here's proposed text for dealing with the DHCPNACK issue. Ted and I
>exchanged messages on this text and I've used most of Ted's feedback
>here - though Ted has not seen this latest round.
>
>1) Add to section 7.4.2:
>
>    |NoPrefixMatch_|26______|_An addr in IA not valid for prefix_|_

OK

>2) Add to 14.4.1, 14.4.2, 14.4.4:
>
>    If the server finds that the prefix on one or more IP addresses in
>    any IA in the {Request,Confirm,Rebind} message is not a valid
>    prefix for the link to which the client is connected, the server
>    MUST send an NoPrefixMatch status in the IA status field for that
>    IA in the DHCP Reply message.
>
>    [Should we include Renew in the message list and add to 14.4.3?]

Yes, I think we can include Renew.  I suggest the following change to the 
first sentence:  If the server can determine that the prefix on any of the 
IP addresses in an IA in the XXX message is not a valid prefix for the link 
to which the interface from which the message was received is connected, 
the server MUST send [...]

>3) Add to Section 14.3.5. (Receipt of Reply message in response
>    to a Request, Confirm, Renew or Rebind message):
>
>    When the client receives a NoPrefixMatch error status in the IA status
>    field of a Reply to a Confirm message, the client MUST make a
>    determination as to whether it has moved to a different link.  If the
>    client is unable to make such a determination it MUST assume that it
>    has moved to a new link.  In this case the client MAY discard the IA
>    that received the NoPrefixMatch status, or may retain it as long as
>    the addresses in the IA continue to be valid.

Why should the client make a determination about moving to a new link?  In 
fact, how can it make that determination at this point, which is, I think, 
after the point at which the client may have received an event from its 
interface about loss of carrier, change of access point, etc.?  I suggest 
the following text:

When the client receives a NoPrefixMatch error status in the IA status 
field of a Reply to a Confirm (what about Request and Rebind?) message, the 
client MUST not use any of the addresses in the IA.

Regarding your last sentence - what does it mean to "discard" an IA?

>4) Add somewhere (perhaps in 18.3, Identity Association Option):
>
>    The client MUST NOT send any address in an IA once that address'
>    valid lifetime has expired.

OK.

- Ralph

---

From: Ted Lemon <[email-masked]>
Date: Thu, 19 Jul 2001 14:17:06 -0700

> interface about loss of carrier, change of access point, etc.?  I suggest 

This is the multiple overlapping link layers problem - a 3G cell phone
that is able to contact two different cell towers.  The client in this
case has information that the server does not have, and is probably
talking to more than one server, and therefore is in a position to
know that it can continue to use its addresses.  The case where this
is most likely is when the client broadcast a Confirm message and gets
a response from the server for each cell tower, one of which says
"stop using those addresses" and the other of which says "go ahead and
keep using them."

That is why the text gives the client the option of determining that
it has not changed link layers.  The way the text is worded, there's
an easy out for implementors who have no clue how to make such a
determination, which I suspect would be most implementors.

			       _MelloN_

---

From: Jim Bound <[email-masked]>
Date: Thu, 19 Jul 2001 21:37:03 -0400 (EDT)

but this would have to be two different interfaces which are two different
IA's?

/jim

---

From: Ted Lemon <[email-masked]>
Date: Thu, 19 Jul 2001 21:40:39 -0700

> but this would have to be two different interfaces which are two different

No, it would be the same interface.  Cell phones only have one
interface.  There's really only one physical layer if you want to get
technical, but because we're dealing with real-world radio
propogation, it's mostly possible to think of the space around one
beacon as a seperate physical layer than the space around another
beacon.  But when two beacons' coverage overlaps, there are places
where you could get the behaviour that I'm talking about, where both
beacons think their idea of the network is authoritative, but in fact
it's not.

I do not know if cell phone manufacturers will actually use this
capability, nor if community-based wireless networks will, but I don't
think it causes any harm to leave this possibility open, and I
would therefore like to avoid closing it.

			       _MelloN_

---

From: Jim Bound <[email-masked]>
Date: Sun, 22 Jul 2001 21:48:26 -0400 (EDT)

I would like to close it until we are sure we need to have such an
abstraction and in fact it  will be deployed.  But, if there are
properties from this we should consider and discuss thats a different
story.

thanks

/jim

---

From: Droms Ralph <[email-masked]>
Date: Thu, 26 Jul 2001 08:27:53 -0400

At 02:17 PM 7/19/2001 -0700, Ted Lemon wrote:

>know that it can continue to use its addresses.

OK, now I get it.  I misunderstood the phrase "whether it has moved to a 
different link."  In some sense, if the client is communicating with 
overlapping links, it has, in fact, moved to a new link.  It is still on 
the old link, as well...

Is it more that the client can determine, through some other means, that 
the addresses in an IA are valid although some server - through 
misconfiguration, overlapping links, ??? - has indicated that the addresses 
are not valid?  I suggest the following text in section 14.3.5 (rev -19):

    When the client receives a NoPrefixMatch error status in the IA status
    field of a Reply to a Confirm, Rebind or Renew message, if the client
    can determine through some other means that the addresses in the IA
    are valid for the link to which the interface is attached, the client
    MAY choose to ignore the NoPrefixMatch error.  Examples of ways a client
    can determine the validity are: examining prefixes in router
    advertisements, receipt of a Confirm message from a different server
    that indicates validity of the addresses in the IA, link-layer
    specific mechanisms through which the client can determine that it
    is currently connected to the link for which the client previously
    determined that the addresses in the IA were valid.

    After receiving a NoPrefixMatch error status in the IA status
    field of a Reply to a Confirm, Rebind or Renew message, if the client
    cannot independently determine that the addresses in the IA are still
    valid, the client MUST NOT use any of the addresses in the IA.

- Ralph

---

From: Ted Lemon <[email-masked]>
Date: Thu, 26 Jul 2001 11:36:02 -0700

> are not valid?  I suggest the following text in section 14.3.5 (rev -19):

Your new text works for me.   Thanks!

			       _MelloN_