[rfc2462bis issue 281] "64-bit assumption" and prefix length

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

One more question about the prefix (and IFID) length.

Since the IFID length is defined in the link specific document (which
must be consistent with addr-arch, based on discussions so far) and
the prefix length is 128 - IFID_length by definition, the appropriate
prefix length must implicitly given by the link specific document.

The implementors may wonder why the RA bothers to specify the prefix
length in its prefix information option.

Recall that we have had a similar discussion in the context of 2461bis:
https://www1.ietf.org/mail-archive/working-groups/ipv6/current/msg01600.html

My conclusion to this point including the one in the 2461bis context
is as follows:

  The prefix length in the prefix information option has non trivial
  meaning for specifying an on-link prefix with the L flag.  For this
  purpose, the length can be shorter (or perhaps even longer) than
  "128 - IFID_length".  For example, if the following four prefixes
  should be regarded as "on-link":
    2001:db8:0:00::/64,
    2001:db8:0:01::/64,
    2001:db8:0:10::/64,
    2001:db8:0:11::/64
  then the administrator may want to advertise the set of the prefixes
  as "on-link" by sending a single aggregated prefix
  "2001:db8::/62" with the L flag being set, instead of sending the
  four prefixes separately.

So, my answer to Hesham's question (see the message available at the
above URL), what we should do is:

  just accept any lengths of prefixes in terms of the "on-link"
  processing.   We may or may not want to add an explicit note that
  the "prefix length + IFID_length" may not be equal to 128 but it's
  okay for the on-link determination.

For rfc2462bis, I'd add a note to bullet d) of Section 5.5.3:

       If the sum of the prefix length and interface identifier length
       does not equal 128 bits, the Prefix Information option MUST be
       ignored.

like this:

	Note that the appropriate prefix length should be determined
	by the interface identifier length and in that sense the
	advertised prefix length is meaningless information.  However,
	the advertised prefix length has non trivial meaning for
	on-link determination in Neighbor Discovery where the sume of
	the prefix length and the interface identifier length may not
	be equal to 128.  Thus, it should be safe to validate the
	advertised prefix length here, in order to detect and avoid
	a configuration error specifying an invalid prefix length in
	the context of address autoconfiguration.

Comments?

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

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