Re: What's 16 bits between friends?

Brian Dickson <briand@ca.afilias.info> Tue, 18 September 2007 13:44 UTC

Return-path: <ipv6-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IXdNS-0007A9-A1; Tue, 18 Sep 2007 09:44:34 -0400
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IXdNQ-00076l-Ou for ipv6@ietf.org; Tue, 18 Sep 2007 09:44:32 -0400
Received: from vgateway.libertyrms.info ([207.219.45.62] helo=mail.libertyrms.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IXdNQ-0003JZ-8f for ipv6@ietf.org; Tue, 18 Sep 2007 09:44:32 -0400
Received: from briand-vpn.int.libertyrms.com ([10.1.7.90]) by mail.libertyrms.com with esmtp (Exim 4.22) id 1IXdNP-0007Ge-FX; Tue, 18 Sep 2007 09:44:31 -0400
Message-ID: <46EFD636.7040008@ca.afilias.info>
Date: Tue, 18 Sep 2007 09:44:22 -0400
From: Brian Dickson <briand@ca.afilias.info>
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: Ignatios Souvatzis <ignatios@cs.uni-bonn.de>
References: <20070918120411.GF2363@cs.uni-bonn.de>
In-Reply-To: <20070918120411.GF2363@cs.uni-bonn.de>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-SA-Exim-Mail-From: briand@ca.afilias.info
X-SA-Exim-Scanned: No; SAEximRunCond expanded to false
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1
Cc: IETF IPv6 Mailing List <ipv6@ietf.org>
Subject: Re: What's 16 bits between friends?
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "IP Version 6 Working Group \(ipv6\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
Errors-To: ipv6-bounces@ietf.org

Ignatios Souvatzis wrote:
> On Mon, Sep 17, 2007 at 10:16:04PM -0700, Christian Huitema wrote:
>
>   
>> That was, and still is, the official IEEE line. IEEE 802 is very
>> concerned that 48 bit is not quite enough.
>>     
>
> Let me add that IEEE1394 is using 64 bit addresses - and yes, it's in
> occasional use here:
>
>   
This comment actually make clear why one size isn't necessarily appropriate:
"Occasional use".

Compare that to deployed networks with hosts world-wide for MAC-48 (i.e. 
802.*) of >> 10^8 devices.
IPv4 networks in the DFZ numbering >>200,000 even with CIDR aggregation.

There is a need to deploy IPv6 into the global Internet to handle the 
IPv4 space exhaustion.

The routing infrastructure of the combined IPv4+IPv6 needs to survive 
the addition of IPv6, and handle
the dual routing via dual-stack, for a minimum of 3-10 years. This means 
not only supporting all of the
existing devices, but handling the continuation of exponential growth, 
ideally with a minimum of additional
routing slots eaten up on the devices in the DFZ.

The question I raise is:
Do we feel so strongly about universally supporting oddball cases, that 
we will not accommodate operator
need when it is presented?

 From what I have seen so far as responses, the counter arguments are:
- there are these wonky things that maybe a few dozen research sites are 
playing with that use 64-bits for MAC
- changing the spec would require, like, actual work. Let's just leave 
it alone

IMHO, those arguments don't hold water.

And, in fact, I'm talking about *relaxing* some of the requirements, in 
a permissive sense, where existing
implementations would not be out-of-spec. So, anyone who is lazy, can 
continue to use old code.

What I'm talking about, is adjusting the specs, so that those who see a 
need for new code, can do the
work, and have it continue to be considered valid as far as the RFCs are 
concerned.

As for prefixes, the RA stuff never actually was constrained to be only 
64 bits of network.
It was only that, for autoconf to work, the announced prefix had to mesh 
with the II exactly.

Relaxing *that* has no impact on the RA's, or old code. Nothing prevents 
an RA using /64, which
will continue to support EUI-64 with autoconf (old code).

What it *does* do, is allow for new code with flexible II of MAC-48 + 
padding, to work with arbitrary
prefixes announced by RA when doing autoconf.

Which, in turn, supports real-world use of autoconf on /80's, permitting 
global assignment
policy which will support real-world growth over the next decade or two, 
while protecting
the DFZ from prefix explosion caused by allocation "squeeze" effects.
> tiger# ifconfig fwip0
> fwip0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
>         address: 00:11:06:00:00:00:6a:21
> 	inet6 fe80::211:600:0:6a21%fwip0 prefixlen 64 scopeid 0x1
>   
I note that all of the examples sent have link-local addresses only.

And, since each such network will include only similar devices, all with 
MAC-64, the addressing
used for those networks has no impact on the addressing for networks 
running Ethernet framing
and MAC-48.

Brian

--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------