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

Ola Thoresen <ola@nlogic.no> Tue, 13 June 2017 13:58 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 C781612EAE2 for <ipv6@ietfa.amsl.com>; Tue, 13 Jun 2017 06:58:00 -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 m25PY9WRd5a9 for <ipv6@ietfa.amsl.com>; Tue, 13 Jun 2017 06:57:58 -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 7284C1242F7 for <ipv6@ietf.org>; Tue, 13 Jun 2017 06:57:56 -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 15:57:47 +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 15:57:45 +0200
Subject: Re: draft-bourbaki-6man-classless-ipv6-00
To: ipv6@ietf.org
References: <20170602141112.x64nleqclygz7dwd@Vurt.local> <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> <aa72c754-1058-df0d-03cc-0bf158d49a90@gmail.com>
From: Ola Thoresen <ola@nlogic.no>
Message-ID: <4b16e46a-a5b8-699f-9df7-a76476d06a34@nlogic.no>
Date: Tue, 13 Jun 2017 15:57:50 +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: <aa72c754-1058-df0d-03cc-0bf158d49a90@gmail.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 8bit
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/aM-RNrxCzF_YvZB3mJ2ZXmTPcrY>
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 13:58:01 -0000

On 13. juni 2017 13:40, Alexandre Petrescu wrote:

>
>
> 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?
>


I am not talking about that. I am talking about the idea of deducing the 
prefix length for _Link_Local_ addresses from the RAs.
If the link local address is randomly generated, which is the case in 
major OSes today, there is no way to ensure that the LL you created for 
one > /64 prefix matches the LL of a second router which also announces 
a prefix > /64 on the same link.
Link local needs to be /64 to ensure that you can reach all possible 
routers on the link - unless you are going to add multiple LL addresses 
to an interface as well.
But then we are suddenly facing other potential issues, so I a not sure 
that is a path we want to go...



>> 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.
>

What /65?

The user complains, because the LL-address generated after receiving a 
RA from router B might make router A unavailable.

1) Router A announces a /80
2) Host generates an LL: fe80::AAAA:1234:abcd:4321/80
3) Router B announces a /64
4) Host generates an LL: fe80::B000:1234:abcd:4321/64 to match the 
prefix length of the new RA

Since that /64 does not match the /80 from router A, router A is no 
longer able to talk to the Link Local address of the Host.

But just for arguments sake.  Let the Host keep the address, but just 
change the prefix length...

4) Host changes its LL-prefix length to: fe80::AAAA:1234:abcd:4321/64 to 
match the prefix length of the new RA

Then router C comes along and also wants to play, but using the prefix 
fe80::CCCC:0:0:0/80 for its link local network.
Now, router A and C can not talk to each other, and the host can not 
talk to router C

Or even worse

Router D is added, with a /60 prefix length: fe80:0:0:D0::/60 - Now, the 
Host MUST change its prefix to talk to the new router, but that will 
make all the other routers unavailable.

In a dynamic network, with more than one router, you simply must have 
the same prefix length for all link local addresses, and just keeping it 
a /64 is much easier than trying to create a new algorithm to solve all 
potential pitfalls of using different prefix lengths for Link Local.


Rgds.

Ola Thoresen