Subject: I-D Action:draft-ietf-v6ops-nat64-pb-statement-req-00.txt

From: [email-masked]
Date: Tue, 13 May 2008 16:30:01 -0700 (PDT)

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the IPv6 Operations Working Group of the IETF.

	Title           : IPv4/IPv6 Coexistence and Transition: Requirements for solutions
	Author(s)       : M. Bagnulo, et al.
	Filename        : draft-ietf-v6ops-nat64-pb-statement-req-00.txt
	Pages           : 17
	Date            : 2008-05-13

This note presents the problem statement, analysis and requirements
for solutions to IPv4/IPv6 coexistence and eventual transition in a
scenario in which dual stack operation is not the norm.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-v6ops-nat64-pb-statement-req-00.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: marcelo bagnulo braun <[email-masked]>
Date: Wed, 14 May 2008 23:48:44 +0200

Hi,

we have submitted the new version of the requirements for translators

AFAICT one issue that needs to be decided is whether we need solutions 
both for v4 initiated solution and v6 initiated solution or it is enough 
to hav solutions for v6 initiated solutions, especially without 
requiring modifications to the v4 nodes.

During some of the discussion, for instance during the one on DNSSec, 
people have expressed that they don't feel that we need to require 
DNSSec support for v4 initiated communications cause these where not 
relevant.

So, i guess we need to define this

comments?

Regards, marcelo

---

From: <[email-masked]>
Date: Thu, 15 May 2008 11:29:58 +0300

Hi,

I agree with the document, with following comments:

In cellular environments it can actually be the mobile phone that is provided IPv6-only connectivity by the network, and the mobile needs to act the role of CPE (to be more exact, the mobile with IPv6-only connectivity may be running IPv4-only apps and it may have IPv4 LAN behind it, for which mobile needs to provide (NATted) addresses). These devices are not manually configurable (provisionable they are, though) and often not easily software upgradable. These devices are also very many and thus transition solutions must be scalable especially on the core network side (imagine operator with 100 million devices connected with IPv6-only and simultaneously asking for IPv4 translation services for high speed data sessions).

The cellular terminals are often on the move - the transition mechanism discovery and setup ought to be very quick process (i.e. during movement users are not happy to wait as long as in system startup and initial connection creation phase). This is also essential in network selection phase - if there are multiple networks available (e.g. WLAN hot-spots) the availability of transition mechanisms might have impact on network selection, and if possible the unavailability should be quickly detectable for fast failures & fallbacks.

In my opinion the modifications should be done only for new/upgradable IPv6-enabled nodes and only for IP-layer, as IPv6 is not widely used yet and as legacy IPv4 applications (running on IPv6-capable nodes) need to be supported as well. 

One aspect on these transition mechanisms is placement of NAT(s) (4-4, 4-6, 6-4) and required ALGs, i.e. whether those are on client itself, on gateway, or nowhere (APBP kind of approach). Different approaches have different pros and cons, which should be studied more. The placement likely affects at least on scalability of the solution.

Thus for chapter 2.2/4.1. I propose additions of:
- Translation architectures SHOULD be scalable for large numbers of hosts and high data speeds
- Availability of translation mechanism service SHOULD be quickly discoverable 
- Legacy IPv4-only applications on IPv6-nodes MUST continue working

I say SHOULD instead of MUST, as there surely are deployment scenarios where scalability is not an issue or where discovery process can be slow.

For chapter 3.5 I'd like to add Symbian as one well-known and widely used OS. There are also great volumes of vendor proprietary OS'es. 

It should be acknowledged (if its not) that quite likely not a single transition solution will be suitable for everybody:
- operator/organization with relatively large IPv4 address pool might prefer IPv4-over-IPv6 tunneling (static or dynamic) - i.e. long term lease of full IPv4 address to clients
- operator/organization with relatively small IPv4 address pool might prefer translation or DSTM/APBP kinds of approaches - i.e. short term lease of IPv4 address(&port) to clients
- operator/organization who deploys DSMIP or VPNs might want to use those as transition mechanism
- operator/organization with large subscriber base (100s of millions ) might need more scalable solutions than operator with small subscriber base (e.g. smaller than RFC1918 address space)
- ....

Best regards,

	Teemu

