[128075] in North American Network Operators' Group
Re: Addressing plan exercise for our IPv6 course
daemon@ATHENA.MIT.EDU (Owen DeLong)
Sat Jul 24 05:13:42 2010
From: Owen DeLong <owen@delong.com>
In-Reply-To: <20100724082932.GA12472@mx.ytti.net>
Date: Sat, 24 Jul 2010 02:13:18 -0700
To: Saku Ytti <saku@ytti.fi>
Cc: nanog@nanog.org
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
On Jul 24, 2010, at 1:29 AM, Saku Ytti wrote:
> On (2010-07-24 03:50 -0400), Valdis.Kletnieks@vt.edu wrote:
>=20
>> Firewall !=3D NAT. The former is still needed in IPv6, the latter is =
not. And I
>> suspect that most Joe Sixpacks think of that little box they bought =
as a
>=20
> Maybe you are talking strictly in context of residential DSL, in which =
case
> I would agree, NAT is killable, if we don't fsck-up in our DSL =
offerings.
> (Provide customer /64 and route /56 to ::c/64, so first /64 is =
bridged, if
> customer ever wants to start routing, they just add ::c/64 router to =
LAN.)
>=20
> However it is quite optimistic to think IPv6 would remove completely =
need
> for NAT. 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. I'm just hoping that we'll at =
least
> see 1:1 NAT instead of NAPT being used.
>=20
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.
> 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?
Finally, if you think that non-multihomed end sites need PI, then, put a =
proposal
in to change the RIR policies. RIR policies are not immutable. Each RIR =
has
a bottom-up consensus driven process. If you don't like the policies, it =
really
isn't that hard to get them changed.
(I say this as an author of the first successful policy to create IPv6 =
PI)
> This is non-technical problem, enterprises of non-trivial size can't
> typically even tell without months of research all the devices and =
software
> where they've written down the IP addresses.
Sounds like they haven't written them down very well.
> RFC4193 + NAT quite simply is what they know and are comfortable with. =
It
> would be hard sell to ask them to design whole IPv6 infra so that they =
can
> confidently renumber it in 15min, like you can with RFC4193+NAT.
>=20
Why would you need to renumber in 15 minutes? It's easy enough to do
in a week, given the above RA-based process.
Owen
