draft-ietf-manet-dymo-13.txt   draft-ietf-manet-dymo-14.txt 
Mobile Ad hoc Networks Working I. Chakeres Mobile Ad hoc Networks Working I. Chakeres
Group Motorola Group Motorola
Internet-Draft C. Perkins Internet-Draft C. Perkins
Intended status: Standards Track Intended status: Standards Track WiChorus
Expires: October 12, 2008 April 10, 2008 Expires: December 27, 2008 June 25, 2008
Dynamic MANET On-demand (DYMO) Routing Dynamic MANET On-demand (DYMO) Routing
draft-ietf-manet-dymo-13 draft-ietf-manet-dymo-14
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 35 skipping to change at page 1, line 35
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on October 12, 2008. This Internet-Draft will expire on December 27, 2008.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2008). Copyright (C) The IETF Trust (2008).
Abstract Abstract
The Dynamic MANET On-demand (DYMO) routing protocol is intended for The Dynamic MANET On-demand (DYMO) routing protocol is intended for
use by mobile nodes in wireless, multihop networks. DYMO determines use by mobile routers in wireless, multihop networks. DYMO
unicast routes among DYMO routers within the network in an on-demand determines unicast routes among DYMO routers within the network in an
fashion, offering improved convergence in dynamic topologies. on-demand fashion, offering improved convergence in dynamic
topologies.
Table of Contents Table of Contents
1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Applicability Statement . . . . . . . . . . . . . . . . . . . 4 2. Applicability Statement . . . . . . . . . . . . . . . . . . . 4
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. Data Structures . . . . . . . . . . . . . . . . . . . . . . . 7 4. Data Structures . . . . . . . . . . . . . . . . . . . . . . . 7
4.1. Route Table Entry . . . . . . . . . . . . . . . . . . . . 7 4.1. Route Table Entry . . . . . . . . . . . . . . . . . . . . 7
4.2. DYMO Messages . . . . . . . . . . . . . . . . . . . . . . 8 4.2. DYMO Messages . . . . . . . . . . . . . . . . . . . . . . 8
4.2.1. Generalized Packet and Message Structure . . . . . . . 8 4.2.1. Generalized Packet and Message Structure . . . . . . . 9
4.2.2. Routing Messages (RM) - RREQ & RREP . . . . . . . . . 9 4.2.2. Routing Messages (RM) - RREQ & RREP . . . . . . . . . 10
4.2.3. Route Error (RERR) . . . . . . . . . . . . . . . . . . 12 4.2.3. Route Error (RERR) . . . . . . . . . . . . . . . . . . 12
5. Detailed Operation . . . . . . . . . . . . . . . . . . . . . . 14 5. Detailed Operation . . . . . . . . . . . . . . . . . . . . . . 14
5.1. DYMO Sequence Numbers . . . . . . . . . . . . . . . . . . 14 5.1. DYMO Sequence Numbers . . . . . . . . . . . . . . . . . . 14
5.1.1. Maintaining A Node's Own Sequence Number . . . . . . . 15 5.1.1. Maintaining A Node's Own Sequence Number . . . . . . . 15
5.1.2. Numerical Operations on OwnSeqNum . . . . . . . . . . 15 5.1.2. Numerical Operations on OwnSeqNum . . . . . . . . . . 15
5.1.3. OwnSeqNum Rollover . . . . . . . . . . . . . . . . . . 15 5.1.3. OwnSeqNum Rollover . . . . . . . . . . . . . . . . . . 15
5.1.4. Actions After OwnSeqNum Loss . . . . . . . . . . . . . 15 5.1.4. Actions After OwnSeqNum Loss . . . . . . . . . . . . . 15
5.2. DYMO Routing Table Operations . . . . . . . . . . . . . . 15 5.2. DYMO Routing Table Operations . . . . . . . . . . . . . . 15
5.2.1. Judging Routing Information's Usefulness . . . . . . . 16 5.2.1. Judging Routing Information's Usefulness . . . . . . . 15
5.2.2. Creating or Updating a Route Table Entry with 5.2.2. Creating or Updating a Route Table Entry with
Received Superior Routing Information . . . . . . . . 17 Received Superior Routing Information . . . . . . . . 17
5.2.3. Route Table Entry Timeouts . . . . . . . . . . . . . . 18 5.2.3. Route Table Entry Timeouts . . . . . . . . . . . . . . 18
5.3. Routing Messages . . . . . . . . . . . . . . . . . . . . . 19 5.3. Routing Messages . . . . . . . . . . . . . . . . . . . . . 18
5.3.1. RREQ Creation . . . . . . . . . . . . . . . . . . . . 19 5.3.1. RREQ Creation . . . . . . . . . . . . . . . . . . . . 18
5.3.2. RREP Creation . . . . . . . . . . . . . . . . . . . . 20 5.3.2. RREP Creation . . . . . . . . . . . . . . . . . . . . 19
5.3.3. Intermediate DYMO Router RREP Creation . . . . . . . . 20 5.3.3. Intermediate DYMO Router RREP Creation . . . . . . . . 20
5.3.4. RM Processing . . . . . . . . . . . . . . . . . . . . 21 5.3.4. RM Processing . . . . . . . . . . . . . . . . . . . . 21
5.3.5. Adding Additional Routing Information to a RM . . . . 24 5.3.5. Adding Additional Routing Information to a RM . . . . 24
5.4. Route Discovery . . . . . . . . . . . . . . . . . . . . . 24 5.4. Route Discovery . . . . . . . . . . . . . . . . . . . . . 24
5.5. Route Maintenance . . . . . . . . . . . . . . . . . . . . 25 5.5. Route Maintenance . . . . . . . . . . . . . . . . . . . . 25
5.5.1. Active Link Monitoring . . . . . . . . . . . . . . . . 26 5.5.1. Active Link Monitoring . . . . . . . . . . . . . . . . 26
5.5.2. Updating Route Lifetimes During Packet Forwarding . . 26 5.5.2. Updating Route Lifetimes During Packet Forwarding . . 26
5.5.3. RERR Generation . . . . . . . . . . . . . . . . . . . 26 5.5.3. RERR Generation . . . . . . . . . . . . . . . . . . . 26
5.5.4. RERR Processing . . . . . . . . . . . . . . . . . . . 27 5.5.4. RERR Processing . . . . . . . . . . . . . . . . . . . 27
5.6. Unknown Message & TLV Types . . . . . . . . . . . . . . . 28 5.6. Unknown Message & TLV Types . . . . . . . . . . . . . . . 28
5.7. Advertising Network Addresses . . . . . . . . . . . . . . 28 5.7. Advertising Network Addresses . . . . . . . . . . . . . . 28
5.8. Simple Internet Attachment . . . . . . . . . . . . . . . . 28 5.8. Simple Internet Attachment . . . . . . . . . . . . . . . . 29
5.9. Multiple Interfaces . . . . . . . . . . . . . . . . . . . 30 5.9. Multiple Interfaces . . . . . . . . . . . . . . . . . . . 30
5.10. DYMO Control Packet/Message Generation Limits . . . . . . 30 5.10. DYMO Control Packet/Message Generation Limits . . . . . . 30
6. Configuration Parameters and Other Administrative Options . . 30 6. Configuration Parameters and Other Administrative Options . . 31
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32
7.1. DYMO Message Type Specification . . . . . . . . . . . . . 32 7.1. DYMO Message Type Specification . . . . . . . . . . . . . 32
7.2. Packet and Message TLV Type Specification . . . . . . . . 32 7.2. Packet and Message TLV Type Specification . . . . . . . . 32
7.3. Address Block TLV Specification . . . . . . . . . . . . . 33 7.3. Address Block TLV Specification . . . . . . . . . . . . . 33
8. Security Considerations . . . . . . . . . . . . . . . . . . . 33 8. Security Considerations . . . . . . . . . . . . . . . . . . . 34
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 34 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 34
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 34 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 35
10.1. Normative References . . . . . . . . . . . . . . . . . . . 34 10.1. Normative References . . . . . . . . . . . . . . . . . . . 35
10.2. Informative References . . . . . . . . . . . . . . . . . . 34 10.2. Informative References . . . . . . . . . . . . . . . . . . 35
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 35 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 36
Intellectual Property and Copyright Statements . . . . . . . . . . 36 Intellectual Property and Copyright Statements . . . . . . . . . . 37
1. Overview 1. Overview
The Dynamic MANET On-demand (DYMO) routing protocol enables reactive, The Dynamic MANET On-demand (DYMO) routing protocol enables reactive,
multihop unicast routing among participating DYMO routers. The basic multihop unicast routing among participating DYMO routers. The basic
operations of the DYMO protocol are route discovery and route operations of the DYMO protocol are route discovery and route
maintenance. maintenance.
During route discovery, the originator's DYMO router initiates During route discovery, the originator's DYMO router initiates
dissemination of a Route Request (RREQ) throughout the network to dissemination of a Route Request (RREQ) throughout the network to
skipping to change at page 4, line 28 skipping to change at page 4, line 28
originator. Each intermediate DYMO router that receives the RREP originator. Each intermediate DYMO router that receives the RREP
creates a route to the target, and then the RREP is unicast hop-by- creates a route to the target, and then the RREP is unicast hop-by-
hop toward the originator. When the originator's DYMO router hop toward the originator. When the originator's DYMO router
receives the RREP, routes have then been established between the receives the RREP, routes have then been established between the
originating DYMO router and the target DYMO router in both originating DYMO router and the target DYMO router in both
directions. directions.
Route maintenance consists of two operations. In order to preserve Route maintenance consists of two operations. In order to preserve
routes in use, DYMO routers extend route lifetimes upon successfully routes in use, DYMO routers extend route lifetimes upon successfully
forwarding a packet. In order to react to changes in the network forwarding a packet. In order to react to changes in the network
topology, DYMO routers monitor links over which traffic is flowing. topology, DYMO routers monitor routers over which traffic is flowing.
When a data packet is received for forwarding and a route for the When a data packet is received for forwarding and a route for the
destination is not known or the route is broken, then the DYMO router destination is not known or the route is broken, then the DYMO router
of source of the packet is notified. A Route Error (RERR) is sent of source of the packet is notified. A Route Error (RERR) is sent
toward the packet source to indicate the current route to a toward the packet source to indicate the route to that particular
particular destination is invalid or missing. When the source's DYMO destination is invalid or missing. When the source's DYMO router
router receives the RERR, it deletes the route. If the source's DYMO receives the RERR, it deletes the route. If the source's DYMO router
router later receives a packet for forwarding to the same later receives a packet for forwarding to the same destination, it
destination, it will need to perform route discovery again for that will need to perform route discovery again for that destination.
destination.
DYMO uses sequence numbers to ensure loop freedom [Perkins99]. DYMO uses sequence numbers to ensure loop freedom [Perkins99].
Sequence numbers enable DYMO routers to determine the temporal order Sequence numbers enable DYMO routers to determine the temporal order
of DYMO route discovery messages, thereby avoiding use of stale of DYMO route discovery messages, thereby avoiding use of stale
routing information. routing information.
2. Applicability Statement 2. Applicability Statement
The DYMO routing protocol is designed for stub or disconnected mobile The DYMO routing protocol is designed for stub or disconnected mobile
ad hoc networks (MANETs). DYMO handles a wide variety of mobility ad hoc networks (MANETs). DYMO handles a wide variety of mobility
patterns by dynamically determining routes on-demand. DYMO also patterns by dynamically determining routes on-demand. DYMO also
handles a wide variety of traffic patterns. In networks with a large handles a wide variety of traffic patterns. In networks with a large
number of routers, DYMO is best suited for sparse traffic scenarios number of routers, DYMO is best suited for sparse traffic scenarios
where routers forward packets to with only a small portion of the where routers forward packets to with only a small portion of the
other DYMO routers, due to the reactive nature of route discovery and other DYMO routers, due to the reactive nature of route discovery and
route maintenance. route maintenance.
DYMO is applicable to memory constrained devices, since minimal DYMO is applicable to memory constrained devices, since very little
routing state is maintained in each DYMO router. Only routing routing state is maintained in each DYMO router. Only routing
information related to active sources and destinations is maintained, information related to active sources and destinations is maintained,
in contrast to other more proactive routing protocols that require in contrast to most other more proactive routing protocols that
routing information to all routers within the routing region be require routing information to all routers within the routing region
maintained. be maintained.
DYMO supports routers with multiple interfaces participating in the DYMO supports routers with multiple interfaces participating in the
MANET. DYMO routers can also perform routing on behalf of other MANET. DYMO routers can also perform routing on behalf of other
nodes, attached via participating or non-participating interfaces. nodes, attached via participating or non-participating interfaces.
DYMO routers perform route discovery to find a route to a particular DYMO routers perform route discovery to find a route to a particular
destination. Therefore, DYMO routers MUST be configured to initiate destination. Therefore, DYMO routers MUST be configured to initiate
route discovery on behalf of certain sources and find routes to route discovery on behalf of certain sources and find routes to
certain destinations. When DYMO is the only protocol interacting certain destinations. When DYMO is the only protocol interacting
with the forwarding table, DYMO MAY be configured to perform route with the forwarding table, DYMO MAY be configured to perform route
discovery for all unknown unicast destinations. discovery for all unknown unicast destinations.
DYMO MUST only utilizes bidirectional links. In the case of possible DYMO MUST only utilizes bidirectional links. In the case of possible
unidirectional links, either blacklists (see Section 7.2) or other unidirectional links, either blacklists (see Section 7.2) or other
means (e.g. only accepting RM from bidirectional links as indicated means (e.g. adjacency establishment with only neighboring routers
by NHDP [I-D.ietf-manet-nhdp]) of ensuring bi-directionality should that have bidirectional communication as indicated by NHDP
be used. Otherwise, persistent packet loss may occur. [I-D.ietf-manet-nhdp]) of ensuring bi-directionality should be used.
Otherwise, persistent packet loss may occur.
The routing algorithm in DYMO may be operated at layers other than The routing algorithm in DYMO may be operated at layers other than
the network layer, using layer-appropriate addresses. For operation the network layer, using layer-appropriate addresses. For operation
at other layers only modification of the packet/message format should at other layers DYMO's routing algorithm likely will not need to
be required; DYMO's routing algorithm need not change. change. Although, modification of the packet/message format may be
required.
3. Terminology 3. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
Additionally, this document uses some terminology from Additionally, this document uses some terminology from
[I-D.ietf-manet-packetbb]. [I-D.ietf-manet-packetbb].
This document defines the following terminology: This document defines the following terminology:
Adjacency
A relationship formed between selected bi-directional neighboring
routers for the purpose of exchanging routing information. Not
every pair of neighboring routers become adjacent. Neighboring
routers may form an adjacency based several different pieces of
information or protocols; for example, exchange of DYMO routing
messages, other protocols (e.g. NDP [RFC4861] or NHDP
[I-D.ietf-manet-nhdp]), or manual configuration.
Distance (Dist) Distance (Dist)
A metric of the distance a message or piece of information has A metric of the distance a message or piece of information has
traversed. The minimum value of distance is the number of IP hops traversed. The minimum value of distance is the number of IP hops
traversed. The maximum value is 65,535. traversed. The maximum value is 65,535.
DYMO Sequence Number (SeqNum) DYMO Sequence Number (SeqNum)
A DYMO Sequence Number is maintained by each DYMO router. This A DYMO Sequence Number is maintained by each DYMO router. This
sequence number is used by other DYMO routers to identify the sequence number is used by other DYMO routers to identify the
temporal order of routing information generated and ensure loop- temporal order of routing information generated and ensure loop-
free routes. free routes.
Forwarding Route Forwarding Route
A route that is used to forward data packets. Forwarding routes A route that is used to forward data packets. Forwarding routes
are generally maintained in a forwarding information base (FIB) or are generally maintained in a forwarding information base (FIB) or
the kernel forwarding/routing table. the kernel forwarding/routing table.
Multihop-capable Unicast IP Address
A multihop-capable unicast IP address is a unicast IP address that
when put into the IP.SoureAddress or IP.DestinationAddress field
is scoped sufficiently to be forwarded by a router. For example,
site-scoped or globally-scoped unicast IP addresses.
Originating Node (OrigNode) Originating Node (OrigNode)
The originating node is the source, its DYMO router creates a DYMO The originating node is the source, its DYMO router creates a DYMO
control message on its behalf in an effort to disseminate some control message on its behalf in an effort to disseminate some
routing information. The originating node is also referred to as routing information. The originating node is also referred to as
a particular message's originator. a particular message's originator.
Route Error (RERR) Route Error (RERR)
A RERR message is used indicate that a DYMO router does not have A RERR message is used indicate that a DYMO router does not have
forwarding route to one or more particular addresses. forwarding route to one or more particular addresses.
skipping to change at page 7, line 32 skipping to change at page 7, line 49
Route.Prefix Route.Prefix
Indicates that the associated address is a network address, rather Indicates that the associated address is a network address, rather
than a host address. The value is the length of the netmask/ than a host address. The value is the length of the netmask/
prefix. prefix.
Route.SeqNum Route.SeqNum
The DYMO SeqNum associated with this routing information. The DYMO SeqNum associated with this routing information.
Route.NextHopAddress Route.NextHopAddress
The IP address of the next DYMO router on the path toward the The IP address of the adjacent DYMO router on the path toward the
Route.Address. Route.Address.
Route.NextHopInterface Route.NextHopInterface
The interface used to send packets toward the Route.Address. The interface used to send packets toward the Route.Address.
Route.Forwarding
A flag indicating whether this Route can be used for forwarding
data packets.
Route.Broken Route.Broken
A flag indicating whether this Route is broken. This flag is set A flag indicating whether this Route is broken. This flag is set
if the next-hop becomes unreachable or in response to processing a if the next-hop becomes unreachable or in response to processing a
RERR (see Section 5.5.4). RERR (see Section 5.5.4).
The following field is optional: The following field is optional:
Route.Dist Route.Dist
A metric indicating the distance traversed before reaching the A metric indicating the distance traversed before reaching the
Route.Address node. Route.Address node.
skipping to change at page 8, line 46 skipping to change at page 9, line 21
blocks. Each of the address blocks may also have an associated blocks. Each of the address blocks may also have an associated
address TLV block. address TLV block.
All DYMO messages specified in this document are sent using UDP to All DYMO messages specified in this document are sent using UDP to
the destination port MANET [I-D.ietf-manet-iana]. the destination port MANET [I-D.ietf-manet-iana].
Most DYMO messages are sent with the IP destination address set to Most DYMO messages are sent with the IP destination address set to
the link-local multicast address LL-MANET-ROUTERS the link-local multicast address LL-MANET-ROUTERS
[I-D.ietf-manet-iana] unless otherwise stated. Therefore, all DYMO [I-D.ietf-manet-iana] unless otherwise stated. Therefore, all DYMO
routers SHOULD subscribe to LL-MANET-ROUTERS [I-D.ietf-manet-iana] routers SHOULD subscribe to LL-MANET-ROUTERS [I-D.ietf-manet-iana]
for receiving control packets. for receiving control packets. Note that multicast packets may be
sent via unicast. For example, this may occur for certain link-types
(non broadcast mediums), improved robustness, or manually configured
router adjacency.
Unicast DYMO messages (e.g. RREP) specified in this document are Unicast DYMO messages (e.g. RREP) unless otherwise specified in this
sent with the IP destination set to the Route.NextHopAddress of the document are sent with the IP destination set to the
route to the TargetNode. Route.NextHopAddress of the route to the TargetNode.
The IPv4 TTL (IPv6 Hop Limit) field for all packets containing DYMO The IPv4 TTL (IPv6 Hop Limit) field for all packets containing DYMO
messages is set to 255. If a packet is received with a value other messages is set to 255. If a packet is received with a value other
than 255, it is discarded. This mechanism helps to ensures packets than 255, it is discarded. This mechanism helps to ensures packets
have not passed through any intermediate routers, and it is known as have not passed through any intermediate routers, and it is known as
GTSM [RFC5082]. GTSM [RFC5082].
The length of an IP address (32 bits for IPv4 and 128 bits for IPv6) The length of an IP address (32 bits for IPv4 and 128 bits for IPv6)
inside a DYMO message depends on the IP packet header containing the inside a DYMO message depends on the IP packet header containing the
DYMO message/packet. For example, if the IP header uses IPv6 DYMO message/packet. For example, if the IP header uses IPv6
addresses then all addresses contained in the payload use IPv6 addresses then all addresses contained in the payload use IPv6
addresses of the same length. In the case of mixed IPv6 and IPv4 addresses of the same length. In the case of mixed IPv6 and IPv4
addresses, please use the methods specified in addresses, please use the methods specified in
[I-D.ietf-manet-packetbb]. [I-D.ietf-manet-packetbb].
If a packet contains only a single DYMO message and no packet TLVs, If a packet contains only a single DYMO message and no packet TLVs,
it need not include a packet-header [I-D.ietf-manet-packetbb]. it need not include a packet-header [I-D.ietf-manet-packetbb].
The aggregation of multiple messages into a packet is not specified The aggregation of multiple messages into a packet is not specified
in this document, but the IP.SourceAddress and IP.DestinationAddress in this document, but if aggregation does occur the IP.SourceAddress
of all contained messages MUST be the same. and IP.DestinationAddress of all contained messages MUST be the same.
Implementations MAY choose to temporarily delay transmission of Implementations MAY choose to temporarily delay transmission of
messages for the purpose of aggregation (into a single packet) or to messages for the purpose of aggregation (into a single packet) or to
improve performance by using jitter [I-D.ietf-manet-jitter]. improve performance by using jitter [I-D.ietf-manet-jitter].
DYMO control packets SHOULD be given priority queue and channel DYMO control packets SHOULD be given priority queue and channel
access. access.
4.2.2. Routing Messages (RM) - RREQ & RREP 4.2.2. Routing Messages (RM) - RREQ & RREP
skipping to change at page 10, line 6 skipping to change at page 10, line 28
RM creation and processing are described in Section 5.3. RM creation and processing are described in Section 5.3.
A RM requires the following information: A RM requires the following information:
IP.SourceAddress IP.SourceAddress
The IP address of the node currently sending this packet. This The IP address of the node currently sending this packet. This
field is generally filled automatically by the operating system field is generally filled automatically by the operating system
and should not require special handling. and should not require special handling.
IP.DestinationAddress IP.DestinationAddress
The IP address of the packet destination. For RREQ the The IP address of the packet destination. For multicast RREQ the
IP.DestinationAddress is set to LL-MANET ROUTERS IP.DestinationAddress is set to LL-MANET ROUTERS
[I-D.ietf-manet-iana]. For RREP the IP.DestinationAddress is set [I-D.ietf-manet-iana]. For unicast RREQ and RREP the
to the NextHopAddress toward the RREP TargetNode. IP.DestinationAddress is set to the NextHopAddress toward the RREP
TargetNode.
UDP.DestinationPort UDP.DestinationPort
By default, the UDP destination port is set to MANET By default, the UDP destination port is set to MANET
[I-D.ietf-manet-iana]. [I-D.ietf-manet-iana].
MsgHdr.HopLimit MsgHdr.HopLimit
The remaining number of hops this message is allowed to traverse. The remaining number of hops this message is allowed to traverse.
AddBlk.TargetNode.Address AddBlk.TargetNode.Address
The IP address of the message TargetNode. In a RREQ the The IP address of the message TargetNode. In a RREQ the
skipping to change at page 13, line 13 skipping to change at page 13, line 13
RERR creation and processing are described in Section 5.5. RERR creation and processing are described in Section 5.5.
A RERR requires the following information: A RERR requires the following information:
IP.SourceAddress IP.SourceAddress
The IP address of the node currently sending this packet. This The IP address of the node currently sending this packet. This
field is generally filled automatically by the operating system field is generally filled automatically by the operating system
and should not require special handling. and should not require special handling.
IP.DestinationAddress IP.DestinationAddress
The IP address is set to LL-MANET-ROUTERS [I-D.ietf-manet-iana]. For multicast RERR messages, The IP address is set to LL-MANET-
ROUTERS [I-D.ietf-manet-iana]. For unicast RERR messages, The IP
address is set to the NextHopAddress.
UDP.DestinationPort UDP.DestinationPort
By default, the UDP destination port is set to MANET By default, the UDP destination port is set to MANET
[I-D.ietf-manet-iana]. [I-D.ietf-manet-iana].
MsgHdr.HopLimit MsgHdr.HopLimit
The remaining number of hops this message is allowed to traverse. The remaining number of hops this message is allowed to traverse.
AddBlk.UnreachableNode.Address AddBlk.UnreachableNode.Address
The IP address of an UnreachableNode and its associated prefix The IP address of an UnreachableNode and its associated prefix
skipping to change at page 15, line 22 skipping to change at page 15, line 22
5.1.2. Numerical Operations on OwnSeqNum 5.1.2. Numerical Operations on OwnSeqNum
When ThisNode increments its OwnSeqNum (as described in Section 5.3) When ThisNode increments its OwnSeqNum (as described in Section 5.3)
it MUST do so by treating the sequence number value as an unsigned it MUST do so by treating the sequence number value as an unsigned
number. number.
5.1.3. OwnSeqNum Rollover 5.1.3. OwnSeqNum Rollover
If the sequence number has been assigned to be the largest possible If the sequence number has been assigned to be the largest possible
number representable as a 16-bit unsigned integer (i.e., 65,535), number representable as a 16-bit unsigned integer (i.e., 65,535),
then the sequence number is set to 256 when incremented. Setting the then the sequence number SHOULD be set to one (1) incremented.
sequence number to 256 allows other nodes to detect that the number
has rolled over and the node has not lost its sequence number.
5.1.4. Actions After OwnSeqNum Loss 5.1.4. Actions After OwnSeqNum Loss
A DYMO router SHOULD maintain its sequence number in persistent A DYMO router SHOULD maintain its sequence number in persistent
storage. storage.
If a DYMO router's OwnSeqNum is lost, it MUST take certain actions to If a DYMO router's OwnSeqNum is lost, it MUST take certain actions to
avoid creating routing loops. To prevent this possibility after avoid creating routing loops. To prevent this possibility after
OwnSeqNum loss a DYMO router MUST wait for at least OwnSeqNum loss a DYMO router MUST wait for at least
ROUTE_DELETE_TIMEOUT before fully participating in the DYMO routing ROUTE_DELETE_TIMEOUT before fully participating in the DYMO routing
protocol. If a DYMO control message is received during this waiting protocol. If a DYMO control message is received during this waiting
period, the DYMO router SHOULD process it normally but MUST NOT period, the DYMO router SHOULD process it normally but MUST NOT
transmit or retransmit any DYMO messages. If a data packet is transmit or retransmit any DYMO messages. If a data packet is
received for forwarding to another destination during this waiting received for forwarding to another destination during this waiting
period, the DYMO router MUST generate a RERR message indicating that period, the DYMO router MUST generate a RERR message indicating that
this route is not available and reset its waiting timeout. At the this route is not available and reset its waiting timeout. At the
end of the waiting period the DYMO router sets its OwnSeqNum to one end of the waiting period the DYMO router sets its OwnSeqNum to one
(1) and begins participating. (1) and begins participating.
The longest a node need wait is ROUTE_AGE_MAX_TIMEOUT. At the end of The longest a node need wait is ROUTE_AGE_MAX_TIMEOUT. At the end of
the maximum waiting period a node sets its OwnSeqNum to one (1) and the maximum waiting period a node SHOULD set its OwnSeqNum to one (1)
begins participating. and begins participating.
5.2. DYMO Routing Table Operations 5.2. DYMO Routing Table Operations
5.2.1. Judging Routing Information's Usefulness 5.2.1. Judging Routing Information's Usefulness
Given a route table entry (Route.SeqNum, Route.Dist, and Given a route table entry (Route.SeqNum, Route.Dist, and
Route.Broken) and new incoming routing information for a particular Route.Broken) and new incoming routing information for a particular
node in a RM (Node.SeqNum, Node.Dist, and RM message type - RREQ/ node in a RM (Node.SeqNum, Node.Dist, and RM message type - RREQ/
RREP), the quality of the new routing information is evaluated to RREP), the quality of the new routing information is evaluated to
determine its usefulness. Incoming routing information is classified determine its usefulness. Incoming routing information is classified
skipping to change at page 19, line 48 skipping to change at page 19, line 39
If OrigNode.Dist is included it is set to a number greater than zero If OrigNode.Dist is included it is set to a number greater than zero
(0). (0).
The MsgHdr.HopLimit SHOULD be set to MSG_HOPLIMIT. The MsgHdr.HopLimit SHOULD be set to MSG_HOPLIMIT.
For RREQ, the MsgHdr.HopLimit MAY be set in accordance with an For RREQ, the MsgHdr.HopLimit MAY be set in accordance with an
expanding ring search as described in [RFC3561] to limit the RREQ expanding ring search as described in [RFC3561] to limit the RREQ
propagation to a subset of the local network and possibly reduce propagation to a subset of the local network and possibly reduce
route discovery overhead. route discovery overhead.
The IP.DestinationAddress for RREQ is set to LL-MANET-ROUTERS. The IP.DestinationAddress for multicast RREQ is set to LL-MANET-
ROUTERS. The IP.DestinationAddress for unicast RREQ is set to the
NextHopAddress.
5.3.2. RREP Creation 5.3.2. RREP Creation
First, the AddBlk.TargetNode.Address is added to the RREP. The First, the AddBlk.TargetNode.Address is added to the RREP. The
TargetNode is the ultimate destination of this RREP; the RREQ TargetNode is the ultimate destination of this RREP; the RREQ
OrigNode.Address. OrigNode.Address.
Next, AddBlk.OrigNode.Address and prefix are added to the RREP. The Next, AddBlk.OrigNode.Address and prefix are added to the RREP. The
AddBlk.OrigNode.Address is the RREQ TargetNode.Address. The AddBlk.OrigNode.Address is the RREQ TargetNode.Address. The
AddBlk.OrigNode.Address MUST be a unicast IP address. ThisNode AddBlk.OrigNode.Address MUST be a unicast IP address. ThisNode
skipping to change at page 21, line 31 skipping to change at page 21, line 22
The Intermediate DYMO router SHOULD also issue a RREP to the RREQ The Intermediate DYMO router SHOULD also issue a RREP to the RREQ
TargetNode, so that the RREQ TargetNode receives routing information TargetNode, so that the RREQ TargetNode receives routing information
on how to reach the RREQ OrigNode. on how to reach the RREQ OrigNode.
When an intermediate DYMO router creates this RREP, it sends a RREP When an intermediate DYMO router creates this RREP, it sends a RREP
to the RREQ TargetNode with additional routing information (Address, to the RREQ TargetNode with additional routing information (Address,
Prefix, SeqNum, Dist, etc.) about the RREQ OrigNode. Prefix, SeqNum, Dist, etc.) about the RREQ OrigNode.
5.3.4. RM Processing 5.3.4. RM Processing
ThisNode first checks whether AddBlk.OrigNode.Address is an address First, ThisNode decides whether to process this message. ThisNode
handled by this DYMO router. If this node is the originating DYMO MAY selectively process messages based upon information in the
router, the RM is dropped. message. ThisNode SHOULD only process messages from adjacent DYMO
routers. If ThisNode chooses not to process this message, the
message is discarded and further processing stopped.
Before processing a RREQ, the DYMO router checks the IP.Destination ThisNode checks if the AddBlk.OrigNode.Address is a valid multihop-
to ensure that it was sent to LL-MANET-ROUTERS [I-D.ietf-manet-iana]. capable (e.g. site or global scope) unicast IP address. If the
If the RREQ was not sent to LL-MANET-ROUTERS, it SHOULD be discarded address is not a valid unicast IP address, the messages is discarded
and further processing stopped. and further processing stopped.
Next, ThisNode checks if the AddBlk.OrigNode.Address is a valid ThisNode also checks whether AddBlk.OrigNode.Address is an address
unicast IP address. If the address is not a valid unicast IP handled by this DYMO router. If this node is the originating DYMO
router, the RM is dropped.
ThisNode checks if the AddBlk.TargetNode.Address is a valid multihop-
capable unicast IP address. If the address is not a valid unicast IP
address, the messages is discarded and further processing stopped. address, the messages is discarded and further processing stopped.
Next, ThisNode checks whether its routing table has an entry to the Next, ThisNode checks whether its routing table has an entry to the
AddBlk.OrigNode.Address using longest-prefix matching [RFC1812]. If AddBlk.OrigNode.Address using longest-prefix matching [RFC1812]. If
a route does not exist, then the new routing information is a route does not exist, then the new routing information is
considered fresh and a new route table entry is created and updated considered fresh and a new route table entry is created and updated
as described in Section 5.2.2. If a route table entry does exists, as described in Section 5.2.2. If a route table entry does exists,
the incoming routing information is compared with the route table the incoming routing information is compared with the route table
entry following the procedure described in Section 5.2.1. If the entry following the procedure described in Section 5.2.1. If the
incoming routing information is considered superior, the route table incoming routing information is considered superior, the route table
entry is updated as described in Section 5.2.2. entry is updated as described in Section 5.2.2.
After processing the OrigNode's routing information, then each After processing the OrigNode's routing information, then each
address that is not the TargetNode should be considered for creating address that is not the TargetNode should be considered for creating
and updating routes. Creating and updating routes to other nodes can and updating routes. Creating and updating routes to other nodes can
eliminate RREQ for those IP destinations, in the event that data eliminate RREQ for those IP destinations, in the event that data
needs to be forwarded to the IP destination(s) now or in the near needs to be forwarded to the IP destination(s) now or in the near
future. future.
For each of the additional addresses considered, ThisNode first For each of the additional addresses considered, ThisNode first
checks the that the address is a unicast IP address. If the address checks the that the address is a multihop-capable unicast IP address.
is not a unicast IP address, the address and all related information If the address is not a unicast IP address, the address and all
MUST be removed. If the routing table does not have a matching route related information MUST be removed.
for this additional address using longest-prefix matching, then a
route is created and updated as described in Section 5.2.2. If a If the routing table does not have a matching route for this
route table entry exists, the incoming routing information is additional address using longest-prefix matching, then a route is
compared with the route table entry following the procedure described created and updated as described in Section 5.2.2. If a route table
in Section 5.2.1. If the incoming routing information is considered entry exists, the incoming routing information is compared with the
superior, the route table entry is updated as described in route table entry following the procedure described in Section 5.2.1.
Section 5.2.2. If the incoming routing information is considered superior, the route
table entry is updated as described in Section 5.2.2.
If the routing information for an AdditionalNode.Address is not If the routing information for an AdditionalNode.Address is not
considered superior, then it is removed from the RM. Removing this considered superior, then it is removed from the RM. Removing this
information ensures that the information is not propagated. information ensures that the information is not propagated.
At this point, if the routing information for the OrigNode was not At this point, if the routing information for the OrigNode was not
superior then this RM SHOULD be discarded and no further processing superior then this RM SHOULD be discarded and no further processing
of this message SHOULD be performed. of this message SHOULD be performed.
If the ThisNode is the DYMO router responsible for the TargetNode and If the ThisNode is the DYMO router responsible for the TargetNode and
this RM is a RREQ, then ThisNode responds with a RREP to the RREQ this RM is a RREQ, then ThisNode responds with a RREP to the RREQ
OrigNode (the new RREP's TargetNode). The procedure for issuing a OrigNode (the new RREP's TargetNode). The procedure for issuing a
new RREP is described in Section 5.3.2. At this point, ThisNode need new RREP is described in Section 5.3.2. At this point, ThisNode need
not perform any more operations for this RM. not perform any more operations for this RM.
Alternatively ThisNode MAY choose to distribute routing information Alternatively, ThisNode MAY choose to distribute routing information
about ThisNode (the RREQ TargetNode) more widely, ThisNode MAY about ThisNode (the RREQ TargetNode) more widely, ThisNode MAY
optionally perform a route discovery; by issuing a RREQ with ThisNode optionally perform a route discovery; by issuing a RREQ with ThisNode
listed as the TargetNode, using the procedure in Section 5.3.1. At listed as the TargetNode, using the procedure in Section 5.3.1. At
this point, ThisNode need not perform any more operations for the this point, ThisNode need not perform any more operations for the
original RM. original RM.
If ThisNode is not the TargetNode, this RM is a RREQ, the RREQ If ThisNode is not the TargetNode, this RM is a RREQ, the RREQ
contains the TargetNode.AddTLV.SeqNum, and ThisNode has a forwarding contains the TargetNode.AddTLV.SeqNum, and ThisNode has a forwarding
route to the TargetNode with a SeqNum where Route.TargetNode.SeqNum - route to the TargetNode with a SeqNum where Route.TargetNode.SeqNum -
RREQ.TargetNode.AddTLV.SeqNum >= 0 (using signed 16-bit arithmetic); RREQ.TargetNode.AddTLV.SeqNum >= 0 (using signed 16-bit arithmetic);
skipping to change at page 23, line 29 skipping to change at page 23, line 27
If the resulting distance value for the OrigNode is greater than If the resulting distance value for the OrigNode is greater than
65,535, the message is discarded. If the resulting distance value 65,535, the message is discarded. If the resulting distance value
for another node is greater than 65,535, the associated address and for another node is greater than 65,535, the associated address and
its information are removed from the RM. its information are removed from the RM.
Next, the MsgHdr.HopLimit is decremented by one (1). If this RM's Next, the MsgHdr.HopLimit is decremented by one (1). If this RM's
MsgHdr.HopLimit is greater than or equal to one (1), ThisNode is not MsgHdr.HopLimit is greater than or equal to one (1), ThisNode is not
the TargetNode, AND this RM is a RREQ, then the current RM (altered the TargetNode, AND this RM is a RREQ, then the current RM (altered
by the procedure defined above) SHOULD be sent to the by the procedure defined above) SHOULD be sent to the
IP.DestinationAddress LL-MANET-ROUTERS [I-D.ietf-manet-iana]. IP.DestinationAddress LL-MANET-ROUTERS [I-D.ietf-manet-iana]. If the
RREQ is unicast, the IP.DestinationAddress is set to the
NextHopAddress.
If this RM's MsgHdr.HopLimit is greater than or equal to one (1), If this RM's MsgHdr.HopLimit is greater than or equal to one (1),
ThisNode is not the TargetNode, AND this RM is a RREP, then the ThisNode is not the TargetNode, AND this RM is a RREP, then the
current RM is sent to the Route.NextHopAddress for the RREP's current RM is sent to the Route.NextHopAddress for the RREP's
TargetNode.Address. If no forwarding route exists to Target.Address, TargetNode.Address. If no forwarding route exists to Target.Address,
then a RERR is issued to the OrigNode of the RREP. then a RERR is issued to the OrigNode of the RREP.
By sending the updated RM ThisNode is advertising that it will By sending the updated RM ThisNode is advertising that it will
provide routing for IP addresses contained in the outgoing RM based provide routing for IP addresses contained in the outgoing RM based
on the information enclosed. ThisNode MAY choose not to send the RM, on the information enclosed. ThisNode MAY choose not to send the RM,
skipping to change at page 27, line 19 skipping to change at page 27, line 19
The SeqNum if known SHOULD also be included. Appending The SeqNum if known SHOULD also be included. Appending
UnreachableNode information notifies each processing node of UnreachableNode information notifies each processing node of
additional routes that are no longer available. This option SHOULD additional routes that are no longer available. This option SHOULD
be administratively configurable or intelligently controlled. be administratively configurable or intelligently controlled.
If SeqNum information is not known or not included in the RERR, all If SeqNum information is not known or not included in the RERR, all
nodes processing the RERR will assume their routing information nodes processing the RERR will assume their routing information
associated with the UnreachableNode is no longer valid and flag those associated with the UnreachableNode is no longer valid and flag those
routes as broken. routes as broken.
The RERR is sent to the IP.DestinationAddress LL-MANET-ROUTERS A multicast RERR is sent to the IP.DestinationAddress LL-MANET-
[I-D.ietf-manet-iana]. Sending the RERR to the LL-MANET-ROUTERS ROUTERS [I-D.ietf-manet-iana]. Sending the RERR to the LL-MANET-
address notifies nearby nodes that might depend on the now broken ROUTERS address notifies all nearby DYMO routers that might depend on
link. the now broken link. If the RERR is unicast, the
IP.DestinationAddress is set to the NextHopAddress.
At this point, the packet or message that forced generation of this At this point, the packet or message that forced generation of this
RERR SHOULD be discarded. RERR SHOULD be discarded.
5.5.4. RERR Processing 5.5.4. RERR Processing
Before processing a RERR, the DYMO router checks the First, ThisNode decides whether to process this message. ThisNode
IP.DestinationAddress to ensure that it is addressed to LL-MANET- MAY selectively process messages based upon information in the
ROUTERS [I-D.ietf-manet-iana]. message. ThisNode MAY choose to only process messages from adjacent
DYMO routers. If ThisNode chooses not to process this message, the
message is discarded and further processing stopped.
When a DYMO router processes a RERR, it processes each When a DYMO router processes a RERR, it processes each
UnreachableNode's information. The processing DYMO router removes UnreachableNode's information. The processing DYMO router removes
the forwarding route, sets the broken flag, and a timer for the forwarding route, sets the broken flag, and a timer for
ROUTE_DELETE is set to ROUTE_DELETE_TIMEOUT for each ROUTE_DELETE is set to ROUTE_DELETE_TIMEOUT for each
UnreachableNode.Address found using longest prefix matching that meet UnreachableNode.Address found using longest prefix matching that meet
all of the following conditions: all of the following conditions:
1. The UnreachableNode.Address is a unicast address. 1. The UnreachableNode.Address is a multihop-capable unicast IP
address.
2. The Route.NextHopAddress is the same as the RERR 2. The Route.NextHopAddress is the same as the RERR
IP.SourceAddress. IP.SourceAddress.
3. The Route.NextHopInterface is the same as the interface on which 3. The Route.NextHopInterface is the same as the interface on which
the RERR was received. the RERR was received.
4. The Route.SeqNum is zero (0), unknown, OR the 4. The Route.SeqNum is zero (0), unknown, OR the
UnreachableNode.SeqNum is zero (0), unknown, OR Route.SeqNum - UnreachableNode.SeqNum is zero (0), unknown, OR Route.SeqNum -
UnreachableNode.SeqNum <= 0 (using signed 16-bit arithmetic). UnreachableNode.SeqNum <= 0 (using signed 16-bit arithmetic).
skipping to change at page 28, line 24 skipping to change at page 28, line 30
is not included in the RERR, then Route.SeqNum (i.e. is not included in the RERR, then Route.SeqNum (i.e.
Unreachable.SeqNum) MAY be added to the RERR. Including Unreachable.SeqNum) MAY be added to the RERR. Including
Unreachable.SeqNum can reduce future RRER processing and forwarding. Unreachable.SeqNum can reduce future RRER processing and forwarding.
If no UnreachableNode addresses remain in the RERR, no other If no UnreachableNode addresses remain in the RERR, no other
processing is required and the RERR is discarded. processing is required and the RERR is discarded.
If processing continues, the MsgHdr.HopLimit is decremented by one If processing continues, the MsgHdr.HopLimit is decremented by one
(1). Further, if this RERR's new MsgHdr.HopLimit is greater than one (1). Further, if this RERR's new MsgHdr.HopLimit is greater than one
(1) and at least one unreachable node address remains in the RERR, (1) and at least one unreachable node address remains in the RERR,
then the updated RERR is sent to the IP.DestinationAddress LL-MANET- then the updated multicast RERR is sent to the IP.DestinationAddress
ROUTERS [I-D.ietf-manet-iana]. LL-MANET-ROUTERS [I-D.ietf-manet-iana]. If the RERR is unicast, the
IP.DestinationAddress is set to the NextHopAddress.
5.6. Unknown Message & TLV Types 5.6. Unknown Message & TLV Types
If a message with an unknown type is received, the message is If a message with an unknown type is received, the message is
discarded. discarded.
For processing of messages that contain unknown TLV types, operation For processing of messages that contain unknown TLV types, operation
should be administratively controlled. should be administratively controlled.
5.7. Advertising Network Addresses 5.7. Advertising Network Addresses
skipping to change at page 30, line 17 skipping to change at page 30, line 26
a proxy on behalf of Internet destinations. a proxy on behalf of Internet destinations.
5.9. Multiple Interfaces 5.9. Multiple Interfaces
DYMO may be used with multiple interfaces; therefore, the particular DYMO may be used with multiple interfaces; therefore, the particular
interface over which packets arrive MUST be known whenever a packet interface over which packets arrive MUST be known whenever a packet
is received. Whenever a new route is created, the interface through is received. Whenever a new route is created, the interface through
which the Route.Address can be reached is also recorded in the route which the Route.Address can be reached is also recorded in the route
table entry. table entry.
When multiple interfaces are available, a node transmitting a packet When multiple interfaces are available, a node transmitting a
with IP.DestinationAddress set to LL-MANET-ROUTERS SHOULD send the multicast packet with IP.DestinationAddress set to LL-MANET-ROUTERS
packet on all interfaces that have been configured for DYMO SHOULD send the packet on all interfaces that have been configured
operation. for DYMO operation.
Similarly, DYMO routers should subscribe to LL-MANET-ROUTERS on all Similarly, DYMO routers should subscribe to LL-MANET-ROUTERS on all
their DYMO interfaces. their DYMO interfaces.
5.10. DYMO Control Packet/Message Generation Limits 5.10. DYMO Control Packet/Message Generation Limits
To ensure predictable control overhead, DYMO router's rate of packet/ To ensure predictable control overhead, DYMO router's rate of packet/
message generation SHOULD be limited. The rate and algorithm for message generation SHOULD be limited. The rate and algorithm for
limiting messages is left to the implementor and should be limiting messages is left to the implementor and should be
administratively configurable or intelligently controlled. DYMO administratively configurable or intelligently controlled. DYMO
skipping to change at page 32, line 4 skipping to change at page 32, line 4
| Name | Description | | Name | Description |
+------------------------+------------------------------------------+ +------------------------+------------------------------------------+
| RESPONSIBLE_ADDRESSES | List of addresses, and their associated | | RESPONSIBLE_ADDRESSES | List of addresses, and their associated |
| | prefix, for which this DYMO router is | | | prefix, for which this DYMO router is |
| | responsible. | | | responsible. |
| DYMO_INTERFACES | List of the interfaces participating in | | DYMO_INTERFACES | List of the interfaces participating in |
| | DYMO routing protocol. | | | DYMO routing protocol. |
+------------------------+------------------------------------------+ +------------------------+------------------------------------------+
Table 3 Table 3
Note: several fields have limited size (bits or bytes) these sizes
and their encoding may place specific limitations on the values that
can be set. For example, MsgHdr.HopLimit is a 8-bit field and
therefore MSG_HOPLIMIT cannot be larger than 255.
7. IANA Considerations 7. IANA Considerations
In its default mode of operation, DYMO uses the UDP port MANET In its default mode of operation, DYMO uses the UDP port MANET
[I-D.ietf-manet-iana] to carry protocol packets. DYMO also uses the [I-D.ietf-manet-iana] to carry protocol packets. DYMO also uses the
link-local multicast address LL-MANET-ROUTERS [I-D.ietf-manet-iana]. link-local multicast address LL-MANET-ROUTERS [I-D.ietf-manet-iana].
This section specifies several messages types, message tlv-types, and This section specifies several messages types, message tlv-types, and
address tlv-types. address tlv-types.
skipping to change at page 33, line 34 skipping to change at page 34, line 7
| | ] | | being deleted. The | | | ] | | being deleted. The |
| | | | VALIDITY_TIME TLV is | | | | | VALIDITY_TIME TLV is |
| | | | defined in | | | | | defined in |
| | | | [I-D.ietf-manet-timetlv]. | | | | | [I-D.ietf-manet-timetlv]. |
+---------------+--------------+--------+---------------------------+ +---------------+--------------+--------+---------------------------+
Table 6 Table 6
8. Security Considerations 8. Security Considerations
Currently, DYMO does not specify any special security measures. This document does not mandate any specific security measures.
Instead, this section describes various security considerations and
potential avenues to secure DYMO routing messages.
In situations where confidentiality of DYMO messages is important, In situations where confidentiality of DYMO messages is important,
traditional cryptographic techniques can be applied. cryptographic techniques SHOULD be applied.
Securing routing information integrity will likely require DYMO Securing routing information integrity will likely require DYMO
routers to authenticate DYMO messages upon reception. Also, since routers to authenticate DYMO messages upon reception. IPsec could be
routing information is distributed hop-by-hop, DYMO routers will also used for this single-hop packet protection.
likely need to authenticate the source of the routing information,
the source's DYMO router.
Note that is important that any confidentiality and integrity Also, since routing information is distributed over multiple hops,
algorithms used permit multiple receivers to process the message, DYMO routers will also likely need to authenticate the source of the
since much of DYMO's messaging is multicast. routing information. A digital signature could be used help identify
the source of a message and its authenticity, along with a nonce or
timestamp to protect against replay attacks. S/MIME and OpenPGP are
two possible authentication protocols.
In certain situations, like sending a RREP, a DYMO router may also
need to provide proof that it had received valid routing information
to reach the destination, at one point of time in the past. In these
situations, the original routing information along with its security
credentials may need to be included.
Note that if multicast is used, any confidentiality and integrity
algorithms used must permit multiple receivers to process the
message.
9. Acknowledgments 9. Acknowledgments
DYMO is a descendant of the design of previous MANET reactive DYMO is a descendant of the design of previous MANET reactive
protocols, especially AODV [RFC3561] and DSR [RFC4728]. Changes to protocols, especially AODV [RFC3561] and DSR [RFC4728]. Changes to
previous MANET reactive protocols stem from research and previous MANET reactive protocols stem from research and
implementation experiences. Thanks to Elizabeth Belding-Royer for implementation experiences. Thanks to Elizabeth Belding-Royer for
her long time authorship of DYMO. Additional thanks to Luke Klein- her long time authorship of DYMO. Additional thanks to Luke Klein-
Berndt, Pedro Ruiz, Fransisco Ros, Koojana Kuladinithi, Ramon Berndt, Pedro Ruiz, Fransisco Ros, Koojana Kuladinithi, Ramon
Caceres, Thomas Clausen, Christopher Dearlove, Seung Yi, Romain Caceres, Thomas Clausen, Christopher Dearlove, Seung Yi, Romain
Thouvenin, Tronje Krop, Henner Jakob, Alexandru Petrescu, Christoph Thouvenin, Tronje Krop, Henner Jakob, Alexandru Petrescu, Christoph
Sommer, Cong Yuan, and Lars Kristensen for reviewing of DYMO, as well Sommer, Cong Yuan, Lars Kristensen, and Derek Atkins for reviewing of
as several specification suggestions. DYMO, as well as several specification suggestions.
10. References 10. References
10.1. Normative References 10.1. Normative References
[I-D.ietf-manet-iana] [I-D.ietf-manet-iana]
Chakeres, I., "IANA Allocations for MANET Protocols", Chakeres, I., "IANA Allocations for MANET Protocols",
draft-ietf-manet-iana-07 (work in progress), draft-ietf-manet-iana-07 (work in progress),
November 2007. November 2007.
skipping to change at page 35, line 28 skipping to change at page 36, line 13
February 1999. February 1999.
[RFC3561] Perkins, C., Belding-Royer, E., and S. Das, "Ad hoc On- [RFC3561] Perkins, C., Belding-Royer, E., and S. Das, "Ad hoc On-
Demand Distance Vector (AODV) Routing", RFC 3561, Demand Distance Vector (AODV) Routing", RFC 3561,
July 2003. July 2003.
[RFC4728] Johnson, D., Hu, Y., and D. Maltz, "The Dynamic Source [RFC4728] Johnson, D., Hu, Y., and D. Maltz, "The Dynamic Source
Routing Protocol (DSR) for Mobile Ad Hoc Networks for Routing Protocol (DSR) for Mobile Ad Hoc Networks for
IPv4", RFC 4728, February 2007. IPv4", RFC 4728, February 2007.
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
"Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
September 2007.
Authors' Addresses Authors' Addresses
Ian D Chakeres Ian D Chakeres
Motorola Motorola
Bangalore Bangalore
India India
Email: ian.chakeres@gmail.com Email: ian.chakeres@gmail.com
URI: http://www.ianchak.com/ URI: http://www.ianchak.com/
Charles E. Perkins Charles E. Perkins
Palo Alto, CA WiChorus Inc.
3590 North First Street, Suite 300
San Jose, CA 95134
USA USA
Phone: +1-408-421-1172
Email: charliep@computer.org Email: charliep@computer.org
Full Copyright Statement Full Copyright Statement
Copyright (C) The IETF Trust (2008). Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors contained in BCP 78, and except as set forth therein, the authors
retain all their rights. retain all their rights.
 End of changes. 50 change blocks. 
100 lines changed or deleted 165 lines changed or added

This html diff was produced by rfcdiff 1.35. The latest version is available from http://tools.ietf.org/tools/rfcdiff/