Tech-invite3GPPspaceIETFspace
96959493929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 6621

Simplified Multicast Forwarding

Pages: 55
Experimental
Errata
Part 1 of 3 – Pages 1 to 20
None   None   Next

Top   ToC   RFC6621 - Page 1
Internet Engineering Task Force (IETF)                    J. Macker, Ed.
Request for Comments: 6621                                           NRL
Category: Experimental                                          May 2012
ISSN: 2070-1721


                    Simplified Multicast Forwarding

Abstract

This document describes a Simplified Multicast Forwarding (SMF) mechanism that provides basic Internet Protocol (IP) multicast forwarding suitable for limited wireless mesh and mobile ad hoc network (MANET) use. It is mainly applicable in situations where efficient flooding represents an acceptable engineering design trade- off. It defines techniques for multicast duplicate packet detection (DPD), to be applied in the forwarding process, for both IPv4 and IPv6 protocol use. This document also specifies optional mechanisms for using reduced relay sets to achieve more efficient multicast data distribution within a mesh topology as compared to Classic Flooding. Interactions with other protocols, such as use of information provided by concurrently running unicast routing protocols or interaction with other multicast protocols, as well as multiple deployment approaches are also described. Distributed algorithms for selecting reduced relay sets and related discussion are provided in the appendices. Basic issues relating to the operation of multicast MANET border routers are discussed, but ongoing work remains in this area and is beyond the scope of this document. Status of This Memo This document is not an Internet Standards Track specification; it is published for examination, experimental implementation, and evaluation. This document defines an Experimental Protocol for the Internet community. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741. Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6621.
Top   ToC   RFC6621 - Page 2
Copyright Notice

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

   This document may contain material from IETF Documents or IETF
   Contributions published or made publicly available before November
   10, 2008.  The person(s) controlling the copyright in some of this
   material may not have granted the IETF Trust the right to allow
   modifications of such material outside the IETF Standards Process.
   Without obtaining an adequate license from the person(s) controlling
   the copyright in such materials, this document may not be modified
   outside the IETF Standards Process, and derivative works of it may
   not be created outside the IETF Standards Process, except to format
   it for publication as an RFC or to translate it into languages other
   than English.

Table of Contents

1. Introduction and Scope ..........................................4 2. Terminology .....................................................4 3. Applicability Statement .........................................5 4. Overview and Functioning ........................................6 5. SMF Packet Processing and Forwarding ............................8 6. SMF Duplicate Packet Detection .................................10 6.1. IPv6 Duplicate Packet Detection ...........................11 6.1.1. IPv6 SMF_DPD Option Header .........................12 6.1.2. IPv6 Identification-Based DPD ......................14 6.1.3. IPv6 Hash-Based DPD ................................16 6.2. IPv4 Duplicate Packet Detection ...........................17 6.2.1. IPv4 Identification-Based DPD ......................18 6.2.2. IPv4 Hash-Based DPD ................................19 7. Relay Set Selection ............................................20 7.1. Non-Reduced Relay Set Forwarding ..........................20 7.2. Reduced Relay Set Forwarding ..............................20 8. SMF Neighborhood Discovery Requirements ........................23 8.1. SMF Relay Algorithm TLV Types .............................24 8.1.1. SMF Message TLV Type ...............................24
Top   ToC   RFC6621 - Page 3
           8.1.2. SMF Address Block TLV Type .........................25
   9. SMF Border Gateway Considerations ..............................26
      9.1. Forwarded Multicast Groups ................................27
      9.2. Multicast Group Scoping ...................................28
      9.3. Interface with Exterior Multicast Routing Protocols .......29
      9.4. Multiple Border Routers ...................................29
   10. Security Considerations .......................................31
   11. IANA Considerations ...........................................32
      11.1. IPv6 SMF_DPD Header Extension Option Type ................33
      11.2. TaggerId Types (TidTy) ...................................33
      11.3. Well-Known Multicast Address .............................34
      11.4. SMF TLVs .................................................34
           11.4.1. Expert Review for Created Type Extension
                   Registries ........................................34
           11.4.2. SMF Message TLV Type (SMF_TYPE) ...................34
           11.4.3. SMF Address Block TLV Type (SMF_NBR_TYPE) .........35
           11.4.4. SMF Relay Algorithm ID Registry ...................35
   12. Acknowledgments ...............................................36
   13. References ....................................................37
      13.1. Normative References .....................................37
      13.2. Informative References ...................................38
   Appendix A.  Essential Connecting Dominating Set (E-CDS)
                Algorithm ............................................40
     A.1.  E-CDS Relay Set Selection Overview ........................40
     A.2.  E-CDS Forwarding Rules ....................................41
     A.3.  E-CDS Neighborhood Discovery Requirements .................41
     A.4.  E-CDS Selection Algorithm .................................44
   Appendix B.  Source-Based Multipoint Relay (S-MPR) Algorithm ......46
     B.1.  S-MPR Relay Set Selection Overview ........................46
     B.2.  S-MPR Forwarding Rules ....................................47
     B.3.  S-MPR Neighborhood Discovery Requirements .................48
     B.4.  S-MPR Selection Algorithm .................................50
   Appendix C.  Multipoint Relay Connected Dominating Set
                (MPR-CDS) Algorithm ..................................52
     C.1.  MPR-CDS Relay Set Selection Overview ......................52
     C.2.  MPR-CDS Forwarding Rules ..................................53
     C.3.  MPR-CDS Neighborhood Discovery Requirements ...............53
     C.4.  MPR-CDS Selection Algorithm ...............................54
Top   ToC   RFC6621 - Page 4

1. Introduction and Scope

Unicast routing protocols, designed for MANET and wireless mesh use, often apply distributed algorithms to flood routing control plane messages within a MANET routing domain. For example, algorithms specified within [RFC3626] and [RFC3684] provide distributed methods of dynamically electing reduced relay sets that attempt to efficiently flood routing control messages while maintaining a connected set under dynamic topological conditions. Simplified Multicast Forwarding (SMF) extends the efficient flooding concept to the data forwarding plane, providing an appropriate multicast forwarding capability for use cases where localized, efficient flooding is considered an effective design approach. The baseline design is intended to provide a basic, best-effort multicast forwarding capability that is constrained to operate within a single MANET routing domain. An SMF routing domain is an instance of an SMF routing protocol with common policies, under a single network administration authority. The main design goals of this document are to: o adapt efficient relay sets in MANET environments [RFC2501], and o define the needed IPv4 and IPv6 multicast duplicate packet detection (DPD) mechanisms to support multi-hop packet forwarding.

2. Terminology

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. The terms introduced in [RFC5444], including "packet", "message", "TLV Block", "TLV", and "address", are to be interpreted as described therein.
Top   ToC   RFC6621 - Page 5
   The following abbreviations are used throughout this document:

   +--------------+----------------------------------------------------+
   | Abbreviation | Definition                                         |
   +--------------+----------------------------------------------------+
   | MANET        | Mobile Ad Hoc Network                              |
   | SMF          | Simplified Multicast Forwarding                    |
   | CF           | Classic Flooding                                   |
   | CDS          | Connected Dominating Set                           |
   | MPR          | Multipoint Relay                                   |
   | S-MPR        | Source-based MPR                                   |
   | MPR-CDS      | MPR-based CDS                                      |
   | E-CDS        | Essential CDS                                      |
   | NHDP         | Neighborhood Discovery Protocol                    |
   | DPD          | Duplicate Packet Detection                         |
   | I-DPD        | Identification-based DPD                           |
   | H-DPD        | Hash-based DPD                                     |
   | HAV          | Hash assist value                                  |
   | FIB          | Forwarding Information Base                        |
   | TLV          | type-length-value encoding                         |
   | DoS          | Denial of Service                                  |
   | SMF Router   | A MANET Router implementing the protocol specified |
   |              | in this document                                   |
   | SMF Routing  | A MANET Routing Domain wherein the protocol        |
   | Domain       | specified in this document is operating            |
   +--------------+----------------------------------------------------+

3. Applicability Statement

Within dynamic wireless routing topologies, maintaining traditional forwarding trees to support a multicast routing protocol is often not as effective as in wired networks due to the reduced reliability and increased dynamics of mesh topologies [MGL04][GM99]. A basic packet forwarding service reaching all connected routers running the SMF protocol within a MANET routing domain may provide a useful group communication paradigm for various classes of applications, for example, multimedia streaming, interactive group-based messaging and applications, peer-to-peer middleware multicasting, and multi-hop mobile discovery or registration services. SMF is likely only appropriate for deployment in limited dynamic MANET routing domains (further defined as administratively scoped multicast forwarding domains in Section 9.2) so that the flooding process can be contained. A design goal is that hosts may also participate in multicast traffic transmission and reception with standard IP network-layer semantics (e.g., special or unnecessary encapsulation of IP packets should be avoided in this case). SMF deployments are able to connect and
Top   ToC   RFC6621 - Page 6
   interoperate with existing standard multicast protocols operating
   within more conventional Internet infrastructures.  To this end, a
   multicast border router or proxy mechanism MUST be used when deployed
   alongside more fixed-infrastructure IP multicast routing such
   Protocol Independent Multicast (PIM) variants [RFC3973][RFC4601].
   Experimental SMF implementations and deployments have demonstrated
   gateway functionality at MANET border routers operating with existing
   external IP multicast routing protocols [CDHM07][DHS08][DHG09].  SMF
   may be extended or combined with other mechanisms to provide
   increased reliability and group-specific filtering; the details for
   this are out of the scope of this document.

   This document does not presently support forwarding of packets with
   directed broadcast addresses as a destination [RFC2644].

4. Overview and Functioning

