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

[<teemu.savolainen@nokia.com>]

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: owner-v6ops@ops.ietf.org 
>[mailto:owner-v6ops@ops.ietf.org] On Behalf Of ext marcelo 
>bagnulo braun
>Sent: 15 May, 2008 00:49
>To: v6ops@ops.ietf.org
>Subject: Re: I-D Action:draft-ietf-v6ops-nat64-pb-statement-req-00.txt
>
>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
>
>Internet-Drafts@ietf.org escribió:
>> 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-statemen
>> t-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.
>>   
>
>
>