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

[<teemu.savolainen@nokia.com>]

Hi Marcelo,

Inline,

>I undrsatnd that the changes you are proposing are:
>> 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
>>   
>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)

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.

>> - Availability of translation mechanism service SHOULD be quickly 
>> discoverable
>>   
>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.

>> - 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?

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