>-----Original Message-----
>From: [email-masked] 
>[mailto:[email-masked]] On Behalf Of ext marcelo 
>bagnulo braun
>Sent: 15 May, 2008 00:49
>To: [email-masked]
>Subject: Re: I-D Action:draft-ietf-v6ops-nat64-pb-statement-req-00.txt
>
>Hi,
>
>AFAICT one issue that needs to be decided is whether we need 
>solutions both for v4 initiated solution and v6 initiated 
>solution or it is enough to hav solutions for v6 initiated 
>solutions, especially without requiring modifications to the v4 nodes.
>
>During some of the discussion, for instance during the one on 
>DNSSec, people have expressed that they don't feel that we 
>need to require DNSSec support for v4 initiated communications 
>cause these where not relevant.
>

---

From: marcelo bagnulo braun <[email-masked]>
Date: Thu, 15 May 2008 11:43:02 +0200

Hi Teemu

thanks for the comments

see comments below...

[email-masked] escribió:

> - Translation architectures SHOULD be scalable for large numbers of hosts and high data speeds
that certainly makes sense to me,
would you include it in the basic requirements (MUST) or in the SHOULD? 
(i mean you phrase it as a should but you propose to include it 4.1)

> - Availability of translation mechanism service SHOULD be quickly discoverable 
I also agree with this one, probably in section 4.2?

> - Legacy IPv4-only applications on IPv6-nodes MUST continue working

I am not sure this has to do with the translation mechanisms that we are 
considering at this point... I mean, what we are considering here AFAIU, 
is a new box that you include in between the v4 world and the v6 world, 
so that they can communicate. There may require some modifications to 
the v6 host.
For that it seems to me that this is somehow different transition tool, 
that fits in a different scenario?

So, i don't see this clear...

> For chapter 3.5 I'd like to add Symbian as one well-known and widely used OS. There are also great volumes of vendor proprietary OS'es. 
makes sense to me

> - operator/organization with large subscriber base (100s of millions ) might need more scalable solutions than operator with small subscriber base (e.g. smaller than RFC1918 address space)
could you provide text of where and what you propose to include as you 
did in the previous items?

Thanks, marcelo

>>> A New Internet-Draft is available from the on-line 
>>>       
>> Internet-Drafts directories.
>>     
>>> This draft is a work item of the IPv6 Operations Working 
>>>       
>> Group of the IETF.
>>     
>>> 	Title           : IPv4/IPv6 Coexistence and Transition: 
>>>       
>> Requirements for solutions
>>     
>> http://www.ietf.org/internet-drafts/draft-ietf-v6ops-nat64-pb-statemen
>>     
>>> t-req-00.txt
>>>

---

From: <[email-masked]>
Date: Thu, 15 May 2008 17:08:20 +0300

Hi Marcelo,

Inline,

>(i mean you phrase it as a should but you propose to include it 4.1)

I originally though it to be MUST, but then I started thinking that in
some environments other properties than scalability may be of priority,
and as scalability is somewhat subjective concept, I ended up with
SHOULD. It is very hard to be exact on scalability requirements, but I
believe we will nevertheless be able to compare different proposals from
that point of view. See below for proposal.

>I also agree with this one, probably in section 4.2?

Yes, for same reasons. I added requirement of one RTT. See below for
proposal.

>I am not sure this has to do with the translation mechanisms 
>that we are considering at this point... I mean, what we are 
>considering here AFAIU, is a new box that you include in 
>between the v4 world and the v6 world, so that they can 
>communicate. There may require some modifications to the v6 host.
>For that it seems to me that this is somehow different 
>transition tool, that fits in a different scenario?

Excluding RFC2766 NAT-PT kind of single box solutions (is there others
than RFC2766?), all actually implement two (or more) logical boxes - one
near/on the v6 host and one further away with IPv4 interface (all
tunneling solutions, and also NATv4v6v4 and MNAT-PT), right?

The "I2: operational flexibility" says that "It should be possible to
locate the translation device at an arbitrary point in the network (i.e.
not at fixed points such as a site exit), so that there is full
operational flexibility.". I would read that sentence so that if the
"translation device" is actually two logical functions, then the other
end can locate inside the v6 host as well (i.e. between the small
internal v4 world and v6 world), if seen useful from operational
flexibility point of view. The other end of course is located in some
other device which has global IPv4 interface. 

From solution side at least DSTM/TSP/APBP utilize the possibility to
have great deal of the functionality in the v6 hosts themselves for
achieving scalability benefits (less load for single infrastructure
components, NAT/ALG avoidance). I added this to 4.3 below as MAY. I was
considering SHOULD, but as IPv4 world is so used to live with NATs and
my understanding is that current level of IPv4 support does not need to
be improved here, I ended up with MAY (this can be debated, surely:-)

>could you provide text of where and what you propose to 
>include as you did in the previous items?

Here are the proposed additions (old+some new):

2. Problem statement

It may be that a single transition mechanism is not able to address all
transition scenarios at optimal way. The transition mechanism should be
clear for which scenarios it has been designed for.

2.1.  Transition scenarios

Not every organization has the same starting point and resources
available for IPv6 transition. Namely availability of public IPv4
addresses and number of simultaneously served hosts differs. At least
following general scenarios can be identified, in which different
organizations can be at different moments of time:
o  Enough public IPv4 addresses to uniquely number each host in the
network
o  Enough private IPv4 addresses to uniquely number each host in the
network 
o  Not enough public and private IPv4 addresses to uniquely number each
host in the network without using parallel RFC1918 address spaces

It can be assumed that organizations have access to as many public IPv4
address and port combinations as there are simultaneously active IPv4
data connections.

2.1.2.  Transition scenarios that do not require translation

Organizations that have enough public or private IPv4 addresses can use
"start-time" tunnels, but for those lacking public and private IPv4
addresses "dynamic tunneling" is more favorable, as it does not consume
IPv4 addresses for IPv4-idle hosts.

2.1.3.  Transition scenarios that require translation

Translation is a potential solution for organizations facing shortage of
IPv4 addresses or who do not wish to provide IPv4 access network, but
who still need to provide IPv4 connectivity for legacy IPv4-only
applications running on IPv6 hosts or for hosts that are IPv6-only and
need to connect to IPv4-only services.

2.2.  Requirements for the overall transition strategy

8.  Transition architectures should be scalable for large number of
hosts and high data speeds.
9.  Availability of transition solutions on an access network should be
quickly discoverable.

4.2. Important things that SHOULD be supported

I9: Scalability

The translation mechanism SHOULD support very large number of hosts and
high data speeds with reasonable infrastructure requirements considering
equipment available at the transition timeframe.

I10: Discovery

The translation mechanism SHOULD be quickly discoverable, preferably in
one RTT, to help moving hosts better assess capabilities of available
access networks and to provide good user experience.

4.3. Important things that MAY be supported

M1: No NATs or ALGs

The translation mechanism MAY avoid use of IPv4 NATs and thus also avoid
need for ALGs. 

Best regards,

	Teemu

---

From: Philip Matthews <[email-masked]>
Date: Wed, 21 May 2008 10:15:00 -0400

Some comments on this draft, from the perspective of someone familiar  
with the various BEHAVE documents.

* R6 lists TCP, UDP, ICMP, and TLS as protocols to be supported. I am  
surprised that TLS is listed in addition to TCP, since full TCP  
support would imply TLS. I am also surprised that DTLS is not listed,  
if listing TLS is seen as necessary. Any explanation for this?

* R7 lists the BEHAVE requirement documents for TCP and UDP. Is there  
some reason for not listing the BEHAVE requirement document for ICMP?

* R8 talks about fragmented packets. Is there some reason to include  
this specifically, given that the BEHAVE requirements cover  
fragmentation in some detail? The BEHAVE requirements do not mention  
the 5 second stuff, but they talk about out-of-order fragments which  
R8 does not mention.

* I6 and I7 talk about SCTP and DCCP support. Is it acceptable to  
support these by transporting them over UDP?

* I8 talks about multicast. Should multicast support comply with the  
BEHAVE requirement document for multicast?

* A (long) comment on R2.
There is a class of applications that work today through NAT44s. As a  
general rule, these are applications that do not carry addresses  
embedded inside protocol messages, and have communication initiated by  
the host behind the NAT. Is this the same class of applications that  
should be supported by the proposed translation mechanism?

Code in a NAT that recognizes packets of a specific application  
protocol and does special processing of that packet is known as an ALG  
(Application Level Gateway). The BEHAVE group considers an FTP ALG to  
be acceptable, because FTP was there before NATs, but other ALGs are  
discouraged (= default off). Is this rule consistent with the proposed  
transition mechanism?  This rule is given in RFC 4787, which R7 says  
the mechanism must comply with.

If so, is R2 an attempt to formalize all this in different words?

- Philip

On Tue, 13-May-08, at 19:30 , [email-masked] wrote:
> <mime-attachment>

---

From: Rémi Després <[email-masked]>
Date: Wed, 21 May 2008 16:36:16 +0200

> So, i guess we need to define this

IMO, trying to propose solutions for v4 initiated communications at the 
same time as those for v6 initiated ones, would result into 
counterproductive delays.

