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

From: Nejc Škoberne <[email-masked]>
Date: Wed, 17 Aug 2011 11:24:11 +0100

Dear authors,

as far as I can understand your draft, you make NAPT44 in the CE obligatory.
However, this is not the case for 4rd, dIVI, SA46T-AS and Lightweight 
4over6 A+P
drafts. So I suggest that you make it optional in 4via6 translation as 
well, since it might
be desired for some environments to connect hosts supporting 4via6 
translation
technology, directly to the IPv6 network. In this case, you don't need 
the translator.

Thanks,
Nejc

---

From: GangChen <[email-masked]>
Date: Wed, 17 Aug 2011 21:36:48 +0800

Dear Nejc,

> as far as I can understand your draft, you make NAPT44 in the CE obligatory.

[Gang] Yes. This is to avoid the problem where there are applications
that attempt
to bind to specific ports that are not part of the allowed port range.

> 4over6 A+P drafts.

[Gang] I guess this is always the case for port constrained mechanisms.

>So I suggest that you make it optional in 4via6 translation as
> well, since it might

[Gang] Could you help to elaborate the environment ?

Many thanks

Gang

---

From: Nejc Škoberne <[email-masked]>
Date: Wed, 17 Aug 2011 14:58:01 +0100

Dear Gang,

> to bind to specific ports that are not part of the allowed port range.

Well, if the application/operating system supports the 
standard/protocol/technology, then it should only bind to the port, which 
CPE would normally use to translate source ports of the packets. If there
is no such operating system/application, NAPT44 must be used, of course.

> [Gang] I guess this is always the case for port constrained mechanisms.

Of course. But you could support various scenarios in the scope of your draft,
not only the common "CPE" one. 

> [Gang] Could you help to elaborate the environment ?

Sure. I can imagine a Linux implementation of "4via6 translation
support". If enabled, the TCP/IP stack would only bind to specific ports 
(from the range). If you check the section III./C of the following paper: 

http://zhuyc.info/globecom08mivi.pdf

the authors propose a modification "to the system call related to bind()
in the socket library of the operating system".

Then I could just connect my home gateway-server directly to the ISPs
network, providing support for "4via6 translation" and that's it.

Also, I see is as a use case in non-ISP environments, where you could
have IPv6-only, but 4via6 enabled server networks, with servers supporting
"4via6 translation". Like SA46T-AS, for example.

The main advantage of all this is of course that the IPv4 address is then
natively configured on the (virtual) interface.

--

Other than that, I still am very curious what are the differences between
your draft and draft-xli-behave-divi-03. I would be very happy if you could
elaborate on that.

Thanks,
Nejc

---

From: Behcet Sarikaya <[email-masked]>
Date: Wed, 17 Aug 2011 15:29:48 -0700 (PDT)

> not only the common "CPE" one. 

No.

a+p does not require a NAT44 to be used. This is the case here (my guess) because NAT44 is commonly used in the current CE routers and they don't wish to waste public IPv4 addresses.

Also NAT44 usage has nothing to do with the port range restrictions of the CE.
It is normal behavior of NAPT to select a different source port for the outgoing packet and the port range restriction comes into use here,
CE has to use a source port from its range.

Regards,

Behcet

---

From: Nejc Škoberne <[email-masked]>
Date: Wed, 17 Aug 2011 23:36:01 +0100

Dear Behcet,

> CE has to use a source port from its range.

Sorry, but I didn't get your point. So you think that it is okay as it
is in the draft? You say, that A+P doesn't require a NAT44 to be used.
Exactly. That's why I think it would be great if this was stated in the
draft as well. Currently, NAT is obligatory in the draft.

Thanks,
Nejc

---

From: Satoru Matsushima <[email-masked]>
Date: Thu, 18 Aug 2011 12:43:22 +0900

Dear Nejc,

> not only the common "CPE" one. 

We assume that all applications/OSes doesn't aware port restricted environment. 
However, there is a case where an application would be allocated a port which is inside of port set occasionally.

> in the socket library of the operating system".

The modification of 'to the system call related to bind()' is out of scope in our draft.

> natively configured on the (virtual) interface.

IMHO, address mapping rule and port distribution algorithm are the difference.
Let me think that if 4rd is configured with 'DomainIPv6Prefix == 2001:db8::/32', 'CEIPv6PrefixLength == /72' and 'Domain4rdPrefix == 0/0' for example. 40bits EA-bits are divided to 32bits IPv4 address part and 8bits port-set ID part. The length of the port-set ID expresses that address sharing ratio. The bits pattern of the port-set ID expresses port-set index of modulo operation, described in the divi. 

