draft-ietf-homenet-hncp-01.txt   draft-ietf-homenet-hncp-02.txt 
Homenet Working Group M. Stenberg Homenet Working Group M. Stenberg
Internet-Draft Internet-Draft
Intended status: Standards Track S. Barth Intended status: Standards Track S. Barth
Expires: December 27, 2014 Expires: April 30, 2015
June 25, 2014 October 27, 2014
Home Networking Control Protocol Home Networking Control Protocol
draft-ietf-homenet-hncp-01 draft-ietf-homenet-hncp-02
Abstract Abstract
This document describes the Home Networking Control Protocol (HNCP), This document describes the Home Networking Control Protocol (HNCP),
a minimalist state synchronization protocol for Homenet routers. a minimalist state synchronization protocol for homenet routers.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on December 27, 2014. This Internet-Draft will expire on April 30, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 12 skipping to change at page 2, line 12
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Requirements language . . . . . . . . . . . . . . . . . . . . 3 2. Requirements language . . . . . . . . . . . . . . . . . . . . 3
3. Data model . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Data model . . . . . . . . . . . . . . . . . . . . . . . . . 3
4. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 4 4. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 4
4.1. Trickle-Driven Status Updates . . . . . . . . . . . . . . 4 4.1. Trickle-Driven Status Updates . . . . . . . . . . . . . . 4
4.2. Protocol Messages . . . . . . . . . . . . . . . . . . . . 5 4.2. Protocol Messages . . . . . . . . . . . . . . . . . . . . 4
4.2.1. Network State Update (NetState) . . . . . . . . . . . 5 4.2.1. Network State Update (NetState) . . . . . . . . . . . 5
4.2.2. Network State Request, (NetState-Req) . . . . . . . . 5 4.2.2. Network State Request, (NetState-Req) . . . . . . . . 5
4.2.3. Node Data Request (Node-Req) . . . . . . . . . . . . 6 4.2.3. Node Data Request (Node-Req) . . . . . . . . . . . . 5
4.2.4. Network and Node State Reply (NetNode-Reply) . . . . 6 4.2.4. Network and Node State Reply (NetNode-Reply) . . . . 6
4.3. HNCP Protocol Message Processing . . . . . . . . . . . . 6 4.3. HNCP Protocol Message Processing . . . . . . . . . . . . 6
4.4. Adding and Removing Neighbors . . . . . . . . . . . . . . 8 4.4. Adding and Removing Neighbors . . . . . . . . . . . . . . 7
4.5. Purging Unreachable Nodes . . . . . . . . . . . . . . . . 8 4.5. Purging Unreachable Nodes . . . . . . . . . . . . . . . . 8
5. Type-Length-Value objects . . . . . . . . . . . . . . . . . . 8 5. Type-Length-Value objects . . . . . . . . . . . . . . . . . . 8
5.1. Request TLVs (for use within unicast requests) . . . . . 9 5.1. Request TLVs (for use within unicast requests) . . . . . 8
5.1.1. Request Network State TLV . . . . . . . . . . . . . . 9 5.1.1. Request Network State TLV . . . . . . . . . . . . . . 9
5.1.2. Request Node Data TLV . . . . . . . . . . . . . . . . 9 5.1.2. Request Node Data TLV . . . . . . . . . . . . . . . . 9
5.2. Data TLVs (for use in both multi- and unicast data) . . . 10 5.2. Data TLVs (for use in both multi- and unicast data) . . . 9
5.2.1. Node Link TLV . . . . . . . . . . . . . . . . . . . . 10 5.2.1. Node Link TLV . . . . . . . . . . . . . . . . . . . . 9
5.2.2. Network State TLV . . . . . . . . . . . . . . . . . . 10 5.2.2. Network State TLV . . . . . . . . . . . . . . . . . . 9
5.2.3. Node State TLV . . . . . . . . . . . . . . . . . . . 10 5.2.3. Node State TLV . . . . . . . . . . . . . . . . . . . 10
5.2.4. Node Data TLV . . . . . . . . . . . . . . . . . . . . 11 5.2.4. Node Data TLV . . . . . . . . . . . . . . . . . . . . 11
5.2.5. Node Public Key TLV (within 5.2.5. Neighbor TLV (within Node Data TLV) . . . . . . . . . 11
Node Data TLV) . . . . . . . . . . . . . . . . . . . 12 5.3. Custom TLV (within/without Node Data TLV) . . . . . . . . 11
5.2.6. Neighbor TLV (within Node Data TLV) . . . . . . . . . 12 5.4. Version TLV (within Node Data TLV) . . . . . . . . . . . 12
5.3. Custom TLV (within/without Node Data TLV) . . . . . . . . 12 6. Border Discovery and Prefix Assignment . . . . . . . . . . . 12
5.4. Version TLV (within Node Data TLV) . . . . . . . . . . . 13 7. DNS-based Service Discovery . . . . . . . . . . . . . . . . . 17
5.5. Authentication TLVs . . . . . . . . . . . . . . . . . . . 13 7.1. DNS Delegated Zone TLV . . . . . . . . . . . . . . . . . 17
5.5.1. Certificate-related TLVs . . . . . . . . . . . . . . 13 7.2. Domain Name TLV . . . . . . . . . . . . . . . . . . . . . 18
5.5.2. Signature TLV . . . . . . . . . . . . . . . . . . . . 14 7.3. Router Name TLV . . . . . . . . . . . . . . . . . . . . . 18
6. Border Discovery and Prefix Assignment . . . . . . . . . . . 14 8. Routing support . . . . . . . . . . . . . . . . . . . . . . . 18
7. DNS-based Service Discovery . . . . . . . . . . . . . . . . . 19 8.1. Protocol Requirements . . . . . . . . . . . . . . . . . . 18
7.1. DNS Delegated Zone TLV . . . . . . . . . . . . . . . . . 19 8.2. Announcement . . . . . . . . . . . . . . . . . . . . . . 18
7.2. Domain Name TLV . . . . . . . . . . . . . . . . . . . . . 19 8.3. Protocol Selection . . . . . . . . . . . . . . . . . . . 19
7.3. Router Name TLV . . . . . . . . . . . . . . . . . . . . . 19 8.4. Fallback Mechanism . . . . . . . . . . . . . . . . . . . 20
8. Routing support . . . . . . . . . . . . . . . . . . . . . . . 20 9. Security Considerations . . . . . . . . . . . . . . . . . . . 21
8.1. Protocol Requirements . . . . . . . . . . . . . . . . . . 20 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21
8.2. Announcement . . . . . . . . . . . . . . . . . . . . . . 20 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 22
8.3. Protocol Selection . . . . . . . . . . . . . . . . . . . 21 11.1. Normative references . . . . . . . . . . . . . . . . . . 22
8.4. Fallback Mechanism . . . . . . . . . . . . . . . . . . . 21 11.2. Informative references . . . . . . . . . . . . . . . . . 23
9. Security Considerations . . . . . . . . . . . . . . . . . . . 22 11.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 24
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 Appendix A. Some Outstanding Issues . . . . . . . . . . . . . . 24
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 24 Appendix B. Some Obvious Questions and Answers . . . . . . . . . 24
11.1. Normative references . . . . . . . . . . . . . . . . . . 24 Appendix C. Changelog . . . . . . . . . . . . . . . . . . . . . 25
11.2. Informative references . . . . . . . . . . . . . . . . . 25 Appendix D. Draft source . . . . . . . . . . . . . . . . . . . . 26
11.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 26 Appendix E. Acknowledgements . . . . . . . . . . . . . . . . . . 26
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26
Appendix A. Some Outstanding Issues . . . . . . . . . . . . . . 26
Appendix B. Some Obvious Questions and Answers . . . . . . . . . 27
Appendix C. Changelog . . . . . . . . . . . . . . . . . . . . . 28
Appendix D. Draft source . . . . . . . . . . . . . . . . . . . . 28
Appendix E. Acknowledgements . . . . . . . . . . . . . . . . . . 28
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28
1. Introduction 1. Introduction
HNCP is designed to synchronize state across a Homenet (or other HNCP is designed to synchronize state across a homenet (or other
small site) in order to facilitate automated configuration within the small site) in order to facilitate automated configuration within the
site, integration with trusted bootstrapping site. The design supports border discovery, IP prefix distribution
[I-D.behringer-homenet-trust-bootstrap] and default perimeter [I-D.ietf-homenet-prefix-assignment], and service discovery across
detection [I-D.kline-homenet-default-perimeter], automatic IP prefix multiple links[I-D.stenberg-homenet-dnssd-hybrid-proxy-zeroconf].
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-zeroconf].
HNCP is designed to provide enough information for a routing protocol HNCP is designed to provide enough information for a routing protocol
to operate without homenet-specific extensions. In homenet to operate without homenet-specific extensions. In homenet
environments where multiple IPv6 prefixes are present, routing based environments where multiple IPv6 prefixes are present, routing based
on source and destination address is necessary on source and destination address is necessary
[I-D.troan-homenet-sadr]. Routing protocol requirements for source [I-D.troan-homenet-sadr]. Routing protocol requirements for source
and destination routing are described in section 3 of and destination routing are described in section 3 of
[I-D.baker-rtgwg-src-dst-routing-use-cases]. [I-D.baker-rtgwg-src-dst-routing-use-cases].
A GPLv2-licensed implementation of the HNCP protocol is currently A GPLv2-licensed implementation of the HNCP protocol is currently
skipping to change at page 3, line 51 skipping to change at page 3, line 42
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
3. Data model 3. Data model
The data model of the HNCP protocol is simple: Every participating The data model of the HNCP protocol is simple: Every participating
node has (and also knows for every other participating node): node has (and also knows for every other participating node):
A unique node identifier. It may be a public key, unique hardware A unique node identifier. It may be a public key, unique hardware
ID, or some other unique blob of binary data which HNCP can run a ID, or some other unique blob of binary data which HNCP can run a
hash upon to obtain a node identifier that is very likely unique hash upon to obtain a node identifier that is very likely unique
among the set of routers in the Homenet. among the set of routers in the homenet.
A set of Type-Length-Value (TLV) data it wants to share with other A set of Type-Length-Value (TLV) data it wants to share with other
routers. The set of TLVs have a well-defined order based on routers. The set of TLVs have a well-defined order based on
ascending binary content that is used to quickly identify changes ascending binary content that is used to quickly identify changes
in the set as they occur. in the set as they occur.
Latest update sequence number. A 32 bit number that is Latest update sequence number. A 32 bit number that is
incremented anytime TLV data changes are detected. incremented anytime TLV data changes are detected.
Relative time, in milliseconds, since last publishing of the Relative time, in milliseconds, since last publishing of the
current TLV data set. It is also 32 bit number on the wire. current TLV data set. It is also 32 bit number on the wire.
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.
4. Operation 4. Operation
HNCP is designed to run on UDP port IANA-UDP-PORT, using both link- HNCP is designed to run on UDP port IANA-UDP-PORT, using both link-
local scoped IPv6 unicast and link-local scoped IPv6 multicast local scoped IPv6 unicast and link-local scoped IPv6 multicast
messages to address IANA-MULTICAST-ADDRESS for transport. The messages to address IANA-MULTICAST-ADDRESS for transport. The
protocol consists of Trickle [RFC6206] driven multicast status protocol consists of Trickle [RFC6206] driven multicast status
messages to indicate changes in shared TLV data, and unicast state messages to indicate changes in shared TLV data, and unicast state
synchronization message exchanges when the Trickle state is found to synchronization message exchanges when the Trickle state is found to
be inconsistent. be inconsistent.
skipping to change at page 5, line 44 skipping to change at page 5, line 29
The NetState Message MAY contain Node State TLV(s) (Section 5.2.3). The NetState Message MAY contain Node State TLV(s) (Section 5.2.3).
If so, either all Node State TLVs are included (referred to as a If so, either all Node State TLVs are included (referred to as a
"long" NetState Message), or none are included (referred to as a "long" NetState Message), or none are included (referred to as a
"short" NetState Message). The NetState Message MUST NOT contain "short" NetState Message). The NetState Message MUST NOT contain
only a portion of Node State TLVs as this could cause problems with only a portion of Node State TLVs as this could cause problems with
the Protocol Message Processing (Section 4.3) algorithm. Finally, if the Protocol Message Processing (Section 4.3) algorithm. Finally, if
the long version of the NetState message would exceed the minimum the long version of the NetState message would exceed the minimum
IPv6 MTU when sent, the short version of the NetState message MUST be IPv6 MTU when sent, the short version of the NetState message MUST be
used instead. used instead.
If HNCP security is enabled, authentication TLVs (Section 5.5) MUST
be present.
4.2.2. Network State Request, (NetState-Req) 4.2.2. Network State Request, (NetState-Req)
This Message MUST be sent as a unicast message. This Message MUST be sent as a unicast message.
The following TLVs MUST be present at the start of the message: The following TLVs MUST be present at the start of the message:
Node Link TLV (Section 5.2.1). Node Link TLV (Section 5.2.1).
Request Network State TLV (Section 5.1.1). Request Network State TLV (Section 5.1.1).
If HNCP security is enabled, authentication TLVs (Section 5.5) MUST
be present.
4.2.3. Node Data Request (Node-Req) 4.2.3. Node Data Request (Node-Req)
This Message MUST be sent as a unicast message. This Message MUST be sent as a unicast message.
MUST be present: MUST be present:
Node Link TLV (Section 5.2.1). Node Link TLV (Section 5.2.1).
one or more Request Node Data TLVs (Section 5.1.2). one or more Request Node Data TLVs (Section 5.1.2).
If HNCP security is enabled, authentication TLVs (Section 5.5) MUST
be present.
4.2.4. Network and Node State Reply (NetNode-Reply) 4.2.4. Network and Node State Reply (NetNode-Reply)
This Message MUST be sent as a unicast message. This Message MUST be sent as a unicast message.
MUST be present: MUST be present:
Node Link TLV (Section 5.2.1). Node Link TLV (Section 5.2.1).
Network State TLV (Section 5.2.2) and Node State TLV Network State TLV (Section 5.2.2) and Node State TLV
(Section 5.2.3) for every known node by the sender, or (Section 5.2.3) for every known node by the sender, or
one or more combinations of Node State and Node Data TLVs one or more combinations of Node State and Node Data TLVs
(Section 5.2.4). (Section 5.2.4).
If HNCP security is enabled, authentication TLVs (Section 5.5) MUST
be present.
4.3. HNCP Protocol Message Processing 4.3. HNCP Protocol Message Processing
The majority of status updates among known nodes are handled via the The majority of status updates among known nodes are handled via the
Trickle-driven updates (Section 4.1). This section describes Trickle-driven updates (Section 4.1). This section describes
processing of messages as received, along with associated actions or processing of messages as received, along with associated actions or
responses. responses.
HNCP is designed to operate between directly connected neighbors on a HNCP is designed to operate between directly connected neighbors on a
shared link using link-local IPv6 addresses. If the source address shared link using link-local IPv6 addresses. If the source address
of a received HNCP packet is not an IPv6 link-local unicast address, of a received HNCP packet is not an IPv6 link-local unicast address,
skipping to change at page 8, line 5 skipping to change at page 7, line 30
If a message containing Node State TLVs (Section 5.2.3) is received If a message containing Node State TLVs (Section 5.2.3) is received
via unicast or multicast with the node's own node identifier and a via unicast or multicast with the node's own node identifier and a
higher update number than current local value, or the same update higher update number than current local value, or the same update
number and different hash, there is an error somewhere. A number and different hash, there is an error somewhere. A
recommended default way to handle this is to attempt to assert local recommended default way to handle this is to attempt to assert local
state by increasing the local update number to a value higher than state by increasing the local update number to a value higher than
that received and republish node data using the same node identifier. 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 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 identifier is not globally unique, there may be more than one router
with the same node identifier on the network. If HNCP security is with the same node identifier on the network. If there is no global
not enabled, a new node identifier SHOULD be generated and node data guarantee of unique node identifier, a new node identifier SHOULD be
republished accordingly. If HNCP security is enabled, this is event generated and node data republished accordingly.
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 In all cases, if node data for any node changes, all Trickle
instances MUST be considered inconsistent (I=Imin + timer reset). instances MUST be considered inconsistent (I=Imin + timer reset).
4.4. Adding and Removing Neighbors 4.4. Adding and Removing Neighbors
Whenever multicast message or unicast reply is received on a link Whenever multicast message or unicast reply is received on a link
from another node, the node should be added as Neighbor TLV from another node, the node should be added as Neighbor TLV
(Section 5.2.6) for current node. If nothing (for example - no (Section 5.2.5) for current node. If nothing (for example - no
router advertisements, no HNCP traffic) is received from that router advertisements, no HNCP traffic) is received from that
neighbor in Imax seconds and the neighbor is not in neighbor neighbor in Imax seconds and the neighbor is not in neighbor
discovery cache, and no layer 2 indication of presence is available, discovery cache, and no layer 2 indication of presence is available,
at least 3 attempts to ping it with request network state message at least 3 attempts to ping it with request network state message
(Section 4.2.2) SHOULD be sent with increasing timeouts (e.g. 1, 2, 4 (Section 4.2.2) SHOULD be sent with increasing timeouts (e.g. 1, 2, 4
seconds). If even after suitable period after the last message seconds). If even after suitable period after the last message
nothing is received, the Neighbor TLV MUST be removed so that there 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 are no dangling neighbors. As an alternative, if there is a layer 2
unreachability notification of some sort available for either whole unreachability notification of some sort available for either whole
link or for individual neighbor, it MAY be used to immediately link or for individual neighbor, it MAY be used to immediately
skipping to change at page 11, line 48 skipping to change at page 11, line 21
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| H(node identifier) | | H(node identifier) |
| | | |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Update Sequence Number | | Update Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Nested TLVs containing node information | | Nested TLVs containing node information |
The Node Public Key TLV (Section 5.2.5) SHOULD be always included if 5.2.5. Neighbor TLV (within Node Data TLV)
signatures are ever used.
If signatures are in use, the Node Data TLV SHOULD also contain the
originator's own Signature TLV (Section 5.5.2).
5.2.5. Node Public Key TLV (within Node 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: 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) in the received data
for the node equals H(public key), and that the Signature TLVs are
signed by appropriate public keys.
5.2.6. Neighbor TLV (within Node Data TLV)
0 1 2 3 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 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 | | Type: NEIGHBOR (8) | Length: 28 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| H(neighbor node identifier) | | H(neighbor node identifier) |
| | | |
| | | |
skipping to change at page 13, line 40 skipping to change at page 12, line 40
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version | | Version |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| User-agent | | User-agent |
This TLV indicates which version of HNCP TLV binary structures is in This TLV indicates which version of HNCP TLV binary structures is in
use by this particular node. All TLVs within node data from nodes use by this particular node. All TLVs within node data from nodes
that do not publish version TLV, or with different Version value than that do not publish version TLV, or with different Version value than
locally supported one MUST be ignored (but forwarded). The user- locally supported one MUST be ignored (but forwarded). The user-
agent is an optional human-readable UTF-8 string that can describe agent is an optional human-readable UTF-8 string that can describe
e.g. current hnetd version. This draft describes Version=1 TLVs. e.g. current HNCP implementation version. This draft describes
Version=1 TLVs.
5.5. Authentication TLVs
5.5.1. Certificate-related TLVs
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.
5.5.2. Signature TLV
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)..
Given the ordering of TLVs, this TLV should be last one processed
within current scope.
6. Border Discovery and Prefix Assignment 6. Border Discovery and Prefix Assignment
Using Default Border Definition [I-D.kline-homenet-default-perimeter] This section defines border discovery algorithm derived from the edge
as a basis, this section defines border discovery algorithm specifics router interactions described in the Basic Requirements for IPv6
derived from the edge router interactions described in the Basic Customer Edge Routers [RFC7084]. The algorithm is designed to work
Requirements for IPv6 Customer Edge Routers [RFC7084]. The algorithm for both IPv4 and IPv6 (single or dual-stack).
is designed to work for both IPv4 and IPv6 (single or dual-stack).
In order to avoid conflicts between border discovery and homenet In order to avoid conflicts between border discovery and homenet
routers running DHCP [RFC2131] or DHCPv6-PD [RFC3633] servers each routers running DHCP [RFC2131] or DHCPv6-PD [RFC3633] servers each
router MUST implement the following mechanism based on The User Class router MUST implement the following mechanism based on The User Class
Option for DHCP [RFC3004] or its DHCPv6 counterpart [RFC3315] Option for DHCP [RFC3004] or its DHCPv6 counterpart [RFC3315]
respectively into its DHCP and DHCPv6-logic: respectively into its DHCP and DHCPv6-logic:
A homenet router running a DHCP-client on a homenet-interface MUST A homenet router running a DHCP-client on a homenet-interface MUST
include a DHCP User-Class consisting of the ASCII-String include a DHCP User-Class consisting of the ASCII-String
"HOMENET". "HOMENET".
skipping to change at page 15, line 5 skipping to change at page 13, line 30
2. Any of the following conditions indicate an interface MUST be 2. Any of the following conditions indicate an interface MUST be
considered external: considered external:
1. A delegated prefix could be acquired by running a 1. A delegated prefix could be acquired by running a
DHCPv6-client on the interface. DHCPv6-client on the interface.
2. An IPv4-address could be acquired by running a DHCP-client on 2. An IPv4-address could be acquired by running a DHCP-client on
the interface. the interface.
3. HNCP security is enabled and there are routers on the
interface which could not be authenticated.
3. As default fallback, interface MUST be considered internal. 3. As default fallback, interface MUST be considered internal.
A router SHOULD allow setting a category of either auto-detected, A router MUST allow setting a category of either auto-detected,
internal or external for each interface which is suitable for both internal or external for each interface which is suitable for both
internal and external connections. In addition it MAY offer further internal and external connections. In addition the following
categories which modify the local router behavior, such as: specializations of the internal category are defined to modify the
local router behavior:
Guest category: This is a specialization of the internal category Leaf category: This declares an interface used by clients only. A
which declares an interface used for untrusted clients. The router SHOULD implement this category and MUST NOT send nor accept
router MUST NOT send or accept HNCP messages on these interfaces. HNCP messages on these interfaces.
Clients connected to these interfaces MUST NOT be able to reach
devices inside the home network by default and instead SHOULD only
be able to reach the internet.
Ad-hoc category: This is a specialization of the internal category Guest category: This declares an interface used by untrusted
which declares an interface to be in ad-hoc mode. This indicates clients only. In addition to the restrictions of the leaf
to HNCP applications such as prefix assignment that links on this category, clients connected to these interfaces MUST NOT be able
interface are potentially non-transitive. to reach devices inside the home network by default and instead
SHOULD only be able to reach the internet. This category SHOULD
be also supported.
Hybrid category: This is a specialization of the internal category Ad-hoc category: This declares an interface to be in ad-hoc mode.
in which the router still accepts external connections but does This indicates to HNCP applications such as prefix assignment that
not do border discovery. It is assumed that the link is under links on this interface are potentially non-transitive. This
control of a legacy, trustworthy non-HNCP router, still within the category MAY be implemented.
same home network. Detection of this category automatically is
out of scope for this document, and therefore it MAY be supported Hybrid category: This allows the router to still accepts external
only via manual configuration on a per-router basis. connections but does not do border discovery. It is assumed that
the link is under control of a legacy, trustworthy non-HNCP
router, still within the same home network. Detection of this
category automatically in addition to manual configuration is out
of scope for this document. This category MAY be implemented.
A homenet router SHOULD provide basic connectivity to legacy CERs A homenet router SHOULD provide basic connectivity to legacy CERs
[RFC7084] connected to internal interfaces in order to allow [RFC7084] connected to internal interfaces in order to allow
coexistence with existing devices. coexistence with existing devices.
Each router MUST continuously scan each active interface that does Each router MUST continuously scan each active interface that does
not have a fixed category in order to dynamically reclassify it if not have a fixed category in order to dynamically reclassify it if
necessary. The router therefore runs an appropriately configured necessary. The router therefore runs an appropriately configured
DHCP and DHCPv6-client as long as the interface is active including DHCP and DHCPv6-client as long as the interface is active including
states where it considers the interface to be internal. The router states where it considers the interface to be internal. The router
skipping to change at page 17, line 40 skipping to change at page 16, line 16
bits of the prefix padded with zeroes up to the next byte bits of the prefix padded with zeroes up to the next byte
boundary. boundary.
Nested TLVs might contain prefix-specific information like Nested TLVs might contain prefix-specific information like
DHCPv6-options. DHCPv6-options.
In order for routers to use the distributed information, prefixes and In order for routers to use the distributed information, prefixes and
addresses have to be assigned to the interior links of the homenet. addresses have to be assigned to the interior links of the homenet.
A router MUST therefore implement the algorithm defined in Prefix and A router MUST therefore implement the algorithm defined in Prefix and
Address Assignment in a Home Network Address Assignment in a Home Network
[I-D.pfister-homenet-prefix-assignment]. In order to announce the [I-D.ietf-homenet-prefix-assignment]. In order to announce the
assigned prefixes the following TLVs are defined. assigned prefixes the following TLVs are defined.
Each assigned prefix is given to an interior link and is encoded Each assigned prefix is given to an interior link and is encoded
using one TLVs. Assigned IPv4 prefixes are stored as mapped using one TLVs. Assigned IPv4 prefixes are stored as mapped
IPv4-addresses. The TLV is defined as follows: IPv4-addresses. The TLV is defined as follows:
0 1 2 3 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 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 | | Type: ASSIGNED-PREFIX (43) | Length: >= 9 |
skipping to change at page 20, line 16 skipping to change at page 18, line 29
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type: ROUTER-NAME (52) | Length: >= 4 | | Type: ROUTER-NAME (52) | Length: >= 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Name (not null-terminated - variable length) | | Name (not null-terminated - variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
8. Routing support 8. Routing support
8.1. Protocol Requirements 8.1. Protocol Requirements
In order to be advertised for use within the Homenet, a routing In order to be advertised for use within the homenet, a routing
protocol MUST: protocol MUST:
Comply with Requirements and Use Cases for Source/Destination Comply with Requirements and Use Cases for Source/Destination
Routing [I-D.baker-rtgwg-src-dst-routing-use-cases]. Routing [I-D.baker-rtgwg-src-dst-routing-use-cases].
Be configured with suitable defaults or have an auto-configuration Be configured with suitable defaults or have an auto-configuration
mechanism (e.g. [I-D.acee-ospf-ospfv3-autoconfig]) such that it mechanism (e.g. [I-D.acee-ospf-ospfv3-autoconfig]) such that it
will run in a Homenet without requiring specific configuration will run in a homenet without requiring specific configuration
from the Home user. from the home user.
A router MUST NOT announce that it supports a certain routing A router MUST NOT announce that it supports a certain routing
protocol if its implementation of the routing protocol does not meet protocol if its implementation of the routing protocol does not meet
these requirements, e.g. it does not implement extensions that are these requirements, e.g. it does not implement extensions that are
necessary for compliance. necessary for compliance.
8.2. Announcement 8.2. Announcement
Each router SHOULD announce all routing protocols that it is capable Each router SHOULD announce all routing protocols that it is capable
of supporting in the Homenet. It SHOULD assign a preference value of supporting in the homenet. It MUST announce at least one protocol
for each protocol that indicates its desire to use said protocol over or the fallback mechanism to be considered for protocol selection and
MAY omit announcing the fallback mechanism if it announces at least
one other routing protocol. 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 other protocols it supports and SHOULD make these values
configurable. configurable.
Each router includes one HNCP TLV of type ROUTING-PROTOCOL for every Each router includes one HNCP TLV of type ROUTING-PROTOCOL for every
such routing protocol. This TLV is defined as follows: such routing protocol. This TLV is defined as follows:
0 1 2 3 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 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 | | Type: ROUTING-PROTOCOL (60) | Length: 6 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Protocol ID | Preference | | Protocol ID | Preference |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Protocol ID is one of: Protocol ID is one of:
0 = reserved 0 = Fallback (explicit announcement)
1 = Babel (dual-stack) 1 = Babel (dual-stack)
2 = OSPFv3 (dual-stack) 2 = OSPFv3 (dual-stack)
3 = IS-IS (dual-stack) 3 = IS-IS (dual-stack)
4 = RIP (dual-stack) 4 = RIP (dual-stack)
Preference is a value from 0 to 255. If a router is neutral about Preference is a value from 0 to 255. If a router is neutral about
a routing protocol it SHOULD use the value 128, otherwise a lower a routing protocol it SHOULD use the value 128, otherwise a lower
value indicating lower preference or a higher value indicating value indicating lower preference or a higher value indicating
higher preference respectively. higher preference respectively.
8.3. Protocol Selection 8.3. Protocol Selection
When HNCP detects that a router has joined or left the Homenet it When HNCP detects that a device has joined or left the homenet it
MUST examine all advertised routing protocols and preference values MUST examine all advertised routing protocols and preference values
from all routers in the Homenet in order to find the one routing from all devices announcing at least one ROUTING-PROTOCOL-TLV in
protocol which: order to find the one routing protocol which:
1. Is understood by all routers in the homenet 1. Is understood by all routers in the homenet
2. Has the highest preference value among all routers (calculated as 2. Has the highest preference value among all routers (calculated as
sum of preference values) sum of preference values)
3. Has the highest protocol ID among those with the highest 3. Has the highest protocol ID among those with the highest
preference preference
If the router protocol selection results in the need to change from If the router protocol selection results in the need to change from
one routing protocol to another on the homenet, the router MUST stop one routing protocol to another on the homenet, the router MUST stop
the previously running protocol, remove associated routes, and start the previously running protocol, remove associated routes, and start
the new protocol in a graceful manner. If there is no common routing the new protocol in a graceful manner. If there is no common routing
protocol available among all Homenet routers, routers MUST utilize protocol available among all homenet routers, routers MUST utilize
the Fallback Mechanism (Section 8.4). the Fallback Mechanism (Section 8.4).
8.4. Fallback Mechanism 8.4. Fallback Mechanism
In cases where there is no commonly supported routing protocol In cases where there is no commonly supported routing protocol
available the following fallback algorithm is run to setup routing available the following fallback algorithm is run to setup routing
and preserve interoperability among the homenet. While not intended and preserve interoperability among the homenet. While not intended
to replace a routing protocol, this mechanism provides a valid - but to replace a routing protocol, this mechanism provides a valid - but
not necessarily optimal - routing topology. This algorithm uses the not necessarily optimal - routing topology. This algorithm uses the
node and neighbor state already synchronized by HNCP, and therefore node and neighbor state already synchronized by HNCP, and therefore
skipping to change at page 22, line 38 skipping to change at page 21, line 7
5. For the first router R visited in the traversal announcing an 5. For the first router R visited in the traversal announcing an
IPv4-uplink: Create a default IPv4-route via the next-hop for R IPv4-uplink: Create a default IPv4-route via the next-hop for R
acquired in #2. acquired in #2.
6. For each assigned IPv4-prefix A of a router R: Create an 6. For each assigned IPv4-prefix A of a router R: Create an
IPv4-route to A via the next-hop for R acquired in #2. IPv4-route to A via the next-hop for R acquired in #2.
9. Security Considerations 9. Security Considerations
General security issues for Home Networks are discussed at length in General security issues for home networks are discussed at length in
[I-D.ietf-homenet-arch]. The protocols used to setup IP in home [RFC7368]. The protocols used to set up IP in home networks today
networks today have very little security enabled within the control have rarely security enabled within the control protocol itself. For
protocol itself. For example, DHCP has defined [RFC3118] to example, DHCP has defined [RFC3118] to authenticate DHCP messages,
authenticate DHCP messages, but this is very rarely implemented in but this is very rarely implemented in large or small networks.
large or small networks. Further, while PPP can provide secure Further, while PPP can provide secure authentication of both sides of
authentication of both sides of a point to point link, it is most a point to point link, it is most often deployed with one-way
often deployed with one-way authentication of the subscriber to the authentication of the subscriber to the ISP, not the ISP to the
ISP, not the ISP to the subscriber. HNCP aims to make security as subscriber.
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 authentication. 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 HNCP itself sends messages as clear text which is as secure, or
actual node data and the protocol messages themselves, it is also insecure, as the security of the link it runs on. As HNCP messages
possible to provide signatures just for protocol messages. While are sent over IPv6 UDP, IPsec may be used for confidentiality or
this means it is no longer possible to verify the original source of message authentication. This requires manually keyed IPsec per-port
the node data itself, as long as the set of routers is trusted (i.e., granularity for port IANA-UDP-PORT UDP traffic, and a pre-shared key
no router in the set has itself been hacked to provide malicious node has to be utilized in this case given IKE cannot be used with
data) then one can assume the node data is trusted because the router multicast traffic. This seems acceptable, though, as most routing
is trusted and the data arrived in a protected protocol message. protocols also operate based on pre-shared keys, and the homenet
architecture draft explicitly allows their use for securing
them[RFC7368]. Other traffic security mechanisms are out of scope
for this specification. There is ongoing work
[I-D.barth-homenet-hncp-security-trust] to define a mechanism that
can be used with HNCP and be more user-friendly than pre-shared keys.
10. IANA Considerations 10. IANA Considerations
IANA should set up a registry (policy TBD) for HNCP TLV types, with IANA should set up a registry (policy TBD) for HNCP TLV types, with
following initial contents: following initial contents:
0: Reserved (should not happen on wire) 0: Reserved (should not happen on wire)
1: Node link 1: Node link
skipping to change at page 24, line 4 skipping to change at page 21, line 43
IANA should set up a registry (policy TBD) for HNCP TLV types, with IANA should set up a registry (policy TBD) for HNCP TLV types, with
following initial contents: following initial contents:
0: Reserved (should not happen on wire) 0: Reserved (should not happen on wire)
1: Node link 1: Node link
2: Request network state 2: Request network state
3: Request node data 3: Request node data
4: Network state 4: Network state
5: Node state 5: Node state
6: Node data 6: Node data
7: Node public key 7: (unused - was node public key, but never implemented)
8: Neighbor 8: Neighbor
9: Custom 9: Custom
10: Version 10: Version
41: External connection 41: External connection
42: Delegated prefix 42: Delegated prefix
43: Assigned prefix 43: Assigned prefix
skipping to change at page 25, line 5 skipping to change at page 22, line 43
11. References 11. References
11.1. Normative references 11.1. Normative references
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC6206] Levis, P., Clausen, T., Hui, J., Gnawali, O., and J. Ko, [RFC6206] Levis, P., Clausen, T., Hui, J., Gnawali, O., and J. Ko,
"The Trickle Algorithm", RFC 6206, March 2011. "The Trickle Algorithm", RFC 6206, March 2011.
[I-D.pfister-homenet-prefix-assignment] [I-D.ietf-homenet-prefix-assignment]
Pfister, P., Paterson, B., and J. Arkko, "Prefix and Pfister, P., Paterson, B., and J. Arkko, "Prefix and
Address Assignment in a Home Network", draft-pfister- Address Assignment in a Home Network", draft-ietf-homenet-
homenet-prefix-assignment-01 (work in progress), May 2014. prefix-assignment-01 (work in progress), October 2014.
[I-D.stenberg-homenet-dnssd-hybrid-proxy-zeroconf] [I-D.stenberg-homenet-dnssd-hybrid-proxy-zeroconf]
Stenberg, M., "Auto-Configuration of a Network of Hybrid Stenberg, M., "Auto-Configuration of a Network of Hybrid
Unicast/Multicast DNS-Based Service Discovery Proxy Unicast/Multicast DNS-Based Service Discovery Proxy
Nodes", draft-stenberg-homenet-dnssd-hybrid-proxy- Nodes", draft-stenberg-homenet-dnssd-hybrid-proxy-
zeroconf-01 (work in progress), June 2014. zeroconf-01 (work in progress), June 2014.
11.2. Informative references 11.2. Informative references
[RFC7084] Singh, H., Beebee, W., Donley, C., and B. Stark, "Basic [RFC7084] Singh, H., Beebee, W., Donley, C., and B. Stark, "Basic
skipping to change at page 25, line 47 skipping to change at page 23, line 42
Host Configuration Protocol (DHCP) version 6", RFC 3633, Host Configuration Protocol (DHCP) version 6", RFC 3633,
December 2003. December 2003.
[RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and
E. Lear, "Address Allocation for Private Internets", BCP E. Lear, "Address Allocation for Private Internets", BCP
5, RFC 1918, February 1996. 5, RFC 1918, February 1996.
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 4291, February 2006. Architecture", RFC 4291, February 2006.
[I-D.ietf-homenet-arch] [RFC7368] Chown, T., Arkko, J., Brandt, A., Troan, O., and J. Weil,
Chown, T., Arkko, J., Brandt, A., Troan, O., and J. Weil, "IPv6 Home Networking Architecture Principles", RFC 7368,
"IPv6 Home Networking Architecture Principles", draft- October 2014.
ietf-homenet-arch-13 (work in progress), March 2014.
[I-D.troan-homenet-sadr] [I-D.troan-homenet-sadr]
Troan, O. and L. Colitti, "IPv6 Multihoming with Source Troan, O. and L. Colitti, "IPv6 Multihoming with Source
Address Dependent Routing (SADR)", draft-troan-homenet- Address Dependent Routing (SADR)", draft-troan-homenet-
sadr-01 (work in progress), September 2013. sadr-01 (work in progress), September 2013.
[I-D.behringer-homenet-trust-bootstrap]
Behringer, M., Pritikin, M., and S. Bjarnason,
"Bootstrapping Trust on a Homenet", draft-behringer-
homenet-trust-bootstrap-02 (work in progress), February
2014.
[I-D.baker-rtgwg-src-dst-routing-use-cases] [I-D.baker-rtgwg-src-dst-routing-use-cases]
Baker, F., "Requirements and Use Cases for Source/ Baker, F., "Requirements and Use Cases for Source/
Destination Routing", draft-baker-rtgwg-src-dst-routing- Destination Routing", draft-baker-rtgwg-src-dst-routing-
use-cases-00 (work in progress), August 2013. use-cases-01 (work in progress), October 2014.
[I-D.kline-homenet-default-perimeter]
Kline, E., "Default Border Definition", draft-kline-
homenet-default-perimeter-00 (work in progress), March
2013.
[I-D.acee-ospf-ospfv3-autoconfig] [I-D.acee-ospf-ospfv3-autoconfig]
Lindem, A. and J. Arkko, "OSPFv3 Auto-Configuration", Lindem, A. and J. Arkko, "OSPFv3 Auto-Configuration",
draft-acee-ospf-ospfv3-autoconfig-03 (work in progress), draft-acee-ospf-ospfv3-autoconfig-03 (work in progress),
July 2012. July 2012.
[I-D.barth-homenet-hncp-security-trust]
Barth, S., "HNCP - Security and Trust Management", draft-
barth-homenet-hncp-security-trust-01 (work in progress),
October 2014.
11.3. URIs 11.3. URIs
[2] http://www.openwrt.org [2] http://www.openwrt.org
[3] http://www.homewrt.org/doku.php?id=run-conf [3] http://www.homewrt.org/doku.php?id=run-conf
Appendix A. Some Outstanding Issues Appendix A. Some Outstanding Issues
Should we use MD5 hashes, or EUI-64 node identifier to identify Should we use MD5 hashes, or EUI-64 node identifier to identify
nodes? nodes?
skipping to change at page 27, line 5 skipping to change at page 24, line 41
Is there a case for non-link-local unicast? Currently explicitly Is there a case for non-link-local unicast? Currently explicitly
stating this is link-local only protocol. stating this is link-local only protocol.
Consider if using Trickle with k=1 really pays off, as we need to do Consider if using Trickle with k=1 really pays off, as we need to do
reachability checks if layer 2 does not provide them periodically in reachability checks if layer 2 does not provide them periodically in
any case. Using Trickle with k=inf would remove the need for unicast any case. Using Trickle with k=inf would remove the need for unicast
reachability checks, but at cost of extra multicast traffic. On the reachability checks, but at cost of extra multicast traffic. On the
other hand, N*(N-1)/2 unicast reachability checks when lot of routers other hand, N*(N-1)/2 unicast reachability checks when lot of routers
share a link is not appealing either. 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.
Valid and preferred are now 32 bit millisecond and you cannot even Valid and preferred are now 32 bit millisecond and you cannot even
represent a month in them; is this enough? Or should we switch to 32 represent a month in them; is this enough? Or should we switch to 32
bit seconds (or 64 bit milliseconds)? bit seconds (or 64 bit milliseconds)?
Appendix B. Some Obvious Questions and Answers Appendix B. Some Obvious Questions and Answers
Q: Why not use TCP? Q: Why not use TCP?
A: It does not address the node discovery problem. It also leads to A: It does not address the node discovery problem. It also leads to
N*(N-1)/2 connections when N nodes share a link, which is awkward. N*(N-1)/2 connections when N nodes share a link, which is awkward.
skipping to change at page 27, line 21 skipping to change at page 25, line 4
bit seconds (or 64 bit milliseconds)? bit seconds (or 64 bit milliseconds)?
Appendix B. Some Obvious Questions and Answers Appendix B. Some Obvious Questions and Answers
Q: Why not use TCP? Q: Why not use TCP?
A: It does not address the node discovery problem. It also leads to A: It does not address the node discovery problem. It also leads to
N*(N-1)/2 connections when N nodes share a link, which is awkward. N*(N-1)/2 connections when N nodes share a link, which is awkward.
Q: Why not multicast-only? Q: Why not multicast-only?
A: It would require defining application level fragmentation scheme. A: It would require defining application level fragmentation scheme.
Hopefully the data amounts used will stay small so we just trust Hopefully the data amounts used will stay small so we just trust
unicast UDP to handle 'big enough' packets to contain single node's unicast UDP to handle 'big enough' packets to contain single node's
TLV data. On some link layers unicast is also much more reliable TLV data. On some link layers unicast is also much more reliable
than multicast, especially for large packets. than multicast, especially for large packets. Also on wireless,
multicast is much more power expensive than unicast.
Q: Why so long IDs? Why real hash even in insecure mode? Q: Why so long IDs?
A: Scalability of protocol is not really affected by using real A: Scalability of protocol is not really affected by using real
(=cryptographic) hash function. (=cryptographic) hash function.
Q: Why trust IPv6 fragmentation in unicast case? Why not do L7 Q: Why trust IPv6 fragmentation in unicast case? Why not do L7
fragmentation? fragmentation?
A: Because it will be there for a while at least. And while PMTU et 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 al may be problems on open internet, in a home network environment
UDP fragmentation should NOT be broken in the foreseeable future. UDP fragmentation should NOT be broken in the foreseeable future.
skipping to change at page 28, line 7 skipping to change at page 25, line 38
Q: Why not doing (performance thing X, Y or Z)? Q: Why not doing (performance thing X, Y or Z)?
A: This is designed mostly to be minimal (only timers Trickle ones; A: This is designed mostly to be minimal (only timers Trickle ones;
everything triggered by Trickle-driven messages or local state everything triggered by Trickle-driven messages or local state
changes). However, feel free to suggest better (even more minimal) changes). However, feel free to suggest better (even more minimal)
design which works. design which works.
Appendix C. Changelog Appendix C. Changelog
draft-ietf-homenet-hncp-02: Removed any built-in security. Relying
on IPsec. Reorganized interface categories, added requirements
languages, made manual border configuration a MUST-support.
Redesigned routing protocol election to consider non-router devices.
draft-ietf-homenet-hncp-01: Added (MAY) guest, ad-hoc, hybrid draft-ietf-homenet-hncp-01: Added (MAY) guest, ad-hoc, hybrid
categories for interfaces. Removed old hnetv2 reference, and now categories for interfaces. Removed old hnetv2 reference, and now
pointing just to OpenWrt + github. Fixed synchronization algorithm pointing just to OpenWrt + github. Fixed synchronization algorithm
to spread also same update number, but different data hash case. to spread also same update number, but different data hash case.
Made purge step require bidirectional connectivity between nodes when Made purge step require bidirectional connectivity between nodes when
traversing the graph. Edited few other things to be hopefully traversing the graph. Edited few other things to be hopefully
slightly clearer without changing their meaning. slightly clearer without changing their meaning.
draft-ietf-homenet-hncp-00: Added version TLV to allow for TLV draft-ietf-homenet-hncp-00: Added version TLV to allow for TLV
content changes pre-RFC without changing IDs. Added link id to content changes pre-RFC without changing IDs. Added link id to
skipping to change at page 28, line 30 skipping to change at page 26, line 20
As usual, this draft is available at https://github.com/fingon/ietf- As usual, this draft is available at https://github.com/fingon/ietf-
drafts/ in source format (with nice Makefile too). Feel free to send 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! comments and/or pull requests if and when you have changes to it!
Appendix E. Acknowledgements Appendix E. Acknowledgements
Thanks to Ole Troan, Pierre Pfister, Mark Baugher, Mark Townsley and Thanks to Ole Troan, Pierre Pfister, Mark Baugher, Mark Townsley and
Juliusz Chroboczek for their contributions to the draft. Juliusz Chroboczek for their contributions to the draft.
Thanks to Eric Kline for the original border discovery work.
Authors' Addresses Authors' Addresses
Markus Stenberg Markus Stenberg
Helsinki 00930 Helsinki 00930
Finland Finland
Email: markus.stenberg@iki.fi Email: markus.stenberg@iki.fi
Steven Barth Steven Barth
 End of changes. 54 change blocks. 
231 lines changed or deleted 137 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/