[Docs] [txt|pdf|xml|html] [Tracker] [Email] [Nits]

Versions: 00

Network Working Group                                        S. Cheshire
Internet-Draft                                                Apple Inc.
Intended status: Standards Track                                T. Lemon
Expires: January 4, 2018                                   Nominum, Inc.
                                                            July 3, 2017


                     Multicast DNS Discovery Relay
                     draft-sctl-dnssd-mdns-relay-00

Abstract

   This document extends the Discovery Proxy for Multicast DNS-Based
   Service Discovery specification.  It describes a lightweight relay
   mechanism, a Discovery Relay, which allows Discovery Proxies to
   provide service on links to which the hosts on which they are running
   are not directly attached.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on January 4, 2018.

Copyright Notice

   Copyright (c) 2017 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
   (http://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




Cheshire & Lemon         Expires January 4, 2018                [Page 1]


Internet-Draft            mDNS Discovery Relay                 July 2017


   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   4
   3.  Protocol Overview . . . . . . . . . . . . . . . . . . . . . .   5
     3.1.  Connections between Discovery and Discovery Relays  . . .   5
     3.2.  mDNS Messages On Links  . . . . . . . . . . . . . . . . .   6
   4.  Orchestration . . . . . . . . . . . . . . . . . . . . . . . .   6
     4.1.  Orchestration System Functional Overview  . . . . . . . .   7
     4.2.  Orchestration Primitives  . . . . . . . . . . . . . . . .   7
       4.2.1.  Link Present  . . . . . . . . . . . . . . . . . . . .   7
       4.2.2.  Link Remove . . . . . . . . . . . . . . . . . . . . .   8
       4.2.3.  Discovery Proxy Available . . . . . . . . . . . . . .   8
       4.2.4.  Discovery Proxy Resigning . . . . . . . . . . . . . .   8
       4.2.5.  Discovery Relay Available . . . . . . . . . . . . . .   9
       4.2.6.  Discovery Relay Resigning . . . . . . . . . . . . . .   9
     4.3.  Orchestration System Behavior . . . . . . . . . . . . . .  10
       4.3.1.  Link Present  . . . . . . . . . . . . . . . . . . . .  10
       4.3.2.  Link Remove . . . . . . . . . . . . . . . . . . . . .  10
       4.3.3.  Discovery Proxy Available . . . . . . . . . . . . . .  10
       4.3.4.  Discovery Proxy Resigning . . . . . . . . . . . . . .  11
       4.3.5.  Discovery Relay Available . . . . . . . . . . . . . .  11
       4.3.6.  Discovery Relay Resigning . . . . . . . . . . . . . .  12
       4.3.7.  Node Available  . . . . . . . . . . . . . . . . . . .  12
       4.3.8.  Node Resigning  . . . . . . . . . . . . . . . . . . .  12
     4.4.  Discovery Proxy Performer Behavior  . . . . . . . . . . .  12
       4.4.1.  Link Present  . . . . . . . . . . . . . . . . . . . .  13
       4.4.2.  Link Removed  . . . . . . . . . . . . . . . . . . . .  13
       4.4.3.  Discovery Proxy Available . . . . . . . . . . . . . .  13
       4.4.4.  Discovery Proxy Resigning . . . . . . . . . . . . . .  14
       4.4.5.  Discovery Relay Available . . . . . . . . . . . . . .  14
       4.4.6.  Discovery Relay Resigning . . . . . . . . . . . . . .  15
     4.5.  Discovery Relay Performer Behavior  . . . . . . . . . . .  15
       4.5.1.  Link Present  . . . . . . . . . . . . . . . . . . . .  15
       4.5.2.  Link Removed  . . . . . . . . . . . . . . . . . . . .  15
       4.5.3.  Discovery Proxy Available . . . . . . . . . . . . . .  15
       4.5.4.  Discovery Proxy Resigning . . . . . . . . . . . . . .  16
       4.5.5.  Discovery Relay Available . . . . . . . . . . . . . .  16
       4.5.6.  Discovery Relay Resigning . . . . . . . . . . . . . .  16
   5.  Connections between Discovery Proxies and Discovery Relays  .  16
   6.  Traffic from Relays to Proxies  . . . . . . . . . . . . . . .  18
   7.  Traffic from Proxies to Relays  . . . . . . . . . . . . . . .  19
   8.  Discovery Proxy Behavior  . . . . . . . . . . . . . . . . . .  19
   9.  Session Signaling TLVs  . . . . . . . . . . . . . . . . . . .  19
     9.1.  MDNS Link Request . . . . . . . . . . . . . . . . . . . .  19



Cheshire & Lemon         Expires January 4, 2018                [Page 2]


Internet-Draft            mDNS Discovery Relay                 July 2017


     9.2.  MDNS Link Invalid . . . . . . . . . . . . . . . . . . . .  19
     9.3.  MDNS Link Subscribed  . . . . . . . . . . . . . . . . . .  20
     9.4.  MDNS Message  . . . . . . . . . . . . . . . . . . . . . .  20
     9.5.  Layer 2 Source Address  . . . . . . . . . . . . . . . . .  20
     9.6.  IP Source Address . . . . . . . . . . . . . . . . . . . .  20
     9.7.  IP Source Port  . . . . . . . . . . . . . . . . . . . . .  21
     9.8.  Link Identifier . . . . . . . . . . . . . . . . . . . . .  21
     9.9.  MDNS Discontinue  . . . . . . . . . . . . . . . . . . . .  21
     9.10. IP Address Family . . . . . . . . . . . . . . . . . . . .  21
   10. Security Considerations . . . . . . . . . . . . . . . . . . .  21
   11. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  21
   12. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  22
   13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .  22
   14. References  . . . . . . . . . . . . . . . . . . . . . . . . .  22
     14.1.  Normative References . . . . . . . . . . . . . . . . . .  22
     14.2.  Informative References . . . . . . . . . . . . . . . . .  23
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  23

1.  Introduction

   The Discovery Proxy for Multicast DNS-Based Service Discovery
   [I-D.ietf-dnssd-hybrid] specification defines a mechanism for
   discovering services on a subnetted network using Multicast DNS
   (mDNS) [RFC6762], through the use of Discovery Proxies, which issue
   mDNS requests on various links in the network on behalf of a host
   attempting service discovery.

   In the original Discovery Proxy specification, it is assumed that for
   every link on which services will be discovered, a host will be
   present running a full Discovery Proxy.  This document introduces a
   lightweight Discovery Relay which can be used to provide discovery
   services on a link without requiring a full Discovery Proxy on every
   link.

   The Discovery Relay operates by listening for TCP connections from
   Discovery Proxies.  When a Discovery Proxy conneects, the connection
   is authenticated and secured using TLS.  The Discovery Proxy can then
   send messages that will be relayed to specified links.  The Discovery
   Proxy may also specify one or more links from which it wishes to
   receive mDNS traffic.  DNS Session Signaling
   [I-D.ietf-dnsop-session-signal] is used as a framework for conveying
   interface and IP header information associated with each message.

   The Discovery Relay functions essentially as a set of one or more
   virtual interfaces for the Discovery proxy, one on each link to which
   the Discovery Relay is connected.  In a complex network, it is
   possible that more than one Discovery Relay will be connected to the
   same link; in this case, the Discovery Proxy ideally should only be



Cheshire & Lemon         Expires January 4, 2018                [Page 3]


Internet-Draft            mDNS Discovery Relay                 July 2017


   using one such Relay Proxy per link, since using more than one will
   generate duplicate traffic.

   How such duplication is detected and avoided is out of scope for this
   document: in principle it could be detected using HNCP [RFC7788] or
   configured using some sort of orchestration software in conjunction
   with NETCONF [RFC6241] or CPE WAN Management Protocol [TR-069].

2.  Terminology

   The following definitions may be of use:

   mDNS Agent  A host which sends and/or responds to mDNS queries.

   Discovery Proxy  A network service which receives well-formed
      questions using the DNS protocol, performs multicast DNS queries
      to answer those questions, and responds with those answers using
      the DNS protocol.

   Discovery Relay  A network service which sends mDNS messages on
      behalf of a Discovery Proxy and relays mDNS messages to a
      Discovery Relay.

   link  A maximal set of network connection points such that any host
      connected to any connection point may send a packet to a host
      connected to any other connection point without the help of a
      layer 3 router.

   whitelist  A list of one or more IP addresses from which a Discovery
      Relay may accept connections.

   silently discard  When a message that is not supported or not
      permitted is received, and the required response to that message
      is to "silently discard" it, that means that no response is sent
      by the service that is discarding the message to the service that
      sent it.  The service receiving the message may log the event, and
      may also count such events: "silently" does not preclude such
      behavior.

   Director  A central or coordinated controlling function in an
      orchestrated network of Discovery Proxies and Discovery Relays
      (Section 4.1).

   Performer  The interface through which the Director directs the
      behavior of Discovery Proxies and Discovery Relays (Section 4.1).






Cheshire & Lemon         Expires January 4, 2018                [Page 4]


Internet-Draft            mDNS Discovery Relay                 July 2017


3.  Protocol Overview

   This document describes a way for Discovery Proxies to communicate
   with mDNS agents on networks to which they are not directly connected
   using a Discovery Relay.  As such, there are two parts to the
   protocol: connections between Discovery Proxies and Discovery Relays,
   and communications between Discovery Relays and mDNS agents.

3.1.  Connections between Discovery and Discovery Relays

   Discovery Relays listen for connections.  Connections between
   Discovery Proxies and Discovery Relays are established by Discovery
   Proxies.  Connections are authenticated and encrypted using TLS, with
   both client and server certificates.  Connections are long-lived: a
   Discovery Proxy is expected to send many queries over the same
   connection, and Discovery Relays will forward all mDNS traffic from
   subscribed interfaces over the connection.

   The stream encapsulated in TLS will carry DNS frames as in the DNS
   TCP protocol [RFC1035] Section 4.2.2.  However, all messages will be
   DNS Session Signaling messages [I-D.ietf-dnsop-session-signal].
   There will be three types of such messages:

   o  Subscribe messages from Discovery Proxy to Discovery Relay

   o  mDNS messages from Discovery Proxy to Discovery Relay

   o  mDNS messages from Discovery Relay to Discovery Proxy

   Subscribe messages from the Discovery Proxy to the Discovery Relay
   indicate to the Discovery Relay that mDNS messages from one or more
   specified links are to be relayed to the Discovery Proxy.

   mDNS messages from a Discovery Proxy to a Discovery Relay cause the
   Discovery Relay to re-transmit the mDNS message on one or more links
   to which the Discovery Relay host is directly attached.

   mDNS messages from a Discovery Relay to a Discovery Proxy are sent
   whenever an mDNS message is received on a link to which the Discovery
   Relay has subscribed.

   Discovery Relays are responsible for keeping connections alive when
   no traffic has been sent during a keepalive period
   [I-D.ietf-dnsop-session-signal] Section 4.







Cheshire & Lemon         Expires January 4, 2018                [Page 5]


Internet-Draft            mDNS Discovery Relay                 July 2017


3.2.  mDNS Messages On Links

   Discovery Relays listen for mDNS traffic on all configured links.
   When a mDNS message is received on a link, it is forwarded on every
   open Discovery Proxy connection that is subscribed to mDNS traffic on
   that link.  In the event of congestion, where a particular Discovery
   Proxy connection has no buffer space for an mDNS message that would
   otherwise be forwarded to it, the mDNS message is not forwarded to
   it.  Normal mDNS retry behavior is used to recover from this sort of
   packet loss.  Discovery Relays are not expected to buffer more than a
   few mDNS packets.

   Discovery Relays accept mDNS traffic from Discovery Proxies.  Such
   traffic is forwarded to zero or more more links to which the
   Discovery Relay host is directly connected.

4.  Orchestration

   In order for one or more Discovery Proxies to make use of one or more
   Discovery Relays to provide service discovery on one or more links,
   the set of links on which service will be provided must be known, the
   set of Discovery Relays for those links must be known, and the set of
   Discovery Proxies allowed to connect to those Discovery Relays must
   be known.  We assume that this information is maintained in some sort
   of orchestration system.

   Although it is of course possible to configure such an environment
   with a set of static configuration files, it is most useful to
   consider such a network to be dynamic, with links potentially being
   added and removed, Discovery Proxies being added and removed, and
   Discovery Relays being added and removed.  This document takes no
   position on which specific orchestration system will be used, but
   does specify the inputs and outputs of such a system that will be
   required for successful operation.  In the case of static
   configuration, these inputs and outputs are also the same; the only
   difference is that they do not change without human intervention.

   It is not strictly necessary that all participants in the
   orchestration process have complete information.  It may be desirable
   for example to have more than one Discovery Proxy managed by an
   orchestration system, but to have different Discovery Proxies support
   different links.  The set of primitives described here can be used to
   implement configurations where multiple Discovery Proxies are present
   and supporting disjoint, overlapping or identical sets of links.

   There is a special case of orchestration that may be desirable in
   some settings: when a node may need to be capable of providing either
   Discovery Proxy service or Discovery Relay service, and is configured



Cheshire & Lemon         Expires January 4, 2018                [Page 6]


Internet-Draft            mDNS Discovery Relay                 July 2017


   to provide Discovery Proxy service, it would be useful to have a way
   to automatically configure the Discovery Relay to use the Discovery
   Proxy just on that one node, without requiring a network-wide
   orchestration system.  In the case of a node that supports
   orchestration through HNCP, however, this is unnecessary: HNCP will
   work to provide orchestration even on a single node.

4.1.  Orchestration System Functional Overview

   Conceptually, the orchestration system has two parts: the part that
   manages the network, and the part an instance of which is present on
   each node in the network that is orchestrated by the system.  In a
   cooperative system such as HNCP [RFC7788], orchestration is done
   cooperatively, and the two functions are present on every
   participating node.  In a managed system using NETCONF [RFC6241], a
   central service pushes configuration information to managed nodes,
   and pulls status information from managed nodes.  For this
   discussion, which of these models is used (or whether some other
   model is used) is immaterial.  The functional division is the same in
   either case: conceptually there is one function that does the
   orchestration called the Director, and there are one more more
   functions to which the orchestration applies, called Performers.

   The Director is receptive to primitives from Performers.  Performers
   apply primitives announced to them by the Director, and announce
   primitives to the Director.  The Director announces primitives to
   Performers, based on its operating model and its configuration, based
   either in changes to the network or to announcements from Performers.

   It is permissible for nodes to provide both Discovery Proxy and
   Discovery Relay service at the same time.  In this case, there is a
   further conceptual functional division: on such a node, there are two
   Performers: the Discovery Proxy Performer and the Discovery Relay
   Performer.  These may be the same program, or they may be
   functionally separate; which is the case is beyond the scope of this
   document.  The reason for making this distinction is to point out
   that on a node providing both services, both Performers may receive
   every announcement sent by the Director.  And of course the Director
   receives announcements sent by either Performer.

4.2.  Orchestration Primitives

4.2.1.  Link Present

   The 'Link Present' primitive is used by the Director to communicate
   the presence of a link to Performers.  'Link Present' primitives
   include the following data:




Cheshire & Lemon         Expires January 4, 2018                [Page 7]


Internet-Draft            mDNS Discovery Relay                 July 2017


   link identifier  One or more opaque 32-bit identifiers, each of which
      identifies a link that is present on the orchestrated network.
      Each identifier is unique among all link identifiers managed by
      the Director.  These link identifiers are used in the Discovery
      Relay protocol to identify links on which mDNS requests will be
      sent and received, and are consistent across all participants in
      the orchestration system.

4.2.2.  Link Remove

   The 'Link Remove' primitive is used by the Director to communicate to
   Performers that a link that was formerly present is no longer
   present.  The 'Link Remove' primitive includes the following data:

   link identifier  One or more opaque 32-bit identifiers, as described
      in Section 4.2.1.

4.2.3.  Discovery Proxy Available

   The 'Discovery Proxy Available' primitive is used by Discovery Proxy
   Performers to announce their availability to the Director, and by the
   Director to announce to Discovery Relay Performers that Discovery
   Proxies are present and enabled.  This primitive is only used for
   nodes that provide Discovery Proxy service and can use Discovery
   Relays: a Discovery Proxy that does not support Discovery Proxy
   service is never announced in this way.  The 'Discovery Proxy
   Available' primitive includes the following data:

   node identifier  The node identifier of the Discovery Proxy, unique
      among all nodes managed by a Director.

   IP addresses  One or more IP addresses configured on the network
      interfaces of the node making the announcement.  This list must
      include all IP addresses from which the Discovery Proxy might
      connect to Discovery Relays, but need not include any other IP
      addresses.

   TLS Certificate  A TLS PKI certificate or bare public key which will
      be used by the Discovery Proxy to authenticate itself when
      connecting to Discovery Relays.

4.2.4.  Discovery Proxy Resigning

   The 'Discovery Proxy Resigning' primitive is used by Discovery
   Proxies to announce to the Director that they are no longer
   available, and by the Director to announce to Discovery Relay
   performers that a Discovery Proxy is no longer present or enabled.




Cheshire & Lemon         Expires January 4, 2018                [Page 8]


Internet-Draft            mDNS Discovery Relay                 July 2017


   The 'Discovery Proxy Resigning' primitive includes the following
   data:

      The node identifier of the Discovery Proxy, unique among all nodes
      managed by a Director.

4.2.5.  Discovery Relay Available

   The 'Discovery Relay Available' primitive is used by Discovery Relay
   Performers to inform the Director that they are available to provide
   service.  It is used by the Director to announce to Discovery Proxy
   Performers that a Discovery Relay is available and enabled.  The
   'Discovery Relay Available' primitive includes the following data:

   node identifier  The node identifier of the Discovery Relay, unique
      among all nodes managed by a Director.

   IP addresses  A list of IP addresses on which the Discovery Relay may
      be contacted.

   Port  TCP Port on which the Discovery Relay will be listening for
      connections.

   Server Certificate  A TLS PKI certificate or bare public key which
      will be presented to Discovery Proxies when they initiate TLS
      connections with the Discovery Relay.  This is used both to
      authenticate the Discovery Relay, and also to establish an
      encrypted connection between the two services.

   Links  A list of links on which the Discovery Relay provides service.
      Each link identifier corresponds to a link identified by a
      previous 'Link Present' primitive sent by the Director, as
      described in Section 4.2.1.

4.2.6.  Discovery Relay Resigning

   When a node providing Discovery Relay support can no longer continue
   to do so, it announces to the Director that it is no longer available
   using this primitive.  The 'Discovery Relay Resigning' primitive
   includes the following data:

   node identifier  The node identifier of the Discovery Relay, unique
      among all nodes managed by a Director.








Cheshire & Lemon         Expires January 4, 2018                [Page 9]


Internet-Draft            mDNS Discovery Relay                 July 2017


4.3.  Orchestration System Behavior

4.3.1.  Link Present

   The Director detects new links, or is configured with new links by
   the network operator.  It is responsible for noticing that a link to
   which more than one participating node is connected is the same link.
   For example, see Section 6.1 of [RFC7788].  When a new link is
   detected, the Director reports the presence of that link to all
   enabled Discovery Proxy Performers, and to all Discovery Relay
   Performers.  If the Director becomes aware of more than one link at
   the same time, or within an implementation-specific interval, it may
   announce the presence of more than one link at a time using the 'Link
   Present' primitive.

4.3.2.  Link Remove

   The Director detects the removal of links, either as a result of
   routers that are connected to those links becoming unavailable, or as
   a result of manual changes to the configuration by the network
   operator.  When a link that had previously been present is removed,
   the Director announces the removal of this link to all enabled
   Discovery Proxy performers and to all Discovery Relay performers.  If
   the removal of more than one link is detected at the same time or
   within an implementation-specific interval, the removal of each such
   link may be announced in a single 'Link Remove' primitive.

4.3.3.  Discovery Proxy Available

   When the Director receives a 'Discovery Proxy Available' primitive,
   it records the information in its list of available Discovery Proxies
   (henceforth "Discovery Proxy List").  If that node had previously
   reported that Discovery Proxy service was available, the entry in
   Discovery Proxy List for that node is replaced with an entry
   generated from the new update; any information in the previous entry
   that is not present in the update is discarded.

   Whether or not the Director enables Discovery Proxy service on the
   Discovery Proxy announced in a newly-received 'Discovery Proxy
   Available' primitive is dependent on the operational model and
   configuration of that particular orchestration system, which is out
   of scope for this document.  The same is true as to whether service
   discovery is enabled on all known links, or not.  We assume here that
   Discovery Proxy service may be available but not enabled on some
   nodes, whereas Discovery Relay service is generally available, since
   it will only be used by enabled Discovery Proxies on interfaces on
   which service discovery is enabled.




Cheshire & Lemon         Expires January 4, 2018               [Page 10]


Internet-Draft            mDNS Discovery Relay                 July 2017


   If the Director enables Discovery Proxy service on that node, the
   Discovery Proxy is announced to all nodes currently providing
   Discovery Relay service, using 'Discovery Proxy Available'
   primitives.  In addition, the set of all known Discovery Relays, and
   the information provided by them to the orchestration system, is
   announced to the node providing the Discovery Proxy service, using
   one or more 'Discovery Relay Available' primitives.

   When a 'Discovery Proxy Available' primitive is received from a
   Discovery Proxy Performer for which service is already enabled, but
   the update includes different information than was present in the
   previous announcement, the Discovery Proxy service is re-announced to
   every Discovery Relay Performer.

4.3.4.  Discovery Proxy Resigning

   When the Director receives a 'Discovery Proxy Resigning' primitive
   from a Discovery Proxy Performer that had previously sent a
   'Discovery Proxy available' primitive, the Director first determines
   if Discovery Proxy service had been enabled on that node.  If so,
   'Discovery Proxy Resigning' notifications are sent to Discovery Relay
   Performers.

   The Director may, as a result of a node's resignation from providing
   Discovery Proxy service, enable Discovery Proxy on some other node.
   If so, it does so as described in Section 4.3.3.

   In addition to any announcements sent as a result of a node's
   resignation from providing Discovery Proxy service, the Director also
   looks for an entry in the Discovery Proxy List for that node.  If one
   is present, it is removed.

4.3.5.  Discovery Relay Available

   When the Director receives a 'Discovery Relay Available' primitive,
   it records the information in its list of available Discovery Relay
   Performers (henceforth "Discovery Relay List").  If that list already
   contains an entry for the Performer making the new report, the entry
   from the list is discarded and a new one generated from the new
   announcement.

   Whether or not the Director enables service discovery through a
   particular Discovery Relay is dependent on the operation of that
   particular orchestration system, which is out of scope for this
   document.  It is assumed that a Director may or may not enable a
   particular Discovery Relay.





Cheshire & Lemon         Expires January 4, 2018               [Page 11]


Internet-Draft            mDNS Discovery Relay                 July 2017


   If the Director enables service discovery through the relay that made
   the announcement, the relay is announced to all enabled Discovery
   Proxy Performers.  In addition, if the relay had not previously been
   enabled for service discovery, the Director sends a 'Discovery Proxy
   Available' primitive to that Performer for each Discovery Proxy
   Performer on the Discovery Proxy List.

4.3.6.  Discovery Relay Resigning

   When the Director receives a 'Discovery Relay Resigning' primitive,
   it checks to see if the node making the announcement had previously
   been listed as providing Discovery Relay service; if so, the entry
   for that node is removed from the list.  If Discovery Relay service
   was enabled for that node, all nodes providing Discovery Proxy
   service are notified that this node is no longer providing Discovery
   Relay service, by sending a 'Discovery Relay Resigning' primitive to
   each such node.

4.3.7.  Node Available

   The orchestration system may or may not track the coming and going of
   nodes that provide service discovery.  If it does, depending on the
   operation of the system, it may be necessary to send some
   notification to the node to trigger its announcement of service
   discovery services.  How this is done is out of scope for this
   document.

4.3.8.  Node Resigning

   The orchestration system may or may not track the coming and going of
   nodes that provide service discovery.  If it does, then when the
   departure of a node that has previously announced Discovery Relay
   and/or Discovery Proxy service should result in the synthesis of
   resignation events for those services on that node.  The exact
   operation of this mechanism is out of scope for this document.

4.4.  Discovery Proxy Performer Behavior

   Nodes may provide both Discovery Proxy and Discovery Relay service:
   the two services share no ports and are mutually compatible.  When a
   node is providing both services, the behaviors described in this
   section are specific to the operation of the Discovery Proxy service
   on that node, not to the Discovery Relay service.








Cheshire & Lemon         Expires January 4, 2018               [Page 12]


Internet-Draft            mDNS Discovery Relay                 July 2017


4.4.1.  Link Present

   When a node that is providing Discovery Proxy service receives a link
   present notification, it checks to see if it currently has Discovery
   Relay service configured for each such link.  For any such link for
   which it does not have Discovery Relay service configured, it
   identifies the set of Relay Proxies that provide service on that
   link.  It then chooses a Discovery Relay node from this set using a
   random number generator.  If it already has a connection to the Relay
   Proxy, it attempts to subscribe to mDNS messages from that link.  If
   it does not have a connection, it attempts to establish one.  If that
   succeeds, it attempts to subscribe to mDNS messages from that link.
   If the outcome of each of these attempts to get Discovery Relay
   service on the new link fails, it eliminates this Discovery Relay
   from the set and repeats the process until the set is empty.

   If no attempt to subscribe to mDNS messages on the link is
   successful, then service discovery on that link is not possible.  The
   Discovery Proxy node maintains a list of links on which Discovery
   Relay service is desired but not available; when an attempt to get
   Discovery Relay service on a link fails, either because no node is
   providing Discovery Relay service on that link, or because attempting
   to get service on that link from all nodes claiming to provide it has
   failed, the link is added to this list.

4.4.2.  Link Removed

   When a link is removed, the Discovery Relay checks its list of
   connections to Discovery Relays for subscription for mDNS messages on
   that link.  If one is present, the Discovery Relay unsubscribes from
   mDNS messages on that link.  If there are no subscriptions present on
   that connection, the Discovery Relay terminates the connection.  If
   the link is on the list of links for which Discovery Relay service is
   desired but not available, the link is removed from that list.

4.4.3.  Discovery Proxy Available

   Discovery Proxy Performers send 'Discovery Proxy Available'
   primitives to the Director whenever their configuration changes in a
   way that affects the content of the primitive, and also whenever
   their node becomes newly available to the Director.  In addition to
   notifying the Director when they first become connected to the
   Director's orchestration system, they must also notify the Director
   when they disconnect and reconnect.

   When a node with Discovery Proxy service becomes available to the
   orchestration system, it informs the orchestration system that it can
   provide Discovery Proxy service.  It also provides the orchestration



Cheshire & Lemon         Expires January 4, 2018               [Page 13]


Internet-Draft            mDNS Discovery Relay                 July 2017


   system with a list of IP addresses from which it may originate
   connections to Discovery Relays, and provides a TLS PKI cert or
   suitable bare public key which will be used for TLS Client
   Authentication.

   Whenever the set of IP addresses from which the Discovery Proxy may
   initiate a connection to a Discovery Relay changes, the Discovery
   Proxy sends a new 'Discovery Proxy Available' primitive with its
   complete information, as above.  It may be desirable for the
   Discovery Proxy node to choose a specific IP address from which all
   such connections will originate, so as to minimize the number of such
   updates that may be required, but this behavior is optional.

   It is not ordinarily the case that the key or certificate used for
   authentication will change, but if it does, the Discovery Proxy node
   sends a complete new 'Discovery Proxy Available' primitive, which
   will contain the new key or certificate.

4.4.4.  Discovery Proxy Resigning

   When a node that had previously provided Discovery Proxy service is
   no longer able to do so for any reason, it announces this to the
   orchestration system using a 'Discovery Proxy Resigning' primitive.

4.4.5.  Discovery Relay Available

   When a node providing Discovery Proxy service receives a 'Discovery
   Relay Available' notification, it adds that Discovery Relay to its
   list of available Discovery Relays.  If the Discovery Relay is
   already on the list, the information the list entry is compared to
   the new information provided in the 'Discovery Relay Available'
   primitive.  If a connection to that Discovery Relay is present, and
   the destination IP address of that connection is no longer on the
   list of IP addresses supported by the Discovery Relay, or the public
   key of the Discovery Relay has changed, the connection is dropped and
   the process described in Section 4.4.6 is followed.

   Otherwise, if there is a connection to the Discovery Relay, the list
   of links subscribed to on that connection is compared to the list of
   served links listed in the 'Discovery Relay Available' primitive; any
   links for which subscriptions exist that are not listed in the
   'Discovery Relay Available' announcement are unsubscribed, and those
   links added to the list of links on which Discovery Relay service is
   not available.

   At this point the process described in Section 4.4.1 is followed for
   each link on the list of links for which Discovery Relay service is
   not available.



Cheshire & Lemon         Expires January 4, 2018               [Page 14]


Internet-Draft            mDNS Discovery Relay                 July 2017


4.4.6.  Discovery Relay Resigning

   Discovery Relay drops its connection to that Discovery Relay and puts
   all links for which subscriptions existed on that connection onto the
   list of links on which Discovery Relay service is not available.
   Because it is possible that another Discovery Relay is available for
   that link, the Discovery Proxy node again follows the process
   described in Section 4.4.1.

4.5.  Discovery Relay Performer Behavior

   Nodes that support service discovery may support both Discovery Proxy
   and Discovery Relay.  Behaviors described here are specific to nodes
   that are providing Discovery Relay service.  A node that provides
   both types of service will follow both the behavior described here
   and the behavior described for Discovery Proxy nodes.

4.5.1.  Link Present

   When a Discovery Relay performer receives a link present
   notification, it determines for each link announced whether it has an
   interface that is directly connected to that link.  If so, it
   determines whether it has previously announced the availability of
   service on that link.  If not, it adds the link to the list of links
   on which it provides Discovery Relay service (henceforth "Discovery
   Relay link list").

   If as a result of a 'Link Present' announcement the Discovery Relay
   link list has changed, the Discovery Relay performer sends a new
   'Discovery Relay Available' primitive to the Director.

4.5.2.  Link Removed

   When the Discovery Relay Performer receives a 'Link Removed'
   primitive, for each link mentioned in the primitive it checks to see
   if it is currently providing service on that link.  For each link
   mentioned in the primitive for which it is providing service, it
   deletes that link from its list of links on which it is providing
   service.  If any links were deleted from the list, the Discovery
   Relay Performer sends a new 'Discovery Relay Available' message to
   the Director.

4.5.3.  Discovery Proxy Available

   Directors send 'Discovery Proxy Available' primitives to Discovery
   Relay Performers when new Discovery Proxy Performers announce their
   availability, and also when Discovery Proxy Performers announce
   changes to their configuration.  When a Discovery Relay Performer



Cheshire & Lemon         Expires January 4, 2018               [Page 15]


Internet-Draft            mDNS Discovery Relay                 July 2017


   receives one of these primitives, it updates its Discovery Proxy IP
   address whitelist with the set of IP addresses from the primitive,
   and updates the Discovery Proxy authentication certificate as well.
   If the Discovery Proxy is connected to the Discovery Relay and either
   the certificate changed, or the source IP address of the connection
   is no longer on the whitelist, the Discovery Relay drops the
   connection.

4.5.4.  Discovery Proxy Resigning

   Directors send 'Discovery Proxy Resigning' messages to Discovery
   Relay Performers when Discovery Proxy Performers indicate that they
   are no longer available, or when they are disabled by the
   orchestration system.  When a Discovery Relay Performer receives this
   primitive, it checks to see if any connections from that Discovery
   Proxy are present.  Any such connections are terminated.

4.5.5.  Discovery Relay Available

   Discovery Relay Performers send 'Discovery Relay Available'
   primitives to the Director whenever their configuration changes in a
   way that affects the content of the primitive, and also whenever
   their node becomes newly available to the Director.  In addition to
   notifying the Director when they first become connected to the
   Director's orchestration system, they must also notify the Director
   when they disconnect and reconnect.

   Discovery Relays listen for connections from Discovery Proxies.
   Because no port is reserved for Discovery Relays, it is not useful to
   announce the availability of the service until the service is
   listening for connections, at which point it will know which port it
   is listening on.  Therefore, before sending a 'Discovery Relay
   Available' primitive, a Discovery Relay Performer must have received
   its listening port from the Discovery Relay service.

4.5.6.  Discovery Relay Resigning

   When a node providing Discovery Relay service must stop providing
   that service, it sends a 'Discovery Relay Resigning' primitive to the
   Director.

5.  Connections between Discovery Proxies and Discovery Relays

   When a Discovery Relay starts, it opens a passive TCP listener to
   receive connections from Discovery Proxies.  This listener may be
   bound to one or more source IP addresses, or to the wildcard address,
   depending on the TCP implementation.  When a connection is received,
   the relay must first validate that it is a connection to an IP



Cheshire & Lemon         Expires January 4, 2018               [Page 16]


Internet-Draft            mDNS Discovery Relay                 July 2017


   address to which connections are allowed.  For example, it may be
   that only connections to ULAs are allowed, or to the IP addresses
   configured on certain interfaces.  If the listener is bound to a
   specific IP address, this check is unnecessary.

   The relay must then validate that the source IP address of the
   connection is on its whitelist.  If the connection is not permitted
   either because of the source address or the destination address, the
   Discovery Relay responds to the TLS Client Hello message from the
   Discovery Proxy with a TLS user_canceled alert ([I-D.ietf-tls-tls13]
   Section 6.1).

   Otherwise, the Discovery Relay will attempt to complete a TLS
   handshake with the Discovery Proxy.  Discovery Proxies are required
   to send the post_handshake_auth extension ([I-D.ietf-tls-tls13]
   Section 4.2.5).  If a relay proxy receives a ClientHello message with
   no post_handshake_auth extension, the Discovery Relay rejects the
   connection with a certificate_required alert ([I-D.ietf-tls-tls13]
   Section 6.2).

   Once the TLS handshake is complete, the Discovery Relay MUST request
   post-handshake authentication as described in ([I-D.ietf-tls-tls13]
   Section 4.6.2).  If the Discovery Proxy refuses to send a
   certificate, or the key presented does not match the key associated
   with the IP address from which the connection originated, or the
   CertificateVerify does not validate, the connection is dropped with
   the TLS access_denied alert ([I-D.ietf-tls-tls13] Section 6.2).

   Once the connection is established and authenticated, it is treated
   as a DNS TCP connection [RFC1035].

   Aliveness of connections between Discovery Proxies and Relays is
   maintained as described in Section 4 of
   [I-D.ietf-dnsop-session-signal].  Discovery Proxies must also honor
   the 'Retry Delay' TLV (section 5 of [I-D.ietf-dnsop-session-signal])
   if sent by the Discovery Relay.

   Discovery Proxies may establish more than one connection to a
   specific Discovery Relay.  This would happen in the case that a TCP
   connection stalls, and the Discovery Proxy is able to reconnect
   before the previous connection has timed out.  It could also happen
   as a result of a server restart.  It is not likely that two active
   connections from the same Discovery Proxy would be present at the
   same time, but it must be possible for additional connections to be
   established.  The Discovery Relay may drop the old connection when
   the new one has been fully established, including a successful TLS
   handshake.  What it means for two connections to be from the same
   Discovery Proxy is that the connections both have source addresses



Cheshire & Lemon         Expires January 4, 2018               [Page 17]


Internet-Draft            mDNS Discovery Relay                 July 2017


   that belong to the same proxy, and that they were authenticated using
   the same client certificate.

6.  Traffic from Relays to Proxies

   The mere act of connecting to a Discovery Relay does not result in
   any mDNS traffic being forwarded.  In order to request that mDNS
   traffic from a particular link be forwarded on a particular
   connection, the Discovery Proxy must send a session signaling message
   containing one or more MDNS Link Request TLVs (Section 9.1)
   indicating the link from which traffic is requested.

   When such a message is received, the Discovery Relay validates that
   each specified link is available for forwarding, and that forwarding
   is enabled for that link.  For each such message the Discovery Relay
   validates each link specified and includes in a single response a
   list of zero or more MDNS Link Invalid TLVs )Section 9.2) for links
   that are not valid, and zero or more MDNS Link Subscribed TLVs
   (Section 9.3) for links that are valid.  For each valid link, it
   begins forwarding all mDNS traffic from that link to the Discovery
   Proxy.  Delivery is not guaranteed: if there is no buffer space,
   packets will be dropped.  It is expected that regular mDNS retry
   processing will take care of retransmission of lost packets.  The
   amount of buffer space is implementation dependent, but generally
   should not be more than the bandwidth delay product of the TCP
   connection [RFC1323].

   mDNS messages from Relays to Proxies are framed within DNS Session
   Signaling messages.  This allows multiple TLVs to be included.  Each
   forwarded mDNS message is contained in an MDNS Message TLV
   Section 9.4.  The layer 2 source address of the message, if known,
   MAY be encoded in a Layer 2 Source TLV (Section 9.5).  The source IP
   address of the message MUST be encoded in a IP Source Address TLV
   (Section 9.6).  The source port of the message MUST be encoded in an
   IP Source port TLV (Section 9.7).  The link on which the message was
   received MUST be encoded in a Link Identifier TLV (Section 9.8).  The
   Discovery Proxy MUST silently ignore unrecognized TLVs in mDNS
   messages, and MUST NOT discard mDNS messages that include
   unrecognized TLVs.

   A Discovery Proxy may discontinue listening for mDNS messages on a
   particular link by sending a session signaling message containing an
   MDNS Link Discontinue TLV (Section 9.9).  Subsequent messages from
   that link that had previously been queued indicating may arrive.  The
   Discovery Proxy should silently ignore such messages.  The Discovery
   Relay MUST discontinue generating such messages as soon as the
   request is received.  The Discovery Relay does not respond to this