cheers,
--satoru

---

From: Nejc Škoberne <[email-masked]>
Date: Thu, 18 Aug 2011 09:50:12 +0100

Dear Satoru,

> We assume that all applications/OSes doesn't aware port restricted environment.

Sure.

> However, there is a case where an application would be allocated a port which is inside of port set occasionally.

Yes. But I am just talking about being open to applications/OSes which
_would_ be aware of port restriction. The problem I see with the fact,
that you don't do this at the moment, is that in a while, anoter I-D 
will pop up, filling this very small gap.

> The modification of 'to the system call related to bind()' is out of scope in our draft.

Of course. I don't think you should be defining the implementation. I just
think that you should leave it open so that if someone is going to implement
such a restricted system, he can then connect directly onto the IPv6 network.

All other A+P drafts do this, I really can't see a valid reason why you
could not do this with "4via6 translation" as well.

> Let me think that if 4rd is configured with 'DomainIPv6Prefix == 2001:db8::/32', 'CEIPv6PrefixLength == /72' and 'Domain4rdPrefix == 0/0' for example. 40bits EA-bits are divided to 32bits IPv4 addr…

Yes, this is the difference. Xing Li, one of the authors of dIVI, also points
out that your draft "lacks the difinition of suffix, therefore is not compatible 
to IPv4/IPv6 translation RFCs." How do you see this?

Anyway, are we sure, that we need two different drafts to cover these
differences? I mean, the principle is the same, isn't it? In my opinion, 
there is an inflation of I-Ds and I think that with some additional synchronization
of efforts we could avoid doubling work of each other. But I may be wrong.

I think that the same goes for 4rd and SA46T-AS, for example.

Thanks,
Nejc

---

From: GangChen <[email-masked]>
Date: Thu, 18 Aug 2011 21:59:21 +0800

2011/8/18, Nejc Škoberne <[email-masked]>:
>> a+p does not require a NAT44 to be used. This is the case here (my guess)
>> because NAT44 is commonly used in the current CE routers and they don't
>> wish to waste public IPv4 addresses.
>>
>> It is normal behavior of NAPT to select a different source port for the
>> outgoing packet and the port range restriction comes into use here,

A+P is the same case if I understand correctly. NAT44 is one of three
fundamental functions in A+P architecture. Otherwise, it can’t connect
to legacy end-hosts.

BRs

Gang

---

From: GangChen <[email-masked]>
Date: Thu, 18 Aug 2011 22:03:50 +0800

> in the socket library of the operating system".

That is not practicable. You can't do such modification on innumerable hosts.

> natively configured on the (virtual) interface.

Sorry. I still can't see much benefits from that.

Gang

---

From: Simon Perreault <[email-masked]>
Date: Thu, 18 Aug 2011 10:12:23 -0400

On 2011-08-18 09:59, GangChen wrote:
> NAT44 is one of three

What if in my deployment scenario there are no "legacy" end hosts? What
if all hosts implement A+P-style port ranges?

I'm with Nejc here. A+P/4rd/... do not require NAT44.

Simon
-- 
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
STUN/TURN server               --> http://numb.viagenie.ca

---

From: Nejc Škoberne <[email-masked]>
Date: Thu, 18 Aug 2011 15:14:21 +0100

Dear Behcet,

> fundamental functions in A+P architecture. Otherwise, it can’t connect

It _is_ fundamental, however it is not mandatory in all scenarios. Please
see draft-ymbk-aplusp-10 (which defines A+P architecture and has been
approved RFC status in June), page 16, Figure 6. It clearly shows two
different customers. Customer2 must use NAT44, naturally, since his hosts
don't support the specific A+P mechanism themselves. Customer1, however,
has his hosts connected directly into the A+P network. This is because
his hosts _have_ native A+P support for the specific mechanism.

And I think that "draft-murakami-softwire-4v6-translation" should also
support these kind of scenarios (as all other A+P mechanism drafts do).

Thanks,
Nejc

---

From: Nejc Škoberne <[email-masked]>
Date: Thu, 18 Aug 2011 15:50:11 +0100

Dear Gang,

> That is not practicable. You can't do such modification on innumerable hosts.

