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

From: joel jaeggli <[email-masked]>
Date: Thu, 01 Aug 2013 14:45:49 +0200

On 7/30/13 5:30 PM, xiechf01-Gmail wrote:
> 
> 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.
>

As a datecenter operator availability of public addressing is a
significant consideration. that said that impacts service deployment
considerations not in fact host count.

Decisions to deploy v6 only hosts vs dual stack in my environment and I
suspect most others actually have relatively little to do with my 
supply of public IPs.  I have therefore some issues with your conclusions.

> 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 <mailto:[email-masked]>" <ajs
> at anvilwalrusden.com <mailto:[email-masked]>>, "behave at
> ietf.org <mailto:[email-masked]>" <behave at ietf.org
> <mailto:[email-masked]>> * /Subject/: Re: [BEHAVE] Fwd: I-D
> Action: draft-sun-behave-v4tov6-00.txt * /From/: Branimir Rajtar
> <Branimir.Rajtar at t.ht.hr <mailto:[email-masked]>> *
> /Date/: Tue, 30 Jul 2013 08:46:19 +0000 * /Accept-language/: en-US *
> /Delivered-to/: behave at ietfa.amsl.com
> <mailto:[email-masked]> * /In-reply-to/:
> <20130730080504.GA52575 at mx1.yitter.info
> <mailto:[email-masked]>> * /List-archive/:
> <http://www.ietf.org/mail-archive/web/behave> * /List-help/:
> <mailto:[email-masked]?subject=help> * /List-id/: mailing
> list of BEHAVE IETF WG <behave.ietf.org> * /List-post/:
> <mailto:[email-masked]> * /List-subscribe/:
> <https://www.ietf.org/mailman/listinfo/behave>,
> <mailto:[email-masked]?subject=subscribe> *
> /List-unsubscribe/: <https://www.ietf.org/mailman/options/behave>,
> <mailto:[email-masked]?subject=unsubscribe> * /References/:
> <CAH3bfABtMxZkEyhoAAih5bsDzP6H7BzzMr88h6Tx6+M2Siqbgw at
> mail.gmail.com
>
<mailto:[email-masked]>>
> <CAKcc6Aep7cK_Dt=CFsQM3F5Fn8Oy9Ui1_9gd7u6_d4pYOd1OZQ at
> mail.gmail.com
>
<mailto:[email-masked]>>
> <CAH3bfAB1dLvBJ2FrMvc7bANcUsneZ_xcOk_RPJaMkO=RrWnGCA at
> mail.gmail.com
>
<mailto:[email-masked]>>
> <20130729134623.GD51737 at mx1.yitter.info
> <mailto:[email-masked]>> <51F674D0.3040603 at
> viagenie.ca <mailto:[email-masked]>>
> <20130729143910.GB51823 at mx1.yitter.info
> <mailto:[email-masked]>>
> <CAH3bfAC3CasuudpXyb3XWOMz+TwZUGeya_1h=jd2MGX4oLM0Vg at
> mail.gmail.com
>
<mailto:[email-masked]>>,
> <20130730080504.GA52575 at mx1.yitter.info
> <mailto:[email-masked]>> * /Reply-to/: Branimir
> Rajtar <Branimir.Rajtar at t.ht.hr
> <mailto:[email-masked]>> * /Thread-index/:
> AQHOjNBH7KZnViUbv0K3Et3zbLdQ3Jl8u9YAgAAtDus= * /Thread-topic/:
> [BEHAVE] Fwd: I-D Action: draft-sun-behave-v4tov6-00.txt
>
> ------------------------- 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*: o *[BEHAVE] Fwd: I-D Action:
> draft-sun-behave-v4tov6-00.txt
> <http://www.ietf.org/mail-archive/web/behave/current/msg10965.html>*
> + /From:/ Qiong o *Re: [BEHAVE] Fwd: I-D Action:
> draft-sun-behave-v4tov6-00.txt
> <http://www.ietf.org/mail-archive/web/behave/current/msg11052.html>*
> + /From:/ Liu Dapeng o *Re: [BEHAVE] Fwd: I-D Action:
> draft-sun-behave-v4tov6-00.txt
> <http://www.ietf.org/mail-archive/web/behave/current/msg11056.html>*
> + /From:/ Qiong o *Re: [BEHAVE] Fwd: I-D Action:
> draft-sun-behave-v4tov6-00.txt
> <http://www.ietf.org/mail-archive/web/behave/current/msg11058.html>*
> + /From:/ Andrew Sullivan o *Re: [BEHAVE] Fwd: I-D Action:
> draft-sun-behave-v4tov6-00.txt
> <http://www.ietf.org/mail-archive/web/behave/current/msg11060.html>*
> + /From:/ Simon Perreault o *Re: [BEHAVE] Fwd: I-D Action:
> draft-sun-behave-v4tov6-00.txt
> <http://www.ietf.org/mail-archive/web/behave/current/msg11063.html>*
> + /From:/ Andrew Sullivan o *Re: [BEHAVE] Fwd: I-D Action:
> draft-sun-behave-v4tov6-00.txt
> <http://www.ietf.org/mail-archive/web/behave/current/msg11070.html>*
> + /From:/ Qiong o *Re: [BEHAVE] Fwd: I-D Action:
> draft-sun-behave-v4tov6-00.txt
> <http://www.ietf.org/mail-archive/web/behave/current/msg11078.html>*
> + /From:/ Andrew Sullivan
>
> * Prev by Date: *Re: [BEHAVE] draft-meng-behave-napgt can be met by
> PCP port set
> <http://www.ietf.org/mail-archive/web/behave/current/msg11080.html>*
> * Next by Date: *Re: [BEHAVE] draft-meng-behave-napgt can be met by
> PCP port set
> <http://www.ietf.org/mail-archive/web/behave/current/msg11082.html>*
> * Previous by thread: *Re: [BEHAVE] Fwd: I-D Action:
> draft-sun-behave-v4tov6-00.txt
> <http://www.ietf.org/mail-archive/web/behave/current/msg11078.html>*
> * Next by thread: *Re: [BEHAVE] Fwd: I-D Action:
> draft-sun-behave-v4tov6-00.txt
> <http://www.ietf.org/mail-archive/web/behave/current/msg11061.html>*
> * Index(es): o *Date*
> <http://www.ietf.org/mail-archive/web/behave/current/maillist.html#11081>
>
>
o *Thread*
<http://www.ietf.org/mail-archive/web/behave/current/threads.html#11081>
> 
>
> Note: Messages sent to this list are the opinions of the senders and
> do not imply endorsement
>
>
> ------------------------- xiechf01-Gmail
>
>
> _______________________________________________ Behave mailing list
> [email-masked] https://www.ietf.org/mailman/listinfo/behave

