Skip to main content

Responsive Use of the Mobile Ad Hoc Network (MANET) Routing Protocol OLSRv2
draft-dearlove-manet-olsrv2-responsive-01

Document Type Active Internet-Draft (individual)
Author Christopher Dearlove
Last updated 2024-12-13
RFC stream (None)
Intended RFC status (None)
Formats
Stream Stream state (No stream defined)
Consensus boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-dearlove-manet-olsrv2-responsive-01
Mobile Ad hoc Networking (MANET)                             C. Dearlove
Internet-Draft                                          13 December 2024
Updates: 7181 (if approved)                                             
Intended status: Standards Track                                        
Expires: 16 June 2025

  Responsive Use of the Mobile Ad Hoc Network (MANET) Routing Protocol
                                 OLSRv2
               draft-dearlove-manet-olsrv2-responsive-01

Abstract

   This specification describes an optional Topology Control (TC)
   message that can be sent by an OLSRv2 router.  This is permitted, but
   not suggested, by the existing protocol, but is here recommended for
   use in some networks.  The original motivation for this message came
   from the circumstances of a mostly stable network, in the most
   extreme case updated only by messages responding to the arrival and
   departure of routers, in which case the additional TC message is not
   just recommended but required.  However, the additional message could
   be useful in reducing the routing convergence time in any network in
   which messages are sent at lengthy intervals.

   This specification updates RFC 7181 "The Optimized Link State Routing
   Protocol version 2 (OLSRv2)".

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 https://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 16 June 2025.

Copyright Notice

   Copyright (c) 2024 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

