draft-ietf-6man-ipv6only-flag-02.txt   draft-ietf-6man-ipv6only-flag-03.txt 
Network Working Group R. Hinden Network Working Group R. Hinden
Internet-Draft Check Point Software Internet-Draft Check Point Software
Updates: 5175 (if approved) B. Carpenter Updates: 5175 (if approved) B. Carpenter
Intended status: Standards Track Univ. of Auckland Intended status: Standards Track Univ. of Auckland
Expires: February 15, 2019 August 14, 2018 Expires: April 19, 2019 October 16, 2018
IPv6 Router Advertisement IPv6-Only Flag IPv6 Router Advertisement IPv6-Only Flag
draft-ietf-6man-ipv6only-flag-02 draft-ietf-6man-ipv6only-flag-03
Abstract Abstract
This document specifies a Router Advertisement Flag to indicate to This document specifies a Router Advertisement Flag to indicate to
hosts that the administrator has configured the router to advertise hosts that the administrator has configured the router to advertise
that the link is IPv6-Only. This document updates RFC5175. that the link is IPv6-Only. This document updates RFC5175.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
skipping to change at page 1, line 33 skipping to change at page 1, line 33
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 February 15, 2019. This Internet-Draft will expire on April 19, 2019.
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
(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
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 . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 4
3. Applicability Statements . . . . . . . . . . . . . . . . . . 4 3. Applicability Statements . . . . . . . . . . . . . . . . . . 4
4. IPv6-Only Definition . . . . . . . . . . . . . . . . . . . . 4 4. IPv6-Only Definition . . . . . . . . . . . . . . . . . . . . 4
5. IPv6-Only Flag . . . . . . . . . . . . . . . . . . . . . . . 4 5. IPv6-Only Flag . . . . . . . . . . . . . . . . . . . . . . . 5
6. Router and Operational Considerations . . . . . . . . . . . . 5 6. Router and Operational Considerations . . . . . . . . . . . . 6
7. Host Behavior Considerations . . . . . . . . . . . . . . . . 6 7. Host Behavior Considerations . . . . . . . . . . . . . . . . 6
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
9. Security Considerations . . . . . . . . . . . . . . . . . . . 7 9. Security Considerations . . . . . . . . . . . . . . . . . . . 7
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8
11. Change log [RFC Editor: Please remove] . . . . . . . . . . . 8 11. Change log [RFC Editor: Please remove] . . . . . . . . . . . 8
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
12.1. Normative References . . . . . . . . . . . . . . . . . . 10 12.1. Normative References . . . . . . . . . . . . . . . . . . 10
12.2. Informative References . . . . . . . . . . . . . . . . . 10 12.2. Informative References . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12
1. Introduction 1. Introduction
This document specifies a Router Advertisement Flag to indicate to This document specifies a Router Advertisement Flag to indicate to
hosts that the administrator has configured the router to advertise hosts that the administrator has configured the router to advertise
that the link is IPv6-Only. The flag does not apply to non-default that the link is IPv6-Only. The flag does not apply to non-default
IPv6 routers. IPv6 routers.
Hosts that support IPv4 and IPv6, usually called dual stack hosts, Hosts that support IPv4 and IPv6, usually called dual stack hosts,
need to also work efficiently on IPv6 only links. That is, a link need to also work efficiently on IPv6 only links. That is, a link
where there are no IPv4 routers and/or IPv4 services. Dual stack is where there are no IPv4 routers and/or IPv4 services. Dual stack is
the default configuration for most current host operating systems the default configuration for most current host operating systems
such as Windows 10, IOS, Android, Linux, and BSD, as well as devices such as Windows 10, IOS, Android, Linux, and BSD, as well as devices
such as printers. Monitoring of IPv6-only link, for example at the such as printers. Monitoring of an IPv6-only link, for example at
IETF 100 meeting in Singapore, shows that current dual stack hosts the IETF 100 meeting in Singapore, shows that current dual stack
will create local auto-configured IPv4 addresses and attempt to reach hosts will create local auto-configured IPv4 addresses and attempt to
IPv4 services. This may be a problem for several reasons: reach IPv4 services, even though they cannot configure a normal
address using DHCP. This may be a problem for several reasons,
depending on the equipment in use and its configuration, especially
on large wireless networks:
o It may result in an undesirable level of Layer 2 broadcast o It may result in an undesirable level of wasted Layer 2 broadcast
traffic, especially on large wireless networks. traffic.
o In particular, this may overload switches in multi-segment o In particular, this may overload switches in multi-segment
wireless networks because it will create IPv4 state for every dual wireless networks if the switches create IPv4 state for every dual
stack host. stack host.
o Such traffic may drain battery power on wireless hosts that have o Such traffic may drain battery power on wireless hosts that have
no interest in link-local IPv4 traffic. [RFC7772] indicates how no interest in link-local IPv4, ARP, and DHCPv4 relay traffic, but
this risk might be quantified. receive unwanted IPv4 packets. [RFC7772] indicates how this risk
might be quantified.
o Similarly, hosts may waste battery power on futile attempts to o Similarly, hosts may waste battery power on futile attempts to
access IPv4 services. access services by sending IPv4 packets.
o On an IPv6-only link, IPv4 might be used for malicious purposes o On an IPv6-only link, IPv4 might be used for malicious purposes
and pass unnoticed by IPv6-only monitoring mechanisms. and pass unnoticed by IPv6-only monitoring mechanisms.
This document defines a mechanism that a router administrator can use
to inform hosts that this is an IPv6-Only link on their default
routers such that they can disable IPv4 on this link, mitigating all
of the above problems.
In managed networks whose equipment allows it, these problems could In managed networks whose equipment allows it, these problems could
be mitigated by configuring the Layer 2 infrastructure to drop IPv4 be mitigated by configuring the Layer 2 infrastructure to drop IPv4
and ARP traffic by filtering Ethertypes 0x0800 and 0x806 and ARP traffic by filtering Ethertypes 0x0800 and 0x806
[IANA-Ethertype]. IPv6 uses a different Ethertype 0x86DD so this [IANA-Ethertype]. IPv6 uses a different Ethertype, 0x86DD, so this
filtering will not interfere with IPv6 traffic. Depending on the filtering will not interfere with IPv6 traffic. Depending on the
equipment details, this would limit the traffic to the link to the equipment details, this would limit the traffic to the link from an
switch, and would drop all IPv4 and ARP broadcast packets. However, IPv4 sender to the switch, and would drop all IPv4 and ARP broadcast
hosts transmitting IPv4 packets would still do so, consuming their packets at the switch. This document recommends using such
own battery power and some radio bandwidth. The intent of this mechanisms when available.
specification is to provide a mechanism that works on networks
without the ability to filter L2 traffic, or where there are portions However, hosts transmitting IPv4 packets would still do so, consuming
of a network without the ability to filter L2 traffic. It may also their own battery power and some radio bandwidth. The intent of this
be valuable on unmanaged networks using routers pre-configured for specification is to provide a mechanism that prevents such traffic,
IPv6-only operations and where Layer 2 filtering is unavailable. and also works on networks without the ability to filter L2 traffic,
or where there are portions of a network without the ability to
filter L2 traffic. It may also be valuable on unmanaged networks
using routers pre-configured for IPv6-only operations and where Layer
2 filtering is unavailable.
An assumption of this document is that no IPv4 DHCP server or relay
is active on the link, because it is an IPv6-only link. If this
assumption is false, the DHCP option to disable IPv4 stateless auto-
configuration [RFC2563] could be used.
The remainder of this document therefore assumes that neither
effective Layer 2 filtering nor the RFC 2563 DHCP option is
applicable to the link concerned.
Because there is no IPv4 support on IPv6-only routers, the only way Because there is no IPv4 support on IPv6-only routers, the only way
to notify the dual stack hosts that this link is IPv6-Only is to use to notify the dual stack hosts that this link is IPv6-Only is to use
an IPv6 mechanism. An active notification will be much more precise an IPv6 mechanism. An active notification will be much more precise
than attempting to deduce this fact by the lack of IPv4 responses or than attempting to deduce this fact by the lack of IPv4 responses or
traffic. traffic.
This document therefore defines a mechanism that a router
administrator can use to inform hosts that this is an IPv6-Only link
on their default routers such that they can disable IPv4 on this
link, mitigating all of the above problems.
IPv4-only hosts, and dual-stack hosts that do not recognize the new IPv4-only hosts, and dual-stack hosts that do not recognize the new
flag, will continue to attempt IPv4 operations, in particular IPv4 flag, may continue to attempt IPv4 operations, in particular IPv4
discovery protocols typically sent as link-layer broadcasts. This discovery protocols typically sent as link-layer broadcasts. This
legacy traffic cannot be prevented by any IPv6 mechanism. The value legacy traffic cannot be prevented by any IPv6 mechanism. The value
of the new flag is limited to hosts that recognize it. of the new flag is limited to hosts that recognize it.
A possible subsidiary use of the IPv6-Only flag is using it to
trigger IPv6-Only testing and validation on a link.
This document specifies a new flag for Router Advertisement Flag This document specifies a new flag for Router Advertisement Flag
[RFC5175]. It updates [RFC5175] to add this flag. [RFC5175]. It updates [RFC5175] to add this flag.
2. Requirements Language 2. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
3. Applicability Statements 3. Applicability Statements
The mechanism is designed to allow administrators to notify hosts This OPTIONAL mechanism is designed to allow administrators to notify
that the link is IPv6-Only. It SHOULD be only used in IPv6-Only hosts that the link is IPv6-Only. It SHOULD be only used in
links. IPv6-Only links (see below for definition).
Dual stack hosts that have a good reason to use IPv4, for example for Dual stack hosts that have a good reason to use IPv4, for example for
a specific IPv4 link-local service, can continue to do so. This is a specific IPv4 link-local service, can attempt to do so. Therefore
consistent with the SHOULD language in this document. respect of the IPv6-Only flag is recommended, not mandatory, for
hosts.
Administrators SHOULD only use this mechanism if they are certain Administrators SHOULD only use this mechanism if they are certain
that the link is IPv6-Only. For example, in cases where there is a that the link is IPv6-Only. For example, in cases where there is a
need to continue to use IPv4 or there are IPv4 only routers, setting need to continue to use IPv4, when there are intended to be IPv4-only
this flag to 1 is a configuration error. hosts or IPv4 routers on the link, setting this flag to 1 is a
configuration error.
This mechanism is intended to be compatible with link-layer solutions
that filter out IPv4 traffic.
4. IPv6-Only Definition 4. IPv6-Only Definition
IPv6-Only is defined to mean that no other versions of internet IPv6-Only is defined to mean that no other versions of internet
protocol than IPv6 are running directly on the link. Today this protocol than IPv6 are intentionally running directly on the link.
effectively simply means that IPv4 is not running on the link, and it Today this effectively simply means that IPv4 is not running on the
includes: link, and it includes:
* No IPv4 traffic on the Link * No IPv4 traffic on the Link
* No IPv4 routers on the Link * No IPv4 routers on the Link
* No DHCPv4 servers on the Link * No DHCPv4 servers on the Link
* No IPv4 accessible services on the Link * No IPv4 accessible services on the Link
* All IPv4 and ARP traffic may be blocked at Layer 2 by the * All IPv4 and ARP traffic may be blocked at Layer 2 by the
administrator administrator
It is expected that on IPv6-Only networks it will be common for It is expected that on IPv6-Only networks it will be common for
access to IPv4 external services to be reached by techniques such as access to IPv4 external services to be reached by techniques such as
skipping to change at page 5, line 37 skipping to change at page 6, line 19
router that does not support the new flag will not appear to assert router that does not support the new flag will not appear to assert
that this is an IPv6-Only link. that this is an IPv6-Only link.
Hosts receiving the Router Advertisement SHOULD only process this Hosts receiving the Router Advertisement SHOULD only process this
flag if the advertising router is a Default Router. Specifically, if flag if the advertising router is a Default Router. Specifically, if
the Lifetime field in the Router Advertisement is not zero, otherwise the Lifetime field in the Router Advertisement is not zero, otherwise
it SHOUD be ignored. This is done to allow some IPv6 routers to it SHOUD be ignored. This is done to allow some IPv6 routers to
advertise information without being a Default Router and providing advertise information without being a Default Router and providing
IPv6 connectivity. IPv6 connectivity.
Note that although this mechanism uses one of only two reserved flag
bits in the RA, an extension mechanism is defined in Section 4 of
[RFC5175] in case additional flags are ever required for future
extensions.
6. Router and Operational Considerations 6. Router and Operational Considerations
Default IPv6 routers that are on an IPv6-Only link SHOULD be Default IPv6 routers that are on an IPv6-Only link SHOULD be
configured to set the IPv6-Only flag to 1 on interfaces on this link. configured to set the IPv6-Only flag to 1 on interfaces on this link.
In all other cases the flag SHOULD NOT be set to 1. In all other cases the flag SHOULD NOT be set to 1.
The intent is that the administrator of the router configures the The intent is that the administrator of the router configures the
router to set the IPv6-Only flag if she/he wants to tell the hosts on router to set the IPv6-Only flag if she/he wants to tell the hosts on
the link that the link is IPv6-Only. This is a configuration flag, the link that the link is IPv6-Only. This is a configuration flag,
it is not something that the router decides on it's own. Routers MAY it is not something that the router decides on it's own. Routers MAY
log a configuration error if the flag is set and IPv4 is still active log a configuration error if the flag is set and IPv4 is still active
on the router. on the routers interface to the link.
Operators of large IPv6-only wireless links are advised to also use Operators of large IPv6-only wireless links are advised to also use
Layer 2 techniques to drop IPv4 and ARP packets (Ethertypes 0x0800 Layer 2 techniques to drop IPv4 and ARP packets (Ethertypes 0x0800
and 0x806) at all switches, and to ensure that IPv4 and ARP features and 0x806) at all switches, and to ensure that IPv4 and ARP features
are disabled in all switches. are disabled in all switches.
7. Host Behavior Considerations 7. Host Behavior Considerations
If there are multiple IPv6 default routers on a link, they might send If there are multiple IPv6 default routers on a link, they might send
different values of the flag. If at least one IPv6 default router different values of the flag. If at least one IPv6 default router
skipping to change at page 7, line 18 skipping to change at page 7, line 43
in Section 5 of this document. Bit 6 is the next available bit in in Section 5 of this document. Bit 6 is the next available bit in
this registry, IANA is requested to use this bit unless there is a this registry, IANA is requested to use this bit unless there is a
reason to use another bit in this registry. reason to use another bit in this registry.
IANA is also requested to register this new flag bit in the IANA IPv6 IANA is also requested to register this new flag bit in the IANA IPv6
ND Router Advertisement flags Registry [IANA-RF]. ND Router Advertisement flags Registry [IANA-RF].
9. Security Considerations 9. Security Considerations
This document shares the security issues with other parts of IPv6 This document shares the security issues with other parts of IPv6
Neighbor Discovery. General techniques to protect Router Neighbor Discovery. [RFC6104] discusses certain attacks and
Advertisement traffic such as Router Guard [RFC6105] are useful in mitigations. General techniques to protect Router Advertisement
protecting these vulnerabilities. traffic such as Router Guard [RFC6105] are useful in protecting
against these vulnerabilities.
A bad actor could use this mechanism to attempt turn off IPv4 service A bad actor could use this mechanism to attempt turn off IPv4 service
on a link that is using IPv4, by sending Router Advertisements with on a link that is intentionally using IPv4, by sending Router
the IPv6-Only Flag set to 1. In that case, as long as there are Advertisements with the IPv6-Only Flag set to 1. In that case, as
routers sending Router Advertisements with this Flag set to 0, they long as there are one or more routers sending Router Advertisements
would override this attack given the mechanism in Section 5. with this Flag set to 0, they would override this attack given the
Specifically a host would only turn off IPv4 service if it wasn't mechanism in Section 5. Specifically a host would only turn off IPv4
hearing any Router Advertisement with the Flag set to 0. If the service if it wasn't hearing any Router Advertisement with the Flag
advice in Section 6 is followed, this attack will fail. set to 0. If the advice in Section 6 is followed, this attack will
fail. In a situation where the bad actor has control of all routers
on the link and sends Router Advertisements with the IPv6-Only Flag
set to 1 from all of them, the attack will succeed, but so will many
other forms of router-based attack.
Conversely, a bad actor could use this mechanism to turn on, or Conversely, a bad actor could use this mechanism to turn on, or
pretend to turn on, IPv4 service on an IPv6-only link, by sending pretend to turn on, IPv4 service on an IPv6-only link, by sending
Router Advertisements with the Flag set to 0. However, this is Router Advertisements with the Flag set to 0. However, this is
really no different than what such a bad actor can do anyway, if they really no different than what such a bad actor can do anyway, if they
have the ability to configure a bogus router in the first place. The have the ability to configure a bogus router in the first place. The
advice in Section 6 will minimize such an attack by limiting it to a advice in Section 6 will minimize such an attack by limiting it to a
single link. single link.
Note that manipulating the Router Preference [RFC4191] will not Note that manipulating the Router Preference [RFC4191] will not
skipping to change at page 8, line 12 skipping to change at page 8, line 40
hosts that don't support this flag are not protected from IPv4-based hosts that don't support this flag are not protected from IPv4-based
attacks. attacks.
10. Acknowledgments 10. Acknowledgments
A closely related proposal was published earlier as A closely related proposal was published earlier as
[I-D.ietf-sunset4-noipv4]. [I-D.ietf-sunset4-noipv4].
Helpful comments were received from Lorenzo Colitti, David Farmer, Helpful comments were received from Lorenzo Colitti, David Farmer,
Fernando Gont, Nick Hilliard, Erik Kline, Jen Linkova, Veronika Fernando Gont, Nick Hilliard, Erik Kline, Jen Linkova, Veronika
McKillop, Michael Richardson, Mark Smith, Barbara Stark, Tatuya McKillop, George Michaelson, Michael Richardson, Mark Smith, Barbara
Jinmei, Ole Troan, James Woodyatt, and other members of the 6MAN Stark, Tatuya Jinmei, Ole Troan, James Woodyatt, and other members of
working group. the 6MAN working group.
Bjoern Zeeb has also produced a variant of this proposal and proposed Bjoern Zeeb has also produced a variant of this proposal and proposed
an IPv6 transition plan in [I-D.bz-v4goawayflag]. an IPv6 transition plan in [I-D.bz-v4goawayflag].
11. Change log [RFC Editor: Please remove] 11. Change log [RFC Editor: Please remove]
draft-ietf-6man-ipv6only-flag-03, 2018-October-16:
* Reorganized text about problem statement and applicability
* Added note about shortage of flag bits
* Clarified text about logging configuration error in Section 6
* Editorial changes.
draft-ietf-6man-ipv6only-flag-02, 2018-August-14: draft-ietf-6man-ipv6only-flag-02, 2018-August-14:
* Added text about logging configuration errors to Section 6
* Added text to Section 9 to clarify that hosts not supporting * Added text to Section 9 to clarify that hosts not supporting
this flag are not protected from IPv4-based attacks. this flag are not protected from IPv4-based attacks.
* Editorial changes. * Editorial changes.
draft-ietf-6man-ipv6only-flag-01, 2018-June-29: draft-ietf-6man-ipv6only-flag-01, 2018-June-29:
* Added text to section that defines what IPv6-Only includes to * Added text to section that defines what IPv6-Only includes to
clarify that only other version of the Internet protocol are in clarify that only other version of the Internet protocol are in
scope. scope.
* Added clarification if the lifetime of all routers expire. * Added clarification if the lifetime of all routers expire.
skipping to change at page 11, line 5 skipping to change at page 11, line 35
[I-D.bz-v4goawayflag] [I-D.bz-v4goawayflag]
Zeeb, B., "IPv6 Router Advertisement IPv4 GoAway Flag", Zeeb, B., "IPv6 Router Advertisement IPv4 GoAway Flag",
draft-bz-v4goawayflag-00 (work in progress), March 2018. draft-bz-v4goawayflag-00 (work in progress), March 2018.
[I-D.ietf-sunset4-noipv4] [I-D.ietf-sunset4-noipv4]
Perreault, S., George, W., Tsou, T., Yang, T., and J. Perreault, S., George, W., Tsou, T., Yang, T., and J.
Tremblay, "Turning off IPv4 Using DHCPv6 or Router Tremblay, "Turning off IPv4 Using DHCPv6 or Router
Advertisements", draft-ietf-sunset4-noipv4-01 (work in Advertisements", draft-ietf-sunset4-noipv4-01 (work in
progress), December 2014. progress), December 2014.
[RFC2563] Troll, R., "DHCP Option to Disable Stateless Auto-
Configuration in IPv4 Clients", RFC 2563, DOI 10.17487/
RFC2563, May 1999, <https://www.rfc-editor.org/info/
rfc2563>.
[RFC6104] Chown, T. and S. Venaas, "Rogue IPv6 Router Advertisement
Problem Statement", RFC 6104, DOI 10.17487/RFC6104,
February 2011, <https://www.rfc-editor.org/info/rfc6104>.
[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, DOI Mohacsi, "IPv6 Router Advertisement Guard", RFC 6105, DOI
10.17487/RFC6105, February 2011, <https://www.rfc- 10.17487/RFC6105, February 2011, <https://www.rfc-
editor.org/info/rfc6105>. editor.org/info/rfc6105>.
[RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful
NAT64: Network Address and Protocol Translation from IPv6 NAT64: Network Address and Protocol Translation from IPv6
Clients to IPv4 Servers", RFC 6146, DOI 10.17487/RFC6146, Clients to IPv4 Servers", RFC 6146, DOI 10.17487/RFC6146,
April 2011, <https://www.rfc-editor.org/info/rfc6146>. April 2011, <https://www.rfc-editor.org/info/rfc6146>.
 End of changes. 30 change blocks. 
60 lines changed or deleted 110 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/