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

From: "George, Wesley" <[email-masked]>
Date: Mon, 22 Aug 2011 13:11:32 -0400

From: SM <[email-masked]>
To: [email-masked]
Reply-to: [email-masked]
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 naught.

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.

---

From: SM <[email-masked]>
Date: Mon, 22 Aug 2011 13:47:42 -0700

Hi George,
At 10:11 22-08-2011, George, Wesley wrote:
>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.

Ok.

>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

 From where I sit I have not seen credible plans from residential 
broadband providers to have IPv6 enabled.  Please note that my 
comment should not be read as a disagreement about what you said 
about US residential providers.

>  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 naught.

I don't think that it should be a serial process.  Although my 
earlier quote might not have emphasized it, doing this serially is 
like having a chicken and egg discussion.  I am not saying "don't 
bother".  You are building the "last mile" and you see a problem 
which occurs beyond the DSLAM/BRAS.  You don't want to wait for the 
next technology refresh cycle.  I agree with you on that.  I 
mentioned that the last mile can also be a problem (it may not be one 
from where you stand).

>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.

Thanks for the explanation.  For what it is worth, I made a similar 
comment about another draft ( 
http://www.ietf.org/mail-archive/web/ietf/current/msg68520.html 
).  Based on what you said above, there wasn't any desire for 
corporate name-dropping.

>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.

As I mentioned in a previous message, the draft comes out as a 
statement about "IPv6-required" instead of a Proposed 
Standard.  Irrespective of whether the document is a PS or BCP, it is 
important the ideas are clearly expressed.  Brian mentioned that the 
document can be fixed with some wordsmithing.  I made an attempt at 
"send text" ( 
http://www.ietf.org/mail-archive/web/ietf/current/msg68534.html ).  I 
came to the conclusion that the document needs more work before being 
ready for a Last Call.  The comment about informative v/s normative 
references ( 
http://www.ietf.org/mail-archive/web/ietf/current/msg68535.html ) was 
not made from a process perspective.  You can label it as editorial 
and I am not going to dispute the decision.  In the context of the 
document, I'll just read it as draft-ietf-6man-node-req-bis (or the 
existing RFC) can be overlooked.

I would not support the publication as the draft as Informational in 
its current form as it attempts to update several Standards Track 
RFCs.  You could try to get away with it by dropping the "Updates".

I agree with Tom Petch that the document comes out as utterly bizarre 
( http://www.ietf.org/mail-archive/web/ietf/current/msg68536.html 
).  I would not say that it seriously damages the Internet.  The 
document does not come out as a convincing argument to implement IPv6.

At 12:44 22-08-2011, George, Wesley wrote:
>WEG] I think that you have a point that this update is a little weak 
>in its current form. I don't have a problem with some clarifying 
>text, but I think that the problem with the above is that you now 
>get into situations where IPv4 internet connectivity by that 
>definition is no longer possible due to a lack of available 
>addresses. In other words, each of the defined items in the existing 
>section 2 are applicable to IPv4 and IPv6 separately. So perhaps it 
>needs to discuss the fact that there are now multiple permutations 
>of the items in section 2, e.g. where the host has IPv6 internet

The multiple permutations ends up injecting complexity and can end up 
making the BCP "inaccessible".  As much as it is part of reality, it 
can end up being an hurdle in getting a wider audience to digest that.

>  connectivity, but really only has client/no public IPv4 connectivity.
>Then we're into value-judgment-land regarding whether full IPv6 
>connectivity coupled with NAT for IPv4 is considered "full internet 
>connectivity" or if only true dual-stack is acceptable for that 
>definition, etc.

Yes.

>WEG] I think that this definition is going to be problematic. There 
>are plenty of other

Yes.

>  documents which already define IPv6 connectivity, and we are 
> unlikely to reach consensus on any definition that includes a 
> prefix size, but I'd be interested in opinions on the rest of it 
> assuming that the prefix size recommendation is dropped.

I would avoid a discussion about prefix size.  However, it is going 
to end up being a problem in the long run if the ISP allocates a 
single IPv6 address to the consumer.  There is a little gem in RFC 
1122 which could be used as a workaround for the prefix size discussion.

Regards,
-sm