One document matched: draft-ietf-v6ops-rogue-ra-00.xml

<?xml version="1.0" encoding="UTF-8"?>

<?rfc toc="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<?rfc symrefs="yes"?>

<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [

 <!ENTITY rfc1483  PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.1483.xml'>
 <!ENTITY rfc3056  PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3056.xml'>
 <!ENTITY rfc3315  PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3315.xml'>
 <!ENTITY rfc3736  PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3736.xml'>
 <!ENTITY rfc3971  PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3971.xml'>
 <!ENTITY rfc4191  PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4191.xml'>
 <!ENTITY rfc4192  PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4192.xml'>
 <!ENTITY rfc4861  PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4861.xml'>
 <!ENTITY rfc4862  PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4862.xml'>

<!ENTITY I-D.ietf-v6ops-ra-guard
	PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-v6ops-ra-guard.xml'>

<!ENTITY I-D.nward-ipv6-autoconfig-filtering-ethernet
	PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.nward-ipv6-autoconfig-filtering-ethernet.xml'>

<!ENTITY I-D.droms-dhc-dhcpv6-default-router
	PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.droms-dhc-dhcpv6-default-router.xml'>

]>

<rfc ipr="pre5378Trust200902" category="info" docName="draft-ietf-v6ops-rogue-ra-00">
	<front>
		<title abbrev="Rogue IPv6 Router Advertisements">Rogue IPv6 Router Advertisement Problem Statement</title>
		<author fullname="Tim Chown" initials="T.J." surname="Chown">
			<organization> University of Southampton </organization>
			<address>
				<postal>
					<street> Highfield </street>
					<city> Southampton </city>
					<code> SO17 1BJ </code>
					<region> Hampshire </region>
					<country> United Kingdom </country>
				</postal>
				<email> tjc@ecs.soton.ac.uk </email>
			</address>
		</author>
                <author fullname="Stig Venaas" initials="S." surname="Venaas">
                        <organization> UNINETT </organization>
                        <address>
                                <postal>
                                        <city> Trondheim </city>
                                        <code> NO 7465 </code>
                                        <country> Norway</country>
                                </postal>
                                <email> venaas@uninett.no </email>
                        </address>
                </author>
		<date month="May" year="2009"/>
		<area>Operations</area>
		<workgroup>IPv6 Operations</workgroup>
		<abstract>
<t>
When deploying IPv6, whether IPv6-only or dual-stack, routers
are configured to send IPv6 Router Advertisements to convey information
to nodes that enable them to autoconfigure on the network.  This
information includes the implied default router address taken from the
observed source address of the Router Advertisement (RA) message, as
well as on-link prefix information.
However, unintended misconfigurations by users or administrators, or 
possibly malicious attacks on the network, may 
lead to bogus RAs being present, which in turn can cause
operational problems for hosts on the network.   In this draft we summarise 
the scenarios in which rogue RAs may be 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 this text is to be Informational, and as such
to present a framework around which solutions can be proposed and discussed.
</t>
		</abstract>
	</front>
	<middle>
<section title="Introduction">
	<t>
The Neighbor Discovery protocol <xref target="RFC4861"/> describes
the operation of IPv6 Router Advertisements (RAs) which are used 
to determine node configuration information during
the IPv6 autoconfiguration process, whether that node's configuration is
stateful (via  DHCPv6 <xref target="RFC3315"/>)
or stateless (as 
per <xref target="RFC4862"/>, possibly in combination 
with DHCPv6 Light <xref target="RFC3736"/>).  
	</t>
	<t>
In observing the operation of deployed IPv6 networks, it is apparent that
there is a problem with undesired or 'bogus' IPv6 Router Advertisements (RAs)
appearing on network links or subnets.    By 'bogus' we mean RAs that
were not the intended configured RAs, rather RAs that have appeared for
some other reason.   While the problem appears more common in shared
wireless environments, it is also seen on wired enterprise networks.
	</t>
	<t>
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 default
router address is drawn directly from the source address of the RA message.   
In addition, rogue RAs can cause hosts
to assume wrong prefixes to be used for stateless address autoconfiguration.
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 source 
address, leading to egress filtering problems.
As such, rogue RAs are an operational
issue for which solution(s) are required, and for which best practice needs
to be conveyed.   This not only includes preventing or detecting rogue RAs,
but also where necessary ensuring the network (and hosts on the network)
have the ability to quickly recover from a state where
host configuration is incorrect as a result of processing such an RA.
	</t>
	<t>
