| Network Working Group | M. Stenberg |
| Internet-Draft | S. Barth |
| Intended status: Standards Track | February 05, 2014 |
| Expires: August 09, 2014 |
Home Networking Control Protocol
draft-stenberg-homenet-hncp-00
This document describes the HomeNet Control Protocol (HNCP), a minimalist state synchronization protocol for Homenet routers.
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 August 09, 2014.
Copyright (c) 2014 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.
HNCP is designed to synchronize state across a Homenet (or other small site) in order to facilitate automated configuration within the site, integration with trusted bootstrapping [I-D.behringer-homenet-trust-bootstrap] and default perimeter detection [I-D.kline-homenet-default-perimeter], automatic IP prefix distribution [I-D.pfister-homenet-prefix-assignment], and service discovery across multiple links within the homenet as defined in [I-D.stenberg-homenet-dnssd-hybrid-proxy-network-zeroconf].
HNCP is designed to provide enough information for a routing protocol to operate without homenet-specific extensions. In homenet environments where multiple IPv6 prefixes are present, routing based on source and destination address is necessary [I-D.troan-homenet-sadr]. Routing protocol requirements for source and destination routing are described in section 3 of [I-D.baker-rtgwg-src-dst-routing-use-cases].
A GPLv2-licensed implementation of the HNCP protocol is currently under development at https://github.com/sbyx/hnetd/. Comments and/or pull requests are welcome.
An earlier implementation using many of the same principles, algorithms and data structures built within OSPFv3 is available at http://www.homewrt.org/doku.php?id=downloads.
In this document, the key words "MAY", "MUST, "MUST NOT", "OPTIONAL", "RECOMMENDED", "SHOULD", and "SHOULD NOT", are to be interpreted as described in [RFC2119].
The data model of the HNCP protocol is simple: Every participating node has (and also knows for every other participating node):
If HNCP security is enabled, each node will have a public/private key pair defined. The private key is used to create signatures for messages and node state updates and never sent across the network by HNCP. The public key is used to verify signatures of messages and node state updates.
HNCP is designed to run on UDP port IANA-UDP-PORT, using both link-local scoped IPv6 unicast and link-local scoped IPv6 multicast messages to address IANA-MULTICAST-ADDRESS for transport. The protocol consists of Trickle [RFC6206] driven multicast status messages to indicate changes in shared TLV data, and unicast state synchronization message exchanges when the Trickle state is found to be inconsistent.
Each node MUST send link-local multicast NetState Messages [net-message] each time the Trickle algorithm [RFC6206] indicates they should on each link the protocol is active on. When the locally stored network state hash changes (either by a local node event that affects the TLV data, or upon receipt of more recent data from another node), all Trickle instances MUST be reset. Trickle state MUST be maintained separately for each link.
Trickle algorithm has 3 parameters; Imin, Imax and k. Imin and Imax represent minimum and maximum values for I, which is the time interval during which at least k Trickle updates must be seen on a link to prevent local state transmission. Bounds for recommended Trickle values are described below.
Protocol messages are encoded as purely as a sequence of TLV objects [tlvs]. This section describes which set of TLVs MUST or MAY be present in a given message.
In order to facilitate fast comparing of local state with that in a received message update, all TLVs in every encoding scope (either root level, within the message itself, or within a container TLV) MUST be placed in ascending order based on the binary comparison of both TLV header and value. By design, the TLVs which MUST be present have the lowest available type values, ensuring they will naturally occur at the start of the Protocol Message, resembling a fixed format preamble.
This Message SHOULD be sent as a multicast message.
The following TLVs MUST be present at the start of the message:
The NetState Message MAY contain Node State TLV(s) [node-state]. If so, either all Node State TLVs are included (referred to as a "long" NetState Message), or none are included (refered to as a "short" NetState Message). The NetState Message MUST NOT contain only a portion of Node State TLVs as this could cause problems with the Protocol Message Processing [reception] algorithm. Finally, if the long version of the NetState message would exceed the minimum IPv6 MTU when sent, the short version of the NetState message MUST be used instead.
If HNCP security is enabled, authentication TLVs [auth-tlvs] MUST be present.
This Message MUST be sent as a unicast message.
The following TLVs MUST be present at the start of the message:
If HNCP security is enabled, authentication TLVs [auth-tlvs] MUST be present.
This Message MUST be sent as a unicast message.
MUST be present:
If HNCP security is enabled, authentication TLVs [auth-tlvs] MUST be present.
This Message MUST be sent as a unicast message.
MUST be present:
If HNCP security is enabled, authentication TLVs [auth-tlvs] MUST be present.
The majority of status updates among known nodes are handled via the Trickle-Driven updates [trickle-updates]. This section describes processing of messages as received, along with associated actions or responses.
HNCP is designed to operate between directly connected neighbors on a shared link using link-local IPv6 addresses. If the source address of a received HNCP packet is not an IPv6 link-local unicast address, the packet SHOULD be dropped. Similarly, if the destination address is not IPv6 link-local unicast or IPv6 link-local multicast address, packet SHOULD be dropped.
Upon receipt of:
Each node is responsible for publishing a valid set of data TLVs. When there is a change in a node's set of data TLVs, the update number MUST be incremented accordingly.
If a message containing Node State TLVs [node-state] is received via unicast or multicast with the node's own node identifier and a higher update number than current local value, or the same update number and different hash, there is an error somewhere. A recommended default way to handle this is to attempt to assert local state by increasing the local update number to a value higher than that received and republish node data using the same node identifier. If this happens more than 3 times in 60 seconds and the local node identifier is not globally unique, there may be more than one router with the same node identifier on the network. If HNCP security is not enabled, a new node identifier SHOULD be generated and node data republished accordingly. If HNCP security is enabled, this is event is highly unlikely to occur as collision of identifier hashes for public keys is highly unlikely.
In all cases, if node data for any node changes, all Trickle instances MUST be considered inconsistent (I=Imin + timer reset).
Whenever multicast message or unicast reply is received on a link from another node, the node should be added as Neighbor TLV [neighbor-tlv] for current node. If nothing (for example - no router advertisements, no HNCP traffic) is received from that neighbor in Imax seconds and the neighbor is not in neighbor discovery cache (and L2 indication of presence is available), at least 3 attempts to ping it with request network state message [req-net-message] SHOULD be sent with increasing timeouts (e.g. 1, 2, 4 seconds). If even after suitable period after the last message nothing is received, the Neighbor TLV MUST be removed so that there are no dangling neighbors. As an alternative, if there is a layer 2 unreachability notification of some sort available for either whole link or for individual neighbor, it MAY be used to immediately trigger removal of corresponding Neighbor TLV(s).
Nodes should be purged when unreachable. When node data has changed, the neighbor graph SHOULD be traversed for each node following the Neighbor TLVs, purging nodes that were found entirely unreachable (not traversed).
Every TLV is encoded as 2 octet type, followed by 2 octet length (of the whole TLV, including header; 4 means no value whatsoever), and then the value itself (if any). The actual length of TLV MUST be always divisible by 4; if the length of the value is not, zeroed padding bytes MUST be inserted at the end of TLV. The padding bytes MUST NOT be included in the length field.
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 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value |
| (variable # of bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Encoding of type=123 (0x7b) TLV with value 'x' (120 = 0x78): 007B 0005 7800 0000
Notation:
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: REQ-NETWORK-STATE (2) | Length: 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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: REQ-NODE-DATA (3) | Length: 20 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| H(node identifier) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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-LINK (1) | Length: 24 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| H(node identifier) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link-Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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: NETWORK-STATE (4) | Length: 20 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| H(H(node data TLV 1) .. H(node data TLV N)) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Node Data TLVs are ordered for hashing by octet comparison of the corresponding node identifier hashes in ascending order.
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-STATE (5) | Length: 44 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| H(node identifier) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Update Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Milliseconds since Origination |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| H(node data TLV) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The whole network should have roughly the same idea about the time since origination, i.e. even the originating router should increment the time whenever it needs to send a new Node State TLV regarding itself without changing the corresponding Node Data TLV. This age value is not included within the Node Data TLV, however, as that is immutable and potentially signed by the originating node at the time of origination.
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-DATA (6) | Length: >= 24 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| H(node identifier) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Update Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Nested TLVs containing node information |
The Node Public Key TLV [node-pk-tlv] SHOULD be always included if signatures are ever used.
If signatures are in use, the Node Data TLV SHOULD also contain the originator's own Signature TLV [sig-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: PUBLIC-KEY (7) | Length: >= 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Public Key (raw node identifier) |
Public key data for the node. Only relevant if signatures are used. Can be used to verify that H(node identifier) equals public key, and that the Signature TLVs are signed by appropriate public keys.
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: NEIGHBOR (8) | Length: 28 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| H(neighbor node identifier) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Neighbor Link Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local Link Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This TLV indicates that the node in question vouches that the specified neighbor is reachable by it on the local link id given. This reachability may be unidirectional (if no unicast exchanges have been performed with the neighbor). The presence of this TLV at least guarantees that the node publishing it has received traffic from the neighbor recently. For guaranteed bidirectional reachability, existence of both nodes' matching Neighbor TLVs should be checked.
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: CUSTOM-DATA (9) | Length: >= 12 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| H-64(URI) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Opaque Data |
This TLV can be used to contain anything; the URI used should be under control of the author of that specification. For example:
V=H-64('http://example.com/author/json-for-hncp') .. '{"cool": "json extension!"}'
or
V=H-64('mailto:author@example.com') .. '{"cool": "json extension!"}'
TBD; should be probably some sort of certificate ID to be used in a lookup at most, as raw certificates will overflow easily IPv6 minimum MTU.
TLV with T=0xFFFF, V=(TBD) public key algorithm based signature of all TLVs within current scope as well as the parent TLV header, if any. The assumed signature key is private key matching the public key of the the originator of node link TLV (if signature TLV is within main body of message), or that of the originator of the node data TLV (if signature TLV is within Node Data TLV)..
Using Default Border Definition [I-D.kline-homenet-default-perimeter] as a basis, this section defines border discovery algorithm specifics derived from the edge router interactions described in the Basic Requirements for IPv6 Customer Edge Routers [RFC7084]. The algorithm is designed to work for both IPv4 and IPv6 (single or dual-stack).
In order to avoid conflicts between border discovery and homenet routers running DHCP [RFC2131] or DHCPv6-PD [RFC3633] servers each router MUST implement the following mechanism based on The User Class Option for DHCP [RFC3004] or its DHCPv6 counterpart [RFC3315] respectively into its DHCP and DHCPv6-logic:
An interface MUST be considered external if at least one of the following conditions is satisfied:
Each router MUST continuously scan each active interface that does not have a fixed category in order to dynamically reclassify it if necessary. The router therefore runs an appropriately configured DHCP and DHCPv6-client as long as the interface is active including states where it considers the interface to be internal. The router SHOULD wait for a reasonable time period (5 seconds as a possible default) in which the DHCP-clients can acquire a lease before treating a newly activated or previously external interface as internal. Once it treats a certain interface as internal it MUST start forwarding traffic with appropriate source addresses between its internal interfaces and allow internal traffic to reach external networks. Once a router detects an interface to be external it MUST stop any previously enabled internal forwarding. In addition it SHOULD announce the acquired information for use in the homenet as described in later sections of this draft if the interface appears to be connected to an external network.
To distribute an external connection in the homenet an edge router announces one or more delegated prefixes and associated DHCP(v6)-encoded auxiliary information like recursive DNS-servers. Each external connection is announced using one container-TLV as follows:
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 (41)| Length: > 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Nested TLVs |
Auxiliary connectivity information is encoded as a stream of DHCPv6-attributes or DHCP-attributes placed inside a TLV of type EXTERNAL-CONNECTION or DELEGATED-PREFIX (for IPv6 prefix-specific information). There MUST NOT be more than one instance of this TLV inside a container and the order of the DHCP(v6)-attributes contained within it MUST be preserved as long as the information contained does not change. The TLVs are encoded as follows:
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 (45) | Length: > 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | DHCPv6 attribute stream |
and
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: DHCP-DATA (44) | Length: > 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | DHCP attribute stream |
Each delegated prefix is encoded using one TLV inside an EXTERNAL-CONNECTION TLV. For external IPv4 connections the prefix is encoded in the form of an IPv4-mapped address [RFC4291] and is usually from a private address range [RFC1597]. The related TLV is defined as follows.
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 (42) | Length: >= 13 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Valid until (milliseconds) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Preferred until (milliseconds) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Prefix Length | | +-+-+-+-+-+-+-+-+ Prefix Address [+ nested TLVs] + | |
In order for routers to use the distributed information, prefixes and addresses have to be assigned to the interior links of the homenet. A router MUST therefore implement the algorithm defined in Prefix and Address Assignment in a Home Network [I-D.pfister-homenet-prefix-assignment]. In order to announce the assigned prefixes the following TLVs are defined.
Each assigned prefix is given to an interior link and is encoded using one TLVs. Assigned IPv4 prefixes are stored as mapped IPv4-addresses. The TLV is defined as follows:
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 (43) | Length: >= 9 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Link Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | R. |A| Pref. | Prefix Length | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Prefix Address + | |
In some cases (e.g. IPv4) the set of addresses is very limited and stateless mechanisms are not really suitable for address assignment. Therefore HNCP can manage router address in these cases by itself. Each router assigning an address to one of its interfaces announces one TLV of the following kind:
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: ROUTER-ADDRESS (46) | Length: 20 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Router Address | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Service discovery is generally limited to a local link. [I-D.stenberg-homenet-dnssd-hybrid-proxy-network-zeroconf] defines a mechanism to automatically extended DNS-based service discovery across multiple links within the home automatically. Of the three TLVs, the DNS Delegated Zone TLV MUST be supported, and the remaining two SHOULD be.
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 (50) | Length: >= 21 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Address |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |S|B| |
+-+-+-+-+-+-+-+-+ Zone (DNS label sequence - variable length) |
| |
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 (51) | Length: >= 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Domain (DNS label sequence - variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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: ROUTER-NAME (52) | Length: >= 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Name (not null-terminated - variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
In order to be advertised for use within the Homenet, a routing protocol MUST:
A router MUST NOT announce that it supports a certain routing protocol if its implementation of the routing protocol does not meet these requirements, e.g. it does not implement extensions that are necessary for compliance.
Each router SHOULD announce all routing protocols that it is capable of supporting in the Homenet. It SHOULD assign a preference value for each protocol that indicates its desire to use said protocol over other protocols it supports and SHOULD make these values configurable.
Each router includes one HNCP TLV of type ROUTING-PROTOCOL for every such routing protocol. This TLV is defined as follows:
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: ROUTING-PROTOCOL (60) | Length: 6 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Protocol ID | Preference | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
When HNCP detects that a router has joined or left the Homenet it MUST examine all advertised routing protocols and preference values from all routers in the Homenet in order to find the one routing protocol which:
If the router protocol selection results in the need to change from one routing protocol to another on the homenet, the router MUST stop the previously running protocol, remove associated routes, and start the new protocol in a graceful manner. If there is no common routing protocol available among all Homenet routers, routers MUST utilize the Fallback Mechanism [fallback].
In cases where there is no commonly supported routing protocol available the following fallback algorithm is run to setup routing and preserve interoperability among the homenet. While not intended to replace a routing protocol, this mechanism provides a valid - but not necessarily optimal - routing topology. This algorithm uses the node and neighbor state already synchronized by HNCP, and therefore does not require any additional protocol message exchange.
General security issues for Home Networks are discussed at length in [I-D.ietf-homenet-arch]. The protocols used to setup IP in home networks today have very little security enabled within the control protocol itself. For example, DHCP has defined [RFC3118] to authenticate DHCP 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. HNCP aims to make security as easy as possible for the implementer by including built-in capabilities for authentication of node data being exchanged as well as the protocol messages themselves, but it is ultimately up to the shipping system to take advantage of the protocol constructs defined.
HNCP is designed to integrate with trusted bootstrapping [I-D.behringer-homenet-trust-bootstrap] including the ability to authenticate messages between nodes. This authentication can be used to securely define a border as well as protect against malicious attacks and spoofing attempts from inside or outside the border.
HNCP itself sends messages as (possibly authenticated) clear text which is as secure, or insecure, as the security of the link below as discussed in [I-D.kline-homenet-default-perimeter]. When no unique public key is available, a hardware fingerprint or equivalent to identify routers must be available for use by HNCP.
As HNCP messages are sent over UDP/IP, IPsec may be used for confidentiality or additional message authenitation. However, this requires manually keyed IPsec per-port granularity for port IANA-UDP-PORT UDP traffic. Also, a pre-shared key has to be utilized in this case given IKE cannot be used with multicast traffic.
If no router can be trusted and additional guarantees about source of node status updates is necessary, real public and private keys should be used to create signatures and verify them in HNCP on both on per-node data TLVs as well as across the entire HNCP message. In this mode, care must be taken in rate limiting verification of invalid packets, as otherwise denial of service may occur due to exhaustion of computation resources.
As a performance optimization, instead of providing signatures for actual node data and the protocol messages themselves, it is also possible to provide signatures just for protocol messages. While this means it is no longer possible to verify the original source of the node data itself, as long as the set of routers is trusted (i.e., no router in the set has itself been hacked to provide malicious node data) then one can assume the node data is trusted because the router is trusted and the data arrived in a protected protocol message.
IANA should set up a registry (policy TBD) for HNCP TLV types, with following initial contents:
0: Reserved (should not happen on wire)
1: Node link
2: Request network state
3: Request node data
4: Network state
5: Node state
6: Node data
7: Node public key
8: Neighbor
9: Custom
41: External connection
42: Delegated prefix
43: Assigned prefix
44: DHCP-data
45: DHCPv6-data
46: Router-address
50: DNS Delegated Zone
51: Domain name
52: Node name
60: Routing protocol
65535: Signature
HNCP will also require allocation of a UDP port number IANA-UDP-PORT, as well as IPv6 link-local multicast address IANA-MULTICAST-ADDRESS.
| [RFC2119] | Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. |
| [RFC6206] | Levis, P., Clausen, T., Hui, J., Gnawali, O. and J. Ko, "The Trickle Algorithm", RFC 6206, March 2011. |
| [I-D.pfister-homenet-prefix-assignment] | Pfister, P., Arkko, J. and B. Paterson, "Prefix and Address Assignment in a Home Network", Internet-Draft draft-pfister-homenet-prefix-assignment-00, January 2014. |
| [I-D.stenberg-homenet-dnssd-hybrid-proxy-network-zeroconf] | Stenberg, M., "Auto-Configuration of a Network of Hybrid Unicast/Multicast DNS-Based Service Discovery Proxy Nodes ", Internet-Draft draft-pfister-homenet-prefix-assignment-00, January 2014. |
| [RFC7084] | Singh, H., Beebee, W., Donley, C. and B. Stark, "Basic Requirements for IPv6 Customer Edge Routers", RFC 7084, November 2013. |
| [RFC3004] | Stump, G., Droms, R., Gu, Y., Vyaghrapuri, R., Demirtjis, A., Beser, B. and J. Privat, "The User Class Option for DHCP", RFC 3004, November 2000. |
| [RFC3118] | Droms, R. and W. Arbaugh, "Authentication for DHCP Messages", RFC 3118, June 2001. |
| [RFC2131] | Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March 1997. |
| [RFC3315] | Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C. and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003. |
| [RFC3633] | Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic Host Configuration Protocol (DHCP) version 6", RFC 3633, December 2003. |
| [RFC1597] | Rekhter, Y., Moskowitz, R.G., Karrenberg, D. and G.J. de Groot, "Address Allocation for Private Internets", RFC 1597, March 1994. |
| [RFC4291] | Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, February 2006. |
| [I-D.ietf-homenet-arch] | Chown, T., Arkko, J., Brandt, A., Troan, O. and J. Weil, "IPv6 Home Networking Architecture Principles", Internet-Draft draft-ietf-homenet-arch-11, October 2013. |
| [I-D.troan-homenet-sadr] | Troan, O. and L. Colitti, "IPv6 Multihoming with Source Address Dependent Routing (SADR)", Internet-Draft draft-troan-homenet-sadr-01, September 2013. |
| [I-D.behringer-homenet-trust-bootstrap] | Behringer, M., Pritikin, M. and S. Bjarnason, "Bootstrapping Trust on a Homenet", Internet-Draft draft-behringer-homenet-trust-bootstrap-00, October 2012. |
| [I-D.baker-rtgwg-src-dst-routing-use-cases] | Baker, F., "Requirements and Use Cases for Source/Destination Routing", Internet-Draft draft-baker-rtgwg-src-dst-routing-use-cases-00, August 2013. |
| [I-D.kline-homenet-default-perimeter] | Kline, E., "Default Border Definition", Internet-Draft draft-kline-homenet-default-perimeter-00, March 2013. |
| [I-D.arkko-homenet-prefix-assignment] | Arkko, J., Lindem, A. and B. Paterson, "Prefix Assignment in a Home Network", Internet-Draft draft-arkko-homenet-prefix-assignment-04, May 2013. |
| [I-D.stenberg-homenet-dnssdext-hybrid-proxy-ospf] | Stenberg, M., "Hybrid Unicast/Multicast DNS-Based Service Discovery Auto-Configuration Using OSPFv3", Internet-Draft draft-stenberg-homenet-dnssdext-hybrid-proxy-ospf-00, June 2013. |
| [I-D.acee-ospf-ospfv3-autoconfig] | Lindem, A. and J. Arkko, "OSPFv3 Auto-Configuration", Internet-Draft draft-acee-ospf-ospfv3-autoconfig-03, July 2012. |
Should we use MD5 hashes, or EUI-64 node identifier to identify nodes?
Is there a case for non-link-local unicast? Currently explicitly stating this is link-local only protocol.
Consider if using Trickle with k=1 really pays off, as we need to do reachability checks if L2 doesn't provide them periodically in any case. Using Trickle with k=inf would remove the need for unicast reachability checks, but at cost of extra multicast traffic. On the other hand, N*(N-1)/2 unicast reachability checks when lot of routers share a link is not appealing either.
Should we use something else than MD5 as hash? It IS somewhat insecure; however signature stuff (TBD) should rely on it mainly for security in any case, and MD5 is used in a non-security role.
Q: Why not use TCP?
A: It doesn't address the node discovery problem. It also leads to N*(N-1)/2 connections when N nodes share a link, which is awkward.
Q: Why effectively build a link state routing protocol without routing?
A: It felt like a good idea at the time. It does not require periodic flooding except for very minimal Trickle-based per-link state maintenance (potentially also neighbor reachability checks if so desired).
Q: Why not multicast-only?
A: It would require defining application level fragmentation scheme. Hopefully the data amounts used will stay small so we just trust unicast UDP to handle 'big enough' packets to contain single node's TLV data. On some link layers unicast is also much more reliable than multicast, especially for large packets.
Q: Why so long IDs? Why real hash even in insecure mode?
A: Scalability of protocol isn't really affected by using real (=cryptographic) hash function.
Q: Why trust IPv6 fragmentation in unicast case? Why not do L7 fragmentation?
A: Because it will be there for a while at least. And while PMTU et al may be problems on open internet, in a home network environment UDP fragmentation should NOT be broken in the foreseeable future.
Q: Should there be nested container syntax that is actually self-describing? (i.e. type flag that indicates container, no body except sub-TLVs?)
A: Not for now, but perhaps valid design.. TBD.
Q: Why not doing (performance thing X, Y or Z)?
A: This is designed mostly to be minimal (only timers Trickle ones; everything triggered by Trickle-driven messages or local state changes). However, feel free to suggest better (even more minimal) design which works.
As usual, this draft is available at https://github.com/fingon/ietf-drafts/ in source format (with nice Makefile too). Feel free to send comments and/or pull requests if and when you have changes to it!
Thanks to Ole Troan, Pierre Pfister, Mark Baugher, Mark Townsley and Juliusz Chroboczek for their contributions to the draft.