draft-ietf-6man-slaac-renum-00.txt   draft-ietf-6man-slaac-renum-01.txt 
IPv6 Maintenance (6man) Working Group F. Gont IPv6 Maintenance (6man) Working Group F. Gont
Internet-Draft SI6 Networks Internet-Draft SI6 Networks
Updates: 4861, 4862 (if approved) J. Zorz Updates: 4861, 4862 (if approved) J. Zorz
Intended status: Standards Track Go6 Institute Intended status: Standards Track 6connect
Expires: January 28, 2021 R. Patterson Expires: February 27, 2021 R. Patterson
Sky UK Sky UK
July 27, 2020 August 26, 2020
Improving the Robustness of Stateless Address Autoconfiguration (SLAAC) Improving the Robustness of Stateless Address Autoconfiguration (SLAAC)
to Flash Renumbering Events to Flash Renumbering Events
draft-ietf-6man-slaac-renum-00 draft-ietf-6man-slaac-renum-01
Abstract Abstract
In renumbering scenarios where an IPv6 prefix suddenly becomes In renumbering scenarios where an IPv6 prefix suddenly becomes
invalid, hosts on the local network will continue using stale invalid, hosts on the local network will continue using stale
prefixes for an unacceptably long period of time, thus resulting in prefixes for an unacceptably long period of time, thus resulting in
connectivity problems. This document improves the reaction of IPv6 connectivity problems. This document improves the reaction of IPv6
Stateless Address Autoconfiguration to such renumbering scenarios. Stateless Address Autoconfiguration to such renumbering scenarios.
Status of This Memo Status of This Memo
skipping to change at page 1, line 38 skipping to change at page 1, line 38
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 28, 2021. This Internet-Draft will expire on February 27, 2021.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2020 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 21 skipping to change at page 2, line 21
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. SLAAC reaction to Flash-renumbering Events . . . . . . . . . 4 3. SLAAC reaction to Flash-renumbering Events . . . . . . . . . 4
3.1. Renumbering without Explicit Signaling . . . . . . . . . 4 3.1. Renumbering without Explicit Signaling . . . . . . . . . 4
3.2. Renumbering with Explicit Signaling . . . . . . . . . . . 5 3.2. Renumbering with Explicit Signaling . . . . . . . . . . . 5
4. Improvements to Stateless Address Autoconfiguration (SLAAC) . 6 4. Improvements to Stateless Address Autoconfiguration (SLAAC) . 6
4.1. More Appropriate Lifetime Values . . . . . . . . . . . . 7 4.1. More Appropriate Lifetime Values . . . . . . . . . . . . 7
4.1.1. Router Configuration Variables . . . . . . . . . . . 7 4.1.1. Router Configuration Variables . . . . . . . . . . . 7
4.1.2. Processing of PIO Lifetimes at Hosts . . . . . . . . 7 4.1.2. Processing of PIO Lifetimes at Hosts . . . . . . . . 7
4.2. Honor Small PIO Valid Lifetimes . . . . . . . . . . . . . 7 4.2. Honor Small PIO Valid Lifetimes . . . . . . . . . . . . . 7
4.3. Interface Initialization . . . . . . . . . . . . . . . . 7 4.3. Interface Initialization . . . . . . . . . . . . . . . . 8
4.4. Conveying Information in Router Advertisement (RA) 4.4. Conveying Information in Router Advertisement (RA)
Messages . . . . . . . . . . . . . . . . . . . . . . . . 7 Messages . . . . . . . . . . . . . . . . . . . . . . . . 8
4.5. Recovery from Stale Configuration Information without 4.5. Recovery from Stale Configuration Information without
Explicit Signaling . . . . . . . . . . . . . . . . . . . 7 Explicit Signaling . . . . . . . . . . . . . . . . . . . 8
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
6. Implementation Status . . . . . . . . . . . . . . . . . . . . 7 6. Implementation Status . . . . . . . . . . . . . . . . . . . . 9
6.1. More Appropriate Lifetime Values . . . . . . . . . . . . 8 6.1. More Appropriate Lifetime Values . . . . . . . . . . . . 9
6.1.1. Router Configuration Variables . . . . . . . . . . . 8 6.1.1. Router Configuration Variables . . . . . . . . . . . 9
6.1.2. Processing of PIO Lifetimes at Hosts . . . . . . . . 8 6.1.2. Processing of PIO Lifetimes at Hosts . . . . . . . . 9
6.2. Honor Small PIO Valid Lifetimes . . . . . . . . . . . . . 9 6.2. Honor Small PIO Valid Lifetimes . . . . . . . . . . . . . 10
6.2.1. NetworkManager . . . . . . . . . . . . . . . . . . . 9 6.2.1. Linux Kernel . . . . . . . . . . . . . . . . . . . . 10
6.2.2. NetworkManager . . . . . . . . . . . . . . . . . . . 10
6.3. Conveying Information in Router Advertisement (RA) 6.3. Conveying Information in Router Advertisement (RA)
Messages . . . . . . . . . . . . . . . . . . . . . . . . 9 Messages . . . . . . . . . . . . . . . . . . . . . . . . 10
6.4. Recovery from Stale Configuration Information without 6.4. Recovery from Stale Configuration Information without
Explicit Signaling . . . . . . . . . . . . . . . . . . . 9 Explicit Signaling . . . . . . . . . . . . . . . . . . . 10
6.4.1. dhcpcd(8) . . . . . . . . . . . . . . . . . . . . . . 9 6.4.1. dhcpcd(8) . . . . . . . . . . . . . . . . . . . . . . 10
6.5. Other mitigations implemented in products . . . . . . . . 9 6.5. Other mitigations implemented in products . . . . . . . . 11
7. Security Considerations . . . . . . . . . . . . . . . . . . . 10 7. Security Considerations . . . . . . . . . . . . . . . . . . . 11
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
9.1. Normative References . . . . . . . . . . . . . . . . . . 11 9.1. Normative References . . . . . . . . . . . . . . . . . . 12
9.2. Informative References . . . . . . . . . . . . . . . . . 12 9.2. Informative References . . . . . . . . . . . . . . . . . 13
Appendix A. Analysis of Some Suggested Workarounds . . . . . . . 13 Appendix A. Analysis of Some Suggested Workarounds . . . . . . . 15
A.1. On a Possible Reaction to ICMPv6 Error Messages . . . . . 14 A.1. On a Possible Reaction to ICMPv6 Error Messages . . . . . 15
A.2. On a Possible Improvement to Source Address Selection . . 14 A.2. On a Possible Improvement to Source Address Selection . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18
1. Introduction 1. Introduction
IPv6 network renumbering is expected to take place in a planned IPv6 network renumbering is expected to take place in a planned
manner, with old/stale prefixes being phased-out via reduced prefix manner, with old/stale prefixes being phased-out via reduced prefix
lifetimes while new prefixes (with normal lifetimes) are introduced. lifetimes while new prefixes (with normal lifetimes) are introduced.
However, there are a number of scenarios that may lead to the so- However, there are a number of scenarios that may lead to the so-
called "flash-renumbering" events, where the prefix being employed on called "flash-renumbering" events, where the prefix being employed on
a network suddenly becomes invalid and replaced by a new prefix a network suddenly becomes invalid and replaced by a new prefix
[I-D.ietf-v6ops-slaac-renum]. In such scenarios, hosts on the local [I-D.ietf-v6ops-slaac-renum]. In such scenarios, hosts on the local
skipping to change at page 7, line 26 skipping to change at page 7, line 26
4.1.1. Router Configuration Variables 4.1.1. Router Configuration Variables
[TBD] [TBD]
4.1.2. Processing of PIO Lifetimes at Hosts 4.1.2. Processing of PIO Lifetimes at Hosts
[TBD] [TBD]
4.2. Honor Small PIO Valid Lifetimes 4.2. Honor Small PIO Valid Lifetimes
[TBD] The entire item "e)" (pp. 19-20) from Section 5.5.3 of [RFC4862] is
replaced with the following text:
e) If the advertised prefix is equal to the prefix of an address
configured by stateless autoconfiguration in the list, the valid
lifetime and the preferred lifetime of the address should be
updated by processing the Valid Lifetime and the Preferred
Lifetime (respectively) in the received advertisement.
NOTE:
"Processing" the Valid Lifetime and Preferred Lifetime includes
capping the received values as specified in Section 4.1.2 of this
document.
RATIONALE:
* This change allows hosts to react to the information provided
by a router that has positive knowledge that a prefix has
become invalid.
* The behavior described in RFC4862 had been incorporated during
the revision of the original IPv6 Stateless Address
Autoconfiguration specification ([RFC1971]). At the time, the
IPNG working group decided to mitigate the attack vector
represented by Prefix Information Options with very short
lifetimes, on the premise these packets represented a bigger
risk than other ND-based attack vectors [IPNG-minutes].
While reconsidering the trade-offs represented by such
decision, we conclude that the drawbacks of mitigating the
aforementioned attack vector outweigh the possible benefits.
In scenarios where RA-based attacks are of concern, proper
mitigations such as RA-Guard [RFC6105] [RFC7113] or SEND
[RFC3971] should be implemented.
4.3. Interface Initialization 4.3. Interface Initialization
[TBD] When an interface is initialized, it is paramount that network
configuration information is spread on the corresponding network
(particularly in scenarios where an interface has been re-
initialized, and the conveyed information has changed). Thus, this
document replaces the following text from Section 6.2.4 of [RFC4861]:
In such cases, the router MAY transmit up to
MAX_INITIAL_RTR_ADVERTISEMENTS unsolicited advertisements, using
the same rules as when an interface becomes an advertising
interface.
with:
In such cases, the router SHOULD transmit
MAX_INITIAL_RTR_ADVERTISEMENTS unsolicited advertisements, using
the same rules as when an interface becomes an advertising
interface.
RATIONALE:
* Use of stale information can lead to interoperability problems.
Therefore, it is important that new configuration information
propagates in a timelier manner to all hosts.
NOTE:
[I-D.ietf-v6ops-cpe-slaac-renum] specifies recommendations for CPE
routers to deprecate any stale network configuration information.
4.4. Conveying Information in Router Advertisement (RA) Messages 4.4. Conveying Information in Router Advertisement (RA) Messages
[TBD] [TBD]
4.5. Recovery from Stale Configuration Information without Explicit 4.5. Recovery from Stale Configuration Information without Explicit
Signaling Signaling
[TBD] [TBD]
skipping to change at page 9, line 13 skipping to change at page 10, line 25
this document. this document.
6.1.2.3. systemd-networkd 6.1.2.3. systemd-networkd
systemd-networkd [systemd], a user-space SLAAC implementation systemd-networkd [systemd], a user-space SLAAC implementation
employed by some Linux-based operating systems, caps the lifetimes of employed by some Linux-based operating systems, caps the lifetimes of
the received PIOs as recommended in this document. the received PIOs as recommended in this document.
6.2. Honor Small PIO Valid Lifetimes 6.2. Honor Small PIO Valid Lifetimes
6.2.1. NetworkManager 6.2.1. Linux Kernel
A Linux kernel implementation of this document has been committed to
the net-next tree. The implementation was produced in April 2020 by
Fernando Gont <fgont@si6networks.com>. The corresponding patch can
be found at: <https://patchwork.ozlabs.org/project/netdev/
patch/20200419122457.GA971@archlinux-current.localdomain/>
6.2.2. NetworkManager
NetworkManager [NetworkManager] processes RA messages with a Valid NetworkManager [NetworkManager] processes RA messages with a Valid
Lifetime smaller than two hours as recommended in this document. Lifetime smaller than two hours as recommended in this document.
6.3. Conveying Information in Router Advertisement (RA) Messages 6.3. Conveying Information in Router Advertisement (RA) Messages
We know of no implementation that splits network configuration We know of no implementation that splits network configuration
information into multiple RA messages. information into multiple RA messages.
6.4. Recovery from Stale Configuration Information without Explicit 6.4. Recovery from Stale Configuration Information without Explicit
skipping to change at page 10, line 15 skipping to change at page 11, line 35
deprecating it. deprecating it.
o Possibly as a result of item "e)" (pp. 19-20) from Section 5.5.3 o Possibly as a result of item "e)" (pp. 19-20) from Section 5.5.3
of [RFC4862] (discussed in Section 4.2 of this document), upon of [RFC4862] (discussed in Section 4.2 of this document), upon
first occurrence of a stale prefix, this implementation will first occurrence of a stale prefix, this implementation will
employ a decreasing Valid Lifetime, starting from 2 hours (7200 employ a decreasing Valid Lifetime, starting from 2 hours (7200
seconds), as opposed to a Valid Lifetime of 0. seconds), as opposed to a Valid Lifetime of 0.
7. Security Considerations 7. Security Considerations
When it comes to the algorithm in Section 4.5, an attacker could The protocol update in Section 4.2 could allow an on-link attacker to
impersonate the legitimate router and send an RA that does not perform a Denial of Service attack againts local hosts, by sending a
advertise legitimate prefixes being employed in the local network. forged RA with a PIO with a Valid Lifetime of 0. Upon receipt of
This cause the corresponding addresses to become deprecated. that packet, local hosts would invalidate the corresponding prefix,
However, the addresses would not become invalid since normal and therefore remove any addresses configured for that prefix,
unsolicited RA messages would refresh the "Preferred Lifetime" and possibly terminating e.g. TCP connections employing such addresses.
"Valid Lifetime" of such addresses. However, an attacker may achieve similar effects via a number for ND-
based attack vectors, such as directing traffic to a non-existing
However, an attacker that can impersonate a router could more easily node until ongoing TCP connections time out, or performing a ND-based
deprecate addresses by advertising the legitimate prefixes with the man-in-the-middle (MITM) attack and subsequently forging TCP RST
"Preferred Lifetime" set to 0, or perform a plethora of other segments to cause on-going TCP connections to be aborted. Thus, for
possible of Denial of Service attacks based on forged RA messages. all practical purposes, this attack vector does not really represent
Therefore, when attacks based on forged RA packets are a concern, a greater risk than other ND attack vectors. As noted in Section 4.2
technologies such as RA-Guard [RFC6105] [RFC7113] should be deployed. , in scenarios where RA-based attacks are of concern, proper
mitigations such as RA-Guard [RFC6105] [RFC7113] or SEND [RFC3971]
Capping the "Valid Lifetime" and "Preferred Lifetime" at hosts may should be implemented.
help limit the duration of the effects of non-sustained attacks that
employ forged RAs with PIOs, since hosts would now recover in a
timelier manner.
8. Acknowledgments 8. Acknowledgments
The authors would like to thank (in alphabetical order) Mikael The authors would like to thank (in alphabetical order) Mikael
Abrahamsson, Tore Anderson, Luis Balbinot, Brian Carpenter, Owen Abrahamsson, Tore Anderson, Luis Balbinot, Brian Carpenter, Lorenzo
DeLong, Gert Doering, Thomas Haller, Nick Hilliard, Bob Hinden, Colitti, Owen DeLong, Gert Doering, Thomas Haller, Nick Hilliard, Bob
Philip Homburg, Lee Howard, Christian Huitema, Erik Kline, Jen Hinden, Philip Homburg, Lee Howard, Christian Huitema, Tatuya Jinmei,
Linkova, Albert Manfredi, Roy Marples, Florian Obser, Jordi Palet Erik Kline, Ted Lemon, Jen Linkova, Albert Manfredi, Roy Marples,
Martinez, Michael Richardson, Hiroki Sato, Mark Smith, Hannes Florian Obser, Jordi Palet Martinez, Michael Richardson, Hiroki Sato,
Frederic Sowa, Tarko Tikan, Ole Troan, and Loganaden Velvindron, for Mark Smith, Hannes Frederic Sowa, Dave Thaler, Tarko Tikan, Ole
providing valuable comments on earlier versions of this document. Troan, Eduard Vasilenko, and Loganaden Velvindron, for providing
valuable comments on earlier versions of this document.
The algorithm specified in Section 4.5 is the result of mailing-list The algorithm specified in Section 4.5 is the result of mailing-list
discussions over previous versions of this document with Philip discussions over previous versions of this document with Philip
Homburg. Homburg.
Fernando would like to thank Alejandro D'Egidio and Sander Steffann Fernando would like to thank Alejandro D'Egidio and Sander Steffann
for a discussion of these issues, which led to the publication of for a discussion of these issues, which led to the publication of
[I-D.ietf-v6ops-slaac-renum], and eventually to this document. [I-D.ietf-v6ops-slaac-renum], and eventually to this document.
Fernando would also like to thank Brian Carpenter who, over the Fernando would also like to thank Brian Carpenter who, over the
skipping to change at page 12, line 16 skipping to change at page 13, line 35
Requirements", BCP 220, RFC 8504, DOI 10.17487/RFC8504, Requirements", BCP 220, RFC 8504, DOI 10.17487/RFC8504,
January 2019, <https://www.rfc-editor.org/info/rfc8504>. January 2019, <https://www.rfc-editor.org/info/rfc8504>.
9.2. Informative References 9.2. Informative References
[dhcpcd] Marples, R., "dhcpcd - a DHCP client", [dhcpcd] Marples, R., "dhcpcd - a DHCP client",
<https://roy.marples.name/projects/dhcpcd/>. <https://roy.marples.name/projects/dhcpcd/>.
[FRITZ] Gont, F., "Quiz: Weird IPv6 Traffic on the Local Network [FRITZ] Gont, F., "Quiz: Weird IPv6 Traffic on the Local Network
(updated with solution)", SI6 Networks Blog, February (updated with solution)", SI6 Networks Blog, February
2016, <http://blog.si6networks.com/2016/02/quiz-weird- 2016, <https://www.si6networks.com/2016/02/16/quiz-weird-
ipv6-traffic-on-local-network.html>. ipv6-traffic-on-the-local-network-updated-with-solution/>.
[I-D.ietf-v6ops-cpe-slaac-renum] [I-D.ietf-v6ops-cpe-slaac-renum]
Gont, F., Zorz, J., Patterson, R., and B. Volz, "Improving Gont, F., Zorz, J., Patterson, R., and B. Volz, "Improving
the Reaction of Customer Edge Routers to Renumbering the Reaction of Customer Edge Routers to Renumbering
Events", draft-ietf-v6ops-cpe-slaac-renum-03 (work in Events", draft-ietf-v6ops-cpe-slaac-renum-04 (work in
progress), May 2020. progress), August 2020.
[I-D.ietf-v6ops-slaac-renum] [I-D.ietf-v6ops-slaac-renum]
Gont, F., Zorz, J., and R. Patterson, "Reaction of Gont, F., Zorz, J., and R. Patterson, "Reaction of
Stateless Address Autoconfiguration (SLAAC) to Flash- Stateless Address Autoconfiguration (SLAAC) to Flash-
Renumbering Events", draft-ietf-v6ops-slaac-renum-02 (work Renumbering Events", draft-ietf-v6ops-slaac-renum-03 (work
in progress), May 2020. in progress), August 2020.
[I-D.linkova-6man-default-addr-selection-update] [I-D.linkova-6man-default-addr-selection-update]
Linkova, J., "Default Address Selection and Subnet Linkova, J., "Default Address Selection and Subnet
Renumbering", draft-linkova-6man-default-addr-selection- Renumbering", draft-linkova-6man-default-addr-selection-
update-00 (work in progress), March 2017. update-00 (work in progress), March 2017.
[IPNG-minutes]
IETF, "IPNG working group (ipngwg) Meeting Minutes",
Proceedings of the thirty-eightt Internet Engineering Task
Force , April 1997, <https://www.ietf.org/
proceedings/38/97apr-final/xrtftr47.htm>.
[NetworkManager] [NetworkManager]
NetworkManager, "NetworkManager web site", NetworkManager, "NetworkManager web site",
<https://wiki.gnome.org/Projects/NetworkManager>. <https://wiki.gnome.org/Projects/NetworkManager>.
[rad] Obser, F., "OpenBSD Router Advertisement Daemon - rad(8)", [rad] Obser, F., "OpenBSD Router Advertisement Daemon - rad(8)",
<https://cvsweb.openbsd.org/src/usr.sbin/rad/>. <https://cvsweb.openbsd.org/src/usr.sbin/rad/>.
[radvd] Hawkins, R. and R. Johnson, "Linux IPv6 Router [radvd] Hawkins, R. and R. Johnson, "Linux IPv6 Router
Advertisement Daemon (radvd)", Advertisement Daemon (radvd)",
<http://www.litech.org/radvd/>. <http://www.litech.org/radvd/>.
[radvd.conf] [radvd.conf]
Hawkins, R. and R. Johnson, "radvd.conf - configuration Hawkins, R. and R. Johnson, "radvd.conf - configuration
file of the router advertisement daemon", file of the router advertisement daemon",
<https://github.com/reubenhwk/radvd/blob/master/ <https://github.com/reubenhwk/radvd/blob/master/
radvd.conf.5.man>. radvd.conf.5.man>.
[RFC1971] Thomson, S. and T. Narten, "IPv6 Stateless Address
Autoconfiguration", RFC 1971, DOI 10.17487/RFC1971, August
1996, <https://www.rfc-editor.org/info/rfc1971>.
[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>.
[RFC3971] Arkko, J., Ed., Kempf, J., Zill, B., and P. Nikander,
"SEcure Neighbor Discovery (SEND)", RFC 3971,
DOI 10.17487/RFC3971, March 2005,
<https://www.rfc-editor.org/info/rfc3971>.
[RFC5927] Gont, F., "ICMP Attacks against TCP", RFC 5927, [RFC5927] Gont, F., "ICMP Attacks against TCP", RFC 5927,
DOI 10.17487/RFC5927, July 2010, DOI 10.17487/RFC5927, July 2010,
<https://www.rfc-editor.org/info/rfc5927>. <https://www.rfc-editor.org/info/rfc5927>.
[RFC6105] Levy-Abegnoli, E., Van de Velde, G., Popoviciu, C., and J. [RFC6105] Levy-Abegnoli, E., Van de Velde, G., Popoviciu, C., and J.
Mohacsi, "IPv6 Router Advertisement Guard", RFC 6105, Mohacsi, "IPv6 Router Advertisement Guard", RFC 6105,
DOI 10.17487/RFC6105, February 2011, DOI 10.17487/RFC6105, February 2011,
<https://www.rfc-editor.org/info/rfc6105>. <https://www.rfc-editor.org/info/rfc6105>.
[RFC6724] Thaler, D., Ed., Draves, R., Matsumoto, A., and T. Chown, [RFC6724] Thaler, D., Ed., Draves, R., Matsumoto, A., and T. Chown,
skipping to change at page 16, line 24 skipping to change at page 18, line 17
Fernando Gont Fernando Gont
SI6 Networks SI6 Networks
Segurola y Habana 4310, 7mo Piso Segurola y Habana 4310, 7mo Piso
Villa Devoto, Ciudad Autonoma de Buenos Aires Villa Devoto, Ciudad Autonoma de Buenos Aires
Argentina Argentina
Email: fgont@si6networks.com Email: fgont@si6networks.com
URI: https://www.si6networks.com URI: https://www.si6networks.com
Jan Zorz Jan Zorz
Go6 Institute 6connect
Frankovo naselje 165
Skofja Loka 4220
Slovenia
Email: jan@go6.si Email: jan@connect.com
URI: https://www.go6.si
Richard Patterson Richard Patterson
Sky UK Sky UK
Email: richard.patterson@sky.uk Email: richard.patterson@sky.uk
 End of changes. 22 change blocks. 
69 lines changed or deleted 147 lines changed or added

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