<?xml version='1.0' encoding='ascii'?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc subcompact="no"?>
<?rfc compact="yes"?>
<?rfc comments="yes"?>
<rfc category="std" ipr="trust200902" docName="draft-taylor-manet-dlep-dsa-01" obsoletes="" updates="" submissionType="IETF" xml:lang="en">
  <front>
    <title>DLEP Destination Service Announcement</title>
    <author initials="R." surname="Taylor" fullname="Rick Taylor">
      <organization>Airbus Defence &amp; Space</organization>
      <address>
        <postal>
          <street>Quadrant House</street>
          <street>Celtic Springs</street>
          <street>Coedkernew</street>
          <city>Newport</city>
          <code>NP10 8FZ</code>
          <country>UK</country>
        </postal>
        <email>rick.taylor@airbus.com</email>
      </address>
    </author>
    <date/>
    <area>Routing</area>
    <workgroup>Mobile Ad hoc Networks Working Group</workgroup>
    <abstract><!--This document was prepared using Pandoc2rfc, https://github.com/miekg/pandoc2rfc --><t>When using the Dynamic Link Exchange Protocol (DLEP) <xref target="RFC8175" pageno="false" format="default"/> to bootstrap neighbour discovery for routing protocols there is no indication in the core DLEP protocol of the services of the router announced at a destination. This forces an implementation to either rely on a priori configuration or use heuristic probing of well-known ports to discover potential routing peers.  </t><t>This document defines an extension to DLEP to enable a router to advertise its active services to its peer modem, allowing a connected remote modem to announce the services of a router in a DLEP destination message to its peer, removing the need for service discovery between routing peers. The mechanism is designed to be sufficiently generic to allow the advertisement of network services beyond routing protocols, enabling the fast bootstrapping of other protocols such as messaging protocols or header compression.  </t> </abstract>
  </front>
  <middle><!--This document was prepared using Pandoc2rfc, https://github.com/miekg/pandoc2rfc --><section title="Introduction" anchor="introduction" toc="default"><t>One of the popular uses of the Dynamic Link Exchange Protocol (DLEP) <xref target="RFC8175" pageno="false" format="default"/> is to improve the association time of routing protocol peers. When a DLEP Destination Up Message is received by a router, routing protocol instances can be informed of potential peers, enhancing or avoiding the use of timed Hello messages, speeding up the convergence of nodes. In practice this behaviour has many benefits, but does also have a downside: When a new potential peer is announced via DLEP, every routing protocol active on the receiver attempts to communicate with the potential peer trying to form a neighbour association, with no prior indication if the destination router supports the routing protocol.  Particularly in a heterogeneous network when the capabilities of different routers is not known in advance, as links form between routers each new router may be bombarded by requests to form a routing adjacency from every protocol implementation active on every other reachable router in the network.  </t><t>This document defines an extension to DLEP that introduces a new Data Item to allow a router to announce to its DLEP session peer, during Session Initialization, the set of services that it supports, such as the running routing protocols. A modem supporting this extension can transmit this information over the air using whatever internal protocol it uses for signalling to all connected modems.  Every other modem can then attach the received set of services to the DLEP Destination Up Message that it then sends to its DLEP session peer router. Any changes to the set of services can also be sent via the Session Update Message, resulting in a corresponding DLEP Destination Update Message.  </t><t>This service announcement can be used to advertise the availability of more than just routing protocols. Other protocols that need peers for their operation, such as peer-to-peer messaging applications, or discovering the presence of matching protocol compression proxies, can also use the same mechanism.  </t><section title="Requirements" anchor="requirements" toc="default"><t>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, RFC 2119 <xref target="RFC2119" pageno="false" format="default"/>.  </t></section></section><section title="Assumptions" anchor="assumptions" toc="default"><t>As an extension to DLEP, this document assumes any implementation of this extension correctly implements the core DLEP specification defined in <xref target="RFC8175" pageno="false" format="default"/>. No other DLEP extensions are required.  </t><t>This extension also assumes that supporting modems have the facility to transmit the set of services described by an attached router to other modems in the network.  </t></section><section title="Service Descriptors" anchor="service_desc" toc="default"><t>Services active on a router are described using Service Descriptors, that are modelled on DNS SRV records <xref target="RFC2782" pageno="false" format="default"/>, but with some important differences. A Service Descriptor is a string that describes the name of the service, the IP protocol used by the service, optionally the name of the service instance, and optionally the port number used by the service if not the registered default port.  </t><t>The format of a Service Descriptor string is defined as: </t><figure title="" suppress-title="false" align="left" alt="" width="" height=""><artwork xml:space="preserve" name="" type="" align="left" alt="" width="" height="">
 Service.Protocol.Name:Port