In the next section, we discuss
the scenarios that may give rise to rogue RAs being present.   In the
following section we present some candidate solutions for the problem,
some of which may be more practical to deploy than others.   This document
focuses on 'accidental' rogue RAs; while malicious RAs are of course also
possible, the common problem today lies with unintended RAs.  In addition
a network experiencing malicious attack of this kind is likely to also
experience malicious NA and related messages also.
	</t>
</section>

<section title="Bogus RA Scenarios">

	<t>
There are three broad classes of scenario in which bogus RAs may be 
introduced to an IPv6 network.   
	</t>

	<section title="Administrator misconfiguration">
	<t>
Here an administrator incorrectly configures RAs on a router interface,
causing incorrect RAs to appear on links and hosts to generate incorrect
or unintended IPv6 address, gateway or other information.    
In such a case the default gateway
may be correct, but a host might for example become multi-addressed,
possibly with a correct and incorrect address based on a correct and
incorrect prefix.    There is also
the possibility of other configuration information being misconfigured,
such as the lifetime option.
	</t>
	<t>
In the case of a Layer 2 VLAN misconfiguration,
RAs may 'flood' to unintended links, causing hosts or more than one link
to potentially become incorrectly multiaddressed, with possibly two different
default routers available.    
	</t>
	</section>

	<section title="User misconfiguration">
	<t>
In this case a user's device 'accidentally' transmits RAs onto the local
link, potentially adding an additional default gateway and associated 
prefix information.   
	</t>
	<t>
This seems to typically be seen on wireless (though sometimes 
wired) networks where a laptop has enabled the Windows Internet Connection 
Sharing service (ICS) which turns a host into a 6to4
<xref target="RFC3056"/> 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 it will typically
start a 'rogue' DHCPv4 server on the host.
	</t>
	<t>
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 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 gateway) and then connect to another network
forgetting their previous gateway configuration is still active.   
	</t>
	<t>
There are also reported incidents in enterprise networks of users physically 
plugging Ethernet cables into the wrong sockets and bridging two subnets
together, causing a problem similar to VLAN flooding.
	</t>
	</section>

	<section title="Malicious misconfiguration">
	<t>
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-the-middle
attack.
	</t>
	<t>	
As stated above, while this is a genuine concern for network administrators,
there have been few if any reports of such activity, while in contrast
reports of accidental rogue RAs are very commonplace.   In writing this
text we came to the conclusion that the issue of malicious attack, due
to the other complementary attacks that are likely to be launched using
rogue NA and similar messages, are best considered elsewhere.   As a 
result, this text intends to provide informational guidance for operators
looking for practical measures to take to avoid unintended rogue RAs
on their own networks.
	</t>
	</section>

</section>

<section title="Methods to Mitigate against Rogue RAs">

	<t>
In this section we present a summary of methods suggested to date
for reducing or removing the possibility of rogue RAs being seen on
a network.
	</t>

	<section title="Manual configuration">
	<t>
The default gateway and host address can usually be manually configured on 
a node.
This is of course can be a resource intensive solution, and also prone to
administrative mistakes in itself.   
	</t>
	<t>
Manual configuration implies that RA processing is disabled.
Most operating systems allow RA messages to be ignored, such that if
an IPv6 address is manually configured on a system, an additional 
global autoconfigured address will not be added should an unexpected
RA appear on the link.   
	</t>
	</section>

	<section title="Introduce RA snooping">
	<t>
It should be possible to implement 'RA snooping' in Layer 2 switches in
a similar way to DHCP snooping, such that RAs observed from incorrect
sources are blocked or dropped, and not propagated through a subnet.
One candidate solution in this space called RA-Guard
<xref target="I-D.ietf-v6ops-ra-guard"/> has been proposed.
This type of solution has appeal because it is a familiar model for
enterprise network managers, but it can also be used to complement SeND,
by a switch acting as a SeND proxy for hosts.
	</t>
	<t>
