[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00

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 Header
                   draft-elkins-6man-ipv6-diagnostic-header-00.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 IPID for fragmentation and
reassembly.  This field was commonly used by network diagnosticians for
tracking packets on multi-tier networks. In IPv6, the IPID has been
moved to the Fragment header.  A new Diagnostic header 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 Header       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 Header 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 Identification 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 IPv4 Identification (ID) 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. Some
TCP stacks have the same IPID counter for all connections; some have an
IPID counter on a per connection basis. Each time a TCP stack sends out
a packet, the IPID is incremented by one (or sometimes 2).

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 frequently used on large multi-tier networks to see where the packet
loss or packet corruption is happening.

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.

Elkins                     Expires January 4, 2012           [Page 02]


Internet-Draft                  IPv6 Diagnostic Header       July 2011


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 TCP 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 RFC2233 [RFC2863].

This document will address a way to make the IPv6 IPID field available
and unique for its valuable diagnostic usage. A Destination Options
header is proposed which may be sent by TCP stacks in diagnostic mode.
The implementation MAY provide the option of either turning on the
Diagnostic Header for all connections or turn it on just for specific
connections.  The more sophisticated usage of this header 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].


3.  Applicability

The base IPv6 standard, RFC2460, [RFC2460] allows the use of
extension headers including destination options 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 Options
header is an implementation of the destination options header.

Elkins                     Expires January 4, 2012           [Page 03]


Internet-Draft                  IPv6 Diagnostic Header       July 2011

4.  IPv6 Diagnostics Header 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 has the following format:


+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Next Header  |  Hdr Ext Len  |                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +
|                                                               |
.                                                               .
.                            Options                            .
.                                                               .
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



Next Header          8-bit selector. Identifies the type of header
                     immediately following the Destination Options
                     header. Uses the same values as the IPv4
                     Protocol field [RFC-1700 et seq.].

Hdr Ext Len          8-bit unsigned integer.  Length of the
                     Destination Options header in 8-octet units, not
                     including the first 8 octets.

Options              Variable-length field, of length such that the
                     complete Destination Options header is an
                     integer multiple of 8 octets long. Contains one
                     or more TLV-encoded options.

Figure 1: Destination Options Extension header layout

The desired action for a destination node who does not recognize this
option is to ignore the header and continue processing the packet
normally.

According to RFC2460 [RFC2460], if the Destination Options header
Option Type has the value 00 in its highest-order two bits, the
receiving device should skip over this option and continue processing
the header.

Elkins                     Expires January 4, 2012           [Page 04]


Internet-Draft                  IPv6 Diagnostic Header       July 2011


4.2.  IPv6 Diagnostic Header Option

The IPv6 Diagnostic Header option is carried by the Destination Option
extension 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 Header 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                         +
|                                                               |
+                                                               +
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Option Type

nnn = 0xXX  [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.

Elkins                     Expires January 4, 2012           [Page 05]


Internet-Draft                  IPv6 Diagnostic Header       July 2011


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 Header 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 Header MUST NOT appear
more than once. However, an encapsulated packet MAY contain a separate
IP Identifier option associated with each encapsulating IP header.

The inclusion of a IPv6 Diagnostic Header 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 Header in a packet.



4.3.  Implementation Considerations

In implementation, a TCP stack may send this additional header for all
connections or, in a more sophisticated usage, a single connection only.

We suggest that initiation of this header be done in a 'Debug on',
'Debug off' mode. 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 TCP 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 TCP stack may have a fixed time (for
example, 5 minutes) after which debug mode will automatically be turned
off.

Elkins                     Expires January 4, 2012           [Page 06]


Internet-Draft                  IPv6 Diagnostic Header       July 2011


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.


6. Security Considerations

There are no security considerations.


7. IANA Considerations

A Destination Options value of XXX is pending IANA action. [RFC2780]


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 Header       July 2011


11. Acknowledgments

The authors would like to thank Fred Baker, Bill Jouris, Jose Isidro
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: nalini.elkins@insidethestack.com


   Lawrence Kratzke
   IBM
   8121 Glenbrittle Way
   Raleigh, NC 27615
   United States

   Phone: +1 800-876-8801
   Email: kratzke@us.ibm.com


   Michael Ackermann
   Blue Cross Blue Shield of Michigan
   P.O. Box 2888
   Detroit, Michigan 48231
   United States

   Phone: +1 310 460 4080
   Email: mackermann@bcbsmi.com

Elkins                     Expires January 4, 2012           [Page 08]


Html markup produced by rfcmarkup 1.129c, available from https://tools.ietf.org/tools/rfcmarkup/