Subject: Re: [Softwires] draft-murakami-softwire-4v6-translation

From: Rémi Després <[email-masked]>
Date: Wed, 7 Sep 2011 11:48:18 +0200

Le 22 août 2011 à 19:41, Cameron Byrne a écrit :

> 2011/8/22 Nejc Škoberne <[email-masked]>:
>> Dear Cameron,
>> 
>>> some pressure.  IMHO, i believe that static over-subscription ratios
>>> required by A+P will not meaningfully keep pace with the rapid growth
>>> in the number of internet nodes.
>> 
>> I would be very happy if you elaborated on this. Can you give something
>> to support this belief?
>> 
> 
> Easy math version assuming the entire internet moves to this model of
> stateless address sharing:
> 
> 50 Billion Internet nodes [1]
> 
> 240 Million  IPv4 addresses [2]
> 
> 208.3 devices per IPv4 address -- by dividing the above numbers
> 
> 312.5 ports per user -- by dividing by 65k ports

312 ports per host "for IPv4", while more and more sites are accessible in IPv6 and consume no IPv4 port, is in my understanding a comfortable perspective.

Regards,
RD

> 
> Not a perfect guesstimate on several levels since the "internet" is
> not uniform and does move to anything in a uniform, the numbers used
> above are suspect, and this is not an internet wide solution, some
> nodes may go IPv6 only, and so on ... but sometimes looking at numbers
> like this in the macroscopic view helps us understand our little part
> of the internet that we are trying to design a solution for.
> 
> As stated, some providers may find a benefit here... I believe that is
> clear.  My understanding is that in North America many of the
> incumbent land line providers have fairly static subscriber bases, not
> a lot of growth in users demanding IPv4.  In my world (mobile), AFAIK
> approximately half of the service providers globally already do NAT44
> / LSN / CGN.
> 
> Areas of the internet that are experiencing or anticipate rapid growth
> (mobile, cloud, new ventures) in address consumption will likely not
> extend their existing addresses far with a stateless solution.
> 
> Regards,
> Cameron
> 
> [1] http://www.ericsson.com/thecompany/press/releases/2010/04/1403231
> [2] http://tools.ietf.org/html/rfc3194
> 
> 
>> Thanks,
>> Nejc
>> 
> _______________________________________________
> Softwires mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/softwires

---

From: Behcet Sarikaya <[email-masked]>
Date: Wed, 14 Sep 2011 13:10:20 -0700 (PDT)

Hi Tetsuya,

   I was wondering about DNS Proxy mentioned in Section 5.5 of RFC 6333.
 Do you also need it?

Regards,

Behcet

---

From: Behcet Sarikaya <[email-masked]>
Date: Wed, 14 Sep 2011 12:03:54 -0700 (PDT)

Hi Tetsuya,

Regards,

Behcet

> 
> Brian,
> 
>>>  The problem with static allocation is that it cannot adapt quickly to 
> subscriber demand.
>> 
>>  Exactly; so it cannot optimise the number of ports in use.
>> 
>>  What strikes me in this conversation is that all these solutions are a
>>  tremendous amount of work to deal with legacy equipment, and I have
>>  to wonder whether that is economically rational. That is for the market
>>  to decide, but I don't see that the IETF is obliged to solve each
>>  possible case. In other words I'm not sure where to find the 
> requirements
>>  analysis that this new burst of activity is based on.
> 
> my assumption is that this is done on a CPE, as a part of the existing NAT 
> function.
> legacy applications exists behind the NAT.
> 
> there are multiple implementations of the encapsulation scheme already.
> 
> cheers,
> Ole
> 
>>>  Dear Brian,
>>>  Thank you and in line...
>>> 
>>> 
>>>  Best Regards,
>>>  Tina TSOU
>>>  http://tinatsou.weebly.com/contact.html
>>> 
>>> 
>>>  -----Original Message-----
>>>  From: Brian E Carpenter [mailto:[email-masked]] 
>>>  Sent: Sunday, August 21, 2011 3:21 PM
>>>  To: Tina TSOU
>>>  Cc: Rémi Després; [email-masked]; 
> [email-masked]
>>>  Subject: Re: [Softwires] draft-murakami-softwire-4v6-translation
>>> 
>>>  Hi Tina,
>>> 
>>>  On 2011-08-21 14:08, Tina TSOU wrote:
>>>  ...
>>>>  If an average IPv4 user is consuming 200 ports (or whatever
>>>>  value you prefer to assume) with their favourite p2p app, that
>>>>  is what sets the number of IPv4 users per shared address. It's
>>>>  the number of simultaneous ports, not the amount of traffic,
>>>>  that counts.
>>>>  [Tina:
>>>>  These drafts attempt to solve this issue.
>>>>  https://datatracker.ietf.org/doc/draft-tsou-pcp-natcoord/
>>> 
>>>  This doesn't create new ports; it just helps to allocate
>>>  them more rationally.
>>>  [Tina: When I see your comments about consuming 200 ports, I thought 
> about the motivation of NAT-COORD is to solve the issue of one iTunes, Google 
> Map application consumes 200~300 ports at a time. I did not think about 
> Stateful/Stateless at that time.
>>> 
>>>  In the use cases you mentioned above, do you only mean static port 
> allocation issue with stateless mechanisms? Or it can be either stateful or 
> stateless? 
>>> 
>>>  The stateless address sharing schemes (4rd and friends) allocate a port 
> range to each subscriber statically. Static allocation is necessary for the 
> mechanism to be stateless.
>>>  There are all the advantages of a stateless mechanism (see the 
> motivation draft for a list of these advantages).
>>> 
>>>  The problem with static allocation is that it cannot adapt quickly to 
> subscriber demand. If for example you have one subscriber that is consuming a 
> lot of ports, you cannot assign more ports to it. Once it's assigned, 
> it's static and hard to change.
>>>  ]
>>> 
>>>>  https://datatracker.ietf.org/doc/draft-zhou-softwire-b4-nat/
>>> 
>>>  If I understand this correctly, it avoids NAT444 (which is a
>>>  good thing, and would make
>>>  draft-weil-shared-transition-space-request unnecessary). But
>>>  again, it doesn't create new ports or new public IPv4 addresses,
>>>  which was my point.
>>> 
>>>  4rd and 4via6 share this property of course.
>>> 
>>>    Brian
>>

---

From: Tetsuya Murakami <[email-masked]>
Date: Tue, 20 Sep 2011 07:32:31 -0700

Hi Behcet,

Sorry for my late response.

I think it should be a same situation as DS-Lite. Since the network which CE is facing is only IPv6, the network can not distribute IPv4 DNS information. Hence, CE should have a DNS proxy.

Thanks,
Tetsuya Murakami