Re: Why /64 [was Deprecating EUI-64 Based IPv6 Addresses]

"Bless, Roland (TM)" <roland.bless@kit.edu> Mon, 28 October 2013 08:36 UTC

Return-Path: <roland.bless@kit.edu>
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 D9F5311E822E for <ipv6@ietfa.amsl.com>; Mon, 28 Oct 2013 01:36:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.319
X-Spam-Level:
X-Spam-Status: No, score=-6.319 tagged_above=-999 required=5 tests=[AWL=-0.070, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4taIuaYnq6jI for <ipv6@ietfa.amsl.com>; Mon, 28 Oct 2013 01:36:44 -0700 (PDT)
Received: from iramx2.ira.uni-karlsruhe.de (iramx2.ira.uni-karlsruhe.de [141.3.10.81]) by ietfa.amsl.com (Postfix) with ESMTP id A4CBC11E8146 for <ipv6@ietf.org>; Mon, 28 Oct 2013 01:36:41 -0700 (PDT)
Received: from irams1.ira.uni-karlsruhe.de ([141.3.10.5]) by iramx2.ira.uni-karlsruhe.de with esmtps port 25 id 1VaiJI-0000ZM-Uv; Mon, 28 Oct 2013 09:36:30 +0100
Received: from i72vorta.tm.uni-karlsruhe.de ([141.3.71.26] helo=vorta.tm.kit.edu) by irams1.ira.uni-karlsruhe.de with esmtp port 25 id 1VaiJS-0003us-9n; Mon, 28 Oct 2013 09:36:38 +0100
Received: from [IPv6:::1] (ip6-localhost [IPv6:::1]) by vorta.tm.kit.edu (Postfix) with ESMTPS id 2C735A8067F; Mon, 28 Oct 2013 09:36:37 +0100 (CET)
Message-ID: <526E2214.1060800@kit.edu>
Date: Mon, 28 Oct 2013 09:36:36 +0100
From: "Bless, Roland (TM)" <roland.bless@kit.edu>
Organization: Institute of Telematics, Karlsruhe Institute of Technology
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.0
MIME-Version: 1.0
To: Tim Chown <tjc@ecs.soton.ac.uk>, 6man List <ipv6@ietf.org>
Subject: Re: Why /64 [was Deprecating EUI-64 Based IPv6 Addresses]
References: <20131021224346.32495.64932.idtracker@ietfa.amsl.com> <52695DDE.70909@gont.com.ar> <526AA24F.6010609@gmail.com> <526AACA5.7090604@si6networks.com> <E0F0D3DE-D31B-4CC2-9384-DFEBCCB8F557@ecs.soton.ac.uk> <EMEW3|9f43bef2fe7433173858819bd0eeee2dp9OKUJ03tjc|ecs.soton.ac.uk|E0F0D3DE-D31B-4CC2-9384-DFEBCCB8F557@ecs.soton.ac.uk> <526B0A30.9060600@gmail.com> <526B0E15.8080602@si6networks.com> <F6264230-19EB-4FEC-910C-C86F14C28A83@ecs.soton.ac.uk> <EMEW3|d9e74aba9561d767d4403c2b6597aed6p9P8h103tjc|ecs.soton.ac.uk|F6264230-19EB-4FEC-910C-C86F14C28A83@ecs.soton.ac.uk>
In-Reply-To: <EMEW3|d9e74aba9561d767d4403c2b6597aed6p9P8h103tjc|ecs.soton.ac.uk|F6264230-19EB-4FEC-910C-C86F14C28A83@ecs.soton.ac.uk>
X-Enigmail-Version: 1.5.2
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: 8bit
X-ATIS-AV: ClamAV (irams1.ira.uni-karlsruhe.de)
X-ATIS-AV: ClamAV (iramx2.ira.uni-karlsruhe.de)
X-ATIS-Timestamp: iramx2.ira.uni-karlsruhe.de 1382949390.
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.12
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: <http://www.ietf.org/mail-archive/web/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: Mon, 28 Oct 2013 08:36:51 -0000

Hi,

On 26.10.2013 09:41, Tim Chown wrote:
>> OTOH, deprecating Modified EUI-64 is a local policy which is 
>> incrementally-deployable.
> 
> Well yes, there’s obviously a large deployed code base where /64 has
> been assumed. And changing that assumption may simply not be
> practical.
> 
> But… for example, some people who were concerned over the ND cache
> problem have run with /120 and DHCPv6. I’m not advocating that.
> Indeed the homenet arch text specifically mentions not using such
> “tricks" where the ISP only allocates one /64 to a home which
> requires multiple subnets.
> 
> I’m just suggesting it would be interesting to spend a little time to
> figure out where the /64 really is “burnt in” so that, if there were
> a desire to explore proposing a /80 or /96 or whatever for a future
> SLAAC, we would have a clearer idea of what the implications would
> be, and how/if an incremental progression to variable length SLAAC
> could be facilitated.

+1

Regards,
 Roland