idnits 2.17.1 draft-ietf-ospf-af-alt-07.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 20. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 561. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 572. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 579. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 585. 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.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 2460 (ref. 'IPV6') (Obsoleted by RFC 8200) == Outdated reference: A later version (-08) exists of draft-ietf-ospf-lls-05 -- Obsolete informational reference (is this intentional?): RFC 4601 (ref. 'PIM') (Obsoleted by RFC 7761) Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group A. Lindem (Editor) 3 Internet-Draft Redback Networks 4 Intended status: Standards Track S. Mirtorabi 5 Expires: April 4, 2009 A. Roy 6 M. Barnes 7 Cisco Systems 8 R. Aggarwal 9 Juniper Networks 10 Oct 30 2008 12 Support of address families in OSPFv3 13 draft-ietf-ospf-af-alt-07.txt 15 Status of this Memo 17 By submitting this Internet-Draft, each author represents that any 18 applicable patent or other IPR claims of which he or she is aware 19 have been or will be disclosed, and any of which he or she becomes 20 aware will be disclosed, in accordance with Section 6 of BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that 24 other groups may also distribute working documents as Internet- 25 Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/ietf/1id-abstracts.txt. 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html. 38 This Internet-Draft will expire on April 4, 2009. 40 Copyright Notice 42 Copyright (C) The IETF Trust (2008). 44 Abstract 46 This document describes a mechanism for supporting multiple address 47 families in OSPFv3 using multiple instances. It maps an address 48 family (AF) to an OSPFv3 instance using the Instance ID field in the 49 OSPFv3 packet header. This approach is fairly simple and minimizes 50 extensions to OSPFv3 for supporting multiple AFs. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 1.1. Design Considerations . . . . . . . . . . . . . . . . . . 3 56 1.2. Requirements notation . . . . . . . . . . . . . . . . . . 3 57 2. Protocol Details . . . . . . . . . . . . . . . . . . . . . . . 4 58 2.1. Instance ID values for new AFs . . . . . . . . . . . . . . 4 59 2.2. OSPFv3 Options and Prefix Options Changes . . . . . . . . 4 60 2.2.1. OSPFv3 Options . . . . . . . . . . . . . . . . . . . . 4 61 2.2.2. Prefix Options . . . . . . . . . . . . . . . . . . . . 5 62 2.3. Advertising Prefixes in new AFs . . . . . . . . . . . . . 5 63 2.4. Changes to the Hello processing . . . . . . . . . . . . . 6 64 2.5. Next hop for IPv4 unicast and multicast AFs . . . . . . . 6 65 2.6. AS External LSA Forwarding Address for IPv4 Unicast 66 and IPv4 Multicast AFs . . . . . . . . . . . . . . . . . 7 67 2.7. Database Description Maximum Transmissoin Unit (MTU) 68 Specification for Non-IPv6 AFs . . . . . . . . . . . . . . 7 69 2.8. Operation over Virtual Links . . . . . . . . . . . . . . . 9 70 3. Backward Compatibility . . . . . . . . . . . . . . . . . . . . 10 71 4. Security Considerations . . . . . . . . . . . . . . . . . . . 11 72 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 73 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 74 6.1. Normative References . . . . . . . . . . . . . . . . . . . 14 75 6.2. Informative References . . . . . . . . . . . . . . . . . . 14 76 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 15 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 78 Intellectual Property and Copyright Statements . . . . . . . . . . 17 80 1. Introduction 82 OSPFv3 [OSPFV3] has been defined to support the base IPv6 unicast 83 Address Family (AF). There are requirements to advertise other AFs 84 in OSPFv3 including multicast IPv6, unicast IPv4, and multicast IPv4. 85 This document supports these other AFs in OSPFv3 by mapping each AF 86 to a separate Instance ID and OSPFv3 instance. 88 1.1. Design Considerations 90 This section describes the rationale for using the multiple instance 91 ID approach to support multiple address families in OSPFv3. As 92 described earlier, OSPFv3 is designed to support multiple instances. 93 Hence mapping an instance to an address family doesn't introduce any 94 new mechanisms to the protocol. It minimizes the protocol extensions 95 required and it simplifies the implementation. The presence of a 96 separate link state database per address family is also easier to 97 debug and operate. Additionally, it doesn't change the existing 98 instance, area, and interface based configuration model in most 99 OSPFv3 implementations. 101 1.2. Requirements notation 103 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 104 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 105 document are to be interpreted as described in [RFC-KEYWORDS]. 107 2. Protocol Details 109 Currently the entire Instance ID number space is used for IPv6 110 unicast. This specification assigns different Instance ID ranges to 111 different AFs in order to support other AFs in OSPFv3. Each Instance 112 ID implies a separate OSPFv3 instance with its own neighbor 113 adjacencies, link state database, protocol data structures, and 114 shortest path first (SPF) computation. Additionally, the current 115 LSAs that are defined to advertise IPv6 unicast prefixes can be used 116 without any modifications to advertise prefixes from other AFs. 118 It should be noted that OSPFv3 is running on top of IPv6 and uses 119 IPv6 link local addresses for OSPFv3 control packets. Therefore, it 120 is required that IPv6 be enabled on a link, although the link may not 121 be participating in any IPv6 AF. 123 2.1. Instance ID values for new AFs 125 Instance ID zero is already defined by default for the IPv6 unicast 126 AF. We define the following ranges for different AFs. The first 127 value of each range is considered as the default value for the 128 corresponding AF. 130 Instance ID # 0 - # 31 IPv6 unicast AF 131 Instance ID # 32 - # 63 IPv6 multicast AF 132 Instance ID # 64 - # 95 IPv4 unicast AF 133 Instance ID # 96 - # 127 IPv4 multicast AF 134 Instance ID # 128 - # 255 Unassigned 136 OSPFv3 Instance IDs 138 2.2. OSPFv3 Options and Prefix Options Changes 140 A new AF-bit is added to the OSPFv3 options field. V6-bit and MC-bit 141 are only applicable to the IPv6 unicast AF. 143 2.2.1. OSPFv3 Options 145 1 2 146 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 147 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+-+-+--+-+-+--+--+--+ 148 | | | | | | | | | | | | | | | |AF|*|*|DC|R|N|MC| E|V6| 149 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+-+-+--+-+-+--+--+--+ 151 The Options field 152 OSPFv3 Options 154 V6-bit 155 The V6 bit is used in OSPFv3 to exclude a node from IPv6 unicast 156 route calculation but allow it in the SPF calculation for other 157 address families. Since Instance ID now denotes the AF 158 explicitly, this bit is ignored in AFs other than IPv6 unicast. 160 MC-bit 161 This bit is not used in other AFs introduced in this document. 163 AF-bit 164 When a router supports AF, it MUST set this new bit in the OSPFv3 165 Options field of Hello Packets, DD packets, and LSAs. 167 2.2.2. Prefix Options 169 0 1 2 3 4 5 6 7 170 +--+--+--+--+--+--+--+--+ 171 | | | |DN| P|x |LA|NU| 172 +--+--+--+--+--+--+--+--+ 174 Prefix Options 176 NU-bit 177 The "no unicast" capability bit. If set, the prefix should be 178 excluded from IPv6 unicast calculations. If not set, it should be 179 included. It SHOULD be cleared in advertised prefixes for 180 multicast AFs and MUST be ignored for received prefixes for 181 multicast AFs. 183 x-bit 184 This bit will be deprecated in a future version of [OSPFV3]. It 185 may be reassigned in the future. 187 The LA-bit, P-bit, and DN-bit are described in [OSPFV3]. Note that 188 all bits unused in a given AF MAY be redefined for AF specific 189 purposes in future specifications. 191 2.3. Advertising Prefixes in new AFs 193 Each Prefix defined in OSPFv3 has a prefix length field. This 194 facilitate advertising prefixes of different lengths in different 195 AFs. The existing LSAs defined in OSPFv3 are used for this purpose 196 and there is no need to define new LSAs. 198 2.4. Changes to the Hello processing 200 When a router does not support an AF but it is configured with the 201 corresponding Instance ID packets could be black holed. This could 202 happen due to misconfiguration or a router software downgrade. Black 203 holing is possible because the router which doesn't support the AF 204 can still be included in the SPF calculated path as long as it 205 establishes adjacencies using the Instance ID corresponding to the 206 AF. Note that router and network LSAs are AF independent. 208 In order to avoid the above situation, hello processing is changed in 209 order to only establish adjacencies with routers that have the AF-bit 210 set in their Options field. 212 Receiving Hello Packets is specified in section 3.2.2.1 of [OSPFV3]. 213 The following check is added to Hello reception: 215 o When a router participates in an AF (sets the AF-bit in Options 216 field) it MUST discard Hello packets having the AF-bit clear in 217 the Options field. The only exception is the Base IPv6 unicast 218 AF, where this check MUST NOT be done (for backward 219 compatibility). 221 2.5. Next hop for IPv4 unicast and multicast AFs 223 OSPFv3 runs on top of IPv6 and uses IPv6 link local addresses for 224 OSPFv3 control packets and next hop calculations. Although IPV6 link 225 local addresses could be used as next hops for IPv4 address families, 226 it is desirable to have IPv4 next hop addresses. For example, in 227 IPv4 multicast having the next hop address the same as the Protocol 228 Independent Multicast (PIM) [PIM] neighbor address (IPv4 address) 229 makes it easier to determine which upstream neighbor to send a PIM 230 join when doing a Reverse Path Forwarding (RPF) lookup. It is also 231 easier for troubleshooting to have a next hop with the same AF. 233 In order to achieve this, the link's IPv4 address will be advertised 234 in the "link local address" field of the IPv4 instance's Link-LSA. 235 This address is placed in the first 32 bit of "link local address" 236 field and used for IPv4 next hop calculations. The remaining bits 237 MUST be set to zero. 239 We call direct interface address (DIA) the address that is reachable 240 directly via the link provided that a layer 3 to layer 2 mapping is 241 available. Note that there is no explicit need for the IPv4 link 242 addresses to be on the same subnet. An implementation should resolve 243 layer 3 to layer 2 mappings via Address Resolution Protocol (ARP) 245 [ARP] or Neighbor Discovery (ND) [ND] for a DIA even if the IPv4 246 address is not on the same subnet as the router's interface IP 247 address. 249 2.6. AS External LSA Forwarding Address for IPv4 Unicast and IPv4 250 Multicast AFs 252 For OSPFv3, this address is fully qualified IPv6 address (128 bits). 253 If included, data traffic for the advertised destination will be 254 forwarded to this address. For IPv4 unicast and IPv4 multicast AFs, 255 the Forwarding address in AS-external-LSAs MUST encode an IPv4 256 address. To achieve this, the IPv4 Forwarding address is advertised 257 by placing it in the first 32 bits of the Forwarding address field in 258 the AS-external-LSAs. The remaining bits MUST be set to zero. 260 2.7. Database Description Maximum Transmissoin Unit (MTU) 261 Specification for Non-IPv6 AFs 263 For address families other than IPv6, both the MTU for the address 264 family of the instance and IPv6 MTU used for OSPFv3 maximum packet 265 determination must be considered. The MTU in the Database 266 Description packet MUST always contain the MTU corresponding to the 267 advertised address family. For example, if the instance corresponds 268 to an IPv4 address family, the IPv4 MTU for the interface MUST be 269 specified in the interface MTU field. As specified section 10.6 of 270 [OSPFV2], the Database Description packet will be rejected if the MTU 271 is greater than the receiving interface's MTU for the address family 272 corresponding to the instance. This behavior will assure an 273 adjacency is not formed and address family specific routes are not 274 installed over a path with conflicting MTUs. 276 The value used for OSPFv3 maximum packet size determination must also 277 be compatible for an adjacency to be established. Since only a 278 single MTU field is specified, the M6-bit is defined by this 279 specification. If the M6-bit is clear, the specified MTU should also 280 be checked against the IPv6 MTU and the Database Description packet 281 should be rejected if the MTU is larger than the receiving 282 interface's IPv6 MTU. An OSPFv3 router SHOULD NOT set the M6-bit if 283 its IPv6 MTU and address family specific MTU are the same. 285 If the IPv6 and IPv4 MTUs differ, the M6-bit MUST be set for non-IPv6 286 address families. If the M6-bit is set, the IPv6 MTU is decided by 287 the presence or absense of IPv6 MTU TLV in the LLS [LLS] block. If 288 this TLV is present, it carries the IPv6 MTU which should be compared 289 with local IPv6 MTU. If this TLV is absent, the minimum IPv6 MTU of 290 1280 octets should be used for the comparison (refer to [IPV6]). 292 If the M6-bit is set in a received Database Description packet for a 293 non-IPv6 address family, the receiving router MUST NOT check the 294 Interface MTU in the Database Exchange packet against the receiving 295 interface's IPv6 MTU. 297 The figure below graphically depicts the OSPFv3 Database Description 298 Packet: 300 0 1 2 3 301 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 302 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+-+-+-+--+ 303 | 3 | 2 | Packet Length | 304 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+-+-+-+--+ 305 | Router ID | 306 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+-+-+-+--+ 307 | Area ID | 308 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+-+-+-+--+ 309 | Checksum | Instance ID | 0 | 310 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+-+-+-+--+ 311 | 0 | Options | 312 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+-+-+-+--+ 313 | Interface MTU | 0 |0|0|0|M6|0|I|M|MS| 314 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+-+-+-+--+ 315 | DD sequence number | 316 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+-+-+-+--+ 317 | | 318 +- -+ 319 | | 320 +- An LSA Header -+ 321 | | 322 +- -+ 323 | | 324 +- -+ 325 | | 326 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+-+-+-+--+ 327 | ... | 329 The OSPFv3 Database Description Packet 331 The changed fields in the Database Description packet are described 332 below. The remaining fields are unchanged from [OSPFV3]. 334 Interface MTU 335 The size in octets of the largest address-family specific datagram 336 that can be sent out the associated interface without 337 fragmentation. The MTUs of common Internet link types can be 338 found in Table 7-1 of [MTUDISC]. Interface MTU should be set to 0 339 in Database Description packets sent over virtual links. 341 M6-bit 342 The IPv6 MTU bit - this bit indicates the sender is using a 343 different IPv6 MTU than the MTU for the address family. 345 IPv6 MTU TLV can be optionally carried in LLS block as described 346 above. This TLV carries the IPv6 MTU on the interface. The length 347 field of of TLV is set to 4 bytes. 349 0 1 2 3 350 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 351 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 352 | 3 (TBD) | 4 | 353 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 354 | IPv6 MTU | 355 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 357 Format of IPv6 MTU TLV 359 The IPv6 MTU TLV may appear in the LLS block only once. 361 2.8. Operation over Virtual Links 363 OSPFv3 control packets sent over a virtual link are IPv6 packets and 364 may traverse multiples hops. Therefore, there must be a global IPv6 365 address associated with the virtual link so that the control packet 366 is forwarded correctly by the intermediate hops between virtual link 367 endpoints. Although this requirement can be satisfied in IPv6 368 unicast AFs, it will not function in other AFs as there will not be a 369 routable global IPv6 address or forwarding path. Therefore, virtual 370 links are not supported in AFs other than IPv6 Unicast. 372 3. Backward Compatibility 374 In this section, we will define a non-capable OSPFv3 router as one 375 not supporting this specification. Each new AF will have a 376 corresponding Instance ID and can interoperate with the existing non- 377 capable OSPFv3 routers in an IPv6 unicast topology. Furthermore, 378 when a non-capable OSPFv3 router uses an Instance ID which is 379 reserved for a given AF, no adjacency will be formed with this router 380 since the AF-bit in the Options field will not be set in Hello 381 packets. Therefore, there are no backward compatibility issues. AFs 382 can be gradually deployed without disturbing networks with non- 383 capable OSPFv3 routers. 385 4. Security Considerations 387 IPsec [IPsec]. can be used for OSPFv3 authentication and 388 confidentiality as described in [OSPFV3-AUTH]. When multiple OSPFv3 389 instances use the same interface, they all must use the same Security 390 Association (SA), since the SA selectors do not provide selection 391 based on OSPFv3 header fields such as the instance ID. This 392 restriction is documented in section 8 of [OSPFV3-AUTH]. 394 Security considerations for the OSPFv3 are covered in [OSPFV3]. 396 5. IANA Considerations 398 The following IANA assignments are to be made from existing 399 registries: 401 AF-bit is assigned from OSPFv3 Options field as defined in 402 Section 2.2.1. 404 IANA is requested to create a new registry, "OSPFv3 Instance ID 405 Address Family Values". for assignment of address families IDs. Note 406 that the Instance ID MAY be used for applications other than the 407 support of multiple address families. However, if it is being used 408 for address families the assignments herein should be honored. 410 +-------------+----------------------+--------------------+ 411 | Value/Range | Designation | Assignment Policy | 412 +-------------+----------------------+--------------------+ 413 | 0 | Base IPv6 Unicast AF | Already assigned | 414 | | | | 415 | 1-31 | IPv6 Unicast AFs | Already assigned | 416 | | dependent on local | | 417 | | policy | | 418 | | | | 419 | 32 | Base IPv6 Multicast | Already assigned | 420 | | | | 421 | 33-63 | IPv6 Multicast AFs | Already assigned | 422 | | dependent on local | | 423 | | policy | | 424 | | | | 425 | 64 | Base IPv4 Unicast AF | Already assigned | 426 | | | | 427 | 65-95 | IPv4 Unicast AFs | Already assigned | 428 | | dependent on local | | 429 | | policy | | 430 | | | | 431 | 96 | Base IPv4 Multicast | Already assigned | 432 | | | | 433 | 97-127 | IPv4 Multicast AFs | Already assigned | 434 | | dependent on local | | 435 | | policy | | 436 | | | | 437 | 128-255 | Unassigned | Standards Action | 438 +-------------+----------------------+--------------------+ 440 OSPFv3 Address Family Use of Instance IDs 442 o Instancs IDs 0-127 are assigned by this specification. 444 o Instance IDs in the range 128-255 are not assigned at this time. 445 Before any assignments can be made in this range, there MUST be a 446 Standards Track RFC including IANA Considerations explicitely 447 specifying the AF Instance IDs being assigned. 449 M6-Bit is assigned as defined in Section 2.7. 451 A TLV type for IPv6 MTU TLV is assigned from OSPF LLS TLVs registry. 453 6. References 455 6.1. Normative References 457 [IPV6] Deering, S. and R. Hinden, "Internet Protocol, Version 6 458 (IPv6) Specification", RFC 2460, December 1998. 460 [IPsec] Kent, S. and K. Seo, "Security Architecture for the 461 Internet Protocol", RFC 4301, December 2005. 463 [OSPFV2] Moy, J., "OSPF Version 2", RFC 2328, April 1998. 465 [OSPFV3] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF 466 for IPv6", RFC 5340, July 2008. 468 [OSPFV3-AUTH] 469 Gupta, M. and S. Melam, "Authentication/Confidentiality 470 for OSPFv3", RFC 4552, June 2006. 472 [RFC-KEYWORDS] 473 Bradner, S., "Key words for use in RFC's to Indicate 474 Requirement Levels", RFC 2119, March 1997. 476 6.2. Informative References 478 [ARP] Plummer, D., "An Ethernet Address Resolution Protocol", 479 RFC 826, November 1982. 481 [LLS] Zinin, A., Roy, A., Nguyen, L., Friedman, B., and D. 482 Young, "OSPF Link-local Signaling", 483 draft-ietf-ospf-lls-05.txt, Work in progress. 485 [MTUDISC] Mogul, J. and S. Deering, "Path MTU Discovery", RFC 1191, 486 November 1990. 488 [ND] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 489 "Neighbor Discovery for IP Version 6 (IPv6)", RFC 4861, 490 September 2007. 492 [PIM] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, 493 "Protocol Independent Multicast - Sparse Mode (PIM-SM): 494 Protocol Specification (Revised)", RFC 4601, August 2006. 496 Appendix A. Acknowledgments 498 The RFC text was produced using Marshall Rose's xml2rfc tool. 500 Thanks to Tom Henderson and the folks at Boeing for implementing in 501 quagga. 503 Thanks to Nischal Seth for review and comments. 505 Authors' Addresses 507 Acee Lindem 508 Redback Networks 509 102 Carric Bend Court 510 Cary, NC 27519 511 USA 513 Email: acee@redback.com 515 Sina Mirtorabi 516 Cisco Systems 517 3 West Plumeria Drive 518 San Jose, CA 95134 519 USA 521 Email: smirtora@cisco.com 523 Abhay Roy 524 Cisco Systems 525 225 West Tasman Drive 526 San Jose, CA 95134 527 USA 529 Email: akr@cisco.com 531 Michael Barnes 532 Cisco Systems 533 225 West Tasman Drive 534 San Jose, CA 95134 535 USA 537 Email: mjbarnes@cisco.com 539 Rahul Aggarwal 540 Juniper Networks 541 1194 N. Mathilda Ave. 542 Sunnyvale, CA 94089 543 USA 545 Email: rahul@juniper.net 547 Full Copyright Statement 549 Copyright (C) The IETF Trust (2008). 551 This document is subject to the rights, licenses and restrictions 552 contained in BCP 78, and except as set forth therein, the authors 553 retain all their rights. 555 This document and the information contained herein are provided on an 556 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 557 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 558 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 559 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 560 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 561 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 563 Intellectual Property 565 The IETF takes no position regarding the validity or scope of any 566 Intellectual Property Rights or other rights that might be claimed to 567 pertain to the implementation or use of the technology described in 568 this document or the extent to which any license under such rights 569 might or might not be available; nor does it represent that it has 570 made any independent effort to identify any such rights. Information 571 on the procedures with respect to rights in RFC documents can be 572 found in BCP 78 and BCP 79. 574 Copies of IPR disclosures made to the IETF Secretariat and any 575 assurances of licenses to be made available, or the result of an 576 attempt made to obtain a general license or permission for the use of 577 such proprietary rights by implementers or users of this 578 specification can be obtained from the IETF on-line IPR repository at 579 http://www.ietf.org/ipr. 581 The IETF invites any interested party to bring to its attention any 582 copyrights, patents or patent applications, or other proprietary 583 rights that may cover technology that may be required to implement 584 this standard. Please address the information to the IETF at 585 ietf-ipr@ietf.org. 587 Acknowledgment 589 Funding for the RFC Editor function is provided by the IETF 590 Administrative Support Activity (IASA).