This type of solution may not be applicable everywhere, e.g. in environments
where there are not centrally controlled or manageable switches.
	</t>
	</section>

	<section title="Use ACLs on Managed Switches">
	<t>
Certain switch platforms can already implement some level of rogue
RA filtering by the
administrator configuring Access Control Lists (ACLs) that block RA ICMP
messages that might be inbound on 'user' ports.    Again this type
of 'solution' depends on the presence of such configurable switches.
	</t>
	<t>
A recent draft describes the RA message format(s) for filtering
<xref target="I-D.nward-ipv6-autoconfig-filtering-ethernet"/>.  This
draft also notes requirements for DHCPv6 snooping, which can then
be implemented similar to DHCPv4 snooping.
	</t>
	</section>

	<section title="Secure Neighbor Discovery (SeND)">
	<t>
The Secure Neighbor Discovery (SeND) 
<xref target="RFC3971"/> protocol provides a method for
hosts and routers to perform secure Neighbor Discovery.   
Thus it can in principle protect a network against rogue RAs.
	</t>
	<t>
SeND is not yet widely used at the time of writing, in part because
there are very few implementations of the protocol.  Some other
deployment issues have been raised, though these are likely to
be resolved in due course.   For example, routers probably don't
want to use autogenerated addresses (which might need to be
protected by ACLs) so SeND needs to be shown to work with non
autogenerated addresses.   Also, it has been argued that there 
are 'bootstrapping' issues, in that hosts wanting to validate
router credentials (e.g. to a certificate server or NTP server)
are likely to need to communicate via the router for that
information.   
	</t>
	<t>
Further, it's not wholly clear how widely adopted SeND could or
would be in site networks with 'lightweight' security (e.g. many
campus networks), especially where hosts are managed by users
and not administratively.  Public or conference wireless networks
may face similar challenges.   There may also be networks, like
perhaps sensor networks, where use of SeND is less practical.
These networks still require rogue RA protection.
	</t>
	<t>
While SeND clearly can provide a good, longer term solution, 
especially in networks where malicious activity is a significant
concern, there is a requirement today for practical solutions, 
and/or solutions more readily applicable in more 'relaxed' 
environments.  In the latter case, solutions like 'RA snooping'
or applied ACLs are more attractive now.
	</t>
	</section>

	<section title="Router Preference Option">
	<t>
<xref target="RFC4191"/> introduced a router preference
option, such that an RA could carry one of three router preference
values: High, Medium (default) or Low.   Thus an administrator could
use High settings for managed RAs, and hope that 'accidental' RAs
would be medium priority.   This of course would only work in some
scenarios - if the user who accidentally sends out a rogue RA on
the network has configured their device with High precedence for
their own intended usage, the priorities would clash.   But for
accidental problems like Windows ICS and 6to4, it could be useful.
Obviously this solution would also rely on clients (and routers)
having implementations of the protocol.   
	</t>
	</section>

	<section title="Rely on Layer 2 admission control">
	<t>
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
send or receive IPv6 traffic.    Ideally authentication would be
mutual.   Deployment of 802.1x, with mutual authentication, may
however be seen as somewhat 'heavyweight' akin to SeND, for some
deployments.
	</t>
	<t>
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 misconfiguration issues.  A user can happily authenticate
and still launch a Windows ICS service for example.
	</t>
	</section>

	<section title="Use host-based packet filters">
	<t>
In a managed environment hosts could be configured via their 'personal
firewall' to only accept RAs from trusted sources.    
Hosts could also potentially be configured to discard 6to4-based RAs in
a managed enterprise environment.
	</t>
	<t>
However, the
problem is then pushed to keeping this configuration maintained and
correct.   If a router fails and is replaced, possibly with a new Layer 2
interface address, the link local source address in the filter may become
incorrect and thus no method would be available to push the new 
information to the host over the network.
	</t>
	</section>

	<section title="Use an 'intelligent' deprecation tool">
	<t>
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
with 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 meetings with
some success.    A slightly enhanced tool called RAMOND has since been developed 
from this code, and is now available as a Sourceforge project.   
As with host based firewalling, the daemon would need to somehow
know what 'good' and 'bad' RAs are, from some combination of known good
sources and/or link prefixes.   In an environment with native IPv6 though,
6to4-based RAs would certainly be known to be rogue.
	</t>
	<t>
