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

Ola Thoresen <ola@nlogic.no> Tue, 13 June 2017 07:51 UTC

Return-Path: <ola@nlogic.no>
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 7F08F128CD5 for <ipv6@ietfa.amsl.com>; Tue, 13 Jun 2017 00:51:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.121
X-Spam-Level:
X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_NEUTRAL=0.779] 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 nhjxZfolxs-d for <ipv6@ietfa.amsl.com>; Tue, 13 Jun 2017 00:51:08 -0700 (PDT)
Received: from smtp12.doorway.no (smtp12.doorway.no [212.125.205.195]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3AD431289C3 for <ipv6@ietf.org>; Tue, 13 Jun 2017 00:51:07 -0700 (PDT)
Received: from dware1044.doorway.loc (10.0.20.54) by smtp12.doorway.no (10.0.21.42) with Microsoft SMTP Server (TLS) id 15.0.1236.3; Tue, 13 Jun 2017 09:51:01 +0200
Received: from olen.dhcp.nlogic.no (213.52.81.38) by dware1044.doorway.loc (10.0.20.54) with Microsoft SMTP Server (TLS) id 15.0.1236.3; Tue, 13 Jun 2017 09:50:59 +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>
From: Ola Thoresen <ola@nlogic.no>
Message-ID: <9b259cb2-3d31-78bf-608c-aacf5fdb8101@nlogic.no>
Date: Tue, 13 Jun 2017 09:51:04 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0
MIME-Version: 1.0
In-Reply-To: <f2ac9e0a467b4015a0a78d549c0fbbf0@XCH15-06-11.nw.nos.boeing.com>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Originating-IP: [213.52.81.38]
X-ClientProxiedBy: DWARE1041.doorway.loc (10.0.20.51) To dware1044.doorway.loc (10.0.20.54)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/otJ5207xNqhKqvCSIMLZe-L-4NU>
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 07:51:10 -0000

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 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. 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.
Or you would be forever forced to always use the longest prefix for all 
subnets, 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.


Rgds.

Ola (T)