[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
- [shara] SHARA scenarios marcelo bagnulo braun
- Re: [shara] SHARA scenarios Rémi Després
- Re: [shara] SHARA scenarios pierre.levis
- Re: [shara] SHARA scenarios teemu.savolainen