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

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 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 the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

1. Introduction

Asymmetric Extended Route Optimization (AERO) [I-D.templin-aerolink] specifies both a control messaging and data packet forwarding facility 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 per the Generic UDP Encapsulation (GUE) [I-D.ietf-nvo3-gue] specification. 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] or Generic Routing Encapsulation (GRE) [RFC2784][RFC2890] for interior routing and addressing services. The encapsulation is therefore only differentiated from other tunnel types through the application of AERO control messaging.

However, the tunnel fragmentation required by AERO to support a guaranteed minimum 1500 bytes requires a different fragment header than the one offered by GUE [I-D.herbert-gue-fragmentation] . Instead, for simple IP-in-IP encapsulation an 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.

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.

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. Minimal Encapsulation using GRE

GRE encapsulation can be used instead of simple IP-in-IP encapsulation when GRE facilities such as keys and checksums are desired. In that case, AERO can include a GRE fragmentation header in the encpasulation [I-D.templin-intarea-grefrag] as shown in Figure 2:

     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |        Outer IP Header        |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |          GRE Header           |
     | (with checksum, key, etc..)   |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |     GRE Framgent Header       |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |        Inner IP Header        |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                               |
     ~                               ~
     ~      Inner Packet Body        ~
     ~                               ~
     |                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Minimal Encapsulation Using GRE

Figure 2: Minimal Encapsulation Using GRE

6. IANA Considerations

This document introduces no IANA considerations.

7. Security Considerations

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

8. Acknowledgements

TBD

9. References

9.1. Normative References

[RFC0768]	Postel, J., "User Datagram Protocol", STD 6, RFC 768, DOI 10.17487/RFC0768, August 1980.
[RFC0791]	Postel, J., "Internet Protocol", STD 5, RFC 791, DOI 10.17487/RFC0791, September 1981.
[RFC2003]	Perkins, C., "IP Encapsulation within IP", RFC 2003, DOI 10.17487/RFC2003, October 1996.
[RFC2460]	Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, December 1998.
[RFC2473]	Conta, A. and S. Deering, "Generic Packet Tunneling in IPv6 Specification", RFC 2473, DOI 10.17487/RFC2473, December 1998.
[RFC2784]	Farinacci, D., Li, T., Hanks, S., Meyer, D. and P. Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, DOI 10.17487/RFC2784, March 2000.
[RFC2890]	Dommety, G., "Key and Sequence Number Extensions to GRE", RFC 2890, DOI 10.17487/RFC2890, September 2000.
[RFC4213]	Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms for IPv6 Hosts and Routers", RFC 4213, DOI 10.17487/RFC4213, October 2005.

9.2. Informative References

[I-D.herbert-gue-fragmentation]	Herbert, T. and F. Templin, "Fragmentation option for Generic UDP Encapsulation", Internet-Draft draft-herbert-gue-fragmentation-00, March 2015.
[I-D.ietf-nvo3-gue]	Herbert, T., Yong, L. and O. Zia, "Generic UDP Encapsulation", Internet-Draft draft-ietf-nvo3-gue-01, June 2015.
[I-D.templin-aerolink]	Templin, F., "Asymmetric Extended Route Optimization (AERO)", Internet-Draft draft-templin-aerolink-61, August 2015.
[I-D.templin-intarea-grefrag]	Templin, F., "GRE Tunnel Fragmentation", Internet-Draft draft-templin-intarea-grefrag-00, April 2015.

Author's Address

Fred L. Templin (editor) Boeing Research & Technology P.O. Box 3707 Seattle, WA 98124 USA EMail: fltemplin@acm.org

Abstract

Status of This Memo

Copyright Notice

Table of Contents