Rationale:

- Dual stack hosts that have v6 connectivity and no public v4 address, 
and that have to  reach legacy v4-only servers, should have a better 
solution than through cascaded v4-to-v4 NATs.

- Dual stack hosts that have v4 addresses will most probably get also v6 
connectivity (possibly trough tunnels) well before v4 to v6 NATs can be 
specified, implemented and deployed.

Regards.

Rémi

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 22 May 2008 14:56:35 +1200

Teemu,

On 2008-05-16 02:08, [email-masked] wrote:
...
> other device which has global IPv4 interface. 

If you are still thinking of a mobile device that is acting as an
interworking unit between a local IPv4 network and an IPv6 world,
it seems to me you are loading it up with CPU and memory and battery
power needs that are unreasonable. I agree that we shouldn't restrict
where the various functions can be placed, but it seems desirable to
minimise what is needed in mobile devices.

     Brian

---

From: <[email-masked]>
Date: Thu, 22 May 2008 10:55:46 +0300

>If you are still thinking of a mobile device that is acting as 
>an interworking unit between a local IPv4 network and an IPv6 
>world, it seems to me you are loading it up with CPU and 
>memory and battery power needs that are unreasonable. I agree 

On mobile the resource needs for NATting/translating are not very
significant when compared to resources needed to transmit data (e.g.
video) on WLAN/HSPA/EVDO/LTE/WiMAX speeds at the first place (or having
a VPN for encryption for those speeds, which is a supported feature on
some products). There are already cellular phones on market that come
with DHCP server and NAT for IPv4->IPv4 case (Bluetooth PAN->cellular).

There are also companies implementing software for cellular WLAN
hot-spot kind of features, see e.g.:
- JoikuSpot http://www.joikuspot.com/ (free)
- Walkinghotspot http://www.walkinghotspot.com/

Generally the power consumption with high data rates is a significant
factor and an area of constant research/optimization. However, if people
have to choose between not to have a high speed data access at all, or
have a high speed data access for half a day or so when running on
battery and indefinitely when near mains, they choose to have the
feature. The keep-alives are the biggest problem as they eat the standby
time without giving clear benefits for users.

I also tend to believe that people do most of the data transmission when
they are rather still and near mains - e.g. at visited office, at home,
at summer cottage, or e.g. in train (in Finland the better trains have
power available on certain seats). 

Furthermore, the mobile device does not necessarily have to be handheld,
it can be an USB-stick which gets power from PC, or it can be a fixed
device e.g. in a car/bus/table that acts as WLAN AP for nearby devices
and uses cellular network as WAN. 

An alternative is to make mobile devices IPv6-only, but that would
introduce flag-day kind of problems:
- convince people that they should upgrade their old IPv4-only
applications/devices (is this really a possibility?)
- place the burden of doing IPv4-over-IPv6 to other devices (e.g.
laptops)
=> this solution has the problem of
not-providing-so-nice-transition-experience and also that for some
software there might not be IPv6-support available (in time) - an
important example is Java MIDP 2.0 runtime environment, which is
IPv4-only. MIDP 3 is bringing IPv6 support (optional), but that is not
yet approved standard. I.e. if transition would happen by large next
year, we probably would have to provide support for IPv4-only devices,
applications and run-time environments, but maybe 5 years from now
different approach would be possible.

>that we shouldn't restrict where the various functions can be 
>placed, but it seems desirable to minimise what is needed in 
>mobile devices.

True, but if IPv6-only is not practical option (see above), is native
dual-stack (for mobile device, for last-mile) always the most
cost-efficient solution? 

Consider a cellular operator with 100 million customers needing
simultaneous network connectivity. Which is the cheapest architecture
for them (I don't know the right answer):
1) provide native dual-stack air interface ("last mile") 
2) provide translator box (e.g. NAT-PT, MNAT-PT, NATv4v6v4)
3) provide static tunneling (e.g. configured tunnels (via provisioning),
SNAT, VPN, DSMIP)
4) provide dynamic tunneling (e.g. TSP)

1) requires resources for transmitting both address families over the
air interface/last mile. These resources include at least IPv4 address,
plus in some technologies also more resources from the first hop router
(in 3GPP this requires two parallel PDP contexts and thus more
powerful/costly GGSN). The IPv4 address could be conserved by on-demand
reservation, but if the on-demand reservation requries closing/opening
link-layers (e.g. PDP contexts) and thus brings in latencies, does that
provide good user experience?

