Re: I-D ACTION:draft-narten-ipv6-3177bis-48boundary-00.txt

Brian E Carpenter <brc@zurich.ibm.com> Wed, 20 July 2005 06:33 UTC

Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dv88f-0002j3-Ij; Wed, 20 Jul 2005 02:33:05 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dv88d-0002gL-AQ for ipv6@megatron.ietf.org; Wed, 20 Jul 2005 02:33:03 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA02668 for <ipv6@ietf.org>; Wed, 20 Jul 2005 02:33:01 -0400 (EDT)
Received: from mtagate2.uk.ibm.com ([195.212.29.135]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dv8cO-0000ec-F1 for ipv6@ietf.org; Wed, 20 Jul 2005 03:03:50 -0400
Received: from d06nrmr1407.portsmouth.uk.ibm.com (d06nrmr1407.portsmouth.uk.ibm.com [9.149.38.185]) by mtagate2.uk.ibm.com (8.12.10/8.12.10) with ESMTP id j6K6WlSk310854 for <ipv6@ietf.org>; Wed, 20 Jul 2005 06:32:47 GMT
Received: from d06av03.portsmouth.uk.ibm.com (d06av03.portsmouth.uk.ibm.com [9.149.37.213]) by d06nrmr1407.portsmouth.uk.ibm.com (8.12.10/NCO/VERS6.7) with ESMTP id j6K6Wlx0281160 for <ipv6@ietf.org>; Wed, 20 Jul 2005 07:32:47 +0100
Received: from d06av03.portsmouth.uk.ibm.com (loopback [127.0.0.1]) by d06av03.portsmouth.uk.ibm.com (8.12.11/8.13.3) with ESMTP id j6K6Wk2h015604 for <ipv6@ietf.org>; Wed, 20 Jul 2005 07:32:46 +0100
Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d06av03.portsmouth.uk.ibm.com (8.12.11/8.12.11) with ESMTP id j6K6Wk6w015598; Wed, 20 Jul 2005 07:32:46 +0100
Received: from zurich.ibm.com (sig-9-145-255-17.de.ibm.com [9.145.255.17]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id IAA50332; Wed, 20 Jul 2005 08:32:44 +0200
Message-ID: <42DDF00C.90807@zurich.ibm.com>
Date: Wed, 20 Jul 2005 08:32:44 +0200
From: Brian E Carpenter <brc@zurich.ibm.com>
Organization: IBM
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113
X-Accept-Language: en, fr, de
MIME-Version: 1.0
To: "Manfredi, Albert E" <albert.e.manfredi@boeing.com>
References: <EF40C42ACAB7A649B2EAE70C19B6CD6E037C3AD9@xch-ne-02.ne.nos.boeing.com>
In-Reply-To: <EF40C42ACAB7A649B2EAE70C19B6CD6E037C3AD9@xch-ne-02.ne.nos.boeing.com>
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d
Content-Transfer-Encoding: 7bit
Cc: ipv6@ietf.org, Bob Hinden <bob.hinden@nokia.com>, global-v6@lists.apnic.net
Subject: Re: I-D ACTION:draft-narten-ipv6-3177bis-48boundary-00.txt
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>
Sender: ipv6-bounces@ietf.org
Errors-To: ipv6-bounces@ietf.org

Manfredi, Albert E wrote:
>>A /128 breaks IPv6 Privacy Addresses (RFC3041).  Every device 
>>needs a /64 
>>to allow this mechanism to be used.
>>
>>Bob
> 
> 
> Alternative mechanisms could permit interface IDs to be shorter than 64
> bits, for example 48 bits or far fewer than that. Interface IDs only
> need to be unique within a given subnet, and subnets with long prefixes
> could be small enough to make the uniqueness requirement easy to
> achieve. And also resolve the privacy concern in RFC 3041, by not
> creating interface IDs that are likely to be globally unique?
> 
> If we're quibbling about conserving address space by assigning 56 vs 48
> bit prefixes to individual sites, imagine how much more flexibility and
> savings could be achieved by allowing shorter interface IDs. Without
> imposing the restriction in RFC 3513 Section 4, and without increasing
> privacy concerns. No?

I think this greatly underestimates the practical impact of shortening
the IID. In reality /64 is an architectural boundary, even if in theory
it isn't. I don't believe that revisiting this is realistic. And I don't
believe it is in the least necessary. (This point really concerns
draft-narten-iana-rir-ipv6-considerations-00.txt, not the current draft.)

    Brian


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