draft-ietf-v6ops-rogue-ra-02.txt   rfc6104.txt 
IPv6 Operations T. Chown Internet Engineering Task Force (IETF) T. Chown
Internet-Draft University of Southampton Request for Comments: 6104 University of Southampton
Intended status: Informational S. Venaas Category: Informational S. Venaas
Expires: April 28, 2011 Cisco Systems ISSN: 2070-1721 Cisco Systems
October 25, 2010 February 2011
Rogue IPv6 Router Advertisement Problem Statement Rogue IPv6 Router Advertisement Problem Statement
draft-ietf-v6ops-rogue-ra-02
Abstract Abstract
When deploying IPv6, whether IPv6-only or dual-stack, routers are When deploying IPv6, whether IPv6-only or dual-stack, routers are
configured to send IPv6 Router Advertisements to convey information configured to send IPv6 Router Advertisements (RAs) to convey
to nodes that enable them to autoconfigure on the network. This information to nodes that enable them to autoconfigure on the
information includes the implied default router address taken from network. This information includes the implied default router
the observed source address of the Router Advertisement (RA) message, address taken from the observed source address of the RA message, as
as well as on-link prefix information. However, unintended well as on-link prefix information. However, unintended
misconfigurations by users or administrators, or possibly malicious misconfigurations by users or administrators, or possibly malicious
attacks on the network, may lead to bogus RAs being present, which in attacks on the network, may lead to bogus RAs being present, which in
turn can cause operational problems for hosts on the network. In turn can cause operational problems for hosts on the network. In
this draft we summarise the scenarios in which rogue RAs may be this document, we summarise the scenarios in which rogue RAs may be
observed and present a list of possible solutions to the problem. We observed and present a list of possible solutions to the problem. We
focus on the unintended causes of rogue RAs in the text. The goal of focus on the unintended causes of rogue RAs in the text. The goal of
this text is to be Informational, and as such to present a framework this text is to be Informational, and as such to present a framework
around which solutions can be proposed and discussed. around which solutions can be proposed and discussed.
Status of this Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering This document is not an Internet Standards Track specification; it is
Task Force (IETF). Note that other groups may also distribute published for informational purposes.
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Not all documents
approved by the IESG are a candidate for any level of Internet
Standard; see Section 2 of RFC 5741.
This Internet-Draft will expire on April 28, 2011. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc6104.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2011 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
skipping to change at page 3, line 7 skipping to change at page 3, line 7
modifications of such material outside the IETF Standards Process. modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other it for publication as an RFC or to translate it into languages other
than English. than English.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction ....................................................4
2. Bogus RA Scenarios . . . . . . . . . . . . . . . . . . . . . . 4 2. Bogus RA Scenarios ..............................................4
2.1. Administrator misconfiguration . . . . . . . . . . . . . . 5 2.1. Administrator Misconfiguration .............................5
2.2. User misconfiguration . . . . . . . . . . . . . . . . . . 5 2.2. User Misconfiguration ......................................5
2.3. Malicious misconfiguration . . . . . . . . . . . . . . . . 5 2.3. Malicious Misconfiguration .................................5
3. Methods to Mitigate against Rogue RAs . . . . . . . . . . . . 6 3. Methods to Mitigate against Rogue RAs ...........................6
3.1. Manual configuration . . . . . . . . . . . . . . . . . . . 6 3.1. Manual Configuration .......................................6
3.2. Introduce RA snooping . . . . . . . . . . . . . . . . . . 6 3.2. Introducing RA Snooping ....................................6
3.3. Use ACLs on Managed Switches . . . . . . . . . . . . . . . 7 3.3. Using ACLs on Managed Switches .............................7
3.4. Secure Neighbor Discovery (SeND) . . . . . . . . . . . . . 7 3.4. SEcure Neighbor Discovery (SEND) ...........................7
3.5. Router Preference Option . . . . . . . . . . . . . . . . . 8 3.5. Router Preference Option ...................................8
3.6. Rely on Layer 2 admission control . . . . . . . . . . . . 8 3.6. Relying on Layer 2 Admission Control .......................8
3.7. Use host-based packet filters . . . . . . . . . . . . . . 8 3.7. Using Host-Based Packet Filters ............................8
3.8. Use an 'intelligent' deprecation tool . . . . . . . . . . 8 3.8. Using an "Intelligent" Deprecation Tool ....................8
3.9. Use Layer 2 Partitioning . . . . . . . . . . . . . . . . . 9 3.9. Using Layer 2 Partitioning .................................9
3.10. Add Default Gateway/Prefix Options to DHCPv6 . . . . . . . 9 3.10. Adding Default Gateway/Prefix Options to DHCPv6 ...........9
4. Scenarios and mitigations . . . . . . . . . . . . . . . . . . 10 4. Scenarios and Mitigations ......................................10
5. Other related considerations . . . . . . . . . . . . . . . . . 11 5. Other Related Considerations ...................................11
5.1. Unicast RAs . . . . . . . . . . . . . . . . . . . . . . . 11 5.1. Unicast RAs ...............................................11
5.2. The DHCP vs RA threat model . . . . . . . . . . . . . . . 11 5.2. The DHCP versus RA Threat Model ...........................11
5.3. IPv4-only networks . . . . . . . . . . . . . . . . . . . . 12 5.3. IPv4-Only Networks ........................................12
5.4. Network monitoring tools . . . . . . . . . . . . . . . . . 12 5.4. Network Monitoring Tools ..................................12
5.5. Recovering from bad configuration state . . . . . . . . . 12 5.5. Recovering from Bad Configuration State ...................12
5.6. Isolating the offending rogue RA source . . . . . . . . . 13 5.6. Isolating the Offending Rogue RA Source ...................13
6. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 13 6. Conclusions ....................................................13
7. Security Considerations . . . . . . . . . . . . . . . . . . . 14 7. Security Considerations ........................................14
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 8. Acknowledgments ................................................14
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14 9. Informative References .........................................15
10. Informative References . . . . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16
1. Introduction 1. Introduction
The Neighbor Discovery protocol [RFC4861] describes the operation of The Neighbor Discovery protocol [RFC4861] describes the operation of
IPv6 Router Advertisements (RAs) which are used to determine node IPv6 Router Advertisements (RAs) that are used to determine node
configuration information during the IPv6 autoconfiguration process, configuration information during the IPv6 autoconfiguration process,
whether that node's configuration is stateful via Dynamic Host whether that node's configuration is stateful, via the Dynamic Host
Configuration Protocol for IPv6 (DHCPv6) [RFC3315] or stateless, as Configuration Protocol for IPv6 (DHCPv6) [RFC3315] or stateless, as
per [RFC4862], possibly in combination with DHCPv6 Light [RFC3736]. per [RFC4862], possibly in combination with DHCPv6 Light [RFC3736].
In observing the operation of deployed IPv6 networks, it is apparent In observing the operation of deployed IPv6 networks, it is apparent
that there is a problem with undesired or 'bogus' IPv6 Router that there is a problem with undesired or "bogus" IPv6 RAs appearing
Advertisements (RAs) appearing on network links or subnets. By on network links or subnets. By "bogus" we mean RAs that were not
'bogus' we mean RAs that were not the intended configured RAs, rather the intended configured RAs, but rather RAs that have appeared for
RAs that have appeared for some other reason. While the problem some other reason. While the problem appears more common in shared
appears more common in shared wireless environments, it is also seen wireless environments, it is also seen on wired enterprise networks.
on wired enterprise networks.
The problem with rogue RAs is that they can cause partial or complete The problem with rogue RAs is that they can cause partial or complete
failure of operation of hosts on an IPv6 link. For example, the failure of operation of hosts on an IPv6 link. For example, the
default router address is drawn directly from the source address of default router address is drawn directly from the source address of
the RA message. In addition, rogue RAs can cause hosts to assume the RA message. In addition, rogue RAs can cause hosts to assume
wrong prefixes to be used for stateless address autoconfiguration. wrong prefixes to be used for stateless address autoconfiguration.
In a case where there may be mixing of 'good' and 'bad' RAs, a host In a case where there may be mixing of "good" and "bad" RAs, a host
might keep on using the 'good' default gateway, but pick a wrong might keep on using the "good" default gateway, but pick a wrong
source address, leading to egress filtering problems. As such, rogue source address, leading to egress filtering problems. As such, rogue
RAs are an operational issue for which solution(s) are required, and RAs are an operational issue for which solution(s) are required, and
for which best practice needs to be conveyed. This not only includes for which best practice needs to be conveyed. This not only includes
preventing or detecting rogue RAs, but also where necessary ensuring preventing or detecting rogue RAs, but also where necessary ensuring
the network (and hosts on the network) have the ability to quickly the network (and hosts on the network) have the ability to quickly
recover from a state where host configuration is incorrect as a recover from a state where host configuration is incorrect as a
result of processing such an RA. result of processing such an RA.
In the next section, we discuss the scenarios that may give rise to In the next section, we discuss the scenarios that may give rise to
rogue RAs being present. In the following section we present some rogue RAs being present. In the following section, we present some
candidate solutions for the problem, some of which may be more candidate solutions for the problem, some of which may be more
practical to deploy than others. This document focuses on practical to deploy than others. This document focuses on
'accidental' rogue RAs; while malicious RAs are of course also "accidental" rogue RAs; while malicious RAs are of course also
possible, the common problem today lies with unintended RAs. In possible, the common problem today lies with unintended RAs. In
addition a network experiencing malicious attack of this kind is addition, a network experiencing malicious attack of this kind is
likely to also experience malicious Neighbour Advertisement (NA) and likely to also experience malicious Neighbor Advertisement (NA) and
related messages also. related messages.
2. Bogus RA Scenarios 2. Bogus RA Scenarios
There are three broad classes of scenario in which bogus RAs may be There are three broad classes of scenario in which bogus RAs may be
introduced to an IPv6 network. introduced to an IPv6 network.
2.1. Administrator misconfiguration 2.1. Administrator Misconfiguration
Here an administrator incorrectly configures RAs on a router Here an administrator incorrectly configures RAs on a router
interface, causing incorrect RAs to appear on links and hosts to interface, causing incorrect RAs to appear on links and causing hosts
generate incorrect or unintended IPv6 address, gateway or other to generate incorrect or unintended IPv6 address, gateway, or other
information. In such a case the default gateway may be correct, but information. In such a case, the default gateway may be correct, but
a host might for example become multi-addressed, possibly with a a host might for example become multiaddressed, possibly with a
correct and incorrect address based on a correct and incorrect correct and incorrect address based on a correct and incorrect
prefix. There is also the possibility of other configuration prefix. There is also the possibility of other configuration
information being misconfigured, such as the lifetime option. information being misconfigured, such as the lifetime option.
In the case of a Layer 2 IEEE 802.1Q Virtual LAN (VLAN) In the case of a Layer 2 IEEE 802.1Q Virtual LAN (VLAN)
misconfiguration, RAs may 'flood' to unintended links, causing hosts misconfiguration, RAs may "flood" to unintended links, causing hosts
or more than one link to potentially become incorrectly or more than one link to potentially become incorrectly
multiaddressed, with possibly two different default routers multiaddressed, with possibly two different default routers
available. available.
2.2. User misconfiguration 2.2. User Misconfiguration
In this case a user's device 'accidentally' transmits RAs onto the In this case, a user's device "accidentally" transmits RAs onto the
local link, potentially adding an additional default gateway and local link, potentially adding an additional default gateway and
associated prefix information. associated prefix information.
This seems to typically be seen on wireless (though sometimes wired) This seems to typically be seen on wireless (though sometimes wired)
networks where a laptop has enabled the Windows Internet Connection networks where a laptop has enabled the Windows Internet Connection
Sharing service (ICS) which turns a host into a 6to4 [RFC3056] Sharing (ICS) service, which can turn a host into a 6to4 [RFC3056]
gateway; this can be a useful feature, unless of course it is run gateway; this can be a useful feature, unless of course it is run
when not intended. This service can also cause IPv4 problems too, as when not intended. This service can also cause IPv4 problems, as it
it will typically start a 'rogue' DHCPv4 server on the host. will typically start a "rogue" DHCPv4 server on the host.
We have also had reports that hosts may not see genuine IPv6 RAs on a We have also had reports that hosts may not see genuine IPv6 RAs on a
link due to host firewalls, causing them to turn on a connection link due to host firewalls, causing them to turn on a connection-
sharing service and 6to4 as a result. In some cases more technical sharing service and 6to4 as a result. In some cases, more technical
users may also use a laptop as a home gateway (e.g. again a 6to4 users may also use a laptop as a home gateway (e.g., again a 6to4
gateway) and then connect to another network forgetting their gateway) and then connect to another network, forgetting their
previous gateway configuration is still active. previous gateway configuration is still active.
There are also reported incidents in enterprise networks of users There are also reported incidents in enterprise networks of users
physically plugging Ethernet cables into the wrong sockets and physically plugging Ethernet cables into the wrong sockets and
bridging two subnets together, causing a problem similar to VLAN bridging two subnets together, causing a problem similar to VLAN
flooding. flooding.
2.3. Malicious misconfiguration 2.3. Malicious Misconfiguration
Here an attacker is deliberately generating RAs on the local network Here an attacker is deliberately generating RAs on the local network
in an attempt to perform some form of denial of service or man-in- in an attempt to perform some form of denial-of-service or man-in-
the-middle attack. the-middle attack.
As stated above, while this is a genuine concern for network As stated above, while this is a genuine concern for network
administrators, there have been few if any reports of such activity, administrators, there have been few if any reports of such activity,
while in contrast reports of accidental rogue RAs are very while in contrast reports of accidental rogue RAs are very
commonplace. In writing this text, and with the feedback of the commonplace. In writing this text, and with the feedback of the
v6ops WG, we came to the conclusion that the issue of malicious v6ops working group, we came to the conclusion that the issue of
attack, due to the other complementary attacks that are likely to be malicious attack, due to the other complementary attacks that are
launched using rogue NA and similar messages, are best considered by likely to be launched using rogue NA and similar messages, are best
further work and document(s). As a result, this text intends to considered by further work and document(s). As a result, this text
provide informational guidance for operators looking for practical intends to provide informational guidance for operators looking for
measures to take to avoid 'accidental' rogue RAs on their own practical measures to take to avoid "accidental" rogue RAs on their
networks. own networks.
3. Methods to Mitigate against Rogue RAs 3. Methods to Mitigate against Rogue RAs
In this section we present a summary of methods suggested to date for In this section, we present a summary of methods suggested to date
reducing or removing the possibility of rogue RAs being seen on a for reducing or removing the possibility of rogue RAs being seen on a
network. network.
3.1. Manual configuration 3.1. Manual Configuration
The default gateway and host address can usually be manually The default gateway and host address can usually be manually
configured on a node. This of course can be a resource intensive configured on a node. This of course can be a resource intensive
solution, and also prone to administrative mistakes in itself. solution, and also prone to administrative mistakes in itself.
Manual configuration implies that RA processing is disabled. Most Manual configuration implies that RA processing is disabled. Most
operating systems allow RA messages to be ignored, such that if an operating systems allow RA messages to be ignored, such that if an
IPv6 address is manually configured on a system, an additional global IPv6 address is manually configured on a system, an additional global
autoconfigured address will not be added should an unexpected RA autoconfigured address will not be added should an unexpected RA
appear on the link. appear on the link.
3.2. Introduce RA snooping 3.2. Introducing RA Snooping
It should be possible to implement 'RA snooping' in Layer 2 switches It should be possible to implement "RA snooping" in Layer 2 switches
in a similar way to DHCP snooping, such that RAs observed from in a similar way to DHCP snooping, such that RAs observed from
incorrect sources are blocked or dropped, and not propagated through incorrect sources are blocked or dropped, and not propagated through
a subnet. One candidate solution in this space called RA-Guard a subnet. One candidate solution in this space, called "RA-Guard"
[I-D.ietf-v6ops-ra-guard] has been proposed. This type of solution [RFC6105], has been proposed. This type of solution has appeal
has appeal because it is a familiar model for enterprise network because it is a familiar model for enterprise network managers, but
managers, but it can also be used to complement Secure Neighbour it can also be used to complement SEcure Neighbor Discovery (SEND)
Discovery (SeND) [RFC3971], by a switch acting as a SeND proxy for [RFC3971], by a switch acting as a SEND proxy for hosts.
hosts.
This type of solution may not be applicable everywhere, e.g. in This type of solution may not be applicable everywhere, e.g., in
environments where there are not centrally controlled or manageable environments where there are not centrally controlled or manageable
switches. switches.
3.3. Use ACLs on Managed Switches 3.3. Using ACLs on Managed Switches
Certain switch platforms can already implement some level of rogue RA Certain switch platforms can already implement some level of rogue RA
filtering by the administrator configuring Access Control Lists filtering by the administrator configuring Access Control Lists
(ACLs) that block RA ICMP messages that might be inbound on 'user' (ACLs) that block RA ICMP messages that might be inbound on "user"
ports. Again this type of 'solution' depends on the presence of such ports. Again this type of "solution" depends on the presence of such
configurable switches. configurable switches.
A recent draft describes the RA message format(s) for filtering A recent document describes the RA message format(s) for filtering
[I-D.nward-ipv6-autoconfig-filtering-ethernet]. This draft also [IPv6-AUTOCFG-FILTER]. The document also notes requirements for
notes requirements for DHCPv6 snooping, which can then be implemented DHCPv6 snooping, which can then be implemented similarly to DHCPv4
similar to DHCPv4 snooping. snooping.
3.4. Secure Neighbor Discovery (SeND) 3.4. SEcure Neighbor Discovery (SEND)
The Secure Neighbor Discovery (SeND) [RFC3971] protocol provides a The SEcure Neighbor Discovery (SEND) [RFC3971] protocol provides a
method for hosts and routers to perform secure Neighbor Discovery. method for hosts and routers to perform secure Neighbor Discovery.
Thus it can in principle protect a network against rogue RAs. Thus, it can in principle protect a network against rogue RAs.
SeND is not yet widely used at the time of writing, in part because SEND is not yet widely used at the time of writing, in part because
there are very few implementations of the protocol. Some other there are very few implementations of the protocol. Some other
deployment issues have been raised, though these are likely to be deployment issues have been raised, though these are likely to be
resolved in due course. For example, routers probably don't want to resolved in due course. For example, routers probably don't want to
use autogenerated addresses (which might need to be protected by use autogenerated addresses (which might need to be protected by
ACLs) so SeND needs to be shown to work with non autogenerated ACLs), so SEND needs to be shown to work with non-autogenerated
addresses. Also, it has been argued that there are 'bootstrapping' addresses. Also, it has been argued that there are "bootstrapping"
issues, in that hosts wanting to validate router credentials (e.g. to issues, in that hosts wanting to validate router credentials (e.g.,
a certificate server or Network Time Protocol (NTP) server) are to a certificate server or Network Time Protocol (NTP) server) are
likely to need to communicate via the router for that information. likely to need to communicate via the router for that information.
Further, it's not wholly clear how widely adopted SeND could or would Further, it's not wholly clear how widely adopted SEND could or would
be in site networks with 'lightweight' security (e.g. many campus be in site networks with "lightweight" security (e.g., many campus
networks), especially where hosts are managed by users and not networks), especially where hosts are managed by users and not
administratively. Public or conference wireless networks may face administratively. Public or conference wireless networks may face
similar challenges. There may also be networks, like perhaps sensor similar challenges. There may also be networks, like perhaps sensor
networks, where use of SeND is less practical. These networks still networks, where use of SEND is less practical. These networks still
require rogue RA protection. require rogue RA protection.
While SeND clearly can provide a good, longer term solution, While SEND clearly can provide a good, longer-term solution,
especially in networks where malicious activity is a significant especially in networks where malicious activity is a significant
concern, there is a requirement today for practical solutions, and/or concern, there is a requirement today for practical solutions, and/or
solutions more readily applicable in more 'relaxed' environments. In solutions more readily applicable in more "relaxed" environments. In
the latter case, solutions like 'RA snooping' or applied ACLs are the latter case, solutions like "RA snooping" or applied ACLs are
more attractive now. more attractive now.
3.5. Router Preference Option 3.5. Router Preference Option
[RFC4191] introduced a router preference option, such that an RA [RFC4191] introduced a Router Preference option, such that an RA
could carry one of three router preference values: High, Medium could carry one of three Router Preference values: High, Medium
(default) or Low. Thus an administrator could use High settings for (default), or Low. Thus, an administrator could use "High" settings
managed RAs, and hope that 'accidental' RAs would be medium priority. for managed RAs, and hope that "accidental" RAs would be medium
This of course would only work in some scenarios - if the user who priority. This of course would only work in some scenarios -- if the
accidentally sends out a rogue RA on the network has configured their user who accidentally sends out a rogue RA on the network has
device with High precedence for their own intended usage, the configured their device with "High" precedence for their own intended
priorities would clash. But for accidental rogue RAs caused by usage, the priorities would clash. But for accidental rogue RAs
software like Windows ICS and 6to4, which would use the default caused by software like Windows ICS and 6to4, which would use the
precedence, it could be useful. Obviously this solution would also default precedence, it could be useful. Obviously this solution
rely on clients (and routers) having implementations of the Router would also rely on clients (and routers) having implementations of
Preference Option. the Router Preference option.
3.6. Rely on Layer 2 admission control 3.6. Relying on Layer 2 Admission Control
In principle, if a technology such as IEEE 802.1x is used, devices In principle, if a technology such as IEEE 802.1x is used, devices
would first need to authenticate to the network before being able to would first need to authenticate to the network before being able to
send or receive IPv6 traffic. Ideally authentication would be send or receive IPv6 traffic. Ideally, authentication would be
mutual. Deployment of 802.1x, with mutual authentication, may mutual. Deployment of 802.1x, with mutual authentication, may
however be seen as somewhat 'heavyweight' akin to SeND, for some however be seen as somewhat "heavyweight", akin to SEND, for some
deployments. deployments.
Improving Layer 2 security may help to mitigate against an attacker's Improving Layer 2 security may help to mitigate against an attacker's
capability to join the network to send RAs, but it doesn't prevent capability to join the network to send RAs, but it doesn't prevent
misconfiguration issues. A user can happily authenticate and still misconfiguration issues. A user can happily authenticate and still
launch a Windows ICS service for example. launch a Windows ICS service, for example.
3.7. Use host-based packet filters 3.7. Using Host-Based Packet Filters
In a managed environment hosts could be configured via their In a managed environment, hosts could be configured via their
'personal firewall' to only accept RAs from trusted sources. Hosts "personal firewall" to only accept RAs from trusted sources. Hosts
could also potentially be configured to discard 6to4-based RAs in a could also potentially be configured to discard 6to4-based RAs in a
managed enterprise environment. managed enterprise environment.
However, the problem is then pushed to keeping this configuration However, the problem is then pushed to keeping this configuration
maintained and correct. If a router fails and is replaced, possibly maintained and correct. If a router fails and is replaced, possibly
with a new Layer 2 interface address, the link local source address with a new Layer 2 interface address, the link local source address
in the filter may become incorrect and thus no method would be in the filter may become incorrect, and thus no method would be
available to push the new information to the host over the network. available to push the new information to the host over the network.
3.8. Use an 'intelligent' deprecation tool 3.8. Using an "Intelligent" Deprecation Tool
It is possible to run a daemon on a link (perhaps on the router on It is possible to run a daemon on a link (perhaps on the router on
the link) to watch for incorrect RAs and to send a deprecating RA the link) to watch for incorrect RAs and to send a deprecating RA
with router lifetime of zero when such an RA is observed. The KAME with a router lifetime of zero when such an RA is observed. The KAME
rafixd is an example of such a tool, which has been used at IETF rafixd is an example of such a tool, which has been used at IETF
meetings with some success. A slightly enhanced tool called RAMOND meetings with some success. A slightly enhanced tool called RAMOND
has since been developed from this code, and is now available as a has since been developed from this code, and is now available as a
Sourceforge project. As with host based firewalling, the daemon Sourceforge project. As with host-based firewalling, the daemon
would need to somehow know what 'good' and 'bad' RAs are, from some would need to somehow know what "good" and "bad" RAs are, from some
combination of known good sources and/or link prefixes. In an combination of known good sources and/or link prefixes. In an
environment with native IPv6 though, 6to4-based RAs would certainly environment with native IPv6, though, 6to4-based RAs would certainly
be known to be rogue. be known to be rogue.
Whether or not use of such a tool is the preferred method, monitoring Whether or not use of such a tool is the preferred method, monitoring
a link for observed RAs seems prudent from a network management a link for observed RAs seems prudent from a network management
perspective. Some such tools exist already, e.g. NDPMon, which can perspective. Some such tools exist already, e.g., NDPMon, which can
also detect other undesirable behaviour. also detect other undesirable behaviour.
3.9. Use Layer 2 Partitioning 3.9. Using Layer 2 Partitioning
If each system or user on a network is partitioned into a different If each system or user on a network is partitioned into a different
Layer 2 medium, then the impact of rogue RAs can be limited. In Layer 2 medium, then the impact of rogue RAs can be limited. In
broadband networks RFC2684 bridging [RFC2684] may be available, for broadband networks, bridging [RFC2684] may be available, for example.
example. The benefit may be scenario-specific, e.g. whether a given The benefit may be scenario-specific, e.g., whether a given user or
user or customer has their own network prefix or whether the customer has their own network prefix or whether the provisioning is
provisioning is in a shared subnet or link. It is certainly in a shared subnet or link. It is certainly desirable that any given
desirable that any given user or customer's system(s) are unable to user or customer's system(s) are unable to see RAs that may be
see RAs that may be generated by other users or customers. generated by other users or customers.
However, such partitioning would probably increase address space However, such partitioning would probably increase address space
consumption significantly if applied in enterprise networks, and in consumption significantly if applied in enterprise networks, and in
many cases hardware costs and software licensing costs to enable many cases, hardware costs and software licensing costs to enable
routing to the edge can be quite significant. routing to the edge can be quite significant.
3.10. Add Default Gateway/Prefix Options to DHCPv6 3.10. Adding Default Gateway/Prefix Options to DHCPv6
Adding Default Gateway and Prefix options for DHCPv6 would allow Adding Default Gateway and Prefix options for DHCPv6 would allow
network administrators to configure hosts to only use DHCPv6 for network administrators to configure hosts to only use DHCPv6 for
default gateway and prefix configuration in managed networks, where default gateway and prefix configuration in managed networks, where
RAs would be required today. A new draft has proposed such a default RAs would be required today. A new document has proposed such a
router option, along with prefix advertisement options for DHCPv6 default router option, along with prefix advertisement options for
[I-D.droms-dhc-dhcpv6-default-router]. Even with such options added DHCPv6 [DHCPv6-DEFAULT-RTR]. Even with such options added to DHCPv6,
to DHCPv6, an RA is in principle still required to inform hosts to an RA is in principle still required to inform hosts to use DHCPv6.
use DHCPv6.
An advantage of DHCPv6 is that should an error be introduced, only An advantage of DHCPv6 is that should an error be introduced, only
hosts that have refreshed their DHCP information since that time are hosts that have refreshed their DHCP information since that time are
affected, while a multicast rogue RA will most likely affect all affected, while a multicast rogue RA will most likely affect all
hosts immediately. DHCPv6 also allows different answers to be given hosts immediately. DHCPv6 also allows different answers to be given
to different hosts. to different hosts.
While making host configuration possible via DHCPv6 alone is While making host configuration possible via DHCPv6 alone is a viable
possible, making IPv6 configuration able to be done in a similar way option that would allow IPv6 configuration to be done in a way
to IPv4 today, the problem has only been shifted. Rather than rogue similar to IPv4 today, the problem has only been shifted: rather than
RAs being the problem, rogue DHCPv6 servers would be an equivalent rogue RAs being the problem, rogue DHCPv6 servers would be an
issue. As with IPv4, a network would then still require use of equivalent issue. As with IPv4, a network would then still require
Authenticated DHCP, or DHCP(v6) snooping, as suggested in use of Authenticated DHCP, or DHCP(v6) snooping, as suggested in
[I-D.nward-ipv6-autoconfig-filtering-ethernet]. [IPv6-AUTOCFG-FILTER].
There is certainly some demand in the community for DHCPv6-only host There is certainly some demand in the community for DHCPv6-only host
configuration. While this may mitigate the rogue RA issue, it simply configuration. While this may mitigate the rogue RA issue, it simply
moves the trust problem elsewhere, albeit to a place administrators moves the trust problem elsewhere, albeit to a place administrators
are familiar with today. are familiar with today.
4. Scenarios and mitigations 4. Scenarios and Mitigations
In this section we summarise the scenarios and practical mitigations In this section, we summarise the error/misconfiguration scenarios
described above in a matrix format. We consider, for the case of a and practical mitigation methods described above in a matrix format.
rogue multicast RA, which of the mitigation methods helps protect We consider, for the case of a rogue multicast RA, which of the
against administrator and user errors. For the administrator error, mitigation methods helps protect against administrator and user
we discount an error in configuring the countermeasure itself, rather errors. For the administrator error, we discount an error in
we consider an administrator error to be an error in configuration configuring the countermeasure itself; rather, we consider an
elsewhere in the network. administrator error to be an error in configuration elsewhere in the
network.
+------------------------+-------------+-------------+ +------------------------+---------------------------+
| Scenario | Admin | User | | | Scenario |
| Mitigation | Error | Error | | Mitigation |---------------------------|
| Method | Admin Error | User Error |
+------------------------+-------------+-------------+ +------------------------+-------------+-------------+
| Manual configuration | Y | Y | | Manual configuration | Y | Y |
+------------------------+-------------+-------------+ +------------------------+-------------+-------------+
| SeND | Y | Y | | SEND | Y | Y |
+------------------------+-------------+-------------+ +------------------------+-------------+-------------+
| RA snooping | Y | Y | | RA snooping | Y | Y |
+------------------------+-------------+-------------+ +------------------------+-------------+-------------+
| Use switch ACLs | Y | Y | | Use switch ACLs | Y | Y |
+------------------------+-------------+-------------+ +------------------------+-------------+-------------+
| Router preference | N | Y | | Router preference | N | Y |
+------------------------+-------------+-------------+ +------------------------+-------------+-------------+
| Layer 2 admission | N | N | | Layer 2 admission | N | N |
+------------------------+-------------+-------------+ +------------------------+-------------+-------------+
| Host firewall | Y | Y | | Host firewall | Y | Y |
skipping to change at page 11, line 8 skipping to change at page 11, line 8
| Deprecation daemon | Y | Y | | Deprecation daemon | Y | Y |
+------------------------+-------------+-------------+ +------------------------+-------------+-------------+
| Layer 2 partition | N | Y | | Layer 2 partition | N | Y |
+------------------------+-------------+-------------+ +------------------------+-------------+-------------+
| DHCPv6 gateway option | Partly | If Auth | | DHCPv6 gateway option | Partly | If Auth |
+------------------------+-------------+-------------+ +------------------------+-------------+-------------+
What the above summary does not consider is the practicality of What the above summary does not consider is the practicality of
deploying the measure. An easy-to-deploy method that buys improved deploying the measure. An easy-to-deploy method that buys improved
resilience to rogue RAs without significant administrative overhead resilience to rogue RAs without significant administrative overhead
is attractive. On that basis the RA snooping proposal, e.g. RA is attractive. On that basis, the RA snooping proposal, e.g.,
Guard, has merit, while approaches like manual configuration are less RA-Guard, has merit, while approaches like manual configuration are
appealing. However RA Guard is not yet fully defined or available, less appealing. However, RA-Guard is not yet fully defined or
while only certain managed switch equipment may support the required available, while only certain managed switch equipment may support
ACLs. the required ACLs.
5. Other related considerations 5. Other Related Considerations
There are a number of related issues that have come out of There are a number of related issues that have come out of
discussions on the rogue RA topic, which the authors believe are discussions on the rogue RA topic, which the authors believe are
worth capturing in this document. worth capturing in this document.
5.1. Unicast RAs 5.1. Unicast RAs
The above discussion was initially held on the assumption that rogue The above discussion was initially held on the assumption that rogue
multicast RAs were the cause of problems on a shared network subnet. multicast RAs were the cause of problems on a shared network subnet.
However, the specifications for Router Advertisements allow them to However, the specifications for Router Advertisements allow them to
be sent unicast to a host, as per Section 6.2.6 of RFC4861. If a be sent unicast to a host, as per Section 6.2.6 of RFC 4861. If a
host sending rogues RAs sends them unicast to the soliciting host, host sending rogue RAs sends them unicast to the soliciting host,
that RA may not be seen by other hosts on the shared medium, e.g. by that RA may not be seen by other hosts on the shared medium, e.g., by
a monitoring daemon. In most cases though, an accidental rogue RA is a monitoring daemon. In most cases, though, an accidental rogue RA
likely to be multicast. is likely to be multicast.
5.2. The DHCP vs RA threat model 5.2. The DHCP versus RA Threat Model
Comparing the threat model for rogue RAs and rogue DHCPv6 servers is Comparing the threat model for rogue RAs and rogue DHCPv6 servers is
an interesting exercise. In the case of Windows ICS causing rogue an interesting exercise. In the case of Windows ICS causing rogue
6to4-based RAs to appear on a network, it is very likely that the 6to4-based RAs to appear on a network, it is very likely that the
same host is also acting as a rogue IPv4 DHCP server. The rogue same host is also acting as a rogue IPv4 DHCP server. The rogue
DHCPv4 server can allocate a default gateway and an address to hosts, DHCPv4 server can allocate a default gateway and an address to hosts,
just as a rogue RA can lead hosts to learning of a new (additional) just as a rogue RA can lead hosts to learning of a new (additional)
default gateway, prefix(es) and address. In the case of multicast default gateway, prefix(es), and address. In the case of multicast
rogue RAs however, the impact is potentially immediate to all hosts, rogue RAs, however, the impact is potentially immediate to all hosts,
while the rogue DHCP server's impact will depend on lease timers for while the rogue DHCP server's impact will depend on lease timers for
hosts. hosts.
In principle Authenticated DHCP can be used to protect against rogue In principle, Authenticated DHCP can be used to protect against rogue
DHCPv4 (and DHCPv6) servers, just as SeND could be used to protect DHCPv4 (and DHCPv6) servers, just as SEND could be used to protect
against rogue IPv6 RAs. However, actual use of Authenticated DHCP in against rogue IPv6 RAs. However, actual use of Authenticated DHCP in
typical networks is currently minimal. Were new DHCPv6 default typical networks is currently minimal. Were new DHCPv6 default
gateway and prefix options to be standardised as described above, gateway and prefix options to be standardised as described above,
then without Authenticated DHCP the (lack of) security is just pushed then without Authenticated DHCP the (lack of) security is just pushed
to another place. to another place.
The RA Guard approach is essentially using a similar model to DHCP The RA-Guard approach is essentially using a similar model to DHCP
message snooping to protect against rogue RAs in network (switch) message snooping to protect against rogue RAs in network (switch)
equipment. As noted above, DHCPv6 message snooping would also be equipment. As noted above, DHCPv6 message snooping would also be
very desirable in IPv6 networks. very desirable in IPv6 networks.
5.3. IPv4-only networks 5.3. IPv4-Only Networks
The rogue RA problem should also be considered by administrators and The rogue RA problem should also be considered by administrators and
operators of IPv4-only networks, where IPv6 monitoring, firewalling operators of IPv4-only networks, where IPv6 monitoring, firewalling,
and other related mechanisms may not be in place. and other related mechanisms may not be in place.
For example a comment has been made that in the case of 6to4 being For example, a comment has been made that in the case of 6to4 being
run by a host on a subnet that is not administratively configured run by a host on a subnet that is not administratively configured
with IPv6, some OSes or applications may begin using IPv6 to the 6to4 with IPv6, some OSes or applications may begin using IPv6 to the 6to4
host (router) rather than IPv4 to the intended default IPv4 router, host (router) rather than IPv4 to the intended default IPv4 router,
because they have IPv6 enabled by default and some applications because they have IPv6 enabled by default and some applications
prefer IPv6 by default. Technically aware users may also prefer IPv6 by default. Technically aware users may also
deliberately choose to use IPv6, possibly for subversive reasons. deliberately choose to use IPv6, possibly for subversive reasons.
Mitigating against this condition can also be seen to be important. Mitigating against this condition can also be seen to be important.
5.4. Network monitoring tools 5.4. Network Monitoring Tools
It would generally be prudent for network monitoring or management It would generally be prudent for network monitoring or management
platforms to be able to observe and report on observed RAs, and platforms to be able to observe and report on observed RAs, and
whether unintended RAs (possibly from unintended sources) are present whether unintended RAs (possibly from unintended sources) are present
on a network. Further, it may be useful for individual hosts to be on a network. Further, it may be useful for individual hosts to be
able to report their address status (assuming their configuration able to report their address status (assuming their configuration
status allowed it of course), e.g. this could be useful during an status allowed it, of course), e.g., this could be useful during an
IPv6 renumbering phased process as described in RFC4192 [RFC4192]. IPv6 renumbering phased process as described in RFC 4192 [RFC4192].
The above assumes, of course, that what defines a 'good' (or 'bad') The above assumes, of course, that what defines a "good" (or "bad")
RA can be configured in a trustworthy manner within the network's RA can be configured in a trustworthy manner within the network's
management framework. management framework.
5.5. Recovering from bad configuration state 5.5. Recovering from Bad Configuration State
After a host receives and processes a rogue RA, it may have multiple After a host receives and processes a rogue RA, it may have multiple
default gateways, global addresses, and potentially clashing RA default gateways, global addresses, and potentially clashing RA
options (e.g. M/O bits). The host's behaviour may then be options (e.g., M/O bits [RFC4861]). The host's behaviour may then be
unpredictable, in terms of the default router that is used, and the unpredictable, in terms of the default router that is used, and the
(source) address(es) used in communications. A host that is aware of (source) address(es) used in communications. A host that is aware of
protocols such as shim6 RFC5533 [RFC5533] may believe it is genuinely protocols such as Shim6 [RFC5533] may believe it is genuinely
multihomed. multihomed.
An important issue is how readily a host can recover from receiving An important issue is how readily a host can recover from receiving
and processing bad configuration information, e.g. considering the '2 and processing bad configuration information, e.g., considering the
hour rule' of Section 5.5.3 of RFC4862 (though this applies to the "2 hour rule" mentioned in Section 5.5.3 of RFC 4862 (though this
valid address lifetime not the router lifetime). We should ensure applies to the valid address lifetime and not the router lifetime).
that methods exist for a network administrator to correct bad We should ensure that methods exist for a network administrator to
configuration information on a link or subnet, and that OS platforms correct bad configuration information on a link or subnet, and that
support these methods. At least if the problem can be detected, and OS platforms support these methods. At least if the problem can be
corrected promptly, the impact is minimised. detected, and corrected promptly, the impact is minimised.
5.6. Isolating the offending rogue RA source 5.6. Isolating the Offending Rogue RA Source
In addition to issuing a deprecating RA, it would be desirable to In addition to issuing a deprecating RA, it would be desirable to
isolate the offending source of the rogue RA from the network. It isolate the offending source of the rogue RA from the network. It
may be possible to use Network Access Control methods to quarantine may be possible to use Network Access Control methods to quarantine
the offending host, or rather the network point of attachment or port the offending host, or rather the network point of attachment or port
that it is using. that it is using.
6. Conclusions 6. Conclusions
In this text we have described scenarios via which rogue Router In this text we have described scenarios via which rogue Router
Advertisements (RAs) may appear on a network, and some measures that Advertisements (RAs) may appear on a network, and some measures that
could be used to mitigate against these. We have also noted some could be used to mitigate against these. We have also noted some
related issues that have arisen in the rogue RA discussions. Our related issues that have arisen in the rogue RA discussions. Our
discussion is generally focused on the assumption that rogue RAs are discussion is generally focused on the assumption that rogue RAs are
appearing as a result of accidental misconfiguration on the network, appearing as a result of accidental misconfiguration on the network,
by a user or administrator. by a user or administrator.
While SeND perhaps offers the most robust solution, implementations While SEND perhaps offers the most robust solution, implementations
and deployment guidelines are not yet widely available. SeND is very and deployment guidelines are not yet widely available. SEND is very
likely to be a good, longer term solution, but many administrators likely to be a good, longer-term solution, but many administrators
are seeking solutions today. Such administrators are also often in are seeking solutions today. Such administrators are also often in
networks with security models for which SeND is a 'heavyweight' networks with security models for which SEND is a "heavyweight"
solution, e.g. campus networks, or wireless conference or public solution, e.g., campus networks, or wireless conference or public
networks. For such scenarios, simpler measures are desirable. networks. For such scenarios, simpler measures are desirable.
Adding new DHCPv6 Default Gateway and Prefix Options would allow IPv6 Adding new DHCPv6 Default Gateway and Prefix options would allow IPv6
host configuration by DHCP only, and be a method that IPv4 host configuration by DHCP only and would be a method that IPv4
administrators are comfortable with (for better or worse), but this administrators are comfortable with (for better or worse), but this
simply shifts the robustness issue elsewhere. simply shifts the robustness issue elsewhere.
While a number of the mitigations described above have their appeal, While a number of the mitigations described above have their appeal,
the simplest solutions probably lie in switch-based ACLs and RA-Guard the simplest solutions probably lie in switch-based ACLs and
style approaches. Where managed switches are not available, use of RA-Guard-style approaches. Where managed switches are not available,
the Router Preference option and (more so in managed desktop use of the Router Preference option and (more so in managed desktop
environments) host firewalls may be appropriate. environments) host firewalls may be appropriate.
In the longer term wider experience of SeND will be beneficial, while In the longer term, wider experience of SEND will be beneficial,
the use of RA snooping will remain useful either to complement SeND while the use of RA snooping will remain useful either to complement
(where a switch running RA Guard can potentially be a SeND proxy) or SEND (where a switch running RA-Guard can potentially be a SEND
to assist in scenarios for which SeND is not deployed. proxy) or to assist in scenarios for which SEND is not deployed.
7. Security Considerations 7. Security Considerations
This Informational document is focused on discussing solutions to This Informational document is focused on discussing solutions to
operational problems caused by rogue RAs resulting from unintended operational problems caused by rogue RAs resulting from unintended
misconfiguration by users or administrators. Earlier versions of misconfiguration by users or administrators. Earlier versions of
this text included some analysis of rogue RAs introduced maliciously, this text included some analysis of rogue RAs introduced maliciously;
e.g. by including an extra column in the table in Section 4. e.g., the text included an extra column in the matrix in Section 4.
However, the consensus of the v6ops WG feedback was to instead focus However, the consensus of the v6ops working group feedback was to
on the common operational problem seen today, of 'accidental' rogue instead focus on the common operational problem of "accidental" rogue
RAs. RAs seen today.
Thus the final version of this text does not address attacks on a Thus, the final version of this text does not address attacks on a
network where rogue RAs are intentionally introduced as part of a network where rogue RAs are intentionally introduced as part of a
broader attack, e.g. including malicious NA messages. On the wire, broader attack, e.g., including malicious NA messages. On the wire,
malicious rogue RAs will generally look the same as 'accidental' malicious rogue RAs will generally look the same as "accidental"
ones, though they are more likely, for example, to spoof the MAC or ones, though they are more likely, for example, to spoof the Media
IPv6 source address of the genuine router, or to use a High router Access Control (MAC) or IPv6 source address of the genuine router, or
preference option. It is also likely that malicious rogue RAs will to use a "High" Router Preference option. It is also likely that
be accompanied by other attacks on the IPv6 infrastructure, making malicious rogue RAs will be accompanied by other attacks on the IPv6
discussion of mitigations more complex. Administrators may be able infrastructure, making discussion of mitigations more complex.
to detect such activity by use of tools such as NDPMon. Administrators may be able to detect such activity by the use of
tools such as NDPMon.
It is worth noting that the deprecation daemon could be used as part It is worth noting that the deprecation daemon could be used as part
of a denial of service attack, should the tool be used to deprecate of a denial-of-service attack, should the tool be used to deprecate
the genuine RA. the genuine RA.
8. IANA Considerations 8. Acknowledgments
There are no extra IANA consideration for this document.
9. Acknowledgments
Thanks are due to members of the IETF IPv6 Operations and DHCP WGs Thanks are due to members of the IETF IPv6 Operations and DHCP
for their inputs on this topic, as well as some comments from various working groups for their inputs on this topic, as well as some
operational mailing lists, and private comments, including but not comments from various operational mailing lists, and private
limited to: Iljitsch van Beijnum, Dale Carder, Remi Denis-Courmont, comments, including but not limited to: Iljitsch van Beijnum, Dale
Tony Hain, Bob Hinden, Christian Huitema, Tatuya Jinmei, Eric Levy- Carder, Remi Denis-Courmont, Tony Hain, Bob Hinden, Christian
Abegnoli, David Malone, Thomas Narten, Chip Popoviciu, Dave Thaler, Huitema, Tatuya Jinmei, Eric Levy-Abegnoli, David Malone, Thomas
Gunter Van de Velde, Goeran Weinholt and Dan White. Narten, Chip Popoviciu, Dave Thaler, Gunter Van de Velde, Goeran
Weinholt, and Dan White.
10. Informative References 9. Informative References
[RFC2684] Grossman, D. and J. Heinanen, "Multiprotocol Encapsulation [RFC2684] Grossman, D. and J. Heinanen, "Multiprotocol Encapsulation
over ATM Adaptation Layer 5", RFC 2684, September 1999. over ATM Adaptation Layer 5", RFC 2684, September 1999.
[RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains [RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains
via IPv4 Clouds", RFC 3056, February 2001. via IPv4 Clouds", RFC 3056, February 2001.
[RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C.,
and M. Carney, "Dynamic Host Configuration Protocol for and M. Carney, "Dynamic Host Configuration Protocol for
IPv6 (DHCPv6)", RFC 3315, July 2003. IPv6 (DHCPv6)", RFC 3315, July 2003.
skipping to change at page 15, line 35 skipping to change at page 15, line 40
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
"Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
September 2007. September 2007.
[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
Address Autoconfiguration", RFC 4862, September 2007. Address Autoconfiguration", RFC 4862, September 2007.
[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, June 2009. Shim Protocol for IPv6", RFC 5533, June 2009.
[I-D.ietf-v6ops-ra-guard] [RFC6105] Levy-Abegnoli, E., Van de Velde, G., Popoviciu, C., and J.
Levy-Abegnoli, E., Velde, G., Popoviciu, C., and J. Mohacsi, "IPv6 Router Advertisement Guard", RFC 6105,
Mohacsi, "IPv6 Router Advertisement Guard", February 2011.
draft-ietf-v6ops-ra-guard-08 (work in progress),
September 2010.
[I-D.nward-ipv6-autoconfig-filtering-ethernet] [IPv6-AUTOCFG-FILTER]
Ward, N., "IPv6 Autoconfig Filtering on Ethernet Ward, N., "IPv6 Autoconfig Filtering on Ethernet
Switches", Switches", Work in Progress, March 2009.
draft-nward-ipv6-autoconfig-filtering-ethernet-00 (work in
progress), March 2009.
[I-D.droms-dhc-dhcpv6-default-router] [DHCPv6-DEFAULT-RTR]
Droms, R. and T. Narten, "Default Router and Prefix Droms, R. and T. Narten, "Default Router and Prefix
Advertisement Options for DHCPv6", Advertisement Options for DHCPv6", Work in Progress,
draft-droms-dhc-dhcpv6-default-router-00 (work in March 2009.
progress), March 2009.
Authors' Addresses Authors' Addresses
Tim Chown Tim Chown
University of Southampton University of Southampton
Highfield Highfield
Southampton, Hampshire SO17 1BJ Southampton, Hampshire SO17 1BJ
United Kingdom United Kingdom
Email: tjc@ecs.soton.ac.uk EMail: tjc@ecs.soton.ac.uk
Stig Venaas Stig Venaas
Cisco Systems Cisco Systems
Tasman Drive Tasman Drive
San Jose, CA 95134 San Jose, CA 95134
USA USA
Email: stig@cisco.com EMail: stig@cisco.com
 End of changes. 106 change blocks. 
278 lines changed or deleted 266 lines changed or added

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