|
Re: Last Call: <draft-ietf-intarea-ipv6-required-01.txt> (IPv6 Support Required for all IP-capable nodes) to Proposed Standard
2011-08-22 15:50:02
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(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf
|
|