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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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
_______________________________________________
Ietf mailing list
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf


[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]