tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Glossaries     Architecture     IMS     UICC    |    search     info

RFC 7788

 
 
 

Home Networking Control Protocol

Part 2 of 2, p. 21 to 40
Prev RFC Part

 


prevText      Top      ToC       Page 21 
8.  Naming and Service Discovery

   Network-wide naming and service discovery can greatly improve the
   user friendliness of a network.  The following mechanism provides
   means to setup and delegate naming and service discovery across
   multiple HNCP routers.

   Each HNCP router SHOULD provide and advertise a recursive name
   resolving server to clients that honor the announcements made in
   Delegated-Zone TLVs (Section 10.5), Domain-Name TLVs (Section 10.6),
   and Node-Name TLVs (Section 10.7), i.e., delegate queries to the
   designated name servers and hand out appropriate A, AAAA, and PTR
   records according to the mentioned TLVs.

   Each HNCP router SHOULD provide and announce an auto-generated or
   user-configured name for each internal Common Link (Section 6.1) for
   which it is the designated DHCPv4, stateful DHCPv6 server, mDNS
   proxy, or for which it provides forward or reverse DNS services on
   behalf of connected devices.  This announcement is done using
   Delegated-Zone TLVs (Section 10.5) and MUST be unique in the whole
   network.  In case of a conflict, the announcement of the node with
   the greatest node identifier takes precedence, and all other nodes
   MUST cease to announce the conflicting TLV.  HNCP routers providing
   recursive name resolving services MUST use the included DNS server

Top      Up      ToC       Page 22 
   address within the TLV to resolve names belonging to the zone as if
   there was an NS record.

   Each HNCP node SHOULD announce a node name for itself to be easily
   reachable and MAY announce names on behalf of other devices.
   Announcements are made using Node-Name TLVs (Section 10.7), and the
   announced names MUST be unique in the whole network.  In case of a
   conflict, the announcement of the node with the greatest node
   identifier takes precedence, and all other nodes MUST cease to
   announce the conflicting TLV.  HNCP routers providing recursive name
   resolving services as described above MUST resolve such announced
   names to their respective IP addresses as if there were corresponding
   A/AAAA records.

   Names and unqualified zones are used in an HNCP network to provide
   naming and service discovery with local significance.  A network-wide
   zone is appended to all single labels or unqualified zones in order
   to qualify them. ".home" is the default; however, an administrator
   MAY configure the announcement of a Domain-Name TLV (Section 10.6)
   for the network to use a different one.  In case multiple are
   announced, the domain of the node with the greatest node identifier
   takes precedence.

9.  Securing Third-Party Protocols

   PSKs are often required to secure (for example) IGPs and other
   protocols that lack support for asymmetric security.  The following
   mechanism manages PSKs using HNCP to enable bootstrapping of such
   third-party protocols.  The scheme SHOULD NOT be used unless it's in
   conjunction with secured HNCP unicast transport (i.e., DTLS), as
   transferring the PSK in plaintext anywhere in the network is a
   potential risk, especially as the originator may not know about
   security (and use of DNCP security) on all links.  The following
   rules define how such a PSK is managed and used:

   o  If no Managed-PSK TLV (Section 10.8) is currently being announced,
      an HNCP node using this mechanism MUST create one after a random
      delay of 0 to 10 seconds with a 32 bytes long random key and add
      it to its node data.

   o  In case multiple nodes announce such a TLV at the same time, all
      but the one with the greatest node identifier stop advertising it
      and adopt the remaining one.

   o  The node currently advertising the Managed-PSK TLV MUST generate
      and advertise a new random one whenever an unreachable node is
      removed from the DNCP topology as described in Section 4.6 of
      [RFC7787].

Top      Up      ToC       Page 23 
   PSKs for individual protocols SHOULD be derived from the random PSK
   using a suitable one-way hashing algorithm (e.g., by using the HMAC-
   based Key Derivation Function (HKDF) based on HMAC-SHA256 [RFC6234]
   with the particular protocol name in the info field) so that
   disclosure of any derived key does not impact other users of the
   managed PSK.  Furthermore, derived PSKs MUST be updated whenever the
   managed PSK changes.

