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

[Ray Hunter <[e-mail]>]

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: [e-mail]
> Reply-To: [e-mail]
> To: [e-mail]
>
>
> 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