draft-ietf-v6ops-conditional-ras-02.txt   draft-ietf-v6ops-conditional-ras-03.txt 
IPv6 Operations J. Linkova IPv6 Operations J. Linkova
Internet-Draft Google Internet-Draft Google
Intended status: Informational M. Stucchi Intended status: Informational M. Stucchi
Expires: September 19, 2018 RIPE NCC Expires: October 1, 2018 RIPE NCC
March 18, 2018 March 30, 2018
Using Conditional Router Advertisements for Enterprise Multihoming Using Conditional Router Advertisements for Enterprise Multihoming
draft-ietf-v6ops-conditional-ras-02 draft-ietf-v6ops-conditional-ras-03
Abstract Abstract
This document discusses most common scenarios of connecting an This document discusses most common scenarios of connecting an
enterprise network to multiple ISPs using an address space assigned enterprise network to multiple ISPs using an address space assigned
by an ISP. The problem of enterprise multihoming without address by an ISP. The problem of enterprise multihoming without address
translation of any form has not been solved yet as it requires both translation of any form has not been solved yet as it requires both
the network to select the correct egress ISP based on the packet the network to select the correct egress ISP based on the packet
source address and hosts to select the correct source address based source address and hosts to select the correct source address based
on the desired egress ISP for that traffic. on the desired egress ISP for that traffic.
skipping to change at page 1, line 49 skipping to change at page 1, line 49
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 September 19, 2018. This Internet-Draft will expire on October 1, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2018 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Common Enterprise Multihoming Scenarios . . . . . . . . . . . 3 2. Common Enterprise Multihoming Scenarios . . . . . . . . . . . 4
2.1. Two ISP Uplinks, Primary and Backup . . . . . . . . . . . 3 2.1. Two ISP Uplinks, Primary and Backup . . . . . . . . . . . 4
2.2. Two ISP Uplinks, Used for Load Balancing . . . . . . . . 4 2.2. Two ISP Uplinks, Used for Load Balancing . . . . . . . . 4
3. Conditional Router Advertisements . . . . . . . . . . . . . . 4 3. Conditional Router Advertisements . . . . . . . . . . . . . . 5
3.1. Solution Overview . . . . . . . . . . . . . . . . . . . . 4 3.1. Solution Overview . . . . . . . . . . . . . . . . . . . . 5
3.1.1. Uplink Selection . . . . . . . . . . . . . . . . . . 4 3.1.1. Uplink Selection . . . . . . . . . . . . . . . . . . 5
3.1.2. Source Address Selection and Conditional RAs . . . . 5 3.1.2. Source Address Selection and Conditional RAs . . . . 5
3.2. Example Scenarios . . . . . . . . . . . . . . . . . . . . 6 3.2. Example Scenarios . . . . . . . . . . . . . . . . . . . . 7
3.2.1. Single Router, Primary/Backup Uplinks . . . . . . . . 7 3.2.1. Single Router, Primary/Backup Uplinks . . . . . . . . 7
3.2.2. Two Routers, Primary/Backup Uplinks . . . . . . . . . 8 3.2.2. Two Routers, Primary/Backup Uplinks . . . . . . . . . 8
3.2.3. Single Router, Load Balancing Between Uplinks . . . . 10 3.2.3. Single Router, Load Balancing Between Uplinks . . . . 10
3.2.4. Two Router, Load Balancing Between Uplinks . . . . . 10 3.2.4. Two Router, Load Balancing Between Uplinks . . . . . 11
3.2.5. Topologies with Dedicated Border Routers . . . . . . 11 3.2.5. Topologies with Dedicated Border Routers . . . . . . 11
3.2.6. Intra-Site Communication during Simultaneous Uplinks 3.2.6. Intra-Site Communication during Simultaneous Uplinks
Outage . . . . . . . . . . . . . . . . . . . . . . . 13 Outage . . . . . . . . . . . . . . . . . . . . . . . 13
3.2.7. Uplink Damping . . . . . . . . . . . . . . . . . . . 13 3.2.7. Uplink Damping . . . . . . . . . . . . . . . . . . . 13
3.3. Solution Limitations . . . . . . . . . . . . . . . . . . 13 3.3. Solution Limitations . . . . . . . . . . . . . . . . . . 14
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 3.3.1. Connections Preservation . . . . . . . . . . . . . . 14
5. Security Considerations . . . . . . . . . . . . . . . . . . . 14 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
5.1. Privacy Considerations . . . . . . . . . . . . . . . . . 14 5. Security Considerations . . . . . . . . . . . . . . . . . . . 15
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 5.1. Privacy Considerations . . . . . . . . . . . . . . . . . 15
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15
7.1. Normative References . . . . . . . . . . . . . . . . . . 14 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 15
7.2. Informative References . . . . . . . . . . . . . . . . . 16 7.1. Normative References . . . . . . . . . . . . . . . . . . 15
Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 17 7.2. Informative References . . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18
1. Introduction 1. Introduction
Multihoming is an obvious requirement for many enterprise networks to Multihoming is an obvious requirement for many enterprise networks to
ensure the desired level of network reliability. However, using more ensure the desired level of network reliability. However, using more
than one ISP (and address space assigned by those ISPs) introduces than one ISP (and address space assigned by those ISPs) introduces
the problem of assigning IP addresses to hosts. In IPv4 there is no the problem of assigning IP addresses to hosts. In IPv4 there is no
choice but using [RFC1918] address space and NAT ([RFC3022]) at the choice but using [RFC1918] address space and NAT ([RFC3022]) at the
network edge. Using Provider Independent (PI) address space is not network edge. Using Provider Independent (PI) address space is not
always an option as it requires running BGP between the enterprise always an option as it requires running BGP between the enterprise
skipping to change at page 3, line 43 skipping to change at page 3, line 43
address selection algorithm ([RFC6724]) which has not been widely address selection algorithm ([RFC6724]) which has not been widely
implemented at the moment this document was written. Therefore implemented at the moment this document was written. Therefore
network administrators in enterprise networks can't yet assume that network administrators in enterprise networks can't yet assume that
all devices in their network support the rule 5.5, especially in the all devices in their network support the rule 5.5, especially in the
quite common BYOD ("Bring Your Own Device") scenario. However, while quite common BYOD ("Bring Your Own Device") scenario. However, while
it does not seem feasible to solve all the possible multihoming it does not seem feasible to solve all the possible multihoming
scenarios without reliying on rule 5.5, it is possible to provide scenarios without reliying on rule 5.5, it is possible to provide
IPv6 multihoming using provider-assigned (PA) address space for the IPv6 multihoming using provider-assigned (PA) address space for the
most common use cases. This document discusses how the general most common use cases. This document discusses how the general
solution described in [I-D.ietf-rtgwg-enterprise-pa-multihoming] can solution described in [I-D.ietf-rtgwg-enterprise-pa-multihoming] can
be applied to those two specific cases. be applied to scenarios when:
o An enterprise network has two or more ISP uplinks;
o Those uplinks are used for Internet access in active/backup or
load sharing mode w/o any soficticated traffic engineering
requirements;
o Each ISP assigns the network a subnet from its own PA address
space
o Hosts in the enterprise network are not expected to support the
Rule 5.5 of the default address selection algorithm ([RFC6724]).
2. Common Enterprise Multihoming Scenarios 2. Common Enterprise Multihoming Scenarios
2.1. Two ISP Uplinks, Primary and Backup 2.1. Two ISP Uplinks, Primary and Backup
This scenario has the following key characteristics: This scenario has the following key characteristics:
o The enterprise network is using uplinks to two (or more) ISPs for o The enterprise network is using uplinks to two (or more) ISPs for
Internet access; Internet access;
skipping to change at page 4, line 18 skipping to change at page 4, line 30
uplinks are backup and are not expected to be used while the uplinks are backup and are not expected to be used while the
primary one is operational; primary one is operational;
o If the primary uplink is operational, all Internet traffic should o If the primary uplink is operational, all Internet traffic should
flow via that uplink; flow via that uplink;
o When the primary uplink fails the Internet traffic needs to flow o When the primary uplink fails the Internet traffic needs to flow
via the backup uplinks; via the backup uplinks;
o Recovery of the primary uplink needs to trigger the traffic o Recovery of the primary uplink needs to trigger the traffic
switchover from the backup uplinks back to primary one. switchover from the backup uplinks back to primary one;
o Hosts in the enterprise network are not expected to support the
Rule 5.5 of the default address selection algorithm ([RFC6724]).
2.2. Two ISP Uplinks, Used for Load Balancing 2.2. Two ISP Uplinks, Used for Load Balancing
This scenario has the following key characteristics: This scenario has the following key characteristics:
o The enterprise network is using uplinks to two (or more) ISPs for o The enterprise network is using uplinks to two (or more) ISPs for
Internet access; Internet access;
o Each ISP assigns an IPv6 PA address space; o Each ISP assigns an IPv6 PA address space;
o All the uplinks may be used simultaneously, with the traffic flows o All the uplinks may be used simultaneously, with the traffic flows
being randomly (not nessesary equally) distributed between them. being randomly (not nessesary equally) distributed between them;
o Hosts in the enterprise network are not expected to support the
Rule 5.5 of the default address selection algorithm ([RFC6724]).
3. Conditional Router Advertisements 3. Conditional Router Advertisements
3.1. Solution Overview 3.1. Solution Overview
3.1.1. Uplink Selection 3.1.1. Uplink Selection
As discussed in [I-D.ietf-rtgwg-enterprise-pa-multihoming], one of As discussed in [I-D.ietf-rtgwg-enterprise-pa-multihoming], one of
the two main problems to be solved in the enterprise multihoming the two main problems to be solved in the enterprise multihoming
scenario is the problem of the next-hop (uplink) selection based on scenario is the problem of the next-hop (uplink) selection based on
skipping to change at page 13, line 51 skipping to change at page 14, line 12
in all addresses being deprecated for a while after the flapping in all addresses being deprecated for a while after the flapping
uplink recovers.) uplink recovers.)
3.3. Solution Limitations 3.3. Solution Limitations
It should be noted that the proposed approach is not a silver bullet It should be noted that the proposed approach is not a silver bullet
for all possible multihoming scenarios. The main goal is to solve for all possible multihoming scenarios. The main goal is to solve
some common use cases so it would suit very well relatively simple some common use cases so it would suit very well relatively simple
topologies with straightforward policies. The more complex the topologies with straightforward policies. The more complex the
network topology and the corresponding routing policies more network topology and the corresponding routing policies more
configuration would be required to implement the solution. Another configuration would be required to implement the solution.
limitation is related to the load balancing between the uplinks. In
that scenario when both uplinks are active hosts would select the Another limitation is related to the load balancing between the
source prefix using the Default Address Selection algorithm uplinks. In that scenario when both uplinks are active hosts would
([RFC6724]) and therefore the load between two uplinks most likely select the source prefix using the Default Address Selection
would not be evenly distributed. (However the proposed mechanism algorithm ([RFC6724]) and therefore the load between two uplinks most
does allow a creative way of controlling uplinks load in SDN networks likely would not be evenly distributed. (However the proposed
where controllers might selectively deprecate prefixes on some hosts mechanism does allow a creative way of controlling uplinks load in
but not others to move egress traffic between uplinks). Also the SDN networks where controllers might selectively deprecate prefixes
prefix selection does not take into account any other uplinks on some hosts but not others to move egress traffic between uplinks).
properties (such as RTT etc) so egress traffic might not be sent to Also the prefix selection does not take into account any other
the nearest uplink if the corresponding prefix is selected as a uplinks properties (such as RTT etc) so egress traffic might not be
source. In general if not all uplinks are equal and some uplinks are sent to the nearest uplink if the corresponding prefix is selected as
expected to be preferred over others then the network adminitrator a source. In general if not all uplinks are equal and some uplinks
should ensure that prefixes from non-preferred ISP(s) are kept are expected to be preferred over others then the network
deprecated (so primary/backup setup is used). adminitrator should ensure that prefixes from non-preferred ISP(s)
are kept deprecated (so primary/backup setup is used).
3.3.1. Connections Preservation
The proposed solution is not designed to preserve connections state
after an uplink failure. If all uplinks to an ISP go down all
sessions to/from addresses from that ISP address space are
interrupted as there is no egress path for those packets and there is
not return path from Internet to the correspodning prefix. In this
regard it is similar to IPv4 multihoming using NAT, where an uplink
failure and failover to another uplink means that a public IPv4
address changes and all existing connections are interrupted.
An uplink recovery, however, does not nessesary leads to connections
interruption. In the load sharing/balancing scenario an uplink
recovery does not affect any existing connections at all. In the
active/backup topology when the primary uplink recovers from the
failure and the backup prefix is deprectaed, the existing sessions
(established to/from the backup ISP addresses) can be preserved if
the routers are configured as described in Section 3.2.1 and send
packets with the backup ISP source addresses to the backup uplink
even when the primary one is operational. As a result, the primary
uplink recovery makes the usage of the backup ISP addresses
discouraged but still possible.
It should be noted that in IPv4 multihoming with NAT, when the egress
interface is chosen without taking packet source address into account
(as internal hosts usually have addresses from [RFC1918] space),
sessions can not be preserved after an uplink recovery.
4. IANA Considerations 4. IANA Considerations
This memo asks the IANA for no new parameters. This memo asks the IANA for no new parameters.
5. Security Considerations 5. Security Considerations
This memo introduces no new security considerations. This memo introduces no new security considerations.
5.1. Privacy Considerations 5.1. Privacy Considerations
skipping to change at page 15, line 5 skipping to change at page 15, line 43
[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,
<https://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-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460,
December 1998, <https://www.rfc-editor.org/info/rfc2460>.
[RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering:
Defeating Denial of Service Attacks which employ IP Source Defeating Denial of Service Attacks which employ IP Source
Address Spoofing", BCP 38, RFC 2827, DOI 10.17487/RFC2827, Address Spoofing", BCP 38, RFC 2827, DOI 10.17487/RFC2827,
May 2000, <https://www.rfc-editor.org/info/rfc2827>. May 2000, <https://www.rfc-editor.org/info/rfc2827>.
[RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network [RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network
Address Translator (Traditional NAT)", RFC 3022, Address Translator (Traditional NAT)", RFC 3022,
DOI 10.17487/RFC3022, January 2001, DOI 10.17487/RFC3022, January 2001,
<https://www.rfc-editor.org/info/rfc3022>. <https://www.rfc-editor.org/info/rfc3022>.
skipping to change at page 16, line 5 skipping to change at page 16, line 36
[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
Address Autoconfiguration", RFC 4862, Address Autoconfiguration", RFC 4862,
DOI 10.17487/RFC4862, September 2007, DOI 10.17487/RFC4862, September 2007,
<https://www.rfc-editor.org/info/rfc4862>. <https://www.rfc-editor.org/info/rfc4862>.
[RFC6296] Wasserman, M. and F. Baker, "IPv6-to-IPv6 Network Prefix [RFC6296] Wasserman, M. and F. Baker, "IPv6-to-IPv6 Network Prefix
Translation", RFC 6296, DOI 10.17487/RFC6296, June 2011, Translation", RFC 6296, DOI 10.17487/RFC6296, June 2011,
<https://www.rfc-editor.org/info/rfc6296>. <https://www.rfc-editor.org/info/rfc6296>.
[RFC6724] Thaler, D., Ed., Draves, R., Matsumoto, A., and T. Chown,
"Default Address Selection for Internet Protocol Version 6
(IPv6)", RFC 6724, DOI 10.17487/RFC6724, September 2012,
<https://www.rfc-editor.org/info/rfc6724>.
[RFC7157] Troan, O., Ed., Miles, D., Matsushima, S., Okimoto, T., [RFC7157] Troan, O., Ed., Miles, D., Matsushima, S., Okimoto, T.,
and D. Wing, "IPv6 Multihoming without Network Address and D. Wing, "IPv6 Multihoming without Network Address
Translation", RFC 7157, DOI 10.17487/RFC7157, March 2014, Translation", RFC 7157, DOI 10.17487/RFC7157, March 2014,
<https://www.rfc-editor.org/info/rfc7157>. <https://www.rfc-editor.org/info/rfc7157>.
[RFC8028] Baker, F. and B. Carpenter, "First-Hop Router Selection by [RFC8028] Baker, F. and B. Carpenter, "First-Hop Router Selection by
Hosts in a Multi-Prefix Network", RFC 8028, Hosts in a Multi-Prefix Network", RFC 8028,
DOI 10.17487/RFC8028, November 2016, DOI 10.17487/RFC8028, November 2016,
<https://www.rfc-editor.org/info/rfc8028>. <https://www.rfc-editor.org/info/rfc8028>.
[RFC8106] Jeong, J., Park, S., Beloeil, L., and S. Madanapalli, [RFC8106] Jeong, J., Park, S., Beloeil, L., and S. Madanapalli,
"IPv6 Router Advertisement Options for DNS Configuration", "IPv6 Router Advertisement Options for DNS Configuration",
RFC 8106, DOI 10.17487/RFC8106, March 2017, RFC 8106, DOI 10.17487/RFC8106, March 2017,
<https://www.rfc-editor.org/info/rfc8106>. <https://www.rfc-editor.org/info/rfc8106>.
[RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", STD 86, RFC 8200,
DOI 10.17487/RFC8200, July 2017,
<https://www.rfc-editor.org/info/rfc8200>.
7.2. Informative References 7.2. Informative References
[I-D.ietf-rtgwg-dst-src-routing] [I-D.ietf-rtgwg-dst-src-routing]
Lamparter, D. and A. Smirnov, "Destination/Source Lamparter, D. and A. Smirnov, "Destination/Source
Routing", draft-ietf-rtgwg-dst-src-routing-06 (work in Routing", draft-ietf-rtgwg-dst-src-routing-06 (work in
progress), October 2017. progress), October 2017.
[I-D.ietf-rtgwg-enterprise-pa-multihoming] [I-D.ietf-rtgwg-enterprise-pa-multihoming]
Baker, F., Bowers, C., and J. Linkova, "Enterprise Baker, F., Bowers, C., and J. Linkova, "Enterprise
Multihoming using Provider-Assigned Addresses without Multihoming using Provider-Assigned Addresses without
skipping to change at page 17, line 10 skipping to change at page 18, line 5
[RFC5533] Nordmark, E. and M. Bagnulo, "Shim6: Level 3 Multihoming [RFC5533] Nordmark, E. and M. Bagnulo, "Shim6: Level 3 Multihoming
Shim Protocol for IPv6", RFC 5533, DOI 10.17487/RFC5533, Shim Protocol for IPv6", RFC 5533, DOI 10.17487/RFC5533,
June 2009, <https://www.rfc-editor.org/info/rfc5533>. June 2009, <https://www.rfc-editor.org/info/rfc5533>.
[RFC5534] Arkko, J. and I. van Beijnum, "Failure Detection and [RFC5534] Arkko, J. and I. van Beijnum, "Failure Detection and
Locator Pair Exploration Protocol for IPv6 Multihoming", Locator Pair Exploration Protocol for IPv6 Multihoming",
RFC 5534, DOI 10.17487/RFC5534, June 2009, RFC 5534, DOI 10.17487/RFC5534, June 2009,
<https://www.rfc-editor.org/info/rfc5534>. <https://www.rfc-editor.org/info/rfc5534>.
[RFC6724] Thaler, D., Ed., Draves, R., Matsumoto, A., and T. Chown,
"Default Address Selection for Internet Protocol Version 6
(IPv6)", RFC 6724, DOI 10.17487/RFC6724, September 2012,
<https://www.rfc-editor.org/info/rfc6724>.
[RFC7084] Singh, H., Beebee, W., Donley, C., and B. Stark, "Basic [RFC7084] Singh, H., Beebee, W., Donley, C., and B. Stark, "Basic
Requirements for IPv6 Customer Edge Routers", RFC 7084, Requirements for IPv6 Customer Edge Routers", RFC 7084,
DOI 10.17487/RFC7084, November 2013, DOI 10.17487/RFC7084, November 2013,
<https://www.rfc-editor.org/info/rfc7084>. <https://www.rfc-editor.org/info/rfc7084>.
[RFC7788] Stenberg, M., Barth, S., and P. Pfister, "Home Networking [RFC7788] Stenberg, M., Barth, S., and P. Pfister, "Home Networking
Control Protocol", RFC 7788, DOI 10.17487/RFC7788, April Control Protocol", RFC 7788, DOI 10.17487/RFC7788, April
2016, <https://www.rfc-editor.org/info/rfc7788>. 2016, <https://www.rfc-editor.org/info/rfc7788>.
Appendix A. Change Log Appendix A. Change Log
 End of changes. 16 change blocks. 
49 lines changed or deleted 98 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/