Skip to main content

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

Revision differences

Document history

Date Rev. By Action
2019-11-26
08 (System) RFC Editor state changed to AUTH48-DONE from AUTH48
2019-11-14
08 (System) RFC Editor state changed to AUTH48 from RFC-EDITOR
2019-09-09
08 (System) RFC Editor state changed to RFC-EDITOR from EDIT
2019-08-26
08 Gunter Van de Velde Assignment of request for Last Call review by OPSDIR to Tianran Zhou was marked no-response
2019-07-23
08 (System) IANA Action state changed to No IANA Actions from In Progress
2019-07-23
08 (System) IANA Action state changed to In Progress from Waiting on Authors
2019-07-18
08 Jean Mahoney Request for Last Call review by GENART Completed: Ready. Reviewer: Meral Shirazipour.
2019-07-16
08 (System) RFC Editor state changed to EDIT
2019-07-16
08 (System) IESG state changed to RFC Ed Queue from Approved-announcement sent
2019-07-16
08 (System) Announcement was received by RFC Editor
2019-07-15
08 (System) IANA Action state changed to Waiting on Authors from In Progress
2019-07-15
08 (System) IANA Action state changed to In Progress
2019-07-15
08 Amy Vezza IESG state changed to Approved-announcement sent from Approved-announcement to be sent::AD Followup
2019-07-15
08 Amy Vezza IESG has approved the document
2019-07-15
08 Amy Vezza Closed "Approve" ballot
2019-07-15
08 Amy Vezza Ballot approval text was generated
2019-07-12
08 (System) Sub state has been changed to AD Followup from Revised ID Needed
2019-07-12
08 Jordi Palet Martinez New version available: draft-ietf-v6ops-nat64-deployment-08.txt
2019-07-12
08 (System) Forced post of submission
2019-07-12
08 (System) Request for posting confirmation emailed to previous authors: Jordi Palet
2019-07-12
08 Jordi Palet Martinez Uploaded new revision
2019-07-11
07 Benjamin Kaduk
[Ballot comment]
Staying at No Record since I'm balloting late, but:

Just asking "DNSSEC: Are there hosts validating DNSSEC?" may not be the
best way …
[Ballot comment]
Staying at No Record since I'm balloting late, but:

Just asking "DNSSEC: Are there hosts validating DNSSEC?" may not be the
best way to plan for the future, as it ignores the question of whether
hosts may in the future start or want to start validating DNSSEC.
It would be unfortunate if deploying a NAT64 solution hindered DNSSEC
deployment as a side effect.
2019-07-11
07 Benjamin Kaduk Ballot comment text updated for Benjamin Kaduk
2019-07-11
07 Cindy Morgan IESG state changed to Approved-announcement to be sent::Revised I-D Needed from IESG Evaluation
2019-07-11
07 Magnus Westerlund [Ballot Position Update] New position, No Objection, has been recorded for Magnus Westerlund
2019-07-11
07 Suresh Krishnan [Ballot Position Update] New position, No Objection, has been recorded for Suresh Krishnan
2019-07-10
07 Adam Roach [Ballot Position Update] New position, No Objection, has been recorded for Adam Roach
2019-07-10
07 Barry Leiba [Ballot Position Update] New position, No Objection, has been recorded for Barry Leiba
2019-07-10
07 Roman Danyliw
[Ballot comment]
(1) Section 5.  Is there an informative reference that can be made about the successful deployment on cellular networks?

(2) Section 7.  Consider …
[Ballot comment]
(1) Section 5.  Is there an informative reference that can be made about the successful deployment on cellular networks?

(2) Section 7.  Consider adding an explicit statement such as the following after the intro sentence that “no new security considerations are added”:

As noted in the relevant sections above, the NAT64 and DNS64 technologies can impact the efficacy or functionality of key security (i.e., DNSSEC and VPNs) and privacy preserving (i.e., DNS-over-TLS and DNS-over-HTTP) technologies.

(3) Editorial Nits

** Section 1.  Editorial. s/today unrealistic/unrealistic today/

** Section 5.  Typo.  s/learn he/learn the/

** Section 5.  Editorial.  “Hundreds of millions of users” mentioned twice.

OLD:
NAT64/464XLAT has demonstrated to be a valid choice in several scenarios (IPv6-IPv4 and IPv4-IPv6-IPv4), with hundreds of millions of users, being the predominant mechanism in the majority of the cellular networks (which account for hundreds of millions of users).

