From: SM <sm@xxxxxxxxxxxx> To: ietf@xxxxxxxx Reply-to: sm@xxxxxxxxxxxx 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@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf