Re: [Fwd: I-D Action: draft-carpenter-6man-why64-00.txt]

Hi Ray,

It would be good to suggest specific text/edits.

Tim

On 7 Jan 2014, at 11:11, Ray Hunter <v6ops@globis.net> wrote:

> Brian E Carpenter wrote:
>> Hi,
>> 
>> A group of us put this together following a discussion some weeks
>> ago on the v6ops list about the 64-bit boundary in IPv6 addresses.
>> Discussion belongs in 6man, please.
>> 
>> This draft is incomplete but we'd welcome input. Let me underline
>> an important comment in the introduction:
>> 
>>   _The purpose of this document is to analyse the issues around this
>>    question.  We make no proposal for change, but we do analyse the
>>    possible effects of a change._
>> 
>> 
>>    Brian + co-authors
>> 
>> -------- Original Message --------
>> Subject: I-D Action: draft-carpenter-6man-why64-00.txt
>> Date: Sun, 05 Jan 2014 13:59:17 -0800
>> From: internet-drafts@ietf.org
>> Reply-To: internet-drafts@ietf.org
>> To: i-d-announce@ietf.org
>> 
>> 
>> A New Internet-Draft is available from the on-line Internet-Drafts directories.
>> 
>> 
>>         Title           : Analysis of the 64-bit Boundary in IPv6 Addressing
>>         Authors         : Brian Carpenter
>>                           Tim Chown
>>                           Fernando Gont
>>                           Sheng Jiang
>>                           Alexandru Petrescu
>>                           Andrew Yourtchenko
>> 	Filename        : draft-carpenter-6man-why64-00.txt
>> 	Pages           : 14
>> 	Date            : 2014-01-05
>> 
>> Abstract:
>>    The IPv6 unicast addressing format includes a separation between the
>>    prefix used to route packets to a subnet and the interface identifier
>>    used to specify a given interface connected to that subnet.
>>    Historically the interface identifier has been defined as 64 bits
>>    long, leaving 64 bits for the prefix.  This document discusses the
>>    reasons for this fixed boundary and the issues involved in treating
>>    it as a variable boundary.
>> 
>> 
>> The IETF datatracker status page for this draft is:
>> https://datatracker.ietf.org/doc/draft-carpenter-6man-why64/
>> 
>> There's also a htmlized version available at:
>> http://tools.ietf.org/html/draft-carpenter-6man-why64-00
>> 
>> 
> I have read this draft.
> 
> some comments:
> 
> Where exactly is the requirement that IPv6 has to use /64 prefix length really enshrined?
> I think the draft can help clarify that, and that alone makes it worthwhile proceeding.
> 
> 
> I humbly disagree with the conclusions in Section 9.
> 
> The argument seems to assume that all n hosts must be allocated within one single prefix with a prefix length >> 64.
> Therefore it assumes that increasing prefix length reduces attack search space (given some knowledge of one or more active IPv6 addresses)
> 
> IMHO Address space is address space. Allocation density is allocation density. IPv6 supports multiple prefixes per link and the concept of determining "on link prefixes" via rfc5942 (unlike the "subnet mask" mechanism of IPv4).
> 
> It should be perfectly feasible to allocate a /64 to a router interface in an IPAM tool, but then configure the equivalent of n prefixes each containing 1 or 2 address with prefix length /128 or /127 (depending on the implementation) for n hosts and which are equally sparsely assigned across the /64, and all sharing a single L2 link. Even end node to end node communication should flow directly (avoiding the router) as these prefixes could be marked "on link" via the AdvOnLinkFlag = L flag.
> 
> Anyway, in the majority of modern day wired deployments, the delta cost of L3 over L2 is minimal, as the most dominant form of wired LAN (Ethernet) are commonly switched in silicon, and multicast has to be emulated. Wired Ethernet has in effect become a point to point protocol. So deploying a dedicated L3 connection per end host is both technically and financially feasible, and may have significant operational benefits in certain scenarios. Allocating a /64 for each such port on a L3 switch is sub optimal IMHO. And by the same privacy argument, allocating n hosts sparsely over a single /64 of address space spread over multiple L3 interfaces would have the same net effect for off-net attackers as n hosts sharing a flat L2 LAN using a single /64, with the added advantage that even locally the individual end nodes would not be able to passively observe each other's traffic or addresses (advantageous in shared hosting environments).
> 
> An attacker that happens to discover the address of node A would not find this information helpful in attempts to locate node B, any more than if it were a flat /64.
> 
> So to me it's a non-relevant argument one way or the other.
> 
> Section 2.2
> 
> It may not be a widely held belief, but I remain concerned about the potential for resource exhaustion for any number of processes due to the "massive over sizing" of prefixes to /64: any number of untested processes that track state based on /128 IPv6 address could be attacked. The flip side of expanding privacy through address obfuscation at IID level is that the source space available for attacks also increases. ND cache exhaustion is probably just the first issue we've discovered of many that exist. This may have knock on operational consequences, which in the IPv4 world have relied on the scarcity of IPv4 address space to be able to operate correctly under stress scenarios. We're going to discover who has been swimming naked when the tide goes out. Call that FUD, or operational expediency, whichever you like. BCP38 has saved me on a number of occasions when all else has failed.
> 
> 
> -- 
> Regards,
> RayH
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------