The IESG | 1 Feb 16:09 2012
Picon

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


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@... mailing lists by 2012-02-15. Exceptionally, comments may be
sent to iesg@... 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/
(Continue reading)

Brian E Carpenter | 1 Feb 21:32 2012
Picon

Re: [Fwd: I-D Action: draft-carpenter-v6ops-icp-guidance-02.txt]

> I'm still on the fence about the draft status - I'm no longer opposed to adopting it as a WG item if that's the
general consensus, but I think it would be ok as an individual draft as well.

May I ask the WG chairs to put that question to the WG? We can
of course make an update with the various comments received
recently, either as a WG draft or for individual submission,
as long as we get guidance by the end of this month.

Also do people want to use meeting time for this topic, or can
we handle it on the list?

Regards
   Brian Carpenter

On 2012-01-12 03:53, George, Wes wrote:
> Brian - Thanks for addressing my comments in this version.
> 
> I'm still on the fence about the draft status - I'm no longer opposed to adopting it as a WG item if that's the
general consensus, but I think it would be ok as an individual draft as well.
> 
> A couple of additional comments from this read.
> 
> In your introduction, You mention the "first do no harm" concept - don't make IPv4 worse by deploying IPv6
(with the implication that some IPv6 transition technologies might have that effect).
> I think you might be able to take that a step further and note that IPv4 *extension* technologies (CGN, etc)
on the client side may also have that effect, meaning that this is one of the reasons why ubiquitous IPv6
support (perhaps "on by default" even) is critical for ASP/ICP - it increases the chances that their
service transits to an end customer largely unmolested by IPv4 extension technologies.
> 
> Additionally, it might be worth mentioning the connection between the ICP/ASP and their partners and
(Continue reading)

Fernando Gont | 2 Feb 01:44 2012

RA-Guard: Advice on the implementation (feedback requested)

Folks,

We have just published a revision of our I-D "Implementation Advice for
IPv6 Router Advertisement Guard (RA-Guard)"
<http://tools.ietf.org/id/draft-gont-v6ops-ra-guard-implementation-01.txt>.

In essence, this is the problem statement, and what this I-D is about:

* RA-Guard is essential to have feature parity with IPv4.

* Most (all?) existing RA-Guard implementations can be trivially evaded:
if the attacker includes extension headers in his packets, the RA-Guard
devices fail to identify the Router Advertisement messages. -- For
instance, THC's "IPv6 attack suite" (<http://www.thc.org/thc-ipv6/>)
contains tools that can evade RA-Guard as indicated.

* The I-D discusses this problem, and provides advice on how to
implement RA-Guard, such that the aforementioned vulnerabilities are
eliminated, we have an effective RA-Guard device, and hence
feature-parity with IPv4.

We'd like feedback on this I-D, including high-level comments on whether
you support the proposal in this I-D.

Thanks!

Best regards,
--

-- 
Fernando Gont
SI6 Networks
(Continue reading)

internet-drafts | 2 Feb 02:40 2012
Picon

I-D Action: draft-ietf-v6ops-wireline-incremental-ipv6-01.txt


A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item
of the IPv6 Operations Working Group of the IETF.

	Title           : Wireline Incremental IPv6
	Author(s)       : Victor Kuarsingh
                          Lee Howard
	Filename        : draft-ietf-v6ops-wireline-incremental-ipv6-01.txt
	Pages           : 25
	Date            : 2012-02-01

   Operators worldwide are in various stages of preparing for, or
   deploying IPv6 into their networks.  The operators often face
   difficult challenges related to both IPv6 introduction along with
   those related to IPv4 run out.  Operators will need to meet the
   simultaneous needs of IPv6 connectivity and continue support for IPv4
   connectivity for legacy devices with a depleting supply of IPv4
   addresses.  The IPv6 transition will take most networks from an IPv4-
   only environment to an IPv6 focused environment with long period of
   dual stack operation varying by operator.  This document helps
   provide a framework for Wireline providers who are faced with the
   challenges of introducing IPv6 along meeting the legacy needs of IPv4
   connectivity utilizing well defined and commercially available IPv6
   transition technologies.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-v6ops-wireline-incremental-ipv6-01.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/
(Continue reading)

Victor Kuarsingh | 2 Feb 02:52 2012
Picon

