[shara] SHARA scenarios

marcelo bagnulo braun <marcelo@it.uc3m.es> Sat, 28 February 2009 19:46 UTC

Return-Path: <marcelo@it.uc3m.es>
X-Original-To: shara@core3.amsl.com
Delivered-To: shara@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BC8CC3A6848 for <shara@core3.amsl.com>; Sat, 28 Feb 2009 11:46:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.176
X-Spam-Level:
X-Spam-Status: No, score=-6.176 tagged_above=-999 required=5 tests=[AWL=0.423, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4twxR1Xtd+NO for <shara@core3.amsl.com>; Sat, 28 Feb 2009 11:46:13 -0800 (PST)
Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.176.132]) by core3.amsl.com (Postfix) with ESMTP id 609803A6A14 for <shara@ietf.org>; Sat, 28 Feb 2009 11:46:12 -0800 (PST)
Received: from marcelo-bagnulos-macbook-pro.local (231.pool85-53-147.dynamic.orange.es [85.53.147.231]) by smtp02.uc3m.es (Postfix) with ESMTP id 9EFEE65A123 for <shara@ietf.org>; Sat, 28 Feb 2009 20:46:34 +0100 (CET)
Message-ID: <49A99499.9090008@it.uc3m.es>
Date: Sat, 28 Feb 2009 20:46:33 +0100
From: marcelo bagnulo braun <marcelo@it.uc3m.es>
User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209)
MIME-Version: 1.0
To: shara@ietf.org
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-TM-AS-Product-Ver: IMSS-7.0.0.3116-5.6.0.1016-16492.001
Subject: [shara] SHARA scenarios
X-BeenThere: shara@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Sharing of an IPv4 Address discussion list <shara.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/shara>, <mailto:shara-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/shara>
List-Post: <mailto:shara@ietf.org>
List-Help: <mailto:shara-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/shara>, <mailto:shara-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 28 Feb 2009 19:46:14 -0000

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