Hello Folks,
Would love to get feedback on an Internet Draft we have submitted. The issue
we are addressing is that the IP Identification field which was available with
IPv4 in the main header is available with IPv6 only in the Fragment Header.
Please see:
http://tools.ietf.org/id/draft-elkins-6man-ipv6-diagnostic-header-00.txt
We do have a revision (version 01) which is attached. The submission system is
closed so we will update it formally when it reopens on July 25th.
Thanks!
Nalini Elkins
Inside Products, Inc.
(831) 659-8360
6man Working Group N. Elkins
Internet Draft Inside Products
Intended status: Standards track L. Kratzke
Expires: January, 2012 IBM
M. Ackermann
BCBS of Michigan
July 2011
IPv6 Diagnostic Option
draft-elkins-6man-ipv6-diagnostic-header-01.txt
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), its areas, and its working groups. Note that other groups
may also distribute working documents as Internet-Drafts.
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."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
This Internet-Draft will expire on January 4, 2012.
Copyright Notice
Copyright (c) 2011 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 to this document.
Abstract
The IPv4 main header contained a 16-bit IP Identification (IPID) field
to be used for fragmentation and reassembly. In practice, this field
was commonly used by network diagnosticians for tracking packets. In
IPv6, the IPID has been moved to the Fragment header. A new Diagnostic
Option for IPv6 which can be sent with every packet as a part of the
Destination Options Header with a 64-bit IPID is defined in this
document.
Elkins Expires January 4, 2012 [Page 01]
Internet-Draft IPv6 Diagnostic Option July 2011
Table of Contents
1. Introduction ..................................................... 2
2. Conventions used in this document ................................ 3
3. Applicability ................................................... 3
4. IPv6 Diagnostics Header Format ................................... 3
4.1. Destination Options Header .................................. 4
4.2. Diagnostic Option ........................................... 5
4.3. Implementation Considerations ............................... 6
5. Backward Compatibility ........................................... 6
6. Security Considerations .......................................... 6
7. IANA Considerations .............................................. 6
10. References ...................................................... 6
10.1. Normative References ...................................... 7
10.2. Informative References .................................... 7
11. Acknowledgments ................................................. 8
1. Introduction
In IPv4, the 16 bit IP Identification (IPID) field is located at an
offset of 4 bytes into the IPv4 header and is described in RFC791
[RFC791]. In IPv6, it is a 32 bit field contained in the Fragment Header
defined by section 4.5 of RFC2460 [RFC2460]. Unfortunately, unless
fragmentation is being done by the source node, the packet will not
contain this Fragment Header, and therefore will have no Identification
field.
The intended purpose of the IPID field is to enable fragmentation and
reassembly, and as currently specified is required to be unique within
the maximum segment lifetime (MSL) on all datagrams. The MSL is often 2
minutes.
In practice, the IPID field is used for more than fragmentation.
During network diagnostics, packet traces may be taken at multiple
places along the path or at the source and destination. Then, packets
can be matched by looking at the IPID. Obviously, the time at each
device will differ according to the clock on that device; so another
metric is required. This method of taking multiple traces along the path
is of special use on large multi-tier networks to see where the packet
loss or packet corruption is happening. Multi-tier networks are those
which have multiple routers or switches on the path between the sender
and the receiver.
The inclusion of this option makes it easier for a device in the middle
of the network or on the receiving end of the network to identify flows
belonging to a single node, even if that node might have a different IP
address. For example, if the sending node is a mobile laptop with a
wireless connection to the Internet.
Elkins Expires January 4, 2012 [Page 02]
Internet-Draft IPv6 Diagnostic Option July 2011
Having said that, a known problem with the uniqueness of the IPv4 ID is
that since the field is only 16 bits, then for high speed devices,
wrapping will occur. As discussed in RFC4963 [RFC4963] and
draft-ietf-intarea-ipv4-id-update-02.txt [Draft-ipv4-id], if the
uniqueness requirement were strictly enforced, all connections would be
limited to a maximum speed of 6.4 Mbps. Clearly, this uniqueness
requirement is widely ignored.
In fact, the implementation of the IPID field varies. Some
implementations have the same IPID counter for all connections; some
have an IPID counter on a per connection basis. Some implementations
increment the IPID by one each time a packet is sent out; some
increment by two.
In IPv6, the IPID field, which is in the Fragment Header, has been
increased to 32 bits. This may need to be reconsidered as data rates
increase but if the IPID is used for fragmentation and reassembly
alone, the requirement for uniqueness within the MSL period is
generally not an issue today. RFC4963 [RFC4963] discusses the issue of
reassembly errors at high data rates for IPv4 with a 16-bit counter.
However, for its de-facto diagnostic mode usage, an IPID needs to be
available whether or not fragmentation occurs, and needs to be unique
in the context of the entire session, and across all the connections
controlled by the stack. The problem of 32 bit counters is known
and has been resolved in areas such as SNMP counters by creating
64-bit counters as described in RFC2863 [RFC2863].
This document will address a way to make the IPv6 IPID field available
and unique for its valuable diagnostic usage. A Diagnostic Option which
is an implementation of the Destination Options Header is proposed
which may be sent by stacks in diagnostic mode. The implementation
MAY provide the option of either turning on the Diagnostic Option for
all connections or turn it on just for specific connections. The more
sophisticated usage of this option would be to send it for a single
connection only.
2. Conventions used in this document
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 [RFC2119].
Elkins Expires January 4, 2012 [Page 03]
Internet-Draft IPv6 Diagnostic Option July 2011
3. Applicability
The base IPv6 standard, RFC2460, [RFC2460] allows the use of
extension headers such as the Destination Options Header in order
to encode optional destination information in an IPv6 packet.
Extended diagnostic information such as this MUST be sent by
implementations upon request. The proposed Diagnostic Option is an
implementation of the Destination Options Header.
4. IPv6 Diagnostic Option Format
4.1 Destination Options Header
The Destination Options Header is used to carry optional information
that need be examined only by a packet's destination node(s). The
Destination Options Header is identified by a Next Header value of 60
in the immediately preceding header and is defined in RFC2460 [RFC2460].
4.2. IPv6 Diagnostic Option
The IPv6 Diagnostic Option is an implementation of the Destination
Options Header (Next Header value = 60). It is used in a packet sent
by a node to facilitate diagnostics by informing the recipient and
passive viewers of the packet such as packet capture facilities of
the packet's IP Identifier.
The IPv6 Diagnostic Option is encoded in type-length-value (TLV)
format as follows:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option Type | Option Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ IP Identifier +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Elkins Expires January 4, 2012 [Page 04]
Internet-Draft IPv6 Diagnostic Option July 2011
Option Type
TBD = 0xXX (TBD) [To be assigned by IANA] [RFC2780]
Option Length
8-bit unsigned integer. Length of the option, in octets, excluding the
Option Type and Option Length fields. This field MUST be set to 64.
IP Identifier
The IP Identifier of the packet for 64 bits.
The alignment requirement for the IP Identifier option is 8n+6.
The two highest-order bits of the Option Type field are encoded to
indicate specific processing of the option; for the IP Identifier
option, these two bits MUST be set to 00. This indicates the following
processing requirements:
o 00 - skip over this option and continue processing the header.
o The data within the option cannot change en route to the packet's
final destination.
The IPv6 Diagnostic Option MUST be placed as follows:
o After the Routing Header, if that header is present
o Before the Fragment Header, if that header is present
o Before the AH Header or ESP Header, if either one of those
headers are present.
For each IPv6 packet header, the IPv6 Diagnostic Option MUST NOT appear
more than once. However, an encapsulated packet MAY contain a separate
IPv6 Diagnostic Option associated with each encapsulating IP header.
The inclusion of a IPv6 Diagnostic Option in a packet affects the
receiving node's processing of only this single packet. No state is
created or modified in the receiving node as a result of receiving a
IPv6 Diagnostic Option in a packet.
Elkins Expires January 4, 2012 [Page 05]
Internet-Draft IPv6 Diagnostic Option July 2011
4.3. Implementation Considerations
In implementation, an implementing stack may send this additional header
for all connections, per higher level protocol or in a more
sophisticated usage, for a single connection or flow only.
The initiation of this header MUST be done via a 'Debug on'/'Debug off'
switch. That is, a diagnostician may decide that this header is required
for a certain timeframe or for a certain set of packets after a network
problem is encountered. The diagnostician may then issue a command to
the stack indicating that addition of the IP Identifier header should
now begin. This is the 'Debug on' state. After a certain amount of time,
then 'Debug off' should be issued as a command. Alternatively, the
stack may have a fixed time (for example, 5 minutes) after which debug
mode will automatically be turned off. In their default configuration,
IPv6 nodes SHOULD NOT include this option in IPv6 packets that they
originate. That is, the switch or state SHOULD default to 'Debug off'.
Additionally, implementers MUST permit a system administrator to enable
or disable including this option in originated IPv6 packets on at least
a per-Upper-Protocol basis (e.g. at least provide enable/disable
separate knobs for ICMP, UDP, TCP, or SCTP, in addition to a knob to
enable or disable for all IPv6 packets), and SHOULD permit it also to
be enabled or disabled on a per-flow basis. This configuration
flexibility would increase the potential value of this new option, and
would not increase implementation complexity unduly.
Additionally, we suggest that stacks implement a separate IPID counter
per connection rather than a single counter for all connections.
5. Backward Compatibility
The scheme proposed in this document is backward compatible with all
the currently defined IPv6 extension headers. According to RFC2460
[RFC2460], if the destination node does not recognize this option, it
should skip over this option and continue processing the header.
Elkins Expires January 4, 2012 [Page 06]
Internet-Draft IPv6 Diagnostic Option July 2011
6. Security Considerations
This option might be useful to security gateways seeking to identify
operational security issues or in preventing Replay Attacks.
7. IANA Considerations
A Destination Option requires an IPv6 Option Number or Type [RFC2460]
which is 8 bits.
HEX.........act..chg..rest (5 bits)
---- ---- --- ----
TBD 00 0 TBD IPv6 Diagnostic Option
For the IPv6 Option Number (Type), the first two bits indicate that
the IPv6 node skip over this option and continue processing the header
if it does not recognise the option type. The third bit indicates
that the Option Data must not change en-route, which permits this
option to be protected by the IP Authentication Header.
10. References
10.1. Normative References
[RFC791] Postel, J., "Internet Protocol", RFC 791 / STD 5, September
1981.
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, December 1998.
[RFC2863] K. McCloghrie, K., Kastenholz, F. "The Interfaces Group
MIB", RFC 2863, June 2000.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2780] Bradner, S., Paxson, V. "IANA Allocation Guidelines
For Values In the Internet Protocol and Related Headers", RFC 2780,
March 2000.
See also:
http:http://www.iana.org/assignments/ipv6-parameters
10.2. Informative References
[RFC4963] Heffner, J., Mathis, M., Chandler, B., "IPv4 Reassembly
Errors at High Data Rates", RFC 4963, July 2007.
[Draft-ipv4-id] Touch, J., "Updated Specification of the IPv4 ID
Field", draft-ietf-intarea-ipv4-id-update-02.txt, March 2011
Elkins Expires January 4, 2012 [Page 07]
Internet-Draft IPv6 Diagnostic Option July 2011
11. Acknowledgments
The authors would like to thank Fred Baker, Bill Jouris, Jose Isidro
R. J. Atkinson and James Ashton for their reviews and suggestions that
made this document better.
This document was prepared using 2-Word-v2.0.template.dot.
Authors' Addresses
Nalini Elkins
Inside Products, Inc.
36A Upper Circle
Carmel Valley, CA
United States
Phone: +1 831 659 8360
Email: [email protected]
Lawrence Kratzke
IBM
8121 Glenbrittle Way
Raleigh, NC 27615
United States
Phone: +1 800-876-8801
Email: [email protected]
Michael Ackermann
Blue Cross Blue Shield of Michigan
P.O. Box 2888
Detroit, Michigan 48231
United States
Phone: +1 310 460 4080
Email: [email protected]
Elkins Expires January 4, 2012 [Page 08]
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email protected]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
