Re: Fwd: I-D Action:draft-bagnulo-v6ops-6man-nat64-pb-statement-01.txt

[Rémi Després <remi.despres@free.fr>]

Marcelo,

Sorry to comment so late: I was very busy these days and wanted to
comment in details. The draft is important.
On many points my views are slightly different,or even substantially
different, but as you said the goal was to promote discussion :-) .

Detailed comments follow.

Rémi

marcelo bagnulo wrote :
> the goal of the draft is to promote discussion and in particular tune
>  the requirements
>
> comments are very welcome, in particular, feedback from people
> exploring solutions would be great


General
The subject of the document is most important.

2. Problem statement

- Concepts of IPv6-only and IPv4-only applied to a "network or system"
are IMHO insufficiently precise.
For a practical analysis of some requirements, distinctions are needed
between v4-only, v6-only, and v4&v6, for applications, AND for stacks
AND for addresses (that, if IPv4, can be "public" or "private" with
different implications).
For example, a v6-only application on a v4&v6 stack at only a private v4
address, has requirements of its own.

- Entities to be analyzed separately are IMHO  Hosts, router-CPEs , and
address processing relays in ISP networks (possibly with different names).

2.1 Transition scenarios

- Wouldn't the word "configurations" be more appropriate than "scenarios"?
- Configurations discussed by Alain Durand should IMHO be included in
some way, in particular v4v6v4 which requires mechanisms that NAT64
alone cannot satisfy.
- The most important configurations (and possibly the ONLY important
ones) are IMHO those where connections that must be IPv4 at one of their
endpoints have one end in a site without public v4 address.

2.1.2 Transition scenarios that do not require translation

Configurations considered here seem to be those where IPv6 connections
have to traverse v4 routing clouds (justifying ISATAP in private sites,
and various solution in ISP infrastructures, among which 6rd would be
added).

2.1.3 Transitions scenarios that require translation

"Translation" may seem ambiguous. If v4-only applications that are in
hosts having no v4 public address can borrow temporary address-port
couples from some remote point having public v4 addresses, then their
connections via IPv6 can remain E2E (no packet modification  anywhere in
the network).
The need could be described as "for network temporary address provision".
I have worked on  a proposal which includes an
address-and-port-loan-protocol (APLP); It has some  common grounds with
DSTM and SHANTI, but also substantial differences.
It will be presented in other documents.

2.2 Requirements for the overall transition strategy

IMHO, there is indeed a need for v6-capable applications to be able to
reach v4-only server applications, but there is no real need for v4-only
applications to be able to reach server applications at v6-only
addresses. (Client and P2P applications SHOULD evolve ASAP to support
addresses  longer than those of v4. No new mechanisms are necessary for
this.)

3.1 Application behavior taxonomy

Another application behavior taxonomy which, as far as transition
requirements are concerned, seems to me more practical is as follows:
(1) ignoring remote and local address-port couples (e.g. web servers);
(2) handling remote address-port couples but ignoring local ones (e.g.
web clients); (3) handling both remote and local address-port couples
(e.g. passive mode  FTP clients).
An application which is concerned with its local address-port couple
should typically bind its socket with inaddr_any  and then get its
address-port couple by getsockname().

3.2 Placement of NAT64 mechanisms

Instead of looking for where some given mechanisms, here NAT64, would be
placed, the inverse question could be easier to deal with: what
functions need to be in hosts, in router-CPEs, and within ISP
infrastructures.

3.3 v4 addressing consideration

The purpose of this section didn't seem clear to me.

3.4 Name-space considerations

IMHO, an application which has no permanent public v4 address and needs
to be reachable by IPv4 applications SHOULD get a temporary one.
This is what is done in IPv4 where applications in hosts having
only-private v4 addresses get temporary address-port couples, e.g. using
STUN to "punch holes" in their NATs.
In v6, other mechanisms are possible than in v4, but the principle
should remain the same.

3.5 Market timing considerations

I agree that adequate NAT mechanisms are needed in router-CPEs so that
the need to add new functions in host stacks can be delayed.
But I also believe that host stacks should have more mechanisms to
satisfy transition requirements when they are not behind router-CPEs.
Once these mechanisms are agreed on, they should IMHO be implemented as
early as feasible, by patch or otherwise, in PCs and other portable devices.

4. and 5. Requirements that MUST be and SHOULD be supported.
This is the most useful part of the document.
R1
Ambiguous wording (see 2. above).
But agreement that, v4-only servers should not be required to change.
Agreement also that hosts MAY need transition mechanisms (they even
SHOULD, to operate at v6-only addresses that are not behind router-CPEs).
R2
Yes for  outgoing and incoming connections of v4 applications in hosts
without permanent v4-addresses .
No for "v6 initiated" connections
R3
Yes on the preference for v6 when there is the choice.
R4
Could be part of R1 ?
R5
Yes if it means that no DNS-ALG should be needed.
R6
Yes on the non propagation of routing-prefix proliferation from v4 to v6.
R7
Yes for the support of TCP and UDP (and any protocol above)
IMHO a stronger requirement is possible, namely that transition
mechanisms that depend on v6 deal with only with address-port couples,
with no specific ALG.
(Note that v4 FTP ALGs are not v6 related; they belong to v4 and will
have to remain for long.)
R8
Yes for the need to specify timeout requirements of proposed solutions.
R9
No on the need to support fragmentation (costly over-killing IMHO)
R10
Yes to say that connections that don't use transition specific
mechanisms  should not have less security with the deployment of
transition specific mechanisms.
I1
DNS sec could be covered in a modified R7
I2
No (see 3.2)
I3
Yes on the need to support auto-configuration in CPEs using DHCP.
Central management seems to me ambiguous.
I4
No. See R9.
I5
Yes on the need to support applications that handle both remote and
local address-port couples.
I6
Could MIPv6 be  covered in a modified R7 ? (I am not sure).
I7
SCTP could be  covered in a modified R7
I8
DCCP could be  covered in a modified R7
I9
There should be no more constraint related to multicast than in the case
of v4 NATs.
Whether this can be said "not to prevent multicast" is unclear to me.

4.3 Non Goals
Yes, IPsec (which is not a protocol using address-port couples) should
be kept off-scope.