Network Working Group                                    F. Templin, Ed.
Internet-Draft                              Boeing Research & Technology
Intended status: Informational                         November 10, 2014
Expires: May 14, 2015


                       AERO Minimal Encapsulation
                      draft-templin-aeromin-00.txt

Abstract

   Asymmetric Extended Route Optimization (AERO) specifies both a
   control messaging facility and an encapsulation format for managing
   tunnels over an enterprise network or other Internetwork.  Although
   AERO can operate with any tunnel encapsulation format, the base
   document considers IP-in-UDP-in-IP encapsulation as the default.
   This document presents a minimal encapsulation format for AERO for
   use when a UDP header is not needed.

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 May 14, 2015.

Copyright Notice

   Copyright (c) 2014 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



Templin                   Expires May 14, 2015                  [Page 1]


Internet-Draft         AERO Minimal Encapsulation          November 2014


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

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Minimal Encapsulation Format  . . . . . . . . . . . . . . . .   3
   3.  When to Insert the IPv6 Fragment Header . . . . . . . . . . .   3
   4.  Considerations for Using Minimal Encapsulation  . . . . . . .   4
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   4
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .   4
   7.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   4
   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   4
     8.1.  Normative References  . . . . . . . . . . . . . . . . . .   4
     8.2.  Informative References  . . . . . . . . . . . . . . . . .   5
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .   5

1.  Introduction

   Asymmetric Extended Route Optimization (AERO) [I-D.templin-aerolink]
   specifies both a control messaging facility and an encapsulation
   format for forwarding Internet Protocol (IP) packets [RFC0791]
   [RFC2460] over an enterprise network or other Internetwork through a
   process known as tunneling.  Although AERO can operate with any
   tunnel encapsulation format, the base document specifies the
   insertion of a User Datagram Protocol (UDP) header [RFC0768] with
   port 8060 between the inner and outer IP headers, i.e., as IP-in-UDP-
   in-IP.  This document presents a minimal encapsulation format for
   AERO for use when a UDP header is not needed.

   In its minimal form, AERO can use direct IP-in-IP encapsulation
   [RFC2003][RFC2473][RFC4213] with no intermediate layer between the
   inner and outer IP headers for interior routing and addressing
   services.  The encapsulation is therefore only differentiated from
   other IP-in-IP tunnel types through the application of AERO control
   messaging facilities.

   However, the tunnel fragmentation required by AERO to support a
   guaranteed minimum 1500 bytes cannot be accomplished by inserting an
   IPv6 Fragment Header immediately following the UDP header, since the
   UDP header is not included for minimal encapsulation.  Instead, the
   IPv6 fragment header is inserted directly between the inner and outer
   IP headers when needed, i.e., even if the outer header is IPv4.  The
   IPv6 Fragment Header is identified to the outer IP layer by its IP
   protocol number, and the Next Header field in the IPv6 Fragment
   Header identifies the inner IP header version.





Templin                   Expires May 14, 2015                  [Page 2]


Internet-Draft         AERO Minimal Encapsulation          November 2014


2.  Minimal Encapsulation Format

   Figure 1 shows the AERO minimal encapsulation format before any
   fragmentation is applied:

     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |       Outer IPv4 Header       |                |        Outer IPv6 Header      |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |IPv6 Fragment Header (optional)|                |IPv6 Fragment Header (optional)|
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |        Inner IP Header        |                |         Inner IP Header       |                                                            |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                               |                |                               |
     ~                               ~                ~                               ~
     ~      Inner Packet Body        ~                ~       Inner Packet Body       ~
     ~                               ~                ~                               ~
     |                               |                |                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Minimal Encapsulation in IPv4                    Minimal Encapsulation in IPv6


                  Figure 1: Minimal Encapsulation Format

3.  When to Insert the IPv6 Fragment Header

   The IPv6 Fragment Header is inserted whenever the AERO tunnel ingress
   needs to apply fragmentation to accommodate packets no larger than
   1500 bytes.  Fragmentation is performed on the inner packet while
   encapsulating each inner packet fragment in identical outer IP and
   IPv6 Fragment Headers.  Fragmentation therefore follows the same
   procedure as for the case when a UDP header is included, which
   follows the same procedure as for standard IPv6 fragmentation.

   The IPv6 Fragment Header can also be inserted in order to include a
   coherent Identification value with each packet, e.g., to aid in
   Duplicate Packet Detection (DPD).  In this way, networking devices
   can cache the Identification values of recently-seen packets and use
   the cached values to determine whether a newly-arrived packet is in
   fact a duplicate.

   Finally, the Identification value within each packet could provide a
   rough indicator of packet reordering, e.g., in cases when the tunnel
   egress wishes to discard packets that are grossly out of order.







Templin                   Expires May 14, 2015                  [Page 3]


Internet-Draft         AERO Minimal Encapsulation          November 2014


4.  Considerations for Using Minimal Encapsulation

   Minimal encapsulation is preferred in environments where UDP
   encapsulation would add unnecessary overhead.  For example, certain
   low-bandwidth wireless data links may benefit from an 8-byte-per-
   packet overhead reduction.  This is not likely to be a prime
   consideration for many modern wireless data links nor for most modern
   wired-line data links.

   UDP encapsulation can traverse network paths that are inaccessible to
   minimal encapsulation, e.g., for crossing Network Address Translators
   (NATs).  More and more, network middleboxes are also being configured
   to discard packets that include anything other than a well-known IP
   protocol such as UDP and TCP.  It may therefore be necessary to
   consider the potential for middlebox filtering before enabling
   minimal encapsulation in a given environment.

   Evidence seems to suggest that IPv6 fragmentation does not work along
   all paths, since well-meaning network middleboxes may consider it as
   an attack.

5.  IANA Considerations

   This document introduces no IANA considerations.

6.  Security Considerations

   Security considerations are discussed in the base AERO specification
   [I-D.templin-aerolink].

7.  Acknowledgements

   TBD

8.  References

8.1.  Normative References

   [RFC0768]  Postel, J., "User Datagram Protocol", STD 6, RFC 768,
              August 1980.

   [RFC0791]  Postel, J., "Internet Protocol", STD 5, RFC 791, September
              1981.

   [RFC2003]  Perkins, C., "IP Encapsulation within IP", RFC 2003,
              October 1996.





Templin                   Expires May 14, 2015                  [Page 4]


Internet-Draft         AERO Minimal Encapsulation          November 2014


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

   [RFC2473]  Conta, A. and S. Deering, "Generic Packet Tunneling in
              IPv6 Specification", RFC 2473, December 1998.

   [RFC4213]  Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms
              for IPv6 Hosts and Routers", RFC 4213, October 2005.

8.2.  Informative References

   [I-D.templin-aerolink]
              Templin, F., "Transmission of IP Packets over AERO Links",
              draft-templin-aerolink-46 (work in progress), October
              2014.

Author's Address

   Fred L. Templin (editor)
   Boeing Research & Technology
   P.O. Box 3707
   Seattle, WA  98124
   USA

   Email: fltemplin@acm.org


























Templin                   Expires May 14, 2015                  [Page 5]