idnits 2.17.1 draft-gont-6man-ipv6-opt-transmit-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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 : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC7045]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC2460, updated by this document, for RFC5378 checks: 1997-07-30) -- 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 (August 21, 2015) is 3171 days in the past. Is this intentional? Checking references for intended status: Best Current Practice ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC1034' is defined on line 437, but no explicit reference was found in the text == Unused Reference: 'RFC2205' is defined on line 446, but no explicit reference was found in the text == Unused Reference: 'RFC2710' is defined on line 463, but no explicit reference was found in the text == Unused Reference: 'RFC4302' is defined on line 477, but no explicit reference was found in the text == Unused Reference: 'RFC4303' is defined on line 481, but no explicit reference was found in the text == Unused Reference: 'RFC4304' is defined on line 485, but no explicit reference was found in the text == Unused Reference: 'RFC5095' is defined on line 500, but no explicit reference was found in the text == Unused Reference: 'RFC5201' is defined on line 505, but no explicit reference was found in the text == Unused Reference: 'RFC5533' is defined on line 515, but no explicit reference was found in the text == Unused Reference: 'RFC6398' is defined on line 528, but no explicit reference was found in the text == Unused Reference: 'RFC6550' is defined on line 532, but no explicit reference was found in the text == Unused Reference: 'RFC6554' is defined on line 545, but no explicit reference was found in the text == Unused Reference: 'RFC6740' is defined on line 555, but no explicit reference was found in the text == Unused Reference: 'RFC7112' is defined on line 580, but no explicit reference was found in the text == Unused Reference: 'Biondi2007' is defined on line 587, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-roll-trickle-mcast' is defined on line 592, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-v6ops-ipv6-ehs-in-real-world' is defined on line 597, but no explicit reference was found in the text == Unused Reference: 'RFC7126' is defined on line 623, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) ** Downref: Normative reference to an Experimental RFC: RFC 4782 ** Obsolete normative reference: RFC 5201 (Obsoleted by RFC 7401) ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) ** Downref: Normative reference to an Informational RFC: RFC 5570 ** Downref: Normative reference to an Experimental RFC: RFC 6621 ** Downref: Normative reference to an Experimental RFC: RFC 6740 ** Downref: Normative reference to an Experimental RFC: RFC 6744 ** Downref: Normative reference to an Experimental RFC: RFC 6971 == Outdated reference: A later version (-02) exists of draft-ietf-v6ops-ipv6-ehs-in-real-world-00 Summary: 10 errors (**), 0 flaws (~~), 20 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 6man F. Gont 3 Internet-Draft UTN-FRH / SI6 Networks 4 Updates: 2460 (if approved) W. Liu 5 Intended status: Best Current Practice Huawei Technologies 6 Expires: February 22, 2016 R. Bonica 7 Juniper Networks 8 August 21, 2015 10 Transmission and Processing of IPv6 Options 11 draft-gont-6man-ipv6-opt-transmit-02.txt 13 Abstract 15 Various IPv6 options have been standardized since the core IPv6 16 standard was first published. This document updates RFC 2460 to 17 clarify how nodes should deal with such IPv6 options and with any 18 options that are defined in the future. It complements [RFC7045], 19 which offers a similar clarification regarding IPv6 Extension 20 Headers. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on February 22, 2016. 39 Copyright Notice 41 Copyright (c) 2015 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction and Problem Statement . . . . . . . . . . . . . 2 57 2. Terminology and Conventions Used in This Document . . . . . . 3 58 2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 59 2.2. Conventions . . . . . . . . . . . . . . . . . . . . . . . 3 60 3. Considerations for All IPv6 Options . . . . . . . . . . . . . 4 61 4. Processing of currently-defined IPv6 Options . . . . . . . . 5 62 4.1. Hop-by-Hop Options Header . . . . . . . . . . . . . . . . 5 63 4.2. Destination Options Header . . . . . . . . . . . . . . . 7 64 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 65 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 66 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 67 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 68 8.1. Normative References . . . . . . . . . . . . . . . . . . 10 69 8.2. Informative References . . . . . . . . . . . . . . . . . 13 70 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 72 1. Introduction and Problem Statement 74 Various IPv6 options have been standardized since the core IPv6 75 standard [RFC2460] was first published. Except for the padding 76 options (Pad1 and PadN), all the options that have so far been 77 specified are meant to be employed with specific IPv6 Extension 78 Header (EH) types. Additionally, some options have specific 79 requirements such as, for example, only allowing a single instance of 80 the option in the corresponding IPv6 extension header. This 81 establishes some criteria for validating packets that employ IPv6 82 options. 84 [RFC2460] specifies that IPv6 extension headers (with the exception 85 of the Hop-by-Hop Options extension header) are not examined or 86 processed by any node along a packet's delivery path, until the 87 packet reaches the node (or each of the set of nodes, in the case of 88 multicast) identified in the Destination Address field of the IPv6 89 header. However, in practice this is not really the case: some 90 routers, and a variety of middleboxes such as firewalls, load 91 balancers, or packet classifiers, might inspect other parts of each 92 packet [RFC7045]. Hence both end-nodes an intermediate nodes may end 93 up inspecting the contents of extension headers and discard packets 94 based on the presence of specific IPv6 options. 96 This document clarifies the default processing of IPv6 options. In 97 those cases in which the specifications add additional constraints/ 98 requirements regarding IPv6 options, such additional constraints/ 99 requirements are also taken into account. 101 2. Terminology and Conventions Used in This Document 103 2.1. Terminology 105 In the remainder of this document, the term "forwarding node" refers 106 to any router, firewall, load balancer, prefix translator, or any 107 other device or middlebox that forwards IPv6 packets with or without 108 examining the packet in any way. 110 In this document, "standard" IPv6 options are those specified in 111 detail by IETF Standards Actions [RFC5226]. "Experimental" options 112 include those defined by any Experimental RFC and the option types 113 0x1E, 0x3E, 0x5E, 0x7E, 0x9E, 0xBE, 0xDE, and 0xFE, defined by 114 [RFC3692] and [RFC4727] when used as experimental options. "Defined" 115 options are the "standard" options plus the "experimental" ones. 117 The terms "permit" (allow the traffic), "drop" (drop with no 118 notification to sender), and "reject" (drop with appropriate 119 notification to sender) are employed as defined in [RFC3871]. 120 Throughout this document we also employ the term "discard" as a 121 generic term to indicate the act of discarding a packet, irrespective 122 of whether the sender is notified of such packet drops. 124 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 125 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 126 document are to be interpreted as described in [RFC2119]. 128 2.2. Conventions 130 This document clarifies some basic validation of IPv6 options, and 131 specifies the default processing of them. We recommend that a 132 configuration option is made available to govern the processing of 133 each IPv6 option type, on a per-EH-type granularity. Such 134 configuration options may include the following possible settings: 136 o Permit this IPv6 Option type 138 o Drop (and log) packets containing this IPv6 option type 140 o Reject (and log) packets containing this IPv6 option type (where 141 the packet drop is signaled with an ICMPv6 error message) 143 o Rate-limit the processing of packets containing this IPv6 option 144 type 146 o Ignore this IPv6 option type (forwarding packets that contain 147 them) 149 We note that special care needs to be taken when devices log packet 150 drops/rejects. Devices should count the number of packets dropped/ 151 rejected, but the logging of drop/reject events should be limited so 152 as to not overburden device resources. 154 Finally, we note that when discarding packets, it is generally 155 desirable that the sender be signaled of the packet drop, since this 156 is of use for trouble-shooting purposes. However, throughout this 157 document (when recommending that packets be discarded) we generically 158 refer to the action as "discard" without specifying whether the 159 sender is signaled of the packet drop. 161 3. Considerations for All IPv6 Options 163 Forwarding nodes that discard packets (by default) based on the 164 presence of IPv6 options are known to cause connectivity failures and 165 deployment problems. Any forwarding node along an IPv6 packet's 166 path, which forwards the packet for any reason, SHOULD do so 167 regardless of any IPv6 Destination Options that are present, as 168 required by [RFC2460]. Exceptionally, if a forwarding node is 169 designed to examine IPv6 Destination Options for any reason, such as 170 firewalling, it MUST recognise and deal appropriately with all 171 standard IPv6 options types and SHOULD recognise and deal 172 appropriately with all experimental IPv6 options. The list of 173 standard and experimental option types is maintained by IANA (see 174 [IANA-IPV6-PARAM]), and implementors are advised to check this list 175 regularly for updates. 177 In the case of some options meant to be included in IPv6 extension 178 headers other than Hop-by-Hop Options, [RFC2460] requires destination 179 hosts to discard the corresponding packet if the option is 180 unrecognised. However, intermediate forwarding nodes SHOULD NOT do 181 this, since doing so might cause them to inadvertently discard 182 traffic using a recently standardised IPv6 option not yet recognised 183 by the intermediate node. The exceptions to this rule are discussed 184 next. 186 If a forwarding node discards a packet containing a standard IPv6 187 option, it MUST be the result of a configurable policy and not just 188 the result of a failure to recognise such an option. This means that 189 the discard policy for each standard type of IPv6 option MUST be 190 individually configurable. The default configuration SHOULD allow 191 all standard IPv6 options. 193 Experimental IPv6 options SHOULD be treated in the same way as 194 standard IPv6 options, including an individually configurable discard 195 policy. 197 A node that processes the contents of an extension header MUST 198 discard the corresponding packet if it contains any defined options 199 that are not meant for the extension header being processed. This 200 document requests IANA to add a new column to [IANA-IPV6-PARAM] to 201 clearly mark the IPv6 Extension Header type(s) for which each option 202 (defined by IETF Standards Action or IESG Approval) is valid. 204 A node that processes the contents of an IPv6 extension header MAY 205 discard the corresponding packet if it contains any options that have 206 become deprecated. Whether or not such packets are dropped SHOULD be 207 configurable, and the default setting MUST be to not drop such 208 packets. 210 A node that processes the contents of an extension header and 211 encounters an undefined (unrecognised) IPv6 option MUST react to such 212 option according to the highest-order two bits of the option type, as 213 specified by Section 4.2 of [RFC2460]. 215 A node that processes an IPv6 extension header MAY discard a packet 216 containing any experimental IPv6 options. 218 4. Processing of currently-defined IPv6 Options 220 The following subsections provide advice on how to process the IPv6 221 options that have been defined at the time of this writing, according 222 to the rules specified in the previous sections. 224 4.1. Hop-by-Hop Options Header 226 A node that processes the Hop-by-Hop Options extension header MUST 227 discard the corresponding packet if it contains any options that are 228 not valid for the Hop-by-Hop Options extension header 229 [IANA-IPV6-PARAM]. 231 A node that processes the Hop-by-Hop Options extension header MUST 232 discard a packet containing multiple instances (i.e., more than one) 233 of this option in the Hop-by-Hop Options extension header: 235 o Type 0x05: Router Alert [RFC2711] 236 NOTE: The rationale for discarding the packet is that [RFC2711] 237 forbids multiple instances of this option. 239 A node that processes the Hop-by-Hop Options extension header MUST 240 discard a packet that carries a Fragment Header and also contains 241 this option in the Hop-by-Hop Options extension header: 243 o Type 0xC2: Jumbo Payload [RFC2675] 245 NOTE: The rationale for discarding the packet is that [RFC2675] 246 forbids the use of the Jumbo Payload Option in packets that carry 247 a Fragment Header. 249 A node that processes the Hop-by-Hop Options extension header MAY 250 discard a packet containing any of the following options in that 251 header: 253 o Type=0x4D: Deprecated 255 NOTE: The rationale for discarding the packet is that the 256 aforementioned option has been deprecated. 258 A node that processes the Hop-by-Hop Options extension header MAY 259 discard a packet containing any of the following options in that 260 header: 262 o Type 0x1E: RFC3692-style Experiment [RFC4727] 264 o Type 0x3E: RFC3692-style Experiment [RFC4727] 266 o Type 0x5E: RFC3692-style Experiment [RFC4727] 268 o Type 0x7E: RFC3692-style Experiment [RFC4727] 270 o Type 0x9E: RFC3692-style Experiment [RFC4727] 272 o Type 0xBE: RFC3692-style Experiment [RFC4727] 274 o Type 0xDE: RFC3692-style Experiment [RFC4727] 276 o Type 0xFE: RFC3692-style Experiment [RFC4727] 278 NOTE: This is in line with the corresponding specification in 279 [RFC7045] for experimental extension headers. 281 4.2. Destination Options Header 283 A node that processes the Destination Options header MUST discard a 284 packet containing any options that are not valid for the Destination 285 Options header [IANA-IPV6-PARAM]. 287 A node that processes the Destination Options extension header MAY 288 discard a packet containing any of the following options in that 289 header: 291 o Type 0x8A: Endpoint Identification [nimrod-eid] [NIMROD-DOC] 293 o Type 0x4D: Deprecated 295 NOTE: The rationale for discarding the packet is that the 296 aforementioned options have been deprecated. 298 A node that processes the Destination Options extension header MAY 299 discard a packet containing any of the following options in that 300 header: 302 o Type 0x1E: RFC3692-style Experiment [RFC4727] 304 o Type 0x3E: RFC3692-style Experiment [RFC4727] 306 o Type 0x5E: RFC3692-style Experiment [RFC4727] 308 o Type 0x7E: RFC3692-style Experiment [RFC4727] 310 o Type 0x9E: RFC3692-style Experiment [RFC4727] 312 o Type 0xBE: RFC3692-style Experiment [RFC4727] 314 o Type 0xDE: RFC3692-style Experiment [RFC4727] 316 o Type 0xFE: RFC3692-style Experiment [RFC4727] 318 NOTE: This is in line with the corresponding specification in 319 [RFC7045] for experimental extension headers. 321 5. IANA Considerations 323 IANA is requested to add an extra column entitled "Extension Header 324 Types" to the "Destination Options and Hop-by-Hop Options" registry 325 [IANA-IPV6-PARAM], to clearly mark the IPv6 Extension Header types 326 for which each option (defined by IETF Standards Action or IESG 327 Approval) is valid (see the list below). This also applies to 328 Destination Options and Hop-by-Hop Options defined in the future. 330 What follows is the initial list of IPv6 options and the 331 corresponding marks that indicate which Extension Header type(s) 332 these IPv6 options are valid for: 334 +------+---------------------+------------------------------+-------+ 335 | Hex | Description | Reference | EH | 336 | Valu | | | Types | 337 | e | | | | 338 +------+---------------------+------------------------------+-------+ 339 | 0x00 | Pad1 | [RFC2460] | DH | 340 +------+---------------------+------------------------------+-------+ 341 | 0x01 | PadN | [RFC2460] | DH | 342 +------+---------------------+------------------------------+-------+ 343 | 0xC2 | Jumbo Payload | [RFC2675] | H | 344 +------+---------------------+------------------------------+-------+ 345 | 0x63 | RPL Option | [RFC6553] | H | 346 +------+---------------------+------------------------------+-------+ 347 | 0x04 | Tunnel | [RFC2473] | D | 348 | | Encapsulation Limit | | | 349 +------+---------------------+------------------------------+-------+ 350 | 0x05 | Router Alert | [RFC2711] | H | 351 +------+---------------------+------------------------------+-------+ 352 | 0x26 | Quick-Start | [RFC4782] | H | 353 +------+---------------------+------------------------------+-------+ 354 | 0x07 | CALIPSO | [RFC5570] | H | 355 +------+---------------------+------------------------------+-------+ 356 | 0x08 | SMF_DPD | [RFC6621] | H | 357 +------+---------------------+------------------------------+-------+ 358 | 0xC9 | Home Address | [RFC6275] | D | 359 +------+---------------------+------------------------------+-------+ 360 | 0x8A | Endpoint | [nimrod-eid][NIMROD-DOC] | D | 361 | | Identification | | | 362 +------+---------------------+------------------------------+-------+ 363 | 0x8B | ILNP Nonce | [RFC6744] | D | 364 +------+---------------------+------------------------------+-------+ 365 | 0x8C | Line-Identification | [RFC6788] | D | 366 | | Option | | | 367 +------+---------------------+------------------------------+-------+ 368 | 0x4D | Deprecated | | U | 369 +------+---------------------+------------------------------+-------+ 370 | 0x6D | MPL Option | [I-D.ietf-roll-trickle- | H | 371 | | | mcast] | | 372 +------+---------------------+------------------------------+-------+ 373 | 0xEE | IPv6 DFF Header | [RFC6971] | H | 374 +------+---------------------+------------------------------+-------+ 375 | 0x1E | RFC3692-style | [RFC4727] | DH | 376 | | Experiment | | | 377 +------+---------------------+------------------------------+-------+ 378 | 0x3E | RFC3692-style | [RFC4727] | DH | 379 | | Experiment | | | 380 +------+---------------------+------------------------------+-------+ 381 | 0x5E | RFC3692-style | [RFC4727] | DH | 382 | | Experiment | | | 383 +------+---------------------+------------------------------+-------+ 384 | 0x7E | RFC3692-style | [RFC4727] | DH | 385 | | Experiment | | | 386 +------+---------------------+------------------------------+-------+ 387 | 0x9E | RFC3692-style | [RFC4727] | DH | 388 | | Experiment | | | 389 +------+---------------------+------------------------------+-------+ 390 | 0xBE | RFC3692-style | [RFC4727] | DH | 391 | | Experiment | | | 392 +------+---------------------+------------------------------+-------+ 393 | 0xDE | RFC3692-style | [RFC4727] | DH | 394 | | Experiment | | | 395 +------+---------------------+------------------------------+-------+ 396 | 0xFE | RFC3692-style | [RFC4727] | DH | 397 | | Experiment | | | 398 +------+---------------------+------------------------------+-------+ 400 Additionally, the following legend should be added to the registry: 402 D: Destination Options Header 403 H: Hop-by-Hop Options Header 404 U: Unknown 406 6. Security Considerations 408 Forwarding nodes that operate as firewalls MUST conform to the 409 requirements in this document. In particular, packets containing 410 standard IPv6 options are only to be discarded as a result of an 411 intentionally configured policy. 413 These requirements do not affect a firewall's ability to filter out 414 traffic containing unwanted or suspect IPv6 options, if configured to 415 do so. However, the changes do require firewalls to be capable of 416 permitting any or all IPv6 options, if configured to do so. The 417 default configurations are intended to allow normal use of any 418 standard IPv6 option, avoiding the interoperability issues described 419 in Section 1 and Section 3. 421 As noted above, the default configuration might discard packets 422 containing experimental IPv6 options. 424 7. Acknowledgements 426 This document is heavily based on [RFC7045], authored by Brian 427 Carpenter and Sheng Jiang. 429 The authors of this document would like to thank (in alphabetical 430 order) Brian Carpenter, Mike Heard, and Jen Linkova, for providing 431 valuable comments on earlier versions of this document. 433 8. References 435 8.1. Normative References 437 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 438 STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, 439 . 441 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 442 Requirement Levels", BCP 14, RFC 2119, 443 DOI 10.17487/RFC2119, March 1997, 444 . 446 [RFC2205] Braden, R., Ed., Zhang, L., Berson, S., Herzog, S., and S. 447 Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 448 Functional Specification", RFC 2205, DOI 10.17487/RFC2205, 449 September 1997, . 451 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 452 (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, 453 December 1998, . 455 [RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in 456 IPv6 Specification", RFC 2473, DOI 10.17487/RFC2473, 457 December 1998, . 459 [RFC2675] Borman, D., Deering, S., and R. Hinden, "IPv6 Jumbograms", 460 RFC 2675, DOI 10.17487/RFC2675, August 1999, 461 . 463 [RFC2710] Deering, S., Fenner, W., and B. Haberman, "Multicast 464 Listener Discovery (MLD) for IPv6", RFC 2710, 465 DOI 10.17487/RFC2710, October 1999, 466 . 468 [RFC2711] Partridge, C. and A. Jackson, "IPv6 Router Alert Option", 469 RFC 2711, DOI 10.17487/RFC2711, October 1999, 470 . 472 [RFC3692] Narten, T., "Assigning Experimental and Testing Numbers 473 Considered Useful", BCP 82, RFC 3692, 474 DOI 10.17487/RFC3692, January 2004, 475 . 477 [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, 478 DOI 10.17487/RFC4302, December 2005, 479 . 481 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 482 RFC 4303, DOI 10.17487/RFC4303, December 2005, 483 . 485 [RFC4304] Kent, S., "Extended Sequence Number (ESN) Addendum to 486 IPsec Domain of Interpretation (DOI) for Internet Security 487 Association and Key Management Protocol (ISAKMP)", 488 RFC 4304, DOI 10.17487/RFC4304, December 2005, 489 . 491 [RFC4727] Fenner, B., "Experimental Values In IPv4, IPv6, ICMPv4, 492 ICMPv6, UDP, and TCP Headers", RFC 4727, 493 DOI 10.17487/RFC4727, November 2006, 494 . 496 [RFC4782] Floyd, S., Allman, M., Jain, A., and P. Sarolahti, "Quick- 497 Start for TCP and IP", RFC 4782, DOI 10.17487/RFC4782, 498 January 2007, . 500 [RFC5095] Abley, J., Savola, P., and G. Neville-Neil, "Deprecation 501 of Type 0 Routing Headers in IPv6", RFC 5095, 502 DOI 10.17487/RFC5095, December 2007, 503 . 505 [RFC5201] Moskowitz, R., Nikander, P., Jokela, P., Ed., and T. 506 Henderson, "Host Identity Protocol", RFC 5201, 507 DOI 10.17487/RFC5201, April 2008, 508 . 510 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 511 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 512 DOI 10.17487/RFC5226, May 2008, 513 . 515 [RFC5533] Nordmark, E. and M. Bagnulo, "Shim6: Level 3 Multihoming 516 Shim Protocol for IPv6", RFC 5533, DOI 10.17487/RFC5533, 517 June 2009, . 519 [RFC5570] StJohns, M., Atkinson, R., and G. Thomas, "Common 520 Architecture Label IPv6 Security Option (CALIPSO)", 521 RFC 5570, DOI 10.17487/RFC5570, July 2009, 522 . 524 [RFC6275] Perkins, C., Ed., Johnson, D., and J. Arkko, "Mobility 525 Support in IPv6", RFC 6275, DOI 10.17487/RFC6275, July 526 2011, . 528 [RFC6398] Le Faucheur, F., Ed., "IP Router Alert Considerations and 529 Usage", BCP 168, RFC 6398, DOI 10.17487/RFC6398, October 530 2011, . 532 [RFC6550] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J., 533 Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur, 534 JP., and R. Alexander, "RPL: IPv6 Routing Protocol for 535 Low-Power and Lossy Networks", RFC 6550, 536 DOI 10.17487/RFC6550, March 2012, 537 . 539 [RFC6553] Hui, J. and JP. Vasseur, "The Routing Protocol for Low- 540 Power and Lossy Networks (RPL) Option for Carrying RPL 541 Information in Data-Plane Datagrams", RFC 6553, 542 DOI 10.17487/RFC6553, March 2012, 543 . 545 [RFC6554] Hui, J., Vasseur, JP., Culler, D., and V. Manral, "An IPv6 546 Routing Header for Source Routes with the Routing Protocol 547 for Low-Power and Lossy Networks (RPL)", RFC 6554, 548 DOI 10.17487/RFC6554, March 2012, 549 . 551 [RFC6621] Macker, J., Ed., "Simplified Multicast Forwarding", 552 RFC 6621, DOI 10.17487/RFC6621, May 2012, 553 . 555 [RFC6740] Atkinson, RJ. and SN. Bhatti, "Identifier-Locator Network 556 Protocol (ILNP) Architectural Description", RFC 6740, 557 DOI 10.17487/RFC6740, November 2012, 558 . 560 [RFC6744] Atkinson, RJ. and SN. Bhatti, "IPv6 Nonce Destination 561 Option for the Identifier-Locator Network Protocol for 562 IPv6 (ILNPv6)", RFC 6744, DOI 10.17487/RFC6744, November 563 2012, . 565 [RFC6788] Krishnan, S., Kavanagh, A., Varga, B., Ooghe, S., and E. 566 Nordmark, "The Line-Identification Option", RFC 6788, 567 DOI 10.17487/RFC6788, November 2012, 568 . 570 [RFC6971] Herberg, U., Ed., Cardenas, A., Iwao, T., Dow, M., and S. 571 Cespedes, "Depth-First Forwarding (DFF) in Unreliable 572 Networks", RFC 6971, DOI 10.17487/RFC6971, June 2013, 573 . 575 [RFC7045] Carpenter, B. and S. Jiang, "Transmission and Processing 576 of IPv6 Extension Headers", RFC 7045, 577 DOI 10.17487/RFC7045, December 2013, 578 . 580 [RFC7112] Gont, F., Manral, V., and R. Bonica, "Implications of 581 Oversized IPv6 Header Chains", RFC 7112, 582 DOI 10.17487/RFC7112, January 2014, 583 . 585 8.2. Informative References 587 [Biondi2007] 588 Biondi, P. and A. Ebalard, "IPv6 Routing Header Security", 589 CanSecWest 2007 Security Conference, 2007, 590 . 592 [I-D.ietf-roll-trickle-mcast] 593 Hui, J. and R. Kelsey, "Multicast Protocol for Low power 594 and Lossy Networks (MPL)", draft-ietf-roll-trickle- 595 mcast-12 (work in progress), June 2015. 597 [I-D.ietf-v6ops-ipv6-ehs-in-real-world] 598 Gont, F., Linkova, J., Chown, T., and S. LIU, 599 "Observations on IPv6 EH Filtering in the Real World", 600 draft-ietf-v6ops-ipv6-ehs-in-real-world-00 (work in 601 progress), April 2015. 603 [IANA-IPV6-PARAM] 604 Internet Assigned Numbers Authority, "Internet Protocol 605 Version 6 (IPv6) Parameters", December 2013, 606 . 609 [NIMROD-DOC] 610 Nimrod Documentation Page, , 611 "http://ana-3.lcs.mit.edu/~jnc/nimrod/". 613 [nimrod-eid] 614 Lynn, C., "Endpoint Identifier Destination Option", IETF 615 Internet Draft, draft-ietf-nimrod-eid-00.txt, November 616 1995. 618 [RFC3871] Jones, G., Ed., "Operational Security Requirements for 619 Large Internet Service Provider (ISP) IP Network 620 Infrastructure", RFC 3871, DOI 10.17487/RFC3871, September 621 2004, . 623 [RFC7126] Gont, F., Atkinson, R., and C. Pignataro, "Recommendations 624 on Filtering of IPv4 Packets Containing IPv4 Options", 625 BCP 186, RFC 7126, DOI 10.17487/RFC7126, February 2014, 626 . 628 Authors' Addresses 630 Fernando Gont 631 UTN-FRH / SI6 Networks 632 Evaristo Carriego 2644 633 Haedo, Provincia de Buenos Aires 1706 634 Argentina 636 Phone: +54 11 4650 8472 637 Email: fgont@si6networks.com 638 URI: http://www.si6networks.com 640 Will(Shucheng) Liu 641 Huawei Technologies 642 Bantian, Longgang District 643 Shenzhen 518129 644 P.R. China 646 Email: liushucheng@huawei.com 648 Ronald P. Bonica 649 Juniper Networks 650 2251 Corporate Park Drive 651 Herndon, VA 20171 652 US 654 Phone: 571 250 5819 655 Email: rbonica@juniper.net