NEW:
NAT64/464XLAT has demonstrated to be a valid choice in several scenarios (IPv6-IPv4 and IPv4-IPv6-IPv4) in cellular networks which account for hundreds of millions of users.
2019-07-10
07 Roman Danyliw [Ballot Position Update] New position, No Objection, has been recorded for Roman Danyliw
2019-07-10
07 Alissa Cooper
[Ballot comment]
It is strange to me that this document interleaves figures that are numbered and figures that are lettered.

= Section 4.4.2 =

"A …
[Ballot comment]
It is strange to me that this document interleaves figures that are numbered and figures that are lettered.

= Section 4.4.2 =

"A new trend is for ..."

This will not age well, probably better to phrase this in a timeless fashion.
2019-07-10
07 Alissa Cooper [Ballot Position Update] New position, No Objection, has been recorded for Alissa Cooper
2019-07-10
07 Mirja Kühlewind
[Ballot comment]
The use of normative language in section 5 doesn't very consequent. While it is okay for informational document to have normative language, I …
[Ballot comment]
The use of normative language in section 5 doesn't very consequent. While it is okay for informational document to have normative language, I have the feeling that the recommendation given in this document aren't very "strong" and therefore it might be more suitable to not use any normative language at all. Just a thing to consider before publication.

Minor comment: STUN ([RFC5389]) and TURN ([RFC5766]) have recently been bis'ed. Please update to the new RFC/draft.
2019-07-10
07 Mirja Kühlewind [Ballot Position Update] New position, No Objection, has been recorded for Mirja Kühlewind
2019-07-09
07 (System) IANA Review state changed to IANA OK - No Actions Needed from Version Changed - Review Needed
2019-07-08
07 Deborah Brungard [Ballot Position Update] New position, No Objection, has been recorded for Deborah Brungard
2019-07-08
07 (System) IANA Review state changed to Version Changed - Review Needed from IANA OK - No Actions Needed
2019-07-08
07 Jordi Palet Martinez New version available: draft-ietf-v6ops-nat64-deployment-07.txt
2019-07-08
07 (System) New version approved
2019-07-08
07 (System) Request for posting confirmation emailed to previous authors: Jordi Palet
2019-07-08
07 Jordi Palet Martinez Uploaded new revision
2019-07-07
06 Éric Vyncke
[Ballot comment]
Hello Jordi,

Thank you  for the work put into this clear and well-written document.

I only wonder whether section 3 and section 4 …
[Ballot comment]
Hello Jordi,

Thank you  for the work put into this clear and well-written document.

I only wonder whether section 3 and section 4 should be swapped for a more logical flow: explain the issues, then describe working solutions. Probably too late in the publication to change though.

The underlying message of "464XLAT solves everything" is annoying but I must admit that this is true ;-)

Please find below many COMMENTs in the hope of improving the readability and factual data points in the document.

-éric

== COMMENTS ==

Is there a description of the use of DNS64 in the host as it fixes the DNSSEC issues ? (except in section 3.2.2.)

-- Section 3.1 --

"known to work": can you add references or data backing this statement ?

-- Section 3.1.1 --

When discussing scenarii, please refer to the figure ID in the text for clarity.

-- Section 3.1.2 --

It is unclear to me whether "The support of this scenario" refers to the UE-only or the CPE deployment.

Same demand as above: please refer to the figure ID in the text for clarity.

-- Sectio 3.2.1 --

I really wonder whether it is useful to describe this scenario as 'working under special conditions'... those 'special conditions' will probably never met in real life.

More generally, I am unsure about the value of the whole section 3.2 (it is more like an academic thing).

-- Section 4.1.1. --

Can you add reference and/or data for "monitored by some governmental bodies and other institutions".

Please add a reference for the use of "ipv4only.arpa". AFAIK draft-cheshire-sudn-ipv4only-dot-arpa appears to be dormant/dead.

-- Section 4.1.2 --

The leading paragraph is a little confusing as it assumed that CLAT exists (stated in the text but not in the section title).

-- Section 4.1.5 --

The section title is rather misleading "ACL of clients" and I wonder why a dual-stack client would use a DNS64 server as its recursive DNS server. Isn't it an obvious configuration mistake?

-- Section 4.4.1 --

Some explanations of the consequences of a foreign DNS would be welcome.

-- Section 4.4.2 --

Rather than using "DNS privacy" please use "DNS request confidentiality" as the DNS64 will learn/glean about the client activities.

-- Section 4.6 --

Please explain why older API is a problem (or rather rephrase it into applications using IPv4-only API).

-- Section 4.10 --

draft-ietf-tram-turnbis is also able to support IPv6-only client. It is currently in the same IESG status as this document.

-- Section 5 --

Please add data/references for "with hundreds of millions of users"

-- Section 7 --

