Create TUBYOUT

[mohamed1314]

PR Type

What kind of change does this PR introduce?

[ ] Bugfix
[ ] Feature
[ ] Refactoring (no functional changes, no api changes)
[ ] Documentation content changes
[ ] Other: <!-- Please describe: -->

What is the current behavior?

Issue Number: N/A

What is the new behavior?

Does this PR introduce a breaking change?

[ ] Yes
[ ] No

Other information

[pantomaxbot]

Do you want me to review this PR? Please comment /review .

[nevagenesis]

[RFC Home] [TEXT|PDF|HTML] [Tracker] [IPR] [Errata] [Info page]

                                                   PROPOSED STANDARD

Updated by: 8375 Errata Exist
Internet Engineering Task Force (IETF) M. Stenberg
Request for Comments: 7788 S. Barth
Category: Standards Track Independent
ISSN: 2070-1721 P. Pfister
Cisco Systems
April 2016

                Home Networking Control Protocol

Abstract

This document describes the Home Networking Control Protocol (HNCP),
an extensible configuration protocol, and a set of requirements for
home network devices. HNCP is described as a profile of and
extension to the Distributed Node Consensus Protocol (DNCP). HNCP
enables discovery of network borders, automated configuration of
addresses, name resolution, service discovery, and the use of any
routing protocol that supports routing based on both the source and
destination address.

Status of This Memo

This is an Internet Standards Track document.

This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 5741.

Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc7788.

Stenberg, et al. Standards Track [Page 1]

RFC 7788 Home Networking Control Protocol April 2016

Copyright Notice

Copyright (c) 2016 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
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.

Table of Contents

1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
   1.1. Applicability . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
   2.1. Requirements Language . . . . . . . . . . . . . . . . . . 7
3. DNCP Profile . . . . . . . . . . . . . . . . . . . . . . . . 7
4. HNCP Versioning and Router Capabilities . . . . . . . . . . . 9
5. Interface Classification . . . . . . . . . . . . . . . . . . 9
   5.1. Interface Categories . . . . . . . . . . . . . . . . . . 9
   5.2. DHCP-Aided Auto-Detection . . . . . . . . . . . . . . . . 10
   5.3. Algorithm for Border Discovery . . . . . . . . . . . . . 11
6. Autonomous Address Configuration . . . . . . . . . . . . . . 12
   6.1. Common Link . . . . . . . . . . . . . . . . . . . . . . . 12
   6.2. External Connections . . . . . . . . . . . . . . . . . . 13
   6.3. Prefix Assignment . . . . . . . . . . . . . . . . . . . . 14
   6.3.1. Prefix Assignment Algorithm Parameters . . . . . . . 14
   6.3.2. Making New Assignments . . . . . . . . . . . . . . . 16
   6.3.3. Applying Assignments . . . . . . . . . . . . . . . . 17
   6.3.4. DHCPv6 Prefix Delegation . . . . . . . . . . . . . . 17
   6.4. Node Address Assignment . . . . . . . . . . . . . . . . . 17
   6.5. Local IPv4 and ULA Prefixes . . . . . . . . . . . . . . . 18
7. Configuration of Hosts and Non-HNCP Routers . . . . . . . . . 19
   7.1. IPv6 Addressing and Configuration . . . . . . . . . . . . 19
   7.2. DHCPv6 for Prefix Delegation . . . . . . . . . . . . . . 20
   7.3. DHCPv4 for Addressing and Configuration . . . . . . . . . 20
   7.4. Multicast DNS Proxy . . . . . . . . . . . . . . . . . . . 21
8. Naming and Service Discovery . . . . . . . . . . . . . . . . 21
9. Securing Third-Party Protocols . . . . . . . . . . . . . . . 22

Stenberg, et al. Standards Track [Page 2]

RFC 7788 Home Networking Control Protocol April 2016