10.  Type-Length-Value Objects

   HNCP defines the following TLVs in addition to those defined by DNCP.
   The same general rules and defaults for encoding as noted in
   Section 7 of [RFC7787] apply.  Note that most HNCP variable-length
   TLVs also support optional nested TLVs, and they are encoded after
   the variable-length content, followed by the zero padding of the
   variable-length content to the next 32-bit boundary.

   TLVs defined here are only valid when appearing in their designated
   context, i.e., only directly within container TLVs mentioned in their
   definition or -- absent any mentions -- only as top-level TLVs within
   the node data set.  TLVs appearing outside their designated context
   MUST be ignored.

   TLVs encoding IP addresses or prefixes allow encoding both IPv6 and
   IPv4 addresses and prefixes.  IPv6 information is encoded as is,
   whereas for IPv4, the IPv4-mapped IPv6 addresses format [RFC4291] is
   used, and prefix lengths are encoded as the original IPv4 prefix
   length increased by 96.

10.1.  HNCP-Version TLV

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    Type: HNCP-Version (32)    |         Length: >= 5          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           Reserved            |   M   |   P   |   H   |   L   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          User-agent                           |

   This TLV is used to indicate the supported version and router
   capabilities of an HNCP node as described in Section 4.

   Reserved:  Bits are reserved for future use.  They MUST be set to 0
      when creating this TLV, and their value MUST be ignored when
      processing the TLV.

Top      Up      ToC       Page 24 
   M-capability:  Priority value used for electing the on-link mDNS
      [RFC6762] proxy.  It MUST be set to 0 if the router is not capable
      of proxying mDNS, otherwise it SHOULD be set to 4 but MAY be set
      to any value from 1 to 7 to indicate a non-default priority.  The
      values 8-15 are reserved for future use.

   P-capability:  Priority value used for electing the on-link DHCPv6-PD
      server.  It MUST be set to 0 if the router is not capable of
      providing prefixes through DHCPv6-PD (Section 6.3.4), otherwise it
      SHOULD be set to 4 but MAY be set to any value from 1 to 7 to
      indicate a non-default priority.  The values 8-15 are reserved for
      future use.

   H-capability:  Priority value used for electing the on-link DHCPv6
      server offering non-temporary addresses.  It MUST be set to 0 if
      the router is not capable of providing such addresses, otherwise
      it SHOULD be set to 4 but MAY be set to any value from 1 to 7 to
      indicate a non-default priority.  The values 8-15 are reserved for
      future use.

   L-capability:  Priority value used for electing the on-link DHCPv4
      server.  It MUST be set to 0 if the router is not capable of
      running a legacy DHCPv4 server offering IPv4 addresses to clients,
      otherwise it SHOULD be set to 4 but MAY be set to any value from 1

      to 7 to indicate a non-default priority.  The values 8-15 are
      reserved for future use.

   User-Agent:  The user-agent is a human-readable UTF-8 string that
      describes the name and version of the current HNCP implementation.

10.2.  External-Connection TLV

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Type: External-Connection (33)|             Length            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     (Optional nested TLVs)                    |

   An External-Connection TLV is a container TLV used to gather network
   configuration information associated with a single external
   connection (Section 6.2) to be shared across the HNCP network.  A
   node MAY publish an arbitrary number of instances of this TLV to
   share the desired number of external connections.  Upon reception,
   the information transmitted in any nested TLVs is used for the
   purposes of prefix assignment (Section 6.3) and host configuration
   (Section 7).

Top      Up      ToC       Page 25 
10.2.1.  Delegated-Prefix TLV

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Type: Delegated-Prefix (34)  |          Length: >= 9         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                Valid Lifetime Since Origination               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |              Preferred Lifetime Since Origination             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Prefix Length |                                               |
   +-+-+-+-+-+-+-+-+            Prefix                             +
   ...
   |                                               | 0-pad if any  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     (Optional nested TLVs)                    |

   The Delegated-Prefix TLV is used by HNCP routers to advertise
   prefixes that are allocated to the whole network and can be used for
   prefix assignment.  Delegated-Prefix TLVs are only valid inside
   External-Connection TLVs, and their prefixes MUST NOT overlap with
   those of other such TLVs in the same container.

   Valid Lifetime Since Origination:   The time in seconds the delegated
      prefix was valid for at the origination time of the node data
      containing this TLV.  The value MUST be updated whenever the node
      republishes its Node-State TLV.

   Preferred Lifetime Since Origination:   The time in seconds the
      delegated prefix was preferred for at the origination time of the
      node data containing this TLV.  The value MUST be updated whenever
      the node republishes its Node-State TLV.

   Prefix Length:   The number of significant bits in the prefix.

   Prefix:   Significant bits of the prefix padded with zeros up to the
      next byte boundary.

Top      Up      ToC       Page 26 
10.2.1.1.  Prefix-Policy TLV

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    Type: Prefix-Policy (43)   |          Length: >= 1         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Policy Type  |                                               |
   +-+-+-+-+-+-+-+-+                    Value                      +
   |                                                               |

   The Prefix-Policy TLV contains information about the policy or
   applicability of a delegated prefix.  This information can be used to
   determine whether prefixes for a certain use case (e.g., local
   reachability, Internet connectivity) do exist or are to be acquired
   and to make decisions about assigning prefixes to certain links or to
   fine-tune border firewalls.  See Section 6.2 for a more in-depth
   discussion.  This TLV is only valid inside a Delegated-Prefix TLV.

   Policy Type:   The type of the policy identifier.

      0:        Internet connectivity (no value).

      1-128:    Explicit destination prefix with the Policy Type being
                the actual length of the prefix and the value containing
                significant bits of the destination prefix padded with
                zeros up to the next byte boundary.

      129:      DNS domain.  The value contains a DNS label sequence
                encoded per [RFC1035].  Compression MUST NOT be used.
                The label sequence MUST end with an empty label.

      130:      Opaque UTF-8 string (e.g., for administrative purposes).

      131:      Restrictive assignment (no value).

      132-255:  Reserved for future additions.

   Value:   A variable-length identifier of the given type.

Top      Up      ToC       Page 27 
10.2.2.  DHCPv6-Data TLV

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    Type: DHCPv6-Data (37)     |          Length: > 0          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      DHCPv6 option stream                     |

   This TLV is used to encode auxiliary IPv6 configuration information
   (e.g., recursive DNS servers) encoded as a stream of DHCPv6 options.
   It is only valid in an External-Connection TLV or a Delegated-Prefix
   TLV encoding an IPv6 prefix and MUST NOT occur more than once in any
   single container.  When included in an External-Connection TLV, it
   contains DHCPv6 options relevant to the external connection as a
   whole.  When included in a delegated prefix, it contains options
   mandatory to handle said prefix.

   DHCPv6 option stream:   DHCPv6 options encoded as specified in
      [RFC3315].

10.2.3.  DHCPv4-Data TLV

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type: DHCPv4-Data (38)    |          Length: > 0          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       DHCPv4 option stream                    |

   This TLV is used to encode auxiliary IPv4 configuration information
   (e.g., recursive DNS servers) encoded as a stream of DHCPv4 options.
   It is only valid in an External-Connection TLV and MUST NOT occur
   more than once in any single container.  It contains DHCPv4 options
   relevant to the external connection as a whole.

   DHCPv4 option stream:   DHCPv4 options encoded as specified in
      [RFC2131].

