Network Working Group
Internet Engineering Task Force (IETF)                        M. Eubanks
Internet-Draft
Request for Comments: 6935                            AmericaFree.TV LLC
Updates: 2460 (if approved)                                                P. Chimento
Intended status:
Category: Standards Track               Johns Hopkins University Applied
Expires: August 25, 2013
ISSN: 2070-1721                                       Physics Laboratory
                                                           M. Westerlund
                                                                Ericsson
                                                       February 21,
                                                              April 2013

              IPv6 and UDP Checksums for Tunneled Packets
                    draft-ietf-6man-udpchecksums-08

Abstract

   This document provides an update of updates the Internet Protocol version 6
   (IPv6) IPv6 specification (RFC2460) (RFC 2460) to improve the
   performance in the use
   case where when a tunnel protocol uses UDP with IPv6 to tunnel
   packets.  The performance improvement is obtained by relaxing the
   IPv6 UDP checksum requirement for any suitable tunnel protocol where protocols whose header
   information is protected on the "inner" packet being carried.  This
   relaxation
   Relaxing this requirement removes the overhead associated with the
   computation of UDP checksums on IPv6 packets used to that carry the tunnel protocols.  The
   protocol packets.  This specification describes how the IPv6 UDP
   checksum requirement can be relaxed for the situation where when the encapsulated packet
   itself contains a checksum.  The  It also describes the limitations and
   risks of this approach are
   described, and discusses the restrictions specified on the use of the
   this method.

Status of this This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents an Internet Standards Track document.

   This document is a product of the Internet Engineering Task Force
   (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list  It represents the consensus of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid the IETF community.  It has
   received public review and has been approved for a maximum publication by the
   Internet Engineering Steering Group (IESG).  Further information on
   Internet Standards is available in Section 2 of six months RFC 5741.

   Information about the current status of this document, any errata,
   and how to provide feedback on it may be updated, replaced, or obsoleted by other documents obtained 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 August 25, 2013.
   http://www.rfc-editor.org/info/rfc6935.

Copyright Notice

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

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Some  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  4
     2.1.  Requirements Language  . . . . . . . . . . . . . . . . . .  4
   3.  Problem Statement  . . . . . . . . . . . . . . . . . . . . . .  4
   4.  Discussion . . . . . . . . . . . . . . . . . . . . . . . . . .  4
     4.1.  Analysis of Corruption in Tunnel Context . . . . . . . . .  5
     4.2.  Limitation to Tunnel Protocols . . . . . . . . . . . . . .  7
     4.3.  Middleboxes  . . . . . . . . . . . . . . . . . . . . . . .  8
   5.  The Zero-Checksum Zero UDP Checksum Update . . . . . . . . . . . . . . . . . . .  8
   6.  Additional Observations  . . . . . . . . . . . . . . . . . . . 10  9
   7.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 10
   8.  Security Considerations  . . . . . . . . . . . . . . . . . . . 10
   9.  Acknowledgements
   8.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 11
   10.
   9.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
     10.1.
     9.1.  Normative References . . . . . . . . . . . . . . . . . . . 11
     10.2.
     9.2.  Informative References . . . . . . . . . . . . . . . . . . 12
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 11

1.  Introduction

   This work document constitutes an update of the Internet Protocol Version 6
   (IPv6) Specification [RFC2460], in the use case IPv6 specification
   [RFC2460] for cases where a tunnel protocol uses UDP with IPv6 to
   tunnel packets.  With the rapid growth of the Internet, tunnel
   protocols have become increasingly important to enable the deployment
   of new protocols.  Tunnel protocols can be deployed rapidly, while
   the time to upgrade and deploy a new protocol on a critical mass of
   routers, middleboxes middleboxes, and hosts on the global Internet for a
   new protocol is now
   measured in decades.  At the same time, the increasing use of
   firewalls and other security-related middleboxes means that truly new
   tunnel protocols, with new protocol numbers, are also unlikely to be
   deployable in a reasonable time frame, which has
   resulted in frame.  The result is an increasing
   interest in and use of UDP-based tunnel protocols.  In such
   protocols, there is an encapsulated "inner" packet, and the "outer"
   packet carrying the tunneled inner packet is a UDP packet, which can
   pass through firewalls and other middleboxes that perform the
   filtering that is a fact of life on the current Internet.

   Tunnel endpoints may be routers or middleboxes aggregating traffic
   from a number of tunnel users, therefore users.  Therefore, the computation of an
   additional checksum on the outer UDP packet may be seen as an
   unwarranted burden on nodes that implement a tunnel protocol,
   especially if the inner packet(s) packets are already protected by a checksum.  In IPv4, there is
   IPv4 has a checksum over the IP packet header, and the checksum on
   the outer UDP packet may be set to zero.  However
   in  However, IPv6 there is has no
   checksum in the IP header header, and RFC 2460 [RFC2460] explicitly states
   that IPv6 receivers MUST discard UDP packets with a zero checksum.
   So, while sending a UDP datagram with a zero checksum is permitted in
   IPv4 packets, it is explicitly forbidden in IPv6 packets.  To improve
   support for IPv6 UDP tunnels, this document updates RFC 2460 to allow
   endpoints to use a zero UDP checksum under constrained situations
   (primarily for IPv6 tunnel transports that carry checksum-protected
   packets), following the applicability statements and constraints in [I-D.ietf-6man-udpzero].
   [RFC6936].

   When reading this document, the advice in "Unicast UDP Usage
   Guidelines for Application Designers" [RFC5405]
   should be consulted when reading this specification. is applicable.  It
   discusses both UDP tunnels (Section 3.1.3) and the usage of checksums
   (Section 3.4).

   While the origin of this specification is the problem raised by the
   draft titled "Automatic Multicast Tunnels", also known as "AMT"
   [I-D.ietf-mboned-auto-multicast]
   [AMT], we expect it to have wide applicability.  Since the first version
   draft of this document, RFC was written, the need for an efficient UDP
   tunneling mechanism has increased.  Other IETF Working Groups,
   notably LISP [RFC6830] and Softwires [RFC5619] [RFC5619], have expressed a need
   to update the UDP checksum processing in RFC 2460.  We therefore
   expect this update to be applicable in the future to other tunnel
   protocols specified by these and other IETF Working Groups.

2.  Some  Terminology

   This document discusses only IPv6, since this because the problem being
   addressed does not exist for IPv4.  Therefore  Therefore, all reference references to 'IP' "IP"
   should be understood as a
   reference references to IPv6.

   The document uses the terms "tunneling" and "tunneled" as adjectives
   when describing packets.  When we refer to 'tunneling packets' "tunneling packets", we
   refer to the outer packet header that provides the tunneling
   function.  When we refer to 'tunneled packets' "tunneled packets", we refer to the inner
   packet, i.e., the packet being carried in the tunnel.

2.1.  Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [RFC2119].

3.  Problem Statement

   When using tunnel protocols based on UDP, there can be both a benefit
   and a cost to computing and checking the UDP checksum of the outer
   (encapsulating) UDP transport header.  In certain cases, where
   reducing the forwarding cost is important, e.g., for nodes that perform the
   checksum in software the cost of the
   computation may outweigh the benefit. benefit of the checksum.  This document
   provides an update for usage of the UDP checksum with IPv6.  The
   update is specified for use by a tunnel protocol that transports
   packets that are themselves protected by a checksum.

4.  Discussion

   "Applicability Statement for the use Use of IPv6 UDP Datagrams with Zero
   Checksums" [I-D.ietf-6man-udpzero] [RFC6936] describes issues related to allowing UDP over
   IPv6 to have a valid zero UDP checksum and is the starting point for
   this discussion.  Sections 4 and 5 of
   [I-D.ietf-6man-udpzero], respectively [RFC6936], respectively,
   identify node implementation and usage requirements for datagrams
   sent and received with a zero UDP checksum.  These sections introduce
   constraints on the usage of a zero checksum for UDP over IPv6.  The
   remainder of this section analyses analyzes the use of general tunnels and motivates
   explains the motivations for why tunnel protocols are being permitted
   to use the method described in this update.  Issues
   with middleboxes are  It also discussed. discusses issues
   with middleboxes.

4.1.  Analysis of Corruption in Tunnel Context

   This section analyzes the impact of the different corruption modes in
   the context of a tunnel protocol.  It indicates specifies what needs to be
   considered by the designer and user of a tunnel protocol for the
   protocol to be robust.  It also summarizes why use of a zero UDP
   checksum is thought to be safe for deployment.

   1.

   o  Context (i.e., tunneling state) should be established by
      exchanging application Protocol Data Units (PDUs) carried in
      checksummed UDP datagrams or by using other protocols with that provide
      integrity protection against corruption.  These control packets
      should also carry any negotiation required to enable the tunnel
      endpoint to accept UDP datagrams with a zero checksum and identify
      the set of ports that are used.  It is important that the control
      traffic is robust against corruption corruption, because undetected errors
      can lead to long-lived and significant failures that may affect
      much more than the single packet that was corrupted.

   2.  Keep-alive

   o  Keepalive datagrams with a zero UDP checksum should be sent to
      validate the network path, because the path between tunnel
      endpoints can change change, and therefore therefore, the set of middleboxes along
      the path may change during the life of an association.  Paths with
      middleboxes that drop datagrams with a zero UDP checksum will drop
      these keep-alives. keepalives.  To enable the tunnel endpoints to discover and
      react to this behavior in a timely way, the keep-
       alive keepalive traffic
      should include datagrams with a non-zero checksum and datagrams
      with a zero checksum.

   3.

   o  Receivers should attempt to detect corruption of the address
      information in an encapsulating packet.  A robust tunnel protocol
      should track tunnel context based on the 5-tuple (tunneled
      protocol number, IPv6 source address, IPv6 destination address,
      UDP source port, UDP destination port).  A corrupted datagram that
      arrives at a destination may be filtered based on this check.

      *  If the datagram header matches the 5-tuple and the node has
         enabled the zero checksum enabled for this port, the payload is matched
         to the wrong context.  The tunneled packet will then be
         decapsulated and forwarded by the tunnel egress.

      *  If a corrupted datagram matches a different 5-tuple and the
         node has enabled zero checksum was enabled for the port, the datagram
         payload is matched to the wrong context, context and may be processed by
         the wrong tunnel protocol, if provided that it also passes the
         verification of that protocol.

      *  If a corrupted datagram matches a 5-tuple and the zero
          checksum node has not been
         enabled the zero checksum for this port, the datagram will be
         discarded.

      When only the source information is corrupted, the datagram could
      arrive at the intended applications/protocol, applications or protocol, which will
      process the datagram and try to match it against an existing
      tunnel context.  The likelihood that a corrupted packet enters a
      valid context is reduced when the protocol restricts processing to
      only the source addresses with established contexts.  When both
      source and destination fields are corrupted, this increases also decreases
      the likelihood of failing to match matching a context, with context.  However, the exception of
       errors replacing one packet header with another one.  In this
       case, it is possible that
      when errors replace one packet header with another, so both
      packets are tunnelled could be tunneled, and therefore the corrupted packet
      could match a previously defined context.

   4.

   o  Receivers should attempt to detect corruption of source-
       fragmented source-fragmented
      encapsulating packets.  A tunnel protocol may reassemble fragments
      associated with the wrong context at the right tunnel endpoint, or it
      may reassemble fragments associated with a context at the wrong
      tunnel endpoint, or corrupted fragments may be reassembled at the
      right context at the right tunnel endpoint.  In each of these
      cases, the IPv6 length of the encapsulating header may be checked (though
       [I-D.ietf-6man-udpzero]
      (although [RFC6936] points out the weakness in this check).  In
      addition, if the encapsulated packet is protected by a transport
      (or other) checksum, these errors can be detected (with some
      probability).

   5.  Tunnel

   o  Compared to other applications, tunnel protocols using UDP have
      some advantages that reduce the risk for a corrupted tunnel packet
      reaching a destination that will receive it, compared to other applications.  This results it.  These advantages
      result from processing by the network of the inner (tunneled)
      packet after being it is forwarded from the tunnel egress using a wrong
      context:

      *  A tunneled packet may be forwarded to the wrong address domain,
         for example, to a private address domain where the inner
         packet's address is not routable, or it may fail a source
         address check, such as Unicast Reverse Path Forwarding
         [RFC2827], resulting in the packet being dropped.

      *  The destination address of a tunneled packet may not at all be
         reachable at all from the delivered domain.  For example,  An example is an
         Ethernet frame where the destination MAC address is not present
         on the LAN segment that was reached.

      *  The type of the tunneled packet may prevent delivery.  For
         example, an attempt to interpret an IP packet payload as an
         Ethernet frame, frame would likely to result in the packet being
         dropped as invalid.

      *  The tunneled packet checksum or integrity mechanism may detect
         corruption of the inner packet caused at the same time as
         corruption to the outer packet header.  The resulting packet
         would likely be dropped as invalid.

   These

   Each of these checks each significantly reduce reduces the likelihood that a
   corrupted inner tunneled packet is finally delivered to a protocol
   listener that can be affected by the packet.  While the methods do
   not guarantee correctness, they can reduce the risk risks of relaxing the
   UDP checksum requirement for a tunnel application using IPv6.

4.2.  Limitation to Tunnel Protocols

   This document describes the applicability of using a zero UDP
   checksum to support tunnel protocols.  There are good motivations
   behind this this, and the arguments are provided here.

   o  Tunnels carry inner packets that have their own semantics, which
      may make any corruption less likely to reach the indicated
      destination and be accepted as a valid packet.  This is true for
      IP packets with the addition of verification that can be made by
      the tunnel protocol, the network processing of the inner packet
      headers as discussed above, and verification of the inner packet
      checksums.  Non-IP inner packets are likely to be subject to
      similar effects that may reduce the likelihood of a misdelivered
      packet being delivered to a protocol listener that can be affected
      by the packet.

   o  Protocols that directly consume the payload must have sufficient
      robustness against misdelivered packets from (from any context, context),
      including the ones that are corrupted in tunnels and any or corrupted by other
      usage of the zero checksum.  This will require an integrity
      mechanism.  Using a standard UDP checksum reduces the
      computational load in the receiver that is necessary to verify
      this mechanism.

   o  The design for stateful protocols or protocols where corruption
      causes cascade effects requires extra care.  In tunnel usage, each
      encapsulating packet provides only no functions other than a transport mechanism
      from tunnel ingress to tunnel egress.  A corruption will commonly only
      affect only the single tunneled packet, not the established
      protocol state.  One common effect is that the inner packet flow
      will only see only a corruption and a misdelivery of the outer packet
      as a lost packet.

   o  Some non-tunnel protocols operate with general servers that do not
      know the source from which they will receive a packet.  In such
      applications, a zero UDP checksum is unsuitable unsuitable, because there it is a
      need
      necessary to provide the first level of verification that the
      packet was intended for the receiving server.  A verification
      prevents the server from processing the datagram payload and payload; without this
      it
      this, the server may spend significant resources processing the
      packet, including sending replies or error messages.

   Tunnel protocols that encapsulate IP will generally be safe for
   deployment, since because all IPv4 and IPv6 packets include at least one
   checksum at either the network or transport layer.  The network
   delivery of the inner packet will then further reduce the effects of
   corruption.  Tunnel protocols carrying non-IP packets may offer
   equivalent protection when the non-IP networks reduce the risk of
   misdelivery to applications.  However, there is a need for further analysis is necessary
   to understand the implications of misdelievery misdelivery of corrupted packets
   for that each non-IP protocol.  The analysis above suggests that non-tunnel non-
   tunnel protocols can be expected to have significantly more cases
   where a zero checksum would result in misdelivery or negative
   side-effects. side
   effects.

   One unfortunate side-effect side effect of increased use of a zero-checksum zero checksum is
   that it also increases the likelihood of acceptance when a datagram
   with a zero UDP checksum is misdelivered.  This requires all tunnel
   protocols using this method to be designed to be robust to in the face
   of misdelivery.

4.3.  Middleboxes

   "Applicability Statement for the use Use of IPv6 UDP Datagrams with Zero
   Checksums" [I-D.ietf-6man-udpzero] notes that [RFC6936] specifies requirements for middleboxes and
   tunnels that
   conform need to RFC 2460 will discard datagrams with a zero UDP checksum
   and should log this as an error. traverse middleboxes.  Tunnel protocols
   intending to use a zero UDP checksum need to ensure that they have
   defined a method for handling cases when a middlebox prevents the
   path between the tunnel ingress and egress from supporting
   transmission of datagrams with a zero UDP checksum.  This is
   especially important as middleboxes that conform to RFC 2460 are
   likely to discard datagrams with a zero UDP checksum.

5.  The Zero-Checksum Zero UDP Checksum Update

   This specification updates IPv6 to allow a zero UDP checksum in the
   outer encapsulating datagram of a tunnel protocol.  UDP endpoints
   that implement this update MUST follow the node requirements in
   "Applicability Statement for the use Use of IPv6 UDP Datagrams with Zero
   Checksums" [I-D.ietf-6man-udpzero]. [RFC6936].

   The following text in [RFC2460] [RFC2460], Section 8.1, 4th fourth bullet should be
   deleted:

   "Unlike IPv4, when UDP packets are originated by an IPv6 node, the
   UDP checksum is not optional.  That is, whenever originating a UDP
   packet, an IPv6 node must compute a UDP checksum over the packet and
   the pseudo-header, and, if that computation yields a result of zero,
   it must be changed to hex FFFF for placement in the UDP header.  IPv6
   receivers must discard UDP packets containing a zero checksum, and
   should log the error."

   This text should be replaced by:

      An IPv6 node associates a mode with each used UDP port (for
      sending and/or receiving packets).

      Whenever originating a UDP packet for a port in the default mode,
      an IPv6 node MUST compute a UDP checksum over the packet and the
      pseudo-header, and, if that computation yields a result of zero,
      it
      the checksum MUST be changed to hex FFFF for placement in the UDP header
      header, as specified in [RFC2460].  IPv6 receivers MUST by default
      discard UDP packets containing a zero checksum, checksum and SHOULD log the
      error.

      As an alternative, certain protocols that use UDP as a tunnel
      encapsulation,
      encapsulation MAY enable the zero-checksum mode for a specific port
      (or set of ports) for sending and/or receiving.  Any node
      implementing the zero-checksum mode MUST follow the node requirements
      specified in Section 4 of "Applicability Statement for the use of
      IPv6 UDP Datagrams with Zero Checksums"
      [I-D.ietf-6man-udpzero]. [RFC6936].

      Any protocol that enables the zero-checksum mode for a specific port
      or ports MUST follow the usage requirements specified in Section 5
      of "Applicability Statement for the use Use of IPv6 UDP Datagrams with
      Zero Checksums" [I-D.ietf-6man-udpzero]. [RFC6936].

      Middleboxes supporting IPv6 MUST follow requirements 9, 10 10, and 11
      of the usage requirements specified in Section 5 of "Applicability
      Statement for the use Use of IPv6 UDP Datagrams with Zero Checksums"
      [I-D.ietf-6man-udpzero].
      [RFC6936].

6.  Additional Observations

   This update was motivated by the existence of a number of protocols
   being developed in the IETF that are expected to benefit from the
   change.  The following observations are made:

   o  An empirically-based empirically based analysis of the probabilities of packet
      corruption (with or without checksums) has not (to not, to our knowledge) knowledge,
      been conducted since about 2000.  At the time of publication, it
      is now 2012. 2013.  We strongly suggest that a new empirical study, study be
      performed, along with an extensive analysis of the corruption
      probabilities of the IPv6 header.  This can could potentially allow
      revising the recommendations in this document.

   o  A key motivation for the increase in use of UDP in tunneling is a
      lack of protocol support in middleboxes.  Specifically, new
      protocols, such as LISP [RFC6830], may prefer to use UDP tunnels
      to traverse an end-to-end path successfully and avoid having their
      packets dropped by middleboxes.  If middleboxes were updated to
      support UDP-Lite [RFC3828], UDP-Lite would provide better
      protection than offered by this update.  This  UDP-Lite may be suited to
      a variety of applications and would be expected to be preferred
      over this method for many tunnel protocols.

   o  Another issue is that the UDP checksum is overloaded with the task
      of protecting the IPv6 header for UDP flows (as is the TCP
      checksum for TCP flows).  Protocols that do not use a pseudo-
      header approach to computing a checksum or CRC have essentially no
      protection from misdelivered packets.

7.  IANA Considerations

   This document makes no request of IANA.

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

8.  Security Considerations

   Less work is required to generate an attack using a zero UDP checksum
   than one using a standard full UDP checksum.  However, this does not
   lead to significant new vulnerabilities vulnerabilities, because checksums are not a
   security measure and can be easily generated by any attacker.

   In general general, any user of zero UDP checksums should apply the checks
   and context verification that are possible to minimize the risk of
   unintended traffic to reach a particular context.  This will however will,
   however, not protect against an intended intentional attack that create packet creates
   packets with the correct information.  Source address validation can
   help prevent injection of traffic into contexts by an attacker.

   Depending on the hardware design, the processing requirements may
   differ for tunnels that have a zero UDP checksum and those that
   calculate a checksum.  This processing overhead may need to be
   considered when deciding whether to enable a tunnel and to determine
   an acceptable rate for transmission.  This processing overhead can
   become a security risk for designs that can handle a significantly
   larger number of packets with zero UDP checksums compared to
   datagrams with a non-zero checksum, such as a tunnel egress.  An
   attacker could attempt to inject non-zero checksummed UDP packets
   into a tunnel forwarding zero checksum UDP packets and cause overload
   in the processing of the non-
   zero non-zero checksums, e.g. e.g., if this happens in
   a routers router's slow path.
   Protection  Therefore, protection mechanisms should therefore be
   employed when this threat exists.  Protection may include source source-
   address filtering to prevent an attacker from injecting traffic, as
   well as throttling the amount of non-zero checksum traffic.  The
   latter may impact the function functioning of the tunnel protocol.

9.  Acknowledgements

8.  Acknowledgments

   We would like to thank Brian Haberman, Dan Wing, Joel Halpern, David
   Waltermire, J.W. Atwood, Peter Yee, Joe Touch Touch, and the IESG of 2012
   for discussions and reviews.  Gorry Fairhurst has been very diligent
   in reviewing and help ensuring helping to ensure alignment between this document
   and
   [I-D.ietf-6man-udpzero].

10. [RFC6936].

9.  References

10.1.

9.1.  Normative References

   [I-D.ietf-6man-udpzero]
              Fairhurst, G. and M. Westerlund, "Applicability Statement
              for the use of IPv6 UDP Datagrams with Zero Checksums",
              draft-ietf-6man-udpzero-10 (work in progress),
              January 2013.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

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

10.2.

   [RFC6936]  Fairhurst, G. and M. Westerlund, "Applicability Statement
              for the Use of IPv6 UDP Datagrams with Zero Checksums",
              RFC 6936, April 2013.

9.2.  Informative References

   [I-D.ietf-mboned-auto-multicast]

   [AMT]      Bumgardner, G., "Automatic Multicast Tunneling",
              draft-ietf-mboned-auto-multicast-14 (work Work
              in progress), Progress, June 2012.

   [RFC2827]  Ferguson, P. and D. Senie, "Network Ingress Filtering:
              Defeating Denial of Service Attacks which employ IP Source
              Address Spoofing", BCP 38, RFC 2827, May 2000.

   [RFC3828]  Larzon, L-A., Degermark, M., Pink, S., Jonsson, L-E., and
              G. Fairhurst, "The Lightweight User Datagram Protocol
              (UDP-Lite)", RFC 3828, July 2004.

   [RFC5405]  Eggert, L. and G. Fairhurst, "Unicast UDP Usage Guidelines
              for Application Designers", BCP 145, RFC 5405,
              November 2008.

   [RFC5619]  Yamamoto, S., Williams, C., Yokota, H., and F. Parent,
              "Softwire Security Analysis and Requirements", RFC 5619,
              August 2009.

   [RFC6830]  Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The
              Locator/ID Separation Protocol (LISP)", RFC 6830,
              January 2013.

Authors' Addresses

   Marshall Eubanks
   AmericaFree.TV LLC
   P.O. Box 141
   Clifton, Virginia  20124
   USA

   Phone: +1-703-501-4376
   Fax:
   Email:
   EMail: marshall.eubanks@gmail.com

   P.F. Chimento
   Johns Hopkins University Applied Physics Laboratory
   11100 Johns Hopkins Road
   Laurel, MD Maryland  20723
   USA

   Phone: +1-443-778-1743
   Email:
   EMail: Philip.Chimento@jhuapl.edu

   Magnus Westerlund
   Ericsson
   Farogatan 6
   SE-164 80 Kista
   Sweden

   Phone: +46 10 714 82 87
   Email: 719 00 00
   EMail: magnus.westerlund@ericsson.com