Subject: Re: [psg.com #250] Reception of prefix option with prefix length > 64

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Sun, 08 Aug 2004 22:07:25 +0900

>>>>> On Tue, 20 Jul 2004 10:02:36 +0000, 
>>>>> [email-masked] said:

> This issue was discussed in some detail.
> I've done the following:

> - Clarified the prefix length field in 4.6.2
> - Added clarifications to the second last paragraph in 
>    6.3.4.

> Text in 4.6.2:

> Prefix Length  8-bit unsigned integer. The number of leading bits
>                      in the Prefix that are valid.  The value ranges
>                      from 0 to 128. The prefix length field provides
>                      necessary information for on-link determination
>                      (when combined with other flags in the prefix
>                      option).  It also assists with address
>                      autoconfiguration as specified in [ADDRCONF], for
>                      which there may be more restrictions on the prefix
>                      length.

I'm 100% happy with this text.

> Text in 6.3.4: 

>    Stateless address autoconfiguration [ADDRCONF] may in some
>    circumstances increase the Valid Lifetime of a prefix or ignore it
>    completely in order to prevent a particular denial of service attack.
>    However, since the effect of the same denial of service targeted at
>    the on-link prefix list is not catastrophic (hosts would send packets
>    to a default router and receive a redirect rather than sending
>    packets directly to a neighbor) the Neighbor Discovery protocol does
>    not impose such a check on the prefix lifetime values. Similarly,
>    [ADDRCONF] may impose certain restrictions on the prefix length for
>    address configuration purposes. Therefore, the prefix might be
>    rejected by [ADDRCONF] implementation in the host. However, the
>    prefix length is still valid for on-link determination when combined     
>    with other flags in the prefix option.

I'm 99% happy with this text except one minor nit: the phrase of
"other flags" in the last sentence is not very clear.  Perhaps you
mean the "on-link (L) flag", which makes sense to me, and if so, why
not say so explicitly?  That is, I'd suggest to reword the sentence
to:

  However, the
  prefix length is still valid for on-link determination when combined     
  with the on-link flag in the prefix information option.

Hmm...I then noticed another minor nit (which is not directly related
to issue #250): I also used the term "prefix information option"
instead of "prefix option" used in your proposed text.  Since the
official term of this option is "prefix information" option, I think
we should consistently use this term, not "prefix option".  Note that
RFC2461 contains another occurrence of 'prefix option' in Section
4.6.2:

      Prefix         An IP address or a prefix of an IP address.  The
			(...)
                     the receiver.  A router SHOULD NOT send a prefix
                     option for the link-local prefix and a host SHOULD
                     ignore such a prefix option.
                                   ^^^^^^^^^^^^^
I think this should also be "prefix information option".

> Currently there is no text that limits the prefix length
> to 64 if the A flag is set (as recommended by the IAB). 
> I'd like to hear from the WG if this should be added.

Like I did in rfc2462bis, I personally don't think we should add an
explicit note suggested by the IAB.  But this will probably need a
closer discussion.

The IAB's recommendation is as follows:

  specifically note that it is not valid to configure an IPv6 router
  such that the 'autonomous configuration' bit is set to TRUE AND the
  advertised IPv6 prefix length exceeds 64 bits AND the advertised IPv6
  prefix does not start with binary 000
(from
http://www.iab.org/Appeals/kre-ipng-address-arch-draft-standard-response.html)

In this recommendation, I believe we at least don't have to hard-code
binary 000.  We've discussed this on the list for rfc2462bis, and the
consensus there was that we don't have to do this (and hard-coding can
even be harmful).  Also, I've raised this issue for rfc2462bis
explicitly in the ipv6 wg session in San Diego, and saw no objection.
And, actually, Bob (as an individual, not an IAB member:-) seems to
have supported the idea of not hard-coding that particular prefix of
"000".

For a similar reason, I think we don't have to hard-code the
particular prefix length of 64.

So the recommendation would now be:

  specifically note that it is not valid to configure an IPv6 router
  such that the 'autonomous configuration' bit is set to TRUE AND the
  advertised IPv6 prefix length contradicts the value specified in the
  address architecture and link-specific documents (when the value is
  specified in those documents).

I personally do not see the need for making this explicit note.  At
least hosts should ignore such prefix advertisements, so there should
be no visible bad effect.

But the IAB may still want to add this one.  Regarding rfc2462bis, I
asked the IAB if the current approach is okay.  You might want to do
the same thing.

In any case, I don't think this is a show-stopper for a wg last call
or even for IESG evaluation.  I believe we can move forward with what
we think is the best for now.

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

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------