10. Type-Length-Value Objects . . . . . . . . . . . . . . . . . . 23
    10.1. HNCP-Version TLV . . . . . . . . . . . . . . . . . . . . 23
    10.2. External-Connection TLV . . . . . . . . . . . . . . . . 24
    10.2.1. Delegated-Prefix TLV . . . . . . . . . . . . . . . . 25
    10.2.2. DHCPv6-Data TLV . . . . . . . . . . . . . . . . . . 27
    10.2.3. DHCPv4-Data TLV . . . . . . . . . . . . . . . . . . 27
    10.3. Assigned-Prefix TLV . . . . . . . . . . . . . . . . . . 28
    10.4. Node-Address TLV . . . . . . . . . . . . . . . . . . . . 29
    10.5. DNS-Delegated-Zone TLV . . . . . . . . . . . . . . . . . 30
    10.6. Domain-Name TLV . . . . . . . . . . . . . . . . . . . . 31
    10.7. Node-Name TLV . . . . . . . . . . . . . . . . . . . . . 31
    10.8. Managed-PSK TLV . . . . . . . . . . . . . . . . . . . . 32

11. General Requirements for HNCP Nodes . . . . . . . . . . . . . 32

12. Security Considerations . . . . . . . . . . . . . . . . . . . 34
    12.1. Interface Classification . . . . . . . . . . . . . . . . 34
    12.2. Security of Unicast Traffic . . . . . . . . . . . . . . 35
    12.3. Other Protocols in the Home . . . . . . . . . . . . . . 35

13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 36

14. References . . . . . . . . . . . . . . . . . . . . . . . . . 37
    14.1. Normative References . . . . . . . . . . . . . . . . . . 37
    14.2. Informative References . . . . . . . . . . . . . . . . . 39
    Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 40
    Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 40

15. Introduction

The Home Networking Control Protocol (HNCP) is designed to facilitate
the sharing of state among home routers to fulfill the needs of the
IPv6 homenet architecture [RFC7368], which assumes zero-configuration
operation, multiple subnets, multiple home routers, and (potentially)
multiple upstream service providers providing (potentially) multiple
prefixes to the home network. While RFC 7368 sets no requirements
for IPv4 support, HNCP aims to support the dual-stack mode of
operation, and therefore the functionality is designed with that in
mind. The state is shared as TLVs transported in the DNCP node state
among the routers (and potentially advanced hosts) to enable:

o Autonomic discovery of network borders (Section 5.3) based on
Distributed Node Consensus Protocol (DNCP) topology.

o Automated portioning of prefixes delegated by the service
providers as well as assigned prefixes to both HNCP and non-HNCP
routers (Section 6.3) using [RFC7695]. Prefixes assigned to HNCP
routers are used to:

  *  Provide addresses to non-HNCP aware nodes (using Stateless
     Address Autoconfiguration (SLAAC) and DHCP).

Stenberg, et al. Standards Track [Page 3]

RFC 7788 Home Networking Control Protocol April 2016

  *  Provide space in which HNCP nodes assign their own addresses
     (Section 6.4).

o Internal and external name resolution, as well as multi-link
service discovery (Section 8).

o Other services not defined in this document that do need to share
state among homenet nodes and do not cause rapid and constant TLV
changes (see the following applicability section).

HNCP is a protocol based on DNCP [RFC7787] and includes a DNCP
profile that defines transport and synchronization details for
sharing state across nodes defined in Section 3. The rest of the
document defines behavior of the services noted above, how the
required TLVs are encoded (Section 10), as well as additional
requirements on how HNCP nodes should behave (Section 11).

1.1. Applicability

While HNCP does not deal with routing protocols directly (except
potentially informing them about internal and external interfaces if
classification specified in Section 5.3 is used), in homenet
environments where multiple IPv6 source prefixes can be present,
routing based on the source and destination address is necessary
[RFC7368]. Ideally, the routing protocol is also zero configuration
(e.g., no need to configure identifiers or metrics), although HNCP
can also be used with a manually configured routing protocol.

As HNCP uses DNCP as the actual state synchronization protocol, the
applicability statement of DNCP applies here as well; HNCP should not
be used for any data that changes rapidly and constantly. If such
data needs to be published in an HNCP network, 1) a more applicable
protocol should be used for those portions, and 2) locators to a
server of said protocol should be announced using HNCP instead. An
example for this is naming and service discovery (Section 8) for
which HNCP only transports DNS server addresses and no actual per-
name or per-service data of hosts.