Cheshire & Lemon         Expires January 4, 2018               [Page 18]


Internet-Draft            mDNS Discovery Relay                 July 2017


   message other than to discontinue forwarding mDNS messages from the
   specified links.

7.  Traffic from Proxies to Relays

   Like mDNS traffic from relays, each mDNS message sent by a Discovery
   Proxie to a Discovery Relay is encapsulated in an MDNS Message TLV
   (Section 9.4) within a session signaling message.  Each message MUST
   contain one or more Link Identifier TLVs (Section 9.8).  The
   Discovery Relay will transmit the message to the mDNS port and
   multicast address on each link.  The message MUST include one or more
   IP family TLVs (Section 9.10).  For each such TLVs that is included,
   the message will be sent on each link using the specified IP family.
   If no family codes are recognized, no packets will be transmitted.

8.  Discovery Proxy Behavior

   Discovery Proxies treat links for which Discovery Relay service is
   being used as if they were virtual interfaces; in other words, a
   Discovery Proxy serving multiple links using multiple Discovery
   Relays behaves the same as a Discovery Proxy serving multiple links
   using multiple physical network interfaces.

   Discovery Proxies responding to mDNS messages for non-link-local IP
   addresses where the unicast bit is set respond directly, rather than
   through a proxy.  Link-local responses are not supported for links to
   which Discovery Proxies are not directly connected.