---

From: joel jaeggli <[email-masked]>
Date: Fri, 02 Aug 2013 13:11:57 +0200

> supply of public IPs.  I have therefore some issues with your conclusions.

I've been told this is cryptic...

Here are some observations.

How you number your network and that of your customers is a business
decision.

your customers will require public ipv4 addresses on some device either
owned by them or you in order to service ipv4 customers into the
foreseeable future.

regarding this  assertion:

   This document is designed for IPv4 Internet to reach IPv6 network.
   There are several requirements in this design:

      1.Considering IPv4 address has been a scarce resource, the amount
      of public IPv4 addresses consumed by the translator should be less
      than that the number of IPv6 servers in the IPv6 network.

As far as i know it is common practice already that the operators
conserve public ip addresses by limiting their use to necessary network
components.  this is done notwithstanding the choice of technologies
e.g. it is done is single stack v4 networks as well. I expect that if/as
ipv4 address availability continues to decline that the result will be
that operators will reduce what are considered necessary until such
point as the only devices with public ipv4 addresses are load balancers
nat translators and perhaps select loopbacks.

When looking at section 3.1 and section 4 you assert that the client is
making a query to the dns46 nameserver. and that the client source
address is a consideration in the mapping. In fact the client source
address is not seen by the dns46 nameserver, rather the client's
recursive nameserver(s) is seen by the dns46 nameserver, likewise for
the duration of the ttl on the ipv4 A record the recursive resolvers
will not again query the dns46 nameserver on behalf of the client or
other clients which they may have.

You assert that major feature of the approach you describe is this:

    6 <http://tools.ietf.org/html/draft-sun-behave-v4tov6-00#section-6>.
    The Dynamic IPv6-converted Address Issue

   The major feature in the above two approaches is that the IPv6-
   converted address for destination IPv6 server is now dynamically
   determined by NAT46. 

Which is interesting but it requires two conceits that aren't well
described.
 
It posits the existance of internet content providers with no or few
ipv4 customers such that they don't need an ipv4 address all the time.
maybe that exists in the far future but it doesn't seem like an
immediate problem. therefore one would expect these to be effectively
continuously assigned.

It requires that the forward zone for the internet content providers
name service be delegated to the operator of the nat46 gateway's dns46
server, either a datacenter operator or an internet service provider (as
opposed to either utilizing a third party, or running it themselves). To
the extent that I am aware it is a not a common practice.