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

[JORDI PALET MARTINEZ <[e-mail]>]

Hi Fred,



Thanks a lot !



Comments below in-line.





Regards,

Jordi

 

 



-----Mensaje original-----

De: v6ops <[e-mail]> en nombre de Fred Baker <[e-mail]>

Fecha: miércoles, 27 de junio de 2018, 19:05

Para: Jordi Palet Martínez <[e-mail]>, "[e-mail] list" <[e-mail]>

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



    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.





-> Agree and hopefully we can get a lot of contributions ...

    

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



-> Perfect, thanks a lot. I'm already doing edits in my draft v03, so I don't miss any bit.

    

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



-> Agree, I took it from an equivalent text in the abstract of DNS64, but it makes sense to put it in reverse:

"DNS64, is in charge of the synthesis of AAAA records from the A records, avoiding changes in both, the IPv6-only hosts and the IPv4-only server, so they can use a NAT64."





    

    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.



-> Are you suggesting that I should make a more detailed description in every scenario, with more figures, etc. ? Or just in the 464XLAT case ?

    

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



-> Right, again, you feel I need to add text to explain that, so same as previous question, having some extra text only for the 464XLAT cases?

    

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

 

-> Yes, we are forcing one extra translation at the CE (which is the same as today happens with NAT44). I think if it is a choice of the operator to use DNS64 (and resolve a possible 1.7% - today - DNSSEC incidents), or make its life easier by forcing some extra translations that of course, will keep decreasing as more IPv6 deployment happens in services/content providers. If we take in consideration that 60% or so of the services more used (Youtube, Google, Facebook, etc.), area already IPv6 enabled, it means that in an ISP deploying IPv6, the number of "extra" translations at the CLAT will be really insignificant (and don't happen in the operator network, just in the CLAT) compared to the cost of breaking "some" DNSSEC.

   

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

    _______________________________________________

    v6ops mailing list

    [e-mail]

    https://www.ietf.org/mailman/listinfo/v6ops

    




**********************************************
IPv4 is over
Are you ready for the new Internet ?
http://www.consulintel.es
The IPv6 Company

This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.