One document matched: draft-gont-6man-ipv6-opt-transmit-01.txt
Differences from draft-gont-6man-ipv6-opt-transmit-00.txt
6man F. Gont
Internet-Draft UTN-FRH / SI6 Networks
Updates: 2460 (if approved) W. Liu
Intended status: Best Current Practice Huawei Technologies
Expires: September 10, 2015 R. Bonica
Juniper Networks
March 9, 2015
Transmission and Processing of IPv6 Options
draft-gont-6man-ipv6-opt-transmit-01.txt
Abstract
Various IPv6 options have been standardized since the core IPv6
standard was first published. This document updates RFC 2460 to
clarify how nodes should deal with such IPv6 options and with any
options that are defined in the future. It complements [RFC7045],
which offers a similar clarification regarding IPv6 Extension
Headers.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 10, 2015.
Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
Gont, et al. Expires September 10, 2015 [Page 1]
Internet-Draft Transm. and Proc. of IPv6 Options March 2015
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction and Problem Statement . . . . . . . . . . . . . 2
2. Terminology and Conventions Used in This Document . . . . . . 3
2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
2.2. Conventions . . . . . . . . . . . . . . . . . . . . . . . 3
3. Considerations for All IPv6 Options . . . . . . . . . . . . . 4
4. Processing of currently-defined IPv6 Options . . . . . . . . 5
4.1. Hop-by-Hop Options Header . . . . . . . . . . . . . . . . 5
4.2. Destination Options Header . . . . . . . . . . . . . . . 7
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
6. Security Considerations . . . . . . . . . . . . . . . . . . . 10
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
8.1. Normative References . . . . . . . . . . . . . . . . . . 10
8.2. Informative References . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13
1. Introduction and Problem Statement
Various IPv6 options have been standardized since the core IPv6
standard [RFC2460] was first published. Except for the padding
options (Pad1 and PadN), all the options that have so far been
specified are meant to be employed with specific IPv6 extension
header types. Additionally, some options have specific requirements
such as, for example, only allowing a single instance of the option
in the corresponding IPv6 extension header (EH). This establishes
some criteria for validating packets that employ IPv6 options.
[RFC2460] specifies that IPv6 extension headers (with the exception
of the Hop-by-Hop Options extension header) are not examined or
processed by any node along a packet's delivery path, until the
packet reaches the node (or each of the set of nodes, in the case of
multicast) identified in the Destination Address field of the IPv6
header. However, in practice this is not really the case: some
routers, and a variety of middleboxes such as firewalls, load
balancers, or packet classifiers, might inspect other parts of each
packet [RFC7045]. Hence both end-nodes an intermediate nodes may end
up inspecting the contents of extension headers and discard packets
based on the presence of specific IPv6 options.
This document clarifies the default processing of IPv6 options. In
those cases in which the specifications add additional constraints/
Gont, et al. Expires September 10, 2015 [Page 2]
Internet-Draft Transm. and Proc. of IPv6 Options March 2015
requirements regarding IPv6 options, such additional constraints/
requirements are also taken into account.
2. Terminology and Conventions Used in This Document
2.1. Terminology
In the remainder of this document, the term "forwarding node" refers
to any router, firewall, load balancer, prefix translator, or any
other device or middlebox that forwards IPv6 packets with or without
examining the packet in any way.
In this document, "standard" IPv6 options are those specified in
detail by IETF Standards Actions [RFC5226]. "Experimental" options
include those defined by any Experimental RFC and the option types
0x1E, 0x3E, 0x5E, 0x7E, 0x9E, 0xBE, 0xDE, and 0xFE, defined by
[RFC3692] and [RFC4727] when used as experimental options. "Defined"
options are the "standard" options plus the "experimental" ones.
The terms "permit" (allow the traffic), "drop" (drop with no
notification to sender), and "reject" (drop with appropriate
notification to sender) are employed as defined in [RFC3871].
Throughout this document we also employ the term "discard" as a
generic term to indicate the act of discarding a packet, irrespective
of whether the sender is notified of such packet drops.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
2.2. Conventions
This document clarifies some basic validation of IPv6 options, and
specifies the default processing of them. We recommend that a
configuration option is made available to govern the processing of
each IPv6 option type, on a per-EH-type granularity. Such
configuration options may include the following possible settings:
o Permit this IPv6 Option type
o Drop (and log) packets containing this IPv6 option type
o Reject (and log) packets containing this IPv6 option type (where
the packet drop is signaled with an ICMPv6 error message)
o Rate-limit the processing of packets containing this IPv6 option
type
Gont, et al. Expires September 10, 2015 [Page 3]
Internet-Draft Transm. and Proc. of IPv6 Options March 2015
o Ignore this IPv6 option type (forwarding packets that contain
them)
We note that special care needs to be taken when devices log packet
drops/rejects. Devices should count the number of packets dropped/
rejected, but the logging of drop/reject events should be limited so
as to not overburden device resources.
Finally, we note that when discarding packets, it is generally
desirable that the sender be signaled of the packet drop, since this
is of use for trouble-shooting purposes. However, throughout this
document (when recommending that packets be discarded) we generically
refer to the action as "discard" without specifying whether the
sender is signaled of the packet drop.
3. Considerations for All IPv6 Options
Forwarding nodes that discard packets (by default) based on the
presence of IPv6 options are known to cause connectivity failures and
deployment problems. Any forwarding node along an IPv6 packet's
path, which forwards the packet for any reason, SHOULD do so
regardless of any IPv6 Destination Options that are present, as
required by [RFC2460]. Exceptionally, if a forwarding node is
designed to examine IPv6 Destination Options for any reason, such as
firewalling, it MUST recognise and deal appropriately with all
standard IPv6 options types and SHOULD recognise and deal
appropriately with all experimental IPv6 options. The list of
standard and experimental option types is maintained by IANA (see
[IANA-IPV6-PARAM]), and implementors are advised to check this list
regularly for updates.
In the case of some options meant to be included in IPv6 extension
headers other than Hop-by-Hop Options, [RFC2460] requires destination
hosts to discard the corresponding packet if the option is
unrecognised. However, intermediate forwarding nodes SHOULD NOT do
this, since that might cause them to inadvertently discard traffic
using a recently standardised IPv6 option not yet recognised by the
intermediate node. The exceptions to this rule are discussed next.
If a forwarding node discards a packet containing a standard IPv6
option, it MUST be the result of a configurable policy and not just
the result of a failure to recognise such an option. This means that
the discard policy for each standard type of IPv6 option MUST be
individually configurable. The default configuration SHOULD allow
all standard IPv6 options.
Gont, et al. Expires September 10, 2015 [Page 4]
Internet-Draft Transm. and Proc. of IPv6 Options March 2015
Experimental IPv6 options SHOULD be treated in the same way as
standard IPv6 options, including an individually configurable discard
policy.
A node that processes the contents of an extension header MUST
discard the corresponding packet if it contains any defined options
that are not meant for the extension header being processed.
A node that processes the contents of an IPv6 extension header SHOULD
discard the corresponding packet if it contains any options that have
become deprecated.
A node that processes the contents of an extension header and
encounters an undefined (unrecognised) IPv6 option MUST react to such
option according to the highest-order two bits of the option type, as
specified by Section 4.2 of [RFC2460].
A node that processes an IPv6 extension header MAY discard a packet
containing any experimental IPv6 options.
4. Processing of currently-defined IPv6 Options
The following subsections provide advice on how to process the IPv6
options that have been defined at the time of this writing, according
to the rules specified in the previous sections.
4.1. Hop-by-Hop Options Header
A node that processes the Hop-by-Hop Options extension header MUST
discard the corresponding packet if it contains any of the following
options in that header:
o Type 0x04: Tunnel Encapsulation Limit [RFC2473]
o Type 0xC9: Home Address [RFC6275]
o Type 0x8B: ILNP Nonce [RFC6744]
o Type 0x8C: Line-Identification Option [RFC6788]
o Type 0x8A: Endpoint Identification [nimrod-eid] [NIMROD-DOC]
NOTE: The rationale for discarding packets containing these
options is that these options are meant to be used only with the
Destination Options header
Gont, et al. Expires September 10, 2015 [Page 5]
Internet-Draft Transm. and Proc. of IPv6 Options March 2015
A node that processes the Hop-by-Hop Options extension header MUST
discard a packet containing multiple instances (i.e., more than one)
of this option in the Hop-by-Hop Options extension header:
o Type 0x05: Router Alert [RFC2711]
NOTE: The rationale for discarding the packet is that [RFC2711]
forbids multiple instances of this option.
A node that processes the Hop-by-Hop Options extension header MUST
discard a packet that carries a Fragment Header and also contains
this option in the Hop-by-Hop Options extension header:
o Type 0xC2: Jumbo Payload [RFC2675]
NOTE: The rationale for discarding the packet is that [RFC2675]
forbids the use of the Jumbo Payload Option in packets that carry
a Fragment Header.
A node that processes the Hop-by-Hop Options extension header SHOULD
discard a packet containing any of the following options in that
header:
o Type=0x4D: Deprecated
NOTE: The rationale for discarding the packet is that the
aforementioned option has been deprecated.
A node that processes the Hop-by-Hop Options extension header MAY
discard a packet containing any of the following options in that
header:
o Type 0x1E: RFC3692-style Experiment [RFC4727]
o Type 0x3E: RFC3692-style Experiment [RFC4727]
o Type 0x5E: RFC3692-style Experiment [RFC4727]
o Type 0x7E: RFC3692-style Experiment [RFC4727]
o Type 0x9E: RFC3692-style Experiment [RFC4727]
o Type 0xBE: RFC3692-style Experiment [RFC4727]
o Type 0xDE: RFC3692-style Experiment [RFC4727]
o Type 0xFE: RFC3692-style Experiment [RFC4727]
Gont, et al. Expires September 10, 2015 [Page 6]
Internet-Draft Transm. and Proc. of IPv6 Options March 2015
NOTE: This is in line with the corresponding specification in
[RFC7045] for experimental extension headers.
4.2. Destination Options Header
A node that processes the Destination Options header MUST discard a
packet containing any of the following options in that header:
o Type 0x05: Router Alert [RFC2711]
o Type 0xC2: Jumbo Payload [RFC2675]
o Type 0x63: RPL Option [RFC6553]
o Type 0x08: SMF_DPD [RFC6621]
o Type 0x6D: MPL Option [I-D.ietf-roll-trickle-mcast]
o Type 0xEE: IPv6 DFF Header [RFC6971]
o Type 0x26: Quick-Start [RFC4782]
o Type 0x07: CALIPSO [RFC5570]
NOTE: The rationale for discarding packets containing these
options is that these options are meant to be used only with the
Hop by Hop Options header.
A node that processes the Destination Options extension header SHOULD
discard a packet containing any of the following options in that
header:
o Type 0x8A: Endpoint Identification [nimrod-eid] [NIMROD-DOC]
o Type 0x4D: Deprecated
NOTE: The rationale for discarding the packet is that the
aforementioned options have been deprecated.
A node that processes the Destination Options extension header MAY
discard a packet containing any of the following options in that
header:
o Type 0x1E: RFC3692-style Experiment [RFC4727]
o Type 0x3E: RFC3692-style Experiment [RFC4727]
o Type 0x5E: RFC3692-style Experiment [RFC4727]
Gont, et al. Expires September 10, 2015 [Page 7]
Internet-Draft Transm. and Proc. of IPv6 Options March 2015
o Type 0x7E: RFC3692-style Experiment [RFC4727]
o Type 0x9E: RFC3692-style Experiment [RFC4727]
o Type 0xBE: RFC3692-style Experiment [RFC4727]
o Type 0xDE: RFC3692-style Experiment [RFC4727]
o Type 0xFE: RFC3692-style Experiment [RFC4727]
NOTE: This is in line with the corresponding specification in
[RFC7045] for experimental extension headers.
5. IANA Considerations
IANA is requested to add an extra column entitled "Extension Header
Type" to the "Destination Options and Hop-by-Hop Options" registry
[IANA-IPV6-PARAM], to clearly mark the IPv6 Extension Header for
which each option (defined by IETF Standards Action or IESG Approval)
is valid (see the list below). This also applies to Destination
Options and Hop-by-Hop Options defined in the future.
What follows is the initial list of IPv6 options and the
corresponding marks that indicate which Extension Header type(s)
these IPv6 options are valid for:
+------+---------------------+-------------------------------+------+
| Hex | Description | Reference | EH |
| Valu | | | Type |
| e | | | |
+------+---------------------+-------------------------------+------+
| 0x00 | Pad1 | [RFC2460] | DH |
+------+---------------------+-------------------------------+------+
| 0x01 | PadN | [RFC2460] | DH |
+------+---------------------+-------------------------------+------+
| 0xC2 | Jumbo Payload | [RFC2675] | H |
+------+---------------------+-------------------------------+------+
| 0x63 | RPL Option | [RFC6553] | H |
+------+---------------------+-------------------------------+------+
| 0x04 | Tunnel | [RFC2473] | D |
| | Encapsulation Limit | | |
+------+---------------------+-------------------------------+------+
| 0x05 | Router Alert | [RFC2711] | H |
+------+---------------------+-------------------------------+------+
| 0x26 | Quick-Start | [RFC4782] | H |
+------+---------------------+-------------------------------+------+
| 0x07 | CALIPSO | [RFC5570] | H |
+------+---------------------+-------------------------------+------+
Gont, et al. Expires September 10, 2015 [Page 8]
Internet-Draft Transm. and Proc. of IPv6 Options March 2015
| 0x08 | SMF_DPD | [RFC6621] | H |
+------+---------------------+-------------------------------+------+
| 0xC9 | Home Address | [RFC6275] | D |
+------+---------------------+-------------------------------+------+
| 0x8A | Endpoint | [nimrod-eid][NIMROD-DOC] | D |
| | Identification | | |
+------+---------------------+-------------------------------+------+
| 0x8B | ILNP Nonce | [RFC6744] | D |
+------+---------------------+-------------------------------+------+
| 0x8C | Line-Identification | [RFC6788] | D |
| | Option | | |
+------+---------------------+-------------------------------+------+
| 0x4D | Deprecated | | U |
+------+---------------------+-------------------------------+------+
| 0x6D | MPL Option | [I-D.ietf-roll-trickle-mcast] | H |
+------+---------------------+-------------------------------+------+
| 0xEE | IPv6 DFF Header | [RFC6971] | H |
+------+---------------------+-------------------------------+------+
| 0x1E | RFC3692-style | [RFC4727] | DH |
| | Experiment | | |
+------+---------------------+-------------------------------+------+
| 0x3E | RFC3692-style | [RFC4727] | DH |
| | Experiment | | |
+------+---------------------+-------------------------------+------+
| 0x5E | RFC3692-style | [RFC4727] | DH |
| | Experiment | | |
+------+---------------------+-------------------------------+------+
| 0x7E | RFC3692-style | [RFC4727] | DH |
| | Experiment | | |
+------+---------------------+-------------------------------+------+
| 0x9E | RFC3692-style | [RFC4727] | DH |
| | Experiment | | |
+------+---------------------+-------------------------------+------+
| 0xBE | RFC3692-style | [RFC4727] | DH |
| | Experiment | | |
+------+---------------------+-------------------------------+------+
| 0xDE | RFC3692-style | [RFC4727] | DH |
| | Experiment | | |
+------+---------------------+-------------------------------+------+
| 0xFE | RFC3692-style | [RFC4727] | DH |
| | Experiment | | |
+------+---------------------+-------------------------------+------+
Additionally, the following legend should be added to the registry:
D: Destination Options Header
H: Hop-by-Hop Options Header
U: Unknown
Gont, et al. Expires September 10, 2015 [Page 9]
Internet-Draft Transm. and Proc. of IPv6 Options March 2015
6. Security Considerations
Forwarding nodes that operate as firewalls MUST conform to the
requirements in this document. In particular, packets containing
standard IPv6 options are only to be discarded as a result of an
intentionally configured policy.
These requirements do not affect a firewall's ability to filter out
traffic containing unwanted or suspect IPv6 options, if configured to
do so. However, the changes do require firewalls to be capable of
permitting any or all IPv6 options, if configured to do so. The
default configurations are intended to allow normal use of any
standard IPv6 option, avoiding the interoperability issues described
in Section 1 and Section 3.
As noted above, the default configuration might discard packets
containing experimental IPv6 options.
7. Acknowledgements
This document is heavily based on [RFC7045], authored by Brian
Carpenter and Sheng Jiang.
The authors of this document would like to thank (in alphabetical
order) Mike Heard, for providing valuable comments on earlier
versions of this document.
8. References
8.1. Normative References
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
STD 13, RFC 1034, November 1987.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S.
Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1
Functional Specification", RFC 2205, September 1997.
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, December 1998.
[RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in
IPv6 Specification", RFC 2473, December 1998.
Gont, et al. Expires September 10, 2015 [Page 10]
Internet-Draft Transm. and Proc. of IPv6 Options March 2015
[RFC2675] Borman, D., Deering, S., and R. Hinden, "IPv6 Jumbograms",
RFC 2675, August 1999.
[RFC2710] Deering, S., Fenner, W., and B. Haberman, "Multicast
Listener Discovery (MLD) for IPv6", RFC 2710, October
1999.
[RFC2711] Partridge, C. and A. Jackson, "IPv6 Router Alert Option",
RFC 2711, October 1999.
[RFC3692] Narten, T., "Assigning Experimental and Testing Numbers
Considered Useful", BCP 82, RFC 3692, January 2004.
[RFC4302] Kent, S., "IP Authentication Header", RFC 4302, December
2005.
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC
4303, December 2005.
[RFC4304] Kent, S., "Extended Sequence Number (ESN) Addendum to
IPsec Domain of Interpretation (DOI) for Internet Security
Association and Key Management Protocol (ISAKMP)", RFC
4304, December 2005.
[RFC4727] Fenner, B., "Experimental Values In IPv4, IPv6, ICMPv4,
ICMPv6, UDP, and TCP Headers", RFC 4727, November 2006.
[RFC4782] Floyd, S., Allman, M., Jain, A., and P. Sarolahti, "Quick-
Start for TCP and IP", RFC 4782, January 2007.
[RFC5095] Abley, J., Savola, P., and G. Neville-Neil, "Deprecation
of Type 0 Routing Headers in IPv6", RFC 5095, December
2007.
[RFC5201] Moskowitz, R., Nikander, P., Jokela, P., and T. Henderson,
"Host Identity Protocol", RFC 5201, April 2008.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008.
[RFC5533] Nordmark, E. and M. Bagnulo, "Shim6: Level 3 Multihoming
Shim Protocol for IPv6", RFC 5533, June 2009.
[RFC5570] StJohns, M., Atkinson, R., and G. Thomas, "Common
Architecture Label IPv6 Security Option (CALIPSO)", RFC
5570, July 2009.
Gont, et al. Expires September 10, 2015 [Page 11]
Internet-Draft Transm. and Proc. of IPv6 Options March 2015
[RFC6275] Perkins, C., Johnson, D., and J. Arkko, "Mobility Support
in IPv6", RFC 6275, July 2011.
[RFC6398] Le Faucheur, F., "IP Router Alert Considerations and
Usage", BCP 168, RFC 6398, October 2011.
[RFC6550] Winter, T., Thubert, P., Brandt, A., Hui, J., Kelsey, R.,
Levis, P., Pister, K., Struik, R., Vasseur, JP., and R.
Alexander, "RPL: IPv6 Routing Protocol for Low-Power and
Lossy Networks", RFC 6550, March 2012.
[RFC6553] Hui, J. and JP. Vasseur, "The Routing Protocol for Low-
Power and Lossy Networks (RPL) Option for Carrying RPL
Information in Data-Plane Datagrams", RFC 6553, March
2012.
[RFC6554] Hui, J., Vasseur, JP., Culler, D., and V. Manral, "An IPv6
Routing Header for Source Routes with the Routing Protocol
for Low-Power and Lossy Networks (RPL)", RFC 6554, March
2012.
[RFC6621] Macker, J., "Simplified Multicast Forwarding", RFC 6621,
May 2012.
[RFC6740] Atkinson,, RJ., "Identifier-Locator Network Protocol
(ILNP) Architectural Description", RFC 6740, November
2012.
[RFC6744] Atkinson,, RJ., "IPv6 Nonce Destination Option for the
Identifier-Locator Network Protocol for IPv6 (ILNPv6)",
RFC 6744, November 2012.
[RFC6788] Krishnan, S., Kavanagh, A., Varga, B., Ooghe, S., and E.
Nordmark, "The Line-Identification Option", RFC 6788,
November 2012.
[RFC6971] Herberg, U., Cardenas, A., Iwao, T., Dow, M., and S.
Cespedes, "Depth-First Forwarding (DFF) in Unreliable
Networks", RFC 6971, June 2013.
[RFC7045] Carpenter, B. and S. Jiang, "Transmission and Processing
of IPv6 Extension Headers", RFC 7045, December 2013.
[RFC7112] Gont, F., Manral, V., and R. Bonica, "Implications of
Oversized IPv6 Header Chains", RFC 7112, January 2014.
Gont, et al. Expires September 10, 2015 [Page 12]
Internet-Draft Transm. and Proc. of IPv6 Options March 2015
8.2. Informative References
[Biondi2007]
Biondi, P. and A. Ebalard, "IPv6 Routing Header Security",
CanSecWest 2007 Security Conference, 2007,
<http://www.secdev.org/conf/IPv6_RH_security-csw07.pdf>.
[I-D.gont-v6ops-ipv6-ehs-in-real-world]
Gont, F., Linkova, J., Chown, T., and W. Will,
"Observations on IPv6 EH Filtering in the Real World",
draft-gont-v6ops-ipv6-ehs-in-real-world-02 (work in
progress), March 2015.
[I-D.ietf-roll-trickle-mcast]
Hui, J. and R. Kelsey, "Multicast Protocol for Low power
and Lossy Networks (MPL)", draft-ietf-roll-trickle-
mcast-11 (work in progress), November 2014.
[IANA-IPV6-PARAM]
Internet Assigned Numbers Authority, "Internet Protocol
Version 6 (IPv6) Parameters", December 2013,
<http://www.iana.org/assignments/ipv6-parameters/
ipv6-parameters.xhtml>.
[NIMROD-DOC]
Nimrod Documentation Page, ,
"http://ana-3.lcs.mit.edu/~jnc/nimrod/", .
[RFC3871] Jones, G., "Operational Security Requirements for Large
Internet Service Provider (ISP) IP Network
Infrastructure", RFC 3871, September 2004.
[RFC7126] Gont, F., Atkinson, R., and C. Pignataro, "Recommendations
on Filtering of IPv4 Packets Containing IPv4 Options", BCP
186, RFC 7126, February 2014.
[nimrod-eid]
Lynn, C., "Endpoint Identifier Destination Option", IETF
Internet Draft, draft-ietf-nimrod-eid-00.txt, November
1995.
Authors' Addresses
Gont, et al. Expires September 10, 2015 [Page 13]
Internet-Draft Transm. and Proc. of IPv6 Options March 2015
Fernando Gont
UTN-FRH / SI6 Networks
Evaristo Carriego 2644
Haedo, Provincia de Buenos Aires 1706
Argentina
Phone: +54 11 4650 8472
Email: fgont@si6networks.com
URI: http://www.si6networks.com
Will(Shucheng) Liu
Huawei Technologies
Bantian, Longgang District
Shenzhen 518129
P.R. China
Email: liushucheng@huawei.com
Ronald P. Bonica
Juniper Networks
2251 Corporate Park Drive
Herndon, VA 20171
US
Phone: 571 250 5819
Email: rbonica@juniper.net
Gont, et al. Expires September 10, 2015 [Page 14]
| PAFTECH AB 2003-2026 | 2026-04-24 01:57:51 |