Re: [v6ops] Last Call: <draft-ietf-v6ops-v6-aaaa-whitelisting-implications-08.txt> (Considerations for Transitioning Content to IPv6) to Informational RFC

[Tina TSOU <[e-mail]>]

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 situa­tion 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 mitiga­tion — 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 perfor­mance 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" <[e-mail]<mailto:[e-mail]>> 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 <[e-mail]<mailto:[e-mail]>> 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
[e-mail]<mailto:[e-mail]> mailing lists by 2012-02-15. Exceptionally, comments may be
sent to [e-mail]<mailto:[e-mail]> 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
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/v6ops
_______________________________________________
v6ops mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/v6ops