9.  Session Signaling TLVs

   This document defines a modest number of new DNS Session Signaling
   TLVs.

9.1.  MDNS Link Request

   The MDNS Link Request TLV conveys a 32-bit link identifier from which
   a Discovery Proxy is requesting that a Discovery Relay forward mDNS
   traffic.  The link identifier comes from the orchestration system
   (see Section 4.2.1).  The SSOP-TYPE for this TLV is TBD1.  The SSOP-
   LENGTH is always 4.  The SSOP-DATA is the 32-bit identifier in
   network byte order.

9.2.  MDNS Link Invalid

   The MDNS Link Invalid TLV is returned in response to a session
   signaling message containing an MDNS Link Request, and returns the
   32-bit identifier that was contained in that request.  The link
   identifier comes from an MDNS Link Request TLV in the message being



Cheshire & Lemon         Expires January 4, 2018               [Page 19]


Internet-Draft            mDNS Discovery Relay                 July 2017


   responded to.  The TLV indicates that the specified link identifier
   does not refer to a valid link, either because the link is not
   supported by the Discovery Relay, or because the identifier is not
   known.  The SSOP-TYPE for this TLV is TBD2.  The SSOP-LENGTH is
   always 4.  The SSOP-DATA is the 32-bit identifier in network byte
   order.