Who says only "innumerable" hosts will want to have this? My view on this is, 
that these proposals are not meant to solve only a specific
problem for a specific scenario. Why would we want that? If we do proposals this
way, we will lost ourselves among very similar but a bit different standards.
It's more complex to "administer" such set of standards and it is much harder
for the developers to crawl through all these documents in order to implement
what they need.

> Sorry. I still can't see much benefits from that.

I'll try harder to deliver possible real-world scenarios:

1. Home Torrent node.
---------------------

I am a customer of an ISP who deployed one of the A+P mechanisms. I have a home
server which is also able to run Torrent client. And since this is a new server,
it happens to support the A+P mechanism of the ISP. So I can plug it directly
to my ISP-provided link (modem, CPE, switch, whatever), and everything /just 
works/. This way:

- I don't have to deal with static RFC 1918 addressing, 

- I don't have to deal with static NAT configuration on the CPE,

- I don't have to deal with with additional port configuration on my Torrent box. 

- ...

It just works.

2. Enterprise server mode.
--------------------------

I am a network/system administrator for my company, which has a very limited
set of public IPv4 addresses. But as I don't want to maintain a separate IPv4
addressing infrastructure in my network, my server network will be IPv6-only
as well. However, the servers still need IPv4 connectivity, and for that I'd
like to use A+P. This way:

- I don't need any special ALGs for my servers, which I would have to develop
first since I am using my own proprietary protocols, which can't traverse NATs 
well,

- I don't need to maintain IPv4 in my network where I don't want to have it,
especially I don't need to maintain _another_ IPv4 addressing (RFC 1918),

- I get rid of stateful NAT44 in the core, which is very difficult to make
highly available properly (state synchronization).

- ...

----

Can you see the benefits now?

Thanks,
Nejc

---

From: Wojciech Dec <[email-masked]>
Date: Thu, 18 Aug 2011 19:08:06 +0200

2011/8/17 Nejc Škoberne <[email-masked]>

> technology, directly to the IPv6 network. In this case, you don't need the
> translator.
>

It's useful to note that the implementation of any A+P based scheme on an
end host has practical challenges, irrespective of what drafts say (just
think of two such host on the same LAN - something that is not allowed)
If it helps think of any of 4rd, 4V6, dIVI-PD, as having the same
applicability, but practically being most suitable for a CE alongside NAPT44
(which all rely on to provide address sharing)

-Wojciech

>
> Thanks,
> Nejc
> ______________________________**_________________
> Softwires mailing list
> [email-masked]
> https://www.ietf.org/mailman/**listinfo/softwires<https://www.ietf.org/mailman/listinfo/softwires>
>

---

From: "Jan Zorz @ go6.si" <[email-masked]>
Date: Thu, 18 Aug 2011 22:14:03 +0200

> fundamental functions in A+P architecture. Otherwise, it can’t connect

Usually yes, but not necessary. PAT could also do the work, if you 
connect behind CPE a host with public IP address, sort of like "bridged 
mode", and PAT in CPE changes ports to ones inside port-range/set.

This way no address translation is needed, just ports needs to be 
"redirected" to right ones.

Cheers, Jan Zorz

---

From: Nejc Škoberne <[email-masked]>
Date: Fri, 19 Aug 2011 00:17:43 +0100

Dear Wojciech,

> It's useful to note that the implementation of any A+P based scheme on 
> an end host has practical challenges, irrespective of what drafts say 
> (just think of two such host on the same LAN - something that is not 
> allowed)

Are these challenges documented anywhere? Also, why would having two
such hosts on the same LAN not be allowed? I mean, yes, if you have 2
hosts having the same IPv4 address configured on the interface, that
won't work. But in "my world", A+P-enabled hosts are connected to the 
IPv6 network directly.

> applicability, but practically being most suitable for a CE alongside 
> NAPT44 (which all rely on to provide address sharing)

I agree that this will be the most common scenario. But that doesn't
mean we should forget about other scenarios.

Thanks,
Nejc

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 19 Aug 2011 11:35:30 +1200

On 2011-08-19 11:17, Nejc Škoberne wrote:

...
> won't work. But in "my world", A+P-enabled hosts are connected to the 

And how will that support legacy SOHO LANs?

   Brian

---

From: GangChen <[email-masked]>
Date: Fri, 19 Aug 2011 10:03:35 +0800

> I'm with Nejc here. A+P/4rd/... do not require NAT44.

And then, how many hosts could support "what if" in the wild

Gang

---

From: Satoru Matsushima <[email-masked]>
Date: Fri, 19 Aug 2011 11:17:30 +0900

