[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [BEHAVE] [v4tov6transition] draft-arkko-ipv6-transition-guidelines WGLC
> -----Original Message-----
> 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/website will run out. But
> 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
> is
> 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. 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
> operators in USA don't deploy IPv6 now, and only one Chinese operator
> 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 incentive to support IPv6 so 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 TSOU wrote:
> > [..]
> >> 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 wondering which parallel universe 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