Subject: [shara] Updated SHARA BOF description

From: marcelo bagnulo braun <[email-masked]>
Date: Wed, 04 Mar 2009 19:42:37 +0100

Hi,

We have updated the SHARA bof description to adapt its scope to the 
non-wg forming bof that was accepted by the ADs.

Please find it below.

Comments are welcome

Regards, marcelo

(on behalf of Bernard, Magnus and myself)

Sharing IPv4 Addresses (SHARA) BOF

In the current Internet, it is fairly common for ISPs to provision
their subscribers with a single public IPv4 address and for those
subscribers to use NAT technology to allow multiple machines in
their networks to access the Internet. This setup essentially
requires one public IPv4 address per subscriber. As the IPv4 free
address pool becomes depleted, it seems likely that  ISPs will not
have enough public IPv4 addresses to assign one address per
subscriber. When that happens, multiple subscriber networks will
have to share a single public IPv4 address. Multiple approaches
have been proposed in order to implement the sharing of public
IPv4 addresses, as described in section 2.1 of
draft-arkko-townsley-coexistence-00.

The goal of this BOF is to discuss and gain understanding of a
particular family of solutions, the so called distributed-NAT
approaches described in section 2.1.2 of draft-arkko-townsley-
coexistence-00. This family of solutions, essentially assigns
a public IP address and a port range to each subscriber and
relies on some form of port range routing capability within
the ISP network. The result is that each subscriber still
obtains at least a part of a public IP address and retains
some of the capabilities of the current configuration.

During the BOF we intend to discuss the following items:
- Problem characterization: We need to understand what is
exactly the problem, what are the different scenarios that are
affected by the IPv4 address space depletion and what are the
possible approaches to address the problem. In addition, we
need to identify the different relevant aspects of the problem
and solution space that need to be taken into account during
the discussion of the solution space.
- Motivation for SHARA: Discuss the benefits and potential
issues with a distributed NAT approach.
- Distributed NAT approaches: Explore the solution space for
distributed NATs and the implications of the relevant aspects
previously identified.
- Interaction with other efforts. There are a significant
number of efforts in related areas, such as the work being
done in the BEHAVE WG and the SOFTWIRES WG. It is then relevant
to understand how the proposed mechanisms interact with these.
- Implication for the deployment of IPv6. Any mechanism that
aims to extend the lifetime of IPv4 can potentially delay IPv6
deployment. An analysis of the impact of the adoption of these
techniques is needed.

This is non-wg forming BOF and the goal is to provide input
material to the community in general and the IESG in particular
for them to scope out what gaps still need to be addressed in
chartered WG items in other WGs.

---

From: <[email-masked]>
Date: Thu, 5 Mar 2009 11:57:58 +0100

Marcelo,

The description focuse now strongly to distributed NAT, while that is not the only intent of this work - from my point of view more as side-effect. Thus the new version of chapter looks somewhat misleading.

The host having port restricted IPv4 address may or may not implement the NAT internally. If, as is likely, it is running applications or protocols that would face problems with port restricted addresses, NAT can be used to hide the problematics from them, but those apps and protocols that do understand port restricted address, or don't care, should be able to totally avoid NAT and have the benefits of NATless communication (but the port restriction).

This was part of the original BOF description:"..and/or require NATless IPv4 connectivity."

The port restriction anyways is something apps needs to live with - with port restricted addresses the restriction comes already from the network, instead of another apps running on a same host.

So the solutions that are proposed indeed enable distributed NAT functionality, but also enable NATless IPv4 communication. So on the "motivation of shara" I'd like to see benefits and potential issues of having NATless communication possible, but with limited port availability.

On the solution space the same thing, as this BOF is not only about distributed NAT. For example, in DS-Lite environment the NAT can actually be at CGN, while the host is - at the same time - able to get port restricted IPv4 address for those applications that are capable of using them. For other apps CGN is used.

Best regards,

	Teemu