</artwork></figure><t><list style="hanging"><t hangText="Service:">The symbolic name of the desired service, as defined in Assigned Numbers <xref target="RFC1700" pageno="false" format="default"/> or locally.  The maximum length of a Service is 15 characters. The Service is case insensitive.  </t><t hangText="Protocol:">The symbolic name of the desired protocol. 'tcp' and 'udp' are at present the most useful values for this field, though any name defined by Assigned Numbers or locally may be used (as for Service). The Protocol is case insensitive.  </t><t hangText="Name:">OPTIONAL. The Name of the instance of the service active at the destination. Unlike DNS SRV records, this name MAY not be a DNS name, but it MUST use the DNS name syntax. The Name is case insensitive.  </t><t hangText="Port:">OPTIONAL. The port on router of this service. The range is 1-65535. This field SHOULD only be specified if the port differs from the value specified in Assigned Numbers.  </t></list></t><t>As mentioned above, the Name field in a service descriptor MUST follow the DNS name syntax, but MAY not be a DNS name, as DLEP is often deployed in environments where DNS is not available. However, the Name field still serves a purpose as a descriminiator for different instances of a service and could be used by a receiving router to make peering decisions.  </t><t>When a service operates as an IP protocol, rather than TCP, UDP, SCTP or DCCP, such as OSPF <xref target="RFC2328" pageno="false" format="default"/>, the Protocol field MUST be specified as 'ip'.  </t><section title="Service Descriptor ABNF" anchor="service-descriptor-abnf" toc="default"><figure title="" suppress-title="false" align="left" alt="" width="" height=""><artwork xml:space="preserve" name="" type="" align="left" alt="" width="" height="">
service-descriptor = service-part "." protocol-part
                      [ "." name-part [ ":" alt-port ] ]

service-part       = *( 1*DIGIT [ "-" ] ) ALPHA
                      *( [ "-" ] ALNUM )   ; Maximum 15 characters

protocol-part      = "tcp" / "udp" / "sctp" / "dccp" / "ip"

name-part          = label *( "." label )
label              = ALNUM *( [ "-" ] ALNUM )

alt-port           = %x31-39 *DIGIT         ; Values of 1-65535

ALNUM              = ALPHA / DIGIT
ALPHA              = %x41-5A / %x61-7A    ; A-Z / a-z [RFC5234]
DIGIT              = %x30-39              ; 0-9       [RFC5234]
</artwork></figure></section></section><section title="Operation" anchor="operation" toc="default"><t>To use this extension, as with all DLEP extensions, the extension MUST be announced during DLEP session initialization. A router advertises support by including the value 'Destination Service Announcement' (TBD1) in the Extension Data Item within the Session Intitialization Message. A modem advertises support by including the value 'Destination Service Announcement' (TBD1) in the Extension Data Item within the Session Intitialization Response Message. If both DLEP peers advertise support for this extension then the Data Items described in this document MAY be used. If a modem does not announce support for this extension, the router MUST NOT include any Data Items described in this document in any DLEP Message.  </t><t>If a router announces support for the 'Destination Service Announcement' extension in the Session Initialization Message, it MAY incude one or more <xref target="v4_dca_di" pageno="false" format="default">IPv4 Destination Service Data Items</xref> and/or [IPv6 Destination Service Data Items] (#v6_dca_di) in the Session Initialization Message, as a DLEP compliant modem implementation that does not support this extension will correctly ignore the unknown.  </t><section title="Service Description Information Base" anchor="sdib" toc="default"><t>In order to describe the correct operation of this extension, a conceptual service descriptor information base is described that contains the set of service descriptors current announced by a router during a DLEP session. A modem that supports this extension is described as maintaining a service descriptor information base recording the set of service descriptors advertised by its local router, ready to relay this information to any over-the-air peers that support this extension with which it forms a link. An implementation is, of course, free to choose alternative ways of providing compliant functionality.  </t><t>When a modem receives a Session Initialization Message from its local router containing an Extension Supported Data Item announcing its support for this extension, and one or more Destination Service Data Items, it records this service information in the service descriptor information base.  </t><t>In order to retract a previously advertised service or announce the availability of a new service, the router sends a new Session Update Message to the modem containing a relevant Destination Service Data Item using the Add/Remove flag to indicate the change.  </t><t>When a modem receives a Session Update Message from its local router containing one or more Destination Service Data Items, it updates the set of service descriptors in its service descriptor information base.  </t></section><section title="Over-the-air signalling" anchor="over-the-air-signalling" toc="default"><t>When a modem forms a new link with a remote modem, it sends the contents of the service descriptor information base to the remote modem. How this information is sent is an implementation detail that is out of scope of this document.  </t><t>When a modem supporting this extension receives a set of service descriptors from a remote modem, it SHOULD propogate this information to its DLEP peer router by including one or more Destination Service Data Items in the associated Destination Up Message.  </t><t>When the service descriptor information base of a modem is updated, as a result of a Session Update Message containing one or more Service Description Data Items, it informs all currently connected remote modems of the change. Each remote modem that receives such a notification SHOULD announce the change in remote router services by sending a Destination Update Message to their attached router containing one or more Destination Service Data Items describing the update in services.  </t></section></section><section title="DLEP Data Items for Destination Service Announcement" anchor="dlep-data-items-for-destination-service-announcement" toc="default"><t>This extension introduces two new DLEP Data Items, described below.  Both Data Items carry information about destination services, one for IPv4, the other for IPv6.  </t><t>One or more instances of either or both Destination Service Data Items MAY appear in the DLEP Session Initialization, Session Update, Destination Up, and Destination Update Messages.  </t><t>A router MAY use one or more instances of either or both Data Items in the DLEP Session Initialization Message to advertise all services that are currently available at the router, and a router MAY use one or more instances of either or both Data Items in the DLEP Session Update Message to advertise a change in the services that are currently available at the router.  </t><t>A modem MAY include one or more instances of either or both Data Items in the DLEP Destination Up and Destination Update Messages to inform its DLEP session peer of the services available at a remote DLEP destination.  </t><t>A router announcing services MUST NOT report the same combination of address and service in more than one Data Item per Message. A modem that receives multiple Data Items with the same address and service descriptor in a single Message SHOULD treat this as an invalid Data Item in the Message, and react as defined in the core DLEP specification.  </t><t>A modem receiving a Destination Service Data Item with the Add/Remove flag cleared (zero) retracts any previously announced service from its service descriptor information base, and MUST inform all connected remote modems of the change. If a retraction of a destination service does not match a previous announcement, the implementation SHOULD treat this as an invalid Data Item and react as defined in the core DLEP specification.  </t><t>Destination Service Data Items MUST NOT be included in any DLEP Destination Message referring to a multicast destination.  </t><section title="IPv4 Destination Service Data Item" anchor="v4_dca_di" toc="default"><t>The IPv4 Destination Service Data Item contains the following fields: </t><figure title="" suppress-title="false" align="left" alt="" width="" height=""><artwork xml:space="preserve" name="" type="" align="left" alt="" width="" height="">
 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data Item Type                | Length                        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags         |       IPv4 Address                            :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
:   (cont)...   |  Service Descriptor...                        :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork></figure><t><list style="hanging"><t hangText="Data Item Type:">TBD </t><t hangText="Length:">5 + the length of Service Descriptor in octets.  </t><t hangText="Flags:">Flags field, defined below.  </t><t hangText="IPv4 Address:">An IPv4 address used by the announced service.  </t><t hangText="Service Descriptor:">A string of characters, as defined in <xref target="service_desc" pageno="false" format="default"/>.  </t></list></t><t>The Flags field is defined as: </t><figure title="" suppress-title="false" align="left" alt="" width="" height=""><artwork xml:space="preserve" name="" type="" align="left" alt="" width="" height="">
 0 1 2 3 4 5 6 7 
+-+-+-+-+-+-+-+-+
</artwork></figure><t>| Reserved |A| +-+-+-+-+-+-+-+-+ </t><t><list style="hanging"><t hangText="A:">Add/Remove flag, indicating whether this service is being announced as running (1), or whether a previously announced active service is being announced as no longer avaiable at the destination (0).  </t><t hangText="Reserved:">MUST be zero. Reserved for future use.  </t></list></t><t>An implementation MUST NOT assume the Service Descriptor field is NUL-terminated.  </t></section><section title="IPv6 Destination Service Data Item" anchor="v6_dca_di" toc="default"><t>The IPv6 Destination Service Data Item contains the following fields: </t><figure title="" suppress-title="false" align="left" alt="" width="" height=""><artwork xml:space="preserve" name="" type="" align="left" alt="" width="" height="">
 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data Item Type                | Length                        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags         |               IPv6 Address                    :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                        IPv6 Address                           :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
:                        IPv6 Address                           :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
:                        IPv6 Address                           :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
:                        IPv6 Address                           :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
:               |     Service Descriptor...                     :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork></figure><t><list style="hanging"><t hangText="Data Item Type:">TBD </t><t hangText="Length:">17 + the length of Service Descriptor in octets.  </t><t hangText="Flags:">Flags field, defined below.  </t><t hangText="IPv6 Address:">An IPv6 address used by the announced service.  </t><t hangText="Service Descriptor:">A string of characters, as defined in <xref target="service_desc" pageno="false" format="default"/>.  </t></list></t><t>The Flags field is defined as: </t><figure title="" suppress-title="false" align="left" alt="" width="" height=""><artwork xml:space="preserve" name="" type="" align="left" alt="" width="" height="">
 0 1 2 3 4 5 6 7 
+-+-+-+-+-+-+-+-+
|   Reserved  |A|
+-+-+-+-+-+-+-+-+
</artwork></figure><t><list style="hanging"><t hangText="A:">Add/Remove flag, indicating whether this service is being announced as running (1), or whether a previously announced active service is being announced as no longer avaiable at the destination (0).  </t><t hangText="Reserved:">MUST be zero. Reserved for future use.  </t></list></t><t>An implementation MUST NOT assume the Service Descriptor field is NUL-terminated.  </t></section></section><section title="Security Considerations" anchor="security-considerations" toc="default"><t>This extension introduces a mechanism for routers to announce their services to other potential peers. In cases where an adversary can manipulate the list of services, by either accessing the network segment between router or modem, or by intercepting any signalling between modems, this list of services may be altered if the link is not secured.  </t><t>Therefore: </t><t><list style="symbols"><t>Any implementation MUST follow the security considerations defined in the core DLEP protocol.  </t><t>Any implementation, when used in an environment where the signalling between modems may be open to interception, MUST apply any relevant security considerations for the modem to modem signalling.  </t></list></t><t>It should be also noted that a malicious router could attempt to deny service to a network by rapidly and repeatedly announcing a varying set of services, forcing the modems to flood the over the air signalling with updates. A modem implementation MUST be aware of this risk and implement mitigations, such as aggregating the changes and trottling the updates propogated between devices.  </t></section><section title="IANA Considerations" anchor="iana-considerations" toc="default"><t>This section specifies requests to IANA.  </t><section title="Registrations" anchor="registrations" toc="default"><t>This specification defines two new Data Items for DLEP.  Assignments from the DLEP Data Item registry are requested for: </t><t><list style="symbols"><t>IPv6 Destination Service </t><t>IPv4 Destination Service </t></list></t><t>The specification also defined an extension to the DLEP protocol.  An assignment from the DLEP extension registry is requested for 'Destination Service Announcement'.  </t></section></section><section title="Acknowledgements" anchor="acknowledgements" toc="default"><t>Many thanks to Steve Loates, Stan Ratliff and Henning Rogge for their reviews and feedback.  </t></section> </middle>
  <back><references title="Normative References"><reference anchor="RFC1700" target="http://www.rfc-editor.org/info/rfc1700" quote-title="true"><front><title>Assigned Numbers</title><author initials="J." surname="Reynolds" fullname="J. Reynolds"><organization/></author><author initials="J." surname="Postel" fullname="J. Postel"><organization/></author><date year="1994" month="October"/><abstract><t>This RFC is a snapshot of the ongoing process of the assignment of protocol parameters for the Internet protocol suite.  To make the current information readily available the assignments are kept up-to- date in a set of online text files. This memo is a status report on the parameters (i.e., numbers and keywords) used in protocols in the Internet community.</t></abstract></front><seriesInfo name="RFC" value="1700"/><seriesInfo name="DOI" value="10.17487/RFC1700"/></reference> <reference anchor="RFC2119" target="http://www.rfc-editor.org/info/rfc2119" quote-title="true"><front><title>Key words for use in RFCs to Indicate Requirement Levels</title><author initials="S." surname="Bradner" fullname="S. Bradner"><organization/></author><date year="1997" month="March"/><abstract><t>In many standards track documents several words are used to signify the requirements in the specification.  These words are often capitalized. This document defines these words as they should be interpreted in IETF documents.  This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t></abstract></front><seriesInfo name="BCP" value="14"/><seriesInfo name="RFC" value="2119"/><seriesInfo name="DOI" value="10.17487/RFC2119"/></reference> <reference anchor="RFC5234" target="http://www.rfc-editor.org/info/rfc5234" quote-title="true"><front><title>Augmented BNF for Syntax Specifications: ABNF</title><author initials="D." surname="Crocker" fullname="D. Crocker" role="editor"><organization/></author><author initials="P." surname="Overell" fullname="P. Overell"><organization/></author><date year="2008" month="January"/><abstract><t>Internet technical specifications often need to define a formal syntax.  Over the years, a modified version of Backus-Naur Form (BNF), called Augmented BNF (ABNF), has been popular among many Internet specifications.  The current specification documents ABNF. It balances compactness and simplicity with reasonable representational power.  The differences between standard BNF and ABNF involve naming rules, repetition, alternatives, order-independence, and value ranges.  This specification also supplies additional rule definitions and encoding for a core lexical analyzer of the type common to several Internet specifications.  [STANDARDS-TRACK]</t></abstract></front><seriesInfo name="STD" value="68"/><seriesInfo name="RFC" value="5234"/><seriesInfo name="DOI" value="10.17487/RFC5234"/></reference> <reference anchor="RFC8175" target="http://www.rfc-editor.org/info/rfc8175" quote-title="true"><front><title>Dynamic Link Exchange Protocol (DLEP)</title><author initials="S." surname="Ratliff" fullname="S. Ratliff"><organization/></author><author initials="S." surname="Jury" fullname="S. Jury"><organization/></author><author initials="D." surname="Satterwhite" fullname="D. Satterwhite"><organization/></author><author initials="R." surname="Taylor" fullname="R. Taylor"><organization/></author><author initials="B." surname="Berry" fullname="B. Berry"><organization/></author><date year="2017" month="June"/><abstract><t>When routing devices rely on modems to effect communications over wireless links, they need timely and accurate knowledge of the characteristics of the link (speed, state, etc.) in order to make routing decisions.  In mobile or other environments where these characteristics change frequently, manual configurations or the inference of state through routing or transport protocols does not allow the router to make the best decisions.  This document introduces a new protocol called the Dynamic Link Exchange Protocol (DLEP), which provides a bidirectional, event-driven communication channel between the router and the modem to facilitate communication of changing link characteristics.</t></abstract></front><seriesInfo name="RFC" value="8175"/><seriesInfo name="DOI" value="10.17487/RFC8175"/></reference> </references><references title="Informative References"><reference anchor="RFC2782" target="http://www.rfc-editor.org/info/rfc2782" quote-title="true"><front><title>A DNS RR for specifying the location of services (DNS SRV)</title><author initials="A." surname="Gulbrandsen" fullname="A. Gulbrandsen"><organization/></author><author initials="P." surname="Vixie" fullname="P. Vixie"><organization/></author><author initials="L." surname="Esibov" fullname="L. Esibov"><organization/></author><date year="2000" month="February"/><abstract><t>This document describes a DNS RR which specifies the location of the server(s) for a specific protocol and domain.  [STANDARDS-TRACK]</t></abstract></front><seriesInfo name="RFC" value="2782"/><seriesInfo name="DOI" value="10.17487/RFC2782"/></reference> <reference anchor="RFC2328" target="http://www.rfc-editor.org/info/rfc2328" quote-title="true"><front><title>OSPF Version 2</title><author initials="J." surname="Moy" fullname="J. Moy"><organization/></author><date year="1998" month="April"/><abstract><t>This memo documents version 2 of the OSPF protocol.  OSPF is a link- state routing protocol.  [STANDARDS-TRACK]</t></abstract></front><seriesInfo name="STD" value="54"/><seriesInfo name="RFC" value="2328"/><seriesInfo name="DOI" value="10.17487/RFC2328"/></reference> </references><!--This document was prepared using Pandoc2rfc, https://github.com/miekg/pandoc2rfc --> </back>
</rfc>