HNCP TLVs specified within this document, in steady state, stay
constant, with one exception: as Delegated-Prefix TLVs
(Section 10.2.1) do contain lifetimes, they force republishing of
that data every time the valid or preferred lifetimes of prefixes are
updated (significantly). Therefore, it is desirable for ISPs to
provide large enough valid and preferred lifetimes to avoid
unnecessary HNCP state churn in homes, but even given non-cooperating
ISPs, the state churn is proportional only to the number of
externally received delegated prefixes and not to the home network
size, and it should therefore be relatively low.

Stenberg, et al. Standards Track [Page 4]

RFC 7788 Home Networking Control Protocol April 2016

HNCP assumes a certain level of control over host configuration
servers (e.g., DHCP [RFC2131]) on links that are managed by its
routers. Some HNCP functionality (such as border discovery or some
aspects of naming) might be affected by existing DHCP servers that
are not aware of the HNCP-managed network and thus might need to be
reconfigured to not result in unexpected behavior.

While HNCP routers can provide configuration to and receive
configuration from non-HNCP routers, they are not able to traverse
such devices based solely on the protocol as defined in this
document, i.e., HNCP routers that are connected only by different
interfaces of a non-HNCP router will not be part of the same HNCP
network.

While HNCP is designed to be used by (home) routers, it can also be
used by advanced hosts that want to do, e.g., their own address
assignment and routing.

HNCP is link-layer agnostic; if a link supports IPv6 (link-local)
multicast and unicast, HNCP will work on it. Trickle retransmissions
and keep-alives will handle both packet loss and non-transitive
connectivity, ensuring eventual convergence.

2. Terminology

The following terms are used as they are defined in [RFC7695]:

o Advertised Prefix Priority

o Advertised Prefix

o Assigned Prefix

o Delegated Prefix

o Prefix Adoption

o Private Link

o Published Assigned Prefix

o Applied Assigned Prefix

o Shared Link

Stenberg, et al. Standards Track [Page 5]

RFC 7788 Home Networking Control Protocol April 2016

The following terms are used as they are defined in [RFC7787]:

o DNCP profile

o Node identifier

o Link

o Interface

(HNCP) node a device implementing this specification.

(HNCP) router a device implementing this specification, which
forwards traffic on behalf of other devices.

Greatest node when comparing the DNCP node identifiers of
identifier multiple nodes, the one that has the greatest value
in a bitwise comparison.

Border separation point between administrative domains; in
this case, between the home network and any other
network, i.e., usually an ISP network.

Internal link a link that does not cross borders.

Internal an interface that is connected to an internal link.
interface

External an interface that is connected to a link that is
interface not an internal link.

Interface a local configuration denoting the use of a
category particular interface. The Interface category
determines how an HNCP node should treat the
particular interface. The External and Internal
categories mark the interface as out of or within
the network border; there are also a number of
subcategories of Internal that further affect local
node behavior. See Section 5.1 for a list of
interface categories and how they behave. The
Internal or External category may also be auto-
detected (Section 5.3).

Border router a router announcing external connectivity and
forwarding traffic across the network border.

Stenberg, et al. Standards Track [Page 6]

RFC 7788 Home Networking Control Protocol April 2016

Common Link a set of nodes on a link that share a common view
of it, i.e., they see each other's traffic and the
same set of hosts. Unless configured otherwise,
transitive connectivity is assumed.

DHCPv4 refers to the Dynamic Host Configuration Protocol
[RFC2131] in this document.

DHCPv6 refers to the Dynamic Host Configuration Protocol
for IPv6 (DHCPv6) [RFC3315] in this document.

DHCP refers to cases that apply to both DHCPv4 and
DHCPv6 in this document.

2.1. Requirements Language

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in RFC
2119 [RFC2119].

3. DNCP Profile

The DNCP profile for HNCP is defined as follows:

