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

From: "Bernie Volz (EUD)" <[email-masked]>
Date: Thu, 26 Jul 2001 09:18:42 -0500

Ralph, et al:

The new text works for me.

Regarding your other issue:
"In the middle of writing my previous message, I had the following thought: 
suppose the link has been renumbered - the addresses in the IA will be 
invalid although the client has remained connected to the same link..."

Isn't this a violation of the address lifetimes? If the lifetimes are
maintained properly, this should never happen.

And, what's the impact? Won't the server send a NoPrefixMatch in this case
because the client's prefixes aren't valid - though the client is still on
the same link? In that case, the client will simply either believe the
NoPrefixMatch and go through Solicit/Advertise or it will ignore the
NoPrefixMatch in which case the lifetimes will expire the address anyway.

Note: There will probably be instances because of clock differences where
a client may still believe an address to be valid when it truely is not.
But that condition should only last for short periods of time and it is
adviseable that there be some "grace" involved in lifetimes.

- Bernie

-----Original Message-----
From: Droms Ralph [mailto:[email-masked]]
Sent: Thursday, July 26, 2001 8:28 AM
To: DHCPv6 discussion list
Cc: DHCPv6 discussion list
Subject: Re: DHCPNACK for DHCPv6 [Proposed Draft Changes] 

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

> > 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:
>
>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.

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: Jim Bound <[email-masked]>
Date: Fri, 27 Jul 2001 11:48:25 -0400 (EDT)

In IPv6 the prefixes could be deprecated to 2 hours by a router. So it
could happen.  Or by the dhcpv6 serverr.

/jim