9.3.  MDNS Link Subscribed

   The MDNS Link Subscribed TLV is returned in response to a session
   signaling message containing an MDNS Link Request, and returns the
   32-bit identifier from a MDNS Link Request TLV that was contained in
   that request.  It indicates that MDNS messages for the specified link
   have been successfully subscribed.  The SSOP-TYPE for this TLV is
   TBD3.  The SSOP-LENGTH is always 4.  The SSOP-DATA is the 32-bit
   identifier in network byte order.

9.4.  MDNS Message

   The MDNS Message TLV is used to encapsulate an mDNS message that is
   being forwarded from a link to a Discovery Proxy, or is being
   forwarded from a Discovery Proxy to a link.  The SSOP-TYPE for this
   TLV is TBD4.  SSOP-LENGTH is the length of the application layer
   payload of the MDNS message.  SSOP-DATA is the application layer
   payload of the message.

9.5.  Layer 2 Source Address

   The Layer 2 Source Address TLV is used to report the layer 2 address
   from which an mDNS message was received.  This TLV is optionally
   present in session signaling messages from Discovery Relays to
   Discovery Proxies that contain mDNS messages when the source link-
   layer address is known.  The SSOP-TYPE is TBD5.  SSOP-LENGTH is
   variable, depending on the length of link-layer addresses on the link
   from which the message was received.  SSOP-data is the link-layer
   address as it was received on the link.

