Re: [shara] SHARA scenarios

[<[e-mail]>]

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 : [e-mail] [mailto:[e-mail]] De la part de marcelo bagnulo braun
Envoyé : samedi 28 février 2009 20:47
À : [e-mail]
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

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

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

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.

I think these are the scenarios where A+P can be used, am i missing any?

Regards, marcelo






_______________________________________________
shara mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/shara