Skip to main content

B. Changes Since RFC 2460

Its alignment requirement is 4n+3, to ensure that the 4-octet field starts at a multiple-of-4 offset from the start of the enclosing header. A complete Hop-by-Hop or Destination Options header containing this one option would look as follows:

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Next Header | Hdr Ext Len=1 | Pad1 Option=0 | Option Type=Y | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Opt Data Len=7 | 1-octet field | 2-octet field | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 4-octet field | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PadN Option=1 |Opt Data Len=2 | 0 | 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Example 3

A Hop-by-Hop or Destination Options header containing both options X and Y from Examples 1 and 2 would have one of the two following formats, depending on which option appeared first:

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Next Header | Hdr Ext Len=3 | Option Type=X |Opt Data Len=12| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 4-octet field | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |

  •                     8-octet field                         +

| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PadN Option=1 |Opt Data Len=1 | 0 | Option Type=Y | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Opt Data Len=7 | 1-octet field | 2-octet field | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 4-octet field | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PadN Option=1 |Opt Data Len=2 | 0 | 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Next Header | Hdr Ext Len=3 | Pad1 Option=0 | Option Type=Y | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Opt Data Len=7 | 1-octet field | 2-octet field | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 4-octet field | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PadN Option=1 |Opt Data Len=4 | 0 | 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0 | 0 | Option Type=X |Opt Data Len=12| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 4-octet field | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |

  •                     8-octet field                         +

| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Appendix B. Changes Since RFC 2460

This memo has the following changes from RFC 2460.

o Removed IP Next Generation from the Abstract.

o Added text in Section 1 that the data transmission order is the same as IPv4 as defined in RFC 791.

o Clarified the text in Section 3 about decrementing the Hop Limit.

o Clarified that extension headers (except for the Hop-by-Hop Options header) are not processed, inserted, or deleted by any node along a packet's delivery path.

o Changed requirement for the Hop-by-Hop Options header to a "may", and added a note to indicate what is expected regarding the Hop-by-Hop Options header.

o Added a paragraph to Section 4 to clarify how extension headers are numbered and which are upper-layer headers.

o Added a reference to the end of Section 4 to the "IPv6 Extension Header Types" IANA registry.

o Incorporated the updates from RFCs 5095 and 5871 to remove the description of RH0, that the allocations guidelines for routing headers are specified in RFC 5871, and removed RH0 from the list of required extension headers.

o Revised Section 4.5 on IPv6 fragmentation based on updates from RFCs 5722, 6946, 7112, and 8021. This includes:

  -  Revised the text to handle the case of fragments that are whole
     datagrams (i.e., both the Fragment Offset field and the M flag
     are zero).  If received, they should be processed as a
     reassembled packet.  Any other fragments that match should be
     processed independently.  The revised Fragment creation process
     was modified to not create whole datagram fragments (Fragment
     Offset field and the M flag are zero).

  -  Changed the text to require that IPv6 nodes must not create
     overlapping fragments.  Also, when reassembling an IPv6
     datagram, if one or more its constituent fragments is
     determined to be an overlapping fragment, the entire datagram
     (and any constituent fragments) must be silently discarded.
     Includes a clarification that no ICMP error message should be
     sent if overlapping fragments are received.






  -  Revised the text to require that all headers through the first
     Upper-Layer header are in the first fragment.  This changed the
     text describing how packets are fragmented and reassembled and
     added a new error case.

  -  Added text to the Fragment header process on handling exact
     duplicate fragments.

  -  Updated the Fragmentation header text to correct the inclusion
     of an Authentication Header (AH) and noted No Next Header case.
Last updated on