Re: I-D Action: draft-ietf-v6ops-wireline-incremental-ipv6-01.txt

V6OPS WG,

An update has been posted which rolled up comments made to date.  This
version reflects the following:

- Focus on IPv6 enablement and deployment progression
- Tone around IPv4 has been muted somewhat in that it's noted, but again -
focus on IPv6
- Less focus on text around "IPv6 code immaturity" as it did not sit well
with many - focus here is on operational experience in IPv6 and lack of
maturity in operation networks

Points still in debate and/or require more discussion

- Test describing and including technologies outside of Dual Stack,
DS-Lite and 6RD.  Some have noted that inclusion of NAT46 (with relation
to NAT64) should be included.  Example would be
draft-mawatari-v6ops-464xlat-00.
- Regarding the above, we had originally intended to only include a set of
technologies which have commercial availability.  Would discussion of the
above be worth describing in document? (as actual text and/or just minor
reference?)

I will be looking for comments which support (or challenge) updates on the
recent -01 post, and the matter of including NAT46/NAT464 (as referenced
above).

Future update will include more information in the considerations portion
of the document as I have much input from folks who have deployment
experience information for some areas.
(Continue reading)

Tina TSOU | 2 Feb 04:01 2012

Re: RA-Guard: Advice on the implementation (feedback requested)

It is useful for my current deployment.
I like this document in general, will discuss more details with Fernando.

Sent from my iPhone

On Feb 1, 2012, at 4:45 PM, "Fernando Gont" <fgont@...> wrote:

> Folks,
> 
> We have just published a revision of our I-D "Implementation Advice for
> IPv6 Router Advertisement Guard (RA-Guard)"
> <http://tools.ietf.org/id/draft-gont-v6ops-ra-guard-implementation-01.txt>.
> 
> In essence, this is the problem statement, and what this I-D is about:
> 
> * RA-Guard is essential to have feature parity with IPv4.
> 
> * Most (all?) existing RA-Guard implementations can be trivially evaded:
> if the attacker includes extension headers in his packets, the RA-Guard
> devices fail to identify the Router Advertisement messages. -- For
> instance, THC's "IPv6 attack suite" (<http://www.thc.org/thc-ipv6/>)
> contains tools that can evade RA-Guard as indicated.
> 
> * The I-D discusses this problem, and provides advice on how to
> implement RA-Guard, such that the aforementioned vulnerabilities are
> eliminated, we have an effective RA-Guard device, and hence
> feature-parity with IPv4.
> 
> We'd like feedback on this I-D, including high-level comments on whether
> you support the proposal in this I-D.
(Continue reading)

Erik Kline | 3 Feb 03:57 2012
Picon

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

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.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.org mailing lists by 2012-02-15. Exceptionally, comments may be
> sent to iesg <at> ietf.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,
(Continue reading)

Tina TSOU | 3 Feb 05:56 2012

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

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" <ek-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org> 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-EgrivxUAwEY@public.gmane.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.org mailing lists by 2012-02-15. Exceptionally, comments may be
sent to iesg-EgrivxUAwEY@public.gmane.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.org
https://www.ietf.org/mailman/listinfo/v6ops
_______________________________________________
v6ops mailing list
v6ops-EgrivxUAwEY@public.gmane.org
https://www.ietf.org/mailman/listinfo/v6ops
_______________________________________________
v6ops mailing list
v6ops@...
https://www.ietf.org/mailman/listinfo/v6ops
Fred Baker | 3 Feb 17:35 2012
Picon

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


On Feb 2, 2012, at 6:57 PM, Erik Kline 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.

With respect...

The document was originally discussed in v6ops, and you chose to not comment. It went through last call
there in January 2011 and was sent to the IESG. IESG review took until April, and an updated draft was posted
at the end of May 2011. At IETF 81 (Quebec City) we were able to have you, the author, and some others discuss
it. The IESG again decided it needed a revised draft, and that draft - in large part, a rewrite - arrived in
October. v6ops had a second WGLC, in which you again declined to comment, although you may have seen
Lorenzo's comments, which were picked up in a November version of the draft. Ralph and Jari finally
cleared their "discuss" ballots a couple of weeks ago, and we are having a second IETF last call.

