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

[Brian E Carpenter <brian.e.carpenter@gmail.com>]

Hi,

A few comments:

> 2.1.  Transition scenarios
> 
>    There are six obvious transition scenarios:

I think we can avoid off-topic reactions by changing this
slightly:

   There are six obvious IP layer transition scenarios:

and adding underneath something like

   Transition scenarios involving the use of upper layer proxies
   have their place, but are out of scope for this document.

> 2.1.3.  Transition scenarios that require translation

I think there's a point that should be made in this section:

In practice, it is highly likely that addresses will be in short
supply in the IPv4-only domain, and therefore that address sharing
and port mapping will be required. These functions may or may not
be combined with the IPv6-IPv4 translation function.

> 3.3.  v4 addressing consideration
...
>    ...The case where the v4-only node has a
>    private v4 address and the NAT64 box has a public address seems also
>    possible, but here it seems reasonable to assume that a NAT box will
>    exist between the v4 only node and the NAT64 box.  

There is an alternative assumption which is that traditional NAT
(v4 to v4) is embedded in the NAT64 device. There is a difference,
because then the NAT64 is aware of the address and port mappings
(and that opens some possibilities, as SHANTI and MNAT-PT show).

> 3.4.  Name-space considerations
> 
>    One of the major choices that are faced when designing a NAT4
>    mechanism that enable communication initiated by the v4-only node
>    towards a v6-only node.  In this case, the v4 only node needs to
>    identify the v6 only node and the problem is that there is no means
>    to permanently map the v6 address space in the v4 address space.  

Well yes, that is unsolvable, so let's not try to solve it.
This returns to point about port mapping - if you want the NAT64 to
support incoming sessions, the number of sessions is limited by
(number of ports)*(number of IPv4 addresses). In DNS, the IPv6-only
servers will have to be represented by a shared A record for each
IPv4 address. That doesn't require a DNS ALG. But it does require
defined mappings for inbound ports. That's NAT 101, and the mapping
to IPv6 doesn't change it.

>    o  R2.2: Translation mechanim must support v4-initiated short-lived
>       local handle (as defined in Section 3.1). (not clear if there is
>       consensus for this)

I think that if we're going to do this at all, it needs to be symmetrical,
so I hum for this.

>    o  R2.2.1: v4 initiators can either use IPv4 public addresses or IPv4
>       private addresses and use a NAT.(The acceptance of R2.2.1 is
>       subject to the acceptance of R2.2.

As noted above, that does *not* imply a separate NAT; it could be combined
with the NAT64.

  Brian