Whether or not use of such a tool is the preferred method,
monitoring a link for observed RAs seems prudent from a network management
perspective.   Some such tools exist already, e.g. NDPMon, which can also
detect other undesirable behaviour.
	</t>
	</section>

	<section title="Wait before using new advertisements">
	<t>
It might be possible, in networks where configurations are very static
and systems generally remain up, to configure an option
such that any new RAs that are seen are not acted upon for a certain
period, e.g. 2 hours.   This might allow time for a misconfiguration or
accidental RA to be detected and stopped, before hosts use the data in
the RA.   Of course this would add delays where genuine new RAs are required,
while new hosts appearing on a network would still be vulnerable (or be
unable to configure at all).   In general, this does not seem to be
an attractive solution.
	</t>
	</section>

	<section title="Use Layer 2 Partitioning">
	<t>
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
broadband networks RFC1483 bridging 
<xref target="RFC1483"/> may be available, for example.
The benefit may be scenario-specific, e.g. whether a given user or
customer has their own network prefix or whether the provisioning is
in a shared subnet or link.   It is certainly desirable that any given
user or customer's system(s) are unable to see RAs that may be generated
by other users or customers.   
	</t>
	<t>
However, such partitioning would probably increase
address space consumption significantly if applied in enterprise networks,
and in many cases hardware costs and software licensing costs to enable
routing to the edge can be quite significant.
	</t>
	</section>

	<section title="Add Default Gateway/Prefix Options to DHCPv6">
	<t>
Adding Default Gateway and Prefix options
for DHCPv6 would allow network administrators to configure
hosts to only use DHCPv6
for default gateway and prefix configuration in managed networks,
where RAs would be required today.
A new draft has proposed such a default router option, along
with prefix advertisement options for DHCPv6
<xref target="I-D.droms-dhc-dhcpv6-default-router"/>.
Even with such options added to DHCPv6, an 
RA is in principle  still required to inform hosts to use DHCPv6.
	</t>
	<t>
An advantage of DHCPv6 is that should an error be introduced, only
hosts that have refreshed their DHCP information since that time are
affected, while a multicast rogue RA will most likely affect all hosts 
immediately.   DHCPv6 also allows different answers to be given to
different hosts.
	</t>
	<t>
While making host configuration possible via DHCPv6 alone is
possible, making IPv6 configuration able to be done in a similar
way to IPv4 today, the problem has only been shifted.   Rather
than rogue RAs being the problem, rogue DHCPv6 servers would
be an equivalent issue.   As with IPv4, a network would then
still require use of Authenticated DHCP, or DHCP(v6) snooping,
as suggested in
<xref target="I-D.nward-ipv6-autoconfig-filtering-ethernet"/>. 
	</t>
	<t>
There is certainly some demand in the community for DHCPv6-only
host configuration.   While this may mitigate the rogue RA issue,
it simply moves the trust problem elsewhere, albeit to a place
administrators are familiar with today.
	</t>
	</section>

</section>

<section title="Scenarios and mitigations">
	<t>
