Re: [shara] SHARA scenarios

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
> shara@ietf.org
> https://www.ietf.org/mailman/listinfo/shara
> 