Skip to main content

Update to the processing of the Hop-by-Hop Options extension header
draft-tsou-6man-hbh-header-update-00

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft whose latest revision state is "Expired".
Authors Sreenatha Setty, Tina Tsou (Ting ZOU)
Last updated 2012-03-04
RFC stream (None)
Formats
Stream Stream state (No stream defined)
Consensus boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-tsou-6man-hbh-header-update-00
Internet Engineering Task Force                                 S. Setty
Internet-Draft                            Huawei Technologies India Pvt.
Intended status: Standards Track                                    Ltd.
Expires: September 5, 2012                                  T. Tsou, Ed.
                                               Huawei Technologies (USA)
                                                           March 4, 2012

  Update to the processing of the Hop-by-Hop Options extension header
                  draft-tsou-6man-hbh-header-update-00

Abstract

   The Hop-by-Hop Options header is used to convey optional information
   that must be examined by every node along a packet's delivery path.
   This document updates RFC2460, removing the requirement that source
   nodes must process the Hop-by-Hop extension header, on the basis that
   it imposes a performance impact with no advantages.

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).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   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."

   This Internet-Draft will expire on September 5, 2012.

Copyright Notice

   Copyright (c) 2012 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.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of

Setty & Tsou            Expires September 5, 2012               [Page 1]
Internet-Draft          HBH Options Header Update             March 2012

   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 3
     1.1.  Requirements Language . . . . . . . . . . . . . . . . . . . 3
   2.  Processing of Hop-by-Hop Option Header  . . . . . . . . . . . . 3
   3.  Updating RFC2460  . . . . . . . . . . . . . . . . . . . . . . . 4
   4.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 4
   5.  Security Considerations . . . . . . . . . . . . . . . . . . . . 4
   6.  Normative References  . . . . . . . . . . . . . . . . . . . . . 4
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . . . 4

Setty & Tsou            Expires September 5, 2012               [Page 2]
Internet-Draft          HBH Options Header Update             March 2012

1.  Introduction

   The Hop-by-Hop Options extension header is used to convery
   information that must be examined by all nodes along the path.
   [RFC2460] requires processing of the Hop-by-Hop Options extension
   header in all nodes along the packet delivery path.  However, this is
   not really necessary for source node, and imposes a performance
   penalty on the source node when such packets are employed.

   Section 2 describes the Processing of Hop-by-hop Options header.
   Section 3 formally updates the [RFC2460] such that the aforementioned
   penalty on the source node is eliminated.

1.1.  Requirements Language

   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 RFC 2119 [RFC2119].

2.  Processing of Hop-by-Hop Option Header

   Section 4 of [RFC2460] states that the Hop-by-Hop Options header must
   be examined and processed by every node along a packet's delivery
   path, including the source and destination nodes.

   The above requirement means that a node originating the packet that
   contains a Hop-by-Hop Extension header will have to process that
   header.  Since source node is the one inserting the header in the
   first place, there does not seem to be any advantages in such
   requirement, but otherwise represents a performance penalty.

   As of the time of this writing, two options (other than the padding
   options) have been specified for the Hop-by-Hop Options extension
   header:

   Router Alert Option      This option is defined in [RFC2711],
                            intended for applications like MLD, RSVP,
                            etc.

   Jumbo Payload Option     This option is defined in [RFC2675], and
                            used to convey IPv6 payloads larger than
                            2^16 bytes.

   In the above two cases, the source node does not need to process the
   Hop-By-Hop options extension header.

Setty & Tsou            Expires September 5, 2012               [Page 3]
Internet-Draft          HBH Options Header Update             March 2012

3.  Updating RFC2460

   This document updates [RFC2460] as follows:

   The Hop-by-Hop Options header MUST be examined and processed by every
   node along a packet's delivery path (including the destination nodes), 
   except for the source node.

4.  IANA Considerations

   This specification does not require any IANA actions.

5.  Security Considerations

   This specification does not introduce new security issues.

6.  Normative References

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

   [RFC2460]  Deering, S. and R. Hinden, "Internet Protocol, Version 6
              (IPv6) Specification", RFC 2460, December 1998.

   [RFC2675]  Borman, D., Deering, S., and R. Hinden, "IPv6 Jumbograms",
              RFC 2675, August 1999.

   [RFC2710]  Deering, S., Fenner, W., and B. Haberman, "Multicast
              Listener Discovery (MLD) for IPv6", RFC 2710,
              October 1999.

   [RFC2711]  Partridge, C. and A. Jackson, "IPv6 Router Alert Option",
              RFC 2711, October 1999.

   [RFC3810]  Vida, R. and L. Costa, "Multicast Listener Discovery
              Version 2 (MLDv2) for IPv6", RFC 3810, June 2004.

Setty & Tsou            Expires September 5, 2012               [Page 4]
Internet-Draft          HBH Options Header Update             March 2012

Authors' Addresses

   Sreenatha Setty
   Huawei Technologies India Pvt. Ltd.
   Airport Road
   Bangalore  560008
   India

   Phone: +91 961 127 9232
   Email: sreenathabs@huawei.com

   Tina Tsou (editor)
   Huawei Technologies (USA)
   2330 Central Expressway
   Santa Clara  CA  95050
   USA

   Phone: +1 408 330 4424
   Email: tina.tsou.zouting@huawei.com

Setty & Tsou            Expires September 5, 2012               [Page 5]