2) Don't these require ALG support for either NAT-PT box, or also on the
mobile host in case MNAT-PT/NATv4v6v4 is implemented there? E.g. even if
application uses synthetic IPv4 source address and thus knows there is a
NAT on the path, the "client-side" of MNAT-PT/NATv4v6v4 needs to
implement IPv4->IPv6 ALG? (in the original NAT-PT this ALG would be only
on the NAT-PT box). ALG implementation burden to all mobile devices does
not sound very attractive.

3) Has the biggest header overhead and also requires IPv4 address. I
believe these solutions also introduce biggest requirements for tunnel
endpoint performance? 

4) Aren't these kind of solutions performance-wise most optimal? No NAT,
no ALG, and the tunnel-endpoint load is the lowest?

I would be happy if we would end up with just a single solution, but I
think we may need several for different deployment scenarios (which are
the used access technologies, how many simultaneous customers need to be
served, how heavily IPv4 addresses need to be conserved) and for
different moments of time (what is the level of IPv6-support in
softwares/hardwares/services). 

E.g. 
1) dual-stack could be a solution for home deployments
(DSL/hotspot-style, from CPE box to LAN)
2) translators for further in the future when IPv6 is widely supported
by applications/devices
3) static tunneling for more demanding use-cases such as where public
IPv4 address is required, for enterprises VPN uses, where mobility is
required, or for infrastructure (e.g. used to provide IPv4 connectivity
to that CPE box/WLAN hot-post)
4) dynamic tunneling for cases where subscriber base is very large and
IPv4 applications/devices that need to be supported are many?

Best regards,

	Teemu

---

From: Rémi Després <[email-masked]>
Date: Thu, 22 May 2008 15:06:14 +0200

Marcelo,

The scope of the draft being (quite rightly) comprehensive, a mention of 
scenarios based on APBP should IMU be included.
These scenarios fit in:
- the 3rd scenario of section 2.1 (an IPv4 system connecting to an IPv4 
system across an IPv6 network),
- the 6th scenario (IPv6 system connecting to an IPv4 system),

Their raison d'être is that, unlike those described in section 2.1.3, 
they DO NOT require any NAT64.

(Explanations on APBP, address-port-borrowing-protocol, are in
http://www.ietf.org/internet-drafts/draft-despres-v6ops-apbp-00.txt.)

This complement could be inserted, for example, as follows:

(A)
Title 2.1.2 becomes:
  "2.1.2 Transition scenarios that do not require NAT64
   2.1.2.1 Tunnel scenarios"

(B)
Title 2.1.3 becomes:
  "2.1.2.2 Address-port-borrowing-protocol scenarios
    <Some text on these scenarios, with a Work in Progress reference>
   2.1.3  Transition scenarios that do not require NAT64"

If the principle has some support, I can work on a text for the new 
section  2.1.2.2.

Regards

Rémi

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Sun, 25 May 2008 00:44:06 +0200

On 15 mei 2008, at 10:29, <[email-masked]> <[email-masked] 
 > wrote:

>
> In cellular environments it can actually be the mobile phone that is  
> provided IPv6-only connectivity by the network, and the mobile needs  
> to act the role of CPE (to be more exact, the mobile with IPv6-only  
> connectivity may be running IPv4-only apps and it may have IPv4 LAN  
> behind it, for which mobile needs to provide (NATted) addresses).

[...]

> - Legacy IPv4-only applications on IPv6-nodes MUST continue working

The problem with IPv4-only applications in an IPv6 world is that there  
is no way to encode all possible IPv6 destinations into an IPv4  
header. However, the case where the ultimate destination is also IPv4  
and it's just the network in the middle that's IPv4 is much easier.

In a previous modified-nat-pt draft I wrote about the v4-v6-v4 case  
where IPv4 clients sit behind a CPE or layer in the stack that  
translates their IPv4 packets into IPv6 packets using SIIT (=  
stateless) and then the resulting IPv6 packets flow through the same  
NAT64 translators that IPv6 hosts that want to talk to the IPv4 world  
also use.

Expect to see a new or updated draft on this topic before Dublin.

I'm currently looking at defining a new DHCPv6 option that would allow  
NAT464 devices/layers to discover the 96 upper bits used by the NAT64  
translator. Would DHCPv6 be fast enough for your use case?

In a mobile environment, a NAT464 could obtain a new /96 for a new  
translator when it moves and send new sessions through the new  
translator while existing sessions keep using the previous translator.  
This is not ideal from a BEHAVE viewpoint but it would allow for a  
reasonable amount of route optimization without breaking too much stuff.