9.6.  IP Source Address

   The IP Source Address TLV is used to report the IP source address
   from which an mDNS message was received.  This TLV is present in
   session signaling messages from Discovery Relays to Discovery Proxies
   that contain mDNS messages.  SSOP-TYPE is TBD6.  SSOP-LENGTH is
   either 4, for an IPv4 address, or 16, for an IPv6 address.  SSOP-DATA
   is the IP Address.






Cheshire & Lemon         Expires January 4, 2018               [Page 20]


Internet-Draft            mDNS Discovery Relay                 July 2017


9.7.  IP Source Port

   The IP Source Port TLV is used to report the IP source port from
   which an mDNS message was received.  This TLV is present in session
   signaling messages from Discovery Relays to Discovery Proxies.  SSOP-
   TYPE is TBD7.  SSOP-LENGTH is 2.  SSOP-DATA is the source port in
   network byte order.

9.8.  Link Identifier

   This option is used both in session signaling messages from Discovery
   Proxies to Discovery Relays that contain mDNS messages, and in
   message from Discovery Relays to Discovery Proxies that contain mDNS
   messages.  In the former case, it indicates a link to which the
   message should be forwarded; in the latter case, it indicates the
   link on which the message was received.  SSOP-TYPE is TBD8.  SSOP-
   LENGTH is 4.  SSOP-DATA is a 32-bit link identifier as described in
   Section 4.2.1.

9.9.  MDNS Discontinue

   This option is used by Discovery Proxies to unsubscribe to mDNS
   messages on the specified link.  More than one may be present in a
   single session signaling message.  SSOP-TYPE is TBD9.  SSOP-LENGTH is
   4.  SSOP-DATA is a 32-bit link identifier as described in
   Section 4.2.1.

9.10.  IP Address Family

   This option is used in mDNS messages sent by Discovery Proxies to
   links to indicate to the Discovery Relay which IP address family or
   families should be used when transmitting the message on the link.
   More than one may be present in a single session signaling message.
   SSOP-TYPE is TBD10.  SSOP-LENGTH is 1.  SSOP-DATA is a 8-bit IP
   family identifier.  A value of 1 indicates IPv4.  A value of 2
   indicates IPv6.  Other values are reserved, and MUST be ignored if
   not recognized.

10.  Security Considerations

11.  IANA Considerations

   The IANA is kindly requested to update the DNS Session Signaling Type
   Codes Registry [I-D.ietf-dnsop-session-signal] by allocating codes
   for each of the TBD type codes listed in the following table, and by
   updating this document, here and in Section 9.  Each type code should
   list this document as its reference document.




Cheshire & Lemon         Expires January 4, 2018               [Page 21]


Internet-Draft            mDNS Discovery Relay                 July 2017


             +--------+----------+--------------------------+
             | Opcode | Status   | Name                     |
             +--------+----------+--------------------------+
             | TBD1   | Standard | MDNS Link Request        |
             | TBD2   | Standard | MDNS Link Invalid        |
             | TBD3   | Standard | MDNS Link Subscribed     |
             | TBD4   | Standard | MDNS Messsage            |
             | TBD5   | Standard | Layer Two Source Address |
             | TBD6   | Standard | IP Source Address        |
             | TBD7   | Standard | IP Destination Address   |
             | TBD8   | Standard | Link Identifier          |
             | TBD9   | Standard | MDNS Discontinue         |
             | TBD10  | Standard | IP Address Family        |
             +--------+----------+--------------------------+

             DNS Session Signaling Type Codes to be allocated

