Subject: Re: [BEHAVE] Fwd: I-D Action: draft-sun-behave-v4tov6-00.txt

From: xiechf01-Gmail <[email-masked]>
Date: Tue, 30 Jul 2013 17:21:45 +0200

Hi,

      The requirements in draft-sun-behave-v4tov6-00 orginates from the real experience and expectations of our product network.  

      Recently, IPv4 address shortage begin to occour in some data centers, and we guess that this situation will become worse as the days pass.  Since the IPv4 address owned by a given data center is finite, so IPv4 address in their hands will run out soon, it is inevitable that IPv6-only server will apear. Dual-stack services to new ICPs is based on sufficient IPv4 address provisionging, but this is not the future for most IDCs. 

       On the other side, although some operators in the world begin to deploy IPv6 for their broadband users, a great portion of users worldwide will still be IPv4-only in the long future due to many well-known factors,  we can not assume that all the users will become dual-stack in a short period. Right now, IPv6 peneration in most regions is below 10%.

       Combing the 2 factors together, we deem it is necessary to solve 4to6 acess problem during the long transition period.   

Chongfeng

To: "ajs at anvilwalrusden.com" <ajs at anvilwalrusden.com>, "behave at ietf.org" <behave at ietf.org> 
Subject: Re: [BEHAVE] Fwd: I-D Action: draft-sun-behave-v4tov6-00.txt 
From: Branimir Rajtar <Branimir.Rajtar at t.ht.hr> 
Date: Tue, 30 Jul 2013 08:46:19 +0000 
Accept-language: en-US 
Reply-to: Branimir Rajtar <Branimir.Rajtar at t.ht.hr> 

Hi,

Your argumentation says that everybody needs to have IPv6 access and I agree completely that would solve all issues. However, we will not be in that point of time for at least five years. And I think I'm optimistic - by looking at the current IPv6 deployment percentages, it might be much more.

ISPs are not really keen on deploying IPv6, they rather do CGN. NAT46 would be cheaper and would provide a reason for servers which are currently IPv4-only to switch to dual-stack and eventually to IPv6-only.

