I think that although the draft mainly discusses aaaa-whitelisting, it can be
more specific in section 2 on issues impacting content delivery over ipv6.
Perhaps the biggest challenge in the IPv4-to-IPv6 transition is that the two
protocols are not compatible; that is, IPv4-only systems cannot talk directly
to IPv6-only systems. This means no one can turn off IPv4 support until every
last device they want to reach has acquired IPv6 connectivity. Unfortunately,
many existing devices — including PCs running older OSes, as well as older
cable and DSL modems, wireless routers, and other business and consumer
electronic devices—have either limited or no IPv6 support. In other words,
companies will have to support both protocols for years to come, in a long and
bumpy transition period. During that time, there will effectively be two
Internets, an IPv4 one and an IPv6 one, loosely bound together into a hybrid
Internet by various transition technologies.
Challenges of reaching IPv6 users from IPv4 sites
Many types of Web applications rely on an end-to-end connection, where each
device, household, or entity is associated with a single IP address. CGN breaks
this assumption — as it creates a situation where hundreds or thousands of end
users — related only by their network provider — share the same IP address, and
each user’s IP address may change with every new connection. Thus, CGN cripples
functions like geo-location — using the user’s IP address to determine their
location, in order to personalize content or to enforce licensing restrictions,
for example, and abuse mitigation — IP blacklisting or whitelisting, in order
to block spammers, trolls, or other abusive users.
CGN breaks assumptions that many of today’s Web applications rely on. In
particular it affects applications, such as peer-to-peer and VoIP, which rely
in some way on a unique end user IP address. Troubleshooting the issues is
extremely complex and costly, as it can’t be done without the NAT operator’s
help.
In order to reach IPv4 sites, IPv6 end users need to go through a NAT64
gateway. Because there may be only one or two such gateways within a network,
communications may be forced through long, indirect paths. In addition, these
gateways quickly become congestion points within the network, as well as easily
targeted points of failure, further affecting the performance and reliability.
Challenges of reaching IPv6 users from IPv6 sites
Because the IPv6 Internet is still sparsely connected, native IPv6
communications may require longer, less direct routes than their IPv4
counterparts, resulting in slower performance and higher packet loss. This is
particularly troublesome for high throughput or low latency applications such
as online gaming or streaming media. In addition, a significant portion of the
IPv6 Internet currently relies on tunneling traffic over IPv4, creating
additional performance degradation.
So I think that content providers and application providers are no longer
pondering when to enable delivery over IPv6 but are focused on how to manage
this transition in a manner that is cost-effective and efficient in the short
term but takes into account long-term needs and opportunities.
Sent from my iPad
On Feb 2, 2012, at 7:05 PM, "Erik Kline"
<ek(_at_)google(_dot_)com<mailto:ek(_at_)google(_dot_)com>> wrote:
World IPv6 Launch changes the relevance of this document greatly, I
think. Since this would be published after the announcement of World
IPv6 Launch, I think the document should be updated to discuss its own
applicability in a post- World IPv6 Launch Internet.
On 2 February 2012 00:09, The IESG
<iesg-secretary(_at_)ietf(_dot_)org<mailto:iesg-secretary(_at_)ietf(_dot_)org>>
wrote:
The IESG has received a request from the IPv6 Operations WG (v6ops) to
consider the following document:
- 'Considerations for Transitioning Content to IPv6'
<draft-ietf-v6ops-v6-aaaa-whitelisting-implications-08.txt> as an
Informational RFC
The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf(_at_)ietf(_dot_)org<mailto:ietf(_at_)ietf(_dot_)org> mailing lists by
2012-02-15. Exceptionally, comments may be
sent to iesg(_at_)ietf(_dot_)org<mailto:iesg(_at_)ietf(_dot_)org> instead. In
either case, please retain the
beginning of the Subject line to allow automated sorting.
Abstract
This document describes considerations for the transition of end user
content on the Internet to IPv6. While this is tailored to address
end user content, which is typically web-based, many aspects of this
document may be more broadly applicable to the transition to IPv6 of
other applications and services. This document explores the
challenges involved in the transition to IPv6, potential migration
tactics, possible migration phases, and other considerations. The
audience for this document is the Internet community generally,
particularly IPv6 implementers.
The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-v6ops-v6-aaaa-whitelisting-implications/
IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-v6ops-v6-aaaa-whitelisting-implications/
No IPR declarations have been submitted directly on this I-D.
_______________________________________________
v6ops mailing list
v6ops(_at_)ietf(_dot_)org<mailto:v6ops(_at_)ietf(_dot_)org>
https://www.ietf.org/mailman/listinfo/v6ops
_______________________________________________
v6ops mailing list
v6ops(_at_)ietf(_dot_)org<mailto:v6ops(_at_)ietf(_dot_)org>
https://www.ietf.org/mailman/listinfo/v6ops
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf