Internet DRAFT - draft-elkins-v6ops-ipv6-ipid-needed

draft-elkins-v6ops-ipv6-ipid-needed



v6ops Working Group                                            N. Elkins
Internet Draft                                           Inside Products
Intended status: Standards track                              L. Kratzke
Expires: September, 2013                                             IBM
                                                            M. Ackermann
                                                        BCBS of Michigan
                                                              K. Haining
                                                                 US Bank

                                                              April 2013

                             IPv6 IPID Needed
                   draft-elkins-v6ops-ipv6-ipid-needed-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 October 4, 2013.


Copyright Notice

Copyright (c) 2013 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.

Elkins                     Expires   October 4, 2013           [Page 01]


Internet-Draft                  IPv6 Diagnostic Option       April 2013

Abstract

The IPv4 main header contained a 16-bit IP Identification (IPID) field
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, and would only
be used when fragmentation is required.  Thus, the IPID field in IPv6,
is no longer able to be utilized in the valuable role it played in
IPv4, relative to diagnostics and problem resolution.  This causes
great concern in particular for end users and large enterprises, for
whom Network/Application availability and performance can directly and
profoundly affect bottom line financials. Several viable solutions to 
this situation exist.

Elkins                     Expires October 4, 2013            [Page 02]


Internet-Draft                  IPv6 IPID Needed       April 2013

Table of Contents

1. Introduction ..................................................... 4
2. Conventions used in this document ................................ 5
3. Applicability  ................................................... 6
6. Security Considerations .......................................... 7
7. IANA Considerations .............................................. 7
10.References ....................................................... 7
    10.1. Normative References ...................................... 8
11. Acknowledgments ................................................. 8



Elkins                     Expires October 4, 2013            [Page 03]


Internet-Draft                  IPv6 IPID Needed       April 2013


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, the IPID field 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 Large Enterprise Networks, 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 the IPID makes it easier for a device(s) 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 October 4, 2013            [Page 04]
  

Internet-Draft                  IPv6 IPID Needed       April 2013

For its de-facto diagnostic mode usage, the IPID field needs to be 
available whether or not fragmentation occurs.  It also needs to be
unique in the context of the entire session, and across all the
connections controlled by the stack. 

This document will present information that demonstrates how valuable
and useful the IPID field has been (in IPv4) for diagnostics and 
problem resolution, and how not having it available (in IPv6), could
be a major detriment to new IPv6 deployments and contribute to 
protracted downtimes in existing IPv6 operations. 

As network technology has evolved, the uses to which fields are put can 
change as well.  De-facto use is powerful, and should not be lightly 
ignored.  In fact, it is a testiment to the power and pervasiveness of 
the protocol that users create new uses for the original technology. 

For example, the use of the IPID goes beyond the vision of the original 
authors.  This sort of thing has happened with numerous other 
technologies.  It is similar to the ways in which cell phones have 
evolved to be more than just a means of vocal communication, including 
Internet communications, photo-sharing, stock exchange transactions, 
etc.  Or the way that the bicycle, originally intended merely as a 
means of fashionable transportation for a single individual, developed 
into a replacement for the horse in hauling materials.  Or the way 
that the automobile went from being a means of transport for people 
to a truck, for transport of materials on a large scale.  Indeed, 
the Internet itself has evolved, from a small network for researchers 
and the military to share files into the pervasive global information 
superhighway that it is today. 

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 October 4, 2013             [Page 05]



Internet-Draft                  IPv6 IPID Needed      April 2013

3.  Applicability

The ability to utilize the IPID has enhanced problem diagnosis 
efforts and significantly reduced problem resolution time.

Several actual use case examples are shown below.  These
demonstrate how use of the IPID has reduced problem resolution time in
very valuable production networks of Large Enterprises/End Users.  In 
general, if a problem or performance issue with an application or
network component can be fixed in minutes, as opposed to hours, this
can mean significant dollar savings to large enterprises.  The IPID
can be used extensively when debugging involves traces or packet 
captures.  Its absence in IPv6 may lead to protracted problem
diagnosis and extended problem resolution time.

This value/perspective may be unique to tech support organizations
of large enterprises.  Other functional areas may not share this 
concern/perspective, as packets could continue to flow, but service
levels may not be acceptable to end users during the extended problem 
resolution time.

Although very situation dependent, the use cases below clearly
illustrate the value of network availability, and the need to keep 
problem resolution time to an absolute minimum.