Top      Up      ToC       Page 28 
10.3.  Assigned-Prefix TLV

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Type: Assigned-Prefix (35)   |          Length: >= 6         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      Endpoint Identifier                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Rsv. | Prty. | Prefix Length |                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+            Prefix             +
   ...
   |                                               | 0-pad if any  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     (Optional nested TLVs)                    |

   This TLV is used to announce Published Assigned Prefixes for the
   purposes of prefix assignment (Section 6.3).

   Endpoint Identifier:   The endpoint identifier of the local interface
      the prefix is assigned to, or 0 if it is assigned to a Private
      Link (e.g., when the prefix is assigned for downstream prefix
      delegation).

   Rsv.:   Bits are reserved for future use.  They MUST be set to 0 when
      creating this TLV, and their value MUST be ignored when processing
      the TLV.

   Prty:   The Advertised Prefix Priority from 0 to 15.

      0-1:    Low priorities.

      2:      Default priority.

      3-7:    High priorities.

      8-11:   Administrative priorities.  MUST NOT be used unless
              configured otherwise.

      12-14:  Reserved for future use.

      15:     Provider priorities.  MAY only be used by the router
              advertising the corresponding delegated prefix and based
              on static or dynamic configuration (e.g., for excluding a
              prefix based on the DHCPv6-PD Prefix Exclude Option
              [RFC6603]).

Top      Up      ToC       Page 29 
   Prefix Length:   The number of significant bits in the Prefix field.

   Prefix:   The significant bits of the prefix padded with zeros up to
      the next byte boundary.

10.4.  Node-Address TLV

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    Type: Node-Address (36)    |           Length: 20          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      Endpoint Identifier                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   |                           IP Address                          |
   |                                                               |
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     (Optional nested TLVs)                    |

   This TLV is used to announce addresses assigned to an HNCP node as
   described in Section 6.4.

   Endpoint Identifier:   The endpoint identifier of the local interface
      the prefix is assigned to, or 0 if it is not assigned on an HNCP
      enabled link.

   IP Address:   The globally scoped IPv6 address, or the IPv4 address
      encoded as an IPv4-mapped IPv6 address [RFC4291].

Top      Up      ToC       Page 30 
10.5.  DNS-Delegated-Zone TLV

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Type: DNS-Delegated-Zone (39) |        Length: >= 17          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   |                           IP Address                          |
   |                                                               |
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |Reserved |L|B|S|                                               |
   +-+-+-+-+-+-+-+-+  Zone  (DNS label sequence - variable length) |
   ...
   |                                               | 0-pad if any  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     (Optional nested TLVs)                    |

   This TLV is used to announce a forward or reverse DNS zone delegation
   in the HNCP network.  Its meaning is roughly equivalent to specifying
   an NS and A/AAAA record for said zone.  Details are specified in
   Section 8.

   IP Address:  The IPv6 address of the authoritative DNS server for the
      zone; IPv4 addresses are represented as IPv4-mapped addresses
      [RFC4291].  The special value of :: (all zeros) means the
      delegation is available in the global DNS hierarchy.

   Reserved:  Those bits MUST be set to 0 when creating the TLV and
      ignored when parsing it unless defined in a later specification.

   L-bit:  (DNS-based Service Discovery (DNS-SD) [RFC6763] Legacy-
      Browse) indicates that this delegated zone SHOULD be included in
      the network's DNS-SD legacy browse list of domains at
      lb._dns-sd._udp.(DOMAIN-NAME).  Local forward zones SHOULD have
      this bit set; reverse zones SHOULD NOT.

   B-bit:  (DNS-SD [RFC6763] Browse) indicates that this delegated zone
      SHOULD be included in the network's DNS-SD browse list of domains
      at b._dns-sd._udp.(DOMAIN-NAME).  Local forward zones SHOULD have
      this bit set; reverse zones SHOULD NOT.

   S-bit:  (Fully qualified DNS-SD [RFC6763] domain) indicates that this
      delegated zone consists of a fully qualified DNS-SD domain, which
      should be used as the base for DNS-SD domain enumeration, i.e.,
      _dns-sd._udp.(Zone) exists.  Forward zones MAY have this bit set;
      reverse zones MUST NOT.  This can be used to provision a DNS