On 2011/08/19, at 5:14, Jan Zorz @ go6.si wrote:

> Usually yes, but not necessary. PAT could also do the work, if you connect behind CPE a host with public IP address, sort of like "bridged mode", and PAT in CPE changes ports to ones inside port-range/set.
> 
> This way no address translation is needed, just ports needs to be "redirected" to right ones.

It seems to me that no modification for any system call, correct?
AFAIK, Nejc insists some system call modification, bind(), etc.,

cheers,
--satoru

---

From: GangChen <[email-masked]>
Date: Fri, 19 Aug 2011 10:52:50 +0800

> for the developers to crawl through all these documents in order to

"NOT PRACTICABLE" has two meanings.
1) Restricted port aware host is relatively few case
2) Socket need to be modified. That is a practical challenge, not only
bind() but also connect()

> I'll try harder to deliver possible real-world scenarios:

The consumption is to produce a brand-new network. If that is the
case, I may prefer going to native IPv6 network.

Gang

---

From: Simon Perreault <[email-masked]>
Date: Fri, 19 Aug 2011 08:10:47 -0400

> And then, how many hosts could support "what if" in the wild

It's your deployment scenario that requires NAT44, not 4rd itself.

I'm not denying that this deployment scenario is important. Many of us
are considering the same scenario. All I'm saying is that there is
another scenario where 4rd would also be applicable that would not
require NAT44.

Simon

---

From: Xing Li <[email-masked]>
Date: Fri, 19 Aug 2011 21:30:01 +0800

于 2011/8/19 20:10, Simon Perreault 写道:
>> 2011/8/18, Simon Perreault<[email-masked]>:

This is also the case for dIVI, where NAT44 is an option.

Regards,

xing

---

From: Behcet Sarikaya <[email-masked]>
Date: Fri, 19 Aug 2011 09:03:20 -0700 (PDT)

>>  set of public IPv4 addresses. But as I don't want to maintain a 
> separate
>>  IPv4
>>  first since I am using my own proprietary protocols, which can't 
> traverse
>>  NATs
>>  well,
>> 

+1

Behcet

---

From: "Jan Zorz @ go6.si" <[email-masked]>
Date: Fri, 19 Aug 2011 22:23:11 +0200

> AFAIK, Nejc insists some system call modification, bind(), etc.,

Yes, if CPE is doing A+P-PAT, then no modification for any system call.
But this goes for 1 host only :)

Cheers, Jan

---

From: Nejc Škoberne <[email-masked]>
Date: Fri, 19 Aug 2011 22:18:47 +0100

Dear Brian,

> And how will that support legacy SOHO LANs?

It will not, because I don't have a legacy SOHO LAN. If I have legacy 
SOHO LAN, I can use (optional) NAT44.

Nejc

---

From: Nejc Škoberne <[email-masked]>
Date: Fri, 19 Aug 2011 22:21:28 +0100

Dear Gang,

> And then, how many hosts could support "what if" in the wild

I don't see why this is important. Anyway, the answer is "hopefully
more and more". Isn't encouraging the transition to IPv6 one of the 
major "commandments" of IETF?

Nejc

---

From: Nejc Škoberne <[email-masked]>
Date: Fri, 19 Aug 2011 22:34:25 +0100

Dear Gang,

> 1) Restricted port aware host is relatively few case

Since we are not developing mechanisms for the period of the next few
months, I don't think this argument is relevant. Long term, there
might (hopefully) be more such hosts.

> bind() but also connect()

This is just one of the ways to implement this. See Jan's mail on PAT.

> case, I may prefer going to native IPv6 network.

I am very sorry, but I don't understand what you mean with your first
sentence. Of course I want/will go to native IPv6 network, but during
the IPv4/IPv6 coexistence, I will need IPv4 connectivity as well! And
this is why I want my hosts, connected to IPv6-only network, to also
support A+P. So I don't need any nat.

If you think my arguments don't hold, please comment on them one-by-one
so that I understand why they don't hold.

Thanks,
Nejc

---

From: Nejc Škoberne <[email-masked]>
Date: Fri, 19 Aug 2011 22:34:29 +0100

Dear Satoru,

> AFAIK, Nejc insists some system call modification, bind(), etc.,

I don't insist on any specific implementation. I just insist on NAPT44
being optional. It may be done with changing the host, but it might
be also done with the PAT, as Jan says (although in this case, there
are significant other issues). It just doesn't matter how it is done.

