Additional NAT64/464XLAT Deployment Guidelines in Operator and Enterprise Networks
draft-ietf-v6ops-nat64-deployment-08

Approval announcement
Draft of message to be sent after approval:

From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
Cc: The IESG <iesg@ietf.org>, v6ops@ietf.org, v6ops-chairs@ietf.org, Mikael Abrahamsson <swmike@swm.pp.se>, rfc-editor@rfc-editor.org, draft-ietf-v6ops-nat64-deployment@ietf.org, warren@kumari.net, swmike@swm.pp.se
Subject: Document Action: 'Additional NAT64/464XLAT Deployment Guidelines in Operator and Enterprise Networks' to Informational RFC (draft-ietf-v6ops-nat64-deployment-08.txt)

The IESG has approved the following document:
- 'Additional NAT64/464XLAT Deployment Guidelines in Operator and
   Enterprise Networks'
  (draft-ietf-v6ops-nat64-deployment-08.txt) as Informational RFC

This document is the product of the IPv6 Operations Working Group.

The IESG contact persons are Warren Kumari and Ignas Bagdonas.

A URL of this Internet Draft is:
https://datatracker.ietf.org/doc/draft-ietf-v6ops-nat64-deployment/


Technical Summary

   This document describes how NAT64 (including 464XLAT) can be deployed
   in an IPv6 network, whether cellular ISP, broadband ISP, or
   enterprise, and possible optimizations.  The document also discusses
   issues to be considered when having IPv6-only connectivity,
   regarding: a) DNS64, b) applications or devices that use literal IPv4
   addresses or non-IPv6 compliant APIs, and c) IPv4-only hosts or
   applications.

Working Group Summary

The draft started its life as draft-palet-v6ops-464xlat-deployment in October 2017, then evolved into draft-palet-v6ops-nat64-deployment in March 2018 as a
NAT64 deployment guideline document intended to be BCP. It was adopted as a working group document as draft-ietf-v6ops-nat64-deployment in July 2018 with changed intended status to Informational.

  The discussions in the WG has been supportive of the draft, the author has taken feedback/suggestions into account and over time evolved/progressed the document during productive discussions. There has been no general opposition to the draft itself apart from people opposing on principle on DNS64 "breaking" 
DNSSEC. That is not the fault of this draft and this draft suggests no technological changes.

Document Quality

     The document describes technology implemented by numerous networks and devices, primarily in mobile networks. The author proposes this technology to be used in more deployment scenarios and that's the motivation for this draft, to analyse the deployment considerations for other types of network types. The document has received substantial technical and stylistic feedback and I believe the document is in good technical shape. The RFC editor might have some linguistic/grammar/stylistic work to do on this draft, but I believe this is normal when the author is non-native english speaker/writer.

Personnel

   Shepherd: Mikael Abrahamsson
  RAD: Warren Kumari