Subject: Re: [shara] SHARA scenarios

From: Rémi Després <[email-masked]>
Date: Mon, 02 Mar 2009 11:20:46 +0100

Hi, Marcello,

In my understanding, applicability of "Port Restricted" IPv4
addressing (PR-v4) is as follows:

  +--------+                            +-------+
-+        +============tunnel==========+       +---------------
  +--------+                            +-------+
    PR NAT  <-----------PR-v4 ---------->PR router<--- IPv4----
or PR router        over IPv6                          or
or PR host       or over private v4              <--- PR-v4---
                  or over p2p link                  over IPv6
                                                 or over private v4
                                                 or over p2p link

Whether the port restricted NAT is NAT44 or NAT64 should therefore 
remain orthogonal the port-restricted IPv4 model (scenarios with NAT64 
must be supported).

More comments below.

Regards
RD

marcelo bagnulo braun  -  le (m/j/a) 2/28/09 8:46 PM:
> Hi,
> 
> I am trying to understand the scenarios the apply to shara. In other 
> words, whcih are the use cases for A+P type of solutions.
> Looking into draft-arkko-townsley-coexistence-00, they identify that the 
> following scenarios where the A+P (or distributed NAT approaches) can be 
> used.
> The problem that A+P attempts to solve is defined in section 2.1. 
> Reaching the IPv4 Internet
> 
>                    +----+                       +---------------+
>   IPv4 host(s)-----+ GW +------IPv4-------------| IPv4 Internet |
>                    +----+                       +---------------+
> 
>   <---private v4--->NAT<--------------public v4----------------->
> 
> 
>            Figure 1: Accessing the IPv4 Internet today
> 
> 
> ...
> 
>   Taking the typical residential subscriber as an example, each
>   subscriber line is allocated one global IPv4 address for it to use
>   with as many devices as the NAT GW and local network can handle.  As
>   IPv4 address space becomes more constrained and without substantial
>   movement to IPv6, it is expected that service providers will be
>   pressured to assign a single global IPv4 address to multiple
>   subscribers.  Indeed, in some deployments this is already the case.
> 
> 
> So, they identify the following A+P deployment possibilities.
> 
> 
>                 one frac addr            one public addr
>                    +----+                   +---+  +-------------+
>   IPv4 host(s)-----+ GW +-----p2p link------+CGN+--+IPv4 Internet|
>                    +----+                   +---+  +-------------+
> 
>   <---private v4--->            NAT             <----public v4--->
>                             (distributed,
>                           over a p2p link)
> 
> 
>               Figure 3: Distributed-NAT service
> 
> and
> 
>                 one frac addr            one public addr
>                    +----+                   +---+  +-------------+
>   IPv4 host(s)-----+ GW +======tunnel=======+CGN+--+IPv4 Internet|
>                    +----+                   +---+  +-------------+
> 
>   <---private v4--->            NAT             <----public v4--->
>                            (distributed,
>                            over a tunnel)
> 
> 
>          Figure 4: Point-to-point link created through a tunnel
> 
> These seem clear cases for A+P.
RD> YES
> 
> Next, it seems that the above cases can be combined with the problem 
> they describe in section 2.2. Running out of IPv4 Private Address Space, 
> in particular with the following scenario:
> 
>                            IPv6-only network
>                    +----+                     +---+  +-------------+
>   IPv4 host--------+ GW +=======tunnel========+CGN+--+IPv4 Internet|
>                    +----+                     +---+  +-------------+
> 
>   <---private v4---->  <-----  v4 over v6 ----->  <---public v4---->
> 
> 
>             Figure 5: Running IPv4 over IPv6-only network
> 
> 
> I understand that this case is simply changing the tunnel technology 
> used in the figure 4 above, so current A+P proposals should work without 
> much problem in this scenario as well. Would this be correct?
RD> YES
> In any case, imho there are a couple of observations to make:
> - IMHO it is important that whatever A+P solution supports the above 
> scenario and this should be explicitly included in the scope of the work
> - I understand the work to support this scenario is being done in the 
> sofwires WG, so i think it would be important to understand how the A+P 
> solution would interact with the dula stack lite mechanism defined in 
> softwires to support this scenario. Does anyone can shed some light on 
> this?
> 
> Now, i think there is another scenario that it is related to the A+P, 
> that is also covered in draft-arkko-townsley-coexistence-00
> Section 2.3. Enterprise IPv6 Only Networks describes a site that is 
> running only IPv6.
> The proposed approach to support this scenario is depicted in the draft 
> as follows:
> 
>                             +----+                  +-------------+
>                             |    +------------------+IPv6 Internet+
>                             |    |                  +-------------+
>   IPv6 host-----------------+ GW |
>                             |    |                  +-------------+
>                             |    +------------------+IPv4 Internet+
>                             +----+                  +-------------+
> 
>   <-------------------------public v6----------------------------->
>   <-------public v6--------->NAT<----------public v4-------------->
> 
> 
>            Figure 7: Enterprise IPv6-only network
> 
> 
> Now, i think that we need to analyse this situation a bit more in depth 
> in order to understand how this related to A+P type of solutions.
RD> For PR-v4 to apply, "public IPv4" has just to be replaced by "PR-v4" 
  (which implies that some PR router, doing PR-v4 over IPv6, is 
available somewhere in the ISP infrastructure).