I think we could discuss this topic for the next couple of weeks (which would be quite difficult since I'm writing from my smartphone) so I suggest to leave the decision on the working group.

BR,
Branimir

-------- Izvorna poruka --------
Åalje: Andrew Sullivan <ajs at anvilwalrusden.com>
Datum:
To: behave at ietf.org
Naslov: Re: [BEHAVE] Fwd: I-D Action: draft-sun-behave-v4tov6-00.txt

Hi,

I'm already violating my usual rules about over-posting, so I'm going
to endeavour to shut up after this.  But there's a subtle but, in my
opinion, mistaken parallelism here, and I want to challenge it.

On Tue, Jul 30, 2013 at 10:55:42AM +0800, Qiong wrote:

> For example, we now have NAT64 and so v6-only client can emerge and talk to
> v4 server. So v6-only clients may be more and more in the future. I see
> nobody argues that if we have NAT64, v4 server may live in v4 forever.
>
> Then for v4-to-v6 scenario, this is the same since it will bring the
> ability to support v6-only server to be reachable by v4-only clients.
> Therefore, v6-only server may emerge because they do not need to worry
> about losing v4 clients. So v6-only server maybe more and more in the
> future. This will promote v6-development, rather than the opposite one.

The key reason to have defined NAT64 was because we had a supply
problem.  If you were a v6-only node, you couldn't reach servers on
the v4 Internet.  But _most_ things were on the v4 Internet.  So NAT64
gave us a way of permitting people to have v6-only connectivity
without paying the cost of losing access to the entire Internet.

The argument above turns this on its head, and says that if you are
standing up a service, you are worried about losing the possible
customers on v4-only networks.  Therefore, you will go dual stack.
Implicitly, if we say, "New v4 service bad," we think it would be
better that the service be v6-only.  So, we should have a mechanism by
which v4-only clients can access the v6 Internet, and this will in
some sense increase v6 use because the service is actually accessed
over v6.

I think the argument is subtle but wrong.  First, it depends on the
premise that there is an interesting population that will
(economically) remain v4-only while v6-only service deployment is in
some sense (likely economically) a reasonable plan.  As I already
argued elsewhere in this thread, that premise needs a lot of
supporting argument, because it seems to me to be false.  Second, it
confuses the goal of IPv6 deployment in the sense of native use with a
supposed goal of merely carrying traffic over v6.  The latter is not
an interesting goal in any sense: if tomorrow we simply encapsulated
all v4 traffic inside v6, I do not think it would be an interesting
advance in v6 deployment.  So I reject the claim that this sort of
4-to-6 NAT is a positive contributor to IPv6 deployment.  The right
message is, "If you want to reach this v6-only service, get a v6
address."  If the service is valuable, the customers will come, since
v6 communications are no longer an enormous big deal.

As for the risk that dual stack everywhere permits v4 to persist: so
what?  If v6 is working everywhere, then the v4 network will gradually
wither away because it is not economical to keep that network
interface active.  (Lee Howard has done interesting analysis in this
area, and his models at least suggest a pretty significant changeover
incentive once a not very large number of services come up on IPv6.)
The goal is not to make the evil, bad, wrong v4 go away, any more than
the goal was in itself to kill X.25 and dance about on its grave
singing hallelujah.  That was just a happy consequence.

> From the long history of IPv6 development, I think it is clear this
> assumption has never hardly existed. If anyone *ought to be able to get a
> v6 address*, we would have reached the v6-world long ago, rather than
> debating how to transit.

Surely not.  V6 deployment has never been impeded by lack of v6
addresses.  As long as v4 was good enough and it was still possible to
get address space for reasonable cost, there was little incentive to
move to a network technology that seemed like it was still under
development.  But we're out of v4 addresses now, the experience is
_not_ good enough, and so one might suppose the incentives have changed.

Best,

A

--
Andrew Sullivan
ajs at anvilwalrusden.com
_______________________________________________
Behave mailing list
Behave at ietf.org
https://www.ietf.org/mailman/listinfo/behave

<HTML><P><FONT face=Arial color=#999999 size=1>

IZJAVA O ODRICANJU ODGOVORNOSTI: SadrÅaj ove poruke i eventualno priloÅenih datoteka je povjerljiv i namijenjen je samo osobama ili subjektima koji su navedeni u adresi. Ukoliko ste primili ovu poruku greÅkom, molimo Vas, obavijestite poÅiljatelja, a poruku i sve njene privitke odmah, bez Äitanja, trajno uklonite s raÄunala. Bilo kakvo prenoÅenje, kopiranje ili distribucija informacija sadrÅanih u poruci treÄim osobama je zabranjeno i moÅe biti zakonski kaÅnjivo. SadrÅaj, stavovi i miÅljenja izneseni u poruci su autorovi i ne predstavljaju nuÅno stavove HT - Hrvatskih telekomunikacija d.d. HT ne prihvaÄa nikakvu odgovornost za eventualnu Åtetu nastalu primitkom ove poruke i priloga sadrÅanih u poruci.

</FONT></P><P><FONT face=Arial color=#999999 size=1>

 DISCLAIMER:The contents of this email as well as any files attached to it are confidential and intended solely for individuals or entities which they are addressed to. If you have received this email message in error, please notify the sender and permanently remove the message and all attached files from the computer. Any disclosure, copying or distribution of all or a part of information contained herein to or by third parties is prohibited and may be unlawful. Please note that any views or opinions presented in this message are solely those of the author and do not necessarily represent the views and opinions of Croatian Telecom Inc. Croatian Telecom Inc. accepts no liability for any potential damage caused by this message and files attached to it.

</FONT></P></HTML>

References: 
[BEHAVE] Fwd: I-D Action: draft-sun-behave-v4tov6-00.txt 
From: Qiong
Re: [BEHAVE] Fwd: I-D Action: draft-sun-behave-v4tov6-00.txt 
From: Liu Dapeng
Re: [BEHAVE] Fwd: I-D Action: draft-sun-behave-v4tov6-00.txt 
From: Qiong
Re: [BEHAVE] Fwd: I-D Action: draft-sun-behave-v4tov6-00.txt 
From: Andrew Sullivan
Re: [BEHAVE] Fwd: I-D Action: draft-sun-behave-v4tov6-00.txt 
From: Simon Perreault
Re: [BEHAVE] Fwd: I-D Action: draft-sun-behave-v4tov6-00.txt 
From: Andrew Sullivan
Re: [BEHAVE] Fwd: I-D Action: draft-sun-behave-v4tov6-00.txt 
From: Qiong
Re: [BEHAVE] Fwd: I-D Action: draft-sun-behave-v4tov6-00.txt 
From: Andrew Sullivan
Prev by Date: Re: [BEHAVE] draft-meng-behave-napgt can be met by PCP port set 
Next by Date: Re: [BEHAVE] draft-meng-behave-napgt can be met by PCP port set 
Previous by thread: Re: [BEHAVE] Fwd: I-D Action: draft-sun-behave-v4tov6-00.txt 
Next by thread: Re: [BEHAVE] Fwd: I-D Action: draft-sun-behave-v4tov6-00.txt 
Index(es): 
Date 
Thread 
Note: Messages sent to this list are the opinions of the senders and do not imply endorsement 

xiechf01-Gmail

---

From: xiechf01-Gmail <[email-masked]>
Date: Tue, 30 Jul 2013 17:30:27 +0200

Hi,

Chongfeng

Hi,

BR,
Branimir

-------- Izvorna poruka --------
Åalje: Andrew Sullivan <ajs at anvilwalrusden.com>
Datum:
To: behave at ietf.org
Naslov: Re: [BEHAVE] Fwd: I-D Action: draft-sun-behave-v4tov6-00.txt

Hi,

Best,

A

</FONT></P></HTML>

References: 

xiechf01-Gmail