Re: [BEHAVE] [v4tov6transition] draft-arkko-ipv6-transition-guidelines WGLC

[Joel Jaeggli <joelja@bogus.com>]

 Just a few observations without the wg-cochair hat on.

On 8/30/10 8:12 PM, Tina TSOU wrote:
> Technically, these drafts are well written and very useful. It is really
> appreciated. Fred, would you explicitly point out the answers of the
> following questions from these drafts? Thanks.
> 
> 1) There are some applications, server, clients don’t support IPv6.
> These situations will be met regardless of stateful or stateless NAT64.
> No one has right to request these applications must support IPv6
> (Monocrat may have), but these applications have existed and been used
> for many people. In the migration to IPv6, if these users can’t use
> these service and applications, it will result in the losing of
> subscribers for operators, unless all the operators of the world support
> IPv6 at the same moment.

Legacy ipv4 only apps aren't going to support v6 period, it has nothing
to do with when operators support or don't support ipv6. legacy
applications do not become new again. see (3) for dicussion of rights.

> 2) Some applications have supported NAT44 traversal maturely, but in a
> long period of time in the future these applications would unlikely to
> support NAT64’s traversal. If adopting NAT64, these applications would
> be impacted. No one has the right to request these applications must
> support NAT64 traversal, so after the usage of NAT64, these application
> will conk out inevitably. Both stateful and stateless NAT64 have the
> same issues.

An application that supports nat64 traversal is fact a native ipv6
application that isn't dependent on layer violations for it's signaling
of among other things ip address port numbers or security bindings. You
sort of characterized this in (3).

> 3) Some applications contain the senders’ IP address in the packet
> payload, even in the encrypted packet case. These will have problems
> when using NAT64. Since these applications are existing applications, no
> one has right to requesting stop using these applications. These issues
> will be encountered when using NAT64 (both stateful and stateless ones
> have the same problem).

The word "right" is a challenge to me here. Supporting a protocol on a
network is a business decision(for example, when do I add ipv6 aaaa
records to a service in my network). It is is in the interests of
internet service providers to induce as little deliberate breakage into
the network as possible. As a content and services provider (which is
what I do) if I don't adhere to this axiom I get to look for a new job.

> 4) No one has the right to force all the UE to support IPV6, therefore
> from the technology evolution point of view, we don't have to consider
> IPV4 only user actively visits IPv6 only service, but in the actual use
> people have to consider it, otherwise it may result in the subscriber
> losing. Yes, it is not NAT64.

There is going to be a time where ipv4 only users cannot access a
resource because it only accessible via v6, in superficial cases this
happens all the time. It is in the interests of most if perhaps not all
network operators, application vendors and end users, to push the time
in which that occurs routinely, beyond the window in which ipv6
deployment largely occurs. That said it seems like that workarounds
associated with ipv4 support post-runout will result in a gradually less
usable ipv4 network, which is if anything and incentive against holding
out to the bitter end.

> 5) For some P2P application, after using NAT64, IPv4 only peer is not
> able to actively scan the IPv6 only peer; some P2P applications don’t
> consider NAT64 traversal for the time being.

p2p applications have a built-in assumption of the existence of usable
endpoint identifiers. To the extent that ipv4 identifiers become
progressively less usable, p2p applications will prefer ipv6, that will
require upgrade or substitution.

> Again, these drafts are very practical drafts, any way.

It is useful to understand what on a v6 native host is not going to work
well through a 6to4 gateway. It is not so useful to have an
existence-proof for problems with ipv4 only applications, given that we
have ipv4-only-hosts to support into the immediately forseeable future.
The assumption that I make with those devices be they embedded systems,
pc's, mobile phones, etc, Is that I have the luxury of zero stack change.

