nanog mailing list archives

Re: Addressing plan exercise for our IPv6 course


From: Owen DeLong <owen () delong com>
Date: Sat, 24 Jul 2010 10:57:49 -0700


On Jul 24, 2010, at 9:40 AM, Brandon Butterworth wrote:

Enterprises of non-trivial size will likely use RFC4193 (and I
fear we will notice PRNG returning 0 very often) and then NAT it to
provider provided public IP addresses.

Eventually ARIN (or someone else will do it for them) may create a site
you can register your address and know that it really is unique
among participating registrants. Random is fine, unique is better.

Such a site would be the seed for when (if) we come up with the tech
for everyone to have PI and lose all the restrictions imposed so far.

SIXXS already has such a registry with a pretty low adoption rate.

I still fail to see any advantage whatsoever to this approach and I think
that the limited number of sites that implement it is unlikely to get
continued support from ISVs.

I'm just hoping that we'll at least
see 1:1 NAT instead of NAPT being used.

I think that will be a common PI alternative. If people really don't
want NAT then we shouldn't provide reasons for it to exist.

RFC4193 seems to be the best enterprise plan. They can link to other
enterprises and change ISPs easily or multihome. They are not beholden
to any ISP or numbering authority. The global table doesn't explode.

I agree that easier to get PI addresses is a better alternative. I will support
policy initiatives to do that. RFC4193 remains an utterly horrible idea
and NATing it to the public internet remains even worse.

Why on earth would you do that? Why not just put the provider-assigned
addresses on the interfaces along side the ULA addresses? Using ULA
in that manner is horribly kludgy and utterly unnecessary.

Enterprises tend to want only one identifier to manage per device and
that it be unique and mostly permanent.

Right... That identifier is the EUI-64 which is both permanent and unique.
The prefix changes when you switch providers, but, that's mostly not
particularly horrible since there are tools to make that easier for the
bulk of internal hosts.

With several PA and ULA on each device, links to ISPs and other
enterprises, the combinations of addresses and paths to manage flows
and security over become too hard (if it's not simple it's probably not
secure). Every device becomes a router and firewall and the staff who
manage those aren't cheap.

Actually, if you set things up correctly, most of the security stuff to manage
is about the same because you hairpin the stuff that doesn't need filtration
at a point before it hits the packet filters.

This is to facilitate easy and cheap way to change provider. Getting PI
address is even harder now, as at least RIPE will verify that you are
multihomed, while many enterprises don't intent to be, they just need low
cost ability to change operator.

Why is that easier/cheaper than changing your RAs to the new provider and
letting the old provider addresses time out?

And changing all the ACLs based on the old providers addresses

Mostly this is a pretty straight forward copy->search->replace
problem with prefix changes that can be done with the equivalent
of an s/x/y/g construct.

And allowing for all the 5 - 15 year old kit that predates this and
won't be upgraded (we have that problem with NT embedded in systems
with 10year+ refresh cycle)

That kit won't support IPv6, so, I fail to see the relevance. Any kit that supports
IPv6 supports this.

Owen



Current thread: