draft-ietf-v6ops-nat64-deployment-07.txt   draft-ietf-v6ops-nat64-deployment-08.txt 
v6ops J. Palet Martinez v6ops J. Palet Martinez
Internet-Draft The IPv6 Company Internet-Draft The IPv6 Company
Intended status: Informational July 8, 2019 Intended status: Informational July 11, 2019
Expires: January 9, 2020 Expires: January 12, 2020
Additional NAT64/464XLAT Deployment Guidelines in Operator and Additional NAT64/464XLAT Deployment Guidelines in Operator and
Enterprise Networks Enterprise Networks
draft-ietf-v6ops-nat64-deployment-07 draft-ietf-v6ops-nat64-deployment-08
Abstract Abstract
This document describes how NAT64 (including 464XLAT) can be deployed This document describes how NAT64 (including 464XLAT) can be deployed
in an IPv6 network, whether cellular ISP, broadband ISP, or in an IPv6 network, whether cellular ISP, broadband ISP, or
enterprise, and possible optimizations. The document also discusses enterprise, and possible optimizations. The document also discusses
issues to be considered when having IPv6-only connectivity, issues to be considered when having IPv6-only connectivity,
regarding: a) DNS64, b) applications or devices that use literal IPv4 regarding: a) DNS64, b) applications or devices that use literal IPv4
addresses or non-IPv6 compliant APIs, and c) IPv4-only hosts or addresses or non-IPv6 compliant APIs, and c) IPv4-only hosts or
applications. applications.
skipping to change at page 1, line 37 skipping to change at page 1, line 37
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 9, 2020. This Internet-Draft will expire on January 12, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 36 skipping to change at page 2, line 36
4.1.2. DNSSEC validator aware of DNS64 . . . . . . . . . . . 21 4.1.2. DNSSEC validator aware of DNS64 . . . . . . . . . . . 21
4.1.3. Stub validator . . . . . . . . . . . . . . . . . . . 22 4.1.3. Stub validator . . . . . . . . . . . . . . . . . . . 22
4.1.4. CLAT with DNS proxy and validator . . . . . . . . . . 22 4.1.4. CLAT with DNS proxy and validator . . . . . . . . . . 22
4.1.5. ACL of clients . . . . . . . . . . . . . . . . . . . 22 4.1.5. ACL of clients . . . . . . . . . . . . . . . . . . . 22
4.1.6. Mapping-out IPv4 addresses . . . . . . . . . . . . . 23 4.1.6. Mapping-out IPv4 addresses . . . . . . . . . . . . . 23
4.2. DNS64 and Reverse Mapping . . . . . . . . . . . . . . . . 23 4.2. DNS64 and Reverse Mapping . . . . . . . . . . . . . . . . 23
4.3. Using 464XLAT with/without DNS64 . . . . . . . . . . . . 23 4.3. Using 464XLAT with/without DNS64 . . . . . . . . . . . . 23
4.4. Foreign DNS . . . . . . . . . . . . . . . . . . . . . . . 24 4.4. Foreign DNS . . . . . . . . . . . . . . . . . . . . . . . 24
4.4.1. Manual Configuration of DNS . . . . . . . . . . . . . 25 4.4.1. Manual Configuration of DNS . . . . . . . . . . . . . 25
4.4.2. DNS Privacy/Encryption Mechanisms . . . . . . . . . . 25 4.4.2. DNS Privacy/Encryption Mechanisms . . . . . . . . . . 25
4.4.3. Split DNS . . . . . . . . . . . . . . . . . . . . . . 26 4.4.3. Split DNS and VPNs . . . . . . . . . . . . . . . . . 26
4.5. Well-Known Prefix (WKP) vs Network-Specific Prefix (NSP) 26 4.5. Well-Known Prefix (WKP) vs Network-Specific Prefix (NSP) 26
4.6. IPv4 literals and non-IPv6 Compliant APIs . . . . . . . . 26 4.6. IPv4 literals and non-IPv6 Compliant APIs . . . . . . . . 26
4.7. IPv4-only Hosts or Applications . . . . . . . . . . . . . 27 4.7. IPv4-only Hosts or Applications . . . . . . . . . . . . . 27
4.8. CLAT Translation Considerations . . . . . . . . . . . . . 27 4.8. CLAT Translation Considerations . . . . . . . . . . . . . 27
4.9. EAM Considerations . . . . . . . . . . . . . . . . . . . 28 4.9. EAM Considerations . . . . . . . . . . . . . . . . . . . 28
4.10. Incoming Connections . . . . . . . . . . . . . . . . . . 28 4.10. Incoming Connections . . . . . . . . . . . . . . . . . . 28
5. Summary of Deployment Recommendations for NAT64/464XLAT . . . 28 5. Summary of Deployment Recommendations for NAT64/464XLAT . . . 28
6. Deployment of NAT64 in Enterprise Networks . . . . . . . . . 31 6. Deployment of 464XLAT/NAT64 in Enterprise Networks . . . . . 31
7. Security Considerations . . . . . . . . . . . . . . . . . . . 33 7. Security Considerations . . . . . . . . . . . . . . . . . . . 33
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 33 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 33
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 33 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 33
10. ANNEX A: Example of Broadband Deployment with 464XLAT . . . . 34 10. ANNEX A: Example of Broadband Deployment with 464XLAT . . . . 34
11. ANNEX B: CLAT Implementation . . . . . . . . . . . . . . . . 37 11. ANNEX B: CLAT Implementation . . . . . . . . . . . . . . . . 37
12. ANNEX C: Benchmarking . . . . . . . . . . . . . . . . . . . . 38 12. ANNEX C: Benchmarking . . . . . . . . . . . . . . . . . . . . 38
13. ANNEX D: Changes from -00 to -01/-02 . . . . . . . . . . . . 38 13. ANNEX D: Changes from -00 to -01/-02 . . . . . . . . . . . . 38
14. ANNEX E: Changes from -02 to -03 . . . . . . . . . . . . . . 38 14. ANNEX E: Changes from -02 to -03 . . . . . . . . . . . . . . 38
15. ANNEX F: Changes from -03 to -04 . . . . . . . . . . . . . . 39 15. ANNEX F: Changes from -03 to -04 . . . . . . . . . . . . . . 39
16. ANNEX G: Changes from -04 to -05 . . . . . . . . . . . . . . 39 16. ANNEX G: Changes from -04 to -05 . . . . . . . . . . . . . . 39
skipping to change at page 4, line 21 skipping to change at page 4, line 21
specific. specific.
According to that, across this document, the use of "operator", According to that, across this document, the use of "operator",
"operator network", "service provider", and similar ones, are "operator network", "service provider", and similar ones, are
interchangeable with equivalent cases of enterprise networks (and interchangeable with equivalent cases of enterprise networks (and
similar ones). This may be also the case for "managed end-user similar ones). This may be also the case for "managed end-user
networks". networks".
Note that if all the hosts in a network were performing the address Note that if all the hosts in a network were performing the address
synthesis, as described in Section 7.2 of [RFC6147], some of the synthesis, as described in Section 7.2 of [RFC6147], some of the
drawbacks may vanish. However, it is today unrealistic to expect drawbacks may vanish. However, it is unrealistic today to expect
that, considering the high number of devices and applications that that, considering the high number of devices and applications that
aren't yet IPv6-enabled. So, in this document, this will be aren't yet IPv6-enabled. So, in this document, this will be
considered only for specific scenarios that can guarantee it. considered only for specific scenarios that can guarantee it.
An analysis of stateful IPv4/IPv6 mechanisms is provided in An analysis of stateful IPv4/IPv6 mechanisms is provided in
[RFC6889]. [RFC6889].
This document looks into different possible NAT64 ([RFC6146]) This document looks into different possible NAT64 ([RFC6146])
deployment scenarios, including IPv4-IPv6-IPv4 (464 for short) and deployment scenarios, including IPv4-IPv6-IPv4 (464 for short) and
similar ones, which were not documented in [RFC6144], such as 464XLAT similar ones, which were not documented in [RFC6144], such as 464XLAT
skipping to change at page 25, line 38 skipping to change at page 25, line 38
categories, as depicted in the following sub-sections. categories, as depicted in the following sub-sections.
4.4.1. Manual Configuration of DNS 4.4.1. Manual Configuration of DNS
It is becoming increasingly common that end-users or even devices or It is becoming increasingly common that end-users or even devices or
applications configure alternative DNS in their Operating Systems, applications configure alternative DNS in their Operating Systems,
and sometimes in CEs. and sometimes in CEs.
4.4.2. DNS Privacy/Encryption Mechanisms 4.4.2. DNS Privacy/Encryption Mechanisms
A new trend is for clients or applications to use mechanisms for DNS Clients or applications may use mechanisms for DNS privacy/
privacy/encryption, such as DNS over TLS ([RFC7858]), DNS over DTLS encryption, such as DNS over TLS ([RFC7858]), DNS over DTLS
([RFC8094]), DNS queries over HTTPS ([RFC8484]) or DNS over QUIC ([RFC8094]), DNS queries over HTTPS ([RFC8484]) or DNS over QUIC
([I-D.huitema-quic-dnsoquic]). Those are commonly cited as DoT, DoH ([I-D.huitema-quic-dnsoquic]). Those are commonly cited as DoT, DoH
and DoQ. and DoQ.
Those DNS privacy/encryption options, currently are typically Those DNS privacy/encryption options, currently are typically
provided by the applications, not the Operating System vendors. At provided by the applications, not the Operating System vendors. At
the time of writing this document, at least DoT and DoH standards the time of writing this document, at least DoT and DoH standards
have declared DNS64 (and consequently NAT64) out of their scope, so have declared DNS64 (and consequently NAT64) out of their scope, so
an application using them may break NAT64, unless a correctly an application using them may break NAT64, unless a correctly
configured CLAT function is used. configured CLAT function is used.
4.4.3. Split DNS 4.4.3. Split DNS and VPNs
When networks or hosts use "split-DNS" (also called Split Horizon, When networks or hosts use "split-DNS" (also called Split Horizon,
DNS views or private DNS), the successful use of the DNS64 is not DNS views or private DNS), the successful use of the DNS64 is not
guaranteed. Section 4 of [RFC6950], analyses this case. guaranteed. Section 4 of [RFC6950], analyses this case.
A similar situation may happen in case of VPNs that force all the DNS A similar situation may happen in case of VPNs that force all the DNS
queries through the VPN, ignoring the operator DNS64 function. queries through the VPN, ignoring the operator DNS64 function.
4.5. Well-Known Prefix (WKP) vs Network-Specific Prefix (NSP) 4.5. Well-Known Prefix (WKP) vs Network-Specific Prefix (NSP)
skipping to change at page 28, line 31 skipping to change at page 28, line 31
4.10. Incoming Connections 4.10. Incoming Connections
The use of NAT64, in principle, disallows IPv4 incoming connections, The use of NAT64, in principle, disallows IPv4 incoming connections,
which may be still needed for IPv4-only peer-to-peer applications. which may be still needed for IPv4-only peer-to-peer applications.
However, there are several alternatives that resolve this issue: However, there are several alternatives that resolve this issue:
a. STUN ([RFC5389]), TURN ([RFC5766]) and ICE ([RFC8445]) are a. STUN ([RFC5389]), TURN ([RFC5766]) and ICE ([RFC8445]) are
commonly used by peer-to-peer applications in order to allow commonly used by peer-to-peer applications in order to allow
incoming connections with IPv4 NAT. In the case of NAT64, they incoming connections with IPv4 NAT. In the case of NAT64, they
work as well. Note also the relevance of work as well. RFC editor note: If in time, replace STUN and TURN
[I-D.ietf-tram-turnbis]. with [I-D.ietf-tram-stunbis] / [I-D.ietf-tram-turnbis].
b. PCP ([RFC6887]) allows a host to control how incoming IPv4 and b. PCP ([RFC6887]) allows a host to control how incoming IPv4 and
IPv6 packets are translated and forwarded. A NAT64 may implement IPv6 packets are translated and forwarded. A NAT64 may implement
PCP to allow this service. PCP to allow this service.
c. EAM ([RFC7757]) may also be used in order to configure explicit c. EAM ([RFC7757]) may also be used in order to configure explicit
mappings for customers that require them. This is used for mappings for customers that require them. This is used for
example by SIIT-DC ([RFC7755]) and SIIT-DC-DTM ([RFC7756]). example by SIIT-DC ([RFC7755]) and SIIT-DC-DTM ([RFC7756]).
5. Summary of Deployment Recommendations for NAT64/464XLAT 5. Summary of Deployment Recommendations for NAT64/464XLAT
NAT64/464XLAT has demonstrated to be a valid choice in several NAT64/464XLAT has demonstrated to be a valid choice in several
scenarios (IPv6-IPv4 and IPv4-IPv6-IPv4), with hundreds of millions scenarios (IPv6-IPv4 and IPv4-IPv6-IPv4), being the predominant
of users, being the predominant mechanism in the majority of the mechanism in the majority of the cellular networks, which account for
cellular networks (which account for hundreds of millions of users). hundreds of millions of users ([ISOC]). NAT64/464XLAT offer
NAT64/464XLAT offer different choices of deployment, depending on different choices of deployment, depending on each network case,
each network case, needs and requirements. Despite that, this needs and requirements. Despite that, this document is not an
document is not an explicit recommendation for using this choice explicit recommendation for using this choice versus other IPv4aaS
versus other IPv4aaS transition mechanisms. Instead, this document transition mechanisms. Instead, this document is a guide that
is a guide that facilitates evaluating a possible implementation of facilitates evaluating a possible implementation of NAT64/464XLAT and
NAT64/464XLAT and key decision points about specific design key decision points about specific design considerations for its
considerations for its deployment. deployment.
Depending on the specific requirements of each deployment case, DNS64 Depending on the specific requirements of each deployment case, DNS64
may be a required function, while in other cases the adverse effects may be a required function, while in other cases the adverse effects
may be counterproductive. Similarly, in some cases a NAT64 function, may be counterproductive. Similarly, in some cases a NAT64 function,
together with a DNS64 function, may be a valid solution, when there together with a DNS64 function, may be a valid solution, when there
is a certainty that IPv4-only hosts or applications do not need to be is a certainty that IPv4-only hosts or applications do not need to be
supported (Section 4.6 and Section 4.7). However, in other cases supported (Section 4.6 and Section 4.7). However, in other cases
(i.e. IPv4-only devices or applications need to be supported), the (i.e. IPv4-only devices or applications need to be supported), the
limitations of NAT64/DNS64, may suggest the operator to look into limitations of NAT64/DNS64, may suggest the operator to look into
464XLAT as a more complete solution. 464XLAT as a more complete solution.
skipping to change at page 30, line 6 skipping to change at page 30, line 6
This "increased performance" approach has the disadvantage of This "increased performance" approach has the disadvantage of
potentially breaking DNSSEC for a small percentage of validating end- potentially breaking DNSSEC for a small percentage of validating end-
hosts versus the small impact of a double translation taking place in hosts versus the small impact of a double translation taking place in
the CE. If CE performance is not an issue, which is the most the CE. If CE performance is not an issue, which is the most
frequent case, then a much safer approach is to not use DNS64 at all, frequent case, then a much safer approach is to not use DNS64 at all,
and consequently, ensure that all the IPv4 traffic is translated at and consequently, ensure that all the IPv4 traffic is translated at
the CLAT (Section 4.3). the CLAT (Section 4.3).
If DNS64 is not used, at least one of the alternatives described in If DNS64 is not used, at least one of the alternatives described in
Section 4.1.1, must be followed in order to learn he NAT64 prefix. Section 4.1.1, must be followed in order to learn the NAT64 prefix.
The operator needs to consider that if the DNS configuration can be The operator needs to consider that if the DNS configuration can be
modified (Section 4.4, Section 4.4.2, Section 4.4.3), which most modified (Section 4.4, Section 4.4.2, Section 4.4.3), which most
probably is impossible to avoid, there are chances that instead of probably is impossible to avoid, there are chances that instead of
configuring a DNS64 a foreign non-DNS64 is used. In a scenario with configuring a DNS64 a foreign non-DNS64 is used. In a scenario with
only a NAT64 function IPv4-only remote host will no longer be only a NAT64 function IPv4-only remote host will no longer be
accessible. Instead, it will continue to work in the case of accessible. Instead, it will continue to work in the case of
464XLAT. 464XLAT.
Similar considerations need to be taken regarding the usage of a Similar considerations need to be taken regarding the usage of a
skipping to change at page 31, line 44 skipping to change at page 31, line 44
function is reachable for the host, the problem goes away. function is reachable for the host, the problem goes away.
Whenever feasible, using EAM ([RFC7757]) as indicated in Section 4.9, Whenever feasible, using EAM ([RFC7757]) as indicated in Section 4.9,
provides a very relevant optimization, avoiding double-translations. provides a very relevant optimization, avoiding double-translations.
Applications that require incoming connections, typically already Applications that require incoming connections, typically already
provide means for that. However, PCP and EAM, as indicated in provide means for that. However, PCP and EAM, as indicated in
Section 4.10, are valid alternatives, even for creating explicit Section 4.10, are valid alternatives, even for creating explicit
mappings for customers that require them. mappings for customers that require them.
6. Deployment of NAT64 in Enterprise Networks 6. Deployment of 464XLAT/NAT64 in Enterprise Networks
The recommendations of this document can be used as well in The recommendations of this document can be used as well in
enterprise networks, campus and other similar scenarios (including enterprise networks, campus and other similar scenarios (including
managed end-user networks). managed end-user networks).
This include scenarios where the NAT64 function (and DNS64 function, This include scenarios where the NAT64 function (and DNS64 function,
if available) are under the control of that network (or can be if available) are under the control of that network (or can be
configured manually according to that network specific requirements), configured manually according to that network specific requirements),
and for whatever reasons, there is a need to provide "IPv6-only and for whatever reasons, there is a need to provide "IPv6-only
access" to any part of that network or it is IPv6-only connected to access" to any part of that network or it is IPv6-only connected to
skipping to change at page 33, line 19 skipping to change at page 33, line 19
| | + +--------+ CLAT | +--------+ NAT64 | | | + +--------+ CLAT | +--------+ NAT64 |
| | IPv4 | | | | only | | | | IPv4 | | | | only | |
| +----------+ +----------+ | +----------+ | +----------+ +----------+ | +----------+
+----------------------------------+ +----------------------------------+
Figure 16: DS enterprise with CLAT, IPv6-only Access, without DNS64 Figure 16: DS enterprise with CLAT, IPv6-only Access, without DNS64
7. Security Considerations 7. Security Considerations
This document does not have new specific security considerations This document does not have new specific security considerations
beyond those already reported by each of the documents cited. beyond those already reported by each of the documents cited. For
example, DNS64 ([RFC6147]) already describes the DNSSEC issues.
Note that, as already described in Section 4.4, there may be
undesirable interactions, specially if using VPNs or DNS privacy,
which may impact in the correct performance of DNS64/NAT64.
It should be remarked that the use of a DNS64 function has equivalent It should be remarked that the use of a DNS64 function has equivalent
privacy considerations as in the case of a regular DNS, either privacy considerations as in the case of a regular DNS, either
located in the service provider or an external one. located in the service provider or an external one.
8. IANA Considerations 8. IANA Considerations
This document does not have any new specific IANA considerations. This document does not have any new specific IANA considerations.
Note: This section is assuming that https://www.rfc- Note: This section is assuming that https://www.rfc-
skipping to change at page 43, line 21 skipping to change at page 43, line 21
Huitema, C., Shore, M., Mankin, A., Dickinson, S., and J. Huitema, C., Shore, M., Mankin, A., Dickinson, S., and J.
Iyengar, "Specification of DNS over Dedicated QUIC Iyengar, "Specification of DNS over Dedicated QUIC
Connections", draft-huitema-quic-dnsoquic-06 (work in Connections", draft-huitema-quic-dnsoquic-06 (work in
progress), March 2019. progress), March 2019.
[I-D.ietf-6man-ra-pref64] [I-D.ietf-6man-ra-pref64]
Colitti, L. and J. Linkova, "Discovering PREF64 in Router Colitti, L. and J. Linkova, "Discovering PREF64 in Router
Advertisements", draft-ietf-6man-ra-pref64-01 (work in Advertisements", draft-ietf-6man-ra-pref64-01 (work in
progress), June 2019. progress), June 2019.
[I-D.ietf-tram-stunbis]
Petit-Huguenin, M., Salgueiro, G., Rosenberg, J., Wing,
D., Mahy, R., and P. Matthews, "Session Traversal
Utilities for NAT (STUN)", draft-ietf-tram-stunbis-21
(work in progress), March 2019.
[I-D.ietf-tram-turnbis] [I-D.ietf-tram-turnbis]
K, R., Johnston, A., Matthews, P., and J. Rosenberg, K, R., Johnston, A., Matthews, P., and J. Rosenberg,
"Traversal Using Relays around NAT (TURN): Relay "Traversal Using Relays around NAT (TURN): Relay
Extensions to Session Traversal Utilities for NAT (STUN)", Extensions to Session Traversal Utilities for NAT (STUN)",
draft-ietf-tram-turnbis-27 (work in progress), June 2019. draft-ietf-tram-turnbis-27 (work in progress), June 2019.
[I-D.li-intarea-nat64-prefix-dhcp-option] [I-D.li-intarea-nat64-prefix-dhcp-option]
Li, L., Cui, Y., Liu, C., Wu, J., Baker, F., and J. Palet, Li, L., Cui, Y., Liu, C., Wu, J., Baker, F., and J. Palet,
"DHCPv6 Options for Discovery NAT64 Prefixes", draft-li- "DHCPv6 Options for Discovery NAT64 Prefixes", draft-li-
intarea-nat64-prefix-dhcp-option-02 (work in progress), intarea-nat64-prefix-dhcp-option-02 (work in progress),
skipping to change at page 43, line 49 skipping to change at page 44, line 10
[I-D.palet-v6ops-464xlat-opt-cdn-caches] [I-D.palet-v6ops-464xlat-opt-cdn-caches]
Palet, J. and A. D'Egidio, "464XLAT Optimization", draft- Palet, J. and A. D'Egidio, "464XLAT Optimization", draft-
palet-v6ops-464xlat-opt-cdn-caches-02 (work in progress), palet-v6ops-464xlat-opt-cdn-caches-02 (work in progress),
June 2019. June 2019.
[I-D.vixie-dns-rpz] [I-D.vixie-dns-rpz]
Vixie, P. and V. Schryver, "DNS Response Policy Zones Vixie, P. and V. Schryver, "DNS Response Policy Zones
(RPZ)", draft-vixie-dns-rpz-04 (work in progress), (RPZ)", draft-vixie-dns-rpz-04 (work in progress),
December 2016. December 2016.
[ISOC] ISOC, "State of IPv6 Deployment 2018", 2018,
<https://www.internetsociety.org/resources/2018/
state-of-ipv6-deployment-2018/>.
[RFC6889] Penno, R., Saxena, T., Boucadair, M., and S. Sivakumar, [RFC6889] Penno, R., Saxena, T., Boucadair, M., and S. Sivakumar,
"Analysis of Stateful 64 Translation", RFC 6889, "Analysis of Stateful 64 Translation", RFC 6889,
DOI 10.17487/RFC6889, April 2013, DOI 10.17487/RFC6889, April 2013,
<https://www.rfc-editor.org/info/rfc6889>. <https://www.rfc-editor.org/info/rfc6889>.
[RFC6950] Peterson, J., Kolkman, O., Tschofenig, H., and B. Aboba, [RFC6950] Peterson, J., Kolkman, O., Tschofenig, H., and B. Aboba,
"Architectural Considerations on Application Features in "Architectural Considerations on Application Features in
the DNS", RFC 6950, DOI 10.17487/RFC6950, October 2013, the DNS", RFC 6950, DOI 10.17487/RFC6950, October 2013,
<https://www.rfc-editor.org/info/rfc6950>. <https://www.rfc-editor.org/info/rfc6950>.
 End of changes. 15 change blocks. 
25 lines changed or deleted 40 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/