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

Ole Troan <otroan@employees.org> Thu, 09 October 2014 11:03 UTC

Return-Path: <otroan@employees.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 02E9D1ACD58 for <homenet@ietfa.amsl.com>; Thu, 9 Oct 2014 04:03:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.235
X-Spam-Level:
X-Spam-Status: No, score=-6.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] 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 X6ajK9AxMmnD for <homenet@ietfa.amsl.com>; Thu, 9 Oct 2014 04:03:26 -0700 (PDT)
Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 675661ACD57 for <homenet@ietf.org>; Thu, 9 Oct 2014 04:03:26 -0700 (PDT)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AqAEAPpqNlStJssW/2dsb2JhbABf1x4CgR4Be4QEAQEDAXkFCwtGVwaISQizIpJoAReQETMHgy2BHgEEnnODRYoFgxaDf4IggUU7gnkBAQE
X-IronPort-AV: E=Sophos;i="5.04,684,1406592000"; d="scan'208";a="205565326"
Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP; 09 Oct 2014 11:03:24 +0000
Received: from dhcp-10-61-103-225.cisco.com (dhcp-10-61-103-225.cisco.com [10.61.103.225]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s99B3Nqb027268 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 9 Oct 2014 11:03:24 GMT
Content-Type: text/plain; charset="windows-1252"
Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\))
From: Ole Troan <otroan@employees.org>
In-Reply-To: <A50A4BEF-B267-4BFF-8DDE-297D03A16DBC@darou.fr>
Date: Thu, 09 Oct 2014 13:03:23 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <0D6BC65B-CD29-4C90-8787-365C79542DDC@employees.org>
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>
To: Pierre Pfister <pierre.pfister@darou.fr>
X-Mailer: Apple Mail (2.1990.1)
Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/W90H1hqgCz3rdEtkwvqfDaRl820
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:03:28 -0000

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

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.

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.

cheers,
Ole