Again, all other A+P drafts out there, allow for such a scenario.
"4via6 translation" is the only one which does not.

Thanks,
Nejc

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 20 Aug 2011 11:12:48 +1200

> SOHO LAN, I can use (optional) NAT44.

Exactly, resulting in NAT444 . But if I'm forced to use NAT444
via a 4 in 6 tunnel anyway, A+P is pointless.

    Brian

---

From: Nejc Škoberne <[email-masked]>
Date: Sat, 20 Aug 2011 00:41:01 +0100

> via a 4 in 6 tunnel anyway, A+P is pointless.

I don't think you understood what I was saying. There is no need for NAT444. 

Let me explain again. The provider has an A+P solution in place. They will,
by default, provide me with their CPE, which supports A+P and also does
NAPT44 for my legacy SOHO LAN. In this case, I just plug my computers and
everything will work like today, just with not-so-many ports.

However, there are at least two more possible scenarios I can imagine:

1.) I don't want the provider's CPE since I have my home gateway-server, 
which supports A+P and is connected directly to the ISP. This server will 
have a public IPv4 address configured and if I need, it /can/ then do 
NAPT44 (instead of the CPE) for the rest of my legacy LAN.

2.) I don't want the provider's CPE since my computers actually support
A+P mechanism of the provider. I have IPv6-only network in my LAN and
IPv4 addressing is brought directly to hosts via A+P mechanism. So it
is like "extending" the access network to my home. This scenario is also
shown on page 16, Figure 6 in draft-ymbk-aplusp-10.

Nejc

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 20 Aug 2011 16:15:29 +1200

Ahah, you seem to assume that A+P will solve the ISP's shortage
of IPv4 addresses. That may be true for a year or three, but
after that they will discover that they have to CGN their A+P
customers, and then you have NAT444 after all, IMHO.

Regards
   Brian

---

From: Rémi Després <[email-masked]>
Date: Sat, 20 Aug 2011 09:15:59 +0200

> customers, and then you have NAT444 after all, IMHO.

Two points:
- There is no claim AFAIK that the stateless solution fits all situations. There is only a claim that some will use it alone if they can, because of its simplicity, that some will combine it with dynamic mechanisms, and that some may prefer dynamic mechanisms alone.
- As IPv6-enablement is generalized, less and less traffic will be in IPv4. Thus, each IPv4 address will become sharable among more and more customers.

Is this acceptable?

Regards,
RD

> _______________________________________________
> Softwires mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/softwires

---

From: Cameron Byrne <[email-masked]>
Date: Sat, 20 Aug 2011 15:23:30 -0700

> customers, and then you have NAT444 after all, IMHO.

I share this concern.  While i do agree that IPv6 usage will relieve
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.

Cameron

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 21 Aug 2011 10:54:00 +1200

> - There is no claim AFAIK that the stateless solution fits all situations. There is only a claim that some will use it alone if they can, because of its simplicity, that some will combine it with d…

Sure. The question is really whether its "market share" would be
enough to justify the effort.

> - As IPv6-enablement is generalized, less and less traffic will be in IPv4. Thus, each IPv4 address will become sharable among more and more customers.

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.

   Brian

---

From: Tina TSOU <[email-masked]>
Date: Sun, 21 Aug 2011 02:08:47 +0000

Brian, Remi,
In line.

Best Regards,
Tina TSOU
http://tinatsou.weebly.com/contact.html

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Brian E Carpenter
Sent: Saturday, August 20, 2011 3:54 PM
To: Rémi Després
Cc: [email-masked]; [email-masked]
Subject: Re: [Softwires] draft-murakami-softwire-4v6-translation

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/
https://datatracker.ietf.org/doc/draft-zhou-softwire-b4-nat/
The running code was demoed in IETF-81.]

   Brian

---

From: Rémi Després <[email-masked]>
Date: Sun, 21 Aug 2011 07:42:57 +0200

...
> is what sets the number of IPv4 users per shared address.

It _contributes_ to set the number, yes, but with due consideration of the following:
- Users behind common CPE's typically don't have their peak consumption at the same time.
- More and more of these applications will be possible in IPv6 (thus consuming no IPv4 port at all).

(Extending IPv6 availability as widely as possible, including behind legacy CPE's, is therefore key. That's exactly why we together submitted draft-despres-6a44 ;-))
 
> It's

Sure, that was of course well understood.

RD

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 22 Aug 2011 10:21:26 +1200

