[ppml] Proposed Policy: IPv4 Countdown
David Conrad
drc at virtualized.org
Wed Mar 14 18:56:09 EDT 2007
- Previous message: [ppml] Proposed Policy: IPv4 Countdown
- Next message: [ppml] Proposed Policy: IPv4 Countdown
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Hi, > The NRO is really all about how to get the RIRs to play nice in the > sandbox > with each other. Actually, the NRO was all about what would happen if ICANN collapsed. What it is all about now is an exercise for the reader (:-)). > An observation I have been working from lately : It is simple human > nature > to ignore the problem until it becomes a crisis. Given that, most > Network > Managers will not act until they run into a problem getting IPv4 > space. Very true. This is why the proposal coming from APNIC confuses me. In particular, section 4.1 (4) says that there should be no change in allocation policies "until the last moment". One day, an ISP can get address space from the RIR, the next day, it can't. Period. Well, unless your lawyers or government (if the RIR is located in your country) can get at the space reserved in 4.1 (2). This seems to be a pretty optimal way for both instigating a rush on address space as well as engendering confusion, chaos, and lawsuits. > ISPs will have to pay whatever the market demands until their - > customers- stop using > IPv4. I suspect -customers- will have to pay whatever the market demands. ISPs will undoubtedly be happy to route prefixes provided to them by their customers for a (perhaps not so) nominal fee. Of course, this implies fragmenting prefixes and a surge in the amount of unaggregatable routing information being propagated back and forth (whether this is a real problem depends is an interesting ongoing debate). If a customer doesn't have a prefix, then I'm sure ISPs will be happy to provide them with a few addresses the customer can assign to their NAT boxes for a (perhaps not so) nominal fee. I suspect ISPs, when faced with the prospect of getting not insignificant revenue from the address space they already 'have under their control', will quickly see the advantages of renumbering their infrastructure with IPv6, tunneling IPv4 through IPv6, or (possibly augmented) RFC 1918 space and using their existing non-private IPv4 for customer NAT box interconnects. > Eventually this will resolve itself as > people realize the machines they have are capable of IPv6, some > services > will offer IPv6 access forcing others to follow suit or loose > eyeballs, at > which point the only ones that will even be aware of IPv4 or care > are those > that just refuse to evolve. I'm not sure I follow this. Services would lose eyeballs if they were IPv6-only so any IPv6-only site will need to have some mechanism to communicate with the vast majority of the Internet that only has IPv4. Since IPv4 will not be available (thus breaking the base assumption of the "dual stack" transition strategy), the only option I see is NAT. Since you're already doing NAT, why bother deploying IPv6? Given inertia and your observation of human nature, it would seem a likely outcome of the impending IPv4 free pool runout will be a vast swamp of IPv4 NAT end points, interconnecting and interconnected with private networks (either IPv4 tunneled through IPv6 or RFC 1918 space). Blech. Rgds, -drc
- Previous message: [ppml] Proposed Policy: IPv4 Countdown
- Next message: [ppml] Proposed Policy: IPv4 Countdown
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
More information about the PPML mailing list