[ppml] IPv6 flawed?

David Conrad drc at virtualized.org
Thu Sep 13 15:02:17 EDT 2007


On Sep 13, 2007, at 10:21 AM, Ted Mittelstaedt wrote:
> I disagree.  We have worse than jack because nothing prevents any
> network admin from simply picking an unused portion of the IPv6 space
> and calling that private and slapping an IPv6 NAT in front of it.

Interoperability.  If you want to play by yourself, you can do  
anything you want.  If you want to play with others, you have to  
abide by some rules.  If you happen to pick an IPv6 prefix somebody  
or something else is using, bzzzt.  Even behind NAT.

> If IPv6 is assigned sequentially and it is as big as everyone claims,
> then how soon do you think the RIRs will run out of IPv6 assignments?
> 10 years?  50 years?  100 years?

Obviously depends on how big the assignments are and how frequently  
they're made.  When RIRs are handing out /19s and /20s (and shorter),  
hard to guess how long the entire address space will last.

> I think it would be very easy to look and find a range that won't be
> even close to being assigned for another 100 years and set up exactly
> the same NAT-based network we have today with IPv4, despite what IETF
> wants.

Maybe.  Pick something outside of 2000::/3.  Will it last a hundred  
years?  Hard to say.  Will it last long enough that you won't need to  
worry about it?  Probably (again depending on size and frequency of  
RIR allocation).

> All you really need is the IPv6 NAT device itself - and someone
> will build that once there's demand for it.

I'm sure it already exists (perhaps not yet in commercial form).  ULA  
(of any form) guarantees it.  Maybe this isn't a bad thing -- at  
least you'd have provider independence and easy site-level multi- 
homing.  (I'm reminded of the scene in the book 'Salem's Lot where a  
character is about to be bitten by a vampire and thinks to himself  
that maybe over a few centuries he'll get used to it and the undead  
existence won't be so terrible).

Regards,
-drc




More information about the ARIN-PPML mailing list