Re: [shara] SHARA scenarios

[<[e-mail]>]

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: [e-mail] [mailto:[e-mail]] 
>On Behalf Of ext marcelo bagnulo braun
>Sent: 28 February, 2009 21:47
>To: [e-mail]
>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.
>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
>