Re: draft-bourbaki-6man-classless-ipv6-00

Alexandre Petrescu <alexandre.petrescu@gmail.com> Tue, 13 June 2017 11:40 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 D6128126C0F for <ipv6@ietfa.amsl.com>; Tue, 13 Jun 2017 04:40:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.332
X-Spam-Level:
X-Spam-Status: No, score=-0.332 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_SOFTFAIL=0.665, 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 tS5iCIOpZS6n for <ipv6@ietfa.amsl.com>; Tue, 13 Jun 2017 04:40:39 -0700 (PDT)
Received: from oxalide-smtp-out.extra.cea.fr (oxalide-smtp-out.extra.cea.fr [132.168.224.13]) (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 DE9201294E1 for <ipv6@ietf.org>; Tue, 13 Jun 2017 04:40:38 -0700 (PDT)
Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id v5DBebPT134174 for <ipv6@ietf.org>; Tue, 13 Jun 2017 13:40:37 +0200
Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 43850202EBF for <ipv6@ietf.org>; Tue, 13 Jun 2017 13:40:36 +0200 (CEST)
Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 05C392054F5 for <ipv6@ietf.org>; Tue, 13 Jun 2017 13:40:35 +0200 (CEST)
Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet2.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id v5DBeZiJ013541 for <ipv6@ietf.org>; Tue, 13 Jun 2017 13:40:35 +0200
Subject: Re: draft-bourbaki-6man-classless-ipv6-00
To: ipv6@ietf.org
References: <20170602141112.x64nleqclygz7dwd@Vurt.local> <CAD6AjGTjikAWutcenW8qn7OW8kPM9c_x_yDUy5vQxJmXKL85dg@mail.gmail.com> <91c3c0f4-eb8b-cdf7-b9c9-7d1eecb7fe64@gmail.com> <CAKD1Yr0_WR_TB+OC0U1Qt2h6WzUp9EGvrqC1ZKW2mwFeBd3bCQ@mail.gmail.com> <4021a559-5b6d-b3fb-19cd-afbe9041e8f2@gmail.com> <34A29D4D-3670-40BC-B62E-85C4EABC55D5@employees.org> <6e03e25e-fd6a-6311-390e-4834281a76f7@si6networks.com> <1B580CBB-B29D-4860-9EC8-BECD1D5E0006@employees.org> <4b2f5200-86a1-7711-e5ff-7436572be467@gmail.com> <E02C4C99-155A-4358-A845-F00F8BB071C1@employees.org> <b3ca5271-21b1-ab33-2dff-82735ebe9128@gmail.com> <235143da452c4ff4aec39a26ba918e7e@XCH15-06-11.nw.nos.boeing.com> <1489a50a-2616-f9ac-4109-16c595e15f90@gmail.com> <FA3032F9-F44B-45B4-9AFF-01EBC84F1448@employees.org> <b1c5c13d-ef69-ef30-546c-9178a2655caf@si6networks.com> <391c730c-fa75-7596-bb6b-383ea6583131@gmail.com> <f2ac9e0a467b4015a0a78d549c0fbbf0@XCH15-06-11.nw.nos.boeing.com> <9b259cb2-3d31-78bf-608c-aacf5fdb8101@nlogic.no>
From: Alexandre Petrescu <alexandre.petrescu@gmail.com>
Message-ID: <aa72c754-1058-df0d-03cc-0bf158d49a90@gmail.com>
Date: Tue, 13 Jun 2017 13:40:35 +0200
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1
MIME-Version: 1.0
In-Reply-To: <9b259cb2-3d31-78bf-608c-aacf5fdb8101@nlogic.no>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: fr
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/6sZ__NNk3i05Mqsov8Nff5vF8uI>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
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: Tue, 13 Jun 2017 11:40:41 -0000


Le 13/06/2017 à 09:51, Ola Thoresen a écrit :
> On 13. juni 2017 04:22, Manfredi, Albert E wrote:
> 
>> Why so, Brian? I've already described one easy technique: the host 
>> can create IIDs of any length, based on an algorithm that we might 
>> just be debating for a long time, but fundamentally can be quite 
>> straightforward. And then the host chooses the correct IID to use 
>> for SLAAC, based on the RA it just received.
> 
> 
> Some people argue in the DNS "tussle" that it might be a problem if 
> the host receives different DNS-info from eg. RAs and DHCP. And now 
> we are discussing if the host should create its LL prefix length 
> based on a variable in the RAs?
> 
> What if multiple routers in a network announces different prefix 
> lengths? This would cause MUCH greater problems

Please identify such a problem.

In my setting, I could put a /64 and a /65 PIOs in a same RA.

The kernel of the existing Host would self-configure an address out of
that /64 and ignore the /65.  The software-to-be-written in userspace
would consider only  the /65 and form a second address.

What do you think breaks in this casE?

> than just getting an invalid DNS-server and would require much more 
> work for the operators to keep consistent throughout a complex 
> network.
> 
> I can foresee scenarios here, where one router is deployed and 
> announcing prefix-lengths of /80 for its public prefix.  Then
> another router is added do the mix, that does not have the
> flexibility to change the prefix-length, so it will always use /64.

What breaks in this case?  Who complains?  I think the existing Host
simply ignores the /65.

> Then the operator would either have to renumber the first prefix to 
> /64 as well, or you would be stuck with two different prefixes 
> announced in the RAs, and the host constantly regenerating its LL.

But the LLs have a prefix and plen that is distinct from the PIOs.  It
is fe80::/10.

> Or you would be forever forced to always use the longest prefix for 
> all subnets,

No.  Let's make that into a requirement: the longet-prefix applies for
forwarding but MUST NOT apply for address auto-configuration.

> so as soon as I have deployed 2001:db8:1234:5678:9abc::/80 from one
> ISP, I can never use anything but a /80 on that link no matter what
> prefix size another ISP might give me.

Right above.

Alex

> 
> 
> Rgds.
> 
> Ola (T)
> 
> --------------------------------------------------------------------
>  IETF IPv6 working group mailing list ipv6@ietf.org Administrative 
> Requests: https://www.ietf.org/mailman/listinfo/ipv6 
> --------------------------------------------------------------------
>