From: ietf-bounces(_at_)ietf(_dot_)org
[mailto:ietf-bounces(_at_)ietf(_dot_)org] On Behalf Of
Randy Bush
talk to free.fr, camron byrne, ... there are roadmaps.
but this proposal is not about migrating to ipv6. it is about ipv4
life extension and nat4444444 4ever. to hell with that.
[WEG] let's see... free.fr = 6rd. Cameron Byrne (TMO) = NAT64 (which requires
IPv6-capable end devices) + squatting on routable space (*not* 1918) + CGN.
Please explain how either of those help to ensure that I can stay in business,
given that my business requires me to provide functional IPv4 service to
devices that my *customers* own which do not support IPv6, *IN ADDITION TO*
deploying IPv6 [citations: 1, 2, 3, 4] for devices that do.
Should I stop selling IPv4 service citing the IETF's principles on the matter?
Tell all of my customers that they must spend hundreds or thousands of dollars
to upgrade all of their otherwise functional IP-capable devices because the old
ones are obsolete (not to mention that the current new ones *still* might not
support IPv6)?
I admit that DSLite would potentially help, but that requires support in CPE
that is currently extremely limited, and my business model does not allow for
me to purchase a new router for all X Million of my customers anyway.
*taps the mic, clears throat*
<RandyBush> "I strongly encourage all of my competitors to do the above."
</RandyBush>
<snip>
this has become a contest of wills, not a technical discussion.
[WEG] only because a number of folks, including you, insist on arguing about
"the principle of the thing" and "making the internet work better" and "IPv4
life support" while rejecting technical arguments that you don't believe/like
despite hearing them from multiple operators and other sources.
This is turning into a referendum on CGN and whether the industry as a whole
has deployed IPv6 fast enough for a set of armchair quarterbacks' taste, and
now people seem content to wag fingers and revel in saying "I told you so..."
because business reality didn't line up with their view of how the universe
should work. This is akin to standing on the deck of the Titanic and yelling "I
told you we needed more lifeboats!" instead of finding a piece of wood to float
on.
CGN = RFC6264. I'm not sure why it passed IETF LC or IESG vote given the
resistance this draft is getting, but if you don't like it because it breaks
the internet and extends IPv4, then write the draft to make that historic,
along with NAT44, and any other astoundingly bad ideas that IETF has had for
extending IPv4 beyond its original design life. For that matter, write a draft
to make IPv4 historic. I (along with several authors of this draft) am already
trying to update IETF's official position (for some value of official) from
"version agnostic" to "IPv6 is a requirement", and I'd welcome the help.
But stop conflating a practical solution to a practical problem with whether
IPv6 is deployed or whether CGN (and IPv4) is fundamentally bad.
I've been conflicted on this draft all along. I hate the idea for all the same
reasons everyone else does, and I'm just as unhappy that IPv6 isn't further
along. But I see few good alternatives, and I'm not sure it's worth cutting off
my nose to spite my face, so I chose to stop opposing it. You may be correct,
that RFC1918 would work in the majority of cases, and that people are likely to
use this new space for off-label uses the first time they run into an RFC1918
conflict. So what? Is squatting on allocated space really the better idea? What
about people who legitimately *can't* use RFC1918 space? Are they just SOL, or
are you convinced that they're lying? As far as I can tell, your argument
regarding this being used as RFC1918 annex is - "people are idiots and they'll
do things we tell them not to, despite RFCxxxx that says 'Very Bad Things will
happen if you do x', so we shouldn't even give them the option." The problem
with idiot-proofing is that there are always better
idiots.
Wes George
CF
1 http://www.timewarnercable.com/SoCal/support/IPv6.html
2 http://www.comcast6.net/
3
http://ww2.cox.com/residential/idaho/support/internet/article.cox?articleId=%7B0bced860-9666-11df-6baf-000000000000%7D
4
http://www.att.com/esupport/article.jsp?sid=KB409112&cv=812&_requestid=723971#fbid=V_Bys5OCNCJ
This E-mail and any of its attachments may contain Time Warner Cable
proprietary information, which is privileged, confidential, or subject to
copyright belonging to Time Warner Cable. This E-mail is intended solely for
the use of the individual or entity to which it is addressed. If you are not
the intended recipient of this E-mail, you are hereby notified that any
dissemination, distribution, copying, or action taken in relation to the
contents of and attachments to this E-mail is strictly prohibited and may be
unlawful. If you have received this E-mail in error, please notify the sender
immediately and permanently delete the original and any copy of this E-mail and
any printout.
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf