tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Gloss.     Arch.     IMS     UICC    |    Misc.    |    search     info

RFC 6621

 Errata 
Experimental
Pages: 55
Top     in Index     Prev     Next
in Group Index     Prev in Group     Next in Group     Group: MANET

Simplified Multicast Forwarding

Part 1 of 3, p. 1 to 20
None       Next RFC Part

 


Top       ToC       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.

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       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       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       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       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       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       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       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       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       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       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       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       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       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       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       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       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       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       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 RFC Part