[128092] in North American Network Operators' Group
Re: Addressing plan exercise for our IPv6 course
daemon@ATHENA.MIT.EDU (Owen DeLong)
Sat Jul 24 14:00:27 2010
From: Owen DeLong <owen@delong.com>
In-Reply-To: <201007241640.RAA07071@sunf10.rd.bbc.co.uk>
Date: Sat, 24 Jul 2010 10:57:49 -0700
To: Brandon Butterworth <brandon@rd.bbc.co.uk>
Cc: nanog@nanog.org
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
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.
>=20
> 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.
>=20
> 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.
>=20
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.
>=20
> 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.
>=20
> 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.
>=20
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.
>=20
> Enterprises tend to want only one identifier to manage per device and
> that it be unique and mostly permanent.
>=20
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.
>=20
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.
>>>=20
>> Why is that easier/cheaper than changing your RAs to the new provider =
and
>> letting the old provider addresses time out?
>=20
> And changing all the ACLs based on the old providers addresses
>=20
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)
>=20
That kit won't support IPv6, so, I fail to see the relevance. Any kit =
that supports
IPv6 supports this.
Owen