Top      Up      ToC       Page 31 
      search path to hosts for non-local services (such as those
      provided by an ISP or other manually configured service
      providers).  Zones with this flag SHOULD be added to the search
      domains advertised to clients.

   Zone:  The label sequence encoded according to [RFC1035].
      Compression MUST NOT be used.  The label sequence MUST end with an
      empty label.

10.6.  Domain-Name TLV

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    Type: Domain-Name (40)     |         Length: > 0           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |        Domain (DNS label sequence - variable length)          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   This TLV is used to indicate the base domain name for the network as
   specified in Section 8.  This TLV MUST NOT be announced unless the
   domain name was explicitly configured by an administrator.

   Domain:   The label sequence encoded according to [RFC1035].
      Compression MUST NOT be used.  The label sequence MUST end with an
      empty label.

10.7.  Node-Name TLV

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type: Node-Name (41)      |         Length: > 17          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   |                           IP Address                          |
   |                                                               |
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Length    |       Name                                    |
    ...
   | (not null-terminated, variable length)        | 0-pad if any  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     (Optional nested TLVs)                    |

   This TLV is used to assign the name of a node in the network to a
   certain IP address as specified in Section 8.

Top      Up      ToC       Page 32 
   IP Address:   The IP address associated with the name.  IPv4
      addresses are encoded using IPv4-mapped IPv6 addresses.

   Length:   The length of the name (0-63).

   Name:   The name of the node as a single DNS label.

10.8.  Managed-PSK TLV

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    Type: Managed-PSK (42)     |          Length: 32           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   |                                                               |
   |                                                               |
   |                      Random 256-bit PSK                       |
   |                                                               |
   |                                                               |
   |                                                               |
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     (Optional nested TLVs)                    |

   This TLV is used to announce a PSK for securing third-party protocols
   exclusively supporting symmetric cryptography as specified in
   Section 9.

11.  General Requirements for HNCP Nodes

   Each node implementing HNCP is subject to the following requirements:

   o  It MUST implement HNCP versioning (Section 4) and interface
      classification (Section 5).

   o  It MUST implement and run the method for securing third-party
      protocols (Section 9) whenever it uses the security mechanism of
      HNCP.

   If the node is acting as a router, then the following requirements
   apply in addition:

   o  It MUST support Autonomous Address Configuration (Section 6) and
      configuration of hosts and non-HNCP routers (Section 7).

   o  It SHOULD implement support for naming and service discovery
      (Section 8) as defined in this document.

Top      Up      ToC       Page 33 
   o  It MAY be able to provide connectivity to IPv4 devices using
      DHCPv4.

   o  It SHOULD be able to delegate prefixes to legacy IPv6 routers
      using DHCPv6-PD (Section 6.3.4).

   o  In addition, the normative language of "Basic Requirements for
      IPv6 Customer Edge Routers" [RFC7084] applies with the following
      adjustments:

      *  The generic requirements G-4 and G-5 are relaxed such that any
         known default router on any interface is sufficient for a
         router to announce itself as the default router; similarly,
         only the loss of all such default routers results in self-
         invalidation.

      *  "WAN-Side Configuration" (Section 4.2) applies to interfaces
         classified as external.

      *  If the Customer Edge (CE) sends a size hint as indicated in
         WPD-2, the hint MUST NOT be determined by the number of LAN
         interfaces of the CE but SHOULD instead be large enough to at
         least accommodate prefix assignments announced for existing
         delegated or ULA prefixes, if such prefixes exist and unless
         explicitly configured otherwise.

      *  The dropping of packets with a destination address belonging to
         a delegated prefix mandated in WPD-5 MUST NOT be applied to
         destinations that are part of any prefix announced using an
         Assigned-Prefix TLV by any HNCP router in the network.

      *  "LAN-Side Configuration" (Section 4.3) applies to interfaces
         not classified as external.

      *  The requirement L-2 to assign a separate /64 to each LAN
         interface is replaced by the participation in the prefix
         assignment mechanism (Section 6.3) for each such interface.

      *  The requirement L-9 is modified, in that the M flag MUST be set
         if and only if a router connected to the respective Common Link
         is advertising a non-zero H-capability.  The O flag SHOULD
         always be set.

      *  The requirement L-12 to make DHCPv6 options available is
         adapted, in that Canonical Encoding Rules (CER) SHOULD publish
         the subset of options using the DHCPv6-Data TLV in an External-
         Connection TLV.  Similarly, it SHOULD do the same for DHCPv4
         options in a DHCPv4-Data TLV.  DHCPv6 options received inside