> 
> The GW depicted in the picture, will be an IPv6 to IPv4 translator (AKA 
> NAT64). The NAT64 as a regular NAT, needs a  public IPv4 address in the 
> "external" side. This implies that the same considerations of IPv4 
> public address shortage will apply to the NAT64 scenarios.
> 
> So, similarly to the NAT cases described above, there are two deployment 
> models for NAT64. Either we will have a carrier grade NAT64 deeper in 
> the ISP network, or we can have A+P approaches in NAT64, where the NAT64 
> is located in the edge between the IPv6 only site and its ISP. the NAT64 
> in this case, would obtain a public IPv4 address and a port range.
> 
> I think it is important that any A+P effort supports also the NAT64 
> case. I think this is important cause, if we think that the A+P approach 
> has some advantages over the CGA approach, and we make only the CGA 
> approach available to the users running IPv6 only networks, we are 
> creating a disadvantage for the IPv6 adopters, which i guess is exactly 
> what we don't want to do at this stage. I mean, f for isntance, p2p apps 
> work with A+P type of approaches and don't work with CGN and if A+P is 
> available only for IPv4 users and the only thing available for IPv6 
> users is CGN NAT64, then people would be even more reluctant to adopt 
> IPv6. So, my point here is that we should support this scenario as well.
> At this point, i would like to understand whether the current proposed 
> A+P approaches can support this scenario and if not how much work is 
> needed to support it... if someone could comment on this it would be 
> appreciated.
RD> Agreed. Wherever PR-v4 and NAT64 are appropriate, their combination 
should be appropriate too.
> 
> I think these are the scenarios where A+P can be used, am i missing any?
> 
> Regards, marcelo
> 
> 
> 
> 
> 
> 
> _______________________________________________
> shara mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/shara
>

---

From: <[email-masked]>
Date: Mon, 2 Mar 2009 12:49:37 +0100

Hi Marcelo,

I will try to address your comments and questions.

First the scope and vocabulary, I think it is worth to clarify.

shara problem: IPv4 Internet access in the context of IPv4 public address exhastion

shara overall mechanism: allocate one IPv4 public address to several customers at the same time, hence the name shara for shared address

shara solution space: there are several ways to classify the solutions, I guess the most meaningful one is:

(1) CGN-based solutions 
Solutions that propose the introduction of a NAPT function in the ISP network, denoted also as Carrier Grade NAT (CGN). 
The CGN is responsible for translating IP packets issued with private addresses to ones with publicly routable IPv4 addresses.
  
(2) non CGN-based solutions
Solutions that avoid the introduction of a NAT in the ISP network. 
They allocate the same IP public address to several customers at the same time.  They also allocate a restricted port range to each customer so that two customers with the same IP address have two different portranges that do not overlap.

Names & Proposals:
(1)
DS-lite[ID.durand-softwire-dual-stack-lite]
(2)
A+P [ID.ymbk-aplusp]
Port Range [I-D.bajko-pripaddrassign], [I-D.boucadair-port-range], [ID.boucadair-behave-ipv6-portrange] 
Stateless Address Mappings (SAMs) [ID.despres-sam)]
An other name, sometimes used: Fractionnal Address

No matter how the CGN works, what you refer as Figures 3, 4 and 5 belongs to category 1 because there is a CGN. A solution which uses a CGN that restricts the choice of source port values to a customer specific range belongs to category 1.

All solutions put a specific function in the ISP network:
A CGN for category 1
                    +---+                   +---+  +-------------+
   IPv4 host(s)-----+CPE+-------------------+CGN+--+IPv4 Internet|
                    +---+                   +---+  +-------------+
If there is a NAT in the CPE it is the Double NAT solution, if there is no NAT in the CPE (and IPv6 tunnelling) it is DS-lite solution.

A port-aware router for category 2 (called a PRR Port range Router, or a Gateway)

                    +---+                   +---+  +-------------+
   IPv4 host(s)-----+CPE+-------------------+PRR+--+IPv4 Internet|
                    +NAT+                   +---+  +-------------+
                    +---+                   

Now, about IPv6, for category 2, we have the following scenarios:

Dual-Stack: hosts and CPE dual-stack; IPv4 hosts to IPv4 Internet, IPv6 hosts to IPv6 Internet 

DS-lite-like scenario: hosts dual-stack, CPE IPv6-only provisionned; IPv4 hosts to IPv4 Internet, IPv6 hosts to IPv6 Internet

NAT64 scenario: hosts IPv6-only, CPE IPv6-only provisionned; IPv6 hosts to IPv4 and IPv6 Internet

Best Regards

Pierre

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]] De la part de marcelo bagnulo braun
Envoyé : samedi 28 février 2009 20:47
À : [email-masked]
Objet : [shara] SHARA scenarios

Hi,

I am trying to understand the scenarios the apply to shara. In other words, whcih are the use cases for A+P type of solutions.
Looking into draft-arkko-townsley-coexistence-00, they identify that the following scenarios where the A+P (or distributed NAT approaches) can be used.
The problem that A+P attempts to solve is defined in section 2.1. 
Reaching the IPv4 Internet

                    +----+                       +---------------+

...

and

Next, it seems that the above cases can be combined with the problem they describe in section 2.2. Running out of IPv4 Private Address Space, in particular with the following scenario:

                            IPv6-only network

I understand that this case is simply changing the tunnel technology used in the figure 4 above, so current A+P proposals should work without much problem in this scenario as well. Would this be correct?
In any case, imho there are a couple of observations to make:
- IMHO it is important that whatever A+P solution supports the above scenario and this should be explicitly included in the scope of the work
- I understand the work to support this scenario is being done in the sofwires WG, so i think it would be important to understand how the A+P solution would interact with the dula stack lite mechanism defined in softwires to support this scenario. Does anyone can shed some light on this?

Now, i think there is another scenario that it is related to the A+P, that is also covered in draft-arkko-townsley-coexistence-00
Section 2.3. Enterprise IPv6 Only Networks describes a site that is running only IPv6.
The proposed approach to support this scenario is depicted in the draft as follows:

                             +----+                  +-------------+

Now, i think that we need to analyse this situation a bit more in depth in order to understand how this related to A+P type of solutions.

The GW depicted in the picture, will be an IPv6 to IPv4 translator (AKA NAT64). The NAT64 as a regular NAT, needs a  public IPv4 address in the "external" side. This implies that the same considerations of IPv4 public address shortage will apply to the NAT64 scenarios.

So, similarly to the NAT cases described above, there are two deployment models for NAT64. Either we will have a carrier grade NAT64 deeper in the ISP network, or we can have A+P approaches in NAT64, where the NAT64 is located in the edge between the IPv6 only site and its ISP. the NAT64 in this case, would obtain a public IPv4 address and a port range.

I think it is important that any A+P effort supports also the NAT64 case. I think this is important cause, if we think that the A+P approach has some advantages over the CGA approach, and we make only the CGA approach available to the users running IPv6 only networks, we are creating a disadvantage for the IPv6 adopters, which i guess is exactly what we don't want to do at this stage. I mean, f for isntance, p2p apps work with A+P type of approaches and don't work with CGN and if A+P is available only for IPv4 users and the only thing available for IPv6 users is CGN NAT64, then people would be even more reluctant to adopt IPv6. So, my point here is that we should support this scenario as well.
At this point, i would like to understand whether the current proposed 
A+P approaches can support this scenario and if not how much work is
needed to support it... if someone could comment on this it would be appreciated.

