On Sep 3, 2010, at 12:35 PM, Dan Wing wrote: -----Original Message----
uote type="cite">From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On
Behalf Of Tina TSOU
Sent: Thursday, September 02, 2010 9:03 PM
To: Gert Doering
Cc: 'Behave WG'; YangGL; 'Fred Baker'; 'IPv6 v6ops';
v4tov6transition@ietf.org
Subject: Re: [BEHAVE] [v4tov6transition] draft-arkko-ipv6-transition-
guidelines WGLC
Hi Gert,
I agree with you that IPv4 only applications/
it
will happen some years later.
Because different operators face a lack of IPv4 addresses not the same
case.
Not all operators support IPv6 at the same time and not all operators
deploy
the same technology in their network when transit to IPv6. So the host
will
be various (IPv4 only, IPv6 only, dual stack) and the time that
applications
support IPv6 or support across NAT64 will not be at the same time. This
why we need so many tunnel/translate technologies for IP version
transition.
(e.g.draft-ietf-softwire-dual-stack-lite, RFC5569, RFC5214,
draft-ietf-behave-v6v4-xlate-stateful, RFC3089, etc.)
If an operator deploys native IPv6 in its network first and deploys
NAT64,
You're saying an operator deploys IPv6-only (and not IPv4). Yes,
that will break applications that require IPv4 -- almost all games,
bittorrent, skype, and many other applications.
many applications will not be served till these applications support
IPv6 or
across NAT64, this will lead the losing of subscribers for operators.
The problem is not solely the fault of NAT64.
No, I didn't say that. NAT64 is wonderful. Rather, the problem is the fault of the application (and oftentimes the underlying host operating system) which cannot support running IPv6-only. Another idealistic solution to solve the problems is that all networks,
applications, host support IPv6 immediately. Then there is no problem
for IP version transition. Is this is possible?
No. For example, an ICP (Internet Content Provider) which is in USA
supports
IPv4 and across NAT44, and its customers are mainly from USA. If the
deploy
native IPv6. Only a few customers of the ICP are subscribers for
operators,
the ICP will not support IPv6 immediately. This will lead to the losing
of
subscribers for this IPv6 operator.
So you're saying the content, being served by that IPv4-only content
provider, is inaccessible via NAT64. Can you explain how that content
is delivered that doesn't work across NAT64? HTTP? IMAP? SMTP?
RTSP?? I am interested in what breaks.
Secondly, if -- as you say -- that content provider is losing customers
(customers which cannot get to their IPv4-only content), the content
provider seems to havea financial in
o that
IPv6-only subscribers can view the content.
-d
B. R.
Tina
http://tinatsou.weebly.com
----- Original Message -----
From: "Gert Doering" <gert@space.net>
To: "Tina TSOU" <tena@huawei.com>
Cc: "'Fred Baker'" <fred@cisco.com>; "YangGL" <iamyanggl@gmail.com>;
v4tov6transition@ietf.org>; "'IPv6 v6ops'" <v6ops@ops.ietf.org>;
"'Kurt
Erik Lindqvist'" <kurtis@kurtis.pp.se>; "'Behave WG'" <behave@ietf.org>
Sent: Thursday, September 02, 2010 10:32 PM
Subject: Re: [v4tov6transition] draft-arkko-ipv6-transition-guidelines
WGLC
Hi,
On Tue, Aug 31, 2010 at 11:12:58AM +0800, Tina T
e> [..]
No one has the right to request these applications must support
NAT64
traversal,
[..]
NAT64. Since these applications are existing applications, no one
has
right
to requesting stop using these applications.
[..]
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
[..]
I'm wonderin
this is going to happen.
In my universe, IPv4 is going to run out, and if there is no more
IPv4,
these applications will either get fixed, or die. Very
straightforward.
gert
--
Total number of prefixes smaller than registry allocations: 155817
SpaceNet AG Vorstand: Sebastian v. Bomhard
Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A.
Grundner-Culemann
D-80807 Muenchen HRB: 136055 (AG Muenchen)
Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279
_______________________________________________
Behave mailing list
Behave@ietf.org
https://www.ietf.org/mailman/listinfo/behave
|