[arin-ppml] Set aside round deux
owen at delong.com
Sun Aug 1 09:43:44 EDT 2010
On Aug 1, 2010, at 1:47 AM, Ted Mittelstaedt wrote:
> On 7/31/2010 8:22 PM, Owen DeLong wrote:
>>> I disagree unless you mean near ubiquity on the provider side. It's going to be many, many years before the end-users start using it even
>>> though their provider offers it.
>> We shall see. I suspect it will happen a lot faster than you expect due
>> to the pressure that will be brought to bear from strong economic
>> incentives to deprecate IPv4.
> I don't believe that because these economic incentives will not exist
> for all orgs at the same time. It will be very lumpy, some orgs will
> be desperate for the Internet to shift to IPv6 right away, others will be uninterested for a few years.
My point is that in fairly short order, the ISPs providing the transit services
will have strong economic incentives to deprecate IPv4. This will, in turn,
lead to strong economic incentives being passed along to their customers
in the form of "If you want us to keep routing IPv4, it's going to cost you."
>>>> I also think that
>>>> the post-runout IPv4 world is going to create a great deal of pressure to
>>>> deprecate IPv4 much sooner than most people think
>>> I hope this is true.
>> I see one of two things happening:
>> 1. The address market is a total flop, nobody wants to sell addresses
>> at any price. Result: the need for addresses drives a strong and rapid
>> shift towards IPv6.
>> 2. The address market is a wild success, /8s are deaggregated left
>> and right and sold off as /24s everywhere. The routing table explodes.
>> Creating a strong economic incentive to deprecate IPv4 just to keep
>> the internet routable.
> How about 3:
> The address market is a wild success for about 6 months until all of
> the IPv4 speculators and horders are tapped out, then it flops since
> nobody who is actually USING IPv4 wants to sell it at any price.
> Result is the need for addresses drives a strong self-generation
> movement and for another 4-5 years orgs get very creative about
> reallocating IPv4 addresses within their networks to squeeze out
> unused IPv4.
In that 6 months, the routing table growth will meet criteria number 2
and the rest won't matter.
>>>> There are far too many organizations running IPv6 for me to believe that
>>>> it cannot be deployed.
>>> And how many of those orgs are IPv6 ONLY?
>> Who said anything about IPv6 only. Deployment of IPv6 does not depend
>> on deprecation of IPv4. Quite the opposite.
> Nobody said that deployment of IPv6 is dependent on deprecation of IPv4.
> However, you cannot base the notion that IPv6 is ready for production
> on hundreds of dual-stacked orgs. As long as an org is dual-stacked it
> simply has no credibility as an example for IPv6 being ready for
> prime time and your wasting your time trying to convince someone who
> does not believe IPv6 is ready.
The main thing about IPv6 not being ready for prime time (the main reason
you need dual stack) in most cases is the ability to reach orgs that don't yet
There are a few other straggler problems such as windows resolvers
that require IPv4, but, for the most part, that's a local need for IPv4,
not a need for global IPv4 connectivity. That need can be met even
through RFC-1918 without IPv4 internet connectivity, so, is not impacted
significantly by IPv4 runout.
> It would be like someone trying to argue the advantages of everybody
> riding the bikes to work, pointing out 50 cyclists who are biking to
> work that day as evidence. Only the 4 bicyclists in that group of 50
> who don't own cars are really walking the talk. And when you come back
> the next day and it's raining buckets, sure as shootin your only gonna
> see 4 bicyclists out there, not 50.
I don't think that's quite an apples to apples comparison, but, time will
>>> Please keep in mind that people who do not have experience with
>>> enterprise networks, who are coming at this from a small company
>>> perspective, where everyone is single-homed, simply do not understand
>>> the difficulties that NAT introduces to multi-site WANs. NAT
>>> is the "poor man's firewall" to the single-homers and it is
>>> deployed on millions of residential CPEs and works well on most of
>>> them, so continuing to harp on how the lack of NAT is a benefit
>>> to IPv6 goes completely over many people's heads.
>> I have substantial experience with SOHO, small enterprise and
>> large enterprise networks as well as service provider networks
>> of just about any scale.
>> The fact that NAT is widespread does not mean we can't deploy
>> IPv6 without introducing that damage to IPv6. NAT is not the poor
>> man's firewall, just a case of ignorance on the part of the poor
>> man. The poor man's firewall is and has long been stateful
>> inspection with a default deny inbound policy for all traffic not
>> matching an existing state table entry. That works with or
>> without the address mangling of NAT. NAT, on the other hand,
>> does not work without stateful inspection.
>> NAT does cause problems even for the single-homed small
>> environment, whether those environments are aware of the
>> problems or not.
> Owen, I'm the choir your preaching to here, I'm just telling you
> that if you want to have credibility with the unrepentant sinners
> in the congregation you better start thinking like they do.
> Your running around preaching the evils of NAT and half of these SOHO's
> out there likely think your talking about some insect that flies up
> their nose when they ride their bicycle. And the ones that know
> what it is, they aren't aware of those NAT problems and so they
> are going to conclude that NAT works fine. I'm just saying,
> when preaching IPv6, you gotta flog a horse that the listener
Right now, I'm mostly focused on preaching to the content providers
and ISPs that the SOHOs connect to. The SOHOs will likely accept
whatever is handed to them by their upstream as they have in the
So far, the message seems to be getting through to the intended
audience reasonably well, but, I'll keep this in mind when I start
directly addressing SOHOs.
More information about the ARIN-PPML