Regards, marcelo

---

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

Hi,

There's also a scenario:

    one frac addr                 one public addr
    +-----------+                   +-------+  +-------------+
    + IPv4 host +-----p2p link------+Gateway+--+IPv4 Internet|
    +-----------+                   +-------+  +-------------+
                 <----public v4--->
                   (distributed,
                  over a p2p link)

Where there's no NAT whatsoever, just port restricted IPv4 address (possibly tunneled over IPv6)

And

    one frac addr                  one public addr
    +-----+-----+                   
    + NAT +     +
    +-----+     +                   +-------+  +-------------+
    + IPv4 host +-----p2p link------+Gateway+--+IPv4 Internet|
    +-----------+                   +-------+  +-------------+
                 <----public v4--->
                   (distributed,
                  over a p2p link)

Where the NAT is inside the IPv4 host for those apps or protocols that are not able to live with port restrictions. I.e. merged GW+host. In this case the NAT can be instead in CGN, in which case host would send both packets (possibly over IPv6 tunnel like in DS-Lite) with private IPv4 addresses as source address for CGN to be NATted, and packets with public IPv4 address as source that just need routed by the port.

Best regards,

	Teemu

>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]] 
>On Behalf Of ext marcelo bagnulo braun
>Sent: 28 February, 2009 21:47
>To: [email-masked]
>Subject: [shara] SHARA scenarios
>
>Hi,
>
>I am trying to understand the scenarios the apply to shara. In 
>other words, whcih are the use cases for A+P type of solutions.
>Looking into draft-arkko-townsley-coexistence-00, they 
>identify that the following scenarios where the A+P (or 
>distributed NAT approaches) can be used.
>Next, it seems that the above cases can be combined with the 
>problem they describe in section 2.2. Running out of IPv4 
>Private Address Space, in particular with the following scenario:
>
>                            IPv6-only network
>I understand that this case is simply changing the tunnel 
>technology used in the figure 4 above, so current A+P 
>proposals should work without much problem in this scenario as 
>well. Would this be correct?
>- IMHO it is important that whatever A+P solution supports the 
>above scenario and this should be explicitly included in the 
>scope of the work
>- I understand the work to support this scenario is being done 
>in the sofwires WG, so i think it would be important to 
>understand how the A+P solution would interact with the dula 
>stack lite mechanism defined in softwires to support this 
>scenario. Does anyone can shed some light on this?
>
>Now, i think there is another scenario that it is related to 
>the A+P, that is also covered in draft-arkko-townsley-coexistence-00
>Now, i think that we need to analyse this situation a bit more 
>in depth in order to understand how this related to A+P type 
>of solutions.
>
>The GW depicted in the picture, will be an IPv6 to IPv4 
>translator (AKA NAT64). The NAT64 as a regular NAT, needs a  
>public IPv4 address in the "external" side. This implies that 
>the same considerations of IPv4 public address shortage will 
>apply to the NAT64 scenarios.
>
>So, similarly to the NAT cases described above, there are two 
>deployment models for NAT64. Either we will have a carrier 
>grade NAT64 deeper in the ISP network, or we can have A+P 
>approaches in NAT64, where the NAT64 is located in the edge 
>between the IPv6 only site and its ISP. the NAT64 in this 
>case, would obtain a public IPv4 address and a port range.
>
>I think it is important that any A+P effort supports also the 
>NAT64 case. I think this is important cause, if we think that 
>the A+P approach has some advantages over the CGA approach, 
>and we make only the CGA approach available to the users 
>running IPv6 only networks, we are creating a disadvantage for 
>the IPv6 adopters, which i guess is exactly what we don't want 
>to do at this stage. I mean, f for isntance, p2p apps work 
>with A+P type of approaches and don't work with CGN and if A+P 
>is available only for IPv4 users and the only thing available 
>for IPv6 users is CGN NAT64, then people would be even more 
>reluctant to adopt IPv6. So, my point here is that we should 
>support this scenario as well.