[v6ops] draft-palet-v6ops-nat64-deployment-02 comments

[Fred Baker <[e-mail]>]

Chair comment: I am interested in making this draft a working group draft. I think there is merit in it to do so. However, following our usual process, I need agreement from the working group. Consider this a solicitation for that. To do so, I'm looking for comments, supportive or otherwise, especially from operators. To respond to Barbara's question that she raised with ipv4aas, making it a working group document doesn't mean it's done, it means it's a work item as opposed to a suggestion to the working group.

The rest of this is sans hats.

Thanks for your new draft. Let me say that I am increasingly hearing about ISPs (cellular and broadband) that, in the words of one, "just don't want to allocate IPv4 addresses anymore", and are taking important steps toward turning IPv4 off within their networks in favor of IPv4 as a service. As you know, this falls into a couple of categories - those that are willing to offer a client-only IPv4-over-IPv6 or IPv4-cum-IPv6 service, and those that need to be able to somehow still put an IPv4 address into an A record (such as a company like Lumix that uses Dynamic DNS Update and firewall hole-punching to allow a residential user to access their surveillance system from an Android/iPhone app) and use it to send a message to the IPv4 server. So IMHO, this is an important draft, and it would be useful to get operator comment on it.

I'm reviewing the draft. I'll bring up nits inline, and I may have some other thoughts as well.

> Abstract
> 
>    This document describes how NAT64 and 464XLAT can be deployed in an
>    IPv6 operator (cellular and broadband) or enterprise network and the

I suspect that this would read better as "IPv6 network, whether cellular ISP, broadband ISP, or enterprise".

> 1.  Introduction

>    To avoid changes in both, the IPv6-only hosts and the IPv4-only
>    server, NAT64 requires also the use of a DNS64 ([RFC6147]), in charge
>    for the synthesis of AAAA records from the A records.

I would disagree that NAT64 "requires" DNS64. NAT64 requires that the destination IPv6 address contain an embedded IPv4 address. The source of that IPv4-embedded IPv6 address is up to the system that sent the packet. A CLAT (stateless translation as in RFC 7915) uses address synthesis with a PLAT translation prefix. MAP-T adds NAPT44 functionality to that with respect to the outbound IPv4 source address. A random IPv6 host accessing an IPv4-only peer might use DNS64, and the AAAA records might simply exist in DNS containing an IPv4-embedded IPv6 address. But the NAT64 function doesn't use, nor does it require, DNS64.

BTW, SIIT-DC makes rather a point that RFC 6146 is a per-session (effectively NAPT) translator, and provides translation strictly at the IP layer. I suspect that is also a valid configuration, one that needs to be supported. In the 464XLAT case, I think it falls out, but I'll have to think about MAP-T.

> 3.  NAT64 Deployment Scenarios

>    Consequently, the perspective in this document is to broader those

"broaden"

> 3.1.2.  Service Provider offering 464XLAT, with DNS64

Pictorial image of what I'm picturing:

                          +----+                +----+
                          |DNS |     +-----+    |DNS |
                          |IPv6|     |DNS64|    |IPv4|
                          +--+-+     +--+--+    +--+-+
  +------+ v6 +------+       |          |          |
  |      +----+      |    ,--+--.       |       ,--+--.
  |Dual  |    | IPv6 |   /       \    ,-+-.    /       \
  |Stack |  +-+Router+--(  IPv6   )--( PLAT)--(  IPv4   )
  |Device|v4|C|      |   \Network/`.  `---'    \Network/
  |      +--+L|      |    `--+--'   `.         /`-----'
  +------+  |A|      |       |        `+------+
            |T|      |    +--+---+     | Peer |
            +-+------+    | IPv6 |     |Device|
                          |Device|     +------+
                          +------+

The dual stack device obviously has an IPv4 and an IPv6 address, and the IPv4 side of it speaks through the CLAT. The IPv6 device has no IPv4 address. The peer device is the thing the "dual stack" device connects to, and might itself be dual stack or IPv4-only. In both cases, however, IPv4 access to the peer device will go through the PLAT.

When the IPv6 device wants to talk with the peer device, it will need a AAAA record. In the dual stack case, that will contain a "usual" IPv6 address, and connectivity will be IPv6 end to end; in the IPv4-only case, it will need its IPv4 address embedded into the PLAT's translation prefix, which is or is functionally equivalent to DNS64.

When the dual stack device wants to talk with the Peer Device, its IPv4 side will need an A record and the CLAT will do the address synthesis. Hence, no need for DNS64, and no requirement for it if it exists. The IPv6 side will need a AAAA record. If there is a native IPv6 address, that's fine, it will use that, and the system might be best served if the IPv6 connectivity is used. If there is a DNS64 AAAA record, the IPv4 side will use an A record and the CLAT and PLAT, and the IPv6 side will use the PLAT and the DNS64 address.

> 3.1.3.  Service Provider offering 464XLAT, without DNS64

The difference from the preceding section will be connectivity between an IPv6-only device and an IPv4-only peer. In the previous section, the IPv6 device will be unable to communicate with an IPv4-only peer, and the dual stack device will use its IPv4 side, the CLAT, and the PLAT.

>    The major advantage of this scenario, using 464XLAT without DNS64, is
>    that the service provider ensures that DNSSEC is never broken.

Yes, but at the cost of IPv6-IPv4 connectivity.

> 3.2.  Known to Work Under Special Conditions
> 
>    The scenarios in this category are known not to work unless

"known to not work"

I'll probably have more comments later, but I'm sending this much now.