>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]] 
>On Behalf Of ext marcelo bagnulo braun
>Sent: 04 March, 2009 20:43
>To: [email-masked]
>Subject: [shara] Updated SHARA BOF description
>
>Hi,
>
>We have updated the SHARA bof description to adapt its scope 
>to the non-wg forming bof that was accepted by the ADs.
>
>Please find it below.
>
>Comments are welcome
>
>Regards, marcelo
>
>In the current Internet, it is fairly common for ISPs to 
>provision their subscribers with a single public IPv4 address 
>and for those subscribers to use NAT technology to allow 
>multiple machines in their networks to access the Internet. 
>This setup essentially requires one public IPv4 address per 
>subscriber. As the IPv4 free address pool becomes depleted, it 
>seems likely that  ISPs will not have enough public IPv4 
>addresses to assign one address per subscriber. When that 
>happens, multiple subscriber networks will have to share a 
>single public IPv4 address. Multiple approaches have been 
>proposed in order to implement the sharing of public
>done in the BEHAVE WG and the SOFTWIRES WG. It is then 
>relevant to understand how the proposed mechanisms interact with these.
>material to the community in general and the IESG in 
>particular for them to scope out what gaps still need to be 
>addressed in chartered WG items in other WGs.
>_______________________________________________
>shara mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/shara
>

---

From: marcelo bagnulo braun <[email-masked]>
Date: Thu, 05 Mar 2009 12:25:33 +0100

Hi Teemu,

About this scenario that you describe, i think that what you mean is 
that instead of having the NAT CPE acquiing the public address and the 
port range, the host itself acquires it, is that correct?

As i see it, the shara problem has two sides: the internal side (that 
goes between the host and where the public address and port range is 
acquired) and the public side, that goes between the entity acquiring 
the address and the port range that the PRR.
I see these two sides somehow orthogonal. I mean, the internal side can 
be a network running private IPv4 with a nat in the CPE (which acquires 
the public address and the port range), it can be an IPv6 network, with 
a nat64 (which acquires the public IPv4 address and the port range) or 
can be just a host, which directly acquires the address and the port range.

Now, i understand that we are focusing in the external part i.e. how 
does the CPE NAT/NAT64/host acquires the address and the port range and 
how is the ISP network works in the case this is used. We are not 
focusing in how the internal part works beyond to the fact that these 3 
cases must be supported.

I think we should scope the discussion to the external part of the 
problem (even if we need to understand the impact on the internal part, 
such as the impact in UPnp and the like)

So, i don't think that the case you bring is not considered in the bof, 
just that only the external part (of all use cases) is the focus

I do agree that the distributed nat terminology is probably not the best 
option, but we were trying to rely on the terminology used in 
draft-townsley...

Makes sense?

Regards, marcelo

---

From: "[email-masked]" <[email-masked]>
Date: Thu, 5 Mar 2009 12:51:12 +0100

Hi Marcelo,

Inline:

>From: ext marcelo bagnulo braun [mailto:[email-masked]] 
>Sent: 05 March, 2009 13:26
>To: Savolainen Teemu (Nokia-D-MSW/Tampere)
>Cc: [email-masked]
>Subject: Re: [shara] Updated SHARA BOF description
>
>Hi Teemu,
>
>About this scenario that you describe, i think that what you 
>mean is that instead of having the NAT CPE acquiing the public 
>address and the port range, the host itself acquires it, is 
>that correct?

Yes.

But this host can also act like CPE, if it implements and shares the IPv4 address to other devices, e.g. in scenario
   
IPv4 host -- WLAN -- IPv4 cellular -- gateway -- IPv4 Internet

I.e. sometimes the IPv4 cellular is just a host that gets port restricted IPv4 address for NATless communication, and maybe has internal NAT, but sometimes it acts as a CPE for other devices, to which itself allocates private IPv4 addresses and provides NAT functionality.

Generally, I think name CPE relates more to a specific deployment scenario rather than to an entity that exist in protocol level as such. Thinking about CPEs may help to understand the functionality being discussed, but that same functionality can just as easily be implemented by some other kinds of nodes.