Dearlove                  Expires 16 June 2025                  [Page 1]
Internet-Draft          Responsive Use of OLSRv2           December 2024

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents (https://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 Revised BSD License text as
   described in Section 4.e of the Trust Legal Provisions and are
   provided without warranty as described in the Revised BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   4
   3.  Applicability Statement . . . . . . . . . . . . . . . . . . .   4
   4.  Analysis  . . . . . . . . . . . . . . . . . . . . . . . . . .   4
     4.1.  Overview  . . . . . . . . . . . . . . . . . . . . . . . .   4
     4.2.  Router Arrival  . . . . . . . . . . . . . . . . . . . . .   5
     4.3.  An Alternative Approach . . . . . . . . . . . . . . . . .   6
   5.  Changes to OLSRv2 . . . . . . . . . . . . . . . . . . . . . .   6
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   7
   7.  Security Considerations . . . . . . . . . . . . . . . . . . .   7
   8.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .   7
   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   7
     9.1.  Normative References  . . . . . . . . . . . . . . . . . .   7
     9.2.  Informative References  . . . . . . . . . . . . . . . . .   8
   Appendix A.  Fully Responsive Networks" . . . . . . . . . . . . .   9
     A.1.  Network Dynamism and Message Loss . . . . . . . . . . . .   9
     A.2.  Router Arrival  . . . . . . . . . . . . . . . . . . . . .  10
     A.3.  Router Departure  . . . . . . . . . . . . . . . . . . . .  10
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  12

1.  Introduction

   The Optimized Link State Routing Protocol version 2 (OLSRv2)
   [RFC7181] is a proactive routing protocol for use in mobile ad hoc
   networks (MANETs).

   This specification considers TC (Topology Control) messages that are
   sent by instances of OLSRv2, but there is also reference to HELLO
   messages.  HELLO messages are formally sent by the NeighborHood
   Discovery Protocol (NHDP) specified in [RFC6130], but are then
   modified by OLSRv2.  For simplicity, this document describes both as
   sent by OLSRv2.

   [RFC7181] permits a wide range of behaviours by routers.  This is
   intended to allow other approaches than its usual behavior.  For
   example, OLSRv2 permits a router to set and change its message
   intervals, constrained only by administrative rules that are outside

Dearlove                  Expires 16 June 2025                  [Page 2]
Internet-Draft          Responsive Use of OLSRv2           December 2024

   the scope of [RFC7181].  This can be used, for example, to allow a
   router to "back off" (typically exponentially) message intervals when
   a network appears to be stable, reverting to more frequent messages
   if any changes are observed.  Such behavior is not directly
   considered in this specification, but can be combined with the
   sending of other responsive messages, i.e., any messages sent in
   response to a change in circumstances rather than on a periodic
   schedule.

   This specification was motivated by the design of OLSRv2 that permits
   the sending of HELLO messages, and subsequently TC messages if
   required, in response to changes in the local neighborhood.  These
   messages can be sent in addition to periodically scheduled messages,
   their aim being to accelerate routing table convergence.  The extreme
   case of such behavior would be to only send such responsive message,
   with no periodic messages sent at all.  This extreme case, and
   variants of it, is considered further in Appendix A.  This case was
   the motivation for this specification, because in it sending some
   additional TC messages that are permitted but not suggested by
   [RFC7181], is required for the protocol to be fully functional.
   These additional messages are thus required in those circumstances,
   should they ever occur, by this specification.

   However, the primary purpose of this specification is to recommend,
   but not require, sending such additional messages in networks that,
   while not fully responsive, are generally stable and thus use longer
   message intervals, possibly due to being backed off, as well as
   sending messages responding to local neighborhood changes.  In such
   networks the additional messages recommended by this specification
   can further improve the routing table convergence time across the
   network.

   This specification thus modifies the behavior of the protocol, but
   only by making an optional behavior - sending an additional, but
   standard format, TC message - recommended in some cases, and required
   in some further cases.  The circumstances in which this additional
   message is required, not just recommended, are not expected to be
   encountered in most practical networks, but represent a limiting case
   of those in which the message is recommended.  In addition, in the
   circumstances when the message is required the existing protocol
   would not produce a fully functioning network, and thus there is no
   interoperability issue introduced by requiring the additional message
   in those circumstances.

   All OLSRv2 routers, whether or not using this specification, can
   process these additional TC messages, and can thus fully interoperate
   in all circumstances.  This specification is thus in practice, fully
   interoperable with all routers in functional OLSRv2 networks.

Dearlove                  Expires 16 June 2025                  [Page 3]
Internet-Draft          Responsive Use of OLSRv2           December 2024

   Whether or not such additional messages are sent is, as with all
   details of message sending, including but not limited to message
   intervals and validity times, and any variation thereof, set by
   administrative configuration, for example using [RFC6779] and
   [RFC7184].

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

   Additionally, this document uses the terminology of [RFC6130] and
   [RFC7181].

3.  Applicability Statement

   This specification updates [RFC7181] by indicating circumstances in
   which an otherwise optional, but not suggested, additional TC message
   sending is recommended or required due to the reduction or
   elimination of periodic message sending in a network that is largely
   stable.

   This change has no effect on the interoperability of routers using
   [RFC7181], because such additional messages are always permitted, and
   the only circumstances in which the additional messages are required
   are ones in which the network will not properly function without
   them.

4.  Analysis

   This section considers the implications of a mostly or fully
   responsive network and why the responsive messages indicated in
   [RFC7181] are not sufficient in this case.  The solution proposed,
   which is necessary if operating fully responsively, is not limited to
   this case, but this case is useful to develop it.

4.1.  Overview

   The main reason for considering the responsive use of OLSRv2 is to
   reduce the number of messages sent and received by the protocol,
   while still responding to changes.  When using this approach, the
   protocol loses the resilience to message loss that is provided by the
   sending of periodic messages.  For discussion of this and other
   practical issues arising in a fully, or largely, responsive network,
   see Appendix A.  This analysis assumes that all messages are, by one
   means or another, successfully received by the intended recipients,

Dearlove                  Expires 16 June 2025                  [Page 4]
Internet-Draft          Responsive Use of OLSRv2           December 2024

   and considers whether these messages are sufficient.

4.2.  Router Arrival

   When a router is first activated, it sends a HELLO message that
   announces its own identity, but no other significant information.
   This is recognised by other routers that send new, modified, HELLO
   messages that in due course stabilise.  This can be using any
   combination of periodic and responsive HELLO messages.  If acting
   purely responsively, after stabilisation no further HELLO messages
   would be required until any later local change to the network.

   At this point all routers within two hops of the new router will have
   updated their relevant Information Bases and computed new MultiPoint
   Relays (MPRs) that are included in their HELLO messages.  (This is
   the modification to the HELLO messages defined in [RFC6130] that was
   introduced by [RFC7181].)  From this, these local routers update
   their MPR selectors and thus some or all of them will send new TC
   messages, with a new Advertised Neighbor Sequence Number (ANSN) that
   replaces the information recorded from previous TC messages.

   This process updates all necessary information recorded at each pre-
   existing router, in particular its routing table.  However, the new
   router will lack routing information from routers beyond its 2-hop
   neighborhood, and from any routers within its 2-hop neighborhood that
   do not change their advertised neighbors.  In normal use, this
   missing information will, in due course, be provided by the periodic
   sending of TC messages by all routers that advertise any neighbors.
   However, that would not occur in a fully responsive network.

   A solution to this problem is that when a router recognises a new
   router added to the network it sends a responsive TC message, if it
   has not already done so.  The arrival of a new router can be
   recognised by the addition of a new tuple to the Advertising Remote
   Router Set. This new form of responsiveness - to a remote event
   rather than to a local event - ensures that the new router learns all
   the information that it requires even without periodic messages.

   In the usual case where responsive messages supplement periodic
   messages, which may thus have a longer interval, this will provide
   the new router with its required information without waiting for a
   periodic message, thus accelerating routing table convergence.

Dearlove                  Expires 16 June 2025                  [Page 5]
Internet-Draft          Responsive Use of OLSRv2           December 2024

4.3.  An Alternative Approach

   A faster approach to a new router joining the network would be for
   one or more of its new neighbors to provide the complete network
   topology to it.  This would require new protocol messages and is not
   included in this specification.  A suggestion as to how to achieve
   this for what is now considered version 1 of OLSR, [RFC3626], was
   described in [Clausen2004].  It has not been suggested here as it is
   a non-compatible change to the protocol if it is relied on.  (If it
   is supplementary then it could simply be ignored, failing to achieve
   its purpose of speeding up convergence, but not doing any harm.)

5.  Changes to OLSRv2

   This specification makes a single normative change to [RFC7181].  A
   complete TC message MAY be sent, according to that specification, at
   any time.  One such time - not considered in that specification - is
   the addition of an Advertising Remote Router Tuple to the Advertising
   Remote Router Set. This specification defines circumstances in which
   that OPTIONAL sending is instead RECOMMENDED or REQUIRED.  Note that
   this behavior on recognising these circumstances is administratively
   configured, not recognised from message exchange; it is a companion
   to administrative configuration of the protocol parameters, for
   example using [RFC6779] and [RFC7184].

   When a router adds an Advertising Remote Router Tuple to the
   Advertising Remote Router Set it is RECOMMENDED that a complete TC
   message is sent if the router has not already sent a TC message in
   response to the same change (which can occur if the sending router is
   within two hops of the new router) and there would be a significant
   delay before such a message would be sent periodically.  The decision
   as to what constitutes a significant delay is an administrative
   issue, but, as a guideline, delays in excess of the default value of
   TC_INTERVAL are likely to be considered as significant.

   When a router adds an Advertising Remote Router Tuple to the
   Advertising Remote Router Set it is REQUIRED that a complete TC
   message is sent if the router has not already sent a TC message in
   response to the same change and no TC messages are currently
   scheduled, or if the maximum possible TC message interval is used as
   an effective equivalent to that.

Dearlove                  Expires 16 June 2025                  [Page 6]
Internet-Draft          Responsive Use of OLSRv2           December 2024

   Such sending of a TC message is subject to the usual constraints on
   sending such messages, in particular the setting of the parameter
   TC_MIN_INTERVAL, and SHOULD be jittered as described in [RFC5148]
   according to the guidelines as to its use in [RFC7181].  Note that
   even if the parameter TC_INTERVAL is currently set to a long time,
   the parameter TC_MIN_INTERVAL should usually be kept to its default
   value or another smaller value.

6.  IANA Considerations

   This document has no actions for IANA.

   [This section may be removed by the RFC Editor.]

7.  Security Considerations

   This update to [RFC7181] recommends, under the circumstances
   indicated, additional messages that are already permitted.  As such,
   this protocol introduces no new integrity considerations to an
   implementation of [RFC7181], which is usually expected to use
   [RFC7182] for this purpose.  If responsive behaviour is used in a
   network that it is unsuited for, then there will be a loss of network
   availability.  However, this is another case of the existing
   consideration that any use of OLSRv2 with unsuitable parameters will
   produce a badly or non- functioning network.  In any already
   functioning network this change will improve, rather than reduce,
   availability, that being its purpose.

8.  Acknowledgments

   The author would like to thank Thomas Clausen (Ecole Polytechnique)
   for his comments on the first version of this Internet Draft.

9.  References

9.1.  Normative References

   [BCP14]    Best Current Practice 14,
              <https://www.rfc-editor.org/info/bcp14>.
              At the time of writing, this BCP comprises the following:

              Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

Dearlove                  Expires 16 June 2025                  [Page 7]
Internet-Draft          Responsive Use of OLSRv2           December 2024

              Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/info/rfc8174>.

   [RFC6130]  Clausen, T., Dearlove, C., and J. Dean, "Mobile Ad Hoc
              Network (MANET) Neighborhood Discovery Protocol (NHDP)",
              RFC 6130, DOI 10.17487/RFC6130, April 2011,
              <https://www.rfc-editor.org/info/rfc6130>.

   [RFC7181]  Clausen, T., Dearlove, C., Jacquet, P., and U. Herberg,
              "The Optimized Link State Routing Protocol Version 2",
              RFC 7181, DOI 10.17487/RFC7181, April 2014,
              <https://www.rfc-editor.org/info/rfc7181>.

9.2.  Informative References

   [Clausen2004]
              Clausen, T., Baccelli, E., and P. Jacquet, "OSPF-Style
              Database Exchange and Reliable Synchronization in the
              Optimized Link-State Routing Protocol", First Annual IEEE
              Communications Society Conference on Sensor and Ad Hoc
              Communications and Networks, 2004.  IEEE SECON 2004.,
              Santa Clara, CA, USA, 2004, pp. 227-234, doi: 10.1109/
              SAHCN.2004.1381921.

   [RFC3626]  Clausen, T., Ed. and P. Jacquet, Ed., "Optimized Link
              State Routing Protocol (OLSR)", RFC 3626,
              DOI 10.17487/RFC3626, October 2003,
              <https://www.rfc-editor.org/info/rfc3626>.

   [RFC5148]  Clausen, T., Dearlove, C., and B. Adamson, "Jitter
              Considerations in Mobile Ad Hoc Networks (MANETs)",
              RFC 5148, DOI 10.17487/RFC5148, February 2008,
              <https://www.rfc-editor.org/info/rfc5148>.

   [RFC6779]  Herberg, U., Cole, R., and I. Chakeres, "Definition of
              Managed Objects for the Neighborhood Discovery Protocol",
              RFC 6779, DOI 10.17487/RFC6779, October 2012,
              <https://www.rfc-editor.org/info/rfc6779>.

   [RFC7182]  Herberg, U., Clausen, T., and C. Dearlove, "Integrity
              Check Value and Timestamp TLV Definitions for Mobile Ad
              Hoc Networks (MANETs)", RFC 7182, DOI 10.17487/RFC7182,
              April 2014, <https://www.rfc-editor.org/info/rfc7182>.

Dearlove                  Expires 16 June 2025                  [Page 8]
Internet-Draft          Responsive Use of OLSRv2           December 2024

   [RFC7184]  Herberg, U., Cole, R., and T. Clausen, "Definition of
              Managed Objects for the Optimized Link State Routing
              Protocol Version 2", RFC 7184, DOI 10.17487/RFC7184, April
              2014, <https://www.rfc-editor.org/info/rfc7184>.

   [RFC7859]  Dearlove, C., "Identity-Based Signatures for Mobile Ad Hoc
              Network (MANET) Routing Protocols", RFC 7859,
              DOI 10.17487/RFC7859, May 2016,
              <https://www.rfc-editor.org/info/rfc7859>.

Appendix A.  Fully Responsive Networks"

   This appendix considers some details of how a network that only sends
   responsive messages could operate.  As noted, this is the limiting
   case of possible behavior, and unlikely to be fully realised, as
   while is expected that while some networks may rely more on
   responsive messages, none are expected to rely fully on them.
   However, these comments may also apply, in whole or part, to such
   more (but not fully) responsive networks.

A.1.  Network Dynamism and Message Loss

   In considering these networks, note that although the word "mobile"
   is part of the expansion of the acronym MANET, and networks with
   mobility are the most important use case for OLSRv2, ad hoc networks
   need not include mobility, but can be dynamic in other ways,
   including cases such as changes in the physical medium.  An important
   case is where the principal, or even only, dynamism is the
   introduction of new routers to the network, or the departure -
   voluntarily or otherwise - of routers from the network.  Such a
   network can be considered to be stable between such arrivals and
   departures.

   If only single messages - whether HELLO messages or TC messages - are
   sent, the loss of even a single message could mean that some
   connectivity that is present is not used.  This might be acceptable
   in a dense network, or one in which message loss is unusual, possibly
   due to the behavior of the data link layer in use.  However, it is
   also important to maintain connectivity to any routers that have
   local hosts from or to which data traffic may be sent, even if these
   are not essential for routing.

Dearlove                  Expires 16 June 2025                  [Page 9]
Internet-Draft          Responsive Use of OLSRv2           December 2024

   When maintaining the connectivity of a router that is not sending
   messages periodically, one approach to improve the situation is to
   send more than one copy of each message, separated by at least the
   appropriate minimum message interval, which must be set appropriately
   for this case.  This is similar to the suggestion in [RFC7181] that,
   when sending messages following an increase in message interval, more
   than one message can be sent using the old interval before changing
   to the new interval.

A.2.  Router Arrival

   A newly arrived router in a fully responsive network will send HELLO
   messages and, due to its new neighbors hearing those messages,
   realising that their neighborhood has changed, and sending their own
   responsive HELLO messages, the new router will become fully
   integrated into its neighborhood (assuming no message loss).  It will
   also then send TC messages including its advertised neighbors.

   In this way, remote routers - those beyond two hops of the new router
   - will learn of the new router.  But the converse is not so.  The new
   router will only learn of remote routers if they send TC messages.
   Those messages are the subject of this specification, described
   outside this appendix.  But note that in a fully responsive network,
   these TC messages are essential to the new router fully joining the
   network, and hence why these TC messages from remore routers are
   required in this case.

A.3.  Router Departure

   There are two possible cases of router departure, depending on
   whether the router can recognise its upcoming departure, or loss, in
   time to take action, or not.  An example of where this recognition
   might be possible is when that loss is due to battery exhaustion, but
   by monitoring the battery that exhaustion can be anticipated.  In
   this case the router can opt out of the network by sending a HELLO
   message reporting all of its neighbours as lost using a LINK_STATUS
   TLVs with all neighbour addresses having value LOST, and, if
   necessary, a complete TC message with a new ANSN containing no
   advertised neighbors.

   However, in other circumstances this loss might occur unpredictably.
   In that case it is necessary for the lost router's neighbors to
   recognise the loss.  If that can be done by some means other than
   using OLSRv2 messages that would be advantageous, but it is expected
   that the only source for this is to use OLSRv2 messages.

Dearlove                  Expires 16 June 2025                 [Page 10]
Internet-Draft          Responsive Use of OLSRv2           December 2024

   That a router is present and correct is signalled by HELLO messages.
   In principle, in an otherwise purely responsive network it would be
   possible to restrict these to being empty, and neighbors to recognise
   that a router is lost by the cessation of these simple "heartbeat"
   messages.  But that is not how NHDP is defined, and would require a
   change to its operation, and is not part of this specification.

   However, although in this case periodic HELLO messages are required,
   this does not mean that periodic TC messages are required.  TC
   messages can be, in this instance, limited to the initial long
   validity time messages sent by a new router.  To show this, consider
   what happens if a router is lost in this case.  Because the lost
   router was sending HELLO messages that have now ceased, neighbor
   routers can recognise that the router is lost and remove it from all
   Information Bases.

   However, if TC messages have effectively infinite validity times, and
   if a router is lost without warning, the information it has
   previously sent in its TC messages will remain in the Information
   Bases of all other routers in the network.  This is undesirable in
   that it occupies memory and might increase the time required to
   access wanted information.  However, as the analysis below shows,
   that unwanted information is never used, and thus there is no major
   harm in its continued presence.

   Once a router is recognised as lost by its neighbors, they will
   remove it from their Neighbor Information Bases.  This will leave no
   local links to the lost router based on messages from those
   neighbors.  However, links using the lost router will persist in the
   Topology Information Bases of other routers based on received TC
   messages.  However, all of those links will be outgoing from the lost
   router, there will be no incoming links to that lost router still
   recorded, and thus that lost router will not be included in any
   routes.  This is because although a TC message can - because there is
   no prohibition on doing so - include incoming links as well as the
   required outgoing links, those incoming links are not processed using
   [RFC7181] as the required processing in Section 16.3.3.2 relies on
   having a known associated metric value, and that value is defined in
   Section 16.3.2 as being an outgoing meighbor metric value.

   One approach that could be used to remove unwanted information in a
   network with both router gains and losses, but is not part of this
   specification, is that when a router recognises a router gain, as
   described in the previous section, as well as sending a TC message it
   expects to receive similar TC messages from other routers.  To rely
   on this would require all routers to send TC messages in this
   circumstance, even if they have no advertised neighbors.  Because the
   sending of such TC messages, especially in the latter case, cannot be

Dearlove                  Expires 16 June 2025                 [Page 11]
Internet-Draft          Responsive Use of OLSRv2           December 2024

   assumed, this is not part of this specification, which aims at
   backward compatibility.  However, were a guarantee of such TC
   messages to be implemented in a network then failure to receive any
   such TC messages would suggest that a router that is represented in
   the Advertising Remote Router Set, but from which no such TC message
   is received, might be lost.  One or more such occurrences could then
   be used to remove the corresponding Advertising Remote Router Tuple.

   Retaining periodic HELLO messages, but not periodic TC messages,
   loses some of the advantages of responsive use of the protocol, such
   as possible covertness.  However, it reduces message sending and
   processing, thus economising battery use.  Note also that in a large
   network, it is the periodic TC messages, that here are not being
   sent, that can create some scalability problems for the protocol, as
   periodic TC messages impose an overhead on each router that depends
   on the overall network size, whereas periodic HELLO messages
   introduce an overhead on each router that only depends on the local
   neighborhood size.

   The unwanted information based on TC messages from a lost router
   could also be removed if a neighbor that has recognised its loss sent
   a cancelling TC message that is created as if from the lost router.
   This could be sent as if forwarded and thus would appear to be
   genuine.  However, this is undesirable from a security viewpoint, and
   some forms of message integrity check values (ICVs) as defined in
   [RFC7182], in particular the identity-based ICV described in
   [RFC7859], could not be created.  Consequently this approach,
   although possible in some circumstances, such as the use of a single
   shared key for all ICVs, is also not part of this specification.

Author's Address

   Christopher Dearlove
   Email: christopher.dearlove@gmail.com

Dearlove                  Expires 16 June 2025                 [Page 12]