Top      Up      ToC       Page 34 
         an OPTION_IAPREFIX [RFC3633] MUST be published using a
         DHCPv6-Data TLV inside the respective Delegated-Prefix TLV.
         HNCP routers SHOULD make relevant DHCPv6 and DHCPv4 options
         available to clients, i.e., options contained in External-
         Connection TLVs that also include delegated prefixes from which
         a subset is assigned to the respective link.

      *  The requirement L-13 to deprecate prefixes is applied to all
         delegated prefixes in the network from which assignments have
         been made on the respective interface.  Furthermore, the Prefix
         Information Options indicating deprecation MUST be included in
         Router Advertisements for the remainder of the prefixes'
         respective valid lifetime but MAY be omitted after at least 2
         hours have passed.

12.  Security Considerations

   HNCP enables self-configuring networks, requiring as little user
   intervention as possible.  However, this zero-configuration goal
   usually conflicts with security goals and introduces a number of
   threats.

   General security issues for existing home networks are discussed in
   [RFC7368].  The protocols used to set up addresses and routes in such
   networks to this day rarely have security enabled within the
   configuration protocol itself.  However, these issues are out of
   scope for the security of HNCP itself.

   HNCP is a DNCP-based state synchronization mechanism carrying
   information with varying threat potential.  For this consideration,
   the payloads defined in DNCP and this document are reviewed:

   o  Network topology information such as HNCP nodes and their common
      links.

   o  Address assignment information such as delegated and assigned
      prefixes for individual links.

   o  Naming and service discovery information such as auto-generated or
      customized names for individual links and nodes.

12.1.  Interface Classification

   As described in Section 5.3, an HNCP node determines the internal or
   external state on a per-interface basis.  A firewall perimeter is set
   up for the external interfaces, and for internal interfaces, HNCP
   traffic is allowed, with the exception of the Leaf and Guest
   subcategories.

Top      Up      ToC       Page 35 
   Threats concerning automatic interface classification cannot be
   mitigated by encrypting or authenticating HNCP traffic itself since
   external routers do not participate in the protocol and often cannot
   be authenticated by other means.  These threats include propagation
   of forged uplinks in the homenet in order to, e.g., redirect traffic
   destined to external locations and forged internal status by external
   routers to, e.g., circumvent the perimeter firewall.

   It is therefore imperative to either secure individual links on the
   physical or link layer or preconfigure the adjacent interfaces of
   HNCP routers to an appropriate fixed category in order to secure the
   homenet border.  Depending on the security of the external link,
   eavesdropping, man-in-the-middle, and similar attacks on external
   traffic can still happen between a homenet border router and the ISP;
   however, these cannot be mitigated from inside the homenet.  For
   example, DHCPv4 has defined [RFC3118] to authenticate DHCPv4
   messages, but this is very rarely implemented in large or small
   networks.  Further, while PPP can provide secure authentication of
   both sides of a point-to-point link, it is most often deployed with
   one-way authentication of the subscriber to the ISP, not the ISP to
   the subscriber.

12.2.  Security of Unicast Traffic

   Once the homenet border has been established, there are several ways
   to secure HNCP against internal threats like manipulation or
   eavesdropping by compromised devices on a link that is enabled for
   HNCP traffic.  If left unsecured, attackers may perform arbitrary
   traffic redirection, eavesdropping, spoofing, or denial-of-service
   attacks on HNCP services such as address assignment or service
   discovery, and the protocols are secured using HNCP-derived keys such
   as routing protocols.

   Detailed interface categories like "Leaf" or "Guest" can be used to
   integrate not fully trusted devices to various degrees into the
   homenet by not exposing them to HNCP traffic or by using firewall
   rules to prevent them from reaching homenet-internal resources.

   On links where this is not practical and lower layers do not provide
   adequate protection from attackers, DTLS-based secure unicast
   transport MUST be used to secure traffic.

