Re: [homenet] homenet-prefix-assignment update - prefix length 64 and on prefix comparison

Pierre Pfister <pierre.pfister@darou.fr> Thu, 09 October 2014 11:45 UTC

Return-Path: <SRS0=7cAE=7A=darou.fr=pierre.pfister@bounces.m4x.org>
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0A591A028A for <homenet@ietfa.amsl.com>; Thu, 9 Oct 2014 04:45:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.202
X-Spam-Level:
X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
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 bkK2iIvpW3dx for <homenet@ietfa.amsl.com>; Thu, 9 Oct 2014 04:45:00 -0700 (PDT)
Received: from mx1.polytechnique.org (mx1.polytechnique.org [129.104.30.34]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 500681ACDA4 for <homenet@ietf.org>; Thu, 9 Oct 2014 04:45:00 -0700 (PDT)
Received: from [10.61.199.17] (173-38-208-170.cisco.com [173.38.208.170]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ssl.polytechnique.org (Postfix) with ESMTPSA id DD22C1408EEE1; Thu, 9 Oct 2014 13:44:56 +0200 (CEST)
Content-Type: text/plain; charset="windows-1252"
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Pierre Pfister <pierre.pfister@darou.fr>
In-Reply-To: <0D6BC65B-CD29-4C90-8787-365C79542DDC@employees.org>
Date: Thu, 09 Oct 2014 13:45:02 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <AB96CBAA-F11D-4504-80DA-6ED480664C9D@darou.fr>
References: <A0C73AEC-6D0F-498B-9BDD-D6AF91202CCB@darou.fr> <54350D62.5050706@gmail.com> <048F40EB-A1D5-4D70-986B-9DDE55FF7C22@darou.fr> <FAFE72E2-04EC-4B27-BE1F-6E2F9F7F7A1C@employees.org> <37213B35-CAE1-4AF7-B94D-2B5EAD1C4A39@darou.fr> <5308B561-200A-455C-B2E9-4B4824ED2A1D@ecs.soton.ac.uk> <EMEW3|2f5d8f14bb6cf818659db375e4a75ba0q97FLf03tjc|ecs.soton.ac.uk|5308B561-200A-455C-B2E9-4B4824ED2A1D@ecs.soton.ac.uk> <5435D845.9030108@gmail.com> <AE46801C-D3EA-436A-9894-CCF9B9E46A5D@townsley.net> <A50A4BEF-B267-4BFF-8DDE-297D03A16DBC@darou.fr> <0D6BC65B-CD29-4C90-8787-365C79542DDC@employees.org>
To: Ole Troan <otroan@employees.org>
X-Mailer: Apple Mail (2.1878.6)
X-AV-Checked: ClamAV using ClamSMTP at svoboda.polytechnique.org (Thu Oct 9 13:44:58 2014 +0200 (CEST))
Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/oF-G19hOgG9mZz3let9NVjxjACc
Cc: Tim Chown <tjc@ecs.soton.ac.uk>, Mark Townsley <mark@townsley.net>, "homenet@ietf.org" <homenet@ietf.org>, Alexandru Petrescu <alexandru.petrescu@gmail.com>
Subject: Re: [homenet] homenet-prefix-assignment update - prefix length 64 and on prefix comparison
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: <homenet.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/homenet>, <mailto:homenet-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/homenet/>
List-Post: <mailto:homenet@ietf.org>
List-Help: <mailto:homenet-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/homenet>, <mailto:homenet-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 09 Oct 2014 11:45:07 -0000

Reply inline


Le 9 oct. 2014 à 13:03, Ole Troan <otroan@employees.org> a écrit :

> Pierre,
> 
> I certainly understand your argument, and we don't disagree on the technical merit.
> 
>> I’m proposing this change then.
>> 
>> 1. In case the provided prefix is 64, the default consist in assigning prefixes of length 64 first.
>> 2. I’m adding a reference to 6man-why64.
>> 
>> When the algorithm decides to make a new assignment, it first needs
>>   to specify the desired size of the assigned prefix.  Although this
>>   algorithm intends to remain generic, it was observed in
>>   [I-D.ietf-6man-why64] that hosts may malfunction when the prefix
>>   length is not 64.  Therefore, prefixes of length 64 are RECOMMENDED.
>>   The following table MAY be used as default values, where X is the
>>   length of the delegated prefix.
>> 
>>   If X <= 64:  Prefix length = 64
> 
> the "may malfunction" is not the reason for why the IPv6 address is classful, so please don't put that as justification for a default of 64.

I’ll change that into something more generic like: « Because of all the reasons listed in [I-D.ietf-6man-why64], prefixes of length 64 are RECOMMENDED. ». 

> 
> I would like this document to say as little as possible about the boundary.
> RFC6204 says:
> L-2:   The IPv6 CE router MUST assign a separate /64 from its
>          delegated prefix(es) (and ULA prefix if configured to provide
>          ULA addressing) for each of its LAN interfaces.
> 
> which you could tweak to fit this document as well. have text like that in one place, and then all other places threat it as an arbitrary length.
> 
> please remove the table with the description of what to do for various values of X.

The algorithm treats IPv4 and IPv6 the same way, as well as any prefix lengths. 
That table is important for IPv4 support.

> I'd be happy with a statement like in RFC6204:
>   WPD-3:  ...If the
>           delegated prefix is too small to address all of its
>           interfaces, the IPv6 CE router SHOULD log a system management
>           error.
> 
>> Processes proposed in the appendix are optional.
>> Our implementation supports some part of it, and it works fine in our test-cases.
>> I’d rather have a /80 than no connectivity at all (And it just works.).
>> IMO, why64 is way too pessimistic on the current implementation state and even more when it comes to the progress implementations will do in the coming years.
>> 
>> And we either do that or let people do NAT66. ;)
>> 
>> 
>> Is it OK for you Ole ?
> 
> I'd also remove the appendix.
> it doesn't make sense to specify something that breaks SLAAC.

But you think it makes sense to specify something that breaks the network instead. That is, IMO, a curious tradeoff.

> 
> protocol design is politics. we want to make it clear to the address delegation authorities that not delegating a large enough address block will lead to breakage.

It’s not only about the size of the prefix. It’s about all the variety of situations we will encounter.
Before the first homenet router is shipped, Hipnet-like routers (Those who do PD sub delegation) will be there. 
Mostly as CPE routers. If the ISP is kind enough to give you a /56, they will probably give you a /60. If the ISP provides a /60, they will provide a /64.
The customer will buy a *homenet enabled* router. Put it behind one of these CPEs, and won’t be able to provide a prefix on both wifi and wired networks. That works in ISP—Homenet—SubDelegation—Homenet situations too.

And broadband ISPs are not the only kind of uplinks you will have to deal with. 
- VPN service that provides you with a /64 only
- Virtualized networks
- Tethering with your phone… They are not going to provide a /56 for that (Or at least not soon enough).
- Electrical Company will probably not start giving 56s.
- etc…

And on top of that, you’ll have all the devices that require /64 prefixes and cut work without it. 
The algorithm is able to provide them with /64s and deal with smaller prefixes on the rest of the network.

Let’s dream about a world where every device will talk Homenet, but waiting for that time, we’ll have to deal with hundreds of devices that behave differently.

> 
> in my view, if we let this principle slide, then the risk isn't that the delegations are /80s, but that they will be /128s. and you're back to IPv6 NAT anyhow.
> 

If that really is a valuable argument, we should start breaking IPv4 so that ISPs deploy IPv6 faster.

Cheers,

- Pierre