12.  IANA Considerations

13.  Acknowledgments

14.  References

14.1.  Normative References

   [I-D.ietf-dnsop-session-signal]
              Bellis, R., Cheshire, S., Dickinson, J., Dickinson, S.,
              Mankin, A., and T. Pusateri, "DNS Session Signaling",
              draft-ietf-dnsop-session-signal-02 (work in progress),
              March 2017.

   [I-D.ietf-dnssd-hybrid]
              Cheshire, S., "Discovery Proxy for Multicast DNS-Based
              Service Discovery", draft-ietf-dnssd-hybrid-06 (work in
              progress), March 2017.

   [I-D.ietf-tls-tls13]
              Rescorla, E., "The Transport Layer Security (TLS) Protocol
              Version 1.3", draft-ietf-tls-tls13-20 (work in progress),
              April 2017.

   [RFC1035]  Mockapetris, P., "Domain names - implementation and
              specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,
              November 1987, <http://www.rfc-editor.org/info/rfc1035>.

   [RFC1323]  Jacobson, V., Braden, R., and D. Borman, "TCP Extensions
              for High Performance", RFC 1323, DOI 10.17487/RFC1323, May
              1992, <http://www.rfc-editor.org/info/rfc1323>.



Cheshire & Lemon         Expires January 4, 2018               [Page 22]


