idnits 2.17.1 draft-ietf-opsec-ipv6-eh-filtering-00.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 9, 2015) is 3335 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC4304' is defined on line 1253, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) ** Obsolete normative reference: RFC 5201 (Obsoleted by RFC 7401) == Outdated reference: A later version (-10) exists of draft-ietf-6man-predictable-fragment-id-02 == Outdated reference: A later version (-12) exists of draft-ietf-roll-trickle-mcast-11 Summary: 2 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 opsec F. Gont 3 Internet-Draft UTN-FRH / SI6 Networks 4 Intended status: Informational W. Liu 5 Expires: September 10, 2015 Huawei Technologies 6 R. Bonica 7 Juniper Networks 8 March 9, 2015 10 Recommendations on Filtering of IPv6 Packets Containing IPv6 Extension 11 Headers 12 draft-ietf-opsec-ipv6-eh-filtering-00.txt 14 Abstract 16 It is common operator practice to mitigate security risks by 17 enforcing appropriate packet filtering. This document analyzes both 18 the general security implications of IPv6 Extension Headers and the 19 specific security implications of each Extension Header and Option 20 type, and provides advice on the filtering of IPv6 packets based on 21 the IPv6 Extension Headers and the IPv6 options they contain. 22 Additionally, it discusses the operational and interoperability 23 implications of discarding packets based on the IPv6 Extension 24 Headers and IPv6 options they contain. 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at http://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on September 10, 2015. 43 Copyright Notice 45 Copyright (c) 2015 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 61 2. Terminology and Conventions Used in This Document . . . . . . 3 62 2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 63 2.2. Conventions . . . . . . . . . . . . . . . . . . . . . . . 4 64 3. IPv6 Extension Headers . . . . . . . . . . . . . . . . . . . 5 65 3.1. General Discussion . . . . . . . . . . . . . . . . . . . 5 66 3.2. General Security Implications . . . . . . . . . . . . . . 5 67 3.3. Advice on the Handling of IPv6 Packets with Specific IPv6 68 Extension Headers . . . . . . . . . . . . . . . . . . . . 6 69 3.4. Advice on the Handling of Packets with Unknown IPv6 70 Extension Headers . . . . . . . . . . . . . . . . . . . . 14 71 4. IPv6 Options . . . . . . . . . . . . . . . . . . . . . . . . 15 72 4.1. General Discussion . . . . . . . . . . . . . . . . . . . 15 73 4.2. General Security Implications of IPv6 Options . . . . . . 15 74 4.3. Advice on the Handling of Packets with Specific IPv6 75 Options . . . . . . . . . . . . . . . . . . . . . . . . . 15 76 4.4. Advice on the handling of Packets with Unknown IPv6 77 Options . . . . . . . . . . . . . . . . . . . . . . . . . 26 78 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 79 6. Security Considerations . . . . . . . . . . . . . . . . . . . 27 80 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 27 81 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 27 82 8.1. Normative References . . . . . . . . . . . . . . . . . . 27 83 8.2. Informative References . . . . . . . . . . . . . . . . . 29 84 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 31 86 1. Introduction 88 Recent studies (see e.g. [I-D.gont-v6ops-ipv6-ehs-in-real-world]) 89 suggest that there is widespread filtering of IPv6 packets that 90 contain IPv6 Extension Headers (EHs). While some operators 91 "officially" filter packets that contain IPv6 EHs, it is possible 92 that some of the measured packet drops be the result of improper 93 configuration defaults, or inappropriate advice in this area. 95 This document analyzes both the general security implications of IPv6 96 EHs and the specific security implications of each EH and Option 97 type, and provides advice on the filtering of IPv6 packets based on 98 the IPv6 EHs and the IPv6 options they contain. Since various 99 protocols may use IPv6 EHs (possibly with IPv6 options), discarding 100 packets based on the IPv6 EHs or IPv6 options they contain may have 101 implications on the proper functioning of such protocols. Thus, this 102 document also attempts to discuss the operational and 103 interoperability implications of such filtering policies. This 104 document is similar in nature to [RFC7126], which addresses the same 105 problem for the IPv4 case. However, in IPv6, the problem space is 106 compounded by the fact that IPv6 specifies a number of IPv6 EHs, and 107 a number of IPv6 options which may be valid only when included in 108 specific EH types. 110 This document completes and complements the considerations for 111 protecting the control plane from packets containing IP options that 112 can be found in [RFC6192]. 114 Section 2 of this document specifies the terminology and conventions 115 employed throughout this document. Section 3 of this document 116 discusses IPv6 EHs and provides advice in the area of filtering IPv6 117 packets that contain such IPv6 EHs. Section 4 of this document 118 discusses IPv6 options and provides advice in the area of filtering 119 IPv6 packets that contain such options. 121 2. Terminology and Conventions Used in This Document 123 2.1. Terminology 125 The terms "fast path", "slow path", and associated relative terms 126 ("faster path" and "slower path") are loosely defined as in Section 2 127 of [RFC6398]. 129 The terms "permit" (allow the traffic), "drop" (drop with no 130 notification to sender), and "reject" (drop with appropriate 131 notification to sender) are employed as defined in [RFC3871]. 132 Throughout this document we also employ the term "discard" as a 133 generic term to indicate the act of discarding a packet, irrespective 134 of whether the sender is notified of such drops, and irrespective of 135 whether the specific filtering action is logged. 137 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 138 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 139 document are to be interpreted as described in [RFC2119]. 141 2.2. Conventions 143 This document assumes that nodes comply with the requirements in 144 [RFC7045]. Namely (from [RFC7045]), 146 o If a forwarding node discards a packet containing a standard IPv6 147 EH, it MUST be the result of a configurable policy and not just 148 the result of a failure to recognise such a header. 150 o The discard policy for each standard type of EH MUST be 151 individually configurable. 153 o The default configuration SHOULD allow all standard IPv6 EHs. 155 The advice provided in this document is only meant to guide an 156 operator in configuring forwarding devices, and is *not* to be 157 interpreted as advice regarding default configuration settings for 158 network devices. That is, this document provides advice with respect 159 to operational configurations, but does not change the implementation 160 defaults required by [RFC7045] and 161 [draft-gont-6man-ipv6-opt-transmit]. We note that the advice 162 provided in this document is *not* meant to be employed by transit 163 routers for transit traffic, since such devices should not enforce 164 this type of filtering policy on traffic not directed to them. 166 We recommend that a configuration option is made available to govern 167 the processing of each IPv6 EH type and each IPv6 option type. Such 168 configuration options may include the following possible settings: 170 o Permit this IPv6 EH or IPv6 Option type 172 o Discard (and log) packets containing this IPv6 EH or option type 174 o Reject (and log) packets containing this IPv6 EH or option type 175 (where the packet drop is signaled with an ICMPv6 error message) 177 o Rate-limit traffic containing this IPv6 EH or option type 179 o Ignore this IPv6 EH or option type (as if it was not present) and 180 forward the packet. We noted that if a packet carries forwarding 181 information (e.g., in an IPv6 Routing Header) this might be an 182 inappropriate or undesirable action. 184 We note that special care needs to be taken when devices log packet 185 drops/rejects. Devices should count the number of packets dropped/ 186 rejected, but the logging of drop/reject events should be limited so 187 as to not overburden device resources. 189 Finally, we note that when discarding packets, it is generally 190 desirable that the sender be signaled of the packet drop, since this 191 is of use for trouble-shooting purposes. However, throughout this 192 document (when recommending that packets be discarded) we generically 193 refer to the action as "discard" without specifying whether the 194 sender is signaled of the packet drop. 196 3. IPv6 Extension Headers 198 3.1. General Discussion 200 IPv6 [RFC2460] EHs allow for the extension of the IPv6 protocol. 201 Since both IPv6 EHs and upper-layer protocols share the same 202 namespace ("Next Header" registry/namespace), [RFC7045] identifies 203 which of the currently assigned Internet Protocol numbers identify 204 IPv6 EHs vs. upper-layer protocols. This document discusses the 205 filtering of packets based on the IPv6 EHs (as specified by 206 [RFC7045]) they contain. 208 NOTE: [RFC7112] specifies that non-fragmented IPv6 datagrams and 209 IPv6 First-Fragments MUST contain the entire IPv6 header chain 210 [RFC7112]. Therefore, intermediate systems can enforce the 211 filtering policies discussed in this document, or resort to simply 212 discarding the offending packets when they fail to comply with the 213 requirements in [RFC7112]. We note that, in order to implement 214 filtering rules on the fast path, it may be necessary for the 215 filtering device to limit the depth into the packet that can be 216 inspected before giving up. In circumstances where there is such 217 a limitation, it is recommended that implementations discard 218 packets if, when trying to determine whether to discard or permit 219 a packet, the aforementioned limit is encountered. 221 3.2. General Security Implications 223 Depending on the specific device architecture, IPv6 packets that 224 contain IPv6 EHs may cause the corresponding packets to be processed 225 on the slow path, and hence may be leveraged for the purpose of 226 Denial of Service (DoS) attacks [Cisco-EH] [FW-Benchmark]. 228 Operators are urged to consider IPv6 EH filtering and IPv6 options 229 handling capabilities of different devices as they make deployment 230 decisions in future. 232 3.3. Advice on the Handling of IPv6 Packets with Specific IPv6 233 Extension Headers 235 3.3.1. IPv6 Hop-by-Hop Options (Protocol Number=0) 237 3.3.1.1. Uses 239 The Hop-by-Hop Options header is used to carry optional information 240 that should be examined by every node along a packet's delivery path. 242 3.3.1.2. Specification 244 This EH is specified in [RFC2460], and its processing rules have been 245 updated by [RFC7045]. At the time of this writing, the following 246 options have been specified for the Hop-by-Hop Options EH: 248 o Type 0x00: Pad1 [RFC2460] 250 o Type 0x01: PadN [RFC2460] 252 o Type 0x05: Router Alert [RFC2711] 254 o Type 0x07: CALIPSO [RFC5570] 256 o Type 0x08: SMF_DPD [RFC6621] 258 o Type 0x26: Quick-Start [RFC4782] 260 o Type 0x4D: (Deprecated) 262 o Type 0x63: RPL Option [RFC6553] 264 o Type 0x6D: MPL Option [I-D.ietf-roll-trickle-mcast] 266 o Type 0x8A: Endpoint Identification (Deprecated) 267 [draft-ietf-nimrod-eid] 269 o Type 0xC2: Jumbo Payload [RFC2675] 271 o Type 0xEE: IPv6 DFF Header [RFC6971] 273 o Type 0x1E: RFC3692-style Experiment [RFC4727] 275 o Type 0x3E: RFC3692-style Experiment [RFC4727] 277 o Type 0x5E: RFC3692-style Experiment [RFC4727] 279 o Type 0x7E: RFC3692-style Experiment [RFC4727] 280 o Type 0x9E: RFC3692-style Experiment [RFC4727] 282 o Type 0xBE: RFC3692-style Experiment [RFC4727] 284 o Type 0xDE: RFC3692-style Experiment [RFC4727] 286 o Type 0xFE: RFC3692-style Experiment [RFC4727] 288 3.3.1.3. Specific Security Implications 290 Since this EH should be processed by all intermediate-systems en 291 route, it can be leveraged to perform Denial of Service attacks 292 against the network infrastructure. 294 3.3.1.4. Operational and Interoperability Impact if Blocked 296 Discarding packets containing a Hop-by-Hop Option EH would break any 297 of the protocols that rely on it for proper functioning. For 298 example, it would break RSVP [RFC2205] and multicast deployments, and 299 would cause IPv6 jumbograms to be discarded. 301 3.3.1.5. Advice 303 The recommended configuration for the processing of these packets 304 depends on the features and capabilities of the underlying platform. 305 On platforms that allow forwarding of packets with HBH Options on the 306 fast path, we recommend that packets with a HBH Options EH be 307 forwarded as normal (for instance, [RFC7045] allows for 308 implementations to ignore the HBH Options EH when forwarding 309 packets). Otherwise, on platforms in which processing of packets 310 with a IPv6 HBH Options EH is carried out in the slow path, and an 311 option is provided to rate-limit these packets, we recommend that 312 this option be selected. Finally, when packets containing a HBH 313 Options EH are processed in the slow-path, and the underlying 314 platform does not have any mitigation options available for attacks 315 based on these packets, we recommend that such platforms discard 316 packets containing IPv6 HBH Options EHs. 318 Finally, we note that, for obvious reasons, RPL (Routing Protocol for 319 Low-Power and Lossy Networks) [RFC6550] routers must not discard 320 packets based on the presence of an IPv6 Hop-by-Hop Options EH. 322 3.3.2. Routing Header for IPv6 (Protocol Number=43) 323 3.3.2.1. Uses 325 The Routing header is used by an IPv6 source to list one or more 326 intermediate nodes to be "visited" on the way to a packet's 327 destination. 329 3.3.2.2. Specification 331 This EH is specified in [RFC2460]. [RFC2460] originally specified 332 the Routing Header Type 0, which has been later obsoleted by 333 [RFC5095]. 335 At the time of this writing, the following Routing Types have been 336 specified: 338 o Type 0: Source Route (DEPRECATED) [RFC2460] [RFC5095] 340 o Type 1: Nimrod (DEPRECATED) 342 o Type 2: Type 2 Routing Header [RFC6275] 344 o Type 3: RPL Source Route Header [RFC6554] 346 o Types 4-252: Unassigned 348 o Type 253: RFC3692-style Experiment 1 [RFC4727] 350 o Type 254: RFC3692-style Experiment 2 [RFC4727] 352 o Type 255: Reserved 354 3.3.2.3. Specific Security Implications 356 The security implications of RHT0 have been discussed in detail in 357 [Biondi2007] and [RFC5095]. 359 3.3.2.4. Operational and Interoperability Impact if Blocked 361 Blocking packets containing a RHT0 or RTH1 has no operational 362 implications. However, blocking packets employing other routing 363 header types will break the protocols that rely on them. 365 3.3.2.5. Advice 367 Intermediate systems should discard packets containing a RHT0 or 368 RHT1. RHT2 and RHT3 should be permitted, as required by [RFC7045]. 369 Other routing header types should be discarded. 371 3.3.3. Fragment Header for IPv6 (Protocol Number=44) 373 3.3.3.1. Uses 375 This EH provides the fragmentation functionality for IPv6. 377 3.3.3.2. Specification 379 This EH is specified in [RFC2460]. 381 3.3.3.3. Specific Security Implications 383 The security implications of the Fragment Header range from Denial of 384 Service attacks (e.g. based on flooding a target with IPv6 fragments) 385 to information leakage attacks 386 [I-D.ietf-6man-predictable-fragment-id]. 388 3.3.3.4. Operational and Interoperability Impact if Blocked 390 Blocking packets that contain a Fragment Header will break any 391 protocol that may rely on fragmentation (e.g., the DNS [RFC1034]). 393 3.3.3.5. Advice 395 Intermediate systems should permit packets that contain a Fragment 396 Header. 398 3.3.4. Encapsulating Security Payload (Protocol Number=50) 400 3.3.4.1. Uses 402 This EH is employed for the IPsec suite [RFC4303]. 404 3.3.4.2. Specification 406 This EH is specified in [RFC4303]. 408 3.3.4.3. Specific Security Implications 410 Besides the general implications of IPv6 EHs, this EH could be 411 employed to potentially perform a DoS attack at the destination 412 system by wasting CPU resources in validating the contents of the 413 packet. 415 3.3.4.4. Operational and Interoperability Impact if Blocked 417 Discarding packets that employ this EH would break IPsec deployments. 419 3.3.4.5. Advice 421 Intermediate systems should permit packets containing the 422 Encapsulating Security Payload EH. 424 3.3.5. Authentication Header (Number=51) 426 3.3.5.1. Uses 428 The Authentication Header can be employed for provide authentication 429 services in IPv4 and IPv6. 431 3.3.5.2. Specification 433 This EH is specified in [RFC4302]. 435 3.3.5.3. Specific Security Implications 437 Besides the general implications of IPv6 EHs, this EH could be 438 employed to potentially perform a DoS attack at the destination 439 system by wasting CPU resources in validating the contents of the 440 packet. 442 3.3.5.4. Operational and Interoperability Impact if Blocked 444 Discarding packets that employ this EH would break IPsec deployments. 446 3.3.5.5. Advice 448 Intermediate systems should permit packets containing an 449 Authentication Header. 451 3.3.6. Destination Options for IPv6 (Protocol Number=60) 453 3.3.6.1. Uses 455 The Destination Options header is used to carry optional information 456 that needs be examined only by a packet's destination node(s). 458 3.3.6.2. Specification 460 This EH is specified in [RFC2460]. At the time of this writing, the 461 following options have been specified for this EH: 463 o Type 0x00: Pad1 [RFC2460] 465 o Type 0x01: PadN [RFC2460] 467 o Type 0x04: Tunnel Encapsulation Limit [RFC2473] 469 o Type 0x4D: (Deprecated) 471 o Type 0xC9: Home Address [RFC6275] 473 o Type 0x8A: Endpoint Identification (Deprecated) 474 [draft-ietf-nimrod-eid] 476 o Type 0x8B: ILNP Nonce [RFC6744] 478 o Type 0x8C: Line-Identification Option [RFC6788] 480 o Type 0x1E: RFC3692-style Experiment [RFC4727] 482 o Type 0x3E: RFC3692-style Experiment [RFC4727] 484 o Type 0x5E: RFC3692-style Experiment [RFC4727] 486 o Type 0x7E: RFC3692-style Experiment [RFC4727] 488 o Type 0x9E: RFC3692-style Experiment [RFC4727] 490 o Type 0xBE: RFC3692-style Experiment [RFC4727] 492 o Type 0xDE: RFC3692-style Experiment [RFC4727] 494 o Type 0xFE: RFC3692-style Experiment [RFC4727] 496 3.3.6.3. Specific Security Implications 498 No security implications are known, other than the general 499 implications of IPv6 EHs. 501 3.3.6.4. Operational and Interoperability Impact if Blocked 503 Discarding packets that contain a Destination Options header would 504 break protocols that rely on this EH type for conveying information, 505 including protocols such as ILNP [RFC6740] and Mobile IPv6 [RFC6275], 506 and IPv6 tunnels that employ the Tunnel Encapsulation Limit option. 508 3.3.6.5. Advice 510 Intermediate systems should permit packets that contain a Destination 511 Options Header. 513 3.3.7. Mobility Header (Number=135) 515 3.3.7.1. Uses 517 The Mobility Header is an EH used by mobile nodes, correspondent 518 nodes, and home agents in all messaging related to the creation and 519 management of bindings in Mobile IPv6. 521 3.3.7.2. Specification 523 This EH is specified in [RFC6275]. 525 3.3.7.3. Specific Security Implications 527 TBD. 529 3.3.7.4. Operational and Interoperability Impact if Blocked 531 Discarding packets containing this EH would break Mobile IPv6. 533 3.3.7.5. Advice 535 Intermediate systems should permit packets containing this EH. 537 3.3.8. Host Identity Protocol (Protocol Number=139) 539 3.3.8.1. Uses 541 This EH is employed with the Host Identity Protocol (HIP), an 542 experimental protocol that allows consenting hosts to securely 543 establish and maintain shared IP-layer state, allowing separation of 544 the identifier and locator roles of IP addresses, thereby enabling 545 continuity of communications across IP address changes. 547 3.3.8.2. Specification 549 This EH is specified in [RFC5201]. 551 3.3.8.3. Specific Security Implications 553 TBD. 555 3.3.8.4. Operational and Interoperability Impact if Blocked 557 Discarding packets that contain the Host Identity Protocol would 558 break HIP deployments. 560 3.3.8.5. Advice 562 Intermediate systems should permit packets that contain a Host 563 Identity Protocol EH. 565 3.3.9. Shim6 Protocol (Protocol Number=140) 567 3.3.9.1. Uses 569 This EH is employed by the Shim6 [RFC5533] Protocol. 571 3.3.9.2. Specification 573 This EH is specified in [RFC5533]. 575 3.3.9.3. Specific Security Implications 577 TBD. 579 3.3.9.4. Operational and Interoperability Impact if Blocked 581 Discarding packets that contain this EH will break Shim6. 583 3.3.9.5. Advice 585 Intermediate systems should permit packets containing this EH. 587 3.3.10. Use for experimentation and testing (Protocol Numbers=253 and 588 254) 590 3.3.10.1. Uses 592 These IPv6 EHs are employed for performing RFC3692-Style experiments 593 (see [RFC3692] for details). 595 3.3.10.2. Specification 597 These EHs are specified in [RFC3692] and [RFC4727]. 599 3.3.10.3. Specific Security Implications 601 The security implications of these EHs will depend on their specific 602 use. 604 3.3.10.4. Operational and Interoperability Impact if Blocked 606 For obvious reasons, discarding packets that contain these EHs limits 607 the ability to perform legitimate experiments across IPv6 routers. 609 3.3.10.5. Advice 611 Intermediate systems should discard packets containing these EHs. 612 Only in specific scenarios in which RFC3692-Style experiments are to 613 be performed should these EHs be permitted. 615 3.4. Advice on the Handling of Packets with Unknown IPv6 Extension 616 Headers 618 We refer to IPv6 EHs that have not been assigned an Internet Protocol 619 Number by IANA (and marked as such) in [IANA-PROTOCOLS] as "unknown 620 IPv6 extension headers" ("unknown IPv6 EHs"). 622 3.4.1. Uses 624 New IPv6 EHs may be specified as part of future extensions to the 625 IPv6 protocol. 627 Since IPv6 EHs and Upper-layer protocols employ the same namespace, 628 it is impossible to tell whether an unknown "Internet Protocol 629 Number" is being employed for an IPv6 EH or an Upper-Layer protocol. 631 3.4.2. Specification 633 The processing of unknown IPv6 EHs is specified in [RFC2460] and 634 [RFC7045]. 636 3.4.3. Specific Security Implications 638 For obvious reasons, it is impossible to determine specific security 639 implications of unknown IPv6 EHs. However, from security standpoint, 640 a device should discard IPv6 extension headers for which the security 641 implications cannot be determined. We note that this policy is 642 allowed by [RFC7045]. 644 3.4.4. Operational and Interoperability Impact if Blocked 646 As noted in [RFC7045], discarding unknown IPv6 EHs may slow down the 647 deployment of new IPv6 EHs and transport protocols. The 648 corresponding IANA registry ([IANA-PROTOCOLS]) should be monitored 649 such that filtering rules are updated as new IPv6 EHs are 650 standardized. 652 We note that since IPv6 EHs and upper-layer protocols share the same 653 numbering space, discarding unknown IPv6 EHs may result in packets 654 encapsulating unknown upper-layer protocols being discarded. 656 3.4.5. Advice 658 Intermediate systems should discard packets containing unknown IPv6 659 EHs. 661 4. IPv6 Options 663 4.1. General Discussion 665 The following subsections describe specific security implications of 666 different IPv6 options, and provide advice regarding filtering 667 packets that contain such options. 669 4.2. General Security Implications of IPv6 Options 671 The general security implications of IPv6 options are closely related 672 to those discussed in Section 3.2 for IPv6 EHs. Essentially, packets 673 that contain IPv6 options might need to be processed by an IPv6 674 router's general-purpose CPU,and hence could present a DDoS risk to 675 that router's general-purpose CPU (and thus to the router itself). 676 For some architectures, a possible mitigation would be to rate-limit 677 the packets that are to be processed by the general-purpose CPU (see 678 e.g. [Cisco-EH]). 680 4.3. Advice on the Handling of Packets with Specific IPv6 Options 682 The following subsections contain a description of each of the IPv6 683 options that have so far been specified, a discussion of possible 684 interoperability implications if packets containing such options are 685 discarded, and specific advice regarding whether packets containing 686 these options should be permitted. 688 4.3.1. Pad1 (Type=0x00) 690 4.3.1.1. Uses 692 This option is used when necessary to align subsequent options and to 693 pad out the containing header to a multiple of 8 octets in length. 695 4.3.1.2. Specification 697 This option is specified in [RFC2460]. 699 4.3.1.3. Specific Security Implications 701 None. 703 4.3.1.4. Operational and Interoperability Impact if Blocked 705 Discarding packets that contain this option would potentially break 706 any protocol that relies on IPv6 EHs. 708 4.3.1.5. Advice 710 Intermediate systems should not discard packets based on the presence 711 of this option. 713 4.3.2. PadN (Type=0x01) 715 4.3.2.1. Uses 717 This option is used when necessary to align subsequent options and to 718 pad out the containing header to a multiple of 8 octets in length. 720 4.3.2.2. Specification 722 This option is specified in [RFC2460]. 724 4.3.2.3. Specific Security Implications 726 Because of the possible size of this option, it could be leveraged as 727 a large-bandwidth covert channel. 729 4.3.2.4. Operational and Interoperability Impact if Blocked 731 Discarding packets that contain this option would potentially break 732 any protocol that relies on IPv6 EHs. 734 4.3.2.5. Advice 736 Intermediate systems should not discard IPv6 packets based on the 737 presence of this option. 739 4.3.3. Jumbo Payload (Type=0XC2) 741 4.3.3.1. Uses 743 The Jumbo payload option provides the means of specifying payloads 744 larger than 65535 bytes. 746 4.3.3.2. Specification 748 This option is specified in [RFC2675]. 750 4.3.3.3. Specific Security Implications 752 TBD. 754 4.3.3.4. Operational and Interoperability Impact if Blocked 756 Discarding packets based on the presence of this option will cause 757 IPv6 jumbograms to be discarded. 759 4.3.3.5. Advice 761 Intermediate systems should discard packets that contain this option. 762 An operator should permit this option only in specific scenarios in 763 which support for IPv6 jumbograms is desired. 765 4.3.4. RPL Option (Type=0x63) 767 4.3.4.1. Uses 769 The RPL Option provides a mechanism to include routing information 770 with each datagram that an RPL router forwards. 772 4.3.4.2. Specification 774 This option is specified in [RFC6553]. 776 4.3.4.3. Specific Security Implications 778 TBD. 780 4.3.4.4. Operational and Interoperability Impact if Blocked 782 This option is meant to be employed within an RPL instance. As a 783 result, discarding packets based on the presence of this option (e.g. 784 at an ISP) will not result in interoperability implications. 786 4.3.4.5. Advice 788 Non-RPL routers should discard packets that contain an RPL option. 790 4.3.5. Tunnel Encapsulation Limit (Type=0x04) 792 4.3.5.1. Uses 794 The Tunnel Encapsulation Limit option can be employed to specify how 795 many further levels of nesting the packet is permitted to undergo. 797 4.3.5.2. Specification 799 This option is specified in [RFC2473]. 801 4.3.5.3. Specific Security Implications 803 TBD. 805 4.3.5.4. Operational and Interoperability Impact if Blocked 807 Discarding packets based on the presence of this option could result 808 in tunnel traffic being discarded. 810 4.3.5.5. Advice 812 Intermediate systems should not discard packets based on the presence 813 of this option. 815 4.3.6. Router Alert (Type=0x05) 817 4.3.6.1. Uses 819 The Router Alert option [RFC2711] is typically employed for the RSVP 820 protocol [RFC2205] and the MLD protocol [RFC2710]. 822 4.3.6.2. Specification 824 This option is specified in [RFC2711]. 826 4.3.6.3. Specific Security Implications 828 Since this option causes the contents of the packet to be inspected 829 by the handling device, this option could be leveraged for performing 830 DoS attacks. 832 4.3.6.4. Operational and Interoperability Impact if Blocked 834 Discarding packets that contain this option would break RSVP and 835 multicast deployments. 837 4.3.6.5. Advice 839 Intermediate systems should discard packets that contain this option. 840 Only in specific environments where support for RSVP, multicast 841 routing, or similar protocols is desired, should this option be 842 permitted. 844 4.3.7. Quick-Start (Type=0x26) 846 4.3.7.1. Uses 848 This IP Option is used in the specification of Quick-Start for TCP 849 and IP, which is an experimental mechanism that allows transport 850 protocols, in cooperation with routers, to determine an allowed 851 sending rate at the start and, at times, in the middle of a data 852 transfer (e.g., after an idle period) [RFC4782]. 854 4.3.7.2. Specification 856 This option is specified in [RFC4782], on the "Experimental" track. 858 4.3.7.3. Specific Security Implications 860 Section 9.6 of [RFC4782] notes that Quick-Start is vulnerable to two 861 kinds of attacks: 863 o attacks to increase the routers' processing and state load, and, 865 o attacks with bogus Quick-Start Requests to temporarily tie up 866 available Quick-Start bandwidth, preventing routers from approving 867 Quick-Start Requests from other connections. 869 We note that if routers in a given environment do not implement and 870 enable the Quick-Start mechanism, only the general security 871 implications of IP options (discussed in Section 4.2) would apply. 873 4.3.7.4. Operational and Interoperability Impact if Blocked 875 The Quick-Start functionality would be disabled, and additional 876 delays in TCP's connection establishment (for example) could be 877 introduced. (Please see Section 4.7.2 of [RFC4782].) We note, 878 however, that Quick-Start has been proposed as a mechanism that could 879 be of use in controlled environments, and not as a mechanism that 880 would be intended or appropriate for ubiquitous deployment in the 881 global Internet [RFC4782]. 883 4.3.7.5. Advice 885 Intermediate systems should not discard IPv6 packets based on the 886 presence of this option. 888 4.3.8. CALIPSO (Type=0x07) 890 4.3.8.1. Uses 892 This option is used for encoding explicit packet Sensitivity Labels 893 on IPv6 packets. It is intended for use only within Multi-Level 894 Secure (MLS) networking environments that are both trusted and 895 trustworthy. 897 4.3.8.2. Specification 899 This option is specified in [RFC5570]. 901 4.3.8.3. Specific Security Implications 903 Presence of this option in a packet does not by itself create any 904 specific new threat. Packets with this option ought not normally be 905 seen on the global public Internet. 907 4.3.8.4. Operational and Interoperability Impact if Blocked 909 If packets with this option are discarded or if the option is 910 stripped from the packet during transmission from source to 911 destination, then the packet itself is likely to be discarded by the 912 receiver because it is not properly labeled. In some cases, the 913 receiver might receive the packet but associate an incorrect 914 sensitivity label with the received data from the packet whose 915 CALIPSO was stripped by an intermediate router or firewall. 916 Associating an incorrect sensitivity label can cause the received 917 information either to be handled as more sensitive than it really is 918 ("upgrading") or as less sensitive than it really is ("downgrading"), 919 either of which is problematic. 921 4.3.8.5. Advice 923 Intermediate systems that do not operate in Multi-Level Secure (MLS) 924 networking environments should discard packets that contain this 925 option. 927 4.3.9. SMF_DPD (Type=0x08) 929 4.3.9.1. Uses 931 This option is employed in the (experimental) Simplified Multicast 932 Forwarding (SMF) for unique packet identification for IPv6 I-DPD, and 933 as a mechanism to guarantee non-collision of hash values for 934 different packets when H-DPD is used. 936 4.3.9.2. Specification 938 This option is specified in [RFC6621]. 940 4.3.9.3. Specific Security Implications 942 TBD. 944 4.3.9.4. Operational and Interoperability Impact if Blocked 946 TBD. 948 4.3.9.5. Advice 950 TBD. 952 4.3.10. Home Address (Type=0xC9) 954 4.3.10.1. Uses 956 The Home Address option is used by a Mobile IPv6 node while away from 957 home, to inform the recipient of the mobile node's home address. 959 4.3.10.2. Specification 961 This option is specified in [RFC6275]. 963 4.3.10.3. Specific Security Implications 965 TBD. 967 4.3.10.4. Operational and Interoperability Impact if Blocked 969 Discarding IPv6 packets based on the presence of this option will 970 break Mobile IPv6. 972 4.3.10.5. Advice 974 Intermediate systems should not discard IPv6 packets based on the 975 presence of this option. 977 4.3.11. Endpoint Identification (Type=0x8A) 979 4.3.11.1. Uses 981 The Endpoint Identification option was meant to be used with the 982 Nimrod routing architecture [NIMROD-DOC], but has never seen 983 widespread deployment. 985 4.3.11.2. Specification 987 This option is specified in [NIMROD-DOC]. 989 4.3.11.3. Specific Security Implications 991 TBD. 993 4.3.11.4. Operational and Interoperability Impact if Blocked 995 None. 997 4.3.11.5. Advice 999 Intermediate systems should discard packets that contain this option. 1001 4.3.12. ILNP Nonce (Type=0x8B) 1003 4.3.12.1. Uses 1005 This option is employed by Identifier-Locator Network Protocol for 1006 IPv6 (ILNPv6) for providing protection against off-path attacks for 1007 packets when ILNPv6 is in use, and as a signal during initial 1008 network-layer session creation that ILNPv6 is proposed for use with 1009 this network-layer session, rather than classic IPv6. 1011 4.3.12.2. Specification 1013 This option is specified in [RFC6744]. 1015 4.3.12.3. Specific Security Implications 1017 TBD. 1019 4.3.12.4. Operational and Interoperability Impact if Blocked 1021 Discarding packets that contain this option will break INLPv6 1022 deployments. 1024 4.3.12.5. Advice 1026 Intermediate systems should not discard packets based on the presence 1027 of this option. 1029 4.3.13. Line-Identification Option (Type=0x8C) 1031 4.3.13.1. Uses 1033 This option is used by an Edge Router to identify the subscriber 1034 premises in scenarios where several subscriber premises may be 1035 logically connected to the same interface of an Edge Router. 1037 4.3.13.2. Specification 1039 This option is specified in [RFC6788]. 1041 4.3.13.3. Specific Security Implications 1043 TBD. 1045 4.3.13.4. Operational and Interoperability Impact if Blocked 1047 Since this option is meant to be employed in Router Solicitation 1048 messages, discarding packets based on the presence of this option at 1049 intermediate systems will result in no interoperability implications. 1051 4.3.13.5. Advice 1053 Intermediate devices should discard packets that contain this option. 1055 4.3.14. Deprecated (Type=0x4D) 1057 4.3.14.1. Uses 1059 No information has been found about this option type. 1061 4.3.14.2. Specification 1063 No information has been found about this option type. 1065 4.3.14.3. Specific Security Implications 1067 No information has been found about this option type, and hence it 1068 has been impossible to perform the corresponding security assessment. 1070 4.3.14.4. Operational and Interoperability Impact if Blocked 1072 Unknown. 1074 4.3.14.5. Advice 1076 Intermediate systems should discard packets that contain this option. 1078 4.3.15. MPL Option (Type=0x6D) 1080 4.3.15.1. Uses 1082 This option is used with the Multicast Protocol for Low power and 1083 Lossy Networks (MPL), that provides IPv6 multicast forwarding in 1084 constrained networks. 1086 4.3.15.2. Specification 1088 This option is specified in [I-D.ietf-roll-trickle-mcast], and is 1089 meant to be included only in Hop-by-Hop Option headers. 1091 4.3.15.3. Specific Security Implications 1093 TBD. 1095 4.3.15.4. Operational and Interoperability Impact if Blocked 1097 TBD. 1099 4.3.15.5. Advice 1101 TBD. 1103 4.3.16. IP_DFF (Type=0xEE) 1105 4.3.16.1. Uses 1107 This option is employed with the (Experimental) Depth-First 1108 Forwarding (DFF) in Unreliable Networks. 1110 4.3.16.2. Specification 1112 This option is specified in [RFC6971]. 1114 4.3.16.3. Specific Security Implications 1116 TBD. 1118 4.3.16.4. Operational and Interoperability Impact if Blocked 1120 TBD. 1122 4.3.16.5. Advice 1124 TBD. 1126 4.3.17. RFC3692-style Experiment (Types = 0x1E, 0x3E, 0x5E, 0x7E, 0x9E, 1127 0xBE, 0xDE, 0xFE) 1129 4.3.17.1. Uses 1131 These options can be employed for performing RFC3692-style 1132 experiments. It is only appropriate to use these values in 1133 explicitly configured experiments; they must not be shipped as 1134 defaults in implementations. 1136 4.3.17.2. Specification 1138 Specified in RFC 4727 [RFC4727] in the context of RFC3692-style 1139 experiments. 1141 4.3.17.3. Specific Security Implications 1143 The specific security implications will depend on the specific use of 1144 these options. 1146 4.3.17.4. Operational and Interoperability Impact if Blocked 1148 For obvious reasons, discarding packets that contain these options 1149 limits the ability to perform legitimate experiments across IPv6 1150 routers. 1152 4.3.17.5. Advice 1154 Intermediate systems should discard packets that contain these 1155 options. Only in specific environments where RFC3692-style 1156 experiments are meant to be performed should these options be 1157 permitted. 1159 4.4. Advice on the handling of Packets with Unknown IPv6 Options 1161 We refer to IPv6 options that have not been assigned an IPv6 option 1162 type in the corresponding registry ([IANA-IPV6-PARAM]) as "unknown 1163 IPv6 options". 1165 4.4.1. Uses 1167 New IPv6 options may be specified as part of future protocol work. 1169 4.4.2. Specification 1171 The processing of unknown IPv6 options is specified in [RFC2460]. 1173 4.4.3. Specific Security Implications 1175 For obvious reasons, it is impossible to determine specific security 1176 implications of unknown IPv6 options. 1178 4.4.4. Operational and Interoperability Impact if Blocked 1180 Discarding unknown IPv6 options may slow down the deployment of new 1181 IPv6 options. As noted in [draft-gont-6man-ipv6-opt-transmit], the 1182 corresponding IANA registry ([IANA-IPV6-PARAM] should be monitored 1183 such that IPv6 option filtering rules are updated as new IPv6 options 1184 are standardized. 1186 4.4.5. Advice 1188 Enterprise intermediate systems that process the contents of IPv6 EHs 1189 should discard packets that contain unknown options. Other 1190 intermediate systems that process the contents of IPv6 EHs should 1191 permit packets that contain unknown options. 1193 5. IANA Considerations 1195 This document has no actions for IANA. 1197 6. Security Considerations 1199 This document provides advice on the filtering of IPv6 packets that 1200 contain IPv6 EHs (and possibly IPv6 options). Discarding such 1201 packets can help to mitigate the security issues that arise from the 1202 use of different IPv6 EHs and options. 1204 7. Acknowledgements 1206 The authors of this document would like to thank (in alphabetical 1207 order) Mikael Abrahamsson, Brian Carpenter, Mike Heard, Jen Linkova, 1208 Carlos Pignataro, Donald Smith, and Gunter Van De Velde, for 1209 providing valuable comments on earlier versions of this document. 1211 This document borrows some text an analysis from [RFC7126], authored 1212 by Fernando Gont, Randall Atkinson, and Carlos Pignataro. 1214 8. References 1216 8.1. Normative References 1218 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 1219 STD 13, RFC 1034, November 1987. 1221 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1222 Requirement Levels", BCP 14, RFC 2119, March 1997. 1224 [RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S. 1225 Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 1226 Functional Specification", RFC 2205, September 1997. 1228 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 1229 (IPv6) Specification", RFC 2460, December 1998. 1231 [RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in 1232 IPv6 Specification", RFC 2473, December 1998. 1234 [RFC2675] Borman, D., Deering, S., and R. Hinden, "IPv6 Jumbograms", 1235 RFC 2675, August 1999. 1237 [RFC2710] Deering, S., Fenner, W., and B. Haberman, "Multicast 1238 Listener Discovery (MLD) for IPv6", RFC 2710, October 1239 1999. 1241 [RFC2711] Partridge, C. and A. Jackson, "IPv6 Router Alert Option", 1242 RFC 2711, October 1999. 1244 [RFC3692] Narten, T., "Assigning Experimental and Testing Numbers 1245 Considered Useful", BCP 82, RFC 3692, January 2004. 1247 [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, December 1248 2005. 1250 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 1251 4303, December 2005. 1253 [RFC4304] Kent, S., "Extended Sequence Number (ESN) Addendum to 1254 IPsec Domain of Interpretation (DOI) for Internet Security 1255 Association and Key Management Protocol (ISAKMP)", RFC 1256 4304, December 2005. 1258 [RFC4727] Fenner, B., "Experimental Values In IPv4, IPv6, ICMPv4, 1259 ICMPv6, UDP, and TCP Headers", RFC 4727, November 2006. 1261 [RFC4782] Floyd, S., Allman, M., Jain, A., and P. Sarolahti, "Quick- 1262 Start for TCP and IP", RFC 4782, January 2007. 1264 [RFC5095] Abley, J., Savola, P., and G. Neville-Neil, "Deprecation 1265 of Type 0 Routing Headers in IPv6", RFC 5095, December 1266 2007. 1268 [RFC5201] Moskowitz, R., Nikander, P., Jokela, P., and T. Henderson, 1269 "Host Identity Protocol", RFC 5201, April 2008. 1271 [RFC5533] Nordmark, E. and M. Bagnulo, "Shim6: Level 3 Multihoming 1272 Shim Protocol for IPv6", RFC 5533, June 2009. 1274 [RFC5570] StJohns, M., Atkinson, R., and G. Thomas, "Common 1275 Architecture Label IPv6 Security Option (CALIPSO)", RFC 1276 5570, July 2009. 1278 [RFC6275] Perkins, C., Johnson, D., and J. Arkko, "Mobility Support 1279 in IPv6", RFC 6275, July 2011. 1281 [RFC6398] Le Faucheur, F., "IP Router Alert Considerations and 1282 Usage", BCP 168, RFC 6398, October 2011. 1284 [RFC6550] Winter, T., Thubert, P., Brandt, A., Hui, J., Kelsey, R., 1285 Levis, P., Pister, K., Struik, R., Vasseur, JP., and R. 1286 Alexander, "RPL: IPv6 Routing Protocol for Low-Power and 1287 Lossy Networks", RFC 6550, March 2012. 1289 [RFC6553] Hui, J. and JP. Vasseur, "The Routing Protocol for Low- 1290 Power and Lossy Networks (RPL) Option for Carrying RPL 1291 Information in Data-Plane Datagrams", RFC 6553, March 1292 2012. 1294 [RFC6554] Hui, J., Vasseur, JP., Culler, D., and V. Manral, "An IPv6 1295 Routing Header for Source Routes with the Routing Protocol 1296 for Low-Power and Lossy Networks (RPL)", RFC 6554, March 1297 2012. 1299 [RFC6621] Macker, J., "Simplified Multicast Forwarding", RFC 6621, 1300 May 2012. 1302 [RFC6740] Atkinson,, RJ., "Identifier-Locator Network Protocol 1303 (ILNP) Architectural Description", RFC 6740, November 1304 2012. 1306 [RFC6744] Atkinson,, RJ., "IPv6 Nonce Destination Option for the 1307 Identifier-Locator Network Protocol for IPv6 (ILNPv6)", 1308 RFC 6744, November 2012. 1310 [RFC6788] Krishnan, S., Kavanagh, A., Varga, B., Ooghe, S., and E. 1311 Nordmark, "The Line-Identification Option", RFC 6788, 1312 November 2012. 1314 [RFC6971] Herberg, U., Cardenas, A., Iwao, T., Dow, M., and S. 1315 Cespedes, "Depth-First Forwarding (DFF) in Unreliable 1316 Networks", RFC 6971, June 2013. 1318 [RFC7045] Carpenter, B. and S. Jiang, "Transmission and Processing 1319 of IPv6 Extension Headers", RFC 7045, December 2013. 1321 [RFC7112] Gont, F., Manral, V., and R. Bonica, "Implications of 1322 Oversized IPv6 Header Chains", RFC 7112, January 2014. 1324 [draft-gont-6man-ipv6-opt-transmit] 1325 Gont, F., Liu, W., and R. Bonica, "Transmission and 1326 Processing of IPv6 Options", IETF Internet Draft, work in 1327 progress, August 2014. 1329 8.2. Informative References 1331 [Biondi2007] 1332 Biondi, P. and A. Ebalard, "IPv6 Routing Header Security", 1333 CanSecWest 2007 Security Conference, 2007, 1334 . 1336 [Cisco-EH] 1337 Cisco Systems, , "IPv6 Extension Headers Review and 1338 Considerations", Whitepaper. October 2006, 1339 . 1342 [FW-Benchmark] 1343 Zack, E., "Firewall Security Assessment and Benchmarking 1344 IPv6 Firewall Load Tests", IPv6 Hackers Meeting #1, 1345 Berlin, Germany. June 30, 2013, 1346 . 1350 [I-D.gont-v6ops-ipv6-ehs-in-real-world] 1351 Gont, F., Linkova, J., Chown, T., and W. Will, 1352 "Observations on IPv6 EH Filtering in the Real World", 1353 draft-gont-v6ops-ipv6-ehs-in-real-world-02 (work in 1354 progress), March 2015. 1356 [I-D.ietf-6man-predictable-fragment-id] 1357 Gont, F., "Security Implications of Predictable Fragment 1358 Identification Values", draft-ietf-6man-predictable- 1359 fragment-id-02 (work in progress), December 2014. 1361 [I-D.ietf-roll-trickle-mcast] 1362 Hui, J. and R. Kelsey, "Multicast Protocol for Low power 1363 and Lossy Networks (MPL)", draft-ietf-roll-trickle- 1364 mcast-11 (work in progress), November 2014. 1366 [IANA-IPV6-PARAM] 1367 Internet Assigned Numbers Authority, "Internet Protocol 1368 Version 6 (IPv6) Parameters", December 2013, 1369 . 1372 [IANA-PROTOCOLS] 1373 Internet Assigned Numbers Authority, "Protocol Numbers", 1374 2014, . 1377 [NIMROD-DOC] 1378 Nimrod Documentation Page, , 1379 "http://ana-3.lcs.mit.edu/~jnc/nimrod/", . 1381 [RFC3871] Jones, G., "Operational Security Requirements for Large 1382 Internet Service Provider (ISP) IP Network 1383 Infrastructure", RFC 3871, September 2004. 1385 [RFC6192] Dugal, D., Pignataro, C., and R. Dunn, "Protecting the 1386 Router Control Plane", RFC 6192, March 2011. 1388 [RFC7126] Gont, F., Atkinson, R., and C. Pignataro, "Recommendations 1389 on Filtering of IPv4 Packets Containing IPv4 Options", BCP 1390 186, RFC 7126, February 2014. 1392 [draft-ietf-nimrod-eid] 1393 Lynn, C., "Endpoint Identifier Destination Option", IETF 1394 Internet Draft, draft-ietf-nimrod-eid-00.txt, November 1395 1995. 1397 Authors' Addresses 1399 Fernando Gont 1400 UTN-FRH / SI6 Networks 1401 Evaristo Carriego 2644 1402 Haedo, Provincia de Buenos Aires 1706 1403 Argentina 1405 Phone: +54 11 4650 8472 1406 Email: fgont@si6networks.com 1407 URI: http://www.si6networks.com 1409 Will(Shucheng) Liu 1410 Huawei Technologies 1411 Bantian, Longgang District 1412 Shenzhen 518129 1413 P.R. China 1415 Email: liushucheng@huawei.com 1417 Ronald P. Bonica 1418 Juniper Networks 1419 2251 Corporate Park Drive 1420 Herndon, VA 20171 1421 US 1423 Phone: 571 250 5819 1424 Email: rbonica@juniper.net