[arin-ppml] ARIN-prop-127: Shared Transition Space for IPv4Address Extension
aaronh at bind.com
Fri Jan 21 13:18:08 EST 2011
I do not believe anyone would disagree with anything you said below. We all want all objects to support IPv6 and the transition to be easy and smooth. Wouldn't it be nice if we could turn off IPv4 when we were done in a reasonably short period of time...
1) CPEs that do support IPv6 will provide SLAAC or DCHPv6 only to objects that will accept it.
2) Some objects behind the CPE will accept IPv6 / Dual stack, most will not.
3) Many objects behind the CPE are not capable of being upgraded via software to support IPv6.
4) The average person does not know how to take a software update unless a window pops up and says 'click here to install updates'. (Extremely unlikely to be able to perform a firmware upgrade).
5) Many CPEs must be replaced to support IPv6.
6) Many customers will not replace their CPE even if a new one arrives for free.
All of these things are bad and I am sure the list could go on far longer than this one.
- My grandfather still had a pulse phone until last year when the telephone company finally forced him to pay for touch tone and replaced his phone for him.
- X.25 is still heavily in use today (ATM machines etc)
- People still have VCRs
- People still have broadcast television
- People still have pagers
IPv4 will very likely be around for 20+ years.. Sad, but still true.
On Fri, Jan 21, 2011 at 09:50:39AM -0800, George Bonser wrote:
> > >
> > [WES] The IPv6 purist in me couldn't agree more. The pragmatist in me
> > understands that this is an oversimplification of the situation,
> > especially
> > when you start looking at this from the consumer/residential
> > perspective,
> > rather than the enterprise.
> > How many of the network-connected devices in your house support IPv6
> > right
> > now, besides your PC/Mac/Linux box and/or Android/iPhone (wifi only)?
> > [In my
> > case, exactly none, mainly because I couldn't *find* things that did
> > when it
> > was time to purchase]. You want to replace them all to make the
> > network-connected parts keep working? How about your mobile phone?
> > No?
> It has been my experience that many manufacturers don't change anything
> unless they *have* to. They might this minute be scrambling to get IPv6
> into their products but that could all come to a screeching halt and
> they breathe a collective sigh of relief if something like this comes
> about and they continue shipping v4 only devices in perpetuity.
> I suppose I wish there was a way to *temporarily* allow this and not
> create a mechanism for the perpetuating of manufacturers to continue to
> produce v4-only devices, which they probably will if something like this
> passes, particularly if done on a global scale.
> > Would you look for another ISP if you called me to complain and I told
> > you
> > that you *had* to replace one or more of the devices that *you* paid
> > for in
> > order to make them work on my network?
> I would phrase it differently. There should be an education process
> with the users that the "old" IP addresses will soon be running out and
> the new system is incompatible with the old. This shouldn't be a
> "surprise" to the users. Operators and manufacturers have known this
> was coming for a very long time. In fact, I would support a regulation
> at the federal level that makes it illegal to sell an IPv4-only device
> in the United States much like they did with TVs. Maybe something like
> this could be used to enable a "converter" solution until the v4 only
> devices attrit but right now we have no mechanism to ensure that v4
> devices go away and something like this could enable them forever.
> > Regardless of what we do, NAT444 is a necessary evil. It's just a
> > question
> > of how much remaining address space (if any) we want to use in the
> > commission of said evil.
> > Wes George
> I see it as a temporary necessity, not a permanent necessity.
> The hard part to crack is how to ensure it is temporary.
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> Please contact info at arin.net if you experience any issues.
aaronh at bind.com
Key fingerprint = AD 67 37 60 7D 73 C5 B7 33 18 3F 36 C3 1C C6 B8
More information about the ARIN-PPML