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

From: Brian E Carpenter <[email-masked]>
Date: Mon, 09 Jun 2008 14:37:12 +1200

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

---

From: <[email-masked]>
Date: Wed, 18 Jun 2008 09:32:37 +0300

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

True, but I wonder if it is a required feature that IPv4-only
applications can connect to IPv6 destinations? I.e. if application has
to connect to IPv6-destinations, the application should be updated to
support IPv6. The more common case could be network operator to upgrade
the access network to IPv6 while applications & services could still
continue use IPv4 - in that case the IPv4 connectivity should be
provided over the IPv6 cloud.

>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 looking forward to it. We should have a solution available that
includes client side changes, as I believe those can be more efficient
e.g. in wireless systems than the "CPE" based solutions (if the "CPE" is
actually at the other side of the air interface).

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

It would (and often needed anyway e.g. for DNS discovery).

Best regards,
	
	Teemu

---

From: Rémi Després <[email-masked]>
Date: Thu, 19 Jun 2008 18:25:30 +0200

[email-masked]  - Le 6/18/08 8:32 AM :
> ... I wonder if it is a required feature that IPv4-only
> support IPv6.

I share this view, and believe the point is important.

- On one hand, scenarios where a v4-only host connects to a v6-only host 
do raise ineresting problems from a theoretical point of view.

- But on the other hand, IETF suggesting that solutions to these 
problems should be deployed would be a disincentive to the 
generalization of v4&v6, in both Hosts and applications. This IMO would 
be a step backward.

Rémi