12.3.  Other Protocols in the Home

   IGPs and other protocols are usually run alongside HNCP; therefore,
   the individual security aspects of the respective protocols must be
   considered.  It can, however, be summarized that many protocols to be
   run in the home (like IGPs) provide -- to a certain extent -- similar

Top      Up      ToC       Page 36 
   security mechanisms.  Most of these protocols do not support
   encryption and only support authentication based on Pre-Shared Keys
   natively.  This influences the effectiveness of any encryption-based
   security mechanism deployed by HNCP as homenet routing information is
   thus usually not encrypted.

13.  IANA Considerations

   IANA has set up a registry for the (decimal values within range
   32-511) "HNCP TLV Types" under "Distributed Node Consensus Protocol
   (DNCP)".  The registration procedures is 'RFC Required' [RFC5226].
   The initial contents are:

      32: HNCP-Version

      33: External-Connection

      34: Delegated-Prefix

      35: Assigned-Prefix

      36: Node-Address

      37: DHCPv4-Data

      38: DHCPv6-Data

      39: DNS-Delegated-Zone

      40: Domain-Name

      41: Node-Name

      42: Managed-PSK

      43: Prefix-Policy

      44-511: Unassigned.

      768-1023: Reserved for Private Use.  This range is used by HNCP
      for per-implementation experimentation.  How collisions are
      avoided is outside the scope of this document.

   IANA has registered the UDP port numbers 8231 (service name: hncp-
   udp-port, description: HNCP) and 8232 (service name: hncp-dtls-port,
   description: HNCP over DTLS), as well as an IPv6 link-local multicast
   address FF02:0:0:0:0:0:0:11 (description: All-Homenet-Nodes).

Top      Up      ToC       Page 37 
14.  References

14.1.  Normative References

   [RFC1321]  Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321,
              DOI 10.17487/RFC1321, April 1992,
              <http://www.rfc-editor.org/info/rfc1321>.

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

   [RFC2131]  Droms, R., "Dynamic Host Configuration Protocol",
              RFC 2131, DOI 10.17487/RFC2131, March 1997,
              <http://www.rfc-editor.org/info/rfc2131>.

   [RFC2132]  Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor
              Extensions", RFC 2132, DOI 10.17487/RFC2132, March 1997,
              <http://www.rfc-editor.org/info/rfc2132>.

   [RFC3004]  Stump, G., Droms, R., Gu, Y., Vyaghrapuri, R., Demirtjis,
              A., Beser, B., and J. Privat, "The User Class Option for
              DHCP", RFC 3004, DOI 10.17487/RFC3004, November 2000,
              <http://www.rfc-editor.org/info/rfc3004>.

   [RFC3315]  Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins,
              C., and M. Carney, "Dynamic Host Configuration Protocol
              for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July
              2003, <http://www.rfc-editor.org/info/rfc3315>.

   [RFC3633]  Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic
              Host Configuration Protocol (DHCP) version 6", RFC 3633,
              DOI 10.17487/RFC3633, December 2003,
              <http://www.rfc-editor.org/info/rfc3633>.

   [RFC4193]  Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast
              Addresses", RFC 4193, DOI 10.17487/RFC4193, October 2005,
              <http://www.rfc-editor.org/info/rfc4193>.

   [RFC4291]  Hinden, R. and S. Deering, "IP Version 6 Addressing
              Architecture", RFC 4291, DOI 10.17487/RFC4291, February
              2006, <http://www.rfc-editor.org/info/rfc4291>.

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

