MANET H. Rogge Internet-Draft Fraunhofer FKIE Intended status: Experimental July 28, 2014 Expires: January 29, 2015 Optimized flooding for NHDP Dual Stack routers draft-rogge-manet-nhdp-dualstack-optimization-00 Abstract This document specifies an optimization for the flooding of RFC5444 control traffic with NHDP. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on January 29, 2015. Copyright Notice Copyright (c) 2014 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. Rogge Expires January 29, 2015 [Page 1] Internet-Draft NHDP Dual Stack Optimization July 2014 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2 3. Applicability Statement . . . . . . . . . . . . . . . . . . . 3 4. Dual Stack Optimization Rational . . . . . . . . . . . . . . 3 5. Dual Stack Optimization Functioning & Overview . . . . . . . 3 6. Data Structures . . . . . . . . . . . . . . . . . . . . . . . 4 6.1. Initial Values . . . . . . . . . . . . . . . . . . . . . 4 7. Packets and Messages . . . . . . . . . . . . . . . . . . . . 4 7.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 4 7.2. Requirements . . . . . . . . . . . . . . . . . . . . . . 4 7.3. NHDP message generation . . . . . . . . . . . . . . . . . 5 7.4. NHDP message processing . . . . . . . . . . . . . . . . . 5 7.5. Dualstack RFC5444 Message Aggregation . . . . . . . . . . 5 7.6. TLVs . . . . . . . . . . . . . . . . . . . . . . . . . . 6 7.6.1. Message TLVs . . . . . . . . . . . . . . . . . . . . 6 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 8.1. Expert Review: Evaluation Guidelines . . . . . . . . . . 6 8.2. Message TLV Types . . . . . . . . . . . . . . . . . . . . 6 9. Security Considerations . . . . . . . . . . . . . . . . . . . 7 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 11.1. Normative References . . . . . . . . . . . . . . . . . . 7 11.2. Informative References . . . . . . . . . . . . . . . . . 8 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 8 1. Introduction While a lot of MANETs have been running as pure IPv4 networks in the past, networks with both IPv4 and IPv6 support are much more important today. It is possible to run instances of OLSRv2 and NHDP on the same router, but this introduces unnecessary overhead to the network. This document describes a way to reduce the overhead of a Dual Stack MANET while keeping backward compatibility to MANET routers without this capability, including routers that run two separated instances of the routing protocol for both IPv4 and IPv6. 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]. Rogge Expires January 29, 2015 [Page 2] Internet-Draft NHDP Dual Stack Optimization July 2014 The terminology introduced in [RFC5444], [RFC7181] and [RFC6130], including the terms "packet", "message" and "TLV" are to be interpreted as described therein. 3. Applicability Statement The Dual Stack optimization described in this document is applicable for all combined IPv4 and IPv6 deployments of RFC5444 based routing protocols that share a single combined implementation for both IP address types. This specification also requires [RFC6130] HELLO messages with an unique originator address, e.g. as described in [RFC7181]. 4. Dual Stack Optimization Rational RFC5444 based routing protocols can aggregate messages in UDP packets to reduce the number of media access and the overhead introduced by IP and MAC header. This specification allows routers to aggregate messages with different address length (e.g. IPv4 and IPv6 based messages) in a single UDP packet, which allows for a further reduction of media access and overhead. 5. Dual Stack Optimization Functioning & Overview This specification uses an additional TLV inside the IPv6 [RFC6130] HELLO messages to signal the corresponding IPv4 originator address. This allows the router to determine which neighbors are Dual Stack capable and which IPv4/IPv6 originator address pair belongs to the same neighbor router. Whenever a [RFC5444] message with Hoplimit field larger than 1 is created or forwarded, the router counts the number of IPv4-only, IPv6-only and Dual Stack neighbors in its Link Set Tuples on each interface. If the interface has at least one IPv4-only neighbor, all IPv4 messages must be forwarded in IPv4 UDP packets. If the interface has at least one IPv6-only neighbor, all IPv6 messages must be forwarded in IPv6 UDP packets. Other messages can be forwarded in any UDP packet, the protocol prefers IPv4 UDP packets because of the lower header overhead. Rogge Expires January 29, 2015 [Page 3] Internet-Draft NHDP Dual Stack Optimization July 2014 6. Data Structures This specification extends the Link Set Tuples of the Interface Information Base, as defined in [RFC6130] section 7.1, by the following additional elements for each link tuple when being used with this metric: L_Dual Stack_Originator is the originator address of the Dual Stack partner node of the link. This field is only used for IPv6 Link Set Tuples. 6.1. Initial Values When generating a new tuple in the Link Set, as defined in [RFC6130] section 12.5 bullet 3, the values of the elements specified in Section 6 are set as follows: o L_Dual Stack_Originator := UNDEFINED. 7. Packets and Messages 7.1. Definitions For the purpose of this section, note the following definitions: o IPv4ONLY(if): number of IPv4 Link Set Tuples for the interface "if" that have no IPv6 Link Set Tuple for the same interface with L_Dual Stack_Originator set to their IPv4 originator address. o IPv6ONLY(if): number of IPv6 Link Set Tuples for the interface "if" that have no IPv4 Link Set Tuple for the same interface with the IPv4 originator address set to the L_Dual Stack_Originator element. o DUALSTACK(if): number of IPv6 Link Set Tuples for the interface "if" that have a IPv4 Link Set Tuples for the same interface with the IPv4 originator address set to the L_Dual Stack_Originator element. 7.2. Requirements This protocol requires the router to be able to receive and process incoming [RFC5444] messages both with address length 4 and 16, regardless of the IP address family of the UDP packet. Rogge Expires January 29, 2015 [Page 4] Internet-Draft NHDP Dual Stack Optimization July 2014 [RFC5444] messages that have no Hoplimit field or a Hoplimit field with value 1, e.g. [RFC6130] HELLO messages are never sent in UDP packets which don't match the address length of the message. 7.3. NHDP message generation For each generated [RFC6130] HELLO message, the following steps have to be followed: 1. Add a message TLV of type ADDRESS with type extension ADDR_ORIGINATOR and length 4 to the HELLO message with the IPv4 originator address of the local node as the value. 7.4. NHDP message processing For each incoming [RFC6130] HELLO message with an address length of 16 (IPv6), additional processing MUST be carried out after the packet messages have been processed as specified in [RFC6130] and [RFC7181]. The router MUST update the Link Set Tuple corresponding to the originator of the packet: o If the message contains an ADDRESS TLV with type extension ORIGINATOR and length 4: * L_Dual Stack_Originator := tlvvalue. o Otherwise: * L_Dual Stack_Originator := UNDEFINED. 7.5. Dualstack RFC5444 Message Aggregation For each [RFC5444] message with address length 4 (IPv4) that is ready to be put into an UDP packet on the interface 'if', the following steps need to be followed: o If the message has no Hop Limit header field or Hop Limit == 1 or DUALSTACK(if) == 0 or IPv4ONLY(if) != 0 or IPv6ONLY(if) == 0 * Put the message into an IPv4 packet. Otherwise * Put the message into an IPv6 packet. Rogge Expires January 29, 2015 [Page 5] Internet-Draft NHDP Dual Stack Optimization July 2014 For each [RFC5444] message with address length 16 (IPv6) that is ready to be put into an UDP packet on the interface 'if', the following steps need to be followed: o If the message has no Hop Limit header field or Hop Limit == 1 or DUALSTACK(if) == 0 or IPv6ONLY(if) != 0 * Put the message into an IPv6 packet. Otherwise * Put the message into an IPv4 packet. 7.6. TLVs This specification defines one Message TLV. Note that, following [RFC5444] and network byte order, bits in an octet are numbered from 0 (most significant) to 7 (least significant). 7.6.1. Message TLVs The ADDRESS TLV is used in [RFC5444] messages to transport addresses with a different address length than the message address block. +---------+---------------------+---------------------------------+ | Type | Type Extension | Value | +---------+---------------------+---------------------------------+ | ADDRESS | ADDR_ORIGINATOR (0) | Originator Address of a router. | +---------+---------------------+---------------------------------+ Table 1: ADDRESS TLV Definition 8. IANA Considerations This specification defines one Message TLV Type, which have been allocated from the "Message TLV Types" registry of [RFC5444]. 8.1. Expert Review: Evaluation Guidelines For the registries where an Expert Review is required, the designated expert SHOULD take the same general recommendations into consideration as are specified by [RFC5444]. 8.2. Message TLV Types Rogge Expires January 29, 2015 [Page 6] Internet-Draft NHDP Dual Stack Optimization July 2014 This specification defines one Message TLV Type, which has been allocated from the "Message TLV Types" namespace defined in [RFC5444]. IANA has made allocations in the 0-127 range for this type. The new Type Extension registries have been created with assignment as specified in Table 2. +---------+------+-------------------+---------------+--------------+ | Name | Type | Type Extension | Description | Allocation | | | | | | Policy | +---------+------+-------------------+---------------+--------------+ | ADDRESS | TBD | ADDR_ORIGINATOR | Originator | | | | | (0) | address of a | | | | | | router. | | | | | | | | | ADDRESS | TBD | 1-255 | unassigned | Expert | | | | | | Review | +---------+------+-------------------+---------------+--------------+ Table 2: Message TLV Type Assignment: ADDRESS TLV Type extensions indicated as Expert Review SHOULD be allocated as described in [RFC5444], based on Expert Review as defined in [RFC5226]. 9. Security Considerations The IPv6 [RFC6130] HELLO messages of a router might contain an IPv4 originator address that does belong to a different router, which could lead to database inconsistencies. A router implementing this specification might want to include consistency checks so that the mapping between IPv4 and IPv6 Link Set Tuples is strictly one-to-one. 10. Acknowledgements This effort/activity is supported by the European Community Framework Program 7 within the Future Internet Research and Experimentation Initiative (FIRE), Community Networks Testbed for the Future Internet ([CONFINE]), contract FP7-288535. 11. References 11.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, BCP 14, March 1997. Rogge Expires January 29, 2015 [Page 7] Internet-Draft NHDP Dual Stack Optimization July 2014 [RFC5226] Nartan, T. and H. Alverstrand, "Guidelines for Writing an IANA Considerations Section in RFCs", RFC 2119, BCP 14, May 2008. [RFC5444] Clausen, T., Dearlove, C., Dean, J., and C. Adjih, "Generalized Mobile Ad Hoc Network (MANET) Packet/Message Format", RFC 5444, February 2009. [RFC6130] Clausen, T., Dearlove, C., and J. Dean, "Mobile Ad Hoc Network (MANET) Neighborhood Discovery Protocol (NHDP)", RFC 6130, April 2011. [RFC7181] Clausen, T., Jacquet, P., and C. Dearlove, "The Optimized Link State Routing Protocol version 2", RFC 7181, March 2013. 11.2. Informative References [CONFINE] Braem, B., Blondia, C., Barz, C., Rogge, H., Freitag, F., Navarro, L., Bonicioli, J., Papathanasiou, S., Escrich, P., Vinas, R., Kaplan, A., Neumann, A., Balaguer, I., Tatum, B., and M. Matson, "A case for research with and on community networks", July 2013, . Author's Address Henning Rogge Fraunhofer FKIE Fraunhofer Strasse 20 53343 Wachtberg Germany Phone: +49 228 9434 961 Email: henning.rogge@fkie.fraunhofer.de URI: http://www.fkie.fraunhofer.de Rogge Expires January 29, 2015 [Page 8]