RFC 6104
Rogue IPv6 Router Advertisement Problem Statement
RFC 6104: Rogue IPv6 Router Advertisement Problem Statement 💖
okay bestie, the title block first 🎀
- Authors: T. Chown (University of Southampton) and S. Venaas (Cisco Systems)
- Category: Informational 🦋 (published for information, not as a Standards Track spec)
- Date: February 2011
- ISSN: 2070-1721
- Obsoletes / Updates: the header doesn't list any RFCs that it obsoletes or updates ✨
Abstract 🌸
okay so when you roll out IPv6, whether it's IPv6-only or dual-stack, routers get set up to send IPv6 Router Advertisements (RAs). These tell nodes how to autoconfigure on the network 💅. The info includes the default router address (taken from the RA's observed source address) and on-link prefix info. But unintended misconfigurations by users or admins, or possibly malicious attacks, can cause bogus RAs to show up, and those can cause operational problems for hosts ngl 😭.
This doc covers the scenarios where rogue RAs get seen, and it lists possible solutions. We focus on the unintended causes of rogue RAs. The goal is to be Informational, so it's basically a framework for proposing and discussing solutions 🧚.
Status of This Memo 🎀
This document is not an Internet Standards Track specification. It's published for informational purposes only 🦋.
It's a product of the Internet Engineering Task Force (IETF) and represents the consensus of the IETF community. It got public review and was approved for publication by the Internet Engineering Steering Group (IESG). Not every IESG-approved doc is a candidate for any level of Internet Standard, so check Section 2 of RFC 5741 if you're curious 💜.
For the current status, any errata, and how to give feedback, go to http://www.rfc-editor.org/info/rfc6104 🔗.
Copyright Notice 💅
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved ✨.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info), as in effect on the date of publication. Please read these carefully because they describe your rights and restrictions. Code Components pulled out of this document must include the Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions, and they come without warranty, as the Simplified BSD License describes 📜.
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The people controlling the copyright in some of that material may not have granted the IETF Trust the right to allow modifications outside the IETF Standards Process. So unless you get an adequate license from those copyright holders, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside that process. The exceptions are formatting it for publication as an RFC or translating it into languages other than English 🌈.
Table of Contents 🧚
1. Introduction ....................................................4
2. Bogus RA Scenarios ..............................................4
2.1. Administrator Misconfiguration .............................5
2.2. User Misconfiguration ......................................5
2.3. Malicious Misconfiguration .................................5
3. Methods to Mitigate against Rogue RAs ...........................6
3.1. Manual Configuration .......................................6
3.2. Introducing RA Snooping ....................................6
3.3. Using ACLs on Managed Switches .............................7
3.4. SEcure Neighbor Discovery (SEND) ...........................7
3.5. Router Preference Option ...................................8
3.6. Relying on Layer 2 Admission Control .......................8
3.7. Using Host-Based Packet Filters ............................8
3.8. Using an "Intelligent" Deprecation Tool ....................8
3.9. Using Layer 2 Partitioning .................................9
3.10. Adding Default Gateway/Prefix Options to DHCPv6 ...........9
4. Scenarios and Mitigations ......................................10
5. Other Related Considerations ...................................11
5.1. Unicast RAs ...............................................11
5.2. The DHCP versus RA Threat Model ...........................11
5.3. IPv4-Only Networks ........................................12
5.4. Network Monitoring Tools ..................................12
5.5. Recovering from Bad Configuration State ...................12
5.6. Isolating the Offending Rogue RA Source ...................13
6. Conclusions ....................................................13
7. Security Considerations ........................................14
8. Acknowledgments ................................................14
9. Informative References .........................................151. Introduction ✨
The Neighbor Discovery protocol [RFC4861] describes how IPv6 Router Advertisements (RAs) work. RAs are used to figure out node configuration during IPv6 autoconfiguration, whether the node is stateful, using the Dynamic Host Configuration Protocol for IPv6 (DHCPv6) [RFC3315], or stateless, as described in [RFC4862], maybe combined with DHCPv6 Light [RFC3736] 🦋.
When people watch deployed IPv6 networks, they notice a problem: undesired or "bogus" IPv6 RAs show up on network links or subnets 👀. By "bogus" we mean RAs that weren't the intended, configured RAs, but that appeared for some other reason. The problem seems more common on shared wireless setups, but it also shows up on wired enterprise networks 📶.
Rogue RAs are a big deal because they can cause partial or complete failure of hosts on an IPv6 link 😭. For example, the default router address comes straight from the source address of the RA message. Rogue RAs can also make hosts use the wrong prefixes for stateless address autoconfiguration. If you have a mix of "good" and "bad" RAs, a host might keep using the "good" default gateway but pick a wrong source address, which leads to egress filtering problems 💀. So rogue RAs are an operational issue that needs solutions, and best practice needs to be shared. That means preventing or detecting rogue RAs, and also, where needed, making sure the network and its hosts can quickly recover from a state where host configuration went wrong because they processed such an RA 🔥.
Next up, we talk about the scenarios where rogue RAs can show up. After that, we present some candidate solutions, and some are more practical to deploy than others 💖. This document focuses on "accidental" rogue RAs. Malicious RAs are possible too, of course, but the common problem today is the unintended ones 🙈. Also, a network under this kind of malicious attack is likely to see malicious Neighbor Advertisement (NA) and related messages too.
2. Bogus RA Scenarios 🍓
There are three broad classes of scenario where bogus RAs can get introduced to an IPv6 network 🧚.
2.1. Administrator Misconfiguration 🛠️
Here, an administrator incorrectly configures RAs on a router interface. That causes incorrect RAs to show up on links and makes hosts generate incorrect or unintended IPv6 address, gateway, or other info. In this case the default gateway might be correct, but a host could end up multiaddressed, with a correct address and an incorrect one based on a correct and an incorrect prefix 🙃. Other config info could also be misconfigured, like the lifetime option ⏳.
With a Layer 2 IEEE 802.1Q Virtual LAN (VLAN) misconfiguration, RAs can "flood" onto unintended links 🌊. That can make hosts, or hosts on more than one link, end up incorrectly multiaddressed, possibly with two different default routers available 👑.
2.2. User Misconfiguration 🙋♀️
In this case, a user's device "accidentally" sends RAs onto the local link. That could add an extra default gateway and its prefix info 💅.
This seems to happen mostly on wireless (though sometimes wired) networks, where a laptop has turned on the Windows Internet Connection Sharing (ICS) service. ICS can turn a host into a 6to4 [RFC3056] gateway. That can be a useful feature, unless it's running when it isn't meant to be 🙈. The service can also cause IPv4 problems, because it typically starts a "rogue" DHCPv4 server on the host 😬.
We've also had reports that hosts may not see genuine IPv6 RAs on a link because of host firewalls. That makes them turn on a connection-sharing service and 6to4 as a result 🔥. In some cases, more technical users might also use a laptop as a home gateway (again, a 6to4 gateway) and then connect to another network, forgetting their previous gateway configuration is still active 💀.
There are also reported incidents in enterprise networks where users plugged Ethernet cables into the wrong sockets and bridged two subnets together. That causes a problem similar to VLAN flooding 🌈.
2.3. Malicious Misconfiguration 😈
Here, an attacker deliberately generates RAs on the local network to try some kind of denial-of-service or man-in-the-middle attack ⚠️.
As mentioned above, while this is a genuine concern for network administrators, there have been few if any reports of this activity. Meanwhile, reports of accidental rogue RAs are super common 📈. When writing this text, and with feedback from the v6ops working group, we concluded that malicious attacks are best considered in further work and document(s). That's because they're likely to come along with other complementary attacks using rogue NA and similar messages. So this text is meant to give informational guidance for operators who want practical measures to avoid "accidental" rogue RAs on their own networks 🦋.
3. Methods to Mitigate against Rogue RAs 🛡️
In this section, we summarize the methods suggested so far for reducing or removing the chance of rogue RAs showing up on a network 💖.
3.1. Manual Configuration ✍️
The default gateway and host address can usually be configured manually on a node. Of course, this can be a resource-intensive solution, and it's also prone to administrative mistakes on its own 😅.
Manual configuration implies that RA processing is disabled. Most operating systems let RA messages be ignored, so if an IPv6 address is manually configured on a system, an extra globally autoconfigured address won't be added if an unexpected RA shows up on the link 🫶.
3.2. Introducing RA Snooping ✨
okay so bestie, imagine switches doing RA snooping, the same way they already do DHCP snooping 🫶 The idea is that RAs seen coming from the wrong sources get blocked or dropped, so they never spread across the subnet 🚫 One candidate in this space is called "RA-Guard" [RFC6105]. Enterprise network managers are obsessed with this model because it's super familiar to them 💅 It can also work alongside SEcure Neighbor Discovery (SEND) [RFC3971], with a switch acting as a SEND proxy for hosts. Iconic teamwork 🤝
Not every network can do this though 🥺 It may not be applicable everywhere, for example in environments where the switches aren't centrally controlled or manageable.
3.3. Using ACLs on Managed Switches 🛡️
some switch platforms can already do a bit of rogue RA filtering. The administrator sets up Access Control Lists (ACLs) that block RA ICMP messages that might show up inbound on "user" ports 🙈 Again, this kind of "solution" depends on having those configurable switches around, so it's not a universal fix.
A recent document describes the RA message format(s) for filtering [IPv6-AUTOCFG-FILTER]. It also notes requirements for DHCPv6 snooping, which can then be implemented similarly to DHCPv4 snooping 🌸
3.4. SEcure Neighbor Discovery (SEND) 🔐
The SEcure Neighbor Discovery (SEND) [RFC3971] protocol gives hosts and routers a way to perform secure Neighbor Discovery. So in principle, it can protect a network against rogue RAs 🦋
Okay but SEND isn't widely used yet at the time of writing 😭 Part of the reason is that there are very few implementations of the protocol. There are some other deployment issues too, though these are likely to get sorted out 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. There's also the "bootstrapping" problem: hosts that want to validate router credentials (e.g., to a certificate server or Network Time Protocol (NTP) server) are likely to need to talk to that information via the router first. Chicken, meet egg 🐔🥚
Then there's the question of how widely SEND could or would be adopted 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. Some networks, like perhaps sensor networks, might find SEND less practical. These networks still require rogue RA protection, though 💜
SEND can clearly be a good, longer-term solution, especially in networks where malicious activity is a significant concern ✨ But there's a need for practical solutions today, and/or solutions that are more readily applicable in more "relaxed" environments. In that latter case, solutions like "RA snooping" or applied ACLs are more attractive right now 🍓
3.5. Router Preference Option 👑
[RFC4191] introduced a Router Preference option, so an RA could carry one of three Router Preference values: High, Medium (default), or Low. So an administrator could use "High" settings for managed RAs and hope that "accidental" RAs would be medium priority 🤞 Of course, this only works in some scenarios. If the user who accidentally sends out a rogue RA has configured their device with "High" precedence for their own intended usage, the priorities would clash 💀 But for accidental rogue RAs caused by software like Windows ICS and 6to4, which would use the default precedence, it could be useful. Obviously this solution also relies on clients (and routers) having implementations of the Router Preference option.
3.6. Relying on Layer 2 Admission Control 🚪
In principle, if a technology such as IEEE 802.1x is used, devices would first need to authenticate to the network before they could send or receive IPv6 traffic. Ideally, authentication would be mutual 🤝 Deploying 802.1x with mutual authentication may, however, be seen as somewhat "heavyweight," akin to SEND, for some deployments.
Improving Layer 2 security may help mitigate an attacker's ability 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 🙃
3.7. Using Host-Based Packet Filters 🧱
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 🧚
However, the problem then gets 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 then no method would be available to push the new information to the host over the network 😱
3.8. Using an "Intelligent" Deprecation Tool 🧠
It's possible to run a daemon on a link (perhaps on the router on the link) to watch for incorrect RAs. When one is observed, the daemon sends a deprecating RA with a router lifetime of zero ⏳ The KAME rafixd is an example of such a tool, and it has been used at IETF meetings with some success 🎀 A slightly enhanced tool called RAMOND has since been developed from this code, and it's 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 🚩
Whether or not this tool is the preferred method, monitoring a link for observed RAs seems prudent from a network management perspective 👀 Some such tools already exist, e.g., NDPMon, which can also detect other undesirable behaviour.
3.9. Using Layer 2 Partitioning 🏠
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, bridging [RFC2684] 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 happens in a shared subnet or link. It is certainly desirable that any given user's or customer's system(s) are unable to see RAs that may be generated by other users or customers 💖
However, such partitioning would probably increase address space consumption significantly if applied in enterprise networks. In many cases, the hardware costs and software licensing costs to enable routing to the edge can be quite significant 💸
3.10. Adding Default Gateway/Prefix Options to DHCPv6 📦
Adding Default Gateway and Prefix options for DHCPv6 would let network administrators configure hosts to use DHCPv6 only for default gateway and prefix configuration in managed networks, where RAs would be required today. A new document has proposed such a default router option, along with prefix advertisement options for DHCPv6 [DHCPv6-DEFAULT-RTR]. Even with those options added to DHCPv6, an RA is in principle still required to inform hosts to use DHCPv6 🙄
An advantage of DHCPv6 is that if an error gets introduced, only hosts that have refreshed their DHCP information since that time are affected. A multicast rogue RA, on the other hand, will most likely affect all hosts immediately ⚡ DHCPv6 also allows different answers to be given to different hosts 🫶
Making host configuration possible via DHCPv6 alone is a viable option, and it would let IPv6 configuration be done in a way similar to IPv4 today. But 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 Authenticated DHCP, or DHCP(v6) snooping, as suggested in [IPv6-AUTOCFG-FILTER].
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 already familiar with 🥰
4. Scenarios and Mitigations 📊
In this section, we summarise the error and misconfiguration scenarios, and the practical mitigation methods described above, in a matrix format 💅 For the case of a rogue multicast RA, we consider which of the mitigation methods helps protect against administrator and user errors. For the administrator error, we discount an error in configuring the countermeasure itself. Instead, we consider an administrator error to be an error in configuration elsewhere in the network 🧐
+------------------------+---------------------------+
| | Scenario |
| Mitigation |---------------------------|
| Method | Admin Error | User 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 |
+------------------------+-------------+-------------+
| Layer 2 partition | N | Y |
+------------------------+-------------+-------------+
| DHCPv6 gateway option | Partly | If Auth |
+------------------------+-------------+-------------+What the above summary does not consider is how practical the measure is to deploy. 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, and only certain managed switch equipment may support the required ACLs 🥲
5. Other Related Considerations 🌟
There are a number of related issues that came out of discussions on the rogue RA topic, which the authors believe are worth capturing in this document 📝
5.1. Unicast RAs 📮
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 RFC 4861. If a 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 a monitoring daemon 👻 In most cases, though, an accidental rogue RA is likely to be multicast 💁♀️
5.2. The DHCP versus RA Threat Model 🎀
Okay, comparing the threat model for rogue RAs and rogue DHCPv6 servers is such a fun puzzle 🧩. When Windows ICS causes rogue 6to4-based RAs to show up on a network, it's very likely the same host is also acting as a rogue IPv4 DHCP server 😭. A rogue DHCPv4 server can hand out a default gateway and an address to hosts, and a rogue RA can make hosts learn about a new (additional) default gateway, prefix(es), and address. The difference is timing 💅: with multicast rogue RAs the impact can hit all hosts pretty much immediately, while a rogue DHCP server's impact depends on the lease timers hosts are running on ⏰.
Authenticated DHCP can protect against rogue DHCPv4 (and DHCPv6) servers, the same way SEND could protect against rogue IPv6 RAs 🔐. The catch is that actual use of Authenticated DHCP in typical networks is currently pretty minimal 🥲. If the new DHCPv6 default gateway and prefix options get standardised like described above, then without Authenticated DHCP the (lack of) security just gets pushed to another place 🙃.
The RA-Guard approach uses a similar model to DHCP message snooping, protecting against rogue RAs inside network (switch) equipment 🛡️. As noted above, DHCPv6 message snooping would also be super desirable in IPv6 networks 🌸.
5.3. IPv4-Only Networks 🌈
The rogue RA problem matters for admins and operators of IPv4-only networks too 👀, especially where IPv6 monitoring, firewalling, and other related mechanisms might not be set up at all.
Here's a comment someone made that's kinda spooky 👻: say 6to4 is being run by a host on a subnet that isn't administratively configured with IPv6. Some OSes or apps might start using IPv6 to reach the 6to4 host (router) instead of IPv4 to the intended default IPv4 router, because they have IPv6 enabled by default, and some apps prefer IPv6 by default 🫣. Technically aware users might even choose IPv6 on purpose, possibly for subversive reasons 😈. Mitigating this condition is important too 💜.
5.4. Network Monitoring Tools 🔍
It's generally a smart move for network monitoring or management platforms to be able to observe and report on RAs they see, and whether unintended RAs (possibly from unintended sources) are on the network 🕵️♀️. It could also be useful for individual hosts to report their address status (assuming their configuration status allows it, obviously 🙄). For example, this could be really useful during a phased IPv6 renumbering process, as described in RFC 4192 [RFC4192] 🦋.
All of this assumes, of course, that what defines a "good" (or "bad") RA can be configured in a trustworthy way within the network's management framework 🫶.
5.5. Recovering from Bad Configuration State 🧹
After a host receives and processes a rogue RA, it might end up with multiple default gateways, global addresses, and potentially clashing RA options (e.g., M/O bits [RFC4861]) 😵💫. Its behaviour can then get really unpredictable, both in terms of which default router it uses and which (source) address(es) it uses in communications 🌀. A host that knows about protocols like Shim6 [RFC5533] might even think it's genuinely multihomed 🤡.
Here's the big question ❗: how quickly can a host recover from receiving and processing bad configuration information? Think about the "2 hour rule" mentioned in Section 5.5.3 of RFC 4862 (though this applies to the valid address lifetime and not the router lifetime) ⏳. We need to make sure there are ways for a network administrator to correct bad configuration information on a link or subnet, and that OS platforms actually support those methods 🛠️. At the very least, if the problem can be detected and corrected promptly, the impact gets minimised 💖.
5.6. Isolating the Offending Rogue RA Source 🚫
On top of issuing a deprecating RA, it would be super 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, more precisely, the network point of attachment or port that it's using 🔌.
6. Conclusions ✨
So in this text we've described the scenarios where rogue Router Advertisements (RAs) can show up on a network, plus some measures that could help mitigate them 🧐. We also noted some related issues that came up in the rogue RA discussions 💬. Our discussion is mostly focused on the assumption that rogue RAs are appearing because of accidental misconfiguration on the network, by a user or administrator 🥰.
SEND might honestly offer the most robust solution 👑, but implementations and deployment guidelines aren't widely available yet 😩. It's very likely to be a good longer-term solution, but lots of administrators are looking for solutions today 🏃♀️. Those admins are often in networks with security models where SEND is a "heavyweight" solution, like campus networks, or wireless conference or public networks 🏫. For those scenarios, simpler measures are the way to go 💅.
Adding new DHCPv6 Default Gateway and Prefix options would let IPv6 host configuration happen by DHCP only 📬. It's a method IPv4 admins are comfortable with (for better or worse 🙈), but it just shifts the robustness issue somewhere else 🫠.
Even though a bunch of the mitigations above have their appeal 💜, the simplest solutions probably live in switch-based ACLs and RA-Guard-style approaches 🏆. Where managed switches aren't available, the Router Preference option and (even more so in managed desktop environments) host firewalls might be appropriate 🔥.
Long term, wider experience with SEND will be beneficial 🌟. Meanwhile, RA snooping will stay useful, either to complement SEND (where a switch running RA-Guard can potentially act as a SEND proxy) or to help in scenarios where SEND isn't deployed 🦄.
7. Security Considerations 🔐
Okay, bestie, this part is serious 😤. This Informational document is focused on discussing solutions to operational problems caused by rogue RAs that come from unintended misconfiguration by users or administrators ⚠️. Earlier versions of this text included some analysis of rogue RAs introduced maliciously; for example, the text had an extra column in the matrix in Section 4 📊. However, the consensus of the v6ops working group feedback was to instead focus on the common operational problem of "accidental" rogue RAs seen today 🙌.
So the final version of this text does not address attacks on a network where rogue RAs are intentionally introduced as part of a broader attack, for example, one that includes malicious NA messages 🚨. On the wire, malicious rogue RAs will generally look the same as "accidental" ones 🫣. They're more likely, though, to spoof the Media Access Control (MAC) or IPv6 source address of the genuine router, or to use a "High" Router Preference option 🕵️. It's also likely that malicious rogue RAs will come with other attacks on the IPv6 infrastructure, which makes mitigations way more complicated 😵. Admins may be able to detect this kind of activity with tools like NDPMon 🔎.
And one more thing 🧨: the deprecation daemon could itself be used as part of a denial-of-service attack, if somebody used the tool to deprecate the genuine RA 💀.
8. Acknowledgments 🫶
Huge thanks to members of the IETF IPv6 Operations and DHCP working groups for their inputs on this topic 🥹. Thanks also to everyone who sent comments from various operational mailing lists and private comments, including but not limited to these legends 👑:
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,
Goeran Weinholt, and Dan White.9. Informative References 📚
[RFC2684] Grossman, D. and J. Heinanen, "Multiprotocol Encapsulation
over ATM Adaptation Layer 5", RFC 2684, September 1999.
[RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains
via IPv4 Clouds", RFC 3056, February 2001.
[RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C.,
and M. Carney, "Dynamic Host Configuration Protocol for
IPv6 (DHCPv6)", RFC 3315, July 2003.
[RFC3736] Droms, R., "Stateless Dynamic Host Configuration Protocol
(DHCP) Service for IPv6", RFC 3736, April 2004.
[RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure
Neighbor Discovery (SEND)", RFC 3971, March 2005.
[RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and
More-Specific Routes", RFC 4191, November 2005.
[RFC4192] Baker, F., Lear, E., and R. Droms, "Procedures for
Renumbering an IPv6 Network without a Flag Day", RFC 4192,
September 2005.
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
"Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
September 2007.
[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
Address Autoconfiguration", RFC 4862, September 2007.
[RFC5533] Nordmark, E. and M. Bagnulo, "Shim6: Level 3 Multihoming
Shim Protocol for IPv6", RFC 5533, June 2009.
[RFC6105] Levy-Abegnoli, E., Van de Velde, G., Popoviciu, C., and J.
Mohacsi, "IPv6 Router Advertisement Guard", RFC 6105,
February 2011.
[IPv6-AUTOCFG-FILTER]
Ward, N., "IPv6 Autoconfig Filtering on Ethernet
Switches", Work in Progress, March 2009.
[DHCPv6-DEFAULT-RTR]
Droms, R. and T. Narten, "Default Router and Prefix
Advertisement Options for DHCPv6", Work in Progress,
March 2009.Authors' Addresses 🧑💻
Tim Chown
University of Southampton
Highfield
Southampton, Hampshire SO17 1BJ
United Kingdom
EMail: tjc@ecs.soton.ac.uk
Stig Venaas
Cisco Systems
Tasman Drive
San Jose, CA 95134
USA
EMail: stig@cisco.com📦 where this page comes from
- ietf: rfc6104 2011-02
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms