One document matched: draft-van-beijnum-behave-frag64-00.txt

Behavior Engineering for Hindrance                        I. van Beijnum
Avoidance                                                 IMDEA Networks
Internet-Draft                                              May 21, 2009
Expires: November 22, 2009


              IPv6-to-IPv4 translation fragmentation issue
                   draft-van-beijnum-behave-frag64-00

Status of this Memo

   This Internet-Draft is submitted to IETF 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 November 22, 2009.

Copyright Notice

   Copyright (c) 2009 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 in effect on the date of
   publication of this document (http://trustee.ietf.org/license-info).
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.

Abstract

   This draft outlines a way to handle IPv4 MTUs smaller than 1280 bytes
   and a way to handle the identification field in fragmentation that
   are different from the ones specified in [RFC2460] for the purposes



van Beijnum             Expires November 22, 2009               [Page 1]

Internet-Draft             NAT64 fragmentation                  May 2009


   of discussion in the BEHAVE working group.


1.  Introduction

   [RFC2460] specifies that links carrying IPv6 packets must support an
   MTU of at least 1280 bytes and that IPv6 hosts which don't implement
   path MTU discovery can leave this feature out if they limit
   themselves to sending packets no larger than 1280 bytes.  It also
   contains the following text:

      In response to an IPv6 packet that is sent to an IPv4 destination
      (i.e., a packet that undergoes translation from IPv6 to IPv4), the
      originating IPv6 node may receive an ICMP Packet Too Big message
      reporting a Next-Hop MTU less than 1280.  In that case, the IPv6
      node is not required to reduce the size of subsequent packets to
      less than 1280, but must include a Fragment header in those
      packets so that the IPv6-to-IPv4 translating router can obtain a
      suitable Identification value to use in resulting IPv4 fragments.
      Note that this means the payload may have to be reduced to 1232
      octets (1280 minus 40 for the IPv6 header and 8 for the Fragment
      header), and smaller still if additional extension headers are
      used.

   This suggests that an IPv6-IPv4 translator can simply translate ICMP
   "too big" messages it receives from IPv4 hosts to a corresponding
   ICMPv6 "too big" message directed at the IPv6 host originating the
   packet towards the IPv4 host that sent the original "too big"
   message.

   Should the MTU contained in the "too big" message be smaller than
   1280 bytes, the IPv6 host will start including a fragment header,
   which tells the translator to set the DF bit to 0 after translation
   and provides the translator with an identification value that it can
   include in the IPv4 packet (in truncated form).

   [RFC2765] specifies setting DF to 1 in all other translated packets
   to allow for path MTU discovery.


2.  Issues

   With stateful IPv6-to-IPv4 translation, using 16 bits from the
   identification in the IPv6 fragment header is suboptimal because the
   field must be unique within the time period that packets may be
   present in the network for a given protocol, source address,
   destination address tuple.  Because multiple IPv6 hosts will generate
   packets that share the same IPv4 source address, using the



van Beijnum             Expires November 22, 2009               [Page 2]

Internet-Draft             NAT64 fragmentation                  May 2009


   identification from the IPv6 host doesn't provide uniqueness.

   Should the translator use the presence of a fragmentation header as
   the factor that determines whether to set DF to 0 or to 1, the
   situation may arise where an IPv6 host doesn't perform path MTU
   discovery, and thus doesn't react to "too big" messages.  For normal
   IPv6 operation, this would be legitimate way to operate if the host
   sends packets no bigger than 1280 bytes.  However, if the host
   doesn't get the "too big" messages or doesn't react to them by
   including the fragment header, it will send 1280-byte packets without
   the fragment header which the translator will translate into 1260-
   byte packets with DF set to 1.  An IPv4 host with a path MTU smaller
   than 1260 will not be able to receive those packets.  This creates a
   path MTU discovery black hole that wouldn't exist in the pure IPv4 or
   pure IPv6 cases.

   Minor issues: the fragment header creates extra overhead and
   including the fragment header is an otherwise unused code path that
   may not exist or be buggy on implementations that haven't been
   extensively tested.


3.  Identification

   When a session consistently creates fragmented packets, and a
   fragment is lost, then eventually another fragment with the same
   identification value will arrive.  If by that time, the receiver is
   still waiting to reassemble the first packet, it will reassemble a
   packet from fragments belonging to different packets.  When this
   happens, there is an approximately 1 in 65535 chance that the TCP or
   UDP checksum will not catch this situation and undetected data
   corruption occurs.  This situation can be avoided by not reusing
   identification values within the reassembly timeout, or by having a
   very low loss probability.

   In the stateful translation case, the situation where the translator
   assigns identification values with the highest achievable level of
   uniqueness is clearly preferable over copying the lower 16 bits of
   the IPv6 host's identification value, because this reduces the
   chances of identification value clashes within a short time.

   Ideally, a translator would maintain an identification counter for
   each protocol, source, destination address tuple so that
   identification values are only reused within the lifetime of packets
   when the number of packets per second becomes so large that this is
   unavoidable.  However, for reasons of implementation complexity, it
   may be necessary to have fewer identification counters.  Sharing
   identification counters across different protocol, source,



van Beijnum             Expires November 22, 2009               [Page 3]

Internet-Draft             NAT64 fragmentation                  May 2009


   destination tuples means that there is a likelihood that the same
   identification value is reused for the same tuple sooner, but there
   is still a good statistical likelihood that this won't happen.

   Stateless translators could use the same strategy as stateless
   translators, but they may also use the strategy outlined in
   [RFC2460].

   In theory, IPv4 packets with DF set to 1 don't need a unique
   identification value.  However, it is not unheard of for operators to
   configure equipment to clear the DF bit, at which time an
   identification value with good uniqueness becomes necessary.  As
   such, it is recommended that translators include a unique
   identification value in all packets, including those with DF set to
   1.  However, since more packets will be sent with DF set to 1, this
   will use up identification values faster.  Implementations may choose
   to segment the identification space and assign values from non-
   overlapping pools to packets with DF set to 0 and DF set to 1 to
   provide a longer period of uniqueness to fragmentable packets.


4.  Choices

   Considering the above, there are the following choices.  For a
   stateless translator:

   1.  Use the [RFC2460] behavior, with DF set to 0 when a fragment
       header is present and DF set to 1 otherwise.  Take the
       identification value from the IPv6 fragment header.

   2.  Use the [RFC2460] behavior, but set DF to 0 for packets equal to
       or smaller than 1280 bytes and set DF to 1 for packets larger
       than 1280 bytes.  Take the identification value from the IPv6
       fragment header if present, otherwise generate in the translator.
       This avoids the introduction of the path MTU discovery black hole
       but still conforms to [RFC2460].  However, there is a slight risk
       of overlapping identification values between ones from the
       fragment header and locally generated ones.

   3.  Rewrite translated "too big" messages in the IPv4-to-IPv6
       direction to an MTU of 1280 if the indicated MTU is smaller than
       1280, set DF to 0 for packets equal to or smaller than 1280 bytes
       and set DF to 1 for packets larger than 1280 bytes.  Generate
       identification values locally.  This avoids the black hole and
       the extra fragment header overhead and minimzes identification
       clashing issues.

   For a stateful translator:



van Beijnum             Expires November 22, 2009               [Page 4]

Internet-Draft             NAT64 fragmentation                  May 2009


   1.  Use the [RFC2460] / [RFC2765] behavior, with DF set to 0 when a
       fragment header is present and DF set to 1 otherwise.  Take the
       identification value from the IPv6 fragment header.  This has a
       high risk of identification value clashes.

   2.  Use the [RFC2460] behavior, but set DF to 0 for packets equal to
       or smaller than 1280 bytes and set DF to 1 for packets larger
       than 1280 bytes.  Take the identification value from the IPv6
       fragment header if present, otherwise generate in the translator.
       This avoids the introduction of the path MTU discovery black hole
       but still conforms to [RFC2460].  This has a high risk of
       identification value clashes.

   3.  Rewrite translated "too big" messages in the IPv4-to-IPv6
       direction to an MTU of 1280 if the indicated MTU is smaller than
       1280, set DF to 0 for packets equal to or smaller than 1280 bytes
       and set DF to 1 for packets larger than 1280 bytes.  Generate
       identification values locally.  This avoids the black hole and
       the extra fragment header overhead and minimzes identification
       clashing issues.


5.  References

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

   [RFC2765]  Nordmark, E., "Stateless IP/ICMP Translation Algorithm
              (SIIT)", RFC 2765, February 2000.


Author's Address

   Iljitsch van Beijnum
   IMDEA Networks
   Avda. del Mar Mediterraneo, 22
   Leganes, Madrid  28918
   Spain

   Email: iljitsch@muada.com











van Beijnum             Expires November 22, 2009               [Page 5]