[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [v4tov6transition] draft-arkko-ipv6-transition-guidelines WGLC
On Fri, Sep 3, 2010 at 12:02 AM, Tina TSOU <firstname.lastname@example.org> 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
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
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
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."
> B. R.
> ----- Original Message ----- From: "Gert Doering" <email@example.com>
> To: "Tina TSOU" <firstname.lastname@example.org>
> Cc: "'Fred Baker'" <email@example.com>; "YangGL" <firstname.lastname@example.org>;
> <email@example.com>; "'IPv6 v6ops'" <firstname.lastname@example.org>; "'Kurt
> Erik Lindqvist'" <email@example.com>; "'Behave WG'" <firstname.lastname@example.org>
> Sent: Thursday, September 02, 2010 10:32 PM
> Subject: Re: [v4tov6transition] draft-arkko-ipv6-transition-guidelines WGLC
>> 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
>>> NAT64. Since these applications are existing applications, no one has
>>> to requesting stop using these applications.
>>> 4) No one has the right to force all the UE to support IPV6, therefore
>>> the technology evolution point of view, we don't have to consider IPV4
>> 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.
>> Total number of prefixes smaller than registry allocations: 155817
>> SpaceNet AG Vorstand: Sebastian v. Bomhard
>> Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A.
>> D-80807 Muenchen HRB: 136055 (AG Muenchen)
>> Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279