Skip to main content

IPv6 DOTS Signal Option

Document Type Expired Internet-Draft (individual)
Expired & archived
Authors Jérôme François , Abdelkader Lahmadi , Marco Davids
Last updated 2017-11-13 (Latest revision 2017-05-03)
RFC stream (None)
Intended RFC status (None)
Stream Stream state (No stream defined)
Consensus boilerplate Unknown
RFC Editor Note (None)
IESG IESG state Expired
Telechat date (None)
Responsible AD (None)
Send notices to (None)

This Internet-Draft is no longer active. A copy of the expired Internet-Draft is available in these formats:


DOTS client signal using original signal communication channel can expect service degradation and even service disruption as any other service over Internet but in more severe conditions because the signal may have to be transmitted over congested paths due to the denial-of-service attack. This document specifies a fall-back asynchronous mechanism using an intermediate agent to store DOTS signal information during a limited period of time. This mechanism allows a DOTS server to request a signal information stored by a DOTS client when no heartbeat is received from the DOTS client. This intermediate agent called DOTS Signal Repository have to be connected to the DOTS client and server independently. The repository must be located and/or reached through one or multiple network paths, preferably as most as possible disjoint from regular signal channel, in order to increase its reachability. The document introduces a set of support protocols to build the asynchronous communication between the DOTS cient, server and the repository.


Jérôme François
Abdelkader Lahmadi
Marco Davids

(Note: The e-mail addresses provided for the authors of this Internet-Draft may no longer be valid.)