Addressing plan exercise for our IPv6 course

Owen DeLong owen at delong.com
Sat Jul 24 09:13:18 UTC 2010


On Jul 24, 2010, at 1:29 AM, Saku Ytti wrote:

> On (2010-07-24 03:50 -0400), Valdis.Kletnieks at vt.edu wrote:
> 
>> Firewall != 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
> 
> 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.)
> 
> 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.
> 
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.
> 
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.
> 
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





More information about the NANOG mailing list