Re: Proposal to further clarify prefix length issues in I-D.ietf-6man-rfc4291bis
Alexandre Petrescu <alexandre.petrescu@gmail.com> Sat, 11 March 2017 16:49 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 57F0A129541 for <ipv6@ietfa.amsl.com>; Sat, 11 Mar 2017 08:49:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 2.175
X-Spam-Level: **
X-Spam-Status: No, score=2.175 tagged_above=-999 required=5 tests=[DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=1.2, SPF_SOFTFAIL=0.972, URIBL_BLOCKED=0.001] autolearn=no 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 0n3tgwYGLl7I for <ipv6@ietfa.amsl.com>; Sat, 11 Mar 2017 08:49:39 -0800 (PST)
Received: from cirse-smtp-out.extra.cea.fr (cirse-smtp-out.extra.cea.fr [132.167.192.148]) (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 BDB8412953F for <ipv6@ietf.org>; Sat, 11 Mar 2017 08:49:38 -0800 (PST)
Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id v2BGnaA2009377 for <ipv6@ietf.org>; Sat, 11 Mar 2017 17:49:36 +0100
Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id B6395207AF2 for <ipv6@ietf.org>; Sat, 11 Mar 2017 17:49:36 +0100 (CET)
Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id AC44C207704 for <ipv6@ietf.org>; Sat, 11 Mar 2017 17:49:36 +0100 (CET)
Received: from [132.166.84.23] ([132.166.84.23]) by muguet2.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id v2BGnZWG013303 for <ipv6@ietf.org>; Sat, 11 Mar 2017 17:49:36 +0100
Subject: Re: Proposal to further clarify prefix length issues in I-D.ietf-6man-rfc4291bis
To: ipv6@ietf.org
References: <m1clw44-0000I4C@stereo.hq.phicoh.net> <904F4D77-1266-4A05-B0ED-D211E38FFC0F@google.com> <m1cm2pI-0000FsC@stereo.hq.phicoh.net> <CAJE_bqfo9Mje=wgfUW+V1Q5eHwEwpA164R+kHyjrWgD51H_uKg@mail.gmail.com> <DB582F48-22FD-4240-9B78-ECF60FCA68D2@employees.org>
From: Alexandre Petrescu <alexandre.petrescu@gmail.com>
Message-ID: <4bff6311-1b9b-a861-bb11-b8a5b4d44cb8@gmail.com>
Date: Sat, 11 Mar 2017 17:49:32 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1
MIME-Version: 1.0
In-Reply-To: <DB582F48-22FD-4240-9B78-ECF60FCA68D2@employees.org>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/43NLvHtLQSi3YyRj9j7ul-aY0TQ>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.17
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: Sat, 11 Mar 2017 16:49:40 -0000
Le 11/03/2017 à 09:57, otroan@employees.org a écrit : > Jinmei, > > Is there anything here that isn't covered by 5942? > > And creating an artificial separation of prefixes used for address > assignment (SLAAC) and prefixes used for on-link determination seems > fraught with dangers. E.g. from a router perspective you need a > connected route aka an onlink prefix for the prefix used for address > assignment, otherwise you have no reachability. Further, I disagree that a distinction between on-link prefix and SLAAC prefix favors continuation of the 64bit IID, and of the 64bit limit for that matter. A situation can be created where a SLAAC prefix is /64 and a distinct on-link prefix is of plen /65 on that same link. But this situation is not desirable. Because a Host that configures itself an address within the /64 may in some cases not be visible to the ND of another Host on that same link; that other Host used on-link determination with a /65 to find out whether it is on link or not. This problem of visibility is very clear especially if a default router is absent on that link (subnets isolated from the Internet). If a default router is present, then this visibility problem may not be that obvious. This is why the distinction between the plens of an on-link prefix and of a SLAAC prefix on same link is not something good. These two plens should be the same. And when they are the same (the prefix for on-link determination, and the prefix for SLAAC), they must have the same plen. And that plen can be anything from 1 to 128. Finally, yes, it is possible to have multiple prefixes on same link. But these prefixes should be paired: on-link prefix1 and SLAAC prefix1, onlink prefix2 and SLAAC prefix2, and so on. Alex > > O. > >> On 9 Mar 2017, at 22:11, 神明達哉 <jinmei@wide.ad.jp> wrote: >> >> At Thu, 09 Mar 2017 19:30:11 +0100, Philip Homburg >> <pch-ipv6-ietf-3@u-1.phicoh.com> wrote: >> >>> If your use of the term 'subnet prefix' only refers to >>> (stateless) address configuration and not to being onlink or >>> not, then I agree about the concept (but not the term). >>> >>> However, where IPv6 clearly separates address configuration from >>> being onlink, calling a prefix that is only used for (stateless) >>> address configuration 'a subnet prefix' is very confusing. >>> >>> At the same time, calling some onlink prefixes 'subnet prefixes' >>> and others 'other unicast routing prefixes' is also very >>> confusing if they are announced using the same L flag in a PIO >>> option in a router advertisement. I.e, whether or not the A flag >>> is set in PIO option, should not have an effect on what we call >>> an onlink prefix. Or on how we describe onlink prefixes and what >>> their properties are. >> [...] >>> So if we want to say that prefixes used for stateless address >>> configuration MUST/SHOULD be 64 bits long, whereas onlink >>> prefixes can be of any length, then we should at least use clear >>> terminology that separates prefixes for stateless address >>> configuration from other uses. >> >> +1. I've also been feeling that one source of seeming confusion in >> this discussion may be confusion between "subnet prefixes" and >> prefixes for on-link determination as described in RFC4861. In >> fact, the latter (I'll use the term "onlink prefix" in this >> message) has nothing to do with "subnet prefixes" - it simply >> specifies a set of addresses that should be supposed to be on-link >> for the corresponding link. Whether or not we adopt >> "conservative" or "liberal" view of the length of IIDs or "subnet >> prefix" in the context of addressing architecture, an onlink prefix >> can be longer or shorter than a subnet prefix even if these two >> share some leading bits. >> >> So, for example: - if we adopt the "conservative" address >> architecture, The subnet prefix for 2001:db8:1:2:3:4:5:6 must be >> 2001:db8:1:2::/64. - if we adopt the "liberal" address >> architecture, The subnet prefix for 2001:db8:1:2:3:4:5:6 can be >> 2001::/16, 2001:db8::/32, 2001:db8:1::/48, 2001:db8:1:2::/64, >> ...2001:db8:1:2:3:4:5:0/120, etc. and, in either case, - onlink >> prefx in this link advertised via an RA with L=1 can be 2001::/16, >> 2001:db8::/32, 2001:db8:1::/48, ...2001:db8:1:2:3:4:5:0/120, etc. >> >> In particular, the fact that onlink prefix can be of any length >> doesn't mean it violates the conservative address architecture. >> >> Perhaps one source of confusion is the fact or expectation that RA >> PIO often both sets A and L bits on. So, in the above example, if >> we have a PIO for 2001:db8:1::/48 or 2001:db8:1:2:3:4:5:0/120 with >> both L and A bits on, these are valid on link prefix. But they >> can't be used for SLAAC (assuming its link-layer spec specifies >> the consistent IID length with the "conservative" address >> architecture, i.e., 64). That is, for the same PIO, - if we >> consider it as on-link prefix, it can coexist with any of the >> address architecture - if we consider it for SLAAC, it can only >> coexist with the conservative architecture, or liberal one with an >> exception of requiring 64-bit subnet prefix length specifically >> for SLAAC >> >> BTW while writing this message I saw a warning from Brian: >> >>>> Isn't it time we all shut up and wait for the document editor >>>> to propose text? >> >> I don't want to contribute to making this thread even longer, so I >> promise I'll stop here. But I wanted to make this one remark >> since I believe it's important to clarify that ("on-link prefix" is >> irrelevant to the address architecture discussion) and I see why >> this can be so confusing. Even if this attempt of mine fails, >> I'll shut up now (maybe I should write a separate draft just >> focusing on this particular confusion). >> >> -- 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 > -------------------------------------------------------------------- >
- Proposal to further clarify prefix length issues … james woodyatt
- Re: Proposal to further clarify prefix length iss… Philip Homburg
- Re: Proposal to further clarify prefix length iss… Alexandre Petrescu
- Re: Proposal to further clarify prefix length iss… David Farmer
- Re: Proposal to further clarify prefix length iss… james woodyatt
- Re: Proposal to further clarify prefix length iss… james woodyatt
- Re: Proposal to further clarify prefix length iss… Philip Homburg
- Re: Proposal to further clarify prefix length iss… Brian E Carpenter
- RE: Proposal to further clarify prefix length iss… Manfredi, Albert E
- Re: Proposal to further clarify prefix length iss… james woodyatt
- Re: Proposal to further clarify prefix length iss… james woodyatt
- Re: Proposal to further clarify prefix length iss… Fred Baker
- Re: Proposal to further clarify prefix length iss… sthaug
- Re: Proposal to further clarify prefix length iss… 神明達哉
- Re: Proposal to further clarify prefix length iss… Suresh Krishnan
- Re: Proposal to further clarify prefix length iss… otroan
- Re: Proposal to further clarify prefix length iss… Philip Homburg
- Re: Proposal to further clarify prefix length iss… Mark Smith
- Re: Proposal to further clarify prefix length iss… Philip Homburg
- Re: Proposal to further clarify prefix length iss… Mark Smith
- Re: Proposal to further clarify prefix length iss… Alexandre Petrescu
- Re: Proposal to further clarify prefix length iss… Alexandre Petrescu