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

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Thu, 23 Jan 2003 18:03:52 +0900

I have several questions about
draft-ietf-dhc-dhcpv6-opt-prefix-delegation-01.txt from my
implementation experiences.

1. Should the PD (prefix delegation) draft have a similar rule of the
   NoAddrsAvail case in Section 18.2 of dhcpv6-28?  The dhcpv6 spec
   says:
     If the server cannot assign any addresses to an IA in the message
     from the client, the server MUST include the IA in the Reply message
     with no addresses in the IA and a Status Code option in the IA
     containing status code NoAddrsAvail.

   I could not find a corresponding description in Section 11 of
   the PD draft, but our implementation currently applies the same
   logic to the PD case.  That is,

     If the delegating router cannot delegate any prefixes to an IA_PD
     in the message from the requesting router, the delegating router
     MUST include the IA_PD in the Reply message with no prefixes in
     the IA_PD and a Status Code option in the IA_PD containing status
     code NoPrefixAvail.

  (Note that we cannot just copy the dhcpv6 spec, because the status
   code is different.)

2. A similar question applies to the NoBinding case of Section 18.1.8
   of dhcpv6-28.

     When the client receives a NoBinding status in an IA from the server
     in response to a Renew message or a Rebind message, the client sends
     a Request to reestablish an IA with the server.

  In this case, however, we could say that a natural analogy should
  apply, since the sentence is quite generic.

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.

					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: Ralph Droms <[email-masked]>
Date: Thu, 23 Jan 2003 16:28:00 -0500

My comments are in line...

- Ralph

At 06:03 PM 1/23/2003 +0900, JINMEI Tatuya / 
>   (Note that we cannot just copy the dhcpv6 spec, because the status

I suggest Jinmei-san's text should appear following the first paragraph
of Section 11.2, "Delegating Router behaviour" of
draft-ietf-dhc-dhcpv6-opt-prefix-delegation-01.txt.

>   apply, since the sentence is quite generic.

We could add a copy of the paragraph cited above, following the second
paragraph of Section 11.1, "Requesting router behaviour" of
draft-ietf-dhc-dhcpv6-opt-prefix-delegation-01.txt.

>   to use a Renew/Reply exchange.  If there is, the PD draft should be

Yes, I think a Confirm message could be used in this case.

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Sun, 26 Jan 2003 15:36:48 +0900

>>>>> On Thu, 23 Jan 2003 16:28:00 -0500, 
>>>>> Ralph Droms <[email-masked]> said:

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

					JINMEI, Tatuya