draft-ietf-ipsecme-split-dns-02.txt | draft-ietf-ipsecme-split-dns-03.txt | |||
---|---|---|---|---|
Network T. Pauly | Network T. Pauly | |||
Internet-Draft Apple Inc. | Internet-Draft Apple Inc. | |||
Intended status: Standards Track P. Wouters | Intended status: Standards Track P. Wouters | |||
Expires: January 30, 2018 Red Hat | Expires: May 16, 2018 Red Hat | |||
July 29, 2017 | November 12, 2017 | |||
Split DNS Configuration for IKEv2 | Split DNS Configuration for IKEv2 | |||
draft-ietf-ipsecme-split-dns-02 | draft-ietf-ipsecme-split-dns-03 | |||
Abstract | Abstract | |||
This document defines two Configuration Payload Attribute Types for | This document defines two Configuration Payload Attribute Types for | |||
the IKEv2 protocol that add support for private DNS domains. These | the IKEv2 protocol that add support for private DNS domains. These | |||
domains should be resolved using DNS servers reachable through an | domains should be resolved using DNS servers reachable through an | |||
IPsec connection, while leaving all other DNS resolution unchanged. | IPsec connection, while leaving all other DNS resolution unchanged. | |||
This approach of resolving a subset of domains using non-public DNS | This approach of resolving a subset of domains using non-public DNS | |||
servers is referred to as "Split DNS". | servers is referred to as "Split DNS". | |||
skipping to change at page 1, line 36 ¶ | skipping to change at page 1, line 36 ¶ | |||
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 http://datatracker.ietf.org/drafts/current/. | Drafts is at http://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 30, 2018. | This Internet-Draft will expire on May 16, 2018. | |||
Copyright Notice | Copyright Notice | |||
Copyright (c) 2017 IETF Trust and the persons identified as the | Copyright (c) 2017 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 | |||
(http://trustee.ietf.org/license-info) in effect on the date of | (http://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 4, line 8 ¶ | skipping to change at page 4, line 8 ¶ | |||
IKEv2 tunnel, initiators indicate support for Split DNS in their | IKEv2 tunnel, initiators indicate support for Split DNS in their | |||
CFG_REQUEST payloads, and responders assign internal domains (and | CFG_REQUEST payloads, and responders assign internal domains (and | |||
DNSSEC trust anchors) in their CFG_REPLY payloads. When Split DNS | DNSSEC trust anchors) in their CFG_REPLY payloads. When Split DNS | |||
has been negotiated, the existing DNS server configuration attributes | has been negotiated, the existing DNS server configuration attributes | |||
will be interpreted as internal DNS servers that can resolve | will be interpreted as internal DNS servers that can resolve | |||
hostnames within the internal domains. | hostnames within the internal domains. | |||
3.1. Configuration Request | 3.1. Configuration Request | |||
To indicate support for Split DNS, an initiator includes one more | To indicate support for Split DNS, an initiator includes one more | |||
more INTERNAL_DNS_DOMAIN attributes as defined in Section 4 as part | INTERNAL_DNS_DOMAIN attributes as defined in Section 4 as part of the | |||
of the CFG_REQUEST payload. If an INTERNAL_DNS_DOMAIN attribute is | CFG_REQUEST payload. If an INTERNAL_DNS_DOMAIN attribute is included | |||
included in the CFG_REQUEST, the initiator SHOULD also include one or | in the CFG_REQUEST, the initiator SHOULD also include one or more | |||
more INTERNAL_IP4_DNS and INTERNAL_IP6_DNS attributes in the | INTERNAL_IP4_DNS and INTERNAL_IP6_DNS attributes in the CFG_REQUEST. | |||
CFG_REQUEST. | ||||
The INTERNAL_DNS_DOMAIN attribute sent by the initiator is usually | The INTERNAL_DNS_DOMAIN attribute sent by the initiator is usually | |||
empty but MAY contain a suggested domain name. | empty but MAY contain a suggested domain name. | |||
The absence of INTERNAL_DNS_DOMAIN attributes in the CFG_REQUEST | The absence of INTERNAL_DNS_DOMAIN attributes in the CFG_REQUEST | |||
payload indicates that the initiator does not support or is unwilling | payload indicates that the initiator does not support or is unwilling | |||
to accept Split DNS configuration. | to accept Split DNS configuration. | |||
To indicate support for DNSSEC, an initiator includes one or more | To indicate support for DNSSEC, an initiator includes one or more | |||
INTERNAL_DNS_TA attributes as defined in Section 4 as part of the | INTERNAL_DNSSEC_TA attributes as defined in Section 4 as part of the | |||
CFG_REQUEST payload. If an INTERNAL_DNS_TA attriute is included in | CFG_REQUEST payload. If an INTERNAL_DNSSEC_TA attriute is included | |||
the CFG_REQUEST, the initiator SHOULD also include one or more | in the CFG_REQUEST, the initiator SHOULD also include one or more | |||
INTERNAL_DNS_DOMAIN attributes in the CFG_REQUEST. | INTERNAL_DNS_DOMAIN attributes in the CFG_REQUEST. | |||
An initiator MAY convey its current DNSSEC trust anchors for the | An initiator MAY convey its current DNSSEC trust anchors for the | |||
domain specified in the INTERNAL_DNS_DOMAIN attribute. If it does | domain specified in the INTERNAL_DNS_DOMAIN attribute. If it does | |||
not wish to convey this information, it MUST use a length of 0. | not wish to convey this information, it MUST use a length of 0. | |||
The absence of INTERNAL_DNS_TA attributes in the CFG_REQUEST payload | The absence of INTERNAL_DNSSEC_TA attributes in the CFG_REQUEST | |||
indicates that the initiator does not support or is unwilling to | payload indicates that the initiator does not support or is unwilling | |||
accept DNSSEC trust anchor configuration. | to accept DNSSEC trust anchor configuration. | |||
3.2. Configuration Reply | 3.2. Configuration Reply | |||
Responders MAY send one or more INTERNAL_DNS_DOMAIN attributes in | Responders MAY send one or more INTERNAL_DNS_DOMAIN attributes in | |||
their CFG_REPLY payload. If an INTERNAL_DNS_DOMAIN attribute is | their CFG_REPLY payload. If an INTERNAL_DNS_DOMAIN attribute is | |||
included in the CFG_REPLY, the responder MUST also include one or | included in the CFG_REPLY, the responder MUST also include one or | |||
both of the INTERNAL_IP4_DNS and INTERNAL_IP6_DNS attributes in the | both of the INTERNAL_IP4_DNS and INTERNAL_IP6_DNS attributes in the | |||
CFG_REPLY. These DNS server configurations are necessary to define | CFG_REPLY. These DNS server configurations are necessary to define | |||
which servers should receive queries for hostnames in internal | which servers should receive queries for hostnames in internal | |||
domains. If the CFG_REQUEST included an INTERNAL_DNS_DOMAIN | domains. If the CFG_REQUEST included an INTERNAL_DNS_DOMAIN | |||
skipping to change at page 6, line 8 ¶ | skipping to change at page 6, line 8 ¶ | |||
CP(CFG_REPLY) = | CP(CFG_REPLY) = | |||
INTERNAL_IP4_ADDRESS(198.51.100.234) | INTERNAL_IP4_ADDRESS(198.51.100.234) | |||
INTERNAL_IP4_DNS(198.51.100.2) | INTERNAL_IP4_DNS(198.51.100.2) | |||
INTERNAL_IP4_DNS(198.51.100.4) | INTERNAL_IP4_DNS(198.51.100.4) | |||
INTERNAL_DNS_DOMAIN(example.com) | INTERNAL_DNS_DOMAIN(example.com) | |||
INTERNAL_DNS_DOMAIN(city.other.com) | INTERNAL_DNS_DOMAIN(city.other.com) | |||
3.4.2. Requesting Domains and DNSSEC trust anchors | 3.4.2. Requesting Domains and DNSSEC trust anchors | |||
In this example exchange, the initiator requests INTERNAL_IP4_DNS, | In this example exchange, the initiator requests INTERNAL_IP4_DNS, | |||
INTERNAL_DNS_DOMAIN and INTERNAL_DNS_TA attributess in the | INTERNAL_DNS_DOMAIN and INTERNAL_DNSSEC_TA attributess in the | |||
CFG_REQUEST | CFG_REQUEST | |||
Any subsequent DNS queries from the initiator for domains such as | Any subsequent DNS queries from the initiator for domains such as | |||
"www.example.com" or "city.other.com" would be DNSSEC validated using | "www.example.com" or "city.other.com" would be DNSSEC validated using | |||
the DNSSEC trust anchor received in the CFG_REPLY | the DNSSEC trust anchor received in the CFG_REPLY | |||
In this example, the initiator has no existing DNSSEC trust anchors | In this example, the initiator has no existing DNSSEC trust anchors | |||
would the requested domain. the "example.com" dommain has DNSSEC | would the requested domain. the "example.com" dommain has DNSSEC | |||
trust anchors that are returned, while the "other.com" domain has no | trust anchors that are returned, while the "other.com" domain has no | |||
DNSSEC trust anchors | DNSSEC trust anchors | |||
CP(CFG_REQUEST) = | CP(CFG_REQUEST) = | |||
INTERNAL_IP4_ADDRESS() | INTERNAL_IP4_ADDRESS() | |||
INTERNAL_IP4_DNS() | INTERNAL_IP4_DNS() | |||
INTERNAL_DNS_DOMAIN() | INTERNAL_DNS_DOMAIN() | |||
INTERNAL_DNS_TA() | INTERNAL_DNSSEC_TA() | |||
CP(CFG_REPLY) = | CP(CFG_REPLY) = | |||
INTERNAL_IP4_ADDRESS(198.51.100.234) | INTERNAL_IP4_ADDRESS(198.51.100.234) | |||
INTERNAL_IP4_DNS(198.51.100.2) | INTERNAL_IP4_DNS(198.51.100.2) | |||
INTERNAL_IP4_DNS(198.51.100.4) | INTERNAL_IP4_DNS(198.51.100.4) | |||
INTERNAL_DNS_DOMAIN(example.com) | INTERNAL_DNS_DOMAIN(example.com) | |||
INTERNAL_DNS_TA(43547,8,1,B6225AB2CC613E0DCA7962BDC2342EA4F1B56083) | INTERNAL_DNSSEC_TA(43547,8,1,B6225AB2CC613E0DCA7962BDC2342EA4F1B56083) | |||
INTERNAL_DNS_TA(31406,8,2,F78CF3344F72137235098ECBBD08947C2C90....) | INTERNAL_DNSSEC_TA(31406,8,2,F78CF3344F72137235098ECBBD08947C2C90....) | |||
INTERNAL_DNS_DOMAIN(city.other.com) | INTERNAL_DNS_DOMAIN(city.other.com) | |||
4. Payload Formats | 4. Payload Formats | |||
4.1. INTERNAL_DNS_DOMAIN Configuration Attribute Type | 4.1. INTERNAL_DNS_DOMAIN Configuration Attribute Type | |||
1 2 3 | 1 2 3 | |||
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 | 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 | |||
+-+-----------------------------+-------------------------------+ | +-+-----------------------------+-------------------------------+ | |||
|R| Attribute Type | Length | | |R| Attribute Type | Length | | |||
+-+-----------------------------+-------------------------------+ | +-+-----------------------------+-------------------------------+ | |||
skipping to change at page 7, line 10 ¶ | skipping to change at page 7, line 10 ¶ | |||
o Reserved (1 bit) - Defined in IKEv2 RFC [RFC7296]. | o Reserved (1 bit) - Defined in IKEv2 RFC [RFC7296]. | |||
o Attribute Type (15 bits) 25 - INTERNAL_DNS_DOMAIN. | o Attribute Type (15 bits) 25 - INTERNAL_DNS_DOMAIN. | |||
o Length (2 octets, unsigned integer) - Length of domain name. | o Length (2 octets, unsigned integer) - Length of domain name. | |||
o Domain Name (0 or more octets) - A Fully Qualified Domain Name | o Domain Name (0 or more octets) - A Fully Qualified Domain Name | |||
used for Split DNS rules, such as example.com, in DNS presentation | used for Split DNS rules, such as example.com, in DNS presentation | |||
format and optionally using IDNA [RFC5890] for Internationalized | format and optionally using IDNA [RFC5890] for Internationalized | |||
Domain Names. The value is NOT null-terminated. | Domain Names. Implementors need to be careful that this value is | |||
not null-terminated. | ||||
4.2. INTERNAL_DNSSEC_TA Configuration Attribute | 4.2. INTERNAL_DNSSEC_TA Configuration Attribute | |||
1 2 3 | 1 2 3 | |||
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 | 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 | |||
+-+-----------------------------+-------------------------------+ | +-+-----------------------------+-------------------------------+ | |||
|R| Attribute Type | Length | | |R| Attribute Type | Length | | |||
+-+-----------------------------+---------------+---------------+ | +-+-----------------------------+---------------+---------------+ | |||
| Key Tag | Algorithm | Digest Type | | | Key Tag | Algorithm | Digest Type | | |||
+-------------------------------+---------------+---------------+ | +-------------------------------+---------------+---------------+ | |||
skipping to change at page 7, line 36 ¶ | skipping to change at page 7, line 37 ¶ | |||
o Reserved (1 bit) - Defined in IKEv2 RFC [RFC7296]. | o Reserved (1 bit) - Defined in IKEv2 RFC [RFC7296]. | |||
o Attribute Type (15 bits) [TBD IANA] - INTERNAL_DNSSEC_TA. | o Attribute Type (15 bits) [TBD IANA] - INTERNAL_DNSSEC_TA. | |||
o Length (2 octets, unsigned integer) - Length of DNSSEC Trust | o Length (2 octets, unsigned integer) - Length of DNSSEC Trust | |||
Anchor data. | Anchor data. | |||
o Key Tag value (0 or 2 octets, unsigned integer) - Key Tag as | o Key Tag value (0 or 2 octets, unsigned integer) - Key Tag as | |||
specified in [RFC4034] Section 5.1 | specified in [RFC4034] Section 5.1 | |||
o DNSKEY algorithm (0 or 1 octet) - Value from the IANA DNS Security | o Algorithm (0 or 1 octet) - DNSKEY algorithm value from the IANA | |||
Algorithm Numbers Registry | DNS Security Algorithm Numbers Registry | |||
o DS algorithm (0 or 1 octet) - Value from the IANA Delegation | o DS algorithm (0 or 1 octet) - DS algorithm value from the IANA | |||
Signer (DS) Resource Record (RR) Type Digest Algorithms Registry | Delegation Signer (DS) Resource Record (RR) Type Digest Algorithms | |||
Registry | ||||
o Digest (0 or more octets) - The digest as specified in [RFC4034] | o Digest (0 or more octets) - The DNSKEY digest as specified in | |||
Section 5.1 in presentation format. | [RFC4034] Section 5.1 in presentation format. | |||
5. Split DNS Usage Guidelines | 5. Split DNS Usage Guidelines | |||
If a CFG_REPLY payload contains no INTERNAL_DNS_DOMAIN attributes, | If a CFG_REPLY payload contains no INTERNAL_DNS_DOMAIN attributes, | |||
the client MAY use the provided INTERNAL_IP4_DNS or INTERNAL_IP6_DNS | the client MAY use the provided INTERNAL_IP4_DNS or INTERNAL_IP6_DNS | |||
servers as the default DNS server(s) for all queries. | servers as the default DNS server(s) for all queries. | |||
If a client is configured by local policy to only accept a limited | If a client is configured by local policy to only accept a limited | |||
number of INTERNAL_DNS_DOMAIN values, the client MUST ignore any | number of INTERNAL_DNS_DOMAIN values, the client MUST ignore any | |||
other INTERNAL_DNS_DOMAIN values. | other INTERNAL_DNS_DOMAIN values. | |||
skipping to change at page 9, line 23 ¶ | skipping to change at page 9, line 23 ¶ | |||
initiator MUST ignore Split DNS configurations assigned by the | initiator MUST ignore Split DNS configurations assigned by the | |||
responder. | responder. | |||
If a host connected to an authenticated IKE peer is connecting to | If a host connected to an authenticated IKE peer is connecting to | |||
another IKE peer that attempts to claim the same domain via the | another IKE peer that attempts to claim the same domain via the | |||
INTERNAL_DNS_DOMAIN attribute, the IKE connection should only process | INTERNAL_DNS_DOMAIN attribute, the IKE connection should only process | |||
the DNS information if the two connections are part of the same | the DNS information if the two connections are part of the same | |||
logical entity. Otherwise, the client should refuse the DNS | logical entity. Otherwise, the client should refuse the DNS | |||
information and potentially warn the enduser. | information and potentially warn the enduser. | |||
INTERNAL_DNSSEC_TA directives MUST immediately follow an | INTERNAL_DNSSEC_TA payloads MUST immediately follow an | |||
INTERNAL_DNS_DOMAIN directive. As the INTERNAL_DNSSEC_TA format | INTERNAL_DNS_DOMAIN payload. As the INTERNAL_DNSSEC_TA format itself | |||
itself does not contain the domain name, it relies on the preceding | does not contain the domain name, it relies on the preceding | |||
INTERNAL_DNS_DOMAIN to provide the domain for which it specifies the | INTERNAL_DNS_DOMAIN to provide the domain for which it specifies the | |||
trust anchor. | trust anchor. | |||
If the initiator is using DNSSEC validation for a domain in its | If the initiator is using DNSSEC validation for a domain in its | |||
public DNS view, and it requests and receives an INTERNAL_DNS_DOMAIN | public DNS view, and it requests and receives an INTERNAL_DNS_DOMAIN | |||
attribute without an INTERNAL_DNSSEC_TA, it will need to reconfigure | attribute without an INTERNAL_DNSSEC_TA, it will need to reconfigure | |||
its DNS resolver to allow for an insecure delegation. It SHOULD NOT | its DNS resolver to allow for an insecure delegation. It SHOULD NOT | |||
accept insecure delegations for domains that are DNSSEC signed in the | accept insecure delegations for domains that are DNSSEC signed in the | |||
public DNS view, for which it has not explicitely requested such | public DNS view, for which it has not explicitely requested such | |||
deletation by specifying the domain specifically using a | deletation by specifying the domain specifically using a | |||
skipping to change at page 10, line 26 ¶ | skipping to change at page 10, line 26 ¶ | |||
Figure 1 | Figure 1 | |||
8. References | 8. References | |||
8.1. Normative References | 8.1. Normative References | |||
[RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G., | [RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G., | |||
and E. Lear, "Address Allocation for Private Internets", | and E. Lear, "Address Allocation for Private Internets", | |||
BCP 5, RFC 1918, DOI 10.17487/RFC1918, February 1996, | BCP 5, RFC 1918, DOI 10.17487/RFC1918, February 1996, | |||
<http://www.rfc-editor.org/info/rfc1918>. | <https://www.rfc-editor.org/info/rfc1918>. | |||
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate | [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate | |||
Requirement Levels", BCP 14, RFC 2119, | Requirement Levels", BCP 14, RFC 2119, | |||
DOI 10.17487/RFC2119, March 1997, | DOI 10.17487/RFC2119, March 1997, <https://www.rfc- | |||
<http://www.rfc-editor.org/info/rfc2119>. | editor.org/info/rfc2119>. | |||
[RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. | [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. | |||
Rose, "Resource Records for the DNS Security Extensions", | Rose, "Resource Records for the DNS Security Extensions", | |||
RFC 4034, DOI 10.17487/RFC4034, March 2005, | RFC 4034, DOI 10.17487/RFC4034, March 2005, | |||
<http://www.rfc-editor.org/info/rfc4034>. | <https://www.rfc-editor.org/info/rfc4034>. | |||
[RFC5890] Klensin, J., "Internationalized Domain Names for | [RFC5890] Klensin, J., "Internationalized Domain Names for | |||
Applications (IDNA): Definitions and Document Framework", | Applications (IDNA): Definitions and Document Framework", | |||
RFC 5890, DOI 10.17487/RFC5890, August 2010, | RFC 5890, DOI 10.17487/RFC5890, August 2010, | |||
<http://www.rfc-editor.org/info/rfc5890>. | <https://www.rfc-editor.org/info/rfc5890>. | |||
[RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. | [RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. | |||
Kivinen, "Internet Key Exchange Protocol Version 2 | Kivinen, "Internet Key Exchange Protocol Version 2 | |||
(IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October | (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October | |||
2014, <http://www.rfc-editor.org/info/rfc7296>. | 2014, <https://www.rfc-editor.org/info/rfc7296>. | |||
8.2. Informative References | 8.2. Informative References | |||
[RFC2775] Carpenter, B., "Internet Transparency", RFC 2775, | [RFC2775] Carpenter, B., "Internet Transparency", RFC 2775, | |||
DOI 10.17487/RFC2775, February 2000, | DOI 10.17487/RFC2775, February 2000, <https://www.rfc- | |||
<http://www.rfc-editor.org/info/rfc2775>. | editor.org/info/rfc2775>. | |||
[RFC6761] Cheshire, S. and M. Krochmal, "Special-Use Domain Names", | [RFC6761] Cheshire, S. and M. Krochmal, "Special-Use Domain Names", | |||
RFC 6761, DOI 10.17487/RFC6761, February 2013, | RFC 6761, DOI 10.17487/RFC6761, February 2013, | |||
<http://www.rfc-editor.org/info/rfc6761>. | <https://www.rfc-editor.org/info/rfc6761>. | |||
[RFC7435] Dukhovni, V., "Opportunistic Security: Some Protection | [RFC7435] Dukhovni, V., "Opportunistic Security: Some Protection | |||
Most of the Time", RFC 7435, DOI 10.17487/RFC7435, | Most of the Time", RFC 7435, DOI 10.17487/RFC7435, | |||
December 2014, <http://www.rfc-editor.org/info/rfc7435>. | December 2014, <https://www.rfc-editor.org/info/rfc7435>. | |||
Authors' Addresses | Authors' Addresses | |||
Tommy Pauly | Tommy Pauly | |||
Apple Inc. | Apple Inc. | |||
1 Infinite Loop | 1 Infinite Loop | |||
Cupertino, California 95014 | Cupertino, California 95014 | |||
US | US | |||
Email: tpauly@apple.com | Email: tpauly@apple.com | |||
End of changes. 22 change blocks. | ||||
49 lines changed or deleted | 50 lines changed or added | |||
This html diff was produced by rfcdiff 1.46. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ |