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.

Table of Contents

• 1. Introduction
• 2. Terminology
• 3. Applicability Statement
• 4. Dual Stack Optimization Rational
• 5. Dual Stack Optimization Functioning & Overview
• 6. Data Structures
• 6.1. Initial Values
• 7. Packets and Messages
• 7.1. Definitions
• 7.2. Requirements
• 7.3. NHDP message generation
• 7.4. NHDP message processing
• 7.5. Dualstack RFC5444 Message Aggregation
• 7.6. TLVs
• 7.6.1. Message TLVs
• 8. IANA Considerations
• 8.1. Expert Review: Evaluation Guidelines
• 8.2. Message TLV Types
• 9. Security Considerations
• 10. Acknowledgements
• 11. References
• 11.1. Normative References
• 11.2. Informative References
• Author's Address

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].

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.

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:

• L_Dual Stack_Originator := UNDEFINED.

7. Packets and Messages

7.1. Definitions

For the purpose of this section, note the following definitions:

• 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.
• 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.
• 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.

[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:

• If the message contains an ADDRESS TLV with type extension ORIGINATOR and length 4:
  • L_Dual Stack_Originator := tlvvalue.
• 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:

• 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.

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:

• 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.