6man 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-6man-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 IPID Needed 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 4. IPv6 Diagnostics Header Format ................................... 8 4.1. Destination Options Header .................................. 8 4.2. Diagnostic Option ........................................... 8 4.3. Implementation Considerations ...............................10 5. Backward Compatibility ...........................................11 6. Security Considerations ..........................................11 7. IANA Considerations ..............................................11 10. References ......................................................11 10.1. Normative References ......................................11 11. Acknowledgments .................................................12 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.) 4. IPv6 Diagnostic Option Format One Possible Implementation - Example Solution 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 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. Elkins Expires September 4, 2013 [Page 08] Internet-Draft IPv6 IPID Needed February 2013 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 + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 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: - 00 - skip over this option and continue processing the header. - The data within the option cannot change en route to the packet's final destination. Elkins Expires September 4, 2013 [Page 09] Internet-Draft IPv6 IPID Needed February 2013 The IPv6 Diagnostic Option MUST be placed as follows: - After the Routing Header, if that header is present - Before the Fragment Header, if that header is present - 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 only for 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. 4.3. Implementation Considerations In implementation, a given OS/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 would preferably be done via a 'Debug on'/'Debug off' switch. That is, a diagnostician might 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 would 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 might 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. Please note that the ability to turn extended diagnostic information on or off, as appropriate, is very prevalent in many situations: servers, applications, network devices, etc. Elkins Expires September 4, 2013 [Page 10] Internet-Draft IPv6 IPID Needed February 2013 Additionally, we suggest that stacks implement a separate IPID counter per connection, rather than a single counter for all connections. 5. Backward Compatibility The example solution described in the previous sections of 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 The example solution 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 should skip over this option and continue processing the header if it does not recognize 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. Elkins Expires September 4, 2013 [Page 11] 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. [RFC2780] Bradner, S., Paxson, V. "IANA Allocation Guidelines For Values In the Internet Protocol and Related Headers", RFC 2780, March 2000. See also: http://www.iana.org/assignments/ipv6-parameters 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 12] 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 13]