draft-ietf-manet-olsrv2-17.txt   draft-ietf-manet-olsrv2-18.txt 
Mobile Ad hoc Networking (MANET) T. Clausen Mobile Ad hoc Networking (MANET) T. Clausen
Internet-Draft LIX, Ecole Polytechnique Internet-Draft LIX, Ecole Polytechnique
Intended status: Standards Track C. Dearlove Intended status: Standards Track C. Dearlove
Expires: April 17, 2013 BAE Systems ATC Expires: September 19, 2013 BAE Systems ATC
P. Jacquet P. Jacquet
Alcatel-Lucent Bell Labs Alcatel-Lucent Bell Labs
U. Herberg U. Herberg
Fujitsu Laboratories of America Fujitsu Laboratories of America
October 14, 2012 March 18, 2013
The Optimized Link State Routing Protocol version 2 The Optimized Link State Routing Protocol version 2
draft-ietf-manet-olsrv2-17 draft-ietf-manet-olsrv2-18
Abstract Abstract
This specification describes version 2 of the Optimized Link State This specification describes version 2 of the Optimized Link State
Routing (OLSRv2) protocol for Mobile Ad hoc NETworks (MANETs). Routing (OLSRv2) protocol for Mobile Ad hoc NETworks (MANETs).
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
skipping to change at page 1, line 36 skipping to change at page 1, line 36
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
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."
This Internet-Draft will expire on April 17, 2013. This Internet-Draft will expire on September 19, 2013.
Copyright Notice Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 4, line 40 skipping to change at page 4, line 40
20.5. Jitter Time Parameters . . . . . . . . . . . . . . . . . 81 20.5. Jitter Time Parameters . . . . . . . . . . . . . . . . . 81
20.6. Hop Limit Parameter . . . . . . . . . . . . . . . . . . . 81 20.6. Hop Limit Parameter . . . . . . . . . . . . . . . . . . . 81
20.7. Willingness Parameter . . . . . . . . . . . . . . . . . . 82 20.7. Willingness Parameter . . . . . . . . . . . . . . . . . . 82
21. Sequence Numbers . . . . . . . . . . . . . . . . . . . . . . 82 21. Sequence Numbers . . . . . . . . . . . . . . . . . . . . . . 82
22. Extensions . . . . . . . . . . . . . . . . . . . . . . . . . 82 22. Extensions . . . . . . . . . . . . . . . . . . . . . . . . . 82
23. Security Considerations . . . . . . . . . . . . . . . . . . . 83 23. Security Considerations . . . . . . . . . . . . . . . . . . . 83
23.1. Security Architecture . . . . . . . . . . . . . . . . . . 83 23.1. Security Architecture . . . . . . . . . . . . . . . . . . 83
23.2. Integrity . . . . . . . . . . . . . . . . . . . . . . . . 84 23.2. Integrity . . . . . . . . . . . . . . . . . . . . . . . . 84
23.3. Confidentiality . . . . . . . . . . . . . . . . . . . . . 86 23.3. Confidentiality . . . . . . . . . . . . . . . . . . . . . 86
23.4. Interaction with External Routing Domains . . . . . . . . 86 23.4. Interaction with External Routing Domains . . . . . . . . 86
24. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 87 23.5. Mandatory Security Mechanisms . . . . . . . . . . . . . . 87
24.1. Expert Review: Evaluation Guidelines . . . . . . . . . . 87 23.6. Key Management . . . . . . . . . . . . . . . . . . . . . 87
24.2. Message Types . . . . . . . . . . . . . . . . . . . . . . 87 24. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 90
24.3. Message-Type-Specific TLV Type Registries . . . . . . . . 87 24.1. Expert Review: Evaluation Guidelines . . . . . . . . . . 90
24.4. Message TLV Types . . . . . . . . . . . . . . . . . . . . 88 24.2. Message Types . . . . . . . . . . . . . . . . . . . . . . 90
24.5. Address Block TLV Types . . . . . . . . . . . . . . . . . 89 24.3. Message-Type-Specific TLV Type Registries . . . . . . . . 90
24.6. NBR_ADDR_TYPE and MPR Values . . . . . . . . . . . . . . 92 24.4. Message TLV Types . . . . . . . . . . . . . . . . . . . . 91
25. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 92 24.5. Address Block TLV Types . . . . . . . . . . . . . . . . . 92
26. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 93 24.6. NBR_ADDR_TYPE and MPR Values . . . . . . . . . . . . . . 95
27. References . . . . . . . . . . . . . . . . . . . . . . . . . 93 25. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 95
27.1. Normative References . . . . . . . . . . . . . . . . . . 93 26. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 96
27.2. Informative References . . . . . . . . . . . . . . . . . 94 27. References . . . . . . . . . . . . . . . . . . . . . . . . . 96
27.1. Normative References . . . . . . . . . . . . . . . . . . 96
Appendix A. Constraints . . . . . . . . . . . . . . . . . . . . 95 27.2. Informative References . . . . . . . . . . . . . . . . . 97
Appendix B. Example Algorithm for Calculating MPRs . . . . . . . 99 Appendix A. Constraints . . . . . . . . . . . . . . . . . . . . 98
B.1. Additional Notation . . . . . . . . . . . . . . . . . . . 99 Appendix B. Example Algorithm for Calculating MPRs . . . . . . . 102
B.2. MPR Selection Algorithm . . . . . . . . . . . . . . . . . 100 B.1. Additional Notation . . . . . . . . . . . . . . . . . . . 103
Appendix C. Example Algorithm for Calculating the Routing Set . 100 B.2. MPR Selection Algorithm . . . . . . . . . . . . . . . . . 103
C.1. Local Interfaces and Neighbors . . . . . . . . . . . . . 100 Appendix C. Example Algorithm for Calculating the Routing Set . 104
C.2. Add Neighbor Routers . . . . . . . . . . . . . . . . . . 102 C.1. Local Interfaces and Neighbors . . . . . . . . . . . . . 104
C.3. Add Remote Routers . . . . . . . . . . . . . . . . . . . 102 C.2. Add Neighbor Routers . . . . . . . . . . . . . . . . . . 105
C.4. Add Neighbor Addresses . . . . . . . . . . . . . . . . . 103 C.3. Add Remote Routers . . . . . . . . . . . . . . . . . . . 105
C.5. Add Remote Routable Addresses . . . . . . . . . . . . . . 104 C.4. Add Neighbor Addresses . . . . . . . . . . . . . . . . . 107
C.6. Add Attached Networks . . . . . . . . . . . . . . . . . . 104 C.5. Add Remote Routable Addresses . . . . . . . . . . . . . . 107
C.7. Add 2-Hop Neighbors . . . . . . . . . . . . . . . . . . . 105 C.6. Add Attached Networks . . . . . . . . . . . . . . . . . . 108
Appendix D. TC Message Example . . . . . . . . . . . . . . . . . 106 C.7. Add 2-Hop Neighbors . . . . . . . . . . . . . . . . . . . 109
Appendix E. Flow and Congestion Control . . . . . . . . . . . . 108 Appendix D. TC Message Example . . . . . . . . . . . . . . . . . 109
Appendix E. Flow and Congestion Control . . . . . . . . . . . . 112
1. Introduction 1. Introduction
The Optimized Link State Routing protocol version 2 (OLSRv2) is the The Optimized Link State Routing protocol version 2 (OLSRv2) is the
successor to OLSR (version 1) as published in [RFC3626]. Compared to successor to OLSR (version 1) as published in [RFC3626]. Compared to
[RFC3626], OLSRv2 retains the same basic mechanisms and algorithms, [RFC3626], OLSRv2 retains the same basic mechanisms and algorithms,
enhanced by the ability to use a link metric other than hop count in enhanced by the ability to use a link metric other than hop count in
the selection of shortest routes. OLSRv2 also uses a more flexible the selection of shortest routes. OLSRv2 also uses a more flexible
and efficient signaling framework, and includes some simplification and efficient signaling framework, and includes some simplification
of the messages being exchanged. of the messages being exchanged.
skipping to change at page 85, line 24 skipping to change at page 85, line 24
messages and TC messages) are transmitted to all routers in the 1-hop messages and TC messages) are transmitted to all routers in the 1-hop
neighborhood and some control messages (TC messages) are flooded to neighborhood and some control messages (TC messages) are flooded to
all routers in the network. This is done in a packet that is all routers in the network. This is done in a packet that is
transmitted to all routers in the 1-hop neighborhood, the current set transmitted to all routers in the 1-hop neighborhood, the current set
of which may not be known. Thus, a control message, or packet, used of which may not be known. Thus, a control message, or packet, used
by this protocol is always contained in a transmission destined for by this protocol is always contained in a transmission destined for
multiple destinations, and it is important that the authentication multiple destinations, and it is important that the authentication
mechanism employed permits any receiving router to validate the mechanism employed permits any receiving router to validate the
authenticity of a message or packet. authenticity of a message or packet.
[RFC6622] specifies a common exchange format for cryptographic [RFC6622bis] specifies a common exchange format for cryptographic
information in the form of Packet TLVs, Message TLVs, and Address information in the form of Packet TLVs, Message TLVs, and Address
Block TLVs, as specified in [RFC5444]. These may be used (and Block TLVs, as specified in [RFC5444]. These may be used (and
shared) among MANET routing protocol security extensions. In shared) among MANET routing protocol security extensions. In
particular, [RFC6622] specifies the format of TLVs for containing particular, [RFC6622bis] specifies the format of TLVs for containing
Integrity Check Values (ICVs), i.e., signatures, for providing Integrity Check Values (ICVs), i.e., signatures, for providing
integrity, as well as TLVs for containing temporal information for integrity, as well as TLVs for containing temporal information for
preventing replay attacks. [RFC6622] specifies registries for using preventing replay attacks. [RFC6622bis] specifies registries for
different ciphers and formats of temporal information. Failure to using different ciphers and formats of temporal information. Failure
verify an ICV included can be used as a reason to reject an incoming to verify an ICV included can be used as a reason to reject an
message or packet as "invalid", according to Section 12.1 of incoming message or packet as "invalid", according to Section 12.1 of
[RFC6130], and according to Section 16.3.1 of this specification, [RFC6130], and according to Section 16.3.1 of this specification,
when using the multiplexing and demultiplexing process described in when using the multiplexing and demultiplexing process described in
Appendix A of [RFC5444]. Appendix A of [RFC5444].
Any security extension that uses [RFC6622] must specify how to insert Any security extension that uses [RFC6622bis] must specify how to
IVCs in generated messages, how to verify incoming messages, and to insert IVCs in generated messages, how to verify incoming messages,
reject "insecure" messages (i.e., messages without an ICV or with an and to reject "insecure" messages (i.e., messages without an ICV or
ICV that cannot be verified) when operating in a secure mode. with an ICV that cannot be verified) when operating in a secure mode.
Different MANET deployments may, as a result of their purpose for Different MANET deployments may, as a result of their purpose for
which they are used and the possibility and nature of their which they are used and the possibility and nature of their
configuration, require different ICV algorithms and timestamps, and configuration, require different ICV algorithms and timestamps, and
thus a security extension may use any of the different options thus a security extension may use any of the different options
provided in [RFC6622]. provided in [RFC6622bis].
23.3. Confidentiality 23.3. Confidentiality
OLSRv2 periodically MPR floods topological information to all routers OLSRv2 periodically MPR floods topological information to all routers
in the network. Hence, if used in an unprotected network, in in the network. Hence, if used in an unprotected network, in
particular an unprotected wireless network, the network topology is particular an unprotected wireless network, the network topology is
revealed to anyone who successfully listens to the control messages. revealed to anyone who successfully listens to the control messages.
This information may serve an attacker to acquire details about the This information may serve an attacker to acquire details about the
topology, and therefore to initiate more effective attacks against topology, and therefore to initiate more effective attacks against
routers in the routing domain e.g., by spoofing addresses of routers routers in the routing domain e.g., by spoofing addresses of routers
skipping to change at page 87, line 6 skipping to change at page 87, line 6
with invalid information. with invalid information.
A recommended way of extending connectivity from an external routing A recommended way of extending connectivity from an external routing
domain to this routing domain, which is routed using this protocol, domain to this routing domain, which is routed using this protocol,
is to assign an IP prefix (under the authority of the routers/ is to assign an IP prefix (under the authority of the routers/
gateways connecting this routing domain with the external routing gateways connecting this routing domain with the external routing
domain) exclusively to this routing domain, and to configure the domain) exclusively to this routing domain, and to configure the
gateways to advertise routes for that IP prefix into the external gateways to advertise routes for that IP prefix into the external
routing domain. routing domain.
23.5. Mandatory Security Mechanisms
A conformant implementation of OLSRv2 MUST, at a minimum, implement
the security mechanisms specified in [OLSRv2-integrity], providing
integrity and replay protection of OLSRv2 control messages, including
of HELLO messages specified by [RFC6130] that are used by OLSRv2, by
including an Integrity Check Value (ICV) TLV and a timestamp TLV.
The ICV TLV uses a SHA-256 based HMAC and a single shared secret key.
The timestamp TLV is based on POSIX time, assuming router time
synchronization.
The baseline use case, for which this security mechanism provides
adequate integrity protection without rekeying, is for short-lived
(for example up to a couple of months) OLSRv2 deployments.
Any deployment of OLSRv2 SHOULD use an appropriate security
mechanism, possibly different from the one described in
[OLSRv2-integrity]. For example, for longer-term OLSRv2 deployments,
alternative security mechanisms (e.g., including re-keying) SHOULD be
considered.
23.6. Key Management
This specification does not mandate automatic key management (AKM) as
part of the security architecture for OLSRv2. While certain use
cases for OLSRv2 may lend themselves to AKM, the baseline assumption
is that many use cases do not, for the reasons detailed below.
Bootstrapping a key is hard in a radio network, where it is - in
general - not possible to determine from where a received signal was
transmitted, or if two transmissions come from the same or from
different sources.
A widespread use of radio networks, mobile phone networks, works
under the assumptions that (i) secret information is embedded in
mobile phones at manufacture, and (ii) a centralized database of this
is accessible during the network lifetime.
However, as a primary use case of a MANET is to provide connectivity
absent centralized entities, and with minimal management, a solution
such as that used in a mobile phone network is not feasible. In many
instances, a cryptographic authority may not be present in the MANET
at all, since such a cryptographic authority would be too vulnerable.
Due to the potentially dynamic topology of a MANET, a cryptographic
authority may also become unreachable (to some or all of the MANET
routers) without prior warning.
[BCP107] provides guidelines for cryptographic key management.
Specifically, Section 2.1 describes requirements for when AKM is
required, and Section 2.2 describes conditions under which manual key
management is acceptable.
Section 2.1 of [BCP107] stipulates that "Automated key management
MUST be used if any of [a set of given] conditions hold". These
conditions are listed below, for each of which arguments are provided
as to their applicability for the baseline use case of OLSRv2.
A party will have to manage n^2 static keys, where n may become
large.
The baseline use case of OLSRv2 uses only one key in the whole
MANET.
Any stream cipher (such as RC4 [TK], AES-CTR [NIST], or AES-CCM
[WHF]) is used.
A stream cipher is not envisioned to be used for generating ICVs
for OLSRv2 control messages.
An initialization vector (IV) might be reused, especially an implicit
IV. Note that random or pseudo-random explicit IVs are not a problem
unless the probability of repetition is high.
An IV is not envisioned to be used for generating ICVs for OLSRv2
control messages.
Large amounts of data might need to be encrypted in a short time,
causing frequent change of the short-term session key.
Integrity Check Values (ICVs) are required only for OLSRv2 control
messages, which are low-volume messages.
Long-term session keys are used by more than two parties. Multicast
is a necessary exception, but multicast key management standards are
emerging in order to avoid this in the future. Sharing long-term
session keys should generally be discouraged.
OLSRv2 control messages are all sent using link local multicast.
The likely operational environment is one where personnel (or device)
turnover is frequent, causing frequent change of the short-term
session key.
This is not an intended deployment of OLSRv2. For longer-term
OLSRv2 deployments, alternative security mechanisms (e.g.,
including re-keying) SHOULD be considered.
Section 2.2 of [BCP107] stipulates that "Manual key management may be
a reasonable approach in any of [a given set of] situations". These
situation are listed below, for each of which arguments are provided
as to their applicability for the baseline use case of OLSRv2.
The environment has very limited available bandwidth or very high
round-trip times. Public key systems tend to require long messages
and lots of computation; symmetric key alternatives, such as
Kerberos, often require several round trips and interaction with
third parties.
Bandwidth is limited, both by being a radio environment, and by
the need for any signaling to consume a minimal proportion
thereof. A system such as Kerberos would therefore be
inappropriate - and as previously noted, there may not be the
required infrastructure (cryptographic authority) present - or, if
present, reachable - in the MANET.
The information being protected has low value.
This depends on the OLSRv2 use case, but the information being
protected is OLSRv2 control traffic, which is of moderate value.
The total volume of traffic over the entire lifetime of the long-term
session key will be very low.
Integrity Check Values (ICVs) are required only for OLSRv2 control
messages, which are low-volume messages.
The scale of each deployment is very limited
A typical use case for OLSRv2 may involve only tens of devices -
with even the largest use cases for OLSRv2 being small by Internet
standards.
24. IANA Considerations 24. IANA Considerations
This specification defines one Message Type, which must be allocated This specification defines one Message Type, which must be allocated
from the "Message Types" repository of [RFC5444], two Message TLV from the "Message Types" repository of [RFC5444], two Message TLV
Types, which must be allocated from the "Message TLV Types" Types, which must be allocated from the "Message TLV Types"
repository of [RFC5444], and four Address Block TLV Types, which must repository of [RFC5444], and four Address Block TLV Types, which must
be allocated from the "Address Block TLV Types" repository of be allocated from the "Address Block TLV Types" repository of
[RFC5444]. [RFC5444].
24.1. Expert Review: Evaluation Guidelines 24.1. Expert Review: Evaluation Guidelines
skipping to change at page 93, line 37 skipping to change at page 96, line 37
Finally, the authors would like to express their gratitude to the Finally, the authors would like to express their gratitude to the
Area Directors for providing valuable review comments during the IESG Area Directors for providing valuable review comments during the IESG
evaluation, in particular (listed alphabetically) Benoit Claise, evaluation, in particular (listed alphabetically) Benoit Claise,
Adrian Farrel, Stephen Farrell, Barry Leiba, Pete Resnick, and Martin Adrian Farrel, Stephen Farrell, Barry Leiba, Pete Resnick, and Martin
Stiemerling. Stiemerling.
27. References 27. References
27.1. Normative References 27.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to
Requirement Levels", RFC 2119, BCP 14, March 1997. Indicate Requirement Levels", RFC 2119, BCP 14,
March 1997.
[RFC5148] Clausen, T., Dearlove, C., and B. Adamson, "Jitter [RFC5148] Clausen, T., Dearlove, C., and B. Adamson,
Considerations in Mobile Ad Hoc Networks (MANETs)", "Jitter Considerations in Mobile Ad Hoc Networks
RFC 5148, February 2008. (MANETs)", RFC 5148, February 2008.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for
IANA Considerations Section in RFCs", RFC 5226, BCP 26, Writing an IANA Considerations Section in RFCs",
May 2008. RFC 5226, BCP 26, May 2008.
[RFC5444] Clausen, T., Dean, J., Dearlove, C., and C. Adjih, [RFC5444] Clausen, T., Dean, J., Dearlove, C., and C.
"Generalized Mobile Ad Hoc Network (MANET) Packet/ Adjih, "Generalized Mobile Ad Hoc Network (MANET)
Message Format", RFC 5444, February 2009. Packet/Message Format", RFC 5444, February 2009.
[RFC5497] Clausen, T. and C. Dearlove, "Representing Multi-Value [RFC5497] Clausen, T. and C. Dearlove, "Representing Multi-
Time in Mobile Ad Hoc Networks (MANETs)", RFC 5497, Value Time in Mobile Ad Hoc Networks (MANETs)",
March 2009. RFC 5497, March 2009.
[RFC5498] Chakeres, I., "IANA Allocations for Mobile Ad Hoc [RFC5498] Chakeres, I., "IANA Allocations for Mobile Ad Hoc
Network (MANET) Protocols", RFC 5498, March 2009. Network (MANET) Protocols", RFC 5498, March 2009.
[RFC6130] Clausen, T., Dean, J., and C. Dearlove, "Mobile Ad Hoc [RFC6130] Clausen, T., Dean, J., and C. Dearlove, "Mobile
Network (MANET) Neighborhood Discovery Protocol (NHDP)", Ad Hoc Network (MANET) Neighborhood Discovery
RFC 6130, April 2011. Protocol (NHDP)", RFC 6130, April 2011.
[OLSRv2-integrity] Herberg, U., Dearlove, C., and T. Clausen,
"Integrity Protection for Control Messages in
NHDP and OLSRv2", Internet
Draft draft-herberg-manet-nhdp-olsrv2-sec-02,
March 2013.
27.2. Informative References 27.2. Informative References
[RFC2501] Macker, J. and S. Corson, "Mobile Ad hoc Networking [RFC2501] Macker, J. and S. Corson, "Mobile Ad hoc
(MANET): Routing Protocol Performance Issues and Networking (MANET): Routing Protocol Performance
Evaluation Considerations", RFC 2501, January 1999. Issues and Evaluation Considerations", RFC 2501,
January 1999.
[RFC3626] Clausen, T. and P. Jacquet, "The Optimized Link State [RFC3626] Clausen, T. and P. Jacquet, "The Optimized Link
Routing Protocol", RFC 3626, October 2003. State Routing Protocol", RFC 3626, October 2003.
[RFC6622] Herberg, U. and T. Clausen, "Integrity Check Value and [RFC6622bis] Herberg, U., Clausen, T., and C. Dearlove,
Timestamp TLV Definitions for Mobile Ad Hoc Networks "Integrity Check Value and Timestamp TLV
(MANETs)", RFC 6622, May 2012. Definitions for Mobile Ad Hoc Networks (MANETs)",
Internet
Draft draft-herberg-manet-rfc6622-bis-02,
March 2013.
[HIPERLAN] ETSI, "ETSI STC-RES10 Committee. Radio equipment and [HIPERLAN] ETSI, "ETSI STC-RES10 Committee. Radio equipment
systems: HIPERLAN type 1, functional specifications ETS and systems: HIPERLAN type 1, functional
300-652", June 1996. specifications ETS 300-652", June 1996.
[HIPERLAN2] Jacquet, P., Minet, P., Muhlethaler, P., and N. [HIPERLAN2] Jacquet, P., Minet, P., Muhlethaler, P., and N.
Rivierre, "Increasing reliability in cable free radio Rivierre, "Increasing reliability in cable free
LANs: Low level forwarding in HIPERLAN.", 1996. radio LANs: Low level forwarding in HIPERLAN.",
1996.
[MPR] Qayyum, A., Viennot, L., and A. Laouiti, "Multipoint [MPR] Qayyum, A., Viennot, L., and A. Laouiti,
relaying: An efficient technique for flooding in mobile "Multipoint relaying: An efficient technique for
wireless networks.", 2001. flooding in mobile wireless networks.", 2001.
[FSR] Pei, G., Gerla, M., and T. Chen, "Fisheye state routing [FSR] Pei, G., Gerla, M., and T. Chen, "Fisheye state
in mobile ad hoc networks", 2000. routing in mobile ad hoc networks", 2000.
[FSLS] Santivanez, C., Ramanathan, R., and I. Stavrakakis, [FSLS] Santivanez, C., Ramanathan, R., and I.
"Making link-state routing scale for ad hoc networks", Stavrakakis, "Making link-state routing scale for
2000. ad hoc networks", 2000.
[McCabe] McCabe, A., Dearlove, C., Fredin, M., and L. Axelsson, [McCabe] McCabe, A., Dearlove, C., Fredin, M., and L.
"Scalability Modelling of Ad Hoc Routing Protocols - A Axelsson, "Scalability Modelling of Ad Hoc
Comparison of OLSR and DSR", 2004. Routing Protocols - A Comparison of OLSR and
DSR", 2004.
[BCP107] Bellovin, S. and R. Housley, "Guidelines for
Cryptographic Key Management", BCP 107, RFC 4107,
June 2005.
Appendix A. Constraints Appendix A. Constraints
Updates to the Local Information Base, the Neighborhood Information Updates to the Local Information Base, the Neighborhood Information
Base or the Topology Information Base MUST ensure that all Base or the Topology Information Base MUST ensure that all
constraints specified in this appendix are maintained, as well as constraints specified in this appendix are maintained, as well as
those specified in [RFC6130]. This is the case for the processing, those specified in [RFC6130]. This is the case for the processing,
specified in this document. Any protocol extension or outside specified in this document. Any protocol extension or outside
process, which updates the Neighborhood Information Base or the process, which updates the Neighborhood Information Base or the
Topology Information Base, MUST also ensure that these constraints Topology Information Base, MUST also ensure that these constraints
 End of changes. 28 change blocks. 
87 lines changed or deleted 237 lines changed or added

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