Not so much about security but about privacy. I would appreciate to have some text around the lack of privacy when using an external DNS64 as this server will learn about all clients activities.

== NITS ==

Generally, please refrain from using "HEv2" in place of "Happy Eyeball version 2".

-- Section 3.1.1. --

Figure 1 shows a box containing both NAT64 and DNS64 while those functions could reside in different devices.

s/One more equivalent scenario/One additional equivalent scenario/ ?

-- Section 4.1 --

s/to an IPv6-only WAN/to an IPv6-only access network/
2019-07-07
06 Éric Vyncke [Ballot Position Update] New position, No Objection, has been recorded for Éric Vyncke
2019-07-05
06 Alvaro Retana [Ballot Position Update] New position, No Objection, has been recorded for Alvaro Retana
2019-07-01
06 Cindy Morgan Placed on agenda for telechat - 2019-07-11
2019-07-01
06 Warren Kumari IESG state changed to IESG Evaluation from Waiting for Writeup
2019-07-01
06 Warren Kumari Changed consensus to Yes from Unknown
2019-07-01
06 Warren Kumari Ballot has been issued
2019-07-01
06 Warren Kumari [Ballot Position Update] New position, Yes, has been recorded for Warren Kumari
2019-07-01
06 Warren Kumari Created "Approve" ballot
2019-07-01
06 Warren Kumari Ballot writeup was changed
2019-07-01
06 Yoshifumi Nishida Request for Last Call review by TSVART Completed: Ready. Reviewer: Yoshifumi Nishida. Sent review to list.
2019-06-28
06 Tero Kivinen Request for Last Call review by SECDIR Completed: Ready. Reviewer: Chris Lonvick.
2019-06-28
06 (System) IANA Review state changed to IANA OK - No Actions Needed from IANA - Review Needed
2019-06-28
06 Sabrina Tanamal
(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has reviewed draft-ietf-v6ops-nat64-deployment-06, which is currently in Last Call, and has the following comments:

We …
(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has reviewed draft-ietf-v6ops-nat64-deployment-06, which is currently in Last Call, and has the following comments:

We understand that this document doesn't require any registry actions.

IANA also notes that the authors have referenced an RFC Editor Errata. IANA assumes that this will be dealt with in a process outside the scope of an Internet Draft IANA Considerations section.

While it's often helpful for a document's IANA Considerations section to remain in place upon publication even if there are no actions, if the authors strongly prefer to remove it, we do not object.

If this assessment is not accurate, please respond as soon as possible.

Thank you,

Sabrina Tanamal
Senior IANA Services Specialist
2019-06-28
06 (System) IESG state changed to Waiting for Writeup from In Last Call
2019-06-25
06 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Tianran Zhou
2019-06-25
06 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Tianran Zhou
2019-06-23
06 Jean Mahoney Request for Last Call review by GENART is assigned to Meral Shirazipour
2019-06-23
06 Jean Mahoney Request for Last Call review by GENART is assigned to Meral Shirazipour
2019-06-23
06 Tim Evens Assignment of request for Last Call review by GENART to Tim Evens was rejected
2019-06-22
06 Tero Kivinen Request for Last Call review by SECDIR is assigned to Chris Lonvick
2019-06-22
06 Tero Kivinen Request for Last Call review by SECDIR is assigned to Chris Lonvick
2019-06-20
06 Jean Mahoney Request for Last Call review by GENART is assigned to Tim Evens
2019-06-20
06 Jean Mahoney Request for Last Call review by GENART is assigned to Tim Evens
2019-06-19
06 Wesley Eddy Request for Last Call review by TSVART is assigned to Yoshifumi Nishida
2019-06-19
06 Wesley Eddy Request for Last Call review by TSVART is assigned to Yoshifumi Nishida
2019-06-14
06 Cindy Morgan IANA Review state changed to IANA - Review Needed
2019-06-14
06 Cindy Morgan
The following Last Call announcement was sent out (ends 2019-06-28):

From: The IESG
To: IETF-Announce
CC: v6ops@ietf.org, v6ops-chairs@ietf.org, Mikael Abrahamsson , draft-ietf-v6ops-nat64-deployment@ietf.org, …
The following Last Call announcement was sent out (ends 2019-06-28):

From: The IESG
To: IETF-Announce
CC: v6ops@ietf.org, v6ops-chairs@ietf.org, Mikael Abrahamsson , draft-ietf-v6ops-nat64-deployment@ietf.org, warren@kumari.net, swmike@swm.pp.se
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Additional NAT64/464XLAT Deployment Guidelines in Operator and Enterprise Networks) to Informational RFC


The IESG has received a request from the IPv6 Operations WG (v6ops) to
consider the following document: - 'Additional NAT64/464XLAT Deployment
Guidelines in Operator and
  Enterprise Networks'
  as Informational RFC

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2019-06-28. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the beginning of
the Subject line to allow automated sorting.

Abstract


  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.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-v6ops-nat64-deployment/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-v6ops-nat64-deployment/ballot/


No IPR declarations have been submitted directly on this I-D.




2019-06-14
06 Cindy Morgan IESG state changed to In Last Call from Last Call Requested
2019-06-14
06 Warren Kumari Last call was requested
2019-06-14
06 Warren Kumari Last call announcement was generated
2019-06-14
06 Warren Kumari Ballot approval text was generated
2019-06-14
06 Warren Kumari Ballot writeup was generated
2019-06-14
06 Warren Kumari IESG state changed to Last Call Requested from AD Evaluation
2019-06-14
06 Warren Kumari IESG state changed to AD Evaluation from Publication Requested
2019-06-07
06 Ron Bonica
1. The draft is informational. This is the proper type because the draft describes and analyses pros and cons of different deployment scenarios. The status …
1. The draft is informational. This is the proper type because the draft describes and analyses pros and cons of different deployment scenarios. The status is indicated in the draft page header.

2. Technical summary:

This seems fine to grab from the document.

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 dicussions 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
AD:

3. I (Mikael Abrahamsson) has actively participated in review of this document as a WG member before being asked to shepherd the document. I have experience in using the technology described in the document and I believe the document is in good technical shape as is ready to be progressed.

4. The document has received feedback from at least 10 WG members over time and in the last call approximately 5 people publically said they had reviewed the document and proposed changes/enhancements (typically minor things and proposal for adding text) and expressed support for the document being useful and should be progressed. There was no opposition during WGLC.

5. I do not think the document needs broader review. The document is informational and describes an overview of already existing technology and considerations for deploying these technologies in different combinations. It doesn't propose anything new.

6. I do not have any technical concerns regarding this document.

7. The author has publically stated he is not aware of any IPR regarding the draft contents.

8. There are no IPR disclosures that I could find.

9. There were no public opposition to this document. Having participated in the WG for over 10 years I do not believe there is any significant opposition to this document.

10. There has been no publicly expressed discontent with the document.

11. The document uses SHOULD/MUST, I do not know if this is appropriate for an informational document.

12. I do not believe the contents need any such review.

13. The document has normative/informative sections. There are other links in the document that are not part of these sections, for instance that links to example software implementations.

14. The normative references are all already published RFCs.

15. No downward references.

16. From the IANA considerations section of the document:

"  This document does not have any new specific IANA considerations.

    Note: This section is assuming that https://urldefense.proofpoint.com/v2/url?u=https-3A__www.rfc-2D&d=DwIBAg&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=Fch9FQ82sir-BoLx84hKuKwl-AWF2EfpHcAwrDThKP8&m=onDnhh0AK3SDvvBtIoUPMX_EyiwRkhaLMQYS5SjEWhA&s=9sp-Hz5xzkHQ4ZxVoBrBpPx3GvWHOwC7pjLK_nTgmzc&e=
    editor.org/errata/eid5152 is resolved, otherwise, this section may
    include the required text to resolve the issue.
"

I do not know how to resolve this.

17. There are no IANA registries work in the document.

18. N/A

19. The document contains no XML, BNF or MIB definitions.
2019-06-07
06 Ron Bonica Responsible AD changed to Warren Kumari
2019-06-07
06 Ron Bonica IETF WG state changed to Submitted to IESG for Publication from WG Consensus: Waiting for Write-Up
2019-06-07
06 Ron Bonica IESG state changed to Publication Requested from I-D Exists
2019-06-07
06 Ron Bonica IESG process started in state Publication Requested
2019-06-07
06 Ron Bonica
1. The draft is informational. This is the proper type because the draft describes and analyses pros and cons of different deployment scenarios. The status …
1. The draft is informational. This is the proper type because the draft describes and analyses pros and cons of different deployment scenarios. The status is indicated in the draft page header.

2. Technical summary:

This seems fine to grab from the document.

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 dicussions 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
AD:

3. I (Mikael Abrahamsson) has actively participated in review of this document as a WG member before being asked to shepherd the document. I have experience in using the technology described in the document and I believe the document is in good technical shape as is ready to be progressed.

4. The document has received feedback from at least 10 WG members over time and in the last call approximately 5 people publically said they had reviewed the document and proposed changes/enhancements (typically minor things and proposal for adding text) and expressed support for the document being useful and should be progressed. There was no opposition during WGLC.

5. I do not think the document needs broader review. The document is informational and describes an overview of already existing technology and considerations for deploying these technologies in different combinations. It doesn't propose anything new.

6. I do not have any technical concerns regarding this document.

7. The author has publically stated he is not aware of any IPR regarding the draft contents.

8. There are no IPR disclosures that I could find.

9. There were no public opposition to this document. Having participated in the WG for over 10 years I do not believe there is any significant opposition to this document.

10. There has been no publicly expressed discontent with the document.

11. The document uses SHOULD/MUST, I do not know if this is appropriate for an informational document.

12. I do not believe the contents need any such review.

13. The document has normative/informative sections. There are other links in the document that are not part of these sections, for instance that links to example software implementations.

14. The normative references are all already published RFCs.

15. No downward references.

16. From the IANA considerations section of the document:

"  This document does not have any new specific IANA considerations.

    Note: This section is assuming that https://urldefense.proofpoint.com/v2/url?u=https-3A__www.rfc-2D&d=DwIBAg&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=Fch9FQ82sir-BoLx84hKuKwl-AWF2EfpHcAwrDThKP8&m=onDnhh0AK3SDvvBtIoUPMX_EyiwRkhaLMQYS5SjEWhA&s=9sp-Hz5xzkHQ4ZxVoBrBpPx3GvWHOwC7pjLK_nTgmzc&e=
    editor.org/errata/eid5152 is resolved, otherwise, this section may
    include the required text to resolve the issue.
"

I do not know how to resolve this.

17. There are no IANA registries work in the document.

18. N/A

19. The document contains no XML, BNF or MIB definitions.
2019-05-04
06 Jordi Palet Martinez New version available: draft-ietf-v6ops-nat64-deployment-06.txt
2019-05-04
06 (System) New version approved
2019-05-04
06 (System) Request for posting confirmation emailed to previous authors: Jordi Palet
2019-05-04
06 Jordi Palet Martinez Uploaded new revision
2019-04-22
05 Ron Bonica IETF WG state changed to WG Consensus: Waiting for Write-Up from In WG Last Call
2019-04-19
05 Jordi Palet Martinez New version available: draft-ietf-v6ops-nat64-deployment-05.txt
2019-04-19
05 (System) New version approved
2019-04-19
05 (System) Request for posting confirmation emailed to previous authors: Jordi Palet
2019-04-19
05 Jordi Palet Martinez Uploaded new revision
2019-04-15
04 Ron Bonica Notification list changed to Mikael Abrahamsson <swmike@swm.pp.se>
2019-04-15
04 Ron Bonica Document shepherd changed to Mikael Abrahamsson
2019-04-08
04 Ron Bonica Intended Status changed to Informational from None
2019-04-08
04 Ron Bonica IETF WG state changed to In WG Last Call from WG Document
2019-04-02
04 Jordi Palet Martinez New version available: draft-ietf-v6ops-nat64-deployment-04.txt
2019-04-02
04 (System) New version approved
2019-04-02
04 (System) Request for posting confirmation emailed to previous authors: Jordi Palet
2019-04-02
04 Jordi Palet Martinez Uploaded new revision
2018-10-10
03 Jordi Palet Martinez New version available: draft-ietf-v6ops-nat64-deployment-03.txt
2018-10-10
03 (System) New version approved
2018-10-10
03 (System) Request for posting confirmation emailed to previous authors: Jordi Palet
2018-10-10
03 Jordi Palet Martinez Uploaded new revision
2018-08-14
02 Jordi Palet Martinez New version available: draft-ietf-v6ops-nat64-deployment-02.txt
2018-08-14
02 (System) New version approved
2018-08-14
02 (System) Request for posting confirmation emailed to previous authors: Jordi Palet
2018-08-14
02 Jordi Palet Martinez Uploaded new revision
2018-08-13
01 Jordi Palet Martinez New version available: draft-ietf-v6ops-nat64-deployment-01.txt
2018-08-13
01 (System) New version approved
2018-08-13
01 (System) Request for posting confirmation emailed to previous authors: Jordi Palet
2018-08-13
01 Jordi Palet Martinez Uploaded new revision
2018-07-02
00 Jordi Palet Martinez This document now replaces draft-palet-v6ops-nat64-deployment instead of None
2018-07-02
00 Jordi Palet Martinez New version available: draft-ietf-v6ops-nat64-deployment-00.txt
2018-07-02
00 (System) New version approved
2018-07-02
00 Jordi Palet Martinez Request for posting confirmation emailed  to submitter and authors: Jordi Palet
2018-07-02
00 Jordi Palet Martinez Uploaded new revision