> B. R.
> Tina
> http://tinatsou.weebly.com/index.html
> 
> ----- Original Message ----- From: "YangGL" <iamyanggl@gmail.com>
> To: "'Fred Baker'" <fred@cisco.com>
> Cc: "'Behave WG'" <behave@ietf.org>; "'Kurt Erik Lindqvist'"
> <kurtis@kurtis.pp.se>; "'IPv6 v6ops'" <v6ops@ops.ietf.org>;
> <v4tov6transition@ietf.org>
> Sent: Tuesday, August 31, 2010 10:27 AM
> Subject: Re: [v4tov6transition] draft-arkko-ipv6-transition-guidelines WGLC
> 
> 
>> Hi Fred,
>> You are really the dictionary of IPv6! Your mail always make me feel
>> difficult to answer, too many references to read, give me some time, I
>> will
>> come back after reading those documents mentioned in your mail.
>>
>>
>> Best regards,
>> Yang Guoliang
>>
>>
>> </chair> <!-- v6ops -->
>> <author> <!-- draft-ietf-behave-v6v4-xlate -->
>>
>> May I ask a question?
>>
>> When you say you tested it with NAT64, what did you test with?
>>
>> There are two modes for translation between IPv4 and IPv6. The stateful
>> mode, described in draft-ietf-behave-v6v4-xlate-stateful, is essentially
>> identical in function to IPv4/IPv4 NAT, and allows IPv6 systems to
>> connect
>> to IPv4 systems but not the reverse. The stateless mode, described in
>> draft-ietf-behave-v6v4-xlate, allows connections to be initiated in
>> either
>> direction. The downside of the stateless mode is that it requires a
>> direct
>> mapping between an IPv4 and an IPv6 address. The are two parts of a
>> common
>> framework, use the same addressing plan, and the same DNS extension.
>>
>> Are you running both modes, or only the stateful mode? If you are only
>> running the stateful mode, that what you're reporting is what we have
>> been
>> saying for some time it will behave like.
>>
>> http://datatracker.ietf.org/doc/draft-ietf-behave-address-format
>> http://tools.ietf.org/html/draft-ietf-behave-address-format
>>  "IPv6 Addressing of IPv4/IPv6 Translators", Congxiao Bao, Christian
>>  Huitema, Marcelo Bagnulo, Mohammed Boucadair, Xing Li, 15-Aug-10,
>>  <draft-ietf-behave-address-format-10.txt>
>>
>> http://datatracker.ietf.org/doc/draft-ietf-behave-dns64
>> http://tools.ietf.org/html/draft-ietf-behave-dns64
>>  "DNS64: DNS extensions for Network Address Translation from IPv6 Clients
>>  to IPv4 Servers", Marcelo Bagnulo, Andrew Sullivan, Philip Matthews,
>>  Iljitsch van Beijnum, 5-Jul-10, <draft-ietf-behave-dns64-10.txt>
>>
>> http://datatracker.ietf.org/doc/draft-ietf-behave-v6v4-framework
>> http://tools.ietf.org/html/draft-ietf-behave-v6v4-framework
>>  "Framework for IPv4/IPv6 Translation", Fred Baker, Xing Li, Congxiao
>>  Bao, Kevin Yin, 17-Aug-10, <draft-ietf-behave-v6v4-framework-10.txt>
>>
>> http://datatracker.ietf.org/doc/draft-ietf-behave-v6v4-xlate
>> http://tools.ietf.org/html/draft-ietf-behave-v6v4-xlate
>>  "IP/ICMP Translation Algorithm", Xing Li, Congxiao Bao, Fred Baker,
>>  22-Aug-10, <draft-ietf-behave-v6v4-xlate-22.txt>
>>
>> http://datatracker.ietf.org/doc/draft-ietf-behave-v6v4-xlate-stateful
>> http://tools.ietf.org/html/draft-ietf-behave-v6v4-xlate-stateful
>>  "Stateful NAT64: Network Address and Protocol Translation from IPv6
>>  Clients to IPv4 Servers", Marcelo Bagnulo, Philip Matthews, Iljitsch van
>>  Beijnum, 12-Jul-10, <draft-ietf-behave-v6v4-xlate-stateful-12.txt>
>>
>>
>> On Aug 28, 2010, at 5:40 PM, YangGL wrote:
>>
>>> Tests in my lab have proved that many popular applications cannot
>>> work on
>> IPv6-only network with NAT64, such as IM, P2P, games, and part of
>> video. WEB
>> and part of mail (Outlook and Outlook express) are the only
>> applications we
>> can find working properly with NAT64. But there are more than 50%
>> traffic is
>> P2P, WEB traffic is less than 20% on CT’s network. I think it is not a
>> good
>> news to NAT64.
>>> Tests also prove that almost all of popular applications on Internet can
>> work on IPv4-only network with single level and double level NAT44,
>> such as
>> WEB, mail, IM, P2P, games, video and etc.
>>> NAT64 and NAT44 are similar in theory. But what make the difference of
>> application support? I think it should be timing. NAT44 appears ten years
>> ago. There are a few applications on internet at that time. Subsequent
>> applications, such as IM, P2P, were designed to work with NAT44. NAT64
>> come
>> after this popular applications, situation is totally different. If
>> NAT64 is
>> deployed on commercial network now, CT’s network traffic will cut down
>> 70%
>> immediately, and most applications will release a new version for
>> IPv6-only
>> or NAT64 in the next one year. But it is not a good idea to providers.
>>>
>>> Best regards,
>>> Yang Guoliang
>>>
>>> 发件人: v4tov6transition-bounces@ietf.org
>> [mailto:v4tov6transition-bounces@ietf.org] 代表 Yiu L. Lee
>>> 发送时间: 2010年8月25日 22:05
>>> 收件人: huang cancan
>>> 抄送: Kurt Erik Lindqvist; IPv6 v6ops; v4tov6transition@ietf.org
>>> 主题: Re: [v4tov6transition] draft-arkko-ipv6-transition-guidelines WGLC
>>>
>>> From user’s perspective, do they care IPv4 or IPv6? Most don’t. For
>> example: a casual web user wants to access his/her favorite IPv4-only
>> website. If his web client and PC support IPv6 and on an IPv6-only
>> network
>> with NAT64, the web traffic will go through the NAT once. If his web
>> client
>> and PC support IPv4-only on an IPv4 network with NAT444, the web traffic
>> will go through the NAT twice. In the end, he/she still gets the same
>> content. From this perspective, both experience “could be” very similar.
>>>
>>> However, this use case is rather limited and not applicable to many
>> applications. This is why I said “could be”. Also, both Cameron and I
>> agree that this is easier to implement IPv6-only on mobile network
>> than on
>> fixed network because mobile operators have more control over the devices
>> and apps. IMHO, it will take longer time for fixed network operators to
>> support NAT64 only solution in the network.
>>>
>>>
>>> On 8/25/10 9:41 AM, "huang cancan" <cancanhuang110@gmail.com> wrote:
>>>
>>> well, I mean: why customer experience of IPv4-only + NAT444 could be the
>> same as IPv6-only + NAT64?
>>>
>>> On Wed, Aug 25, 2010 at 9:24 PM, Yiu L. Lee <yiu_lee@cable.comcast.com>
>> wrote:
>>> In order to deploy IPv6-only + NAT64, the client and network must talk
>> IPv6. It also requires DNS64. These requirements are not needed for
>> IPv4-only + NAT444. From the deployment point of view, they are very
>> different technologies.
>>>
>>>
>>>
>>> On 8/25/10 7:13 AM, "huang cancan" <cancanhuang110@gmail.com
>> <http://cancanhuang110@gmail.com> > wrote:
>>>
>>> hi,Yiu:
>>>   As you mentioned below:
>>> > All I am saying is the customer
>>> > experience of IPv4-only + NAT444 could be the same as IPv6-only + >
>>> NAT64,
>> but
>>> > the technologies and plan to offer these service are very different.
>>>
>>>   Do you have any test data to support this conclusion?
>>>
>>> Can-can Huang
>>>
>>>
>>> On Sat, Aug 21, 2010 at 7:37 AM, Yiu L. Lee <yiu_lee@cable.comcast.com
>> <http://yiu_lee@cable.comcast.com> > wrote:
>>>
>>> > Agreed.  The 2x cost is really just the packet core ... which is of
>>> > course a lot of money to double for no tangible benefit ..... talk
>>> > about no business case .... And, still have numbering issues, customer
>>> > experience is the same as IPv4-only + NAT44 and approximately the same
>>> > as IPv6-only + NAT64
>>> >
>>> Life cycle of mobile equipments could be every 2-3 years, but life cycle
>> of
>>> consumer electronics could be 5+ years. Consider many large TVs with
>>> Internet service selling today are still running IPv4-only, fixed line
>>> operators must prepare to support them in foreseeable future.
>>>
>>> That said, I am not saying an operator must build a dual-stack core
>> network,
>>> there are technologies such as DS-lite and Softwire Mesh available to
>>> run
>> a
>>> pure IPv6 core network with dual-stack edge. All I am saying is the
>> customer
>>> experience of IPv4-only + NAT444 could be the same as IPv6-only + NAT64,
>> but
>>> the technologies and plan to offer these service are very different.
>>>
>>>
>>>
>>> _______________________________________________
>>> v4tov6transition mailing list
>>> v4tov6transition@ietf.org <http://v4tov6transition@ietf.org>
>>> https://www.ietf.org/mailman/listinfo/v4tov6transition
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> v4tov6transition mailing list
>>> v4tov6transition@ietf.org
>>> https://www.ietf.org/mailman/listinfo/v4tov6transition
>>
>> _______________________________________________
>> v4tov6transition mailing list
>> v4tov6transition@ietf.org
>> https://www.ietf.org/mailman/listinfo/v4tov6transition
>>
> 
> 
> _______________________________________________
> Behave mailing list
> Behave@ietf.org
> https://www.ietf.org/mailman/listinfo/behave
>