[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03

Network Working Group                                          V. Manral
Internet-Draft                                               SiNett Corp
Expires: July 9, 2006

                     Operational issues with Tiny Fragments in IPv6

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of 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-

   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

   The list of Internet-Draft Shadow Directories can be accessed at

   This Internet-Draft will expire on July 9, 2006.

Copyright Notice

   Copyright (C) The Internet Society (2006).


   IPv6 fragmentation allows fragments to be sent only by the source of
   a  packet. The Fragment  header is used by an IPv6 source to send a
   packet larger than would fit in the path MTU to its   destination.

   Firewalls generally use 5-tuples to filter out packets. However there
   are cases where  fragmentation can be used to disguise TCP  packets
   from IP filters used in routers and hosts. This document specifies
   where tiny fragments can be issues.

Manral                                                                [Page 1]

INTERNET-DRAFT         Operational issues with Tiny        January, 2006
                       Fragments in IPv6

Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   document are to be interpreted as described in RFC 2119 [RFC2119].

1.  Problem Statement

   With many IP implementations it is possible to impose a fragment
   small  enough to force some of a packet's Upper Layer e.g. TCP header
   fields  into the second fragment.

   This can cause all middlebox's like firewall and NAT-PT which expect
   the fields header information in the first fragment to not work properly.

   Though the NAT Behave draft, states that NAT box should reassemble
   the packets, a lot of new issues can result. Keeping state could result
   in easy DoS attacks. Besides the jury is still out about how many NAT
   boxes do reassembly.

   All policy based devices where packets are forwarded or sent on a
   tunnel based on some policy are also affected.

2.  Issues with Firewalls

   There are different types of firewalls and state can be created in
   these firewalls through different methods.  Independent of the
   adopted method, firewalls typically look at five parameters of the
   traffic arriving at the firewalls:

   o  Source IP address

   o  Destination IP address

   o  Protocol type

   o  Source port number

   o  Destination port number

   Based on these parameters, firewalls usually decide whether to allow
   the traffic or to drop the packets.

   However in cases where the first fragment does not have the upper
   layer header information, the firewall is not able to get the port
   information and other upper layer information, thus allowing the
   packets to be sent to the protected side.

Manral                                                                [Page 2]

INTERNET-DRAFT         Operational issues with Tiny        January, 2006
                       Fragments in IPv6

   This can lead to attacks to the network and the firewall not being
   able to block such an attack.

3.  Issues with NAT-PT

   NAT-PT [RFC2766] assumes that for NAPT-PT operation the ports are
   visible to the translator. However if the Upper Layer Header is not
   there in the first fragment. This causes the visibility ot the port to
   be lost. This can cause the translation process to fail.

   When the translator gets a tiny IPv6 fragment which has to be
   translated  to an IPv4 packet. The translator will have to reassemble
   the packets as the IPv4 non last  fragment needs to have a datagram
   size of 68 octets  atleast.

    STD 5, RFC 791 states:

      Every internet module must be able to forward a datagram of 68
      octets without further fragmentation.  This is because an internet
      header may be up to 60 octets, and the minimum fragment is 8

4.  Issues with Policy Boxes

   Tiny Fragments could cause issues to Policy boxes which look further
   inside the packet, to make decisions.

   For IPsec Security Policy Database (SPD) specifies what services are
   to be offered to IP datagrams and in what fashion.  The draft
   [RFC2401bis] states:

     "Non-initial" vs "Initial" Fragments

      Throughout this document, the phrase "non-initial" fragments is
      used to mean fragments that do not contain all of the selector
      values that may be needed for access control.  And the phrase
      "initial" fragment is used to mean a fragment that  contains all
      the selector values needed for access control.

   However, it should be noted that for IPv6, which fragment contains
   the Next Layer Protocol and ports (or ICMP message type/code or
   Mobility Header type) will depend on the kind and number of extension
   headers present.

   Having tiny fragments could mean that none of the fragments would
   be the Initial Fragment. So any access control/ tunneling based on
   that may not work unless reassembly is done, or extra state like next
   Header  and previous header length remaining are kept across

Manral                                                                [Page 3]

INTERNET-DRAFT         Operational issues with Tiny        January, 2006
                       Fragments in IPv6

5. Proposed solutions to the problem

   a. Impose a minimum packet size for the non-last fragments. If a
      fragment of a lesser size is received, the packet is treated as a
      malformed packet and is discarded.

   b. Reassemble all the fragments of the packet, translate the header
     fields and, glean out relevent information and then pass the original
     fragments ahead after modifying the relevent fields.

   c.  Reassemble all the fragments of the packet till we have the header
     fields of the upper layer , glean out relevent information and then
     pass the original fragments ahead after modifying the relevent fields.

   d. If upper layer protocol present then the header must be there in
      the first fragment.

   The above is just a first summary and the proposals are expected to
   change as the draft matures.

6.  Issues with fragment size of Minimum MTU

   The minimum fragment size of the non last fragment could be
   specified to be 1280 octets, the minimum link MTU [RFC2460].

   However if the IPv6 packet has to be further tunnelled the packet
   may have to be fragmented. To prevent such a case a minimum packet
   size of the non-last fragment should be less then 1280.

7.  IANA Considerations

   This document makes no request of IANA.

   Note to RFC Editor: this section may be removed on publication as an

Manral                                                                [Page 4]

INTERNET-DRAFT         Operational issues with Tiny        January, 2006
                       Fragments in IPv6

8.  Security Considerations

   This draft outlines security issues arising if "Tiny Fragments" are
   sent. This draft raises no new security issues.

Manral                                                                [Page 5]

INTERNET-DRAFT         Operational issues with Tiny        January, 2006
                       Fragments in IPv6

9.  Acknowledgements

   This draft borrows text heavily from
   draft-ietf-mip6-firewalls-03.txt and RFC1858. Thanks to Brian
   Carpenter, Pekka Savola, Stig Venaas,Fred Baker, Pyda
   Srisuresh, Senthil Sivakumar and Radhakrishnan.S for the
   helpful discussion.

Manral                                                                [Page 6]

INTERNET-DRAFT         Operational issues with Tiny        January, 2006
                       Fragments in IPv6

10.  References

10.1  Normative References

  [RFC2460] Deering & Hinden, "Internet Protocol, Version 6 (IPv6)
            Specification", RFC2460, December 1998

  [RFC2766] Tsirtsis & Srisuresh, "Network Address Translation -
            Protocol Translation (NAT-PT)", RFC2766, February 2000

  [RFC2401bis] Kent & Seo, "Security Architecture for the Internet
            Protocol", Work in Progress, September, 2005

10.2  Informative References

  [RFC1858] Ziemba, Reed & Traina ,  "Security Considerations - IP
            Fragment Filtering", RFC1858, October 1995

Authors' Addresses

   Vishwas Manral
   SiNett Corp,
   2/1 Embassy Icon Annex,
   Infantry Road,

   Phone: +91-80-5137-7023
   Fax:   +91-80-5137-7001
   Email: vishwas@sinett.com

Manral                                                                [Page 7]

INTERNET-DRAFT         Operational issues with Tiny        January, 2006
                       Fragments in IPv6

Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at

Disclaimer of Validity

   This document and the information contained herein are provided on an

Copyright Statement

   Copyright (C) The Internet Society (2005).  This document is subject
   to the rights, licenses and restrictions contained in BCP 78, and
   except as set forth therein, the authors retain all their rights.


   Funding for the RFC Editor function is currently provided by the
   Internet Society.

Manral                                                                [Page 8]

Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/