RE: [dhcwg] question about NoPrefixAvail in DHCPv6 advertisement

"Bernie Volz" <volz@cisco.com> Sun, 20 March 2005 14:57 UTC

Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21045 for <dhcwg-web-archive@ietf.org>; Sun, 20 Mar 2005 09:57:40 -0500 (EST)
Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DD1wy-0007OQ-Gt for dhcwg-web-archive@ietf.org; Sun, 20 Mar 2005 10:02:44 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DD1pK-0006CF-4i; Sun, 20 Mar 2005 09:54:50 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DD1pI-0006By-7v for dhcwg@megatron.ietf.org; Sun, 20 Mar 2005 09:54:48 -0500
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20919 for <dhcwg@ietf.org>; Sun, 20 Mar 2005 09:54:46 -0500 (EST)
Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DD1uA-0007Gx-Av for dhcwg@ietf.org; Sun, 20 Mar 2005 09:59:50 -0500
Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-2.cisco.com with ESMTP; 20 Mar 2005 06:54:39 -0800
Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j2KEsXDr025532; Sun, 20 Mar 2005 06:54:34 -0800 (PST)
Received: from volzw2k (che-vpn-cluster-2-31.cisco.com [10.86.242.31]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id APY62812; Sun, 20 Mar 2005 09:54:34 -0500 (EST)
Message-Id: <200503201454.APY62812@flask.cisco.com>
From: "Bernie Volz" <volz@cisco.com>
To: "'JINMEI Tatuya / ????'" <jinmei@isl.rdc.toshiba.co.jp>, <dhcwg@ietf.org>
Subject: RE: [dhcwg] question about NoPrefixAvail in DHCPv6 advertisement
Date: Sun, 20 Mar 2005 09:54:34 -0500
Organization: Cisco
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook, Build 11.0.6353
In-Reply-To: <y7vk6zf6vct.wl@ocean.jinmei.org>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
Thread-Index: AcUsjCJRPMD55FhCTymQ4tXiLzmKHgA0Ccig
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 67c1ea29f88502ef6a32ccec927970f0
Content-Transfer-Encoding: 7bit
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: dhcwg.ietf.org
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:dhcwg@ietf.org>
List-Help: <mailto:dhcwg-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=subscribe>
Sender: dhcwg-bounces@ietf.org
Errors-To: dhcwg-bounces@ietf.org
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 2086112c730e13d5955355df27e3074b
Content-Transfer-Encoding: 7bit

Jinmei:

I agree with you that the behavior should be the same for IA_NA/IA_TA vs
IA_PD:

It is important to note that BOTH could be operating at the same time - a
router might Solicit both an IA_NA and a IA_PD in a single request.

- Bernie  

> -----Original Message-----
> From: dhcwg-admin@ietf.org [mailto:dhcwg-admin@ietf.org] On 
> Behalf Of JINMEI Tatuya / ????
> Sent: Friday, May 14, 2004 8:34 AM
> To: dhcwg@ietf.org
> Subject: [dhcwg] question about NoPrefixAvail in DHCPv6 advertisement
> 
> Hello,
> 
> I have a question about the following part of RFC3633 (Prefix Options
> for DHCPv6):
> 
> 11.2.  Delegating router behavior
> 
> [...]
> 
>    If the delegating router will not assign any prefixes to any IA_PDs
>    in a subsequent Request from the requesting router, the delegating
>    router MUST send an Advertise message to the requesting router that
>    includes the IA_PD with no prefixes in the IA_PD and a Status Code
>    option in the IA_PD containing status code NoPrefixAvail 
> and a status
>    message for the user, a Server Identifier option with the 
> delegating
>    router's DUID and a Client Identifier option with the requesting
>    router's DUID.
> 
> Why should the delegating router include the IA_PD option(s) as well
> as the status code option (for NoPrefixAvail)?  According to the
> condition that "the router will not assign *any prefixes* to *any
> IA_PDs*", it should be enough to include the status code only.  In
> fact, in the similar condition of RFC3315 a DHCPv6 server just include
> a status code option with NoAddrsAvail:
> 
>    If the server will not assign any addresses to any IAs in a
>    subsequent Request from the client, the server MUST send 
> an Advertise
>    message to the client that includes only a Status Code option with
>    code NoAddrsAvail and a status message for the user, a Server
>    Identifier option with the server's DUID, and a Client Identifier
>    option with the client's DUID.
> 
> I don't see any fundamental differences between the two cases.
> 
> Moreover, the description for the counterpart at the requesting router
> seems to not be consistent very much with the above description for
> the delegating router.  In section 11.1, RFC3633 says:
> 
>    The requesting router MUST ignore any Advertise message 
> that includes
>    a Status Code option containing the value NoPrefixAvail, with the
>    exception that the requesting router MAY display the associated
>    status message to the user.
> 
> It seems to me that this description does not assume the IA_PD option
> containing a Status Code option (with NoPrefixAvail).  Rather, the
> intention seems to be an advertisement only containing a status code
> option.
> 
> To be more concrete, consider the following example.
> 
> 1. the requesting router sends a DHCPv6 solicit message that includes
>    two IA_PD options:
>    solicit: IA_PD (IAID=1, T1, T2), IA_PD(IAID=2, T1, T2)
> 
> 2. unfortunately, the delegating router cannot assign any prefix to
>    any IA_PDs specified by the requesting router.  According to
>    section 11.2, the delegating router sends a DHCPv6 advertisement
>    like this:
>    advertisement: IA_PD (IAID=1, T1, T2, StatusCode(NoPrefixAvail)),
>                   IA_PD (IAID=2, T1, T2, StatusCode(NoPrefixAvail))
> 
> 3. the delegating router receives the advertisement.  The intention
>    of section 11.1 is probably that the delegating router must ignore
>    the advertisement.  The intention looks sane, but the description
>    of the specification is not very clear.  It says: 
> 
>      The requesting router MUST ignore any Advertise message 
> that includes
>      a Status Code option containing the value NoPrefixAvail,
> 
>    so, can the requesting router ignore the advertisement by simply
>    seeing the first StatusCode with NoPrefixAvail containing in the
>    first IA_PD?  Or, is the requesting router expected to parse the
>    entire advertisement and to make the decision to ignore the
>    advertisement only after confirming all the IA_PD options contain
>    StatusCode with NoPrefixAvail?  What should the requesting router
>    do if the first IA_PD contains NoPrefixAvail but the second one
>    does not?
> 
> I personally think the behavior described in RFC3633 is not the best
> one, and should be revised to be consistent with RFC3315.  It should
> probably be too late, however, and if so, I believe we should at least
> clarify the point and make a separate internet draft clarifying this
> point (which will hopefully be merged to the PD specification when it
> is ready for becoming a DS).  Otherwise, this might be a serious
> interoperability issue.
> 
> 					JINMEI, Tatuya
> 					Communication Platform Lab.
> 					Corporate R&D Center, 
> Toshiba Corp.
> 					jinmei@isl.rdc.toshiba.co.jp
> 
> _______________________________________________
> dhcwg mailing list
> dhcwg@ietf.org
> https://www1.ietf.org/mailman/listinfo/dhcwg
> 

_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
https://www1.ietf.org/mailman/listinfo/dhcwg