o HNCP uses UDP datagrams on port 8231 as a transport over link-
local scoped IPv6, using unicast and multicast
(FF02:0:0:0:0:0:0:11 is the HNCP group address). Received
datagrams where either or both of the IPv6 source or destination
addresses are not link-local scoped MUST be ignored. Replies to
multicast and unicast messages MUST be sent to the IPv6 source
address and port of the original message. Each node MUST be able
to receive (and potentially reassemble) UDP datagrams with a
payload of at least 4000 bytes.

o HNCP operates on multicast-capable interfaces only. HNCP nodes
MUST assign a non-zero 32-bit endpoint identifier to each
interface for which HNCP is enabled. The value 0 is not used in
DNCP TLVs but has a special meaning in HNCP TLVs (see Sections 6.4
and 10.3). These identifiers MUST be locally unique within the
scope of the node, and using values equivalent to the IPv6 link-
local scope identifiers for the given interfaces are RECOMMENDED.

o HNCP uses opaque 32-bit node identifiers
(DNCP_NODE_IDENTIFIER_LENGTH = 32). A node implementing HNCP
SHOULD use a random node identifier. If there is a node
identifier collision (as specified in the Node-State TLV handling
of Section 4.4 of [RFC7787]), the node MUST immediately generate

Stenberg, et al. Standards Track [Page 7]

RFC 7788 Home Networking Control Protocol April 2016

  and use a new random node identifier that is not used by any other
  node at the time, based on the current DNCP network state.

o HNCP nodes MUST use the leading 64 bits of the MD5 message digest
[RFC1321] as the DNCP hash function H(x) used in building the DNCP
hash tree.

o HNCP nodes MUST use DNCP's per-endpoint keep-alive extension on
all endpoints. The following parameters are suggested:

  *  Default keep-alive interval (DNCP_KEEPALIVE_INTERVAL): 20
     seconds.

  *  Multiplier (DNCP_KEEPALIVE_MULTIPLIER): 2.1 on virtually
     lossless links works fine, as it allows for one lost keep-
     alive.  If used on a lossy link, a considerably higher
     multiplier, such as 15, should be used instead.  In that case,
     an implementation might prefer shorter keep-alive intervals on
     that link as well to ensure that the timeout (equal to
     DNCP_KEEPALIVE_INTERVAL * DNCP_KEEPALIVE_MULTIPLIER) after
     which entirely lost nodes time out is low enough.

o HNCP nodes use the following Trickle parameters for the per-
interface Trickle instances:

  *  k SHOULD be 1, as the timer reset when data is updated, and
     further retransmissions should handle packet loss.  Even on a
     non-transitive lossy link, the eventual per-endpoint keep-
     alives should ensure status synchronization occurs.

  *  Imin SHOULD be 200 milliseconds but MUST NOT be lower.  Note:
     earliest transmissions may occur at Imin / 2.

  *  Imax SHOULD be 7 doublings of Imin [RFC6206] but MUST NOT be
     lower.

o HNCP unicast traffic SHOULD be secured using Datagram Transport
Layer Security (DTLS) [RFC6347] as described in DNCP if exchanged
over unsecured links. UDP on port 8232 is used for this purpose.
A node implementing HNCP security MUST support the DNCP Pre-Shared
Key (PSK) method, SHOULD support the PKI-based trust method, and
MAY support the DNCP certificate-based trust consensus method.
[RFC7525] provides guidance on how to securely utilize DTLS.

o HNCP nodes MUST ignore all Node-State TLVs received via multicast
on a link that has DNCP security enabled in order to prevent
spoofing of node state changes.

Stenberg, et al. Standards Track [Page 8]

RFC 7788 Home Networking Control Protocol April 2016

4. HNCP Versioning and Router Capabilities

Multiple versions of HNCP based on compatible DNCP profiles may be
present in the same network when transitioning between HNCP versions,
and for troubleshooting purposes, it might be beneficial to identify
the HNCP agent version running. Therefore, each node MUST include an
HNCP-Version TLV (Section 10.1) indicating the currently supported
version in its node data and MUST ignore (except for DNCP
synchronization purposes) any TLVs that have a type greater than 32
and that are published by nodes that didn't also publish an HNCP-
Version TLV.

HNCP routers may also h