Resend: [dhcwg] question about NoPrefixAvail in DHCPv6 advertisement

[JINMEI Tatuya / 神明達哉 <[e-mail]>]

I happen to recall the attached message has not had any
responses...could someone answer the question, please?

Thanks,

					JINMEI, Tatuya
					Communication Platform Lab.
					Corporate R&D Center, Toshiba Corp.
					[e-mail]

--- Begin Message ---

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.
					[e-mail]

_______________________________________________
dhcwg mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/dhcwg

--- End Message ---

_______________________________________________
dhcwg mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/dhcwg