Re: [v6ops] RFC4861 question

On Thu, 27 Jun 2019 at 16:14, Alexandre Petrescu
<alexandre.petrescu@gmail.com> wrote:
>
> With respect to backwards compatibility: some implementations of RIO require PIO to be present too.   That is a problem of forward compatibility, because it does not allow for RIO (the new feature) to be present just itself, it requires the PIO (the old feature).
>
> I would like to ask whether RIO is allowed to exist in itself, without PIO.
>

See RFC 4191. PIOs aren't required, related to, involved in or a
dependency for RIO processing. The implementations you're referring to
sound like they have a bug.

> Alex
>
> Le 26/06/2019 à 23:01, Dave Thaler a écrit :
>
> ➢  Is there some reason to prefer RIOs?
>
>
>
> RFC 4191 says:
>
>    There are several reasons for using a new Route Information Option
>
>    instead of using flag bits to overload the existing Prefix
>
>    Information Option:
>
>
>
>    1. Prefixes will typically only show up in one option, not both, so a
>
>       new option does not introduce duplication.
>
>
>
>    2. The Route Information Option is typically 16 octets while the
>
>       Prefix Information Option is 32 octets.
>
>
>
>    3. Using a new option may improve backwards-compatibility with some
>
>       host implementations.
>
>
>
> Then see all of section 3 of that RFC for the analysis of compatibility.
>
>
>
> Dave
>
>
>
> From: Templin (US), Fred L <Fred.L.Templin@boeing.com>
> Sent: Wednesday, June 26, 2019 1:18 PM
> To: Dave Thaler <dthaler@microsoft.com>; 神明達哉 <jinmei@wide.ad.jp>
> Cc: 6man <6man@ietf.org>
> Subject: RE: [v6ops] RFC4861 question - short prefixes in PIOs
>
>
>
> 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:dthaler@microsoft.com]
> Sent: Wednesday, June 26, 2019 10:40 AM
> To: Templin (US), Fred L <Fred.L.Templin@boeing.com>; 神明達哉 <jinmei@wide.ad.jp>
> Cc: 6man <6man@ietf.org>
> 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 <ipv6-bounces@ietf.org> On Behalf Of Templin (US), Fred L
> Sent: Wednesday, June 26, 2019 9:52 AM
> To: 神明達哉 <jinmei@wide.ad.jp>
> Cc: 6man <6man@ietf.org>
> 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:jinmei@wide.ad.jp]
> Sent: Wednesday, June 26, 2019 9:23 AM
> To: Templin (US), Fred L <Fred.L.Templin@boeing.com>
> Cc: 6man <6man@ietf.org>
> 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" <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.
>
> > 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
> I believe it clarifies many of the above questions.
>
> --
> JINMEI, Tatuya
>
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------