doc: Add RFC documents

1 files changed, 2998 insertions, 0 deletions

diff --git a/doc/rfc/rfc8990.txt b/doc/rfc/rfc8990.txt
new file mode 100644
index 0000000..fdd3d86
--- /dev/null
+++ b/doc/rfc/rfc8990.txt
@@ -0,0 +1,2998 @@
+
+
+
+
+Internet Engineering Task Force (IETF)                        C. Bormann
+Request for Comments: 8990                        Universität Bremen TZI
+Category: Standards Track                              B. Carpenter, Ed.
+ISSN: 2070-1721                                        Univ. of Auckland
+                                                             B. Liu, Ed.
+                                            Huawei Technologies Co., Ltd
+                                                                May 2021
+
+
+              GeneRic Autonomic Signaling Protocol (GRASP)
+
+Abstract
+
+   This document specifies the GeneRic Autonomic Signaling Protocol
+   (GRASP), which enables autonomic nodes and Autonomic Service Agents
+   to dynamically discover peers, to synchronize state with each other,
+   and to negotiate parameter settings with each other.  GRASP depends
+   on an external security environment that is described elsewhere.  The
+   technical objectives and parameters for specific application
+   scenarios are to be described in separate documents.  Appendices
+   briefly discuss requirements for the protocol and existing protocols
+   with comparable features.
+
+Status of This Memo
+
+   This is an Internet Standards Track document.
+
+   This document is a product of the Internet Engineering Task Force
+   (IETF).  It represents the consensus of the IETF community.  It has
+   received public review and has been approved for publication by the
+   Internet Engineering Steering Group (IESG).  Further information on
+   Internet Standards is available in Section 2 of RFC 7841.
+
+   Information about the current status of this document, any errata,
+   and how to provide feedback on it may be obtained at
+   https://www.rfc-editor.org/info/rfc8990.
+
+Copyright Notice
+
+   Copyright (c) 2021 IETF Trust and the persons identified as the
+   document authors.  All rights reserved.
+
+   This document is subject to BCP 78 and the IETF Trust's Legal
+   Provisions Relating to IETF Documents
+   (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 Simplified BSD License text as described in Section 4.e of
+   the Trust Legal Provisions and are provided without warranty as
+   described in the Simplified BSD License.
+
+Table of Contents
+
+   1.  Introduction
+   2.  Protocol Overview
+     2.1.  Terminology
+     2.2.  High-Level Deployment Model
+     2.3.  High-Level Design
+     2.4.  Quick Operating Overview
+     2.5.  GRASP Basic Properties and Mechanisms
+       2.5.1.  Required External Security Mechanism
+       2.5.2.  Discovery Unsolicited Link-Local (DULL) GRASP
+       2.5.3.  Transport Layer Usage
+       2.5.4.  Discovery Mechanism and Procedures
+       2.5.5.  Negotiation Procedures
+       2.5.6.  Synchronization and Flooding Procedures
+     2.6.  GRASP Constants
+     2.7.  Session Identifier (Session ID)
+     2.8.  GRASP Messages
+       2.8.1.  Message Overview
+       2.8.2.  GRASP Message Format
+       2.8.3.  Message Size
+       2.8.4.  Discovery Message
+       2.8.5.  Discovery Response Message
+       2.8.6.  Request Messages
+       2.8.7.  Negotiation Message
+       2.8.8.  Negotiation End Message
+       2.8.9.  Confirm Waiting Message
+       2.8.10. Synchronization Message
+       2.8.11. Flood Synchronization Message
+       2.8.12. Invalid Message
+       2.8.13. No Operation Message
+     2.9.  GRASP Options
+       2.9.1.  Format of GRASP Options
+       2.9.2.  Divert Option
+       2.9.3.  Accept Option
+       2.9.4.  Decline Option
+       2.9.5.  Locator Options
+     2.10. Objective Options
+       2.10.1.  Format of Objective Options
+       2.10.2.  Objective Flags
+       2.10.3.  General Considerations for Objective Options
+       2.10.4.  Organizing of Objective Options
+       2.10.5.  Experimental and Example Objective Options
+   3.  Security Considerations
+   4.  CDDL Specification of GRASP
+   5.  IANA Considerations
+   6.  References
+     6.1.  Normative References
+     6.2.  Informative References
+   Appendix A.  Example Message Formats
+     A.1.  Discovery Example
+     A.2.  Flood Example
+     A.3.  Synchronization Example
+     A.4.  Simple Negotiation Example
+     A.5.  Complete Negotiation Example
+   Appendix B.  Requirement Analysis of Discovery, Synchronization,
+           and Negotiation
+     B.1.  Requirements for Discovery
+     B.2.  Requirements for Synchronization and Negotiation Capability
+     B.3.  Specific Technical Requirements
+   Appendix C.  Capability Analysis of Current Protocols
+   Acknowledgments
+   Authors' Addresses
+
+1.  Introduction
+
+   The success of the Internet has made IP-based networks bigger and
+   more complicated.  Large-scale ISP and enterprise networks have
+   become more and more problematic for human-based management.  Also,
+   operational costs are growing quickly.  Consequently, there are
+   increased requirements for autonomic behavior in the networks.
+   General aspects of Autonomic Networks are discussed in [RFC7575] and
+   [RFC7576].
+
+   One approach is to largely decentralize the logic of network
+   management by migrating it into network elements.  A reference model
+   for Autonomic Networking on this basis is given in [RFC8993].  The
+   reader should consult this document to understand how various
+   autonomic components fit together.  In order to achieve autonomy,
+   devices that embody Autonomic Service Agents (ASAs, [RFC7575]) have
+   specific signaling requirements.  In particular, they need to
+   discover each other, to synchronize state with each other, and to
+   negotiate parameters and resources directly with each other.  There
+   is no limitation on the types of parameters and resources concerned,
+   which can include very basic information needed for addressing and
+   routing, as well as anything else that might be configured in a
+   conventional non-autonomic network.  The atomic unit of discovery,
+   synchronization, or negotiation is referred to as a technical
+   objective, i.e., a configurable parameter or set of parameters
+   (defined more precisely in Section 2.1).
+
+   Negotiation is an iterative process, requiring multiple message
+   exchanges forming a closed loop between the negotiating entities.  In
+   fact, these entities are ASAs, normally but not necessarily in
+   different network devices.  State synchronization, when needed, can
+   be regarded as a special case of negotiation without iteration.  Both
+   negotiation and synchronization must logically follow discovery.
+   More details of the requirements are found in Appendix B.
+   Section 2.3 describes a behavior model for a protocol intended to
+   support discovery, synchronization, and negotiation.  The design of
+   GeneRic Autonomic Signaling Protocol (GRASP) in Section 2 is based on
+   this behavior model.  The relevant capabilities of various existing
+   protocols are reviewed in Appendix C.
+
+   The proposed discovery mechanism is oriented towards synchronization
+   and negotiation objectives.  It is based on a neighbor discovery
+   process on the local link, but it also supports diversion to peers on
+   other links.  There is no assumption of any particular form of
+   network topology.  When a device starts up with no preconfiguration,
+   it has no knowledge of the topology.  The protocol itself is capable
+   of being used in a small and/or flat network structure such as a
+   small office or home network as well as in a large, professionally
+   managed network.  Therefore, the discovery mechanism needs to be able
+   to allow a device to bootstrap itself without making any prior
+   assumptions about network structure.
+
+   Because GRASP can be used as part of a decision process among
+   distributed devices or between networks, it must run in a secure and
+   strongly authenticated environment.
+
+   In realistic deployments, not all devices will support GRASP.
+   Therefore, some Autonomic Service Agents will directly manage a group
+   of non-autonomic nodes, and other non-autonomic nodes will be managed
+   traditionally.  Such mixed scenarios are not discussed in this
+   specification.
+
+2.  Protocol Overview
+
+2.1.  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
+   BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
+   capitals, as shown here.
+
+   This document uses terminology defined in [RFC7575].
+
+   The following additional terms are used throughout this document:
+
+   Discovery:
+      A process by which an ASA discovers peers according to a specific
+      discovery objective.  The discovery results may be different
+      according to the different discovery objectives.  The discovered
+      peers may later be used as negotiation counterparts or as sources
+      of synchronization data.
+
+   Negotiation:
+      A process by which two ASAs interact iteratively to agree on
+      parameter settings that best satisfy the objectives of both ASAs.
+
+   State Synchronization:
+      A process by which ASAs interact to receive the current state of
+      parameter values stored in other ASAs.  This is a special case of
+      negotiation in which information is sent, but the ASAs do not
+      request their peers to change parameter settings.  All other
+      definitions apply to both negotiation and synchronization.
+
+   Technical Objective (usually abbreviated as Objective):
+      A technical objective is a data structure whose main contents are
+      a name and a value.  The value consists of a single configurable
+      parameter or a set of parameters of some kind.  The exact format
+      of an objective is defined in Section 2.10.1.  An objective occurs
+      in three contexts: discovery, negotiation, and synchronization.
+      Normally, a given objective will not occur in negotiation and
+      synchronization contexts simultaneously.
+
+         One ASA may support multiple independent objectives.
+
+         The parameter(s) in the value of a given objective apply to a
+         specific service or function or action.  They may in principle
+         be anything that can be set to a specific logical, numerical,
+         or string value, or a more complex data structure, by a network
+         node.  Each node is expected to contain one or more ASAs which
+         may each manage subsidiary non-autonomic nodes.
+
+         Discovery Objective:  an objective in the process of discovery.
+            Its value may be undefined.
+
+         Synchronization Objective:  an objective whose specific
+            technical content needs to be synchronized among two or more
+            ASAs.  Thus, each ASA will maintain its own copy of the
+            objective.
+
+         Negotiation Objective:  an objective whose specific technical
+            content needs to be decided in coordination with another
+            ASA.  Again, each ASA will maintain its own copy of the
+            objective.
+
+         A detailed discussion of objectives, including their format, is
+         found in Section 2.10.
+
+   Discovery Initiator:
+      An ASA that starts discovery by sending a Discovery message
+      referring to a specific discovery objective.
+
+   Discovery Responder:
+      A peer that either contains an ASA supporting the discovery
+      objective indicated by the discovery initiator or caches the
+      locator(s) of the ASA(s) supporting the objective.  It sends a
+      Discovery Response, as described later.
+
+   Synchronization Initiator:
+      An ASA that starts synchronization by sending a request message
+      referring to a specific synchronization objective.
+
+   Synchronization Responder:
+      A peer ASA that responds with the value of a synchronization
+      objective.
+
+   Negotiation Initiator:
+      An ASA that starts negotiation by sending a request message
+      referring to a specific negotiation objective.
+
+   Negotiation Counterpart:
+      A peer with which the negotiation initiator negotiates a specific
+      negotiation objective.
+
+   GRASP Instance:
+      This refers to an instantiation of a GRASP protocol engine, likely
+      including multiple threads or processes as well as dynamic data
+      structures such as a discovery cache, running in a given security
+      environment on a single device.
+
+   GRASP Core:
+      This refers to the code and shared data structures of a GRASP
+      instance, which will communicate with individual ASAs via a
+      suitable Application Programming Interface (API).
+
+   Interface or GRASP Interface:
+      Unless otherwise stated, this refers to a network interface, which
+      might be physical or virtual, that a specific instance of GRASP is
+      currently using.  A device might have other interfaces that are
+      not used by GRASP and which are outside the scope of the Autonomic
+      Network.
+
+2.2.  High-Level Deployment Model
+
+   A GRASP implementation will be part of the Autonomic Networking
+   Infrastructure (ANI) in an autonomic node, which must also provide an
+   appropriate security environment.  In accordance with [RFC8993], this
+   SHOULD be the Autonomic Control Plane (ACP) [RFC8994].  As a result,
+   all autonomic nodes in the ACP are able to trust each other.  It is
+   expected that GRASP will access the ACP by using a typical socket
+   programming interface, and the ACP will make available only network
+   interfaces within the Autonomic Network.  If there is no ACP, the
+   considerations described in Section 2.5.1 apply.
+
+   There will also be one or more Autonomic Service Agents (ASAs).  In
+   the minimal case of a single-purpose device, these components might
+   be fully integrated with GRASP and the ACP.  A more common model is
+   expected to be a multipurpose device capable of containing several
+   ASAs, such as a router or large switch.  In this case it is expected
+   that the ACP, GRASP and the ASAs will be implemented as separate
+   processes, which are able to support asynchronous and simultaneous
+   operations, for example by multithreading.
+
+   In some scenarios, a limited negotiation model might be deployed
+   based on a limited trust relationship such as that between two
+   administrative domains.  ASAs might then exchange limited information
+   and negotiate some particular configurations.
+
+   GRASP is explicitly designed to operate within a single addressing
+   realm.  Its discovery and flooding mechanisms do not support
+   autonomic operations that cross any form of address translator or
+   upper-layer proxy.
+
+   A suitable Application Programming Interface (API) will be needed
+   between GRASP and the ASAs.  In some implementations, ASAs would run
+   in user space with a GRASP library providing the API, and this
+   library would in turn communicate via system calls with core GRASP
+   functions.  Details of the API are out of scope for the present
+   document.  For further details of possible deployment models, see
+   [RFC8993].
+
+   An instance of GRASP must be aware of the network interfaces it will
+   use, and of the appropriate global-scope and link-local addresses.
+   In the presence of the ACP, such information will be available from
+   the adjacency table discussed in [RFC8993].  In other cases, GRASP
+   must determine such information for itself.  Details depend on the
+   device and operating system.  In the rest of this document, the terms
+   'interfaces' or 'GRASP interfaces' refers only to the set of network
+   interfaces that a specific instance of GRASP is currently using.
+
+   Because GRASP needs to work with very high reliability, especially
+   during bootstrapping and during fault conditions, it is essential
+   that every implementation continues to operate in adverse conditions.
+   For example, discovery failures, or any kind of socket exception at
+   any time, must not cause irrecoverable failures in GRASP itself, and
+   must return suitable error codes through the API so that ASAs can
+   also recover.
+
+   GRASP must not depend upon nonvolatile data storage.  All runtime
+   error conditions, and events such as address renumbering, network
+   interface failures, and CPU sleep/wake cycles, must be handled in
+   such a way that GRASP will still operate correctly and securely
+   afterwards (Section 2.5.1).
+
+   An autonomic node will normally run a single instance of GRASP, which
+   is used by multiple ASAs.  Possible exceptions are mentioned below.
+
+2.3.  High-Level Design
+
+   This section describes the behavior model and general design of
+   GRASP, supporting discovery, synchronization, and negotiation, to act
+   as a platform for different technical objectives.
+
+   A generic platform:
+      The protocol design is generic and independent of the
+      synchronization or negotiation contents.  The technical contents
+      will vary according to the various technical objectives and the
+      different pairs of counterparts.
+
+   Multiple instances:
+      Normally, a single main instance of the GRASP protocol engine will
+      exist in an autonomic node, and each ASA will run as an
+      independent asynchronous process.  However, scenarios where
+      multiple instances of GRASP run in a single node, perhaps with
+      different security properties, are possible (Section 2.5.2).  In
+      this case, each instance MUST listen independently for GRASP link-
+      local multicasts, and all instances MUST be woken by each such
+      multicast in order for discovery and flooding to work correctly.
+
+   Security infrastructure:
+      As noted above, the protocol itself has no built-in security
+      functionality and relies on a separate secure infrastructure.
+
+   Discovery, synchronization, and negotiation are designed together:
+      The discovery method and the synchronization and negotiation
+      methods are designed in the same way and can be combined when this
+      is useful, allowing a rapid mode of operation described in
+      Section 2.5.4.  These processes can also be performed
+      independently when appropriate.
+
+         Thus, for some objectives, especially those concerned with
+         application-layer services, another discovery mechanism such as
+         DNS-based Service Discovery [RFC7558] MAY be used.  The choice
+         is left to the designers of individual ASAs.
+
+   A uniform pattern for technical objectives:
+      The synchronization and negotiation objectives are defined
+      according to a uniform pattern.  The values that they contain
+      could be carried either in a simple binary format or in a complex
+      object format.  The basic protocol design uses the Concise Binary
+      Object Representation (CBOR) [RFC8949], which is readily
+      extensible for unknown, future requirements.
+
+   A flexible model for synchronization:
+      GRASP supports synchronization between two nodes, which could be
+      used repeatedly to perform synchronization among a small number of
+      nodes.  It also supports an unsolicited flooding mode when large
+      groups of nodes, possibly including all autonomic nodes, need data
+      for the same technical objective.
+
+         There may be some network parameters for which a more
+         traditional flooding mechanism such as the Distributed Node
+         Consensus Protocol (DNCP) [RFC7787] is considered more
+         appropriate.  GRASP can coexist with DNCP.
+
+   A simple initiator/responder model for negotiation:
+      Multiparty negotiations are very complicated to model and cannot
+      readily be guaranteed to converge.  GRASP uses a simple bilateral
+      model and can support multiparty negotiations by indirect steps.
+
+   Organizing of synchronization or negotiation content:
+      The technical content transmitted by GRASP will be organized
+      according to the relevant function or service.  The objectives for
+      different functions or services are kept separate because they may
+      be negotiated or synchronized with different counterparts or have
+      different response times.  Thus a normal arrangement is a single
+      ASA managing a small set of closely related objectives, with a
+      version of that ASA in each relevant autonomic node.  Further
+      discussion of this aspect is out of scope for the current
+      document.
+
+   Requests and responses in negotiation procedures:
+      The initiator can negotiate a specific negotiation objective with
+      relevant counterpart ASAs.  It can request relevant information
+      from a counterpart so that it can coordinate its local
+      configuration.  It can request the counterpart to make a matching
+      configuration.  It can request simulation or forecast results by
+      sending some dry-run conditions.
+
+      Beyond the traditional yes/no answer, the responder can reply with
+      a suggested alternative value for the objective concerned.  This
+      would start a bidirectional negotiation ending in a compromise
+      between the two ASAs.
+
+   Convergence of negotiation procedures:
+      To enable convergence when a responder suggests a new value or
+      condition in a negotiation step reply, it should be as close as
+      possible to the original request or previous suggestion.  The
+      suggested value of later negotiation steps should be chosen
+      between the suggested values from the previous two steps.  GRASP
+      provides mechanisms to guarantee convergence (or failure) in a
+      small number of steps, namely a timeout and a maximum number of
+      iterations.
+
+   Extensibility:
+      GRASP intentionally does not have a version number, and it can be
+      extended by adding new message types and options.  The Invalid
+      message (M_INVALID) will be used to signal that an implementation
+      does not recognize a message or option sent by another
+      implementation.  In normal use, new semantics will be added by
+      defining new synchronization or negotiation objectives.
+
+2.4.  Quick Operating Overview
+
+   An instance of GRASP is expected to run as a separate core module,
+   providing an API (such as [RFC8991]) to interface to various ASAs.
+   These ASAs may operate without special privilege, unless they need it
+   for other reasons (such as configuring IP addresses or manipulating
+   routing tables).
+
+   The GRASP mechanisms used by the ASA are built around GRASP
+   objectives defined as data structures containing administrative
+   information such as the objective's unique name and its current
+   value.  The format and size of the value is not restricted by the
+   protocol, except that it must be possible to serialize it for
+   transmission in CBOR, which is no restriction at all in practice.
+
+   GRASP provides the following mechanisms:
+
+   *  A discovery mechanism (M_DISCOVERY, M_RESPONSE) by which an ASA
+      can discover other ASAs supporting a given objective.
+
+   *  A negotiation request mechanism (M_REQ_NEG) by which an ASA can
+      start negotiation of an objective with a counterpart ASA.  Once a
+      negotiation has started, the process is symmetrical, and there is
+      a negotiation step message (M_NEGOTIATE) for each ASA to use in
+      turn.  Two other functions support negotiating steps (M_WAIT,
+      M_END).
+
+   *  A synchronization mechanism (M_REQ_SYN) by which an ASA can
+      request the current value of an objective from a counterpart ASA.
+      With this, there is a corresponding response function (M_SYNCH)
+      for an ASA that wishes to respond to synchronization requests.
+
+   *  A flood mechanism (M_FLOOD) by which an ASA can cause the current
+      value of an objective to be flooded throughout the Autonomic
+      Network so that any ASA can receive it.  One application of this
+      is to act as an announcement, avoiding the need for discovery of a
+      widely applicable objective.
+
+   Some example messages and simple message flows are provided in
+   Appendix A.
+
+2.5.  GRASP Basic Properties and Mechanisms
+
+2.5.1.  Required External Security Mechanism
+
+   GRASP does not specify transport security because it is meant to be
+   adapted to different environments.  Every solution adopting GRASP
+   MUST specify a security and transport substrate used by GRASP in that
+   solution.
+
+   The substrate MUST enforce sending and receiving GRASP messages only
+   between members of a mutually trusted group running GRASP.  Each
+   group member is an instance of GRASP.  The group members are nodes of
+   a connected graph.  The group and graph are created by the security
+   and transport substrate and are called the GRASP domain.  The
+   substrate must support unicast messages between any group members and
+   (link-local) multicast messages between adjacent group members.  It
+   must deny messages between group members and non-group members.  With
+   this model, security is provided by enforcing group membership, but
+   any member of the trusted group can attack the entire network until
+   revoked.
+
+   Substrates MUST use cryptographic member authentication and message
+   integrity for GRASP messages.  This can be end to end or hop by hop
+   across the domain.  The security and transport substrate MUST provide
+   mechanisms to remove untrusted members from the group.
+
+   If the substrate does not mandate and enforce GRASP message
+   encryption, then any service using GRASP in such a solution MUST
+   provide protection and encryption for message elements whose exposure
+   could constitute an attack vector.
+
+   The security and transport substrate for GRASP in the ANI is the ACP.
+   Unless otherwise noted, we assume this security and transport
+   substrate in the remainder of this document.  The ACP does mandate
+   the use of encryption; therefore, GRASP in the ANI can rely on GRASP
+   messages being encrypted.  The GRASP domain is the ACP: all nodes in
+   an autonomic domain connected by encrypted virtual links formed by
+   the ACP.  The ACP uses hop-by-hop security (authentication and
+   encryption) of messages.  Removal of nodes relies on standard PKI
+   certificate revocation or expiry of sufficiently short-lived
+   certificates.  Refer to [RFC8994] for more details.
+
+   As mentioned in Section 2.3, some GRASP operations might be performed
+   across an administrative domain boundary by mutual agreement, without
+   the benefit of an ACP.  Such operations MUST be confined to a
+   separate instance of GRASP with its own copy of all GRASP data
+   structures running across a separate GRASP domain with a security and
+   transport substrate.  In the most simple case, each point-to-point
+   interdomain GRASP peering could be a separate domain, and the
+   security and transport substrate could be built using transport or
+   network-layer security protocols.  This is subject to future
+   specifications.
+
+   An exception to the requirements for the security and transport
+   substrate exists for highly constrained subsets of GRASP meant to
+   support the establishment of a security and transport substrate,
+   described in the following section.
+
+2.5.2.  Discovery Unsolicited Link-Local (DULL) GRASP
+
+   Some services may need to use insecure GRASP discovery, response, and
+   flood messages without being able to use preexisting security
+   associations, for example, as part of discovery for establishing
+   security associations such as a security substrate for GRASP.
+
+   Such operations being intrinsically insecure, they need to be
+   confined to link-local use to minimize the risk of malicious actions.
+   Possible examples include discovery of candidate ACP neighbors
+   [RFC8994], discovery of bootstrap proxies [RFC8995], or perhaps
+   initialization services in networks using GRASP without being fully
+   autonomic (e.g., no ACP).  Such usage MUST be limited to link-local
+   operations on a single interface and MUST be confined to a separate
+   insecure instance of GRASP with its own copy of all GRASP data
+   structures.  This instance is nicknamed DULL -- Discovery Unsolicited
+   Link-Local.
+
+   The detailed rules for the DULL instance of GRASP are as follows:
+
+   *  An initiator MAY send Discovery or Flood Synchronization link-
+      local multicast messages that MUST have a loop count of 1, to
+      prevent off-link operations.  Other unsolicited GRASP message
+      types MUST NOT be sent.
+
+   *  A responder MUST silently discard any message whose loop count is
+      not 1.
+
+   *  A responder MUST silently discard any message referring to a GRASP
+      objective that is not directly part of a service that requires
+      this insecure mode.
+
+   *  A responder MUST NOT relay any multicast messages.
+
+   *  A Discovery Response MUST indicate a link-local address.
+
+   *  A Discovery Response MUST NOT include a Divert option.
+
+   *  A node MUST silently discard any message whose source address is
+      not link-local.
+
+   To minimize traffic possibly observed by third parties, GRASP traffic
+   SHOULD be minimized by using only Flood Synchronization to announce
+   objectives and their associated locators, rather than by using
+   Discovery and Discovery Response messages.  Further details are out
+   of scope for this document.
+
+2.5.3.  Transport Layer Usage
+
+   All GRASP messages, after they are serialized as a CBOR byte string,
+   are transmitted as such directly over the transport protocol in use.
+   The transport protocol(s) for a GRASP domain are specified by the
+   security and transport substrate as introduced in Section 2.5.1.
+
+   GRASP discovery and flooding messages are designed for GRASP domain-
+   wide flooding through hop-by-hop link-local multicast forwarding
+   between adjacent GRASP nodes.  The GRASP security and transport
+   substrate needs to specify how these link-local multicasts are
+   transported.  This can be unreliable transport (UDP) but it SHOULD be
+   reliable transport (e.g., TCP).
+
+   If the substrate specifies an unreliable transport such as UDP for
+   discovery and flooding messages, then it MUST NOT use IP
+   fragmentation because of its loss characteristic, especially in
+   multi-hop flooding.  GRASP MUST then enforce at the user API level a
+   limit to the size of discovery and flooding messages, so that no
+   fragmentation can occur.  For IPv6 transport, this means that the
+   size of those messages' IPv6 packets must be at most 1280 bytes
+   (unless there is a known larger minimum link MTU across the whole
+   GRASP domain).
+
+   All other GRASP messages are unicast between group members of the
+   GRASP domain.  These MUST use a reliable transport protocol because
+   GRASP itself does not provide for error detection, retransmission, or
+   flow control.  Unless otherwise specified by the security and
+   transport substrate, TCP MUST be used.
+
+   The security and transport substrate for GRASP in the ANI is the ACP.
+   Unless otherwise noted, we assume this security and transport
+   substrate in the remainder of this document when describing GRASP's
+   message transport.  In the ACP, TCP is used for GRASP unicast
+   messages.  GRASP discovery and flooding messages also use TCP: these
+   link-local messages are forwarded by replicating them to all adjacent
+   GRASP nodes on the link via TCP connections to those adjacent GRASP
+   nodes.  Because of this, GRASP in the ANI has no limitations on the
+   size of discovery and flooding messages with respect to fragmentation
+   issues.  While the ACP is being built using a DULL instance of GRASP,
+   native UDP multicast is used to discover ACP/GRASP neighbors on
+   links.
+
+   For link-local UDP multicast, GRASP listens to the well-known GRASP
+   Listen Port (Section 2.6).  Transport connections for discovery and
+   flooding on relay nodes must terminate in GRASP instances (e.g.,
+   GRASP ASAs) so that link-local multicast, hop-by-hop flooding of
+   M_DISCOVERY and M_FLOOD messages and hop-by-hop forwarding of
+   M_RESPONSE responses and caching of those responses along the path
+   work correctly.
+
+   Unicast transport connections used for synchronization and
+   negotiation can terminate directly in ASAs that implement objectives;
+   therefore, this traffic does not need to pass through GRASP
+   instances.  For this, the ASA listens on its own dynamically assigned
+   ports, which are communicated to its peers during discovery.
+   Alternatively, the GRASP instance can also terminate the unicast
+   transport connections and pass the traffic from/to the ASA if that is
+   preferable in some implementations (e.g., to better decouple ASAs
+   from network connections).
+
+2.5.4.  Discovery Mechanism and Procedures
+
+2.5.4.1.  Separated Discovery and Negotiation Mechanisms
+
+   Although discovery and negotiation or synchronization are defined
+   together in GRASP, they are separate mechanisms.  The discovery
+   process could run independently from the negotiation or
+   synchronization process.  Upon receiving a Discovery message
+   (Section 2.8.4), the recipient node should return a Discovery
+   Response message in which it either indicates itself as a discovery
+   responder or diverts the initiator towards another more suitable ASA.
+   However, this response may be delayed if the recipient needs to relay
+   the Discovery message onward, as described in Section 2.5.4.4.
+
+   The discovery action (M_DISCOVERY) will normally be followed by a
+   negotiation (M_REQ_NEG) or synchronization (M_REQ_SYN) action.  The
+   discovery results could be utilized by the negotiation protocol to
+   decide which ASA the initiator will negotiate with.
+
+   The initiator of a discovery action for a given objective need not be
+   capable of responding to that objective as a negotiation counterpart,
+   as a synchronization responder, or as source for flooding.  For
+   example, an ASA might perform discovery even if it only wishes to act
+   as a synchronization initiator or negotiation initiator.  Such an ASA
+   does not itself need to respond to Discovery messages.
+
+   It is also entirely possible to use GRASP discovery without any
+   subsequent negotiation or synchronization action.  In this case, the
+   discovered objective is simply used as a name during the discovery
+   process, and any subsequent operations between the peers are outside
+   the scope of GRASP.
+
+2.5.4.2.  Discovery Overview
+
+   A complete discovery process will start with a multicast Discovery
+   message (M_DISCOVERY) on the local link.  On-link neighbors
+   supporting the discovery objective will respond directly with
+   Discovery Response (M_RESPONSE) messages.  A neighbor with multiple
+   interfaces may respond with a cached Discovery Response.  If it has
+   no cached response, it will relay the Discovery message on its other
+   GRASP interfaces.  If a node receiving the relayed Discovery message
+   supports the discovery objective, it will respond to the relayed
+   Discovery message.  If it has a cached response, it will respond with
+   that.  If not, it will repeat the discovery process, which thereby
+   becomes iterative.  The loop count and timeout will ensure that the
+   process ends.  Further details are given in Section 2.5.4.4.
+
+   A Discovery message MAY be sent unicast to a peer node, which SHOULD
+   then proceed exactly as if the message had been multicast, except
+   that when TCP is used, the response will be on the same socket as the
+   query.  However, this mode does not guarantee successful discovery in
+   the general case.
+
+2.5.4.3.  Discovery Procedures
+
+   Discovery starts as an on-link operation.  The Divert option can tell
+   the discovery initiator to contact an off-link ASA for that discovery
+   objective.  If the security and transport substrate of the GRASP
+   domain (see Section 2.5.3) uses UDP link-local multicast, then the
+   discovery initiator sends these to the ALL_GRASP_NEIGHBORS link-local
+   multicast address (Section 2.6), and all GRASP nodes need to listen
+   to this address to act as discovery responders.  Because this port is
+   unique in a device, this is a function of the GRASP instance and not
+   of an individual ASA.  As a result, each ASA will need to register
+   the objectives that it supports with the local GRASP instance.
+
+   If an ASA in a neighbor device supports the requested discovery
+   objective, the device SHOULD respond to the link-local multicast with
+   a unicast Discovery Response message (Section 2.8.5) with locator
+   option(s) (Section 2.9.5) unless it is temporarily unavailable.
+   Otherwise, if the neighbor has cached information about an ASA that
+   supports the requested discovery objective (usually because it
+   discovered the same objective before), it SHOULD respond with a
+   Discovery Response message with a Divert option pointing to the
+   appropriate discovery responder.  However, it SHOULD NOT respond with
+   a cached response on an interface if it learned that information from
+   the same interface because the peer in question will answer directly
+   if still operational.
+
+   If a device has no information about the requested discovery
+   objective and is not acting as a discovery relay (see
+   Section 2.5.4.4), it MUST silently discard the Discovery message.
+
+   The discovery initiator MUST set a reasonable timeout on the
+   discovery process.  A suggested value is 100 milliseconds multiplied
+   by the loop count embedded in the objective.
+
+   If no Discovery Response is received within the timeout, the
+   Discovery message MAY be repeated with a newly generated Session ID
+   (Section 2.7).  An exponential backoff SHOULD be used for subsequent
+   repetitions to limit the load during busy periods.  The details of
+   the backoff algorithm will depend on the use case for the objective
+   concerned but MUST be consistent with the recommendations in
+   [RFC8085] for low data-volume multicast.  Frequent repetition might
+   be symptomatic of a denial-of-service attack.
+
+   After a GRASP device successfully discovers a locator for a discovery
+   responder supporting a specific objective, it SHOULD cache this
+   information, including the interface index [RFC3493] via which it was
+   discovered.  This cache record MAY be used for future negotiation or
+   synchronization, and the locator SHOULD be passed on when appropriate
+   as a Divert option to another discovery initiator.
+
+   The cache mechanism MUST include a lifetime for each entry.  The
+   lifetime is derived from a time-to-live (ttl) parameter in each
+   Discovery Response message.  Cached entries MUST be ignored or
+   deleted after their lifetime expires.  In some environments,
+   unplanned address renumbering might occur.  In such cases, the
+   lifetime SHOULD be short compared to the typical address lifetime.
+   The discovery mechanism needs to track the node's current address to
+   ensure that Discovery Responses always indicate the correct address.
+
+   If multiple discovery responders are found for the same objective,
+   they SHOULD all be cached unless this creates a resource shortage.
+   The method of choosing between multiple responders is an
+   implementation choice.  This choice MUST be available to each ASA,
+   but the GRASP implementation SHOULD provide a default choice.
+
+   Because discovery responders will be cached in a finite cache, they
+   might be deleted at any time.  In this case, discovery will need to
+   be repeated.  If an ASA exits for any reason, its locator might still
+   be cached for some time, and attempts to connect to it will fail.
+   ASAs need to be robust in these circumstances.
+
+2.5.4.4.  Discovery Relaying
+
+   A GRASP instance with multiple link-layer interfaces (typically
+   running in a router) MUST support discovery on all GRASP interfaces.
+   We refer to this as a 'relaying instance'.
+
+   DULL instances (Section 2.5.2) are always single-interface instances
+   and therefore MUST NOT perform discovery relaying.
+
+   If a relaying instance receives a Discovery message on a given
+   interface for a specific objective that it does not support and for
+   which it has not previously cached a discovery responder, it MUST
+   relay the query by reissuing a new Discovery message as a link-local
+   multicast on its other GRASP interfaces.
+
+   The relayed Discovery message MUST have the same Session ID and
+   'initiator' field as the incoming message (see Section 2.8.4).  The
+   IP address in the 'initiator' field is only used to disambiguate the
+   Session ID and is never used to address Response packets.  Response
+   packets are sent back to the relaying instance, not the original
+   initiator.
+
+   The M_DISCOVERY message does not encode the transport address of the
+   originator or relay.  Response packets must therefore be sent to the
+   transport-layer address of the connection on which the M_DISCOVERY
+   message was received.  If the M_DISCOVERY was relayed via a reliable
+   hop-by-hop transport connection, the response is simply sent back via
+   the same connection.
+
+   If the M_DISCOVERY was relayed via link-local (e.g., UDP) multicast,
+   the response is sent back via a reliable hop-by-hop transport
+   connection with the same port number as the source port of the link-
+   local multicast.  Therefore, if link-local multicast is used and
+   M_RESPONSE messages are required (which is the case in almost all
+   GRASP instances except for the limited use of DULL instances in the
+   ANI), GRASP needs to be able to bind to one port number on UDP from
+   which to originate the link-local multicast M_DISCOVERY messages and
+   the same port number on the reliable hop-by-hop transport (e.g., TCP
+   by default) to be able to respond to transport connections from
+   responders that want to send M_RESPONSE messages back.  Note that
+   this port does not need to be the GRASP_LISTEN_PORT.
+
+   The relaying instance MUST decrement the loop count within the
+   objective, and MUST NOT relay the Discovery message if the result is
+   zero.  Also, it MUST limit the total rate at which it relays
+   Discovery messages to a reasonable value in order to mitigate
+   possible denial-of-service attacks.  For example, the rate limit
+   could be set to a small multiple of the observed rate of Discovery
+   messages during normal operation.  The relaying instance MUST cache
+   the Session ID value and initiator address of each relayed Discovery
+   message until any Discovery Responses have arrived or the discovery
+   process has timed out.  To prevent loops, it MUST NOT relay a
+   Discovery message that carries a given cached Session ID and
+   initiator address more than once.  These precautions avoid discovery
+   loops and mitigate potential overload.
+
+   Since the relay device is unaware of the timeout set by the original
+   initiator, it SHOULD set a suitable timeout for the relayed Discovery
+   message.  A suggested value is 100 milliseconds multiplied by the
+   remaining loop count.
+
+   The discovery results received by the relaying instance MUST in turn
+   be sent as a Discovery Response message to the Discovery message that
+   caused the relay action.
+
+2.5.4.5.  Rapid Mode (Discovery with Negotiation or Synchronization)
+
+   A Discovery message MAY include an objective option.  This allows a
+   rapid mode of negotiation (Section 2.5.5.1) or synchronization
+   (Section 2.5.6.3).  Rapid mode is currently limited to a single
+   objective for simplicity of design and implementation.  A possible
+   future extension is to allow multiple objectives in rapid mode for
+   greater efficiency.
+
+2.5.5.  Negotiation Procedures
+
+   A negotiation initiator opens a transport connection to a counterpart
+   ASA using the address, protocol, and port obtained during discovery.
+   It then sends a negotiation request (using M_REQ_NEG) to the
+   counterpart, including a specific negotiation objective.  It may
+   request the negotiation counterpart to make a specific configuration.
+   Alternatively, it may request a certain simulation or forecast result
+   by sending a dry-run configuration.  The details, including the
+   distinction between a dry run and a live configuration change, will
+   be defined separately for each type of negotiation objective.  Any
+   state associated with a dry-run operation, such as temporarily
+   reserving a resource for subsequent use in a live run, is entirely a
+   matter for the designer of the ASA concerned.
+
+   Each negotiation session as a whole is subject to a timeout (default
+   GRASP_DEF_TIMEOUT milliseconds, Section 2.6), initialized when the
+   request is sent (see Section 2.8.6).  If no reply message of any kind
+   is received within the timeout, the negotiation request MAY be
+   repeated with a newly generated Session ID (Section 2.7).  An
+   exponential backoff SHOULD be used for subsequent repetitions.  The
+   details of the backoff algorithm will depend on the use case for the
+   objective concerned.
+
+   If the counterpart can immediately apply the requested configuration,
+   it will give an immediate positive (O_ACCEPT) answer using the
+   Negotiation End (M_END) message.  This will end the negotiation phase
+   immediately.  Otherwise, it will negotiate (using M_NEGOTIATE).  It
+   will reply with a proposed alternative configuration that it can
+   apply (typically, a configuration that uses fewer resources than
+   requested by the negotiation initiator).  This will start a
+   bidirectional negotiation using the Negotiate (M_NEGOTIATE) message
+   to reach a compromise between the two ASAs.
+
+   The negotiation procedure is ended when one of the negotiation peers
+   sends a Negotiation End (M_END) message, which contains an Accept
+   (O_ACCEPT) or Decline (O_DECLINE) option and does not need a response
+   from the negotiation peer.  Negotiation may also end in failure
+   (equivalent to a decline) if a timeout is exceeded or a loop count is
+   exceeded.  When the procedure ends for whatever reason, the transport
+   connection SHOULD be closed.  A transport session failure is treated
+   as a negotiation failure.
+
+   A negotiation procedure concerns one objective and one counterpart.
+   Both the initiator and the counterpart may take part in simultaneous
+   negotiations with various other ASAs or in simultaneous negotiations
+   about different objectives.  Thus, GRASP is expected to be used in a
+   multithreaded mode or its logical equivalent.  Certain negotiation
+   objectives may have restrictions on multithreading, for example to
+   avoid over-allocating resources.
+
+   Some configuration actions, for example, wavelength switching in
+   optical networks, might take considerable time to execute.  The ASA
+   concerned needs to allow for this by design, but GRASP does allow for
+   a peer to insert latency in a negotiation process if necessary
+   (Section 2.8.9, M_WAIT).
+
+2.5.5.1.  Rapid Mode (Discovery/Negotiation Linkage)
+
+   A Discovery message MAY include a Negotiation Objective option.  In
+   this case, it is as if the initiator sent the sequence M_DISCOVERY
+   immediately followed by M_REQ_NEG.  This has implications for the
+   construction of the GRASP core, as it must carefully pass the
+   contents of the Negotiation Objective option to the ASA so that it
+   may evaluate the objective directly.  When a Negotiation Objective
+   option is present, the ASA replies with an M_NEGOTIATE message (or
+   M_END with O_ACCEPT if it is immediately satisfied with the proposal)
+   rather than with an M_RESPONSE.  However, if the recipient node does
+   not support rapid mode, discovery will continue normally.
+
+   It is possible that a Discovery Response will arrive from a responder
+   that does not support rapid mode before such a Negotiation message
+   arrives.  In this case, rapid mode will not occur.
+
+   This rapid mode could reduce the interactions between nodes so that a
+   higher efficiency could be achieved.  However, a network in which
+   some nodes support rapid mode and others do not will have complex
+   timing-dependent behaviors.  Therefore, the rapid negotiation
+   function SHOULD be disabled by default.
+
+2.5.6.  Synchronization and Flooding Procedures
+
+2.5.6.1.  Unicast Synchronization
+
+   A synchronization initiator opens a transport connection to a
+   counterpart ASA using the address, protocol, and port obtained during
+   discovery.  It then sends a Request Synchronization message
+   (M_REQ_SYN, Section 2.8.6) to the counterpart, including a specific
+   synchronization objective.  The counterpart responds with a
+   Synchronization message (M_SYNCH, Section 2.8.10) containing the
+   current value of the requested synchronization objective.  No further
+   messages are needed, and the transport connection SHOULD be closed.
+   A transport session failure is treated as a synchronization failure.
+
+   If no reply message of any kind is received within a given timeout
+   (default GRASP_DEF_TIMEOUT milliseconds, Section 2.6), the
+   synchronization request MAY be repeated with a newly generated
+   Session ID (Section 2.7).  An exponential backoff SHOULD be used for
+   subsequent repetitions.  The details of the backoff algorithm will
+   depend on the use case for the objective concerned.
+
+2.5.6.2.  Flooding
+
+   In the case just described, the message exchange is unicast and
+   concerns only one synchronization objective.  For large groups of
+   nodes requiring the same data, synchronization flooding is available.
+   For this, a flooding initiator MAY send an unsolicited Flood
+   Synchronization message (Section 2.8.11) containing one or more
+   Synchronization Objective option(s), if and only if the specification
+   of those objectives permits it.  This is sent as a multicast message
+   to the ALL_GRASP_NEIGHBORS multicast address (Section 2.6).
+
+   Receiving flood multicasts is a function of the GRASP core, as in the
+   case of discovery multicasts (Section 2.5.4.3).
+
+   To ensure that flooding does not result in a loop, the originator of
+   the Flood Synchronization message MUST set the loop count in the
+   objectives to a suitable value (the default is GRASP_DEF_LOOPCT).
+   Also, a suitable mechanism is needed to avoid excessive multicast
+   traffic.  This mechanism MUST be defined as part of the specification
+   of the synchronization objective(s) concerned.  It might be a simple
+   rate limit or a more complex mechanism such as the Trickle algorithm
+   [RFC6206].
+
+   A GRASP device with multiple link-layer interfaces (typically a
+   router) MUST support synchronization flooding on all GRASP
+   interfaces.  If it receives a multicast Flood Synchronization message
+   on a given interface, it MUST relay it by reissuing a Flood
+   Synchronization message as a link-local multicast on its other GRASP
+   interfaces.  The relayed message MUST have the same Session ID as the
+   incoming message and MUST be tagged with the IP address of its
+   original initiator.
+
+   Link-layer flooding is supported by GRASP by setting the loop count
+   to 1 and sending with a link-local source address.  Floods with link-
+   local source addresses and a loop count other than 1 are invalid, and
+   such messages MUST be discarded.
+
+   The relaying device MUST decrement the loop count within the first
+   objective and MUST NOT relay the Flood Synchronization message if the
+   result is zero.  Also, it MUST limit the total rate at which it
+   relays Flood Synchronization messages to a reasonable value, in order
+   to mitigate possible denial-of-service attacks.  For example, the
+   rate limit could be set to a small multiple of the observed rate of
+   flood messages during normal operation.  The relaying device MUST
+   cache the Session ID value and initiator address of each relayed
+   Flood Synchronization message for a time not less than twice
+   GRASP_DEF_TIMEOUT milliseconds.  To prevent loops, it MUST NOT relay
+   a Flood Synchronization message that carries a given cached Session
+   ID and initiator address more than once.  These precautions avoid
+   synchronization loops and mitigate potential overload.
+
+   Note that this mechanism is unreliable in the case of sleeping nodes,
+   or new nodes that join the network, or nodes that rejoin the network
+   after a fault.  An ASA that initiates a flood SHOULD repeat the flood
+   at a suitable frequency, which MUST be consistent with the
+   recommendations in [RFC8085] for low data-volume multicast.  The ASA
+   SHOULD also act as a synchronization responder for the objective(s)
+   concerned.  Thus nodes that require an objective subject to flooding
+   can either wait for the next flood or request unicast synchronization
+   for that objective.
+
+   The multicast messages for synchronization flooding are subject to
+   the security rules in Section 2.5.1.  In practice, this means that
+   they MUST NOT be transmitted and MUST be ignored on receipt unless
+   there is an operational ACP or equivalent strong security in place.
+   However, because of the security weakness of link-local multicast
+   (Section 3), synchronization objectives that are flooded SHOULD NOT
+   contain unencrypted private information and SHOULD be validated by
+   the recipient ASA.
+
+2.5.6.3.  Rapid Mode (Discovery/Synchronization Linkage)
+
+   A Discovery message MAY include a Synchronization Objective option.
+   In this case, the Discovery message also acts as a Request
+   Synchronization message to indicate to the discovery responder that
+   it could directly reply to the discovery initiator with a
+   Synchronization message (Section 2.8.10) with synchronization data
+   for rapid processing, if the discovery target supports the
+   corresponding synchronization objective.  The design implications are
+   similar to those discussed in Section 2.5.5.1.
+
+   It is possible that a Discovery Response will arrive from a responder
+   that does not support rapid mode before such a Synchronization
+   message arrives.  In this case, rapid mode will not occur.
+
+   This rapid mode could reduce the interactions between nodes so that a
+   higher efficiency could be achieved.  However, a network in which
+   some nodes support rapid mode and others do not will have complex
+   timing-dependent behaviors.  Therefore, the rapid synchronization
+   function SHOULD be configured off by default and MAY be configured on
+   or off by Intent.
+
+2.6.  GRASP Constants
+
+   ALL_GRASP_NEIGHBORS
+      A link-local scope multicast address used by a GRASP-enabled
+      device to discover GRASP-enabled neighbor (i.e., on-link) devices.
+      All devices that support GRASP are members of this multicast
+      group.
+
+      *  IPv6 multicast address: ff02::13
+
+      *  IPv4 multicast address: 224.0.0.119
+
+   GRASP_LISTEN_PORT (7017)
+      A well-known UDP user port that every GRASP-enabled network device
+      MUST listen to for link-local multicasts when UDP is used for
+      M_DISCOVERY or M_FLOOD messages in the GRASP instance.  This user
+      port MAY also be used to listen for TCP or UDP unicast messages in
+      a simple implementation of GRASP (Section 2.5.3).
+
+   GRASP_DEF_TIMEOUT (60000 milliseconds)
+      The default timeout used to determine that an operation has failed
+      to complete.
+
+   GRASP_DEF_LOOPCT (6)
+      The default loop count used to determine that a negotiation has
+      failed to complete and to avoid looping messages.
+
+   GRASP_DEF_MAX_SIZE (2048)
+      The default maximum message size in bytes.
+
+2.7.  Session Identifier (Session ID)
+
+   This is an up to 32-bit opaque value used to distinguish multiple
+   sessions between the same two devices.  A new Session ID MUST be
+   generated by the initiator for every new Discovery, Flood
+   Synchronization, or Request message.  All responses and follow-up
+   messages in the same discovery, synchronization, or negotiation
+   procedure MUST carry the same Session ID.
+
+   The Session ID SHOULD have a very low collision rate locally.  It
+   MUST be generated by a pseudorandom number generator (PRNG) using a
+   locally generated seed that is unlikely to be used by any other
+   device in the same network.  The PRNG SHOULD be cryptographically
+   strong [RFC4086].  When allocating a new Session ID, GRASP MUST check
+   that the value is not already in use and SHOULD check that it has not
+   been used recently by consulting a cache of current and recent
+   sessions.  In the unlikely event of a clash, GRASP MUST generate a
+   new value.
+
+   However, there is a finite probability that two nodes might generate
+   the same Session ID value.  For that reason, when a Session ID is
+   communicated via GRASP, the receiving node MUST tag it with the
+   initiator's IP address to allow disambiguation.  In the highly
+   unlikely event of two peers opening sessions with the same Session ID
+   value, this tag will allow the two sessions to be distinguished.
+   Multicast GRASP messages and their responses, which may be relayed
+   between links, therefore include a field that carries the initiator's
+   global IP address.
+
+   There is a highly unlikely race condition in which two peers start
+   simultaneous negotiation sessions with each other using the same
+   Session ID value.  Depending on various implementation choices, this
+   might lead to the two sessions being confused.  See Section 2.8.6 for
+   details of how to avoid this.
+
+2.8.  GRASP Messages
+
+2.8.1.  Message Overview
+
+   This section defines the GRASP message format and message types.
+   Message types not listed here are reserved for future use.
+
+   The messages currently defined are:
+
+      Discovery and Discovery Response (M_DISCOVERY, M_RESPONSE).
+
+      Request Negotiation, Negotiation, Confirm Waiting, and Negotiation
+      End (M_REQ_NEG, M_NEGOTIATE, M_WAIT, M_END).
+
+      Request Synchronization, Synchronization, and Flood
+      Synchronization (M_REQ_SYN, M_SYNCH, M_FLOOD).
+
+      No Operation and Invalid (M_NOOP, M_INVALID).
+
+2.8.2.  GRASP Message Format
+
+   GRASP messages share an identical header format and a variable format
+   area for options.  GRASP message headers and options are transmitted
+   in Concise Binary Object Representation (CBOR) [RFC8949].  In this
+   specification, they are described using Concise Data Definition
+   Language (CDDL) [RFC8610].  Fragmentary CDDL is used to describe each
+   item in this section.  A complete and normative CDDL specification of
+   GRASP is given in Section 4, including constants such as message
+   types.
+
+   Every GRASP message, except the No Operation message, carries a
+   Session ID (Section 2.7).  Options are then presented serially.
+
+   In fragmentary CDDL, every GRASP message follows the pattern:
+
+     grasp-message = (message .within message-structure) / noop-message
+
+     message-structure = [MESSAGE_TYPE, session-id, ?initiator,
+                          *grasp-option]
+
+     MESSAGE_TYPE = 0..255
+     session-id = 0..4294967295 ; up to 32 bits
+     grasp-option = any
+
+   The MESSAGE_TYPE indicates the type of the message and thus defines
+   the expected options.  Any options received that are not consistent
+   with the MESSAGE_TYPE SHOULD be silently discarded.
+
+   The No Operation (noop) message is described in Section 2.8.13.
+
+   The various MESSAGE_TYPE values are defined in Section 4.
+
+   All other message elements are described below and formally defined
+   in Section 4.
+
+   If an unrecognized MESSAGE_TYPE is received in a unicast message, an
+   Invalid message (Section 2.8.12) MAY be returned.  Otherwise, the
+   message MAY be logged and MUST be discarded.  If an unrecognized
+   MESSAGE_TYPE is received in a multicast message, it MAY be logged and
+   MUST be silently discarded.
+
+2.8.3.  Message Size
+
+   GRASP nodes MUST be able to receive unicast messages of at least
+   GRASP_DEF_MAX_SIZE bytes.  GRASP nodes MUST NOT send unicast messages
+   longer than GRASP_DEF_MAX_SIZE bytes unless a longer size is
+   explicitly allowed for the objective concerned.  For example, GRASP
+   negotiation itself could be used to agree on a longer message size.
+
+   The message parser used by GRASP should be configured to know about
+   the GRASP_DEF_MAX_SIZE, or any larger negotiated message size, so
+   that it may defend against overly long messages.
+
+   The maximum size of multicast messages (M_DISCOVERY and M_FLOOD)
+   depends on the link-layer technology or the link-adaptation layer in
+   use.
+
+2.8.4.  Discovery Message
+
+   In fragmentary CDDL, a Discovery message follows the pattern:
+
+     discovery-message = [M_DISCOVERY, session-id, initiator, objective]
+
+   A discovery initiator sends a Discovery message to initiate a
+   discovery process for a particular objective option.
+
+   The discovery initiator sends all Discovery messages via UDP to port
+   GRASP_LISTEN_PORT at the link-local ALL_GRASP_NEIGHBORS multicast
+   address on each link-layer interface in use by GRASP.  It then
+   listens for unicast TCP responses on a given port and stores the
+   discovery results, including responding discovery objectives and
+   corresponding unicast locators.
+
+   The listening port used for TCP MUST be the same port as used for
+   sending the Discovery UDP multicast, on a given interface.  In an
+   implementation with a single GRASP instance in a node, this MAY be
+   GRASP_LISTEN_PORT.  To support multiple instances in the same node,
+   the GRASP discovery mechanism in each instance needs to find, for
+   each interface, a dynamic port that it can bind to for both sending
+   UDP link-local multicast and listening for TCP before initiating any
+   discovery.
+
+   The 'initiator' field in the message is a globally unique IP address
+   of the initiator for the sole purpose of disambiguating the Session
+   ID in other nodes.  If for some reason the initiator does not have a
+   globally unique IP address, it MUST use a link-local address that is
+   highly likely to be unique for this purpose, for example, using
+   [RFC7217].  Determination of a node's globally unique IP address is
+   implementation dependent.
+
+   A Discovery message MUST include exactly one of the following:
+
+   *  A Discovery Objective option (Section 2.10.1).  Its loop count
+      MUST be set to a suitable value to prevent discovery loops
+      (default value is GRASP_DEF_LOOPCT).  If the discovery initiator
+      requires only on-link responses, the loop count MUST be set to 1.
+
+   *  A Negotiation Objective option (Section 2.10.1).  This is used
+      both for the purpose of discovery and to indicate to the discovery
+      target that it MAY directly reply to the discovery initiator with
+      a Negotiation message for rapid processing, if it could act as the
+      corresponding negotiation counterpart.  The sender of such a
+      Discovery message MUST initialize a negotiation timer and loop
+      count in the same way as a Request Negotiation message
+      (Section 2.8.6).
+
+   *  A Synchronization Objective option (Section 2.10.1).  This is used
+      both for the purpose of discovery and to indicate to the discovery
+      target that it MAY directly reply to the discovery initiator with
+      a Synchronization message for rapid processing, if it could act as
+      the corresponding synchronization counterpart.  Its loop count
+      MUST be set to a suitable value to prevent discovery loops
+      (default value is GRASP_DEF_LOOPCT).
+
+   As mentioned in Section 2.5.4.2, a Discovery message MAY be sent
+   unicast to a peer node, which SHOULD then proceed exactly as if the
+   message had been multicast.
+
+2.8.5.  Discovery Response Message
+
+   In fragmentary CDDL, a Discovery Response message follows the
+   pattern:
+
+     response-message = [M_RESPONSE, session-id, initiator, ttl,
+                         (+locator-option // divert-option), ?objective]
+
+     ttl = 0..4294967295 ; in milliseconds
+
+   A node that receives a Discovery message SHOULD send a Discovery
+   Response message if and only if it can respond to the discovery.
+
+      It MUST contain the same Session ID and initiator as the Discovery
+      message.
+
+      It MUST contain a time-to-live (ttl) for the validity of the
+      response, given as a positive integer value in milliseconds.  Zero
+      implies a value significantly greater than GRASP_DEF_TIMEOUT
+      milliseconds (Section 2.6).  A suggested value is ten times that
+      amount.
+
+      It MAY include a copy of the discovery objective from the
+      Discovery message.
+
+   It is sent to the sender of the Discovery message via TCP at the port
+   used to send the Discovery message (as explained in Section 2.8.4).
+   In the case of a relayed Discovery message, the Discovery Response is
+   thus sent to the relay, not the original initiator.
+
+   In all cases, the transport session SHOULD be closed after sending
+   the Discovery Response.  A transport session failure is treated as no
+   response.
+
+   If the responding node supports the discovery objective of the
+   discovery, it MUST include at least one kind of locator option
+   (Section 2.9.5) to indicate its own location.  A sequence of multiple
+   kinds of locator options (e.g., IP address option and FQDN option) is
+   also valid.
+
+   If the responding node itself does not support the discovery
+   objective, but it knows the locator of the discovery objective, then
+   it SHOULD respond to the Discovery message with a Divert option
+   (Section 2.9.2) embedding a locator option or a combination of
+   multiple kinds of locator options that indicate the locator(s) of the
+   discovery objective.
+
+   More details on the processing of Discovery Responses are given in
+   Section 2.5.4.
+
+2.8.6.  Request Messages
+
+   In fragmentary CDDL, Request Negotiation and Request Synchronization
+   messages follow the patterns:
+
+   request-negotiation-message = [M_REQ_NEG, session-id, objective]
+
+   request-synchronization-message = [M_REQ_SYN, session-id, objective]
+
+   A negotiation or synchronization requesting node sends the
+   appropriate Request message to the unicast address of the negotiation
+   or synchronization counterpart, using the appropriate protocol and
+   port numbers (selected from the discovery result).  If the discovery
+   result is an FQDN, it will be resolved first.
+
+   A Request message MUST include the relevant objective option.  In the
+   case of Request Negotiation, the objective option MUST include the
+   requested value.
+
+   When an initiator sends a Request Negotiation message, it MUST
+   initialize a negotiation timer for the new negotiation thread.  The
+   default is GRASP_DEF_TIMEOUT milliseconds.  Unless this timeout is
+   modified by a Confirm Waiting message (Section 2.8.9), the initiator
+   will consider that the negotiation has failed when the timer expires.
+
+   Similarly, when an initiator sends a Request Synchronization, it
+   SHOULD initialize a synchronization timer.  The default is
+   GRASP_DEF_TIMEOUT milliseconds.  The initiator will consider that
+   synchronization has failed if there is no response before the timer
+   expires.
+
+   When an initiator sends a Request message, it MUST initialize the
+   loop count of the objective option with a value defined in the
+   specification of the option or, if no such value is specified, with
+   GRASP_DEF_LOOPCT.
+
+   If a node receives a Request message for an objective for which no
+   ASA is currently listening, it MUST immediately close the relevant
+   socket to indicate this to the initiator.  This is to avoid
+   unnecessary timeouts if, for example, an ASA exits prematurely but
+   the GRASP core is listening on its behalf.
+
+   To avoid the highly unlikely race condition in which two nodes
+   simultaneously request sessions with each other using the same
+   Session ID (Section 2.7), a node MUST verify that the received
+   Session ID is not already locally active when it receives a Request
+   message.  In case of a clash, it MUST discard the Request message, in
+   which case the initiator will detect a timeout.
+
+2.8.7.  Negotiation Message
+
+   In fragmentary CDDL, a Negotiation message follows the pattern:
+
+     negotiation-message = [M_NEGOTIATE, session-id, objective]
+
+   A negotiation counterpart sends a Negotiation message in response to
+   a Request Negotiation message, a Negotiation message, or a Discovery
+   message in rapid mode.  A negotiation process MAY include multiple
+   steps.
+
+   The Negotiation message MUST include the relevant Negotiation
+   Objective option, with its value updated according to progress in the
+   negotiation.  The sender MUST decrement the loop count by 1.  If the
+   loop count becomes zero, the message MUST NOT be sent.  In this case,
+   the negotiation session has failed and will time out.
+
+2.8.8.  Negotiation End Message
+
+   In fragmentary CDDL, a Negotiation End message follows the pattern:
+
+     end-message = [M_END, session-id, accept-option / decline-option]
+
+   A negotiation counterpart sends a Negotiation End message to close
+   the negotiation.  It MUST contain either an Accept option or a
+   Decline option, defined in Section 2.9.3 and Section 2.9.4.  It could
+   be sent either by the requesting node or the responding node.
+
+2.8.9.  Confirm Waiting Message
+
+   In fragmentary CDDL, a Confirm Waiting message follows the pattern:
+
+     wait-message = [M_WAIT, session-id, waiting-time]
+     waiting-time = 0..4294967295 ; in milliseconds
+
+   A responding node sends a Confirm Waiting message to ask the
+   requesting node to wait for a further negotiation response.  It might
+   be that the local process needs more time or that the negotiation
+   depends on another triggered negotiation.  This message MUST NOT
+   include any other options.  When received, the waiting time value
+   overwrites and restarts the current negotiation timer
+   (Section 2.8.6).
+
+   The responding node SHOULD send a Negotiation, Negotiation End, or
+   another Confirm Waiting message before the negotiation timer expires.
+   If not, when the initiator's timer expires, the initiator MUST treat
+   the negotiation procedure as failed.
+
+2.8.10.  Synchronization Message
+
+   In fragmentary CDDL, a Synchronization message follows the pattern:
+
+     synch-message = [M_SYNCH, session-id, objective]
+
+   A node that receives a Request Synchronization, or a Discovery
+   message in rapid mode, sends back a unicast Synchronization message
+   with the synchronization data, in the form of a GRASP option for the
+   specific synchronization objective present in the Request
+   Synchronization.
+
+2.8.11.  Flood Synchronization Message
+
+   In fragmentary CDDL, a Flood Synchronization message follows the
+   pattern:
+
+     flood-message = [M_FLOOD, session-id, initiator, ttl,
+                      +[objective, (locator-option / [])]]
+
+     ttl = 0..4294967295 ; in milliseconds
+
+   A node MAY initiate flooding by sending an unsolicited Flood
+   Synchronization message with synchronization data.  This MAY be sent
+   to port GRASP_LISTEN_PORT at the link-local ALL_GRASP_NEIGHBORS
+   multicast address, in accordance with the rules in Section 2.5.6.
+
+      The initiator address is provided, as described for Discovery
+      messages (Section 2.8.4), only to disambiguate the Session ID.
+
+      The message MUST contain a time-to-live (ttl) for the validity of
+      the contents, given as a positive integer value in milliseconds.
+      There is no default; zero indicates an indefinite lifetime.
+
+      The synchronization data are in the form of GRASP option(s) for
+      specific synchronization objective(s).  The loop count(s) MUST be
+      set to a suitable value to prevent flood loops (default value is
+      GRASP_DEF_LOOPCT).
+
+      Each objective option MAY be followed by a locator option
+      (Section 2.9.5) associated with the flooded objective.  In its
+      absence, an empty option MUST be included to indicate a null
+      locator.
+
+   A node that receives a Flood Synchronization message MUST cache the
+   received objectives for use by local ASAs.  Each cached objective
+   MUST be tagged with the locator option sent with it, or with a null
+   tag if an empty locator option was sent.  If a subsequent Flood
+   Synchronization message carries an objective with the same name and
+   the same tag, the corresponding cached copy of the objective MUST be
+   overwritten.  If a subsequent Flood Synchronization message carrying
+   an objective with same name arrives with a different tag, a new
+   cached entry MUST be created.
+
+   Note: the purpose of this mechanism is to allow the recipient of
+   flooded values to distinguish between different senders of the same
+   objective, and if necessary communicate with them using the locator,
+   protocol, and port included in the locator option.  Many objectives
+   will not need this mechanism, so they will be flooded with a null
+   locator.
+
+   Cached entries MUST be ignored or deleted after their lifetime
+   expires.
+
+2.8.12.  Invalid Message
+
+   In fragmentary CDDL, an Invalid message follows the pattern:
+
+     invalid-message = [M_INVALID, session-id, ?any]
+
+   This message MAY be sent by an implementation in response to an
+   incoming unicast message that it considers invalid.  The Session ID
+   value MUST be copied from the incoming message.  The content SHOULD
+   be diagnostic information such as a partial copy of the invalid
+   message up to the maximum message size.  An M_INVALID message MAY be
+   silently ignored by a recipient.  However, it could be used in
+   support of extensibility, since it indicates that the remote node
+   does not support a new or obsolete message or option.
+
+   An M_INVALID message MUST NOT be sent in response to an M_INVALID
+   message.
+
+2.8.13.  No Operation Message
+
+   In fragmentary CDDL, a No Operation message follows the pattern:
+
+     noop-message = [M_NOOP]
+
+   This message MAY be sent by an implementation that for practical
+   reasons needs to initialize a socket.  It MUST be silently ignored by
+   a recipient.
+
+2.9.  GRASP Options
+
+   This section defines the GRASP options for the negotiation and
+   synchronization protocol signaling.  Additional options may be
+   defined in the future.
+
+2.9.1.  Format of GRASP Options
+
+   GRASP options SHOULD be CBOR arrays that MUST start with an unsigned
+   integer identifying the specific option type carried in this option.
+   These option types are formally defined in Section 4.
+
+   GRASP options may be defined to include encapsulated GRASP options.
+
+2.9.2.  Divert Option
+
+   The Divert option is used to redirect a GRASP request to another
+   node, which may be more appropriate for the intended negotiation or
+   synchronization.  It may redirect to an entity that is known as a
+   specific negotiation or synchronization counterpart (on-link or off-
+   link) or a default gateway.  The Divert option MUST only be
+   encapsulated in Discovery Response messages.  If found elsewhere, it
+   SHOULD be silently ignored.
+
+   A discovery initiator MAY ignore a Divert option if it only requires
+   direct Discovery Responses.
+
+   In fragmentary CDDL, the Divert option follows the pattern:
+
+     divert-option = [O_DIVERT, +locator-option]
+
+   The embedded locator option(s) (Section 2.9.5) point to diverted
+   destination target(s) in response to a Discovery message.
+
+2.9.3.  Accept Option
+
+   The Accept option is used to indicate to the negotiation counterpart
+   that the proposed negotiation content is accepted.
+
+   The Accept option MUST only be encapsulated in Negotiation End
+   messages.  If found elsewhere, it SHOULD be silently ignored.
+
+   In fragmentary CDDL, the Accept option follows the pattern:
+
+     accept-option = [O_ACCEPT]
+
+2.9.4.  Decline Option
+
+   The Decline option is used to indicate to the negotiation counterpart
+   the proposed negotiation content is declined and to end the
+   negotiation process.
+
+   The Decline option MUST only be encapsulated in Negotiation End
+   messages.  If found elsewhere, it SHOULD be silently ignored.
+
+   In fragmentary CDDL, the Decline option follows the pattern:
+
+     decline-option = [O_DECLINE, ?reason]
+     reason = text  ; optional UTF-8 error message
+
+   Note: there might be scenarios where an ASA wants to decline the
+   proposed value and restart the negotiation process.  In this case, it
+   is an implementation choice whether to send a Decline option or to
+   continue with a Negotiation message, with an objective option that
+   contains a null value or one that contains a new value that might
+   achieve convergence.
+
+2.9.5.  Locator Options
+
+   These locator options are used to present reachability information
+   for an ASA, a device, or an interface.  They are Locator IPv6 Address
+   option, Locator IPv4 Address option, Locator FQDN option, and Locator
+   URI option.
+
+   Since ASAs will normally run as independent user programs, locator
+   options need to indicate the network-layer locator plus the transport
+   protocol and port number for reaching the target.  For this reason,
+   the locator options for IP addresses and FQDNs include this
+   information explicitly.  In the case of the Locator URI option, this
+   information can be encoded in the URI itself.
+
+   Note: It is assumed that all locators used in locator options are in
+   scope throughout the GRASP domain.  As stated in Section 2.2, GRASP
+   is not intended to work across disjoint addressing or naming realms.
+
+2.9.5.1.  Locator IPv6 Address Option
+
+   In fragmentary CDDL, the Locator IPv6 Address option follows the
+   pattern:
+
+     ipv6-locator-option = [O_IPv6_LOCATOR, ipv6-address,
+                            transport-proto, port-number]
+     ipv6-address = bytes .size 16
+
+     transport-proto = IPPROTO_TCP / IPPROTO_UDP
+     IPPROTO_TCP = 6
+     IPPROTO_UDP = 17
+     port-number = 0..65535
+
+   The content of this option is a binary IPv6 address followed by the
+   protocol number and port number to be used.
+
+   Note 1: The IPv6 address MUST normally have global scope.  However,
+   during initialization, a link-local address MAY be used for specific
+   objectives only (Section 2.5.2).  In this case, the corresponding
+   Discovery Response message MUST be sent via the interface to which
+   the link-local address applies.
+
+   Note 2: A link-local IPv6 address MUST NOT be used when this option
+   is included in a Divert option.
+
+   Note 3: The IPPROTO values are taken from the existing IANA Protocol
+   Numbers registry in order to specify TCP or UDP.  If GRASP requires
+   future values that are not in that registry, a new registry for
+   values outside the range 0..255 will be needed.
+
+2.9.5.2.  Locator IPv4 Address Option
+
+   In fragmentary CDDL, the Locator IPv4 Address option follows the
+   pattern:
+
+     ipv4-locator-option = [O_IPv4_LOCATOR, ipv4-address,
+                            transport-proto, port-number]
+     ipv4-address = bytes .size 4
+
+   The content of this option is a binary IPv4 address followed by the
+   protocol number and port number to be used.
+
+   Note: If an operator has internal network address translation for
+   IPv4, this option MUST NOT be used within the Divert option.
+
+2.9.5.3.  Locator FQDN Option
+
+   In fragmentary CDDL, the Locator FQDN option follows the pattern:
+
+     fqdn-locator-option = [O_FQDN_LOCATOR, text,
+                            transport-proto, port-number]
+
+   The content of this option is the FQDN of the target followed by the
+   protocol number and port number to be used.
+
+   Note 1: Any FQDN that might not be valid throughout the network in
+   question, such as a Multicast DNS name [RFC6762], MUST NOT be used
+   when this option is used within the Divert option.
+
+   Note 2: Normal GRASP operations are not expected to use this option.
+   It is intended for special purposes such as discovering external
+   services.
+
+2.9.5.4.  Locator URI Option
+
+   In fragmentary CDDL, the Locator URI option follows the pattern:
+
+     uri-locator-option = [O_URI_LOCATOR, text,
+                           transport-proto / null, port-number / null]
+
+   The content of this option is the URI of the target followed by the
+   protocol number and port number to be used (or by null values if not
+   required) [RFC3986].
+
+   Note 1: Any URI which might not be valid throughout the network in
+   question, such as one based on a Multicast DNS name [RFC6762], MUST
+   NOT be used when this option is used within the Divert option.
+
+   Note 2: Normal GRASP operations are not expected to use this option.
+   It is intended for special purposes such as discovering external
+   services.  Therefore, its use is not further described in this
+   specification.
+
+2.10.  Objective Options
+
+2.10.1.  Format of Objective Options
+
+   An objective option is used to identify objectives for the purposes
+   of discovery, negotiation, or synchronization.  All objectives MUST
+   be in the following format, described in fragmentary CDDL:
+
+   objective = [objective-name, objective-flags,
+                loop-count, ?objective-value]
+
+   objective-name = text
+   objective-value = any
+   loop-count = 0..255
+
+   All objectives are identified by a unique name that is a UTF-8 string
+   [RFC3629], to be compared byte by byte.
+
+   The names of generic objectives MUST NOT include a colon (":") and
+   MUST be registered with IANA (Section 5).
+
+   The names of privately defined objectives MUST include at least one
+   colon (":").  The string preceding the last colon in the name MUST be
+   globally unique and in some way identify the entity or person
+   defining the objective.  The following three methods MAY be used to
+   create such a globally unique string:
+
+   1.  The unique string is a decimal number representing a registered
+       32-bit Private Enterprise Number (PEN) [RFC5612] that uniquely
+       identifies the enterprise defining the objective.
+
+   2.  The unique string is a FQDN that uniquely identifies the entity
+       or person defining the objective.
+
+   3.  The unique string is an email address that uniquely identifies
+       the entity or person defining the objective.
+
+   GRASP treats the objective name as an opaque string.  For example,
+   "EX1", "32473:EX1", "example.com:EX1", "example.org:EX1", and
+   "user@example.org:EX1" are five different objectives.
+
+   The 'objective-flags' field is described in Section 2.10.2.
+
+   The 'loop-count' field is used for terminating negotiation as
+   described in Section 2.8.7.  It is also used for terminating
+   discovery as described in Section 2.5.4 and for terminating flooding
+   as described in Section 2.5.6.2.  It is placed in the objective
+   rather than in the GRASP message format because, as far as the ASA is
+   concerned, it is a property of the objective itself.
+
+   The 'objective-value' field expresses the actual value of a
+   negotiation or synchronization objective.  Its format is defined in
+   the specification of the objective and may be a simple value or a
+   data structure of any kind, as long as it can be represented in CBOR.
+   It is optional only in a Discovery or Discovery Response message.
+
+2.10.2.  Objective Flags
+
+   An objective may be relevant for discovery only, for discovery and
+   negotiation, or for discovery and synchronization.  This is expressed
+   in the objective by logical flag bits:
+
+     objective-flags = uint .bits objective-flag
+     objective-flag = &(
+       F_DISC: 0    ; valid for discovery
+       F_NEG: 1     ; valid for negotiation
+       F_SYNCH: 2   ; valid for synchronization
+       F_NEG_DRY: 3 ; negotiation is a dry run
+     )
+
+   These bits are independent and may be combined appropriately, e.g.,
+   (F_DISC and F_SYNCH) or (F_DISC and F_NEG) or (F_DISC and F_NEG and
+   F_NEG_DRY).
+
+   Note that for a given negotiation session, an objective must be used
+   either for negotiation or for dry-run negotiation.  Mixing the two
+   modes in a single negotiation is not possible.
+
+2.10.3.  General Considerations for Objective Options
+
+   As mentioned above, objective options MUST be assigned a unique name.
+   As long as privately defined objective options obey the rules above,
+   this document does not restrict their choice of name, but the entity
+   or person concerned SHOULD publish the names in use.
+
+   Names are expressed as UTF-8 strings for convenience in designing
+   objective options for localized use.  For generic usage, names
+   expressed in the ASCII subset of UTF-8 are RECOMMENDED.  Designers
+   planning to use non-ASCII names are strongly advised to consult
+   [RFC8264] or its successor to understand the complexities involved.
+   Since GRASP compares names byte by byte, all issues of Unicode
+   profiling and canonicalization MUST be specified in the design of the
+   objective option.
+
+   All objective options MUST respect the CBOR patterns defined above as
+   "objective" and MUST replace the 'any' field with a valid CBOR data
+   definition for the relevant use case and application.
+
+   An objective option that contains no additional fields beyond its
+   'loop-count' can only be a discovery objective and MUST only be used
+   in Discovery and Discovery Response messages.
+
+   The Negotiation Objective options contain negotiation objectives,
+   which vary according to different functions and/or services.  They
+   MUST be carried by Discovery, Request Negotiation, or Negotiation
+   messages only.  The negotiation initiator MUST set the initial 'loop-
+   count' to a value specified in the specification of the objective or,
+   if no such value is specified, to GRASP_DEF_LOOPCT.
+
+   For most scenarios, there should be initial values in the negotiation
+   requests.  Consequently, the Negotiation Objective options MUST
+   always be completely presented in a Request Negotiation message, or
+   in a Discovery message in rapid mode.  If there is no initial value,
+   the 'value' field SHOULD be set to the 'null' value defined by CBOR.
+
+   Synchronization Objective options are similar, but MUST be carried by
+   Discovery, Discovery Response, Request Synchronization, or Flood
+   Synchronization messages only.  They include 'value' fields only in
+   Synchronization or Flood Synchronization messages.
+
+   The design of an objective interacts in various ways with the design
+   of the ASAs that will use it.  ASA design considerations are
+   discussed in [ASA-GUIDELINES].
+
+2.10.4.  Organizing of Objective Options
+
+   Generic objective options MUST be specified in documents available to
+   the public and SHOULD be designed to use either the negotiation or
+   the synchronization mechanism described above.
+
+   As noted earlier, one negotiation objective is handled by each GRASP
+   negotiation thread.  Therefore, a negotiation objective, which is
+   based on a specific function or action, SHOULD be organized as a
+   single GRASP option.  It is NOT RECOMMENDED to organize multiple
+   negotiation objectives into a single option nor to split a single
+   function or action into multiple negotiation objectives.
+
+   It is important to understand that GRASP negotiation does not support
+   transactional integrity.  If transactional integrity is needed for a
+   specific objective, this must be ensured by the ASA.  For example, an
+   ASA might need to ensure that it only participates in one negotiation
+   thread at the same time.  Such an ASA would need to stop listening
+   for incoming negotiation requests before generating an outgoing
+   negotiation request.
+
+   A synchronization objective SHOULD be organized as a single GRASP
+   option.
+
+   Some objectives will support more than one operational mode.  An
+   example is a negotiation objective with both a dry-run mode (where
+   the negotiation is to determine whether the other end can, in fact,
+   make the requested change without problems) and a live mode, as
+   explained in Section 2.5.5.  The semantics of such modes will be
+   defined in the specification of the objectives.  These objectives
+   SHOULD include flags indicating the applicable mode(s).
+
+   An issue requiring particular attention is that GRASP itself is not a
+   transactionally safe protocol.  Any state associated with a dry-run
+   operation, such as temporarily reserving a resource for subsequent
+   use in a live run, is entirely a matter for the designer of the ASA
+   concerned.
+
+   As indicated in Section 2.1, an objective's value may include
+   multiple parameters.  Parameters might be categorized into two
+   classes: the obligatory ones presented as fixed fields and the
+   optional ones presented in some other form of data structure embedded
+   in CBOR.  The format might be inherited from an existing management
+   or configuration protocol, with the objective option acting as a
+   carrier for that format.  The data structure might be defined in a
+   formal language, but that is a matter for the specifications of
+   individual objectives.  There are many candidates, according to the
+   context, such as ABNF, RBNF, XML Schema, YANG, etc.  GRASP itself is
+   agnostic on these questions.  The only restriction is that the format
+   can be mapped into CBOR.
+
+   It is NOT RECOMMENDED to mix parameters that have significantly
+   different response-time characteristics in a single objective.
+   Separate objectives are more suitable for such a scenario.
+
+   All objectives MUST support GRASP discovery.  However, as mentioned
+   in Section 2.3, it is acceptable for an ASA to use an alternative
+   method of discovery.
+
+   Normally, a GRASP objective will refer to specific technical
+   parameters as explained in Section 2.1.  However, it is acceptable to
+   define an abstract objective for the purpose of managing or
+   coordinating ASAs.  It is also acceptable to define a special-purpose
+   objective for purposes such as trust bootstrapping or formation of
+   the ACP.
+
+   To guarantee convergence, a limited number of rounds or a timeout is
+   needed for each negotiation objective.  Therefore, the definition of
+   each negotiation objective SHOULD clearly specify this, for example,
+   a default loop count and timeout, so that the negotiation can always
+   be terminated properly.  If not, the GRASP defaults will apply.
+
+   There must be a well-defined procedure for concluding that a
+   negotiation cannot succeed, and if so, deciding what happens next
+   (e.g., deadlock resolution, tie-breaking, or reversion to best-effort
+   service).  This MUST be specified for individual negotiation
+   objectives.
+
+2.10.5.  Experimental and Example Objective Options
+
+   The names "EX0" through "EX9" have been reserved for experimental
+   options.  Multiple names have been assigned because a single
+   experiment may use multiple options simultaneously.  These
+   experimental options are highly likely to have different meanings
+   when used for different experiments.  Therefore, they SHOULD NOT be
+   used without an explicit human decision and MUST NOT be used in
+   unmanaged networks such as home networks.
+
+   These names are also RECOMMENDED for use in documentation examples.
+
+3.  Security Considerations
+
+   A successful attack on negotiation-enabled nodes would be extremely
+   harmful, as such nodes might end up with a completely undesirable
+   configuration that would also adversely affect their peers.  GRASP
+   nodes and messages therefore require full protection.  As explained
+   in Section 2.5.1, GRASP MUST run within a secure environment such as
+   the ACP [RFC8994], except for the constrained instances described in
+   Section 2.5.2.
+
+   Authentication
+      A cryptographically authenticated identity for each device is
+      needed in an Autonomic Network.  It is not safe to assume that a
+      large network is physically secured against interference or that
+      all personnel are trustworthy.  Each autonomic node MUST be
+      capable of proving its identity and authenticating its messages.
+      GRASP relies on a separate, external certificate-based security
+      mechanism to support authentication, data integrity protection,
+      and anti-replay protection.
+
+      Since GRASP must be deployed in an existing secure environment,
+      the protocol itself specifies nothing concerning the trust anchor
+      and certification authority.  For example, in the ACP [RFC8994],
+      all nodes can trust each other and the ASAs installed in them.
+
+      If GRASP is used temporarily without an external security
+      mechanism, for example, during system bootstrap (Section 2.5.1),
+      the Session ID (Section 2.7) will act as a nonce to provide
+      limited protection against the injecting of responses by third
+      parties.  A full analysis of the secure bootstrap process is in
+      [RFC8995].
+
+   Authorization and roles
+      GRASP is agnostic about the roles and capabilities of individual
+      ASAs and about which objectives a particular ASA is authorized to
+      support.  An implementation might support precautions such as
+      allowing only one ASA in a given node to modify a given objective,
+      but this may not be appropriate in all cases.  For example, it
+      might be operationally useful to allow an old and a new version of
+      the same ASA to run simultaneously during an overlap period.
+      These questions are out of scope for the present specification.
+
+   Privacy and confidentiality
+      GRASP is intended for network-management purposes involving
+      network elements, not end hosts.  Therefore, no personal
+      information is expected to be involved in the signaling protocol,
+      so there should be no direct impact on personal privacy.
+      Nevertheless, applications that do convey personal information
+      cannot be excluded.  Also, traffic flow paths, VPNs, etc., could
+      be negotiated, which could be of interest for traffic analysis.
+      Operators generally want to conceal details of their network
+      topology and traffic density from outsiders.  Therefore, since
+      insider attacks cannot be excluded in a large network, the
+      security mechanism for the protocol MUST provide message
+      confidentiality.  This is why Section 2.5.1 requires either an ACP
+      or an alternative security mechanism.
+
+   Link-local multicast security
+      GRASP has no reasonable alternative to using link-local multicast
+      for Discovery or Flood Synchronization messages, and these
+      messages are sent in the clear and with no authentication.  They
+      are only sent on interfaces within the Autonomic Network (see
+      Section 2.1 and Section 2.5.1).  They are, however, available to
+      on-link eavesdroppers and could be forged by on-link attackers.
+      In the case of discovery, the Discovery Responses are unicast and
+      will therefore be protected (Section 2.5.1), and an untrusted
+      forger will not be able to receive responses.  In the case of
+      flood synchronization, an on-link eavesdropper will be able to
+      receive the flooded objectives, but there is no response message
+      to consider.  Some precautions for Flood Synchronization messages
+      are suggested in Section 2.5.6.2.
+
+   DoS attack protection
+      GRASP discovery partly relies on insecure link-local multicast.
+      Since routers participating in GRASP sometimes relay Discovery
+      messages from one link to another, this could be a vector for
+      denial-of-service attacks.  Some mitigations are specified in
+      Section 2.5.4.  However, malicious code installed inside the ACP
+      could always launch DoS attacks consisting of either spurious
+      Discovery messages or spurious Discovery Responses.  It is
+      important that firewalls prevent any GRASP messages from entering
+      the domain from an unknown source.
+
+   Security during bootstrap and discovery
+      A node cannot trust GRASP traffic from other nodes until the
+      security environment (such as the ACP) has identified the trust
+      anchor and can authenticate traffic by validating certificates for
+      other nodes.  Also, until it has successfully enrolled [RFC8995],
+      a node cannot assume that other nodes are able to authenticate its
+      own traffic.  Therefore, GRASP discovery during the bootstrap
+      phase for a new device will inevitably be insecure.  Secure
+      synchronization and negotiation will be impossible until
+      enrollment is complete.  Further details are given in
+      Section 2.5.2.
+
+   Security of discovered locators
+      When GRASP discovery returns an IP address, it MUST be that of a
+      node within the secure environment (Section 2.5.1).  If it returns
+      an FQDN or a URI, the ASA that receives it MUST NOT assume that
+      the target of the locator is within the secure environment.
+
+4.  CDDL Specification of GRASP
+
+   <CODE BEGINS> file "grasp.cddl"
+   grasp-message = (message .within message-structure) / noop-message
+
+   message-structure = [MESSAGE_TYPE, session-id, ?initiator,
+                        *grasp-option]
+
+   MESSAGE_TYPE = 0..255
+   session-id = 0..4294967295 ; up to 32 bits
+   grasp-option = any
+
+   message /= discovery-message
+   discovery-message = [M_DISCOVERY, session-id, initiator, objective]
+
+   message /= response-message ; response to Discovery
+   response-message = [M_RESPONSE, session-id, initiator, ttl,
+                       (+locator-option // divert-option), ?objective]
+
+   message /= synch-message ; response to Synchronization request
+   synch-message = [M_SYNCH, session-id, objective]
+
+   message /= flood-message
+   flood-message = [M_FLOOD, session-id, initiator, ttl,
+                    +[objective, (locator-option / [])]]
+
+   message /= request-negotiation-message
+   request-negotiation-message = [M_REQ_NEG, session-id, objective]
+
+   message /= request-synchronization-message
+   request-synchronization-message = [M_REQ_SYN, session-id, objective]
+
+   message /= negotiation-message
+   negotiation-message = [M_NEGOTIATE, session-id, objective]
+
+   message /= end-message
+   end-message = [M_END, session-id, accept-option / decline-option]
+
+   message /= wait-message
+   wait-message = [M_WAIT, session-id, waiting-time]
+
+   message /= invalid-message
+   invalid-message = [M_INVALID, session-id, ?any]
+
+   noop-message = [M_NOOP]
+
+   divert-option = [O_DIVERT, +locator-option]
+
+   accept-option = [O_ACCEPT]
+
+   decline-option = [O_DECLINE, ?reason]
+   reason = text  ; optional UTF-8 error message
+
+   waiting-time = 0..4294967295 ; in milliseconds
+   ttl = 0..4294967295 ; in milliseconds
+
+   locator-option /= [O_IPv4_LOCATOR, ipv4-address,
+                      transport-proto, port-number]
+   ipv4-address = bytes .size 4
+
+   locator-option /= [O_IPv6_LOCATOR, ipv6-address,
+                      transport-proto, port-number]
+   ipv6-address = bytes .size 16
+
+   locator-option /= [O_FQDN_LOCATOR, text, transport-proto,
+                      port-number]
+
+   locator-option /= [O_URI_LOCATOR, text,
+                      transport-proto / null, port-number / null]
+
+   transport-proto = IPPROTO_TCP / IPPROTO_UDP
+   IPPROTO_TCP = 6
+   IPPROTO_UDP = 17
+   port-number = 0..65535
+
+   initiator = ipv4-address / ipv6-address
+
+   objective-flags = uint .bits objective-flag
+
+   objective-flag = &(
+     F_DISC: 0    ; valid for discovery
+     F_NEG: 1     ; valid for negotiation
+     F_SYNCH: 2   ; valid for synchronization
+     F_NEG_DRY: 3 ; negotiation is a dry run
+   )
+
+   objective = [objective-name, objective-flags,
+                loop-count, ?objective-value]
+
+   objective-name = text ; see section "Format of Objective Options"
+
+   objective-value = any
+
+   loop-count = 0..255
+
+   ; Constants for message types and option types
+
+   M_NOOP = 0
+   M_DISCOVERY = 1
+   M_RESPONSE = 2
+   M_REQ_NEG = 3
+   M_REQ_SYN = 4
+   M_NEGOTIATE = 5
+   M_END = 6
+   M_WAIT = 7
+   M_SYNCH = 8
+   M_FLOOD = 9
+   M_INVALID = 99
+
+   O_DIVERT = 100
+   O_ACCEPT = 101
+   O_DECLINE = 102
+   O_IPv6_LOCATOR = 103
+   O_IPv4_LOCATOR = 104
+   O_FQDN_LOCATOR = 105
+   O_URI_LOCATOR = 106
+   <CODE ENDS>
+
+5.  IANA Considerations
+
+   This document defines the GeneRic Autonomic Signaling Protocol
+   (GRASP).
+
+   Section 2.6 explains the following link-local multicast addresses
+   that IANA has assigned for use by GRASP.
+
+   Assigned in the "Link-Local Scope Multicast Addresses" subregistry of
+   the "IPv6 Multicast Address Space Registry":
+
+   Address(es):  ff02::13
+   Description:  ALL_GRASP_NEIGHBORS
+   Reference:  RFC 8990
+
+   Assigned in the "Local Network Control Block (224.0.0.0 - 224.0.0.255
+   (224.0.0/24))" subregistry of the "IPv4 Multicast Address Space
+   Registry":
+
+   Address(es):  224.0.0.119
+   Description:  ALL_GRASP_NEIGHBORS
+   Reference:  RFC 8990
+
+   Section 2.6 explains the following User Port (GRASP_LISTEN_PORT),
+   which IANA has assigned for use by GRASP for both UDP and TCP:
+
+   Service Name:  grasp
+   Port Number:  7017
+   Transport Protocol:  udp, tcp
+   Description  GeneRic Autonomic Signaling Protocol
+   Assignee:  IESG <iesg@ietf.org>
+   Contact:  IETF Chair <chair@ietf.org>
+   Reference:  RFC 8990
+
+   The IANA has created the "GeneRic Autonomic Signaling Protocol
+   (GRASP) Parameters" registry, which includes two subregistries:
+   "GRASP Messages and Options" and "GRASP Objective Names".
+
+   The values in the "GRASP Messages and Options" subregistry are names
+   paired with decimal integers.  Future values MUST be assigned using
+   the Standards Action policy defined by [RFC8126].  The following
+   initial values are assigned by this document:
+
+                        +=======+================+
+                        | Value | Message/Option |
+                        +=======+================+
+                        | 0     | M_NOOP         |
+                        +-------+----------------+
+                        | 1     | M_DISCOVERY    |
+                        +-------+----------------+
+                        | 2     | M_RESPONSE     |
+                        +-------+----------------+
+                        | 3     | M_REQ_NEG      |
+                        +-------+----------------+
+                        | 4     | M_REQ_SYN      |
+                        +-------+----------------+
+                        | 5     | M_NEGOTIATE    |
+                        +-------+----------------+
+                        | 6     | M_END          |
+                        +-------+----------------+
+                        | 7     | M_WAIT         |
+                        +-------+----------------+
+                        | 8     | M_SYNCH        |
+                        +-------+----------------+
+                        | 9     | M_FLOOD        |
+                        +-------+----------------+
+                        | 99    | M_INVALID      |
+                        +-------+----------------+
+                        | 100   | O_DIVERT       |
+                        +-------+----------------+
+                        | 101   | O_ACCEPT       |
+                        +-------+----------------+
+                        | 102   | O_DECLINE      |
+                        +-------+----------------+
+                        | 103   | O_IPv6_LOCATOR |
+                        +-------+----------------+
+                        | 104   | O_IPv4_LOCATOR |
+                        +-------+----------------+
+                        | 105   | O_FQDN_LOCATOR |
+                        +-------+----------------+
+                        | 106   | O_URI_LOCATOR  |
+                        +-------+----------------+
+
+                             Table 1: Initial
+                           Values of the "GRASP
+                          Messages and Options"
+                               Subregistry
+
+   The values in the "GRASP Objective Names" subregistry are UTF-8
+   strings that MUST NOT include a colon (":"), according to
+   Section 2.10.1.  Future values MUST be assigned using the
+   Specification Required policy defined by [RFC8126].
+
+   To assist expert review of a new objective, the specification should
+   include a precise description of the format of the new objective,
+   with sufficient explanation of its semantics to allow independent
+   implementations.  See Section 2.10.3 for more details.  If the new
+   objective is similar in name or purpose to a previously registered
+   objective, the specification should explain why a new objective is
+   justified.
+
+   The following initial values are assigned by this document:
+
+                      +================+===========+
+                      | Objective Name | Reference |
+                      +================+===========+
+                      | EX0            | RFC 8990  |
+                      +----------------+-----------+
+                      | EX1            | RFC 8990  |
+                      +----------------+-----------+
+                      | EX2            | RFC 8990  |
+                      +----------------+-----------+
+                      | EX3            | RFC 8990  |
+                      +----------------+-----------+
+                      | EX4            | RFC 8990  |
+                      +----------------+-----------+
+                      | EX5            | RFC 8990  |
+                      +----------------+-----------+
+                      | EX6            | RFC 8990  |
+                      +----------------+-----------+
+                      | EX7            | RFC 8990  |
+                      +----------------+-----------+
+                      | EX8            | RFC 8990  |
+                      +----------------+-----------+
+                      | EX9            | RFC 8990  |
+                      +----------------+-----------+
+
+                        Table 2: Initial Values of
+                           the "GRASP Objective
+                            Names" Subregistry
+
+6.  References
+
+6.1.  Normative References
+
+   [RFC2119]  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>.
+
+   [RFC3629]  Yergeau, F., "UTF-8, a transformation format of ISO
+              10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November
+              2003, <https://www.rfc-editor.org/info/rfc3629>.
+
+   [RFC3986]  Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
+              Resource Identifier (URI): Generic Syntax", STD 66,
+              RFC 3986, DOI 10.17487/RFC3986, January 2005,
+              <https://www.rfc-editor.org/info/rfc3986>.
+
+   [RFC4086]  Eastlake 3rd, D., Schiller, J., and S. Crocker,
+              "Randomness Requirements for Security", BCP 106, RFC 4086,
+              DOI 10.17487/RFC4086, June 2005,
+              <https://www.rfc-editor.org/info/rfc4086>.
+
+   [RFC7217]  Gont, F., "A Method for Generating Semantically Opaque
+              Interface Identifiers with IPv6 Stateless Address
+              Autoconfiguration (SLAAC)", RFC 7217,
+              DOI 10.17487/RFC7217, April 2014,
+              <https://www.rfc-editor.org/info/rfc7217>.
+
+   [RFC8085]  Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage
+              Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085,
+              March 2017, <https://www.rfc-editor.org/info/rfc8085>.
+
+   [RFC8174]  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>.
+
+   [RFC8610]  Birkholz, H., Vigano, C., and C. Bormann, "Concise Data
+              Definition Language (CDDL): A Notational Convention to
+              Express Concise Binary Object Representation (CBOR) and
+              JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610,
+              June 2019, <https://www.rfc-editor.org/info/rfc8610>.
+
+   [RFC8949]  Bormann, C. and P. Hoffman, "Concise Binary Object
+              Representation (CBOR)", STD 94, RFC 8949,
+              DOI 10.17487/RFC8949, December 2020,
+              <https://www.rfc-editor.org/info/rfc8949>.
+
+   [RFC8994]  Eckert, T., Ed., Behringer, M., Ed., and S. Bjarnason, "An
+              Autonomic Control Plane (ACP)", RFC 8994,
+              DOI 10.17487/RFC8994, May 2021,
+              <https://www.rfc-editor.org/info/rfc8994>.
+
+6.2.  Informative References
+
+   [ADNCP]    Stenberg, M., "Autonomic Distributed Node Consensus
+              Protocol", Work in Progress, Internet-Draft, draft-
+              stenberg-anima-adncp-00, 5 March 2015,
+              <https://tools.ietf.org/html/draft-stenberg-anima-adncp-
+              00>.
+
+   [ASA-GUIDELINES]
+              Carpenter, B., Ciavaglia, L., Jiang, S., and P. Peloso,
+              "Guidelines for Autonomic Service Agents", Work in
+              Progress, Internet-Draft, draft-ietf-anima-asa-guidelines-
+              00, 14 November 2020, <https://tools.ietf.org/html/draft-
+              ietf-anima-asa-guidelines-00>.
+
+   [IGCP]     Behringer, M. H., Chaparadza, R., Xin, L., Mahkonen, H.,
+              and R. Petre, "IP based Generic Control Protocol (IGCP)",
+              Work in Progress, Internet-Draft, draft-chaparadza-
+              intarea-igcp-00, 25 July 2011,
+              <https://tools.ietf.org/html/draft-chaparadza-intarea-
+              igcp-00>.
+
+   [RFC2205]  Braden, R., Ed., Zhang, L., Berson, S., Herzog, S., and S.
+              Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1
+              Functional Specification", RFC 2205, DOI 10.17487/RFC2205,
+              September 1997, <https://www.rfc-editor.org/info/rfc2205>.
+
+   [RFC2334]  Luciani, J., Armitage, G., Halpern, J., and N. Doraswamy,
+              "Server Cache Synchronization Protocol (SCSP)", RFC 2334,
+              DOI 10.17487/RFC2334, April 1998,
+              <https://www.rfc-editor.org/info/rfc2334>.
+
+   [RFC2608]  Guttman, E., Perkins, C., Veizades, J., and M. Day,
+              "Service Location Protocol, Version 2", RFC 2608,
+              DOI 10.17487/RFC2608, June 1999,
+              <https://www.rfc-editor.org/info/rfc2608>.
+
+   [RFC2865]  Rigney, C., Willens, S., Rubens, A., and W. Simpson,
+              "Remote Authentication Dial In User Service (RADIUS)",
+              RFC 2865, DOI 10.17487/RFC2865, June 2000,
+              <https://www.rfc-editor.org/info/rfc2865>.
+
+   [RFC3416]  Presuhn, R., Ed., "Version 2 of the Protocol Operations
+              for the Simple Network Management Protocol (SNMP)",
+              STD 62, RFC 3416, DOI 10.17487/RFC3416, December 2002,
+              <https://www.rfc-editor.org/info/rfc3416>.
+
+   [RFC3493]  Gilligan, R., Thomson, S., Bound, J., McCann, J., and W.
+              Stevens, "Basic Socket Interface Extensions for IPv6",
+              RFC 3493, DOI 10.17487/RFC3493, February 2003,
+              <https://www.rfc-editor.org/info/rfc3493>.
+
+   [RFC4861]  Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
+              "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
+              DOI 10.17487/RFC4861, September 2007,
+              <https://www.rfc-editor.org/info/rfc4861>.
+
+   [RFC5612]  Eronen, P. and D. Harrington, "Enterprise Number for
+              Documentation Use", RFC 5612, DOI 10.17487/RFC5612, August
+              2009, <https://www.rfc-editor.org/info/rfc5612>.
+
+   [RFC5971]  Schulzrinne, H. and R. Hancock, "GIST: General Internet
+              Signalling Transport", RFC 5971, DOI 10.17487/RFC5971,
+              October 2010, <https://www.rfc-editor.org/info/rfc5971>.
+
+   [RFC6206]  Levis, P., Clausen, T., Hui, J., Gnawali, O., and J. Ko,
+              "The Trickle Algorithm", RFC 6206, DOI 10.17487/RFC6206,
+              March 2011, <https://www.rfc-editor.org/info/rfc6206>.
+
+   [RFC6241]  Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,
+              and A. Bierman, Ed., "Network Configuration Protocol
+              (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011,
+              <https://www.rfc-editor.org/info/rfc6241>.
+
+   [RFC6733]  Fajardo, V., Ed., Arkko, J., Loughney, J., and G. Zorn,
+              Ed., "Diameter Base Protocol", RFC 6733,
+              DOI 10.17487/RFC6733, October 2012,
+              <https://www.rfc-editor.org/info/rfc6733>.
+
+   [RFC6762]  Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762,
+              DOI 10.17487/RFC6762, February 2013,
+              <https://www.rfc-editor.org/info/rfc6762>.
+
+   [RFC6763]  Cheshire, S. and M. Krochmal, "DNS-Based Service
+              Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013,
+              <https://www.rfc-editor.org/info/rfc6763>.
+
+   [RFC6887]  Wing, D., Ed., Cheshire, S., Boucadair, M., Penno, R., and
+              P. Selkirk, "Port Control Protocol (PCP)", RFC 6887,
+              DOI 10.17487/RFC6887, April 2013,
+              <https://www.rfc-editor.org/info/rfc6887>.
+
+   [RFC7558]  Lynn, K., Cheshire, S., Blanchet, M., and D. Migault,
+              "Requirements for Scalable DNS-Based Service Discovery
+              (DNS-SD) / Multicast DNS (mDNS) Extensions", RFC 7558,
+              DOI 10.17487/RFC7558, July 2015,
+              <https://www.rfc-editor.org/info/rfc7558>.
+
+   [RFC7575]  Behringer, M., Pritikin, M., Bjarnason, S., Clemm, A.,
+              Carpenter, B., Jiang, S., and L. Ciavaglia, "Autonomic
+              Networking: Definitions and Design Goals", RFC 7575,
+              DOI 10.17487/RFC7575, June 2015,
+              <https://www.rfc-editor.org/info/rfc7575>.
+
+   [RFC7576]  Jiang, S., Carpenter, B., and M. Behringer, "General Gap
+              Analysis for Autonomic Networking", RFC 7576,
+              DOI 10.17487/RFC7576, June 2015,
+              <https://www.rfc-editor.org/info/rfc7576>.
+
+   [RFC7787]  Stenberg, M. and S. Barth, "Distributed Node Consensus
+              Protocol", RFC 7787, DOI 10.17487/RFC7787, April 2016,
+              <https://www.rfc-editor.org/info/rfc7787>.
+
+   [RFC7788]  Stenberg, M., Barth, S., and P. Pfister, "Home Networking
+              Control Protocol", RFC 7788, DOI 10.17487/RFC7788, April
+              2016, <https://www.rfc-editor.org/info/rfc7788>.
+
+   [RFC8040]  Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF
+              Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017,
+              <https://www.rfc-editor.org/info/rfc8040>.
+
+   [RFC8126]  Cotton, M., Leiba, B., and T. Narten, "Guidelines for
+              Writing an IANA Considerations Section in RFCs", BCP 26,
+              RFC 8126, DOI 10.17487/RFC8126, June 2017,
+              <https://www.rfc-editor.org/info/rfc8126>.
+
+   [RFC8264]  Saint-Andre, P. and M. Blanchet, "PRECIS Framework:
+              Preparation, Enforcement, and Comparison of
+              Internationalized Strings in Application Protocols",
+              RFC 8264, DOI 10.17487/RFC8264, October 2017,
+              <https://www.rfc-editor.org/info/rfc8264>.
+
+   [RFC8368]  Eckert, T., Ed. and M. Behringer, "Using an Autonomic
+              Control Plane for Stable Connectivity of Network
+              Operations, Administration, and Maintenance (OAM)",
+              RFC 8368, DOI 10.17487/RFC8368, May 2018,
+              <https://www.rfc-editor.org/info/rfc8368>.
+
+   [RFC8415]  Mrugalski, T., Siodelski, M., Volz, B., Yourtchenko, A.,
+              Richardson, M., Jiang, S., Lemon, T., and T. Winters,
+              "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)",
+              RFC 8415, DOI 10.17487/RFC8415, November 2018,
+              <https://www.rfc-editor.org/info/rfc8415>.
+
+   [RFC8991]  Carpenter, B., Liu, B., Ed., Wang, W., and X. Gong,
+              "GeneRic Autonomic Signaling Protocol Application Program
+              Interface (GRASP API)", RFC 8991, DOI 10.17487/RFC8991,
+              May 2021, <https://www.rfc-editor.org/info/rfc8991>.
+
+   [RFC8993]  Behringer, M., Ed., Carpenter, B., Eckert, T., Ciavaglia,
+              L., and J. Nobre, "A Reference Model for Autonomic
+              Networking", RFC 8993, DOI 10.17487/RFC8993, May 2021,
+              <https://www.rfc-editor.org/info/rfc8993>.
+
+   [RFC8995]  Pritikin, M., Richardson, M., Eckert, T., Behringer, M.,
+              and K. Watsen, "Bootstrapping Remote Secure Key
+              Infrastructure (BRSKI)", RFC 8995, DOI 10.17487/RFC8995,
+              May 2021, <https://www.rfc-editor.org/info/rfc8995>.
+
+Appendix A.  Example Message Formats
+
+   For readers unfamiliar with CBOR, this appendix shows a number of
+   example GRASP messages conforming to the CDDL syntax given in
+   Section 4.  Each message is shown three times in the following
+   formats:
+
+   1.  CBOR diagnostic notation.
+
+   2.  Similar, but showing the names of the constants.  (Details of the
+       flag bit encoding are omitted.)
+
+   3.  Hexadecimal version of the CBOR wire format.
+
+   Long lines are split for display purposes only.
+
+A.1.  Discovery Example
+
+   The initiator (2001:db8:f000:baaa:28cc:dc4c:9703:6781) multicasts a
+   Discovery message looking for objective EX1:
+
+   [1, 13948744, h'20010db8f000baaa28ccdc4c97036781', ["EX1", 5, 2, 0]]
+   [M_DISCOVERY, 13948744, h'20010db8f000baaa28ccdc4c97036781',
+                 ["EX1", F_SYNCH_bits, 2, 0]]
+   h'84011a00d4d7485020010db8f000baaa28ccdc4c970367818463455831050200'
+
+   A peer (2001:0db8:f000:baaa:f000:baaa:f000:baaa) responds with a
+   locator:
+
+   [2, 13948744, h'20010db8f000baaa28ccdc4c97036781', 60000,
+                 [103, h'20010db8f000baaaf000baaaf000baaa', 6, 49443]]
+   [M_RESPONSE, 13948744, h'20010db8f000baaa28ccdc4c97036781', 60000,
+                 [O_IPv6_LOCATOR, h'20010db8f000baaaf000baaaf000baaa',
+                  IPPROTO_TCP, 49443]]
+   h'85021a00d4d7485020010db8f000baaa28ccdc4c9703678119ea6084186750
+     20010db8f000baaaf000baaaf000baaa0619c123'
+
+A.2.  Flood Example
+
+   The initiator multicasts a Flood Synchronization message.  The single
+   objective has a null locator.  There is no response:
+
+[9, 3504974, h'20010db8f000baaa28ccdc4c97036781', 10000,
+             [["EX1", 5, 2, ["Example 1 value=", 100]],[] ] ]
+[M_FLOOD, 3504974, h'20010db8f000baaa28ccdc4c97036781', 10000,
+             [["EX1", F_SYNCH_bits, 2, ["Example 1 value=", 100]],[] ] ]
+h'85091a00357b4e5020010db8f000baaa28ccdc4c97036781192710
+  828463455831050282704578616d706c6520312076616c75653d186480'
+
+A.3.  Synchronization Example
+
+   Following successful discovery of objective EX2, the initiator
+   unicasts a Request Synchronization message:
+
+   [4, 4038926, ["EX2", 5, 5, 0]]
+   [M_REQ_SYN, 4038926, ["EX2", F_SYNCH_bits, 5, 0]]
+   h'83041a003da10e8463455832050500'
+
+   The peer responds with a value:
+
+ [8, 4038926, ["EX2", 5, 5, ["Example 2 value=", 200]]]
+ [M_SYNCH, 4038926, ["EX2", F_SYNCH_bits, 5, ["Example 2 value=", 200]]]
+ h'83081a003da10e8463455832050582704578616d706c6520322076616c75653d18c8'
+
+A.4.  Simple Negotiation Example
+
+   Following successful discovery of objective EX3, the initiator
+   unicasts a Request Negotiation message:
+
+   [3, 802813, ["EX3", 3, 6, ["NZD", 47]]]
+   [M_REQ_NEG, 802813, ["EX3", F_NEG_bits, 6, ["NZD", 47]]]
+   h'83031a000c3ffd8463455833030682634e5a44182f'
+
+   The peer responds with immediate acceptance.  Note that no objective
+   is needed because the initiator's request was accepted without
+   change:
+
+   [6, 802813, [101]]
+   [M_END , 802813, [O_ACCEPT]]
+   h'83061a000c3ffd811865'
+
+A.5.  Complete Negotiation Example
+
+   Again the initiator unicasts a Request Negotiation message:
+
+   [3, 13767778, ["EX3", 3, 6, ["NZD", 410]]]
+   [M_REQ_NEG, 13767778, ["EX3", F_NEG_bits, 6, ["NZD", 410]]]
+   h'83031a00d214628463455833030682634e5a4419019a'
+
+   The responder starts to negotiate (making an offer):
+
+   [5, 13767778, ["EX3", 3, 6, ["NZD", 80]]]
+   [M_NEGOTIATE, 13767778, ["EX3", F_NEG_bits, 6, ["NZD", 80]]]
+   h'83051a00d214628463455833030682634e5a441850'
+
+   The initiator continues to negotiate (reducing its request, and note
+   that the loop count is decremented):
+
+   [5, 13767778, ["EX3", 3, 5, ["NZD", 307]]]
+   [M_NEGOTIATE, 13767778, ["EX3", F_NEG_bits, 5, ["NZD", 307]]]
+   h'83051a00d214628463455833030582634e5a44190133'
+
+   The responder asks for more time:
+
+   [7, 13767778, 34965]
+   [M_WAIT, 13767778, 34965]
+   h'83071a00d21462198895'
+
+   The responder continues to negotiate (increasing its offer):
+
+   [5, 13767778, ["EX3", 3, 4, ["NZD", 120]]]
+   [M_NEGOTIATE, 13767778, ["EX3", F_NEG_bits, 4, ["NZD", 120]]]
+   h'83051a00d214628463455833030482634e5a441878'
+
+   The initiator continues to negotiate (reducing its request):
+
+   [5, 13767778, ["EX3", 3, 3, ["NZD", 246]]]
+   [M_NEGOTIATE, 13767778, ["EX3", F_NEG_bits, 3, ["NZD", 246]]]
+   h'83051a00d214628463455833030382634e5a4418f6'
+
+   The responder refuses to negotiate further:
+
+   [6, 13767778, [102, "Insufficient funds"]]
+   [M_END , 13767778, [O_DECLINE, "Insufficient funds"]]
+   h'83061a00d2146282186672496e73756666696369656e742066756e6473'
+
+   This negotiation has failed.  If either side had sent [M_END,
+   13767778, [O_ACCEPT]] it would have succeeded, converging on the
+   objective value in the preceding M_NEGOTIATE.  Note that apart from
+   the initial M_REQ_NEG, the process is symmetrical.
+
+Appendix B.  Requirement Analysis of Discovery, Synchronization, and
+             Negotiation
+
+   This section discusses the requirements for discovery, negotiation,
+   and synchronization capabilities.  The primary user of the protocol
+   is an Autonomic Service Agent (ASA), so the requirements are mainly
+   expressed as the features needed by an ASA.  A single physical device
+   might contain several ASAs, and a single ASA might manage several
+   technical objectives.  If a technical objective is managed by several
+   ASAs, any necessary coordination is outside the scope of GRASP.
+   Furthermore, requirements for ASAs themselves, such as the processing
+   of Intent [RFC7575], are out of scope for the present document.
+
+B.1.  Requirements for Discovery
+
+   D1.   ASAs may be designed to manage any type of configurable device
+         or software, as required in Appendix B.2.  A basic requirement
+         is therefore that the protocol can represent and discover any
+         kind of technical objective (as defined in Section 2.1) among
+         arbitrary subsets of participating nodes.
+
+         In an Autonomic Network, we must assume that when a device
+         starts up, it has no information about any peer devices, the
+         network structure, or the specific role it must play.  The
+         ASA(s) inside the device are in the same situation.  In some
+         cases, when a new application session starts within a device,
+         the device or ASA may again lack information about relevant
+         peers.  For example, it might be necessary to set up resources
+         on multiple other devices, coordinated and matched to each
+         other so that there is no wasted resource.  Security settings
+         might also need updating to allow for the new device or user.
+         The relevant peers may be different for different technical
+         objectives.  Therefore discovery needs to be repeated as often
+         as necessary to find peers capable of acting as counterparts
+         for each objective that a discovery initiator needs to handle.
+         From this background we derive the next three requirements:
+
+   D2.   When an ASA first starts up, it may have no knowledge of the
+         specific network to which it is attached.  Therefore the
+         discovery process must be able to support any network scenario,
+         assuming only that the device concerned is bootstrapped from
+         factory condition.
+
+   D3.   When an ASA starts up, it must require no configured location
+         information about any peers in order to discover them.
+
+   D4.   If an ASA supports multiple technical objectives, relevant
+         peers may be different for different discovery objectives, so
+         discovery needs to be performed separately to find counterparts
+         for each objective.  Thus, there must be a mechanism by which
+         an ASA can separately discover peer ASAs for each of the
+         technical objectives that it needs to manage, whenever
+         necessary.
+
+   D5.   Following discovery, an ASA will normally perform negotiation
+         or synchronization for the corresponding objectives.  The
+         design should allow for this by conveniently linking discovery
+         to negotiation and synchronization.  It may provide an optional
+         mechanism to combine discovery and negotiation/synchronization
+         in a single protocol exchange.
+
+   D6.   Some objectives may only be significant on the local link, but
+         others may be significant across the routed network and require
+         off-link operations.  Thus, the relevant peers might be
+         immediate neighbors on the same layer 2 link, or they might be
+         more distant and only accessible via layer 3.  The mechanism
+         must therefore provide both on-link and off-link discovery of
+         ASAs supporting specific technical objectives.
+
+   D7.   The discovery process should be flexible enough to allow for
+         special cases, such as the following:
+
+         *  During initialization, a device must be able to establish
+            mutual trust with autonomic nodes elsewhere in the network
+            and participate in an authentication mechanism.  Although
+            this will inevitably start with a discovery action, it is a
+            special case precisely because trust is not yet established.
+            This topic is the subject of [RFC8995].  We require that
+            once trust has been established for a device, all ASAs
+            within the device inherit the device's credentials and are
+            also trusted.  This does not preclude the device having
+            multiple credentials.
+
+         *  Depending on the type of network involved, discovery of
+            other central functions might be needed, such as the Network
+            Operations Center (NOC) [RFC8368].  The protocol must be
+            capable of supporting such discovery during initialization,
+            as well as discovery during ongoing operation.
+
+   D8.   The discovery process must not generate excessive traffic and
+         must take account of sleeping nodes.
+
+   D9.   There must be a mechanism for handling stale discovery results.
+
+B.2.  Requirements for Synchronization and Negotiation Capability
+
+   Autonomic Networks need to be able to manage many different types of
+   parameters and consider many dimensions, such as latency, load,
+   unused or limited resources, conflicting resource requests, security
+   settings, power saving, load balancing, etc.  Status information and
+   resource metrics need to be shared between nodes for dynamic
+   adjustment of resources and for monitoring purposes.  While this
+   might be achieved by existing protocols when they are available, the
+   new protocol needs to be able to support parameter exchange,
+   including mutual synchronization, even when no negotiation as such is
+   required.  In general, these parameters do not apply to all
+   participating nodes, but only to a subset.
+
+   SN1.  A basic requirement for the protocol is therefore the ability
+         to represent, discover, synchronize, and negotiate almost any
+         kind of network parameter among selected subsets of
+         participating nodes.
+
+   SN2.  Negotiation is an iterative request/response process that must
+         be guaranteed to terminate (with success or failure).  While
+         tie-breaking rules must be defined specifically for each use
+         case, the protocol should have some general mechanisms in
+         support of loop and deadlock prevention, such as hop-count
+         limits or timeouts.
+
+   SN3.  Synchronization must be possible for groups of nodes ranging
+         from small to very large.
+
+   SN4.  To avoid "reinventing the wheel", the protocol should be able
+         to encapsulate the data formats used by existing configuration
+         protocols (such as Network Configuration Protocol (NETCONF) and
+         YANG) in cases where that is convenient.
+
+   SN5.  Human intervention in complex situations is costly and error
+         prone.  Therefore, synchronization or negotiation of parameters
+         without human intervention is desirable whenever the
+         coordination of multiple devices can improve overall network
+         performance.  It follows that the protocol's resource
+         requirements must be small enough to fit in any device that
+         would otherwise need human intervention.  The issue of running
+         in constrained nodes is discussed in [RFC8993].
+
+   SN6.  Human intervention in large networks is often replaced by use
+         of a top-down network management system (NMS).  It therefore
+         follows that the protocol, as part of the Autonomic Networking
+         Infrastructure, should be capable of running in any device that
+         would otherwise be managed by an NMS, and that it can coexist
+         with an NMS and with protocols such as SNMP and NETCONF.
+
+   SN7.  Specific autonomic features are expected to be implemented by
+         individual ASAs, but the protocol must be general enough to
+         allow them.  Some examples follow:
+
+         *  Dependencies and conflicts: In order to decide upon a
+            configuration for a given device, the device may need
+            information from neighbors.  This can be established through
+            the negotiation procedure, or through synchronization if
+            that is sufficient.  However, a given item in a neighbor may
+            depend on other information from its own neighbors, which
+            may need another negotiation or synchronization procedure to
+            obtain or decide.  Therefore, there are potential
+            dependencies and conflicts among negotiation or
+            synchronization procedures.  Resolving dependencies and
+            conflicts is a matter for the individual ASAs involved.  To
+            allow this, there need to be clear boundaries and
+            convergence mechanisms for negotiations.  Also some
+            mechanisms are needed to avoid loop dependencies or
+            uncontrolled growth in a tree of dependencies.  It is the
+            ASA designer's responsibility to avoid or detect looping
+            dependencies or excessive growth of dependency trees.  The
+            protocol's role is limited to bilateral signaling between
+            ASAs and the avoidance of loops during bilateral signaling.
+
+         *  Recovery from faults and identification of faulty devices
+            should be as automatic as possible.  The protocol's role is
+            limited to discovery, synchronization, and negotiation.
+            These processes can occur at any time, and an ASA may need
+            to repeat any of these steps when the ASA detects an event
+            such as a negotiation counterpart failing.
+
+         *  Since a major goal is to minimize human intervention, it is
+            necessary that the network can in effect "think ahead"
+            before changing its parameters.  One aspect of this is an
+            ASA that relies on a knowledge base to predict network
+            behavior.  This is out of scope for the signaling protocol.
+            However, another aspect is forecasting the effect of a
+            change by a "dry run" negotiation before actually installing
+            the change.  Signaling a dry run is therefore a desirable
+            feature of the protocol.
+
+         Note that management logging, monitoring, alerts, and tools for
+         intervention are required.  However, these can only be features
+         of individual ASAs, not of the protocol itself.  Another
+         document [RFC8368] discusses how such agents may be linked into
+         conventional Operations, Administration, and Maintenance (OAM)
+         systems via an Autonomic Control Plane [RFC8994].
+
+   SN8.  The protocol will be able to deal with a wide variety of
+         technical objectives, covering any type of network parameter.
+         Therefore the protocol will need a flexible and easily
+         extensible format for describing objectives.  At a later stage,
+         it may be desirable to adopt an explicit information model.
+         One consideration is whether to adopt an existing information
+         model or to design a new one.
+
+B.3.  Specific Technical Requirements
+
+   T1.   It should be convenient for ASA designers to define new
+         technical objectives and for programmers to express them,
+         without excessive impact on runtime efficiency and footprint.
+         In particular, it should be convenient for ASAs to be
+         implemented independently of each other as user-space programs
+         rather than as kernel code, where such a programming model is
+         possible.  The classes of device in which the protocol might
+         run is discussed in [RFC8993].
+
+   T2.   The protocol should be easily extensible in case the initially
+         defined discovery, synchronization, and negotiation mechanisms
+         prove to be insufficient.
+
+   T3.   To be a generic platform, the protocol payload format should be
+         independent of the transport protocol or IP version.  In
+         particular, it should be able to run over IPv6 or IPv4.
+         However, some functions, such as multicasting on a link, might
+         need to be IP version dependent.  By default, IPv6 should be
+         preferred.
+
+   T4.   The protocol must be able to access off-link counterparts via
+         routable addresses, i.e., must not be restricted to link-local
+         operation.
+
+   T5.   It must also be possible for an external discovery mechanism to
+         be used, if appropriate for a given technical objective.  In
+         other words, GRASP discovery must not be a prerequisite for
+         GRASP negotiation or synchronization.
+
+   T6.   The protocol must be capable of distinguishing multiple
+         simultaneous operations with one or more peers, especially when
+         wait states occur.
+
+   T7.   Intent: Although the distribution of Intent is out of scope for
+         this document, the protocol must not by design exclude its use
+         for Intent distribution.
+
+   T8.   Management monitoring, alerts, and intervention: Devices should
+         be able to report to a monitoring system.  Some events must be
+         able to generate operator alerts, and some provision for
+         emergency intervention must be possible (e.g., to freeze
+         synchronization or negotiation in a misbehaving device).  These
+         features might not use the signaling protocol itself, but its
+         design should not exclude such use.
+
+   T9.   Because this protocol may directly cause changes to device
+         configurations and have significant impacts on a running
+         network, all protocol exchanges need to be fully secured
+         against forged messages and man-in-the-middle attacks, and
+         secured as much as reasonably possible against denial-of-
+         service attacks.  There must also be an encryption mechanism to
+         resist unwanted monitoring.  However, it is not required that
+         the protocol itself provides these security features; it may
+         depend on an existing secure environment.
+
+Appendix C.  Capability Analysis of Current Protocols
+
+   This appendix discusses various existing protocols with properties
+   related to the requirements described in Appendix B.  The purpose is
+   to evaluate whether any existing protocol, or a simple combination of
+   existing protocols, can meet those requirements.
+
+   Numerous protocols include some form of discovery, but these all
+   appear to be very specific in their applicability.  Service Location
+   Protocol (SLP) [RFC2608] provides service discovery for managed
+   networks, but it requires configuration of its own servers.  DNS-
+   Based Service Discovery (DNS-SD) [RFC6763] combined with Multicast
+   DNS (mDNS) [RFC6762] provides service discovery for small networks
+   with a single link layer.  [RFC7558] aims to extend this to larger
+   autonomous networks, but this is not yet standardized.  However, both
+   SLP and DNS-SD appear to target primarily application-layer services,
+   not the layer 2 and 3 objectives relevant to basic network
+   configuration.  Both SLP and DNS-SD are text-based protocols.
+
+   Simple Network Management Protocol (SNMP) [RFC3416] uses a command/
+   response model not well suited for peer negotiation.  NETCONF
+   [RFC6241] uses an RPC model that does allow positive or negative
+   responses from the target system, but this is still not adequate for
+   negotiation.
+
+   There are various existing protocols that have elementary negotiation
+   abilities, such as Dynamic Host Configuration Protocol for IPv6
+   (DHCPv6) [RFC8415], Neighbor Discovery (ND) [RFC4861], Port Control
+   Protocol (PCP) [RFC6887], Remote Authentication Dial-In User Service
+   (RADIUS) [RFC2865], Diameter [RFC6733], etc.  Most of them are
+   configuration or management protocols.  However, they either provide
+   only a simple request/response model in a master/slave context or
+   very limited negotiation abilities.
+
+   There are some signaling protocols with an element of negotiation.
+   For example, Resource ReSerVation Protocol (RSVP) [RFC2205] was
+   designed for negotiating quality-of-service parameters along the path
+   of a unicast or multicast flow.  RSVP is a very specialized protocol
+   aimed at end-to-end flows.  A more generic design is General Internet
+   Signalling Transport (GIST) [RFC5971]; however, it tries to solve
+   many problems, making it complex, and is also aimed at per-flow
+   signaling across many hops rather than at device-to-device signaling.
+   However, we cannot completely exclude extended RSVP or GIST as a
+   synchronization and negotiation protocol.  They do not appear to be
+   directly usable for peer discovery.
+
+   RESTCONF [RFC8040] is a protocol intended to convey NETCONF
+   information expressed in the YANG language via HTTP, including the
+   ability to transit HTML intermediaries.  While this is a powerful
+   approach in the context of centralized configuration of a complex
+   network, it is not well adapted to efficient interactive negotiation
+   between peer devices, especially simple ones that might not include
+   YANG processing already.
+
+   The Distributed Node Consensus Protocol (DNCP) [RFC7787] is defined
+   as a generic form of a state synchronization protocol, with a
+   proposed usage profile being the Home Networking Control Protocol
+   (HNCP) [RFC7788] for configuring Homenet routers.  A specific
+   application of DNCP for Autonomic Networking was proposed in [ADNCP].
+   According to [RFC7787]:
+
+   |  DNCP is designed to provide a way for each participating node to
+   |  publish a set of TLV (Type-Length-Value) tuples (at most 64 KB)
+   |  and to provide a shared and common view about the data
+   |  published...
+   |  
+   |  DNCP is most suitable for data that changes only infrequently...
+   |  
+   |  If constant rapid state changes are needed, the preferable choice
+   |  is to use an additional point-to-point channel...
+
+   Specific features of DNCP include:
+
+   *  Every participating node has a unique node identifier.
+
+   *  DNCP messages are encoded as a sequence of TLV objects and sent
+      over unicast UDP or TCP, with or without (D)TLS security.
+
+   *  Multicast is used only for discovery of DNCP neighbors when lower
+      security is acceptable.
+
+   *  Synchronization of state is maintained by a flooding process using
+      the Trickle algorithm.  There is no bilateral synchronization or
+      negotiation capability.
+
+   *  The HNCP profile of DNCP is designed to operate between directly
+      connected neighbors on a shared link using UDP and link-local IPv6
+      addresses.
+
+   DNCP does not meet the needs of a general negotiation protocol
+   because it is designed specifically for flooding synchronization.
+   Also, in its HNCP profile, it is limited to link-local messages and
+   to IPv6.  However, at the minimum, it is a very interesting test case
+   for this style of interaction between devices without needing a
+   central authority, and it is a proven method of network-wide state
+   synchronization by flooding.
+
+   The Server Cache Synchronization Protocol (SCSP) [RFC2334] also
+   describes a method for cache synchronization and cache replication
+   among a group of nodes.
+
+   A proposal was made some years ago for an IP based Generic Control
+   Protocol (IGCP) [IGCP].  This was aimed at information exchange and
+   negotiation but not directly at peer discovery.  However, it has many
+   points in common with the present work.
+
+   None of the above solutions appears to completely meet the needs of
+   generic discovery, state synchronization, and negotiation in a single
+   solution.  Many of the protocols assume that they are working in a
+   traditional top-down or north-south scenario, rather than a fluid
+   peer-to-peer scenario.  Most of them are specialized in one way or
+   another.  As a result, we have not identified a combination of
+   existing protocols that meets the requirements in Appendix B.  Also,
+   we have not identified a path by which one of the existing protocols
+   could be extended to meet the requirements.
+
+Acknowledgments
+
+   A major contribution to the original draft version of this document
+   was made by Sheng Jiang, and significant contributions were made by
+   Toerless Eckert.  Significant early review inputs were received from
+   Joel Halpern, Barry Leiba, Charles E. Perkins, and Michael
+   Richardson.  William Atwood provided important assistance in
+   debugging a prototype implementation.
+
+   Valuable comments were received from Michael Behringer, Jéferson
+   Campos Nobre, Laurent Ciavaglia, Zongpeng Du, Yu Fu, Joel Jaeggli,
+   Zhenbin Li, Dimitri Papadimitriou, Pierre Peloso, Reshad Rahman,
+   Markus Stenberg, Martin Stiemerling, Rene Struik, Martin Thomson,
+   Dacheng Zhang, and participants in the Network Management Research
+   Group, the ANIMA Working Group, and the IESG.
+
+Authors' Addresses
+
+   Carsten Bormann
+   Universität Bremen TZI
+   Postfach 330440
+   D-28359 Bremen
+   Germany
+
+   Email: cabo@tzi.org
+
+
+   Brian Carpenter (editor)
+   School of Computer Science
+   University of Auckland
+   PB 92019
+   Auckland 1142
+   New Zealand
+
+   Email: brian.e.carpenter@gmail.com
+
+
+   Bing Liu (editor)
+   Huawei Technologies Co., Ltd
+   Q14, Huawei Campus
+   Hai-Dian District
+   No.156 Beiqing Road
+   Beijing
+   100095
+   China
+
+   Email: leo.liubing@huawei.com