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

["Templin (US), Fred L" <[e-mail]>]

Hi Dave,

I agree that what I want is more akin to RIO than to “traditional” PIO, but then I saw
David Farmer’s note about RFC8028 and that seems to be more in line with what I am
looking for.

Certainly, multi-homing needs to be accommodated and RFC8028 seems to support
that while using the ubiquitous standard PIO albeit with A=L=0. Is there some reason
to prefer RIOs?

Thanks - Fred

From: Dave Thaler [mailto:[e-mail]]
Sent: Wednesday, June 26, 2019 10:40 AM
To: Templin (US), Fred L <[e-mail]>; 神明達哉 <[e-mail]>
Cc: 6man <[e-mail]>
Subject: RE: [v6ops] RFC4861 question - short prefixes in PIOs

RIO should add a route with the next hop of the router, where the prefix is not an on-link prefix.
PIO should be for on-link prefixes, i.e., either the receiver should create a SLAAC address or the receiver should add an on-link route, or both.

Dave

From: ipv6 <[e-mail]<mailto:[e-mail]>> On Behalf Of Templin (US), Fred L
Sent: Wednesday, June 26, 2019 9:52 AM
To: 神明達哉 <[e-mail]<mailto:[e-mail]>>
Cc: 6man <[e-mail]<mailto:[e-mail]>>
Subject: RE: [v6ops] RFC4861 question - short prefixes in PIOs

OK, thanks. Then, it seems to me that what I really want is a Route Information Option
(RIO) [RFC4191] because what I am looking for is a way to establish a short prefix in the
IPv6 forwarding table that directs packets to a specific outgoing interface (or, more
precisely, to a specific router on a specific outgoing interface).

But, with RIO, the prefix would not be added to the interface prefix list in the same
way as for PIO - correct?

Thanks - Fred


From: 神明達哉 [mailto:[e-mail]]
Sent: Wednesday, June 26, 2019 9:23 AM
To: Templin (US), Fred L <[e-mail]<mailto:[e-mail]>>
Cc: 6man <[e-mail]<mailto:[e-mail]>>
Subject: Re: [v6ops] RFC4861 question - short prefixes in PIOs

(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" <[e-mail]<mailto:[e-mail]>> 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.

> 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.

> 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.

> 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.

> 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.

You may also want to check
https://tools.ietf.org/html/draft-jinmei-6man-prefix-clarify-00<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-jinmei-6man-prefix-clarify-00&data=02%7C01%7Cdthaler%40microsoft.com%7C8553bcb309874f844e9408d6fa56b303%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636971647627136134&sdata=AQ8dP3HU4UonvrTkx5TMKYxgS%2FI%2BAxkImKLi%2B9M8aBk%3D&reserved=0>
I believe it clarifies many of the above questions.

--
JINMEI, Tatuya