[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [BEHAVE] [v4tov6transition] draft-arkko-ipv6-transition-guidelines WGLC
> -----Original Message-----
> From: Tina TSOU [mailto:tena@huawei.com]
> Sent: Friday, September 03, 2010 3:45 AM
> To: Dan Wing; 'Gert Doering'
> Cc: 'Behave WG'; 'YangGL'; 'Fred Baker'; 'IPv6 v6ops';
> v4tov6transition@ietf.org
> Subject: Re: [BEHAVE] [v4tov6transition] draft-arkko-ipv6-transition-
> guidelines WGLC
>
>
> B. R.
> Tina
> http://tinatsou.weebly.com
> ----- Original Message -----
> From: "Dan Wing" <dwing@cisco.com>
> To: "'Tina TSOU'" <tena@huawei.com>; "'Gert Doering'" <gert@space.net>
> Cc: "'Behave WG'" <behave@ietf.org>; "'YangGL'" <iamyanggl@gmail.com>;
> "'Fred Baker'" <fred@cisco.com>; "'IPv6 v6ops'" <v6ops@ops.ietf.org>;
> <v4tov6transition@ietf.org>
> Sent: Friday, September 03, 2010 12:35 PM
> Subject: 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.
> [Tina:
> Some VPN service (e.g. PPTP VPN).
I'm not an expert on PPTP, but it uses TCP for its control channel
and a modified GRE for the tunnel. TCP will work fine across a
NAT64. The problem is most likely the GRE protocol (protocol 47).
Many residential-class NAT44 devices don't support GRE; those that
do, implement some tricks for handling it. Sometimes those tricks
that work okay on a residential NAT do not work well with a large
NAT (notably, with a lot of subscribers doing GRE, especially to
the same VPN concentrator).
There is no standard for how to get GRE across a NAT44, or NAT64.
To my knowledge there is no public description of how this is done,
but I recall seeing GRE traversal implemented in the Linux
masquerade code.
> Some presence applications (e.g. OICQ) don't work across NAT64 by now
> but work across NAT44 Maturely.
Does OICQ work on an IPv6-only client?
Searching online, I see several things that appear to be 'OICQ'. Can
you provide a specific pointer to the specific code you're testing?
> ]
> >
> > 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.
> [Tina:
> What I said is that the operator which is IPv6 only (provide NAT64 for
> IPv4
> service) may lose subscribers, but not content provider.
>
> If an operator with small number of subscribers directly deploy native
> IPv6
> and NAT64 for migration from IPv4 to IPv6, but other operators in the
> same
> locale deploy dual stack or DS-Lite or other technologies. The contents
> may
> not support IPv6 immediately. Because of the block of some service,
> this IPv6 only operator will lose of subscribers.
Yes, I agree an operator that does not support IPv4 will lose subscribers
that need IPv4.
> I agree that the current IPv4 only contents will support IPv6 (or
> NAT64) in the end. But it is "in the end".
If there is a subscriber need for IPv4, then, yes, subscribers should
be given access to IPv4. However, that can be provided with a tunnel
such as Dual-Stack Lite.
I don't see the problem. What is missing?
-d
> ]
> >
> > -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
> >
> >
> >