Subject: Re: [dhcwg] questions about prefix-delegation-01

From: Ole Troan <[email-masked]>
Date: Tue, 04 Feb 2003 05:21:20 +0000

>>> 3. Section 11 of the PD draft says:
>>> 
>>> In some circumstances the requesting router may need verification
>>> that the delegating router still has a valid binding for the
>>> requesting router.  Examples of times when a requesting router may
>>> ask for such verification include:
>>> 
>>> o  The requesting router reboots.
>>> ...
>>> If such verification is needed the requesting router MUST initiate a
>>> Renew/Reply message exchange as described in the section "Creation
>>> and Transmission of Renew Messages" of the DHCP specification [6].
>>> 
>>> I don't see why a Renew/Reply exchange is used, instead of a
>>> Confirm/Reply exchange.  The described situation is very similar to
>>> Section 18.1.2 of dhcpv6-28, and I don't see an essential difference
>>> to use a Renew/Reply exchange.  If there is, the PD draft should be
>>> clear on this.
>
>> Yes, I think a Confirm message could be used in this case.
>
> Okay, so do you think the PD draft should be updated by replacing the
> Renew with Confirm?  I personally think it should, because otherwise
> it would be unclear why we had Confirm in the base DHCPv6 spec in the
> first place.

the Confirm message has different semantics. it is used to verify that
a prefix is still on-link, something which restricts it usefulness to
address assignment. the Reply to a Confirm can come from any server,
and there is no requirement that a binding with the server exists.

for PD we wanted a message exchange to verify that the delegating
router still has a binding with the requesting router, therefore the
use of Renew.

/ot
_______________________________________________
dhcwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dhcwg

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Tue, 04 Feb 2003 19:00:38 +0900

>>>>> On Tue, 04 Feb 2003 05:21:20 +0000, 
>>>>> Ole Troan <[email-masked]> said:

> router still has a binding with the requesting router, therefore the

Okay, I understand the intention.  However, I still think of a case
where Confirm is more appropriate.  For example, suppose that we have
two upstream "cables", each of which connects to a separate ISP.  Also
suppose that the requesting router has an upstream port.  We first
plug one cable to the upstream port, and then switch to another
cable.  This situation corresponds to the following case of the PD
draft:

   o  The requesting router is physically disconnected from a wired
      connection.

In this case, the upstream server (a delegating router) should change.
If we use a Renew message, the server would ignore it because the
server Identifier does not match.  As a result, we cannot invalidate
the stale prefix until the renew/reply exchanges fail (or, in the
worst case, until the lifetime of the prefix expires).  On the other
hand, if we use a Confirm message, the upstream server would notice
that the prefixes do not belong to the ISP, and send a reply with some
negative status code.  Then the requesting router can restart
soliciting delegating router and will be able get a new, valid prefix.

					JINMEI, Tatuya
					Communication Platform Lab.
					Corporate R&D Center, Toshiba Corp.
					[email-masked]
_______________________________________________
dhcwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dhcwg

---

From: Ole Troan <[email-masked]>
Date: Tue, 04 Feb 2003 22:55:52 +0000

> soliciting delegating router and will be able get a new, valid prefix.

Confirm as it is currently specified can only be used for the address
options. to make it useful for any type of stateful option it
would have to be changed to:

 - allow confirmation of binding
 - return status code within each option's IA

this is unfortunate but I think it is too late in the game to
change it now.

one possibility is to create a new message type, e.g "Verify", which
has the semantics from Renew (without the ServerId option),
retransmission timers from Confirm and where the status code in a
Reply would be encapsulated in the IA option.

/ot

---

From: Ole Troan <[email-masked]>
Date: Wed, 05 Feb 2003 07:03:27 +0000

>>>>>> On Tue, 04 Feb 2003 22:55:52 +0000, 
> I agree that the ideal approach would be to make the base DHCPv6 spec
> generic and that such an attempt is unfortunately too late.
>
> This would be a possibility.  However, I also think we can still
> "overload" the Confirm message so that it can be used for the PD (or
> other stateful resources) case.
>
> I don't want to introduce too-much generalization into the PD spec and
> to delay the standardization.  But I do not want to see an easygoing
> compromise either, because this is a good (and perhaps the last)
> chance to make the PD spec complete.  So, I'd like to hear from
> others, if anyone else has an opinion on this.

Confirm allows other servers than the one with the binding to reply,
if they have the required information, i.e if the prefix is onlink or
not. I think it is much less likely in the PD case that other servers
than the one with the binding will have the knowledge to determine if
the prefix is correct or not. if you accept this point, then the
scenario you outlined earlier can easily be solved. when Renew is used
as Confirm, Renew should use Confirm's retransmission timers. the
message exchange will stop after 10 seconds, and the requesting router
will go back to soliciting for delegating routers.

cheers,
Ole

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Wed, 05 Feb 2003 15:03:35 +0900

JINMEI, Tatuya

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Wed, 05 Feb 2003 18:27:04 +0900

>>>>> On Wed, 05 Feb 2003 07:03:27 +0000, 

> will go back to soliciting for delegating routers.

As I said in the previous message, I think it is possible that the
other servers have the (particularly negative) knowledge of the prefix
validity.  Also, using different parameters for Renew requires a
special treatment for PD on the base DHCPv6 specification, so I don't
see an advantage of this approach comparing to "overloaded" Confirm.

However, either approach would cover the typical case, so I don't
stick to the idea of overloaded Confirm.  I'll hear from others, and
will follow the consensus.  (If there is no other opinion, I'll follow
the author's decision).

					JINMEI, Tatuya

---

From: Ralph Droms <[email-masked]>
Date: Wed, 05 Feb 2003 10:15:56 -0500

Suppose the RR were to send a Rebind (instead of Renew) in the case that 
the RR may have moved to a new link?  The upstream DR would process the 
Rebind and be able to respond immediately with zero lifetimes in the IA_PD, 
indicating that the prefixes in the IA_PD are no longer valid.

- Ralph

At 06:27 PM 2/5/2003 +0900, JINMEI Tatuya /

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Thu, 06 Feb 2003 02:32:50 +0900

>>>>> On Wed, 05 Feb 2003 10:15:56 -0500, 
>>>>> Ralph Droms <[email-masked]> said:

> indicating that the prefixes in the IA_PD are no longer valid.

Hmm, I guess you're applying the following part of the base DHCPv6
spec:

   If the server finds that any of the addresses are no longer
   appropriate to the link to which the client is attached, the server
   returns the address to the client with lifetimes of 0.
(Section 18.2.4)

However, the section also has the following sentence (before this
part):

   If the server cannot find a client entry for the IA the server
   returns the IA containing no addresses with a Status Code option set
   to NoBinding in the Reply message.

Additionally, according to a recent discussion, we're now agreeing
that the upstream server should ignore the Rebind in such a case.  So,
I don't think we cannot directly apply the case, and this leads me to
a same conclusion as Renew: I don't see an advantage to use Rebind
against Confirm.

However, again, I don't stick to Confirm.  I'll follow the final
consensus (or the author's decision if there is no particular opinion)
as long as the specification is clear and can handle the situation I
raised.

					JINMEI, Tatuya