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 > --------------------------------------------------------------------
- RFC4861 question - short prefixes in PIOs Templin (US), Fred L
- Re: [v6ops] RFC4861 question - short prefixes in … 神明達哉
- RE: [v6ops] RFC4861 question - short prefixes in … Templin (US), Fred L
- RE: [v6ops] RFC4861 question - short prefixes in … Dave Thaler
- Re: [v6ops] RFC4861 question - short prefixes in … David Farmer
- RE: [v6ops] RFC4861 question - short prefixes in … Templin (US), Fred L
- RE: [v6ops] RFC4861 question - short prefixes in … Templin (US), Fred L
- RE: [v6ops] RFC4861 question - short prefixes in … Dave Thaler
- Re: [v6ops] RFC4861 question - short prefixes in … David Farmer
- Re: [v6ops] RFC4861 question - short prefixes in … Brian E Carpenter
- Re: [v6ops] RFC4861 question - short prefixes in … Mark Smith
- Re: [v6ops] RFC4861 question - short prefixes in … Alexandre Petrescu
- Re: [v6ops] RFC4861 question - short prefixes in … Mark Smith
- Re: RFC4861 question - short prefixes in PIOs Michael Richardson
- Re: RFC4861 question - short prefixes in PIOs Mark Smith
- Re: [v6ops] RFC4861 question - short prefixes in … Alexandre Petrescu
- Re: [v6ops] RFC4861 question - short prefixes in … Philip Homburg
- Re: [v6ops] RFC4861 question - short prefixes in … Mark Smith
- Re: [v6ops] RFC4861 question - short prefixes in … Pascal Thubert (pthubert)