Hi Tina,

On 2011-08-21 14:08, Tina TSOU wrote:
...
> https://datatracker.ietf.org/doc/draft-tsou-pcp-natcoord/

This doesn't create new ports; it just helps to allocate
them more rationally.

> 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: Nejc Škoberne <[email-masked]>
Date: Mon, 22 Aug 2011 15:22:08 +0100

Dear Brian,

> customers, and then you have NAT444 after all, IMHO.

I don't assume A+P an ultimate solution for IPv4 address sharing.
I just think that certain ISPs will (be able) to use it. After all,
considering 1024 ports per user, this means 1:64 sharing ratio,
which is a lot compared to 1 IP per customer. If we forget about
Internet of things, which will not be based on IPv4 anyway, I don't
know many ISPs who could make their user base 64 times the size
it is now. Of course, some will do, but they can then use dynamic
port allocation.

Also, even the userbase for an ISP gets this big, there is still
no need for NAT444 in long term with careful planning. A CPE can
support DS-Lite as well as stateless A+P mechanisms at the same
time. It's not that complex to do this. And if it turns out A+P
is not an option (any more), customer-by-customer migration to
DS-Lite could be considered.

Nejc

---

From: Nejc Škoberne <[email-masked]>
Date: Mon, 22 Aug 2011 17:25:25 +0100

Dear Cameron,

> in the number of internet nodes.

I would be very happy if you elaborated on this. Can you give something
to support this belief?

Thanks,
Nejc

---

From: Nejc Škoberne <[email-masked]>
Date: Mon, 22 Aug 2011 17:31:53 +0100

> enough to justify the effort.

But how can you know what the "market share" is? I mean, it's a 
trade-off between having a smaller sharing ratio and having better
end-to-end (perhaps), direct CPE-CPE communication ... I say let's
give ISPs more solutions to avail, so they can adopt the solution
that suits their needs.

> the number of simultaneous ports, not the amount of traffic,

There was a thread on this list recently, which discussed a research
on port reusage by applications:

|>  For example, BitTorrent established five hundreds of sessions while
|> the port consumption  was under a hundred in the first minute of the
|> communication, because when BitTorrent initiates a downloading, it
|> first uses the same source port to connect to the different
|> destinations (destination IP and port) therefore one source port
|> multiplexing different sessions. Skype is  another example that uses
|> one source port to  multiplex different sessions thereby
|saving source
|> port consumptions on NAT.

So I guess we have some reserves here as well.

Nejc

---

From: Cameron Byrne <[email-masked]>
Date: Mon, 22 Aug 2011 10:41:53 -0700

> I would be very happy if you elaborated on this. Can you give something

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

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

---

From: Nejc Škoberne <[email-masked]>
Date: Tue, 23 Aug 2011 10:15:54 +0100

Dear Cameron,

Thanks for your effort.

> 50 Billion Internet nodes [1]

As I said, I don't think we should consider "Internet of things" in this
aspect. Quoting the paper:

"As an example of connected devices, Vestberg was joined on stage by 
Peter Håkansson, research engineer, who showed real life mobile health 
applications. Håkansson showed how heart monitoring can be done remotely 
over the mobile networks and explained the benefits for both patients 
and society."

For these new applications, I don't see why they couldn't be deployed
natively over IPv6. So I think this number is way, way too big.

> approximately half of the service providers globally already do NAT44

Well, as I understand, these (static port allocation) solutions are
predominantly envisioned for resident users and SoHo environments. At
least for mobile environments, I've heard that it is 3GPP's decision
to avoid all host-based transition solutions except dual-stack.

> extend their existing addresses far with a stateless solution.

Well, that's why we have dynamic port allocation solutions ready for them.

====

Let me put it again, so it is clear what I wanted to say initially:

I think that draft-murakami-softwire-4v6-translation SHOULD _allow_ for
NAT-less implementations of the mechanism as well. As all other static
port allocation mechanism drafts do. That's all.

Thanks,
Nejc

---

From: Tina TSOU <[email-masked]>
Date: Tue, 23 Aug 2011 19:23:24 +0000

Dear Brian,
Thank you and in line...

Best Regards,
Tina TSOU

-----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,

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.
]

   Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 24 Aug 2011 08:53:45 +1200

Tina,

> 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.

Regards
   Brian

---

From: Ole Troan <[email-masked]>
Date: Wed, 24 Aug 2011 12:57:55 +0200

Brian,

> 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