RFC 6621
Simplified Multicast Forwarding
Internet Engineering Task Force (IETF) J. Macker, Ed. Request for Comments: 6621 NRL Category: Experimental May 2012 ISSN: 2070-1721 Simplified Multicast ForwardingAbstract
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.
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
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
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.
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
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
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
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
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
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.
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
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].
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
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.
+-------------+-----------+-----------+-----------------------------+ | 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:
+-----------+---------------------------------+---------------------+ | 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.
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.
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
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.
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)
