RE: [v6ops] RFC4861 question

Thanks for your response, David:

>> RFC 8028 updates RFC4861 and talks about A=L=0, it talks about this in Section 2.1;

That does indeed look like the kind of behavior I am after, but how is it different than
RFC4191 RIOs? RIOs include a Preference value for each router that advertises the
prefix. Do we lose that feature by going with PIOs per RFC8028?

Thanks - Fred

From: David Farmer [mailto:farmer@umn.edu]
Sent: Wednesday, June 26, 2019 12:01 PM
To: 神明達哉 <jinmei@wide.ad.jp>
Cc: Templin (US), Fred L <Fred.L.Templin@boeing.com>; 6man <6man@ietf.org>
Subject: Re: [v6ops] RFC4861 question - short prefixes in PIOs

Some additional comments regarding questions #3 and #4 are below;

On Wed, Jun 26, 2019 at 11:23 AM 神明達哉 <jinmei@wide.ad.jp<mailto:jinmei@wide.ad.jp>> wrote:
(I'm only copying 6man, as I believe it's purely a protocol spec
question)

At Wed, 26 Jun 2019 15:56:36 +0000,
"Templin (US), Fred L" <Fred.L.Templin@boeing.com<mailto:Fred.L.Templin@boeing..com>> wrote:
>
> I have an RFC4861 question (several actually) on short prefixes in RA PIOs:
>
> 1) If a PIO includes a prefix with length less than 64 (e.g., 2001:db8::/32) and with L=1, does it
>
> mean that 2001:db8::/32 should be added to the interface prefix list?

In my interpretation (ditto for subsequent questions), yes.

+1

> 2) If yes to 1), does it mean that packets forwarded to the interface for any destination covered
>
> by 2001:db8::/32 will trigger Address Resolution instead of forwarding to a default router?

Yes.

+1

> 3) If the PIO instead has L=0, does it mean that 2001:db8::/32 is “associated” with the link but
> not necessarily “on-link”?

I'm not sure how to interpret it (in particular I'm not sure what
"associated with the link" means), but my interpretation of L=0 is
that the RA doesn't say anything about the on-link-ness of that
prefix.  See also the description of the L flag in RFC4861:

      L              1-bit on-link flag.  [...]  When
                     not set the advertisement makes no statement about
                     on-link or off-link properties of the prefix.  In
                     other words, if the L flag is not set a host MUST
                     NOT conclude that an address derived from the
                     prefix is off-link.  That is, it MUST NOT update a
                     previous indication that the address is on-link.

RFC 8028 updates RFC4861 and talks about A=L=0, it talks about this in Section 2.1;

   In some circumstances, both L and A might be zero.  If SLAAC is not
   wanted (A=0) and there is no reason to announce an on-link prefix
   (L=0), a PIO SHOULD be sent to inform hosts that they should use the
   router in question as the first hop for packets with source addresses
   in the PIO prefix.  An example case is the MIF router in Figure 1,
   which could send PIOs with A=L=0 for the common prefix.  Although
    this does not violate the existing standard [RFC4861], such a PIO has
   not previously been common, and it is possible that existing host
   implementations simply ignore such a PIO or that existing router
   implementations are not capable of sending such a PIO.  Newer
   implementations that support this mechanism should be updated
   accordingly:

   o  A host SHOULD NOT ignore a PIO simply because both L and A flags
      are cleared (extending Section 6.3.4 of [RFC4861]).

   o  A router SHOULD be able to send such a PIO (extending
      Section 6.2.3 of [RFC4861]).

> 4) If yes to 3), does it mean that 2001:db8::/32 should be added to the IPv6 forwarding table
>
> as a “route-to-interface” with the receiving interface as the next hop?

No.  See the second MUST NOT of the RFC4861 text cited above.

I wouldn't call it a “route-to-interface” it should be a route pointing to the route as the next-hop.

> 5) Does A=1 have any meaning for prefixes with length less than 64? Or, must prefixes with
>
> length less than 64 set A=0?

As far as RFC4861 is concerned, the A flag has no meaning, regardless
of the prefix length.  It only matters in RFC4862.  In terms of
RFC4862, whether "A=1 has any meaning for prefixes with length less
than 64" depends on the length of the IID of the link; if the prefix
length != 128-IIDLength, the validation rule 5.5.3 d) of RFC4862 makes
the prefix ignored.  If non-64 prefix length is invalid in terms of
RFC4862 in that sense, it'd be *safe* to avoid setting the A flag, but
the protocol specification doesn't say it *must* be so.

+1

You may also want to check
https://tools.ietf.org/html/draft-jinmei-6man-prefix-clarify-00
I believe it clarifies many of the above questions.

--
JINMEI, Tatuya
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org<mailto:ipv6@ietf.org>
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

--
===============================================
David Farmer               Email:farmer@umn.edu<mailto:Email%3Afarmer@umn.edu>
Networking & Telecommunication Services
Office of Information Technology
University of Minnesota
2218 University Ave SE        Phone: 612-626-0815
Minneapolis, MN 55414-3029   Cell: 612-812-9952
===============================================

RE: [v6ops] RFC4861 question - short prefixes in PIOs