[ipv6hackers] Pros and Cons of Address Randomization

[Owen DeLong]

On Dec 9, 2012, at 11:57 PM, Beat Rubischon <beat at 0x1b.ch> wrote:

> Hello!
> 
> I follow your discussion with a lot of interest. One point I like to
> mention is the fact we still need IPv4 for ages on our LANs and a lot of
> interesting concepts provided by IPv6 are meaningless until we have pure
> IPv6 only networks. Dual stack is still the only possibility to keep
> compatibility to the existing internet. I played with NAT-PT, TRT and
> totd and it's still a big hack, nothing I would implement in a
> production environment. There is simply no useful backward compatibility
> built in, something which was pointed out by DJB years ago [1]. No, I
> don't like his fatalism, but this article contains stuff I'm able to assist.
> 
> 	[1] http://cr.yp.to/djbdns/ipv6mess.html
> 
> Is address randomization really a solution to convince our CEOs to the
> expose of their personal PC addresses to the world? I'm pretty unsure.
> At least my CEO wouldn't accept this fact.
> 
> In the meantime a lot of good stuff in IPv6 was already killed. There is
> DHCPv6 to provide "static" addresses to the clients - which killed the
> great feature of announcing multiple prefixes and routers to a subnet.

DHCPv6 does not prevent you from doing this and you're not required to
use DHCPv6… SLAAC is still widely available, so this comment doesn't
make any sense to me.

> There are PI networks - they killed the hierarchical routing concept
> which would save a lot of memory in the large border routers. And there

Hi… Without PI, IPv6 was going to be a non-starter in the enterprise.
Nobody wants to renumber a 2,000,000 node network every time they want
to switch providers. We need to find a better solution to the scalability
of the routing system. Unfortunately, the IETF punted on that early in the
IPv6 development process and is just now getting back to it. Disastrously,
this means we'll probably have to either really kludge it, or, recode the
packet header yet again.

> are gazillions of firewalls preventing end to end connections - why
> should we allow end to end by the network protocol when mostly everybody
> kills it with more or less broken firewalls?

I don't buy this argument, either. There are still lots of good use cases
for end-to-end addressing where any end-to-end connectivity permitted by
policy can succeed. Host security has not achieved a maintainable level
that would allow us to discard firewalls yet. Hopefully some day it will,
but for now, it is what it is. Transparent addressing is still extremely
valuable even if it doesn't result in end-to-end transparent connectivity
in all cases.

> 
> Applications will have to handle connection refused even in the IPv6
> world. And they will need ways to workaround these problems.
> 

Right, but unlike IPv4 where connection refused might mean "denied" or
it might mean "our NAT box won't let you through so you have to use a
rendezvous host and a bunch of tricks to open weird ports to fool the
firewalls on both sides into translating things so that they work even
though this is entirely insecure" (aka uPNP/NAT-PMP/etc.), if you get
connection refused in IPv6, it means someone in the path didn't want
to permit the packets through. Give up, tell the user it's broke, and
let them argue with the applicable administrator. Much simpler.

> So lets kill end to end connectivity. Invent NATv6 and allow the
> millions of networks to operate the same way as in the IPv4 world. Yes,
> I know NATv6 is a bad word and most readers here will pick up their
> flame thrower. I would never accept it in networks operated by myself.
> But I see it as the only possibility to migrate millions of SOHO networks.

Why? Lots of SOHO networks are already on IPv6 without NATv6 and I don't
see what possible advantage you are advocating here.

Owen