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

[Alexandru Petrescu <[e-mail]>]

Le 07/01/2014 12:11, Ray Hunter a écrit :
[...]
> 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)

Would these hosts use some form of address auto-configuration?

But yes, I agree with the point that this should be possible.

[...]
> 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).

I agree that with large switches and VLANs often the links look very 
much as point to point links.

> 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.

Right.

Alex

> 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.
>
>