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

From: "Bernie Volz (EUD)" <[email-masked]>
Date: Thu, 19 Jul 2001 21:12:44 -0500

In the case of 3G cell phone, yes.

But, what about Wireless LAN (802.11b)? Could this "flop" between two Access
Point which have different prefixes?

Anyway, Ted was just trying to leave some room for implementations to use
other information they may have that would contradict the NoPrefixMatch or
possibly make it suspect.

In the case were a client has just powered on (or gets a link signal that it
may have moved) and is doing a Confirm, getting a NoPrefixMatch likely would
not require further determination.

But, if what if that NoPrefixMatch is returned for other messages. The client
has no other signal that the link may have changed out from under it, so in
that case it might want to be a bit more cautious.

I suspect that most implementations will simply assume that the link has 
changed and do a Solicit to find servers.

So, do we want to force that behavior or allow a client some latitude to take
steps to confirm this change?

- Bernie

-----Original Message-----
From: Jim Bound [mailto:[email-masked]]
Sent: Thursday, July 19, 2001 9:37 PM
To: DHCPv6 discussion list
Subject: Re: DHCPNACK for DHCPv6 [Proposed Draft Changes] 

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

/jim

On Thu, 19 Jul 2001, 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.  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: Fri, 20 Jul 2001 00:10:15 -0400 (EDT)

just as some other input.  we are working on this exactly now in research
with a handheld.  one interface is 802.11 and the other GPRS.  As best as
I can see now the only approach is to treat it as two interfaces in this
case and it becomes a multihomed ipv6 node.

Now the other case I am talking to folks about is sending voice over
802.11 even though it supposed to be only for data (who cares thats 11mbs)
but then its still the same interface to the Acess Point.

So where I was coming from was I think if someone could build a card that
supported say two cell area providers at the same time they may have one
interface to their dhcpv6 client.

But is also this moot in practice?  I think the one place stateless is a
done deal is at the wireless handheld for IPv6?  Maybe not.  I don't
really know I guess but thats my gut feeling.  

/jim

---

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

> really know I guess but thats my gut feeling.  

There's no harm in leaving the flexibility in.   I have no idea how it
will be used.   Do you see any harm in it?

			       _MelloN_

---

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

Any time we add bloat to a protocol design for  things that may never get
used I treat as harm.

/jim