In this section we summarise the scenarios and practical
mitigations described
above in a summary matrix.   We consider, for the case of a rogue 
multicast RA, which of the mitigation methods protects against each
cause.   For the administrator error, we discount an error in
configuring the countermeasure itself, rather we consider an
administrator error to be an error in configuration elsewhere
in the network.
	</t>

	<t>
	<artwork>
     +------------------------+-------------+-------------+
     |              Scenario  |   Admin     |   User      |
     | Mitigation             |   Error     |   Error     |
     +------------------------+-------------+-------------+
     | Manual configuration   |     Y       |      Y      |
     +------------------------+-------------+-------------+
     | SeND                   |     Y       |      Y      |
     +------------------------+-------------+-------------+
     | RA snooping            |     Y       |      Y      |
     +------------------------+-------------+-------------+
     | Use switch ACLs        |     Y       |      Y      |
     +------------------------+-------------+-------------+
     | Router preference      |     N       |      Y      |
     +------------------------+-------------+-------------+
     | Layer 2 admission      |     N       |      N      |
     +------------------------+-------------+-------------+
     | Host firewall          |     Y       |      Y      |
     +------------------------+-------------+-------------+
     | Deprecation daemon     |     Y       |      Y      |
     +------------------------+-------------+-------------+
     | New prefix delay       |   Partly    |   Partly    |
     +------------------------+-------------+-------------+
     | Layer 2 partition      |     N       |      Y      |
     +------------------------+-------------+-------------+
     | DHCPv6 gateway option  |   Partly    |  If Auth    |
     +------------------------+-------------+-------------+
	</artwork>
	</t>
	<t>
What the above summary does not consider is the practicality
of deploying the measure.   An easy-to-deploy method that buys 
improved resilience to rogue RAs without significant administrative
overhead is attractive.   On that basis the RA snooping proposal,
e.g. RA Guard, has merit, while approaches like manual configuration
are less appealing.   However RA Guard is not
yet fully defined or available, while only certain managed switch
equipment may support the required ACLs.
	</t>

</section>

<section title="Other related considerations">

	<t>
There are a number of related issues that have come out of discussions
on the rogue RA topic, which the authors believe are worth capturing in
this document.
	</t>

	<section title="Unicast RAs">
	<t>
The above discussion was initially held on the assumption that rogue
multicast RAs were the cause of problems on a shared network subnet.
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
host sending rogues RAs sends them unicast to the soliciting host,
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 likely to be multicast.
	</t>
	</section>

	<section title="The DHCP vs RA threat model">
	<t>
Comparing the threat model
for rogue RAs and rogue DHCPv6 servers is 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 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, 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 rogue RAs however, the impact is potentially
immediate to all hosts, while the rogue DHCP server's impact will depend
on lease timers for hosts.
	</t>
	<t>
In principle Authenticated DHCP can be used to protect against rogue
DHCPv4 (and DHCPv6) servers, just as SeND could be used to protect 
against rogue IPv6 RAs.    However, actual use of Authenticated DHCP in
typical networks is currently minimal.
Were new DHCPv6 default gateway and prefix options to be standardised 
as described above,
then without Authenticated DHCP the (lack of) security is just pushed to 
another place.
	</t>
	<t>
The RA Guard approach is essentially using a similar model to DHCP message
snooping to protect against rogue RAs in network (switch) equipment. 
As noted above,  DHCPv6 message snooping would also be very
desirable in IPv6 networks.
	</t>
	</section>

	<section title="IPv4-only networks">
	<t>
The rogue RA problem should also be considered by administrators and
operators of IPv4-only networks, where IPv6 monitoring, firewalling and
other related mechanisms may not be in place.
	</t>
	<t>
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 with IPv6, some
OSes or applications may begin using IPv6 to the 6to4 host (router)
rather than IPv4 to the intended default IPv4 router, because they have
IPv6 enabled by default and some applications prefer IPv6 by default.   
Technically aware users may also deliberately choose to use IPv6, possibly
for subversive reasons.
Mitigating against this condition can also be seen to be important.
	</t>
	</section>

	<section title="Network monitoring tools">
	<t>
It would generally be prudent for network monitoring or
management platforms to be able to observe and report on observed RAs,
and whether unintended RAs (possibly from unintended sources) are
present on a network.    Further, it may be useful for individual
hosts to be able to report their address status (assuming their configuration
status allowed it of course), e.g. this could be
useful during an IPv6 renumbering phased process as described in
<xref target="RFC4192">RFC4192</xref>.
	</t>
	<t>
The above assumes, of course, that what defines a 'good' (or 'bad')
RA can be configured in a trustworthy manner within the network's
management framework.
	</t>
	</section>

	<section title="Recovering from bad configuration state">
	<t>
