idnits 2.17.1 draft-chown-v6ops-rogue-ra-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 555. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 566. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 573. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 579. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (November 3, 2008) is 5624 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Obsolete informational reference (is this intentional?): RFC 3315 (ref. '2') (Obsoleted by RFC 8415) -- Obsolete informational reference (is this intentional?): RFC 3736 (ref. '3') (Obsoleted by RFC 8415) == Outdated reference: A later version (-08) exists of draft-ietf-v6ops-ra-guard-00 Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IPv6 Operations T. Chown 3 Internet-Draft University of Southampton 4 Intended status: Informational S. Venaas 5 Expires: May 7, 2009 UNINETT 6 November 3, 2008 8 Rogue IPv6 Router Advertisement Problem Statement 9 draft-chown-v6ops-rogue-ra-02 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on May 7, 2009. 36 Copyright Notice 38 Copyright (C) The IETF Trust (2008). 40 Abstract 42 When deploying IPv6, whether IPv6-only or dual-stack, routers are 43 configured to send IPv6 Router Advertisements to convey information 44 to nodes that enable them to autoconfigure on the network. This 45 information includes the implied default router address taken from 46 the observed source address of the Router Advertisement (RA) message. 47 However, unintended misconfigurations or possibly malicious attacks 48 on the network may lead to bogus RAs being present, which in turn can 49 cause operational problems for hosts on the network. In this draft 50 we summarise the scenarios in which rogue RAs may be observed and 51 present a list of possible solutions to the problem. The goal of 52 this text is to be Informational, and as such to present a framework 53 around which solutions can be proposed and discussed. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 2. Bogus RA Scenarios . . . . . . . . . . . . . . . . . . . . . . 3 59 2.1. Administrator misconfiguration . . . . . . . . . . . . . . 3 60 2.2. User misconfiguration . . . . . . . . . . . . . . . . . . 4 61 2.3. Malicious misconfiguration . . . . . . . . . . . . . . . . 4 62 3. Methods to Mitigate against Rogue RAs . . . . . . . . . . . . 4 63 3.1. Manual configuration . . . . . . . . . . . . . . . . . . . 4 64 3.2. Secure Neighbor Discovery . . . . . . . . . . . . . . . . 4 65 3.3. Introduce RA snooping . . . . . . . . . . . . . . . . . . 5 66 3.4. Use ACLs on Managed Switches . . . . . . . . . . . . . . . 5 67 3.5. Use the Router Preference Option . . . . . . . . . . . . . 5 68 3.6. Rely on Layer 2 admission control . . . . . . . . . . . . 5 69 3.7. Use host-based packet filters . . . . . . . . . . . . . . 6 70 3.8. Use an 'intelligent' deprecation tool . . . . . . . . . . 6 71 3.9. Wait before using new advertisements . . . . . . . . . . . 6 72 3.10. Use Layer 2 Partitioning . . . . . . . . . . . . . . . . . 6 73 3.11. Add a Default Gateway Option to DHCPv6 . . . . . . . . . . 7 74 4. Scenarios and mitigations . . . . . . . . . . . . . . . . . . 7 75 5. Other related considerations . . . . . . . . . . . . . . . . . 8 76 5.1. Unicast RAs . . . . . . . . . . . . . . . . . . . . . . . 9 77 5.2. The DHCP vs RA threat model . . . . . . . . . . . . . . . 9 78 5.3. IPv4-only networks . . . . . . . . . . . . . . . . . . . . 9 79 5.4. Network monitoring tools . . . . . . . . . . . . . . . . . 10 80 5.5. Recovering from bad configuration state . . . . . . . . . 10 81 5.6. Behaviour of a node after receiving a rogue RA . . . . . . 10 82 6. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 10 83 7. Security Considerations . . . . . . . . . . . . . . . . . . . 11 84 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 85 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11 86 10. Informative References . . . . . . . . . . . . . . . . . . . . 11 87 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 88 Intellectual Property and Copyright Statements . . . . . . . . . . 13 90 1. Introduction 92 The Neighbor Discovery protocol [7] describes the operation of IPv6 93 Router Advertisements (RAs), which are used during the IPv6 94 autoconfiguration process, whether a node's configuration is stateful 95 (via DHCPv6 [2]) or stateless (as per RFC4862 [8], possibly in 96 combination with DHCPv6 Light [3]). 98 In observing the operation of deployed IPv6 networks, it is apparent 99 that there is a problem with undesired or 'bogus' IPv6 Router 100 Advertisements (RAs) appearing on network links or subnets. By 101 'bogus' we mean RAs that were not the intended configured RAs, rather 102 RAs that have appeared for some other reason. 104 The problem with rogue RAs is that they can cause partial or complete 105 failure of operation of hosts on an IPv6 link. For example, the 106 default router address is drawn directly from the source address of 107 the RA message. As such, rogue RAs are an operational issue for 108 which solution(s) are required, and for which best practice needs to 109 be conveyed. This not only includes preventing or detecting rogue 110 RAs, but also where necessary the ability to quickly recover from a 111 state where host configuration is incorrect as a result of processing 112 such an RA. 114 In the next section, we discuss the scenarios that may give rise to 115 rogue RAs being present. In the following section we present some 116 candidate solutions for the problem, some of which may be more 117 practical to deploy than others. 119 2. Bogus RA Scenarios 121 There are three broad classes of scenario in which bogus RAs may be 122 introduced to an IPv6 network. 124 2.1. Administrator misconfiguration 126 Here an administrator incorrectly configures RAs on a router 127 interface, causing incorrect RAs to appear on links and hosts to 128 generate incorrect or unintended IPv6 address, gateway or other 129 information. In such a case the default gateway may be correct, but 130 a host might for example become multi-addressed, possibly with a 131 correct and incorrect address based on a correct and incorrect 132 prefix. There is also the possibility of other configuration 133 information being misconfigured, such as the lifetime option. 135 In the case of a Layer 2 VLAN misconfiguration, RAs may 'flood' to 136 unintended links, causing hosts or more than one link to potentially 137 become incorrectly multiaddressed, with possibly two different 138 default routers available. 140 2.2. User misconfiguration 142 In this case a user's device 'accidentally' transmits RAs onto the 143 local link, adding an additional default gateway and associated 144 prefix information. 146 This seems to typically be seen on wireless (though sometimes wired) 147 networks where a laptop has enabled the Windows Internet Connection 148 Sharing service (ICS) which turns a host into a 6to4 [1] gateway; 149 this can be a useful feature, unless of course it is run when not 150 intended. We have had reports that hosts may not see the genuine RAs 151 on link due to host firewalls, and then turning on a connection 152 sharing service and 6to4 as a result. In some cases more technical 153 users may also use a laptop as a home gateway (e.g. again a 6to4 154 gateway) and then connect to another network with the gateway 155 configuration still active. 157 There are also reported incidents in enterprise networks of users 158 physically plugging Ethernet cables into the wrong sockets and 159 bridging two subnets together, causing an problem similar to VLAN 160 flooding. 162 2.3. Malicious misconfiguration 164 Here an attacker is deliberately generating RAs on the local network 165 in an attempt to perform some form of denial of service or man-in- 166 the-middle attack. 168 3. Methods to Mitigate against Rogue RAs 170 In this section we present a summary of methods suggested to date for 171 reducing or removing the possibility of rogue RAs being seen on a 172 network. 174 3.1. Manual configuration 176 The default gateway and host address can usually be manually 177 configured on a device. This is of course a resource intensive 178 solution, and also prone to administrative mistakes in itself. 180 3.2. Secure Neighbor Discovery 182 The SeND [4] protocol provides a method for hosts and routers to 183 perform secure Neighbor Discovery. At present there are very few 184 SeND implementations available, and SeND is perceived as a complex 185 protocol to deploy. It is also likely that not all scenarios will be 186 able to use SeND, for various reasons. In particular SeND may be 187 best suited for fully managed enterprise networks, rather than those 188 where administrative control is not present. 190 3.3. Introduce RA snooping 192 It should be possible to implement 'RA snooping' in Layer 2 switches 193 in a similar way to DHCP snooping, such that RAs observed from 194 incorrect sources are blocked or dropped, and not propagated through 195 a subnet. One candidate solution in this space called RA-Guard [9] 196 has recently been proposed. This type of solution has appeal because 197 it is a familiar model for enterprise network managers, but it can 198 also be used to complement SeND. 200 This type of solution may not be applicable everywhere, e.g. in 201 environments where there are not centrally controlled switches. 203 3.4. Use ACLs on Managed Switches 205 Certain switch platforms can already implement some level of rogue RA 206 filtering by the administrator configuring Access Control Lists 207 (ACLs) that block RA ICMP messages that might be inbound on 'user' 208 ports. Again this type of 'solution' depends on the presence of such 209 configurable switches. 211 3.5. Use the Router Preference Option 213 RFC4191 [5] introduced router preference options, such that an RA 214 could carry one of three router preference values: High, Medium 215 (default) or Low. Thus an administrator could use High settings for 216 managed RAs, and hope that 'accidental' RAs would be medium priority. 217 This of course would only work in some scenarios - an attacker would 218 certainly seek to use High priority anyway - and would also rely on 219 clients having implementations of the protocol. 221 3.6. Rely on Layer 2 admission control 223 In principle, if a technology such as IEEE 802.1x is used, devices 224 would first need to authenticate to the network before being able to 225 send or receive IPv6 traffic. Ideally authentication would be 226 mutual. 228 Improving Layer 2 security may help to mitigate against a malicious 229 attacker's capability to join the network to send RAs, but it doesn't 230 prevent misconfiguration issues. 232 3.7. Use host-based packet filters 234 In a managed environment hosts could be configured via their 235 'personal firewall' to only accept RAs from trusted sources. Hosts 236 could also potentially be configured to discard 6to4-based RAs in a 237 managed enterprise environment. 239 However, the problem is then pushed to keeping this configuration 240 maintained and correct. If a router fails and is replaced, possibly 241 with a new Layer 2 interface address, the link local source address 242 in the filter may become incorrect and no thus no method would be 243 available to push the new information to the host over the network. 245 3.8. Use an 'intelligent' deprecation tool 247 It could be possible to run a daemon on a link (perhaps on the router 248 on the link) to watch for incorrect RAs and to send a deprecating RA 249 with router lifetime of zero when such an RA is observed. The KAME 250 rafixd is an example of such a tool, which has been used at IETF 251 meetings with some success. A slightly enhanced ramond has since 252 been developed from this code. As with host based firewalling, the 253 daemon would need to somehow know what 'good' and 'bad' RAs are, from 254 some combination of known good sources and/or link prefixes. 256 In contrast, an attacker might use such a tool to learn about 257 prefixes being advertised on a link and to deprecate the 'good' RA(s) 258 in favour of their bogus RA(s). 260 Whether or not use of such a tool is the preferred method, monitoring 261 a link for observed RAs seems prudent from a network management 262 perspective. Some such tools exist already, e.g. ndpmon. 264 3.9. Wait before using new advertisements 266 It might be possible, in networks where configurations are very 267 static and systems generally remain up, to configure an option such 268 that any new RAs that are seen are not acted upon for a certain 269 period, e.g. 2 hours. This might allow time for a misconfiguration 270 or accidental RA to be detected and stopped, before hosts use the 271 data in the RA. Of course this would add delays where genuine new 272 RAs are required, while new hosts appearing on a network would still 273 be vulnerable (or be unable to configure at all). 275 3.10. Use Layer 2 Partitioning 277 If each system or user on a network is partitioned into a different 278 Layer 2 medium, then the impact of rogue RAs can be limited. In 279 broadband networks RFC1483 bridging may be available, for example. 281 The benefit may be scenario-specific, e.g. whether a given user or 282 customer has their own network prefix or whether the provisioning is 283 in a shared subnet or link. It is certainly desirable that any given 284 user or customer's system(s) are unable to see RAs that may be 285 generated by other users or customers. 287 However, such partitioning would certainly increase address space 288 consumption significantly if applied in enterprise networks, and in 289 many cases hardware costs and software licensing costs to enable 290 routing to the edge can be quite significant. 292 3.11. Add a Default Gateway Option to DHCPv6 294 It may be possible to define a new Default Gateway Option for DHCPv6 295 that would allow network administrators to only have hosts use DHCPv6 296 for default gateway configuration in managed networks. While such an 297 option could be defined, its ramifications remain unclear, and such a 298 fundamental change to the IPv6 model of autoconfiguration would need 299 very careful consideration. 301 In the absence of RAs, other configuration information would also be 302 missing, e.g. on-link prefix information. Of course, it may be that 303 an RA is still required to inform the host to use DHCPv6, and that 304 may introduce a Catch-22 unless hosts are configured directly to only 305 use DHCPv6. 307 An advantage of DHCPv6 is that should an error be introduced, only 308 hosts that have refreshed their DHCP information since that time are 309 affected, while a multicast rogue RA will most likely affect all 310 hosts immediately. DHCPv6 also allows different answers to be given 311 to different hosts. 313 4. Scenarios and mitigations 315 In this section we summarise the scenarios and mitigations described 316 above in a summary matrix. We consider, for the case of a rogue 317 multicast RA, which of the mitigation methods protects against each 318 cause: 320 +------------------------+-------------+-------------+-------------+ 321 | Scenario | Admin | User | Malicious | 322 | Mitigation | Error | Error | Attack | 323 +------------------------+-------------+-------------+-------------+ 324 | Manual configuration | Y | Y | Y | 325 +------------------------+-------------+-------------+-------------+ 326 | SeND | Partly | Y | Y | 327 +------------------------+-------------+-------------+-------------+ 328 | RA snooping | Y | Y | Y | 329 +------------------------+-------------+-------------+-------------+ 330 | Use switch ACLs | Y | Y | Y | 331 +------------------------+-------------+-------------+-------------+ 332 | Router preference | N | Y | N | 333 +------------------------+-------------+-------------+-------------+ 334 | Layer 2 admission | N | N | Y | 335 +------------------------+-------------+-------------+-------------+ 336 | Host firewall | Y | Y | N | 337 +------------------------+-------------+-------------+-------------+ 338 | Deprecation daemon | Y | Y | Partly | 339 +------------------------+-------------+-------------+-------------+ 340 | New prefix delay | Partly | Partly | Partly | 341 +------------------------+-------------+-------------+-------------+ 342 | Layer 2 partition | N | Y | N | 343 +------------------------+-------------+-------------+-------------+ 344 | DHCPv6 gateway option | If Auth | If Auth | If Auth | 345 +------------------------+-------------+-------------+-------------+ 347 What the above summary does not consider is the practicality of 348 deploying the measure. An easy-to-deploy method that buys improved 349 resilience to rogue RAs without significant administrative overhead 350 is attractive. On that basis the RA snooping proposal, e.g. RA 351 Guard, has merit, while approaches like manual configuration and 352 perhaps SeND may be less appealing. However RA Guard is not yet 353 fully defined or available, while only certain managed switch 354 equipment may support the required ACLs. 356 Methods that involve changes to IPv6 protocols such as delays in 357 processing RAs or a new DHCPv6 option have rather reduced appeal, 358 regardless of their merits or complications. 360 5. Other related considerations 362 There are a number of related issues that have come out of 363 discussions on the rogue RA topic, which the authors believe are 364 worth capturing in this document. 366 5.1. Unicast RAs 368 The above discussion was initially held on the assumption that rogue 369 multicast RAs were the cause of problems on a shared network subnet. 370 However, the specifications for Router Advertisements allow them to 371 be sent unicast to a host, as per Section 6.2.6 of RFC4861. It is 372 thus possible for an attacker to target one or more hosts on a shared 373 medium without (potentially) a rogue multicast RA being observed 374 elsewhere on the network (e.g. by a monitoring daemon). 376 5.2. The DHCP vs RA threat model 378 Comparing the threat model for rogue RAs and rogue DHCPv6 servers is 379 an interesting exercise. In the case of Windows ICS causing rogue 380 6to4-based RAs to appear on a network, it is very likely that the 381 same host is also acting as a rogue IPv4 DHCP server. The rogue 382 DHCPv4 server can allocate a default gateway and an address to hosts, 383 just as a rogue RA can lead hosts to learning of a new (additional) 384 default gateway and address. In the case of multicast rogue RAs 385 however, the impact is potentially immediate to all hosts, while the 386 rogue DHCP server's impact will depend on lease timers for hosts. 388 In principle Authenticated DHCP can be used to protect against rogue 389 DHCPv4 servers, just as SeND could be used to protect against rogue 390 IPv6 RAs. However use of Authenticated DHCP is currently minimal, 391 while SeND is in its infancy in implementation status. 393 Were a new DHCPv6 default gateway option to be defined as described 394 above, then without Authenticated DHCP the (lack of) security is just 395 pushed to another place, albeit one that site administrators are more 396 familiar and (rightly or wrongly) comfortable with. 398 The RA Guard approach is essentially using a similar model to DHCP 399 message snooping to protect against rogue RAs in network (switch) 400 equipment. It is worth noting that DHCPv6 message snooping would 401 also be very desirable in IPv6 networks. 403 5.3. IPv4-only networks 405 The rogue RA problem should also be considered by administrators and 406 operators of IPv4-only networks, where IPv6 monitoring, firewalling 407 and other related mechanisms may not be in place. 409 For example a comment has been made that in the case of 6to4 being 410 run by a host on a subnet that is not administratively configured 411 with IPv6, some OSes or applications may begin using IPv6 to the 6to4 412 host (router) rather than IPv4 to the intended default IPv4 router, 413 because they have IPv6 enabled by default and some applications 414 prefer IPv6 by default. Technically aware users may also 415 deliberately choose to use IPv6, possibly for subversive reasons. 416 Mitigating against this condition can also be seen to be important. 418 5.4. Network monitoring tools 420 It would generally be prudent for network monitoring or management 421 platforms to be able to observe and report on observed RAs, and 422 whether unintended RAs (possibly from unintended sources) are present 423 on a network. Further, it may be useful for individual hosts to be 424 able to report their address status (assuming their configuration 425 status allowed it of course), e.g. this could be useful during an 426 IPv6 renumbering phased process as described in RFC4192 [6]. 428 5.5. Recovering from bad configuration state 430 An important issue is how readily a host can recover from bad 431 configuration information, e.g. considering the '2 hour rule' of 432 Section 5.5.3 of RFC4862 (though this applies to the prefix lifetime 433 not the router lifetime). We should ensure that methods exist for a 434 network administrator to correct bad configuration information on a 435 link or subnet, and that OS platforms support these methods. At 436 least if the problem can be detected, and corrected promptly, the 437 impact is minimised. 439 5.6. Behaviour of a node after receiving a rogue RA 441 After a host receives and processes a rogue RA, it may have multiple 442 default gateways, global addresses, and potentially clashing RA 443 options (e.g. M/O bits). The host's behaviour may then be 444 unpredictable, in terms of the default router that is used, and the 445 (source) address(es) used in communications. A host that is aware of 446 protocols such as shim6 may believe it is genuinely multihomed. 448 6. Conclusions 450 In this text we have described scenarios via which rogue Router 451 Advertisements (RAs) may appear on a network, and some measures that 452 could be used to mitigate against these. We have also noted some 453 related issues that have arisen in the rogue RA discussions. 455 While SeND perhaps offers the most robust solution, implementations 456 are not widely available, and the solution is perceived as complex 457 (parallels can possibly be drawn with Authenticated DHCP in terms of 458 likely deployment). Adding a new DHCPv6 Default Gateway Option would 459 allow configuration by DHCP, and be a method that IPv4 administrators 460 are comfortable with (for better or worse), but such an option would 461 have significant impacts elsewhere, and in any event one must 462 recognise that the security risk is then simply shifted elsewhere. 464 Further work on the solutions is certainly welcome. In the meantime, 465 the simplest initial step would be for RA snooping to be defined and 466 deployed for Layer 2 devices, in such a way that can address (shared) 467 wireless as well as wired networks. One draft proposal in this 468 space, RA-Guard, has recently been published [9]. Alternatively, 469 certain switch platforms allow configuration of Access Control Lists 470 (ACLs) that can achieve a similar function. 472 In the longer term wider experience of SeND will be beneficial, while 473 the use of RA snooping (and DHCPv6 snooping) will remain useful 474 either to complement SeND or to assist in scenarios that do not lend 475 themselves to SeND deployment. 477 7. Security Considerations 479 There are no extra Security consideration for this document. 481 8. IANA Considerations 483 There are no extra IANA consideration for this document. 485 9. Acknowledgments 487 Thanks are due to members of the IETF IPv6 Operations and DHCP WGs 488 for their inputs on this topic, as well as some comments from various 489 operational mailing lists, including but not limited to: Iljitsch van 490 Beijnum, Dale Carder, Remi Denis-Courmant, Tony Hain, Christian 491 Huitema, Tatuya Jinmei, David Malone, Chip Popoviciu, Dave Thaler, 492 Goeran Weinholt and Dan White. 494 10. Informative References 496 [1] Carpenter, B. and K. Moore, "Connection of IPv6 Domains via IPv4 497 Clouds", RFC 3056, February 2001. 499 [2] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. 500 Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", 501 RFC 3315, July 2003. 503 [3] Droms, R., "Stateless Dynamic Host Configuration Protocol (DHCP) 504 Service for IPv6", RFC 3736, April 2004. 506 [4] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure 507 Neighbor Discovery (SEND)", RFC 3971, March 2005. 509 [5] Draves, R. and D. Thaler, "Default Router Preferences and More- 510 Specific Routes", RFC 4191, November 2005. 512 [6] Baker, F., Lear, E., and R. Droms, "Procedures for Renumbering 513 an IPv6 Network without a Flag Day", RFC 4192, September 2005. 515 [7] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, "Neighbor 516 Discovery for IP version 6 (IPv6)", RFC 4861, September 2007. 518 [8] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless Address 519 Autoconfiguration", RFC 4862, September 2007. 521 [9] Van de Velde, G., Levy-Abegnoli, E., Popoviciu, C., and J. 522 Mohacsi, "IPv6 RA-Guard (draft-ietf-v6ops-ra-guard-00)", 523 July 2008. 525 Authors' Addresses 527 Tim Chown 528 University of Southampton 529 Southampton, Hampshire SO17 1BJ 530 United Kingdom 532 Email: tjc@ecs.soton.ac.uk 534 Stig Venaas 535 UNINETT 536 Trondheim NO 7465 537 Norway 539 Email: venaas@uninett.no 541 Full Copyright Statement 543 Copyright (C) The IETF Trust (2008). 545 This document is subject to the rights, licenses and restrictions 546 contained in BCP 78, and except as set forth therein, the authors 547 retain all their rights. 549 This document and the information contained herein are provided on an 550 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 551 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 552 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 553 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 554 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 555 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 557 Intellectual Property 559 The IETF takes no position regarding the validity or scope of any 560 Intellectual Property Rights or other rights that might be claimed to 561 pertain to the implementation or use of the technology described in 562 this document or the extent to which any license under such rights 563 might or might not be available; nor does it represent that it has 564 made any independent effort to identify any such rights. Information 565 on the procedures with respect to rights in RFC documents can be 566 found in BCP 78 and BCP 79. 568 Copies of IPR disclosures made to the IETF Secretariat and any 569 assurances of licenses to be made available, or the result of an 570 attempt made to obtain a general license or permission for the use of 571 such proprietary rights by implementers or users of this 572 specification can be obtained from the IETF on-line IPR repository at 573 http://www.ietf.org/ipr. 575 The IETF invites any interested party to bring to its attention any 576 copyrights, patents or patent applications, or other proprietary 577 rights that may cover technology that may be required to implement 578 this standard. Please address the information to the IETF at 579 ietf-ipr@ietf.org. 581 Acknowledgment 583 Funding for the RFC Editor function is provided by the IETF 584 Administrative Support Activity (IASA).