draft-ietf-mboned-driad-amt-discovery-09.txt   draft-ietf-mboned-driad-amt-discovery-10.txt 
Mboned J. Holland Mboned J. Holland
Internet-Draft Akamai Technologies, Inc. Internet-Draft Akamai Technologies, Inc.
Updates: 7450 (if approved) October 27, 2019 Updates: 7450 (if approved) December 12, 2019
Intended status: Standards Track Intended status: Standards Track
Expires: April 29, 2020 Expires: June 14, 2020
DNS Reverse IP AMT Discovery DNS Reverse IP AMT Discovery
draft-ietf-mboned-driad-amt-discovery-09 draft-ietf-mboned-driad-amt-discovery-10
Abstract Abstract
This document updates RFC 7450 (Automatic Multicast Tunneling, or This document updates RFC 7450 (Automatic Multicast Tunneling, or
AMT) by extending the relay discovery process to use a new DNS AMT) by extending the relay discovery process to use a new DNS
resource record named AMTRELAY when discovering AMT relays for resource record named AMTRELAY when discovering AMT relays for
source-specific multicast channels. The reverse IP DNS zone for a source-specific multicast channels. The reverse IP DNS zone for a
multicast sender's IP address is configured to use AMTRELAY resource multicast sender's IP address is configured to use AMTRELAY resource
records to advertise a set of AMT relays that can receive and forward records to advertise a set of AMT relays that can receive and forward
multicast traffic from that sender over an AMT tunnel. multicast traffic from that sender over an AMT tunnel.
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 April 29, 2020. This Internet-Draft will expire on June 14, 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 23 skipping to change at page 2, line 23
1.2.1. Relays and Gateways . . . . . . . . . . . . . . . . . 4 1.2.1. Relays and Gateways . . . . . . . . . . . . . . . . . 4
1.2.2. Definitions . . . . . . . . . . . . . . . . . . . . . 4 1.2.2. Definitions . . . . . . . . . . . . . . . . . . . . . 4
2. Relay Discovery Operation . . . . . . . . . . . . . . . . . . 5 2. Relay Discovery Operation . . . . . . . . . . . . . . . . . . 5
2.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 6 2.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 6
2.2. Signaling and Discovery . . . . . . . . . . . . . . . . . 6 2.2. Signaling and Discovery . . . . . . . . . . . . . . . . . 6
2.3. Optimal Relay Selection . . . . . . . . . . . . . . . . . 8 2.3. Optimal Relay Selection . . . . . . . . . . . . . . . . . 8
2.3.1. Overview . . . . . . . . . . . . . . . . . . . . . . 8 2.3.1. Overview . . . . . . . . . . . . . . . . . . . . . . 8
2.3.2. Preference Ordering . . . . . . . . . . . . . . . . . 10 2.3.2. Preference Ordering . . . . . . . . . . . . . . . . . 10
2.3.3. Connecting to Multiple Relays . . . . . . . . . . . . 12 2.3.3. Connecting to Multiple Relays . . . . . . . . . . . . 12
2.4. Happy Eyeballs . . . . . . . . . . . . . . . . . . . . . 12 2.4. Happy Eyeballs . . . . . . . . . . . . . . . . . . . . . 12
2.4.1. Overview . . . . . . . . . . . . . . . . . . . . . . 12 2.4.1. Overview . . . . . . . . . . . . . . . . . . . . . . 13
2.4.2. Algorithm Guidelines . . . . . . . . . . . . . . . . 13 2.4.2. Algorithm Guidelines . . . . . . . . . . . . . . . . 13
2.4.3. Connection Definition . . . . . . . . . . . . . . . . 14 2.4.3. Connection Definition . . . . . . . . . . . . . . . . 14
2.5. Guidelines for Restarting Discovery . . . . . . . . . . . 14 2.5. Guidelines for Restarting Discovery . . . . . . . . . . . 15
2.5.1. Overview . . . . . . . . . . . . . . . . . . . . . . 14 2.5.1. Overview . . . . . . . . . . . . . . . . . . . . . . 15
2.5.2. Updates to Restarting Events . . . . . . . . . . . . 15 2.5.2. Updates to Restarting Events . . . . . . . . . . . . 15
2.5.3. Tunnel Stability . . . . . . . . . . . . . . . . . . 16 2.5.3. Tunnel Stability . . . . . . . . . . . . . . . . . . 16
2.5.4. Traffic Health . . . . . . . . . . . . . . . . . . . 16 2.5.4. Traffic Health . . . . . . . . . . . . . . . . . . . 17
2.5.5. Relay Loaded or Shutting Down . . . . . . . . . . . . 18 2.5.5. Relay Loaded or Shutting Down . . . . . . . . . . . . 18
2.5.6. Relay Discovery Messages vs. Restarting Discovery . . 18 2.5.6. Relay Discovery Messages vs. Restarting Discovery . . 19
2.5.7. Independent Discovery Per Traffic Source . . . . . . 19 2.5.7. Independent Discovery Per Traffic Source . . . . . . 19
2.6. DNS Configuration . . . . . . . . . . . . . . . . . . . . 19 2.6. DNS Configuration . . . . . . . . . . . . . . . . . . . . 20
2.7. Waiting for DNS resolution . . . . . . . . . . . . . . . 20 2.7. Waiting for DNS resolution . . . . . . . . . . . . . . . 20
3. Example Deployments . . . . . . . . . . . . . . . . . . . . . 20 3. Example Deployments . . . . . . . . . . . . . . . . . . . . . 20
3.1. Example Receiving Networks . . . . . . . . . . . . . . . 20 3.1. Example Receiving Networks . . . . . . . . . . . . . . . 20
3.1.1. Tier 3 ISP . . . . . . . . . . . . . . . . . . . . . 20 3.1.1. Internet Service Provider . . . . . . . . . . . . . . 21
3.1.2. Small Office . . . . . . . . . . . . . . . . . . . . 21 3.1.2. Small Office . . . . . . . . . . . . . . . . . . . . 22
3.2. Example Sending Networks . . . . . . . . . . . . . . . . 23 3.2. Example Sending Networks . . . . . . . . . . . . . . . . 23
3.2.1. Sender-controlled Relays . . . . . . . . . . . . . . 23 3.2.1. Sender-controlled Relays . . . . . . . . . . . . . . 23
3.2.2. Provider-controlled Relays . . . . . . . . . . . . . 24 3.2.2. Provider-controlled Relays . . . . . . . . . . . . . 24
4. AMTRELAY Resource Record Definition . . . . . . . . . . . . . 25 4. AMTRELAY Resource Record Definition . . . . . . . . . . . . . 25
4.1. AMTRELAY RRType . . . . . . . . . . . . . . . . . . . . . 25 4.1. AMTRELAY RRType . . . . . . . . . . . . . . . . . . . . . 25
4.2. AMTRELAY RData Format . . . . . . . . . . . . . . . . . . 25 4.2. AMTRELAY RData Format . . . . . . . . . . . . . . . . . . 25
4.2.1. RData Format - Precedence . . . . . . . . . . . . . . 26 4.2.1. RData Format - Precedence . . . . . . . . . . . . . . 26
4.2.2. RData Format - Discovery Optional (D-bit) . . . . . . 26 4.2.2. RData Format - Discovery Optional (D-bit) . . . . . . 26
4.2.3. RData Format - Type . . . . . . . . . . . . . . . . . 26 4.2.3. RData Format - Type . . . . . . . . . . . . . . . . . 26
4.2.4. RData Format - Relay . . . . . . . . . . . . . . . . 27 4.2.4. RData Format - Relay . . . . . . . . . . . . . . . . 27
skipping to change at page 3, line 14 skipping to change at page 3, line 14
4.3.2. Examples . . . . . . . . . . . . . . . . . . . . . . 28 4.3.2. Examples . . . . . . . . . . . . . . . . . . . . . . 28
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28
6. Security Considerations . . . . . . . . . . . . . . . . . . . 29 6. Security Considerations . . . . . . . . . . . . . . . . . . . 29
6.1. Use of AMT . . . . . . . . . . . . . . . . . . . . . . . 29 6.1. Use of AMT . . . . . . . . . . . . . . . . . . . . . . . 29
6.2. Record-spoofing . . . . . . . . . . . . . . . . . . . . . 29 6.2. Record-spoofing . . . . . . . . . . . . . . . . . . . . . 29
6.3. Congestion . . . . . . . . . . . . . . . . . . . . . . . 30 6.3. Congestion . . . . . . . . . . . . . . . . . . . . . . . 30
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 30 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 30
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 30 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 30
8.1. Normative References . . . . . . . . . . . . . . . . . . 30 8.1. Normative References . . . . . . . . . . . . . . . . . . 30
8.2. Informative References . . . . . . . . . . . . . . . . . 32 8.2. Informative References . . . . . . . . . . . . . . . . . 32
Appendix A. Unknown RRType construction . . . . . . . . . . . . 33 Appendix A. Unknown RRType construction . . . . . . . . . . . . 34
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 34 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 35
1. Introduction 1. Introduction
This document defines DNS Reverse IP AMT Discovery (DRIAD), a This document defines DNS Reverse IP AMT Discovery (DRIAD), a
mechanism for AMT gateways to discover AMT relays that are capable of mechanism for AMT gateways to discover AMT relays that are capable of
forwarding multicast traffic from a known source IP address. forwarding multicast traffic from a known source IP address.
AMT (Automatic Multicast Tunneling) is defined in [RFC7450], and AMT (Automatic Multicast Tunneling) is defined in [RFC7450], and
provides a method to transport multicast traffic over a unicast provides a method to transport multicast traffic over a unicast
tunnel, in order to traverse non-multicast-capable network segments. tunnel, in order to traverse non-multicast-capable network segments.
skipping to change at page 10, line 5 skipping to change at page 10, line 5
When the above conditions are met, the gateway has no path within its When the above conditions are met, the gateway has no path within its
local network that can receive multicast traffic from the source IP local network that can receive multicast traffic from the source IP
of the (S,G). of the (S,G).
In this situation, the best way to find a relay that can forward the In this situation, the best way to find a relay that can forward the
required traffic is to use information that comes from the operator required traffic is to use information that comes from the operator
of the sender. When the sender has configured an AMTRELAY RR, of the sender. When the sender has configured an AMTRELAY RR,
gateways can use the DRIAD mechanism defined in this document to gateways can use the DRIAD mechanism defined in this document to
discover the relay information provided by the sender. discover the relay information provided by the sender.
Note that the DNS-SD service is not source-specific, so even though
several methods of finding a more local source of multicast traffic
connectivity are preferred where available to using a relay provided
by an AMTRELAY RR, a gateway further upstream would still be using
the AMTRELAY RR unless the upstream network has a peering or direct
connectivity that provides an alternative end-to-end multicast
transport path for the (S,G)'s traffic.
2.3.2. Preference Ordering 2.3.2. Preference Ordering
This section defines a preference ordering for relay addresses during This section defines a preference ordering for relay addresses during
the relay discovery process. Gateways are encouraged to implement a the relay discovery process. Gateways are encouraged to implement a
Happy Eyeballs algorithm to try candidate relays concurrently, but Happy Eyeballs algorithm to try candidate relays concurrently, but
even gateways that do not implement a Happy Eyeballs algorithm SHOULD even gateways that do not implement a Happy Eyeballs algorithm SHOULD
use this ordering, except as noted. use this ordering, except as noted.
When establishing an AMT tunnel to forward multicast data, it's very When establishing an AMT tunnel to forward multicast data, it's very
important for the discovery process to prioritize the network important for the discovery process to prioritize the network
skipping to change at page 14, line 25 skipping to change at page 14, line 37
connection attempt as "generally when the TCP handshake completes". connection attempt as "generally when the TCP handshake completes".
There is no normative definition of a connection in the AMT There is no normative definition of a connection in the AMT
specification [RFC7450], and there is no TCP connection involved in specification [RFC7450], and there is no TCP connection involved in
an AMT tunnel. an AMT tunnel.
However, the concept of an AMT connection in the context of a Happy However, the concept of an AMT connection in the context of a Happy
Eyeballs algorithm is a useful one, and so this section provides the Eyeballs algorithm is a useful one, and so this section provides the
following normative definition: following normative definition:
o An AMT connection is completed successfully when the gateway o An AMT connection is established successfully when the gateway
receives from a newly discovered relay a valid Membership Query receives from a newly discovered relay a valid Membership Query
message (Section 5.1.4 of [RFC7450]) that does not have the L flag message (Section 5.1.4 of [RFC7450]) that does not have the L flag
set. set.
See Section 2.5.5 of this document for further information about the See Section 2.5.5 of this document for further information about the
relevance of the L flag to the establishment of a Happy Eyeballs relevance of the L flag to the establishment of a Happy Eyeballs
connection. See Section 2.5.4 for an overview of how to respond if connection. See Section 2.5.4 for an overview of how to respond if
the connection does not provide multicast connectivity to the source. the connection does not provide multicast connectivity to the source.
To "cancel" this kind of AMT connection for the Happy Eyeballs To "cancel" this kind of AMT connection for the Happy Eyeballs
skipping to change at page 17, line 12 skipping to change at page 17, line 21
received in a reasonable time, it's appropriate for the gateway to received in a reasonable time, it's appropriate for the gateway to
restart the discovery process. restart the discovery process.
If the gateway restarts the discovery process multiple times If the gateway restarts the discovery process multiple times
consecutively for this reason, the timeout period SHOULD be adjusted consecutively for this reason, the timeout period SHOULD be adjusted
to provide a random exponential back-off. to provide a random exponential back-off.
The RECOMMENDED timeout is a random value in the range The RECOMMENDED timeout is a random value in the range
[initial_timeout, MIN(initial_timeout * 2^retry_count, [initial_timeout, MIN(initial_timeout * 2^retry_count,
maximum_timeout)], with a RECOMMENDED initial_timeout of 4 seconds maximum_timeout)], with a RECOMMENDED initial_timeout of 4 seconds
and a RECOMMENDED maximum_timeout of 120 seconds. and a RECOMMENDED maximum_timeout of 120 seconds (which is the
recommended minimum NAT mapping timeout described in [RFC4787]).
Note that the recommended initial_timeout is larger than the initial Note that the recommended initial_timeout is larger than the initial
timout recommended in the similar algorithm from Section 5.2.3.4.3 of timout recommended in the similar algorithm from Section 5.2.3.4.3 of
[RFC7450]. This is to provide time for RPF Join propagation in the [RFC7450]. This is to provide time for RPF Join propagation in the
sending network. Although the timeout values may be administratively sending network. Although the timeout values may be administratively
adjusted to support performance requirements, operators are advised adjusted to support performance requirements, operators are advised
to consider the possibility of join propagation delays between the to consider the possibility of join propagation delays between the
sender and the relay when choosing an appropriate timeout value. sender and the relay when choosing an appropriate timeout value.
Gateways restarting the discovery process because of an absence of Gateways restarting the discovery process because of an absence of
skipping to change at page 20, line 36 skipping to change at page 21, line 4
As with the waiting process for the Relay Advertisement message from As with the waiting process for the Relay Advertisement message from
Section 5.2.3.4.3 of [RFC7450], the RECOMMENDED timeout is a random Section 5.2.3.4.3 of [RFC7450], the RECOMMENDED timeout is a random
value in the range [initial_timeout, MIN(initial_timeout * value in the range [initial_timeout, MIN(initial_timeout *
2^retry_count, maximum_timeout)], with a RECOMMENDED initial_timeout 2^retry_count, maximum_timeout)], with a RECOMMENDED initial_timeout
of 1 second and a RECOMMENDED maximum_timeout of 120 seconds. of 1 second and a RECOMMENDED maximum_timeout of 120 seconds.
3. Example Deployments 3. Example Deployments
3.1. Example Receiving Networks 3.1. Example Receiving Networks
3.1.1. Internet Service Provider
3.1.1. Tier 3 ISP One example of a receiving network is an Internet Service Provider
(ISP) that offers multicast ingest services to its subscribers,
One example of a receiving network is an ISP that offers multicast illustrated in Figure 3.
ingest services to its subscribers, illustrated in Figure 3.
In the example network below, subscribers can join (S,G)s with MLDv2 In the example network below, subscribers can join (S,G)s with MLDv2
or IGMPv3 as described in [RFC4604], and the AMT gateway in this ISP or IGMPv3 as described in [RFC4604], and the AMT gateway in this ISP
can receive and forward multicast traffic from one of the example can receive and forward multicast traffic from one of the example
sending networks in Section 3.2 by discovering the appropriate AMT sending networks in Section 3.2 by discovering the appropriate AMT
relays with a DNS lookup for the AMTRELAY RR with the reverse IP of relays with a DNS lookup for the AMTRELAY RR with the reverse IP of
the source in the (S,G). the source in the (S,G).
Internet Internet
^ ^ Multicast-enabled ^ ^ Multicast-enabled
skipping to change at page 29, line 44 skipping to change at page 29, line 44
established and secured. established and secured.
6.2. Record-spoofing 6.2. Record-spoofing
The AMTRELAY resource record contains information that SHOULD be The AMTRELAY resource record contains information that SHOULD be
communicated to the DNS client without being modified. The method communicated to the DNS client without being modified. The method
used to ensure the result was unmodified is up to the client. used to ensure the result was unmodified is up to the client.
There must be a trust relationship between the end consumer of this There must be a trust relationship between the end consumer of this
resource record and the DNS server. This relationship may be end-to- resource record and the DNS server. This relationship may be end-to-
end DNSSEC validation, a TSIG [RFC2845] or SIG(0) [RFC2931] channel end DNSSEC validation, or a secure connection to a trusted DNS server
to another secure source, a secure local channel on the host, DNS that provides end-to-end safety, to prevent record-spoofing of the
over TLS [RFC7858] or HTTPS [RFC8484], or some other secure response from the trusted server. The connection to the trusted
mechanism. server can use any secure channel, such as with a TSIG [RFC2845] or
SIG(0) [RFC2931] channel, a secure local channel on the host, DNS
over TLS [RFC7858], DNS over HTTPS [RFC8484], or some other mechanism
that provides authentication of the RR.
If an AMT gateway accepts a maliciously crafted AMTRELAY record, the If an AMT gateway accepts a maliciously crafted AMTRELAY record, the
result could be a Denial of Service, or receivers processing result could be a Denial of Service, or receivers processing
multicast traffic from a source under the attacker's control. multicast traffic from a source under the attacker's control.
6.3. Congestion 6.3. Congestion
Multicast traffic, particularly interdomain multicast traffic, Multicast traffic, particularly interdomain multicast traffic,
carries some congestion risks, as described in Section 4 of carries some congestion risks, as described in Section 4 of
[RFC8085]. [RFC8085].
skipping to change at page 30, line 29 skipping to change at page 30, line 33
attack. attack.
7. Acknowledgements 7. Acknowledgements
This specification was inspired by the previous work of Doug Nortz, This specification was inspired by the previous work of Doug Nortz,
Robert Sayko, David Segelstein, and Percy Tarapore, presented in the Robert Sayko, David Segelstein, and Percy Tarapore, presented in the
MBONED working group at IETF 93. MBONED working group at IETF 93.
Thanks to Jeff Goldsmith, Toerless Eckert, Mikael Abrahamsson, Lenny Thanks to Jeff Goldsmith, Toerless Eckert, Mikael Abrahamsson, Lenny
Giuliano, Mark Andrews, Sandy Zheng, Kyle Rose, Ben Kaduk, Bill Giuliano, Mark Andrews, Sandy Zheng, Kyle Rose, Ben Kaduk, Bill
Atwood, Tim Chown, and Warren Kumari for their very helpful comments. Atwood, Tim Chown, Warren Kumari, Dan Romanescu, Bernard Aboba,
Carlos Pignataro, and Niclas Comstedt for their very helpful reviews
and comments.
8. References 8. References
8.1. Normative References 8.1. Normative References
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities", [RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987,
<https://www.rfc-editor.org/info/rfc1034>. <https://www.rfc-editor.org/info/rfc1034>.
[RFC1035] Mockapetris, P., "Domain names - implementation and [RFC1035] Mockapetris, P., "Domain names - implementation and
skipping to change at page 32, line 47 skipping to change at page 33, line 5
July 2003, <https://www.rfc-editor.org/info/rfc3550>. July 2003, <https://www.rfc-editor.org/info/rfc3550>.
[RFC4025] Richardson, M., "A Method for Storing IPsec Keying [RFC4025] Richardson, M., "A Method for Storing IPsec Keying
Material in DNS", RFC 4025, DOI 10.17487/RFC4025, March Material in DNS", RFC 4025, DOI 10.17487/RFC4025, March
2005, <https://www.rfc-editor.org/info/rfc4025>. 2005, <https://www.rfc-editor.org/info/rfc4025>.
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the [RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, DOI 10.17487/RFC4301, Internet Protocol", RFC 4301, DOI 10.17487/RFC4301,
December 2005, <https://www.rfc-editor.org/info/rfc4301>. December 2005, <https://www.rfc-editor.org/info/rfc4301>.
[RFC4787] Audet, F., Ed. and C. Jennings, "Network Address
Translation (NAT) Behavioral Requirements for Unicast
UDP", BCP 127, RFC 4787, DOI 10.17487/RFC4787, January
2007, <https://www.rfc-editor.org/info/rfc4787>.
[RFC5110] Savola, P., "Overview of the Internet Multicast Routing [RFC5110] Savola, P., "Overview of the Internet Multicast Routing
Architecture", RFC 5110, DOI 10.17487/RFC5110, January Architecture", RFC 5110, DOI 10.17487/RFC5110, January
2008, <https://www.rfc-editor.org/info/rfc5110>. 2008, <https://www.rfc-editor.org/info/rfc5110>.
[RFC6726] Paila, T., Walsh, R., Luby, M., Roca, V., and R. Lehtonen, [RFC6726] Paila, T., Walsh, R., Luby, M., Roca, V., and R. Lehtonen,
"FLUTE - File Delivery over Unidirectional Transport", "FLUTE - File Delivery over Unidirectional Transport",
RFC 6726, DOI 10.17487/RFC6726, November 2012, RFC 6726, DOI 10.17487/RFC6726, November 2012,
<https://www.rfc-editor.org/info/rfc6726>. <https://www.rfc-editor.org/info/rfc6726>.
[RFC7359] Gont, F., "Layer 3 Virtual Private Network (VPN) Tunnel [RFC7359] Gont, F., "Layer 3 Virtual Private Network (VPN) Tunnel
 End of changes. 19 change blocks. 
25 lines changed or deleted 44 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/