>As i see it, the shara problem has two sides: the internal 
>side (that goes between the host and where the public address 
>and port range is
>acquired) and the public side, that goes between the entity 
>acquiring the address and the port range that the PRR.
>I see these two sides somehow orthogonal. I mean, the internal 
>side can be a network running private IPv4 with a nat in the 
>CPE (which acquires the public address and the port range), it 
>can be an IPv6 network, with a nat64 (which acquires the 
>public IPv4 address and the port range) or can be just a host, 
>which directly acquires the address and the port range.

Good description.

>Now, i understand that we are focusing in the external part 
>i.e. how does the CPE NAT/NAT64/host acquires the address and 
>the port range and how is the ISP network works in the case 
>this is used. We are not focusing in how the internal part 
>works beyond to the fact that these 3 cases must be supported.

I agree, we could look at the internal side as well, but we can leave that for later as well. But do we then have to call that as distributed NAT, as doesn't the name choice hint on one aspect of the internal side functionality then? Rather "distributed addresses" or "distributed shared addresses" or something?

>I think we should scope the discussion to the external part of 
>the problem (even if we need to understand the impact on the 
>internal part, such as the impact in UPnp and the like)

That is a good place to start discussions.

>So, i don't think that the case you bring is not considered in 
>the bof, just that only the external part (of all use cases) 
>is the focus
>
>I do agree that the distributed nat terminology is probably 
>not the best option, but we were trying to rely on the 
>terminology used in draft-townsley...

Maybe the draft-townsley is not most up-to-date anymore - its missing discussion from interim, IETF#73, mailing list.. 

I brought this up because the name "distributed NAT" sounded for me like BOF would be focusing too much on distributed NATs (thus missing benefits apps could obtain from NATless communication), while if I understand you now correctly the BOF is still focusing on shared addresses and pros/cons with those - which include the possibility of NAT distribution (which has its own PROs and CONs e.g. in relation to ALG deployment possibilities).

>Makes sense?

Yes. I think it would be good to define this internal and external separation on BOF description and say we focus on external part first. Will you update the BOF proposal to be more descriptive?

Best regards,

	Teemu

---

From: marcelo bagnulo braun <[email-masked]>
Date: Thu, 05 Mar 2009 13:03:57 +0100

> Generally, I think name CPE relates more to a specific deployment scenario rather than to an entity that exist in protocol level as such. Thinking about CPEs may help to understand the functionalit…
Let's see

either the device that acquires the public v4 address and the port range 
uses them for its apps (this is the case where the host directly 
acquires the IP address and the port range)
or
the device that acquires the public IPv4 address and the port range is 
forwarding packets for apps running in other nodes, and it is performing 
the nat fucntion

correct?

> I agree, we could look at the internal side as well, but we can leave that for later as well.
fwiw, i think the focus should be in the external side, but i am not 
suggesting that the considerations of the internal side are out of 
scope. I personally beleive that any approach that does not support all 
the identified internal scenarios is a non starter, so that part is very 
relavant. Just that ther may the need for additional protocol work, that 
may be different for the IPv4 NAT than the one for the NAT64 case than 
the one of the host, so that is why, i think we should focus in the 
common part.

>  But do we then have to call that as distributed NAT, as doesn't the name choice hint on one aspect of the internal side functionality then? Rather "distributed addresses" or "distributed shared addresses" or something?
>
>   

SHARA approaches?

> Maybe the draft-townsley is not most up-to-date anymore - its missing discussion from interim, IETF#73, mailing list.. 
agree (n i think the authors agree as well)

> I brought this up because the name "distributed NAT" sounded for me like BOF would be focusing too much on distributed NATs (thus missing benefits apps could obtain from NATless communication), whi…

right

> Yes. I think it would be good to define this internal and external separation on BOF description and say we focus on external part first. Will you update the BOF proposal to be more descriptive?
i will
(Will wait for some additional feedback though)
thanks, marcelo

---

From: <[email-masked]>
Date: Thu, 5 Mar 2009 13:34:45 +0100

Dear all,

I fully agree with Teemu that the term "distributed NAT" is not appropriate with the proposed port range approaches. 

As for the scenario described by Teemu, the port-restricted device may be a CPE/HGW or a directly connected terminal. A NAT function may be hosted by those port-restricted devices.

Cheers,
Med

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]] De la part de [email-masked]
Envoyé : jeudi 5 mars 2009 12:51
À : [email-masked]
Cc : [email-masked]
Objet : Re: [shara] Updated SHARA BOF description

Hi Marcelo,

Yes.

Good description.

>I do agree that the distributed nat terminology is probably not the 
>best option, but we were trying to rely on the terminology used in 
>draft-townsley...

Best regards,

	Teemu

---

From: <[email-masked]>
Date: Thu, 5 Mar 2009 14:27:34 +0100

To coin a name that best describes shara BoF solution space

shara stands for "Sharing IPv4 Addresses"
Sharing IPv4 Addresses is the very generic target for all solutions that deal with IPv4 access in the context of IPv4 public address exhaustion

We can classify these solutions into two groups:
(1)CGN solutions 
(2)Non-CGN solutions

For me, basically, shara deals with (2)

What can we call (2)?
Why not simply "Non-CGN solutions"? It is my preference, it is genereic enough, it is simple to understand, it emphazises that a very important feature is that you don't use a CGN (and possibly no NAT at all as pointed out by Teemu)

"distributed shared addresses": sounds also good to me, well describe the current proposals
"Shara approaches" looks like a tautology to me, shara is talking about shara 

Pierre

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]] De la part de [email-masked]
Envoyé : jeudi 5 mars 2009 13:35
À : [email-masked]; [email-masked]
Cc : [email-masked]
Objet : Re: [shara] Updated SHARA BOF description

Dear all,

Cheers,
Med

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]] De la part de [email-masked] Envoyé : jeudi 5 mars 2009 12:51 À : [email-masked] Cc : [email-masked] Objet : Re: [shara] Updated SHARA BOF description

Hi Marcelo,

Yes.

Good description.

Best regards,

	Teemu

---

From: Rémi Després <[email-masked]>
Date: Thu, 05 Mar 2009 14:42:02 +0100

Marcello,

I agree with Teemu that "Distributed NAT" should not be used as a 
generic term for the solution space.

Among alternatives, I like "Port-Extended IPv4 addressing". It seems to 
be general enough.
 
In this framework:
- some CPEs will use ISP provided "Private IPv4 addresses", with some 
NATs used in ISP infrastructures, and dynamic port sharing. This is the 
"provider-NAT" based approach (note that the term CGN has faced various 
objections, from James Woodyatt in particular).
- some CPEs will use "Port-Restricted IPv4 addresses", without NAT used 
in ISP infrastructures, and static port sharing. This is the Port-range" 
based approach.

Regards,
RD

marcelo bagnulo braun  -  le (m/j/a) 3/5/09 1:03 PM:
>>  But do we then have to call that as distributed NAT, as doesn't the 
>> name choice hint on one aspect of the internal side functionality 
>> then? Rather "distributed addresses" or "distributed shared 
>> addresses" or something?  
>
> SHARA approaches?

---

From: <[email-masked]>
Date: Thu, 5 Mar 2009 15:09:36 +0100

I think Rémi's proposal exactly covers the distinction I made.

So I'm fine with this proposal, with a CPE being either a host or a router

Pierre

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]] De la part de Rémi Després
Envoyé : jeudi 5 mars 2009 14:42
À : marcelo bagnulo braun
Cc : [email-masked]
Objet : Re: [shara] Updated SHARA BOF description

Marcello,

I agree with Teemu that "Distributed NAT" should not be used as a generic term for the solution space.

Among alternatives, I like "Port-Extended IPv4 addressing". It seems to be general enough.
 
In this framework:
- some CPEs will use ISP provided "Private IPv4 addresses", with some NATs used in ISP infrastructures, and dynamic port sharing. This is the "provider-NAT" based approach (note that the term CGN has faced various objections, from James Woodyatt in particular).
- some CPEs will use "Port-Restricted IPv4 addresses", without NAT used in ISP infrastructures, and static port sharing. This is the Port-range" 
based approach.

Regards,
RD