After a host receives and processes a rogue RA, it may have multiple
default gateways, global addresses, and potentially clashing RA options
(e.g. M/O bits).   The host's behaviour may then be unpredictable, in
terms of the default router that is used, and the (source) address(es)
used in communications.   A host that is aware of protocols such as
shim6 may believe it is genuinely multihomed.   
	</t>
	<t>
An important issue is how readily a host can recover from 
receiving and processing bad configuration
information, e.g. considering the '2 hour rule' of Section 5.5.3 of
RFC4862 (though this applies to the valid address lifetime not the router
lifetime).   We should ensure that methods exist for a network
administrator to correct bad configuration information on a link or
subnet, and that OS platforms support these methods.    At least if the
problem can be detected, and corrected promptly, the impact is
minimised.
	</t>
	</section>

	<section title="Isolating the offending rogue RA source">
	<t>
	In addition to issuing a deprecating RA, it would be desirable 
to isolate the offending source of the rogue RA from the network.
It may be possible to use Network Access Control methods to quarantine
the offending host, or rather the network point of attachment or
port that it is using.
	</t>
	</section>

</section>

<section anchor="Conclusions" title="Conclusions">
	<t>
In this text we have described scenarios via which rogue Router Advertisements
(RAs) may appear on a network, and some measures that could be used
to mitigate against these.   We have also noted some related issues
that have arisen in the rogue RA discussions.  Our discussion is generally
focused on the assumption that rogue RAs are appearing as a result of
accidental misconfiguration on the network, by a user or administrator.
	</t>
	<t>
While SeND perhaps offers the most robust solution, implementations and
deployment guidelines are not yet widely available.   SeND is very likely
to be a good, longer term solution, but many administrators are seeking
solutions today.   Such administrators are also often in networks with
security models for which SeND is a 'heavyweight' solution, e.g. campus 
networks, or wireless conference or public networks.   For such
scenarios, simpler measures are desirable.
	</t>
	<t>
Adding new DHCPv6 Default Gateway and Prefix Options 
would allow IPv6 host configuration by
DHCP only, and be a method that IPv4 administrators are comfortable with
(for better or worse), but this simply shifts the robustness issue elsewhere.
	</t>
	<t>
While a number of the mitigations described above have their appeal, the
simplest solutions probably lie in switch-based ACLs and RA-Guard style
approaches.   Where managed switches are no available, use of the Router
Preference option and (moreso in managed desktop environments) host 
firewalls may be appropriate.
	</t>
	<t>
In the longer term wider experience of SeND will be beneficial, while the
use of RA snooping will remain useful either to complement SeND (where a
switch running RA Guard can potentially be a SeND proxy) or to assist 
in scenarios for which SeND is not deployed.
	</t>

</section>

<section anchor="Security" title="Security Considerations">
	<t>
This document is Informational.  It does not describe solutions for
malicious attacks on a network for which malicious RAs may be part of
a broader attack, e.g. including malicious NA messages.
	</t>
</section>

<section anchor="IANA" title="IANA Considerations">
	<t>
There are no extra IANA consideration for this document.
	</t>
</section>

<section anchor="Acknowledgments" title="Acknowledgments">
	<t>
Thanks are due to members of the IETF IPv6 Operations and DHCP WGs for their
inputs on this topic, as well as some comments from various operational 
mailing lists, and private comments, including but not limited to:
Iljitsch van Beijnum,
Dale Carder,
Remi Denis-Courmont,
Tony Hain,
Bob Hinden,
Christian Huitema,
Tatuya Jinmei,
Eric Levy-Abegnoli,
David Malone,
Thomas Narten,
Chip Popoviciu,
Dave Thaler,
Gunter Van de Velde,
Göran Weinholt and
Dan White.  
	</t>
</section>


</middle>
<back>

<references title="Informative References">

	&rfc1483;
	&rfc3056;
	&rfc3315;
	&rfc3736;
	&rfc3971;
	&rfc4191;
	&rfc4192;
	&rfc4861;
	&rfc4862;
	&I-D.ietf-v6ops-ra-guard;
	&I-D.nward-ipv6-autoconfig-filtering-ethernet;
	&I-D.droms-dhc-dhcpv6-default-router;

</references>
	</back>
</rfc>