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

Alexandre Petrescu <alexandre.petrescu@gmail.com> Thu, 27 June 2019 06:14 UTC

Return-Path: <alexandre.petrescu@gmail.com>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C7ED1202C1 for <ipv6@ietfa.amsl.com>; Wed, 26 Jun 2019 23:14:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.53
X-Spam-Level:
X-Spam-Status: No, score=-2.53 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mP89XbIecm8w for <ipv6@ietfa.amsl.com>; Wed, 26 Jun 2019 23:13:59 -0700 (PDT)
Received: from sainfoin-smtp-out.extra.cea.fr (sainfoin-smtp-out.extra.cea.fr [132.167.192.228]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DDDFC1200B5 for <ipv6@ietf.org>; Wed, 26 Jun 2019 23:13:58 -0700 (PDT)
Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id x5R6Duol047546 for <ipv6@ietf.org>; Thu, 27 Jun 2019 08:13:56 +0200
Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id B4A4E201BD5 for <ipv6@ietf.org>; Thu, 27 Jun 2019 08:13:56 +0200 (CEST)
Received: from muguet2-smtp-out.intra.cea.fr (muguet2-smtp-out.intra.cea.fr [132.166.192.13]) by pisaure.intra.cea.fr (Postfix) with ESMTP id A5447200BF0 for <ipv6@ietf.org>; Thu, 27 Jun 2019 08:13:56 +0200 (CEST)
Received: from [132.166.86.18] ([132.166.86.18]) by muguet2-sys.intra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id x5R6Dt4U024602 for <ipv6@ietf.org>; Thu, 27 Jun 2019 08:13:55 +0200
Subject: Re: [v6ops] RFC4861 question - short prefixes in PIOs
To: ipv6@ietf.org
References: <729f46ec4a8b419797e15bbdcac3e549@boeing.com> <CAJE_bqeXkyWec9-EG1QxS-1FeTyKS6-ONNOYhQK8gsQGwenaVQ@mail.gmail.com> <2b54c5e1eb54498faa7ec5d07e0f9b3a@boeing.com> <BN6PR21MB04977E999EE62A9929ABE7B7A3E20@BN6PR21MB0497.namprd21.prod.outlook.com> <e5671ed47bd1402e84840c1a266f18dd@boeing.com> <DM5PR21MB0508A10B647C43269C4354D5A3E20@DM5PR21MB0508.namprd21.prod.outlook.com>
From: Alexandre Petrescu <alexandre.petrescu@gmail.com>
Message-ID: <877c15fd-c6f0-e108-f984-54e5101d2f12@gmail.com>
Date: Thu, 27 Jun 2019 08:13:55 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.7.2
MIME-Version: 1.0
In-Reply-To: <DM5PR21MB0508A10B647C43269C4354D5A3E20@DM5PR21MB0508.namprd21.prod.outlook.com>
Content-Type: multipart/alternative; boundary="------------0C362A51CF1E6BAE3374D800"
Content-Language: fr
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/KJGcqjPlOh1mV35wh0ys8TpgCDY>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 27 Jun 2019 06:14:07 -0000

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.

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 
> <mailto:Fred.L.Templin@boeing.com>>; 神明達哉<jinmei@wide.ad.jp 
> <mailto:jinmei@wide.ad.jp>>
> *Cc:* 6man <6man@ietf.org <mailto: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 <mailto:ipv6-bounces@ietf.org>> *On 
> Behalf Of *Templin (US), Fred L
> *Sent:* Wednesday, June 26, 2019 9:52 AM
> *To:* 神明達哉<jinmei@wide.ad.jp <mailto:jinmei@wide.ad.jp>>
> *Cc:* 6man <6man@ietf.org <mailto: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 
> <mailto:Fred.L.Templin@boeing.com>>
> *Cc:* 6man <6man@ietf.org <mailto: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 
> <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.
>
> > 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%7Ca4ed3a82231c4312e3e508d6fa736514%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636971770868375490&sdata=TqUONb7gp99ceqpcgKZXYrSEnBZq8uUPk3FJJIuot8c%3D&reserved=0>
> 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
> --------------------------------------------------------------------