One document matched: draft-elkins-v6ops-ipv6-ipid-needed-00.txt
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
February 2013
IPv6 IPID Needed
draft-elkins-v6ops-ipv6-ipid-needed-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 September 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 September 4, 2013 [Page 01]
Internet-Draft IPv6 Diagnostic Option February 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. One potential solution is included in later
sections of this RFC, but the primary intention of this RFC is to
initiate action by the IETF on this issue, perhaps in the form of a
Working Group Subcommittee.
Elkins Expires September 4, 2013 [Page 02]
Internet-Draft IPv6 IPID Needed February 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 September 4, 2013 [Page 03]
Internet-Draft IPv6 IPID Needed February 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 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 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 September 4, 2013 [Page 04]
Internet-Draft IPv6 IPID Needed February 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. A possible
solution to this situation will be suggested, but the primary
intention of this document is to highlight the existence of this
issue and to ask that the IETF research and recommend an optimal
solution, perhaps by the formation of a Working Group Subcommittee.
End users and Large Enterprises involved in this initiative to date
seem to agree on the need to retain this valuable diagnostic facility,
as well as the preference that it be able turned on and off as needed,
if it cannot be statically included in the base header, as it is in
IPv4.
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 September 4, 2013 [Page 05]
Internet-Draft IPv6 IPID Needed February 2013
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 example solution is an implementation of the
Destination Options Header. Once again, this approach assumes the
IPID field cannot be included in the base header, as it is in IPv4.
BASIC RATIONALE FOR RETENTION OF THE IPID FIELD
1. The ability to utilize the IPID has enhanced problem diagnosis
efforts and significantly reduced problem resolution time.
2. 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.
3. 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.
4. 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.
5. 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.
6. 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 September 4, 2013 [Page 06]
Internet-Draft IPv6 IPID Needed February 2013
7. 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 September 4, 2013 [Page 07]
Internet-Draft IPv6 IPID Needed February 2013
USE CASE #4 --- Large Government Agency
- (estimated time saved by use of IPID: 9 hours)
VPN DROPS
- Cell phone connection 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.)
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 September 4, 2013 [Page 8]
Internet-Draft IPv6 IPID Needed February 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, 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 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 September 4, 2013 [Page 9]
Internet-Draft IPv6 IPID Needed February 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 September 4, 2013 [Page 10]
| PAFTECH AB 2003-2026 | 2026-04-24 08:31:07 |