Figure 1 provides an overview of the logical SMF router architecture, consisting of "Neighborhood Discovery", "Relay Set Selection", and "Forwarding Process" components. Typically, relay set selection (or self-election) occurs based on dynamic input from a neighborhood discovery process. SMF supports the case where neighborhood discovery and/or relay set selection information is obtained from a coexistent process (e.g., a lower-layer mechanism or a unicast routing protocol using relay sets). In some algorithm designs, the forwarding decision for a packet can also depend on previous hop or incoming interface information. The asterisks (*) in Figure 1 mark the primitives and relationships needed by relay set algorithms requiring previous-hop packet-forwarding knowledge. ______________ _____________ | | | | | Neighborhood | | Relay Set | | Discovery |------------->| Selection | | | neighbor | | |______________| info |_____________| \ / \ / neighbor\ /forwarding info* \ ____________ / status \ | | / `-->| Forwarding |<--' | Process | ~~~~~~~~~~~~~~~~~>|____________|~~~~~~~~~~~~~~~~~> incoming packet, forwarded packets interface id*, and previous hop* Figure 1: SMF Router Architecture
Top   ToC   RFC6621 - Page 7
   Certain IP multicast packets, defined in Sections 9.2 and 5, are
   "non-forwardable".  These multicast packets MUST be ignored by the
   SMF forwarding engine.  The SMF forwarding engine MAY also work with
   policies and management interfaces to allow additional filtering
   control over which multicast packets are considered for potential SMF
   forwarding.  This interface would allow more refined dynamic
   forwarding control once such techniques are matured for MANET
   operation.  At present, further discussion of dynamic control is left
   to future work.

   Interoperable SMF implementations MUST use compatible DPD approaches
   and be able to process the header options defined in this document
   for IPv6 operation.

   Classic Flooding (CF) is defined as the simplest case of SMF
   multicast forwarding.  With CF, all SMF routers forward each received
   multicast packet exactly once.  In this case, the need for any relay
   set selection or neighborhood topology information is eliminated, at
   the expense of additional network overhead incurred from unnecessary
   packet retransmissions.  With CF, the SMF DPD functionality is still
   required.  While SMF supports CF as a mode of operation, the use of
   more efficient relay set modes is RECOMMENDED in order to reduce
   contention and congestion caused by unnecessary packet
   retransmissions [NTSC99].

   An efficient reduced relay set is constructed by selecting and
   updating, as needed, a subset of all possible routers in a MANET
   routing domain to act as SMF forwarders.  Known distributed relay set
   selection algorithms have demonstrated the ability to provide and
   maintain a dynamic connected set for forwarding multicast IP packets
   [MDC04].  A few such relay set selection algorithms are described in
   the appendices of this document, and the basic designs borrow
   directly from previously documented IETF work.  SMF relay set
   configuration is extensible, and additional relay set algorithms
   beyond those specified here can be accommodated in future work.

   Determining and maintaining an optimized set of relays generally
   requires dynamic neighborhood topology information.  Neighborhood
   topology discovery functions MAY be provided by a MANET unicast
   routing protocol or by using the MANET Neighborhood Discovery
   Protocol (NHDP) [RFC6130], operating concurrently with SMF.  This
   specification also allows alternative lower-layer interfaces (e.g.,
   radio router interfaces) to provide the necessary neighborhood
   information to aid in supporting more effective relay set selection.
   An SMF implementation SHOULD provide the ability for multicast
   forwarding state to be dynamically managed per operating network
   interface.  The relay state maintenance options and interactions are
   outlined in Section 7.  This document states specific requirements
Top   ToC   RFC6621 - Page 8
   for neighborhood discovery with respect to the forwarding process and
   the relay set selection algorithms described herein.  For determining
   dynamic relay sets in the absence of other control protocols, SMF
   relies on NHDP to assist in IP-layer 2-hop neighborhood discovery and
   maintenance for relay set selection.  "SMF_TYPE" and "SMF_NBR_TYPE"
   Message and Address Block TLV structures (per [RFC5444]) are defined
   by this document for use with NHDP to carry SMF-specific information.
   It is RECOMMENDED that all routers performing SMF operation in
   conjunction with NHDP include these TLV types in any NHDP HELLO
   messages generated.  This capability allows for routers participating
   in SMF to be explicitly identified along with their respective
   dynamic relay set algorithm configuration.

5. SMF Packet Processing and Forwarding

The SMF packet processing and forwarding actions are conducted with the following packet handling activities: 1. Processing of outbound, locally generated multicast packets. 2. Reception and processing of inbound packets on specific network interfaces. The purpose of intercepting outbound, locally generated multicast packets is to apply any added packet marking needed to satisfy the DPD requirements so that proper forwarding may be conducted. Note that for some system configurations, the interception of outbound packets for this purpose is not necessary. Inbound multicast packets are received by the SMF implementation and processed for possible forwarding. SMF implementations MUST be capable of forwarding IP multicast packets with destination addresses that are not router-local and link-local for IPv6, as defined in [RFC4291], and that are not within the local network control block as defined by [RFC5771]. This will support generic multi-hop multicast application needs or distribute designated multicast traffic ingressing the SMF routing domain via border routers. The multicast addresses to be forwarded should be maintained by an a priori list or a dynamic forwarding information base (FIB) that MAY interact with future MANET dynamic group membership extensions or management functions. The SL-MANET-ROUTERS multicast group is defined to contain all routers within an SMF routing domain, so that packets transmitted to the multicast address associated with the group will be attempted to be delivered to all connected routers running SMF. Due to the mobile nature of a MANET, routers running SMF may not be topologically
Top   ToC   RFC6621 - Page 9
   connected at particular times.  For IPv6, SL-MANET-ROUTERS is
   specified to be "site-local".  Minimally, SMF MUST forward, as
   instructed by the relay set selection algorithm, unique (non-
   duplicate) packets received for SL-MANET-ROUTERS when the Time to
   Live (TTL) / hop limit or hop limit value in the IP header is greater
   than 1.  SMF MUST forward all additional global-scope multicast
   addresses specified within the dynamic FIB or configured list as
   well.  In all cases, the following rules MUST be observed for SMF
   multicast forwarding:

   1.  Any IP packets not addressed to an IP multicast address MUST NOT
       be forwarded by the SMF forwarding engine.

   2.  IP multicast packets with TTL/hop limit <= 1 MUST NOT be
       forwarded.

   3.  Link local IP multicast packets MUST NOT be forwarded.

   4.  Incoming IP multicast packets with an IP source address matching
       one of those of the local SMF router interface(s) MUST NOT be
       forwarded.

   5.  Received frames with the Media Access Control (MAC) source
       address matching any MAC address of the router's interfaces MUST
       NOT be forwarded.

   6.  Received packets for which SMF cannot reasonably ensure temporal
       DPD uniqueness MUST NOT be forwarded.

   7.  Prior to being forwarded, the TTL/hop limit of the forwarded
       packet MUST be decremented by one.

   Note that rule #4 is important because over some types of wireless
   interfaces, the originating SMF router may receive retransmissions of
   its own packets when they are forwarded by adjacent routers.  This
   rule avoids unnecessary retransmission of locally generated packets
   even when other forwarding decision rules would apply.

   An additional processing rule also needs to be considered based upon
   a potential security threat.  As discussed in Section 10, there is a
   potential DoS attack that can be conducted by remotely "previewing"
   (e.g., via a directional receive antenna) packets that an SMF router
   would be forwarding and conducting a "pre-play" attack by
   transmitting the packet before the SMF router would otherwise receive
   it, but with a reduced TTL/hop limit field value.  This form of
   attack can cause an SMF router to create a DPD entry that would block
   the proper forwarding of the valid packet (with correct TTL/hop
   limit) through the SMF routing domain.  A RECOMMENDED approach to
Top   ToC   RFC6621 - Page 10
   prevent this attack, when it is a concern, would be to cache temporal
   packet TTL/hop limit values along with the per-packet DPD state (hash
   value(s) and/or identifier as described in Section 6).  Then, if a
   subsequent matching (with respect to DPD) packet arrives with a
   larger TTL/hop limit value than the packet that was previously
   forwarded, SMF should forward the new packet and update the TTL/hop
   limit value cached with corresponding DPD state to the new, larger
   TTL/hop limit value.  There may be temporal cases where SMF would
   unnecessarily forward some duplicate packets using this approach, but
   those cases are expected to be minimal and acceptable when compared
   with the potential threat of denied service.

   Once the SMF multicast forwarding rules have been applied, an SMF
   implementation MUST make a forwarding decision dependent upon the
   relay set selection algorithm in use.  If the SMF implementation is
   using Classic Flooding (CF), the forwarding decision is implicit once
   DPD uniqueness is determined.  Otherwise, a forwarding decision
   depends upon the current interface-specific relay set state.  The
   descriptions of the relay set selection algorithms in the appendices
   to this document specify the respective heuristics for multicast
   packet forwarding and specific DPD or other processing required to
   achieve correct SMF behavior in each case.  For example, one class of
   forwarding is based upon relay set selection status and the packet's
   previous hop, while other classes designate the local SMF router as a
   forwarder for all neighboring routers.

6. SMF Duplicate Packet Detection

Duplicate packet detection (DPD) is often a requirement in MANET or wireless mesh packet forwarding mechanisms because packets may be transmitted out via the same physical interface as the one over which they were received. Routers may also receive multiple copies of the same packets from different neighbors or interfaces. SMF operation requires DPD, and implementations MUST provide mechanisms to detect and reduce the likelihood of forwarding duplicate multicast packets using temporal packet identification. It is RECOMMENDED this be implemented by keeping a history of recently processed multicast packets for comparison with incoming packets. A DPD packet cache history SHOULD be kept long enough so as to span the maximum network traversal lifetime, MAX_PACKET_LIFETIME, of multicast packets being forwarded within an SMF routing domain. The DPD mechanism SHOULD avoid keeping unnecessary state for packet flows such as those that are locally generated or link-local destinations that would not be considered for forwarding, as presented in Section 5. For both IPv4 and IPv6, this document describes two basic multicast duplicate packet detection mechanisms: header content identification- based (I-DPD) and hash-based (H-DPD) duplicate packet detection.
Top   ToC   RFC6621 - Page 11
   I-DPD is a mechanism using specific packet headers, and option
   headers in the case of IPv6, in combination with flow state to
   estimate the temporal uniqueness of a packet.  H-DPD uses hashing
   over header fields and payload of a multicast packet to provide an
   estimation of temporal uniqueness.

   Trade-offs of the two approaches to DPD merit different
   considerations dependent upon the specific SMF deployment scenario.

   Because of the potential addition of a hop-by-hop option header with
   IPv6, all SMF routers in the same SMF deployments MUST be configured
   so as to use a common mechanism and DPD algorithm.  The main
   difference between IPv4 and IPv6 SMF DPD specifications is the
   avoidance of any additional header options for IPv4.

   For each network interface, SMF implementations MUST maintain DPD
   packet state as needed to support the forwarding heuristics of the
   relay set algorithm used.  In general, this involves keeping track of
   previously forwarded packets so that duplicates are not forwarded,
   but some relay techniques have additional considerations, such as
   those discussed in Appendix B.2.

   Additional details of I-DPD and H-DPD processing and maintenance for
   different classes of packets are described in the following
   subsections.

6.1. IPv6 Duplicate Packet Detection

This section describes the mechanisms and options for SMF IPv6 DPD. The base IPv6 packet header does not provide an explicit packet identification header field that can be exploited for I-DPD. The following options are therefore described to support IPv6 DPD: 1. a hop-by-hop SMF_DPD option header, defined in this document (Section 6.1.1), 2. the use of IPv6 fragment header fields for I-DPD, if one is present (Section 6.1.2), 3. the use of IPsec sequencing for I-DPD when a non-fragmented, IPsec header is detected (Section 6.1.2), and 4. an H-DPD approach assisted, as needed, by the SMF_DPD option header (Section 6.1.3). SMF MUST provide a DPD marking module that can insert the hop-by-hop IPv6 header option, defined in Section 6.1.1. This module MUST be invoked after any source-based fragmentation that may occur with
Top   ToC   RFC6621 - Page 12
   IPv6, so as to ensure that all fragments are suitably marked.  SMF
   IPv6 DPD is presently specified to allow either a packet hash or
   header identification method for DPD.  An SMF implementation MUST be
   configured to operate either in I-DPD or H-DPD mode and perform the
   corresponding tasks, outlined in Sections 6.1.2 and 6.1.3.

6.1.1. IPv6 SMF_DPD Option Header

This section defines an IPv6 Hop-by-Hop Option [RFC2460], SMF_DPD, to serve the purpose of unique packet identification for IPv6 I-DPD. Additionally, the SMF_DPD option header provides a mechanism to guarantee non-collision of hash values for different packets when H-DPD is used. If this is the only hop-by-hop option present, the optional TaggerId field (see below) is not included, and the size of the DPD packet identifier (sequence number) or hash token is 24 bits or less, this will result in the addition of 8 bytes to the IPv6 packet header including the "Next Header", "Header Extension Length", SMF_DPD option fields, and padding. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... |0|0|0| 01000 | Opt. Data Len | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |H| DPD Identifier Option Fields or Hash Assist Value ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2: IPv6 SMF_DPD Hop-by-Hop Option Header "Option Type" = 00001000. The highest order three bits are 000 because this specification requires that routers not recognizing this option type skip over this option and continue processing the header and that the option must not change en route [RFC2460]. "Opt. Data Len" = Length of option content (i.e., 1 + (<IdType> ? (<IdLen> + 1): 0) + Length(DPD ID)). "H-bit" = a hash indicator bit value identifying DPD marking type. 0 == sequence-based approach with optional TaggerId and a tuple-based sequence number. 1 == indicates a hash assist value (HAV) field follows to aid in avoiding hash-based DPD collisions. When the "H-bit" is cleared (zero value), the SMF_DPD format to support I-DPD operation is specified as shown in Figure 3 and defines the extension header in accordance with [RFC2460].
Top   ToC   RFC6621 - Page 13
        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                      ...              |0|0|0|  01000  | Opt. Data Len |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |0|TidTy| TidLen|             TaggerId (optional) ...           |
       +-+-+-+-+-+-+-+-+               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                               |            Identifier  ...
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

            Figure 3: IPv6 SMF_DPD Option Header in I-DPD mode

   "TidTy" = a 3-bit field indicating the presence and type of the
   optional TaggerId field.

   "TidLen" = a 4-bit field indicating the length (in octets) of the
   following TaggerId field.

   "TaggerId" = a field, is used to differentiate multiple ingressing
   border gateways that may commonly apply the SMF_DPD option header to
   packets from a particular source.  Table 1 lists the TaggerId types
   used in this document:

   +---------+---------------------------------------------------------+
   | Name    | Purpose                                                 |
   +---------+---------------------------------------------------------+
   | NULL    | Indicates no TaggerId field is present. "TidLen" MUST   |
   |         | also be set to ZERO.                                    |
   | DEFAULT | A TaggerId of non-specific context is present. "TidLen  |
   |         | + 1" defines the length of the TaggerId field in bytes. |
   | IPv4    | A TaggerId representing an IPv4 address is present. The |
   |         | "TidLen" MUST be set to 3.                              |
   | IPv6    | A TaggerId representing an IPv6 address is present. The |
   |         | "TidLen" MUST be set to 15.                             |
   +---------+---------------------------------------------------------+

                          Table 1: TaggerId Types

   This format allows a quick check of the "TidTy" field to determine if
   a TaggerId field is present.  If "TidTy" is NULL, then the length of
   the DPD packet <Identifier> field corresponds to (<Opt. Data Len> -
   1).  If the <TidTy> is non-NULL, then the length of the TaggerId
   field is equal to (<TidLen> - 1), and the remainder of the option
   data comprises the DPD packet <Identifier> field.  When the TaggerId
   field is present, the <Identifier> field can be considered a unique
   packet identifier in the context of the <TaggerId:srcAddr:dstAddr>
   tuple.  When the TaggerId field is not present, then it is assumed
   that the source applied the SMF_DPD option and the <Identifier> can
Top   ToC   RFC6621 - Page 14
   be considered unique in the context of the IPv6 packet header
   <srcAddr:dstAddr> tuple.  IPv6 I-DPD operation details are in
   Section 6.1.2.

   When the "H-bit" in the SMF_DPD option data is set, the data content
   value is interpreted as a hash assist value (HAV) used to facilitate
   H-DPD operation.  In this case, the source or ingressing gateways
   apply the SMF_DPD with an HAV only when required to differentiate the
   hash value of a new packet with respect to hash values in the DPD
   cache.  This situation can be detected locally on the router by
   running the hash algorithm and checking the DPD cache, prior to
   ingressing a previously unmarked packet or a locally sourced packet.
   This helps to guarantee the uniqueness of generated hash values when
   H-DPD is used.  Additionally, this avoids the added overhead of
   applying the SMF_DPD option header to every packet.  For many hash
   algorithms, it is expected that only sparse use of the SMF_DPD option
   may be required.  The format of the SMF_DPD option header for H-DPD
   operation is given in Figure 4.

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                     ...              |0|0|0| OptType | Opt. Data Len |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |1|    Hash Assist Value (HAV) ...
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

            Figure 4: IPv6 SMF_DPD Option Header in H-DPD Mode

   The SMF_DPD option should be applied with an HAV to produce a unique
   hash digest for packets within the context of the IPv6 packet header
   <srcAddr>.  The size of the HAV field is implied by "Opt. Data Len".
   The appropriate size of the field depends upon the collision
   properties of the specific hash algorithm used.  More details on IPv6
   H-DPD operation are provided in Section 6.1.3.

6.1.2. IPv6 Identification-Based DPD

Table 2 summarizes the IPv6 I-DPD processing and forwarding decision approach. Within the table, '*' indicates an ignore field condition.
Top   ToC   RFC6621 - Page 15
   +-------------+-----------+-----------+-----------------------------+
   | IPv6        | IPv6      | IPv6      | SMF IPv6 I-DPD Mode Action  |
   | Fragment    | IPsec     | I-DPD     |                             |
   | Header      | Header    | Header    |                             |
   +-------------+-----------+-----------+-----------------------------+
   | Present     | *         | Not       | Use Fragment Header I-DPD   |
   |             |           | Present   | Check and Process for       |
   |             |           |           | Forwarding                  |
   | Not Present | Present   | Not       | Use IPsec Header I-DPD      |
   |             |           | Present   | Check and Process for       |
   |             |           |           | Forwarding                  |
   | Present     | *         | Present   | Invalid; do not forward.    |
   | Not Present | Present   | Present   | Invalid; do not forward.    |
   | Not Present | Not       | Not       | Add I-DPD Header, and       |
   |             | Present   | Present   | Process for Forwarding      |
   | Not Present | Not       | Present   | Use I-DPD Header Check and  |
   |             | Present   |           | Process for Forwarding      |
   +-------------+-----------+-----------+-----------------------------+

                   Table 2: IPv6 I-DPD Processing Rules

   1.  If a received IPv6 multicast packet is an IPv6 fragment, SMF MUST
       use the fragment extension header fields for packet
       identification.  This identifier can be considered unique in the
       context of the <srcAddr:dstAddr> of the IP packet.

   2.  If the packet is an unfragmented IPv6 IPsec packet, SMF MUST use
       IPsec fields for packet identification.  The IPsec header
       <sequence> field can be considered a unique identifier in the
       context of the <IPsecType:srcAddr:dstAddr:SPI> where "IPsecType"
       is either Authentication Header (AH) or Encapsulating Security
       Payload (ESP) [RFC4302].

   3.  For unfragmented, non-IPsec IPv6 packets, the use of the SMF_DPD
       option header is necessary to support I-DPD operation.  The
       SMF_DPD option header is applied in the context of the <srcAddr>
       of the IP packet.  Hosts or ingressing SMF gateways are
       responsible for applying this option to support DPD.  Table 3
       summarizes these packet identification types:
Top   ToC   RFC6621 - Page 16
   +-----------+---------------------------------+---------------------+
   | IPv6      | Packet DPD ID Context           | Packet DPD ID       |
   | Packet    |                                 |                     |
   | Type      |                                 |                     |
   +-----------+---------------------------------+---------------------+
   | Fragment  | <srcAddr:dstAddr>               | <fragmentOffset:id> |
   | IPsec     | <IPsecType:srcAddr:dstAddr:SPI> | <sequence>          |
   | Packet    |                                 |                     |
   | Regular   | <[TaggerId:]srcAddr:dstAddr>    | <SMF_DPD option     |
   | Packet    |                                 | header id>          |
   +-----------+---------------------------------+---------------------+

              Table 3: IPv6 I-DPD Packet Identification Types

   "IPsecType" is either Authentication Header (AH) or Encapsulating
   Security Payload (ESP).

   The "TaggerId" is an optional field of the IPv6 SMF_DPD option
   header.

6.1.3. IPv6 Hash-Based DPD

A default hash-based DPD approach (H-DPD) for use by SMF is specified as follows. An SHA-1 [RFC3174] hash of the non-mutable header fields, options fields, and data content of the IPv6 multicast packet is used to produce a 160-bit digest. The approach for calculating this hash value SHOULD follow the same guidelines described for calculating the Integrity Check Value (ICV) described in [RFC4302] with respect to non-mutable fields. This approach should have a reasonably low probability of digest collision when packet headers and content are varying. SHA-1 is being applied in SMF only to provide a low probability of collision and is not being used for cryptographic or authentication purposes. A history of the packet hash values SHOULD be maintained within the context of the IPv6 packet header <srcAddr>. SMF ingress points (i.e., source hosts or gateways) use this history to confirm that new packets are unique with respect to their hash value. The hash assist value (HAV) field described in Section 6.1.1 is provided as a differentiating field when a digest collision would otherwise occur. Note that the HAV is an immutable option field, and SMF MUST process any included HAV values (see Section 6.1.1) in its hash calculation. If a packet results in a digest collision (i.e., by checking the H-DPD digest history) within the DPD cache kept by SMF forwarders, the packet SHOULD be silently dropped. If a digest collision is detected at an SMF ingress point, the H-DPD option header is constructed with a randomly generated HAV. An HAV is recalculated as needed to produce a non-colliding hash value prior to forwarding.
Top   ToC   RFC6621 - Page 17
   The multicast packet is then forwarded with the added IPv6 SMF_DPD
   option header.  A common hash approach MUST be used by SMF routers
   for the applied HAV to consistently avoid hash collision and thus
   inadvertent packet drops.

   The SHA-1 indexing and IPv6 HAV approaches are specified at present
   for consistency and robustness to suit experimental uses.  Future
   approaches and experimentation may discover design trade-offs in hash
   robustness and efficiency worth considering.  Enhancements MAY
   include reducing the maximum payload length that is processed,
   determining shorter indexes, or applying more efficient hashing
   algorithms.  Use of the HAV functionality may allow for application
   of "lighter-weight" hashing techniques that might not have been
   initially considered otherwise due to poor collision properties.
   Such techniques could reduce packet-processing overhead and memory
   requirements.

6.2. IPv4 Duplicate Packet Detection

This section describes the mechanisms and options for IPv4 DPD. The following areas are described to support IPv4 DPD: 1. the use of IPv4 fragment header fields for I-DPD when they exist (Section 6.2.1), 2. the use of IPsec sequencing for I-DPD when a non-fragmented IPv4 IPsec packet is detected (Section 6.2.1), and 3. an H-DPD approach(Section 6.2.2) when neither of the above cases can be applied. Although the IPv4 datagram has a 16-bit Identification (ID) field as specified in [RFC0791], it cannot be relied upon for DPD purposes due to common computer operating system implementation practices and the reasons described in the updated specification of the IPv4 ID Field [IPV4-ID-UPDATE]. An SMF IPv4 DPD marking option like the IPv6 SMF_DPD option header is not specified since IPv4 header options are not as tractable for hosts as they are for IPv6. However, when IPsec is applied or IPv4 packets have been fragmented, the I-DPD approach can be applied reliably using the corresponding packet identifier fields described in Section 6.2.1. For the general IPv4 case (non- IPsec and non-fragmented packets), the H-DPD approach of Section 6.2.2 is RECOMMENDED.
Top   ToC   RFC6621 - Page 18
   Since IPv4 SMF does not specify an option header, the
   interoperability constraints are looser than in the IPv6 version, and
   forwarders may operate with mixed H-DPD and I-DPD modes as long as
   they consistently perform the appropriate DPD routines outlined in
   the following sections.  However, it is RECOMMENDED that a deployment
   be configured with a common mode for operational consistency.

6.2.1. IPv4 Identification-Based DPD

Table 4 summarizes the IPv4 I-DPD processing approach once a packet has passed the basic forwardable criteria described in Section 5. To summarize, for IPv4, I-DPD is applicable only for packets that have been fragmented or have IPsec applied. In Table 4, '*' indicates an ignore field condition. DF, MF, and Fragment offset correspond to related fields and flags defined in [RFC0791]. +------+------+----------+---------+--------------------------------+ | DF | MF | Fragment | IPsec | IPv4 I-DPD Action | | flag | flag | offset | | | +------+------+----------+---------+--------------------------------+ | 1 | 1 | * | * | Invalid; do not forward. | | 1 | 0 | nonzero | * | Invalid; do not forward. | | * | 0 | zero | not | Use H-DPD check instead | | | | | Present | | | * | 0 | zero | Present | IPsec enhanced Tuple I-DPD | | | | | | Check and Process for | | | | | | Forwarding | | 0 | 0 | nonzero | * | Extended Fragment Offset Tuple | | | | | | I-DPD Check and Process for | | | | | | Forwarding | | 0 | 1 | zero or | * | Extended Fragment Offset Tuple | | | | nonzero | | I-DPD Check and Process for | | | | | | Forwarding | +------+------+----------+---------+--------------------------------+ Table 4: IPv4 I-DPD Processing Rules For performance reasons, IPv4 network fragmentation and reassembly of multicast packets within wireless MANET networks should be minimized, yet SMF provides the forwarding of fragments when they occur. If the IPv4 multicast packet is a fragment, SMF MUST use the fragmentation header fields for packet identification. This identification can be considered temporally unique in the context of the <protocol:srcAddr: dstAddr> of the IPv4 packet. If the packet is an unfragmented IPv4 IPsec packet, SMF MUST use IPsec fields for packet identification. The IPsec header <sequence> field can be considered a unique
Top   ToC   RFC6621 - Page 19
   identifier in the context of the <IPsecType:srcAddr:dstAddr:SPI>
   where "IPsecType" is either AH or ESP [RFC4302].  Table 5 summarizes
   these packet identification types:

   +-----------+---------------------------------+---------------------+
   | IPv4      | Packet Identification Context   | Packet Identifier   |
   | Packet    |                                 |                     |
   | Type      |                                 |                     |
   +-----------+---------------------------------+---------------------+
   | Fragment  | <protocol:srcAddr:dstAddr>      | <fragmentOffset:id> |
   | IPsec     | <IPsecType:srcAddr:dstAddr:SPI> | <sequence>          |
   | Packet    |                                 |                     |
   +-----------+---------------------------------+---------------------+

              Table 5: IPv4 I-DPD Packet Identification Types

   "IPsecType" is either Authentication Header (AH) or Encapsulating
   Security Payload (ESP).

6.2.2. IPv4 Hash-Based DPD

The hashing technique here is similar to that specified for IPv6 in Section 6.1.3, but the H-DPD header option with HAV is not considered. To ensure consistent IPv4 H-DPD operation among SMF routers, a default hashing approach is specified. A common DPD hashing algorithm for an SMF routing area is RECOMMENDED because colliding hash values for different packets result in "false positive" duplicate packet detection, and there is small probability that valid packets may be dropped based on the hashing technique used. Since the "hash assist value" approach is not available for IPv4, use of a common hashing approach minimizes the probability of hash collision packet drops over multiple hops of forwarding. SMF MUST perform a SHA-1 [RFC3174] hash of the immutable header fields, option fields, and data content of the IPv4 multicast packet resulting in a 160-bit digest. The approach for calculating the hash value SHOULD follow the same guidelines described for calculating the Integrity Check Value (ICV) described in [RFC4302] with respect to non-mutable fields. A history of the packet hash values SHOULD be maintained in the context of <protocol:srcAddr:dstAddr>. The context for IPv4 is more specific than that of IPv6 since the SMF_DPD HAV cannot be employed to mitigate hash collisions. A RECOMMENDED implementation detail for IPv4 H-DPD is to concatenate the 16-bit IPv4 ID value with the computed hash value as an extended DPD hash value that may provide reduced hash collisions in the cases where the IPv4 ID field is being set by host operating systems or gateways.
Top   ToC   RFC6621 - Page 20
   When this approach is taken, the use of the supplemental "internal
   hash" technique as described in Section 10 is RECOMMENDED as a
   security measure.

   The SHA-1 hash is specified at present for consistency and
   robustness.  Future approaches and experimentation may discover
   design trade-offs in hash robustness and efficiency worth considering
   for future revisions of SMF.  This MAY include reducing the packet
   payload length that is processed, determining shorter indexes, or
   applying a more efficient hashing algorithm.



(page 20 continued on part 2)

Next Section