[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Comment on draft-lee-v4v6tran-problem-00 and draft-carpenter-v4v6tran-framework-00//Re: [v4tov6transition] draft-arkko-ipv6-transition-guidelines WGLC
Dear Chris, Dan, Gert et al,
Thank you for all your comments. I started also commenting on others' email,
couldn't remember from whom.
I'm not an operator. I spoke just like an observer, might not be a good
observer. I might be wrong.
It's time to look at the two drafts, and comment on them.
http://tools.ietf.org/html/draft-lee-v4v6tran-problem-00
http://tools.ietf.org/html/draft-carpenter-v4v6tran-framework-00
Thanks, good weekend. Hope typhoon does not impact much on the east coast of
the States and Asia.
B. R.
Tina
http://tinatsou.weebly.com
----- Original Message -----
From: "Christopher Morrow" <morrowc.lists@gmail.com>
To: "Tina TSOU" <tena@huawei.com>
Cc: "Gert Doering" <gert@space.net>; "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: Friday, September 03, 2010 1:43 PM
Subject: Re: [v4tov6transition] draft-arkko-ipv6-transition-guidelines WGLC
On Fri, Sep 3, 2010 at 12:02 AM, Tina TSOU <tena@huawei.com> wrote:
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.)
these are all well known problems that have been here for ... since
IPng happened. You make a new protocol that's not compatable on the
wire with the old one and, you'll surely have an interesting time
transitioning. Deprecate the only feasible transition technology and
... well you have what we have today.
I'm not sure I see, aside from a few well documented straightforward
cases, why there needs to be a lot more added to the set of ways we
can provide v6 to the existing v4 user base. I'm not sure how much
more we have to deliberate the 'if you only have ipv6 you can't see
anything on the current internet" discussion either.
If an operator deploys native IPv6 in its network first and deploys NAT64,
many applications will not be served till these applications support IPv6
or
across NAT64, this will lead the losing of subscribers for operators.
sure, this also isn't huge news. Folks will only deploy when they are
ready and when there is a financial incentive for them to do the work
required... UNLESS they see that there is a coming end-time and they
MUST be prepared for it, and that preparing NOW when you can do it
leisurely is far better than doing it under the gun tomorrow.
(today/tomorrow of course are 5 years ago and last week, but...)
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?
how's it worked out so far?
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.
this didn't come across quite as plainly as you wanted, I suspect...
perhaps you meant:
"A content provider in one locale deploys only ipv4 accessible
services, an ISP in another locale (with perhaps no users of the
content provider's content) deploys native ipv6 (you don't mention if
they already have ipv4, I'll assume you mean 'only ipv6'). The ISP
will lose subscribers since they can't access the content providers
content."
There are quite a few problems with your supposition, mainly that
since the users on the ipv6 only network weren't users of the content
there's no reason for them to even know that it exists.
I think you really mean something like: All consumer ISP networks
today should be able to support ipv6 to their subscribers in one form
or another. There will be cost (capex or opex) for them to deploy,
but... that cost should be shown to be lower than the lost revenues
due to the eventual exodus of their customers when the ipv6 content
providers reign.
I still don't see the above as a problem since eventually (in a
crunch) the ISP will deploy ipv6 because "Some Important Service" to
their customers will be inaccessible. The only option will be to
deploy ipv6 to these customers... It will suddenly be obvious that the
cost to deploy is lower than the cost to NOT deploy (lost subs). This
problem is self-correcting, I think.
Additionally, if the content provider starts losing customers, and
those customers make up a noticeable portion of their revenue stream
they will deploy v6 accessible versions of the content... content
providers today are doing this very thing, actually.
Again, I think it behooves us to speak about 'transit' or 'backbone'
ISP networks apart from 'consumer' ISP networks. There are
significantly different challenges in these two arenas. None are
insurmountable, but v6ops can (and has to some extent) document some
deployment "BCP's".
DanWing has said some similar things as well... although it seems to
me that much of the issue here is a 'follow the money' problem, if
there is monetary reason to do ipv6, it gets done. To date, there has
not been a strong enough story to deploy ipv6 from a financial
perspective (looking across 1 or 2 quarters of fiscal reporting),
where you see it being deployed folks have done so either with the
"This will pay out in the long run" (lorenzo for instance, to name a
particular person who used this reasoning) or "we should do this for
our own good, it will cost us something now, but later we'll be all
set when we HAVE to have ipv6 ready."
-Chris
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