Top      Up      ToC       Page 38 
   [RFC5226]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
              IANA Considerations Section in RFCs", BCP 26, RFC 5226,
              DOI 10.17487/RFC5226, May 2008,
              <http://www.rfc-editor.org/info/rfc5226>.

   [RFC6092]  Woodyatt, J., Ed., "Recommended Simple Security
              Capabilities in Customer Premises Equipment (CPE) for
              Providing Residential IPv6 Internet Service", RFC 6092,
              DOI 10.17487/RFC6092, January 2011,
              <http://www.rfc-editor.org/info/rfc6092>.

   [RFC6206]  Levis, P., Clausen, T., Hui, J., Gnawali, O., and J. Ko,
              "The Trickle Algorithm", RFC 6206, DOI 10.17487/RFC6206,
              March 2011, <http://www.rfc-editor.org/info/rfc6206>.

   [RFC6347]  Rescorla, E. and N. Modadugu, "Datagram Transport Layer
              Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347,
              January 2012, <http://www.rfc-editor.org/info/rfc6347>.

   [RFC6603]  Korhonen, J., Ed., Savolainen, T., Krishnan, S., and O.
              Troan, "Prefix Exclude Option for DHCPv6-based Prefix
              Delegation", RFC 6603, DOI 10.17487/RFC6603, May 2012,
              <http://www.rfc-editor.org/info/rfc6603>.

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

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

   [RFC7695]  Pfister, P., Paterson, B., and J. Arkko, "Distributed
              Prefix Assignment Algorithm", RFC 7695,
              DOI 10.17487/RFC7695, November 2015,
              <http://www.rfc-editor.org/info/rfc7695>.

   [RFC7787]  Stenberg, M. and S. Barth, "Distributed Node Consensus
              Protocol", RFC 7787, DOI 10.17487/RFC7787, April 2016,
              <http://www.rfc-editor.org/info/rfc7787>.

Top      Up      ToC       Page 39 
14.2.  Informative References

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

   [RFC1918]  Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G.,
              and E. Lear, "Address Allocation for Private Internets",
              BCP 5, RFC 1918, DOI 10.17487/RFC1918, February 1996,
              <http://www.rfc-editor.org/info/rfc1918>.

   [RFC3118]  Droms, R., Ed. and W. Arbaugh, Ed., "Authentication for
              DHCP Messages", RFC 3118, DOI 10.17487/RFC3118, June 2001,
              <http://www.rfc-editor.org/info/rfc3118>.

   [RFC6234]  Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms
              (SHA and SHA-based HMAC and HKDF)", RFC 6234,
              DOI 10.17487/RFC6234, May 2011,
              <http://www.rfc-editor.org/info/rfc6234>.

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

   [RFC7084]  Singh, H., Beebee, W., Donley, C., and B. Stark, "Basic
              Requirements for IPv6 Customer Edge Routers", RFC 7084,
              DOI 10.17487/RFC7084, November 2013,
              <http://www.rfc-editor.org/info/rfc7084>.

   [RFC7368]  Chown, T., Ed., Arkko, J., Brandt, A., Troan, O., and J.
              Weil, "IPv6 Home Networking Architecture Principles",
              RFC 7368, DOI 10.17487/RFC7368, October 2014,
              <http://www.rfc-editor.org/info/rfc7368>.

   [RFC7525]  Sheffer, Y., Holz, R., and P. Saint-Andre,
              "Recommendations for Secure Use of Transport Layer
              Security (TLS) and Datagram Transport Layer Security
              (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May
              2015, <http://www.rfc-editor.org/info/rfc7525>.

Top      Up      ToC       Page 40 
Acknowledgments

   Thanks to Ole Troan, Mark Baugher, Mark Townsley, Juliusz Chroboczek,
   and Thomas Clausen for their contributions to the document.

   Thanks to Eric Kline for the original border discovery work.

Authors' Addresses

   Markus Stenberg
   Independent
   Helsinki  00930
   Finland

   Email: markus.stenberg@iki.fi


   Steven Barth
   Independent
   Halle  06114
   Germany

   Email: cyrus@openwrt.org


   Pierre Pfister
   Cisco Systems
   Paris
   France

   Email: pierre.pfister@darou.fr