Another benefit of using the IPID to expedite problem resolution
is reducing the cost of associated resources being consumed during 
extended problem resolution, such as storage, CPU and staff time.

Will IPID be critical in most problem resolutions?  NO!  But if
it even helps in a few per year, significant money and/or lost
business could be saved.

Elkins                     Expires October 4, 2013           [Page 06]


Internet-Draft                  IPv6 IPID Needed      April 2013

A facility such as IPID, that has proven field value, should not
be eliminated as an effective diagnosis tool!


USE CASE EXAMPLEs:

 USE CASE #1 --- Large Insurance Company
   -  (estimated time saved by use of IPID:  7 hours)
 PERFORMANCE TOOL PRODUCES EXTRANEOUS PACKETS? 
 - Issue was whether a performance tool was accurately replicating
   session flow during performance testing?
 - Trace IPIDs showed more unique packets within same flow from
   performance tool compared to IE Browser.
 - Having the clear IPID sequence numbers also showed where and why
   the extra packets were being generated.
 - Solution: Problem rectified in subsequent version of performance
   tool.
 - Without IPID, it was not clear if there was an issue at all.
 
 USE CASE #2 --- Large Bank
   -   (estimated time saved by use of IPID:  4 hours)
 BATCH TRANSFER DURATION INCREASES 12X 
 -  A 30 minute data transfer started taking 6-8 hours to complete.
 -  Possible packet loss?  All vendors said no.
 -  Other Apps were working OK.
 -  4 trace points used, and then IPIDs compared.
 -  Showed 7% packet loss.
 -  Solution: WAN hardware was replaced and problem fixed.
 -  Without IPID, no one would agree a problem existed
 
 USE CASE #3 --- Large Bank
   -    (estimated time saved by use of IPID: 6 hours)
 VERY SLOW INTERACTIVE PERFORMANCE.
 - All network links looked good.
 - Traces showed duplicated small packets (which can be OK).
 - Saw that IPID was equal but TTL was always + 1.
 - Network device was "Splitting" small packets only.(2 interfaces).
 - The small packets were control info, telling other side to slow
   down.
 - Erroneously looked like network congestion.
 - Solution:  Network Device replaced and good interactive
   performance restored.
 - Without IPID, flows would have appeared OK.

Elkins                     Expires October 4, 2013           [Page 07]


Internet-Draft                  IPv6 IPID Needed      April 2013


 USE CASE #4 --- Large Government Agency
   -    (estimated time saved by use of IPID: 9 hours)
 VPN DROPS 
 - Cell phone connections to law enforcement were being dropped. 
   Going through a VPN. 
 - All parties (both sides of VPN connection, application, etc.) said
   it was not their problem.  Problem went on for weeks. 
 - Finally, when we were called in as consultants, we took a trace
   which showed packet with IPID and TTL that did not match others in
   the flow AT ALL was coming from router nearest application server
   end of VPN. 
 - Solution: Provider for VPN for application server changed.  Problem
   resolved. 
 - Without IPID, much harder to diagnose problem. 
 - (Same case also happened with large corporation.  Again, all 
   parties saying not their fault until proven via packet trace.)

The IPID is very valuable to large enterprises and Data Center 
Operators (EDCO) in trace analysis, specifically in reducing problem
diagnosis and resolution time.   As such, IPID or something equivalent, 
should be part of IPv6 for all situations where it can provide value. 
(As it is IPv4.)  Not just where fragmentation is required. 

   
6. Security Considerations

There are no security considerations.


7. IANA Considerations

There are no IANA considerations.


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.

Elkins                     Expires October 4, 2013          [Page 8]


Internet-Draft               IPv6 IPID Needed      April 2013

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 
Requirement Levels", BCP 14, RFC 2119, March 1997.


11. Acknowledgments

The authors would like to thank Fred Baker, Bill Jouris, Jose Isidro, 
R. J. Atkinson, James Ashton, Sigfrido Perdomo and Neil Wasserman 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 93924
   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

Elkins                     Expires October 4, 2013          [Page 9]


Internet-Draft                  IPv6 IPID Needed      April 2013

   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

   Keven Haining
   US Bank
   16900 W Capitol Drive 
   Brookfield, WI 53005 

   Phone: +1 262-790-3551 
   Email: keven.haining@usbank.com 


Elkins                     Expires October 4, 2013          [Page 10]