I'd like to understand your objective here. I know that you don't care for the draft, and at least at one point
took it as a somewhat-personal attack. Is your objective to prevent the draft's publication entirely, or
do you think that there is value in publishing it given a productive response to this comment? At what point
are you willing to either participate in the public dialog or choose to not comment at all?

> On 2 February 2012 00:09, The IESG <iesg-secretary <at> ietf.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.org mailing lists by 2012-02-15. Exceptionally, comments may be
>> sent to iesg <at> ietf.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.org
>> https://www.ietf.org/mailman/listinfo/v6ops
> _______________________________________________
> Ietf mailing list
> Ietf <at> ietf.org
> https://www.ietf.org/mailman/listinfo/ietf
Cameron Byrne | 3 Feb 21:17 2012
Picon

464XLAT Trial Deployment Report

Hi,

I have recently concluded a simple initial experimental deployment
464XLAT [1] on the T-Mobile USA IPv6-only network [2] using an Android
Nexus S phone.

The high level summary is that a sample of the top ~200 free Android
apps that use network services (ie not a calculator with no ads),
~85+% work on an IPv6-only DNS64/NAT64 mobile UMTS network using a
stock Android 4.0 (ICS) on a stock Nexus S phone.

When using custom 464XLAT code [3] on Android, 100% of  the ~15% of
apps that failed in the initial test now work. The 464XLAT CLAT code
on the Android allowed for IPv4 socket bindings and IPv4 referrals to
proceed on the IPv6-only network by doing RFC 6145 protocol
translation locally on the phone.  The tested application sample set
is at [4].

I believe this simple experiment running real code on a real network
shows the value of draft-mawatari-v6ops-464xlat for enabling network
operators to embrace IPv6-only networks as the going forward future of
access networks. 464XLAT, like NAT64/DNS64, is a bridge technology
that makes IPv6 deployment feasible without harming the customer
experience.  464XLAT, like DNS64/NAT64, is not used when apps and
service are IPv6 native.  Thus, as IPv6 deployment progresses across
the Internet, the 464XLAT as well as the NAT64/DNS64 fall out of
service.

I hope the problem statement that draft-mawatari-v6ops-464xlat
addresses is clear as it applies to this trial: 15% of applications
for this sample in the Android market require IPv4 addresses.

And, i hope the proposed applicability and usefulness of 464XLAT is
clear as it applies to this trial:  464XLAT allows for 100%
functionality of all applications in the sample and is only used when
IPv4 sockets are required (IPv4 literals, IPv4 referrals, ...).

I do have 2 requests of  the group.  First, please read and comment on
draft-mawatari-v6ops-464xlat [1].  We are looking for working group
adoption of this draft since we believe it will broadly support the
ability of network operators to move forward with IPv6 in the near
term (code is running, network is deployed).  Right now, some networks
feel they are held back by "IPv6 spoilers" like Skype that require
IPv4.  But now, even Skype works on IPv6 with the help of 464XLAT :) .
 I would like to emphasize that Skype and others MUST still deploy and
support IPv6.  That said, we cannot let their failure hold the rest of
us back.  Second, the IPv4 exhaustion problem is real and now, the
urgency must be high.  Please also comment to the folks at Android
that this code should be brought into the Android main line
distribution because network operators (v6ops) need it to continue
growing the Internet and restoring the end-to-end principle [5].

Thanks,

Cameron

ps.  Big thanks to Dan Drown for open-sourcing his CLAT code!

[1] http://tools.ietf.org/html/draft-mawatari-v6ops-464xlat

[2] http://goo.gl/HGmsy or https://sites.google.com/site/tmoipv6/lg-mytouch

[3]  http://code.google.com/p/android-clat/ and
http://dan.drown.org/android/clat/  and

[4] http://goo.gl/z3j3q  or
https://docs.google.com/spreadsheet/ccc?key=0AnVbRg3DotzFdGVwZWlWeG5wXzVMcG5qczZEZloxWGc

[5]  http://goo.gl/W55YQ or http
://www.androidpolice.com/2012/01/29/t-mobile-usa-testing-ipv6-on-select-devices-here-is-what-it-all-means-and-yes-no-more-nat/
_______________________________________________
v6ops mailing list
v6ops@...
https://www.ietf.org/mailman/listinfo/v6ops


Gmane