Internet-Draft            mDNS Discovery Relay                 July 2017


   [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,
              <http://www.rfc-editor.org/info/rfc6241>.

   [RFC6762]  Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762,
              DOI 10.17487/RFC6762, February 2013,
              <http://www.rfc-editor.org/info/rfc6762>.

   [RFC6763]  Cheshire, S. and M. Krochmal, "DNS-Based Service
              Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013,
              <http://www.rfc-editor.org/info/rfc6763>.

   [RFC7788]  Stenberg, M., Barth, S., and P. Pfister, "Home Networking
              Control Protocol", RFC 7788, DOI 10.17487/RFC7788, April
              2016, <http://www.rfc-editor.org/info/rfc7788>.

14.2.  Informative References

   [TR-069]   Broadband Forum, "CPE WAN Management Protocol", November
              2013, <https://www.broadband-forum.org/technical/download/
              TR-069_Amendment-5.pdf>.

Authors' Addresses

   Stuart Cheshire
   Apple Inc.
   1 Infinite Loop
   Cupertino, California  95014
   USA

   Phone: +1 408 974 3207
   Email: cheshire@apple.com


   Ted Lemon
   Nominum, Inc.
   800 Bridge Parkway
   Redwood City, California  94065
   United States of America

   Phone: +1 650 381 6000
   Email: ted.lemon@nominum.com








Cheshire & Lemon         Expires January 4, 2018               [Page 23]


Html markup produced by rfcmarkup 1.123, available from https://tools.ietf.org/tools/rfcmarkup/