ietf
[Top] [All Lists]

Re: Last Call: <draft-ietf-intarea-ipv6-required-01.txt> (IPv6 Support Required for all IP-capable nodes) to Proposed Standard

2011-08-22 12:12:16
From: SM <sm(_at_)resistor(_dot_)net>
To: ietf(_at_)ietf(_dot_)org
Reply-to: sm(_at_)resistor(_dot_)net
Subject: Re: Last Call: <draft-ietf-intarea-ipv6-required-01.txt> (IPv6 Support 
Required for all IP-capable nodes) to Proposed Standard
X-RSN: 1/0/933/10475/58528

From Section 1:

"However, due to the success of the Internet in finding new and
innovative uses for IP networking, billions of hosts are now
connected via the Internet and requiring unique addressing."

That sounds like the requirement for unique addressing is a
problem. The draft mentions that demand has lead to the exhaustion
of the IANA global pool of unique IPv4 addresses. Should the above
be read as "requiring unique IPv4 addressing"?
_________
WEG] You're reading too much into this. It's a statement of the current 
situation, not a discussion about whether unique addresses are good or bad.
There are billions of hosts on the internet, a lot of them require unique 
addresses. End of line. No value judgment.
A requirement for unique addresses is not a problem. However, it *is* a problem 
if all you have to address those nodes  with is an exhausted IANA IPv4 free 
pool, which leaves us needing IPv6 to meet the demand for those unique 
addresses.


"However, the IPv6 deployment necessary to reduce reliance on IPv4 has
been hampered by a lack of ubiquitous hardware and software support
throughout the industry."

Quoting RFC 5218:

'The lack of a value chain can make it difficult for a new protocol to
progress from implementation to deployment to use. While the term
"chicken-and-egg" problem is sometimes used to describe the lack of a
value chain, the lack of implementation, deployment, or use is not
the cause of failure, it is merely a symptom.'

The assertion that the problem is a lack of ubiquitous hardware and
software support throughout the industry is incorrect. It is the
lack of the value chain that has hampered IPv6 deployment.
_________
WEG] I find it strange that you'd a) quote from a section of 5218 on protocol 
failure in a discussion about IPv6, which doesn't meet any of the criteria 
listed earlier in that section and b) invoke a value chain here as a reason to 
invalidate the above statement. Whether it's a cause or a symptom, the above 
quoted issue still exists as a barrier, and ultimately the lack of that support 
breaks that chain - no killer app making it attractive to move to IPv6 due to 
concerns that the target audience wouldn't be able to reach it, due to a lack 
of last mile support for IPv6, for example. I think this argument is mostly 
based on your following assertion, so I'll respond in more detail below.


Many vendors in the consumer space such as Internet Service Providers
still view IPv6 support as optional. They are still pushing the
"Internet" as an IPv4 medium only.
<snip>
Even if the average home gets an IPv6-capable device, that would not
get it any further due to last-mile issues.

___________
WEG] As an operator (consumer ISP) who happens to spend a lot of time talking 
about IPv6 deployments with other operators, I disagree with this assertion. 
This is exactly the problem we're trying to solve. From where I sit, I see 
credible plans from a number of US residential broadband providers to have IPv6 
enabled on a large portion of their footprint within the next 12-18 months. 
There is no reason why IPv6 support in ancillary devices needs to be a serial 
process dependent on completion of that last mile deployment. You're saying, 
"don't bother, there's no IPv6 support on the last mile." We're saying "we're 
building the last mile, and we'd like to not have to wait for the next 
technology refresh cycle before the IPv6 support we build has any devices to 
use it." Understand that in many cases, even if the providers turned on IPv6 
support in the CMTS or DSLAM/BRAS tomorrow, if the customer supplies their own 
modem or wireless gateway, if it doesn't do v6, it's also all for n
 aught.

Anyway, let's get to the meat of the draft.
__________
WEG] Brian's already responded to several of these items, so I'll respond 
inline in those messages as necessary.


BTW, this draft has nine pages and four authors. The 162-page draft
I read recently has five authors. "If there is a desire to
demonstrate how many companies are interested in this spec, a simple
acknowledgment section can accomplish the same thing".
___________
WEG] I fail to see the relevance of this other than to impugn the authors 
rather than the ideas in the draft, but since you brought it up, all 4 of the 
listed authors collaborated on the initial text of this draft at the end of 
IETF 79, and have provided material contributions to the text in each 
subsequent revision.


I do not support the publication of this document as a RFC. It
attempts to update old RFCs which are well-written in a confusing
manner. The draft comes out as a statement about "IPv6-required"
instead of a Proposed Standard.
__________
WEG] It would be helpful to know whether you do not support this because of the 
choice to update several RFCs, the choice to make it a proposed standard 
(instead of BCP or informational), or you disagree with the entire thing. This 
will make it easier for the authors to address your concerns adequately.

Thanks

Wes George



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

<Prev in Thread] Current Thread [Next in Thread>