draft-ietf-homenet-hncp-00.txt   draft-ietf-homenet-hncp-01.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: October 17, 2014 Expires: December 27, 2014
April 15, 2014 June 25, 2014
Home Networking Control Protocol Home Networking Control Protocol
draft-ietf-homenet-hncp-00 draft-ietf-homenet-hncp-01
Abstract Abstract
This document describes the HomeNet Control Protocol (HNCP), a This document describes the Home Networking Control Protocol (HNCP),
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 October 17, 2014. This Internet-Draft will expire on December 27, 2014.
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 30 skipping to change at page 2, line 30
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) . . . . . 9
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) . . . 10
5.2.1. Node Link TLV . . . . . . . . . . . . . . . . . . . . 10 5.2.1. Node Link TLV . . . . . . . . . . . . . . . . . . . . 10
5.2.2. Network State TLV . . . . . . . . . . . . . . . . . . 10 5.2.2. Network State TLV . . . . . . . . . . . . . . . . . . 10
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. Node Public Key TLV (within
Node Data TLV) . . . . . . . . . . . . . . . . . . . 11 Node Data TLV) . . . . . . . . . . . . . . . . . . . 12
5.2.6. Neighbor TLV (within Node Data TLV) . . . . . . . . . 12 5.2.6. Neighbor TLV (within Node Data TLV) . . . . . . . . . 12
5.3. Custom TLV (within/without Node Data TLV) . . . . . . . . 12 5.3. Custom TLV (within/without Node Data TLV) . . . . . . . . 12
5.4. Version TLV (within Node Data TLV) . . . . . . . . . . . 13 5.4. Version TLV (within Node Data TLV) . . . . . . . . . . . 13
5.5. Authentication TLVs . . . . . . . . . . . . . . . . . . . 13 5.5. Authentication TLVs . . . . . . . . . . . . . . . . . . . 13
5.5.1. Certificate-related TLVs . . . . . . . . . . . . . . 13 5.5.1. Certificate-related TLVs . . . . . . . . . . . . . . 13
5.5.2. Signature TLV . . . . . . . . . . . . . . . . . . . . 13 5.5.2. Signature TLV . . . . . . . . . . . . . . . . . . . . 14
6. Border Discovery and Prefix Assignment . . . . . . . . . . . 14 6. Border Discovery and Prefix Assignment . . . . . . . . . . . 14
7. DNS-based Service Discovery . . . . . . . . . . . . . . . . . 18 7. DNS-based Service Discovery . . . . . . . . . . . . . . . . . 19
7.1. DNS Delegated Zone TLV . . . . . . . . . . . . . . . . . 18 7.1. DNS Delegated Zone TLV . . . . . . . . . . . . . . . . . 19
7.2. Domain Name TLV . . . . . . . . . . . . . . . . . . . . . 18 7.2. Domain Name TLV . . . . . . . . . . . . . . . . . . . . . 19
7.3. Router Name TLV . . . . . . . . . . . . . . . . . . . . . 18 7.3. Router Name TLV . . . . . . . . . . . . . . . . . . . . . 19
8. Routing support . . . . . . . . . . . . . . . . . . . . . . . 19 8. Routing support . . . . . . . . . . . . . . . . . . . . . . . 20
8.1. Protocol Requirements . . . . . . . . . . . . . . . . . . 19 8.1. Protocol Requirements . . . . . . . . . . . . . . . . . . 20
8.2. Announcement . . . . . . . . . . . . . . . . . . . . . . 19 8.2. Announcement . . . . . . . . . . . . . . . . . . . . . . 20
8.3. Protocol Selection . . . . . . . . . . . . . . . . . . . 20 8.3. Protocol Selection . . . . . . . . . . . . . . . . . . . 21
8.4. Fallback Mechanism . . . . . . . . . . . . . . . . . . . 20 8.4. Fallback Mechanism . . . . . . . . . . . . . . . . . . . 21
9. Security Considerations . . . . . . . . . . . . . . . . . . . 21 9. Security Considerations . . . . . . . . . . . . . . . . . . . 22
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 23 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 24
11.1. Normative references . . . . . . . . . . . . . . . . . . 23 11.1. Normative references . . . . . . . . . . . . . . . . . . 24
11.2. Informative references . . . . . . . . . . . . . . . . . 24 11.2. Informative references . . . . . . . . . . . . . . . . . 25
Appendix A. Some Outstanding Issues . . . . . . . . . . . . . . 25 11.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 26
Appendix B. Some Obvious Questions and Answers . . . . . . . . . 26
Appendix C. Changelog . . . . . . . . . . . . . . . . . . . . . 27 Appendix A. Some Outstanding Issues . . . . . . . . . . . . . . 26
Appendix D. Draft source . . . . . . . . . . . . . . . . . . . . 27 Appendix B. Some Obvious Questions and Answers . . . . . . . . . 27
Appendix E. Acknowledgements . . . . . . . . . . . . . . . . . . 27 Appendix C. Changelog . . . . . . . . . . . . . . . . . . . . . 28
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27 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, integration with trusted bootstrapping
[I-D.behringer-homenet-trust-bootstrap] and default perimeter [I-D.behringer-homenet-trust-bootstrap] and default perimeter
detection [I-D.kline-homenet-default-perimeter], automatic IP prefix detection [I-D.kline-homenet-default-perimeter], automatic IP prefix
distribution [I-D.pfister-homenet-prefix-assignment], and service distribution [I-D.pfister-homenet-prefix-assignment], and service
discovery across multiple links within the homenet as defined in discovery across multiple links within the homenet as defined in
skipping to change at page 3, line 30 skipping to change at page 3, line 32
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
under development at https://github.com/sbyx/hnetd/ [1]. Comments under development at https://github.com/sbyx/hnetd/ and the binaries
are available in the routing feed of OpenWrt [2] trunk release. Some
information how to get started with it is available at [3]. Comments
and/or pull requests are welcome. 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 [2].
2. Requirements language 2. Requirements language
In this document, the key words "MAY", "MUST, "MUST NOT", "OPTIONAL", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"RECOMMENDED", "SHOULD", and "SHOULD NOT", are to be interpreted as "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
described in [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 identifer 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 four octet 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. 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 If HNCP security is enabled, each node will have a public/private key
pair defined. The private key is used to create signatures for pair defined. The private key is used to create signatures for
messages and node state updates and never sent across the network by messages and node state updates and never sent across the network by
HNCP. The public key is used to verify signatures of messages and HNCP. The public key is used to verify signatures of messages and
node state updates. 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-
skipping to change at page 4, line 42 skipping to change at page 4, line 42
4.1. Trickle-Driven Status Updates 4.1. Trickle-Driven Status Updates
Each node MUST send link-local multicast NetState Messages Each node MUST send link-local multicast NetState Messages
(Section 4.2.1) each time the Trickle algorithm [RFC6206] indicates (Section 4.2.1) each time the Trickle algorithm [RFC6206] indicates
they should on each link the protocol is active on. When the locally 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 stored network state hash changes (either by a local node event that
affects the TLV data, or upon receipt of more recent data from affects the TLV data, or upon receipt of more recent data from
another node), all Trickle instances MUST be reset. Trickle state another node), all Trickle instances MUST be reset. Trickle state
MUST be maintained separately for each link. MUST be maintained separately for each link.
Trickle algorithm has 3 parameters; Imin, Imax and k. Imin and Imax Trickle algorithm has 3 parameters; Imin, Imax and k. Imin and Imax
represent minimum and maximum values for I, which is the time represent minimum and maximum values for I, which is the time
interval during which at least k Trickle updates must be seen on a interval during which at least k Trickle updates must be seen on a
link to prevent local state transmission. Bounds for recommended link to prevent local state transmission. Bounds for recommended
Trickle values are described below. Trickle values are described below.
k=1 SHOULD be used, as given the timer reset on data updates, k=1 SHOULD be used, as given the timer reset on data updates,
retransmissions should handle packet loss. retransmissions should handle packet loss.
Imax MUST be at least one minute. Imax MUST be at least one minute.
skipping to change at page 5, line 36 skipping to change at page 5, line 36
This Message SHOULD be sent as a multicast message. This Message SHOULD be sent as a multicast 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).
Network State TLV (Section 5.2.2). Network State TLV (Section 5.2.2).
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 (refered 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 If HNCP security is enabled, authentication TLVs (Section 5.5) MUST
be present. be present.
skipping to change at page 6, line 45 skipping to change at page 6, line 45
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 If HNCP security is enabled, authentication TLVs (Section 5.5) MUST
be present. 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,
the packet SHOULD be dropped. Similarly, if the destination address the packet SHOULD be dropped. Similarly, if the destination address
is not IPv6 link-local unicast or IPv6 link-local multicast address, is not IPv6 link-local unicast or IPv6 link-local multicast address,
packet SHOULD be dropped. packet SHOULD be dropped.
skipping to change at page 7, line 18 skipping to change at page 7, line 18
NetState Message (Section 4.2.1): If the network state hash within NetState Message (Section 4.2.1): If the network state hash within
the message matches the hash of the locally stored network state, the message matches the hash of the locally stored network state,
consider Trickle state as consistent with no further processing consider Trickle state as consistent with no further processing
required. If the hashes do not match, consider Trickle state as required. If the hashes do not match, consider Trickle state as
inconsistent. In this case, if the message is "short" (contains inconsistent. In this case, if the message is "short" (contains
zero Node State TLVs), reply with a NetState-Req Message zero Node State TLVs), reply with a NetState-Req Message
(Section 4.2.2). If the message was in long format (contained all (Section 4.2.2). If the message was in long format (contained all
Node State TLVs), reply with NodeState-Req (Section 4.2.3) for any Node State TLVs), reply with NodeState-Req (Section 4.2.3) for any
nodes for which local information is outdated (local update number nodes for which local information is outdated (local update number
is lower than that within the message) or missing. Note that if is lower than that within the message), potentially incorrect
local information is more recent than that of the neighbor, there (local update number is same and the hash of node data TLV
is no need to send a message. differs) or missing. Note that if local information is more
recent than that of the neighbor, there is no need to send a
message.
NetState-Req (Section 4.2.2): Provide requested data in a NetNode- NetState-Req (Section 4.2.2): Provide requested data in a NetNode-
Reply Message containing Network State TLV and all Node State Reply Message containing Network State TLV and all Node State
TLVs. TLVs.
NodeState-Req (Section 4.2.3): Provide requested data in a NodeState-Req (Section 4.2.3): Provide requested data in a
NetNode-Reply containing Node State and Node Data TLVs. NetNode-Reply containing Node State and Node Data TLVs.
State-Reply (Section 4.2.4): If the message contains Node State State-Reply (Section 4.2.4): If the message contains Node State
TLVs that are more recent than local state (higher update number TLVs that are more recent than local state (higher update number,
or we lack the node data altogether), if the message also contains different node data TLV hash, or we lack the node data
corresponding Node Data TLVs, update local state and reset altogether), and if the message also contains corresponding Node
Trickle. If the message is lacking Node Data TLVs for some Node Data TLVs, update local state and reset Trickle. If the message
State TLVs which are more recent than local state, reply with a is lacking Node Data TLVs for some Node State TLVs which are more
NodeState-Req (Section 4.2.3) for the corresponding nodes. recent than local state, reply with a NodeState-Req
(Section 4.2.3) for the corresponding nodes.
Each node is responsible for publishing a valid set of data TLVs. 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 When there is a change in a node's set of data TLVs, the update
number MUST be incremented accordingly. number MUST be incremented accordingly.
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
skipping to change at page 8, line 18 skipping to change at page 8, line 21
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.6) 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 L2 indication of presence is available), at discovery cache, and no layer 2 indication of presence is available,
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
trigger removal of corresponding Neighbor TLV(s). trigger removal of corresponding Neighbor TLV(s).
4.5. Purging Unreachable Nodes 4.5. Purging Unreachable Nodes
Nodes should be purged when unreachable. When node data has changed, When node data has changed, the neighbor graph SHOULD be traversed
the neighbor graph SHOULD be traversed for each node following the for each node following the bidirectional neighbor relationships.
Neighbor TLVs, purging nodes that were found entirely unreachable These are identified by looking for neighbor TLVs on both nodes, that
(not traversed). have the remote node's identifier hash as h(neighbor node
identifier), and local and neighbor link identifiers swapped. After
the traverse, unreachable nodes SHOULD be purged after some grace
period. During the grace period, the unreachable nodes MUST NOT be
used for calculation of network state hash, or even be provided to
any applications that need to use the whole TLV graph.
5. Type-Length-Value objects 5. Type-Length-Value objects
Every TLV is encoded as 2 octet type, followed by 2 octet length (of 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 the whole TLV, including header; 4 means no value), and then the
then the value itself (if any). The actual length of TLV MUST be value itself (if any). The actual length of TLV MUST be always
always divisible by 4; if the length of the value is not, zeroed divisible by 4; if the length of the value is not, zeroed padding
padding bytes MUST be inserted at the end of TLV. The padding bytes bytes MUST be inserted at the end of TLV. The padding bytes MUST NOT
MUST NOT be included in the length field. be included in the length field.
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 | Length | | Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value | | Value |
| (variable # of bytes) | | (variable # of bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 13, line 28 skipping to change at page 13, line 38
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type: VERSION (10) | Length: >= 8 | | Type: VERSION (10) | Length: >= 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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). under control locally supported one MUST be ignored (but forwarded). The user-
of the author of that specification. The user-agent is an optional agent is an optional human-readable UTF-8 string that can describe
human-readable UTF-8 string that can describe e.g. current hnetd e.g. current hnetd version. This draft describes Version=1 TLVs.
version. This draft describes Version=1 TLVs.
5.5. Authentication TLVs 5.5. Authentication TLVs
5.5.1. Certificate-related TLVs 5.5.1. Certificate-related TLVs
TBD; should be probably some sort of certificate ID to be used in a 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 lookup at most, as raw certificates will overflow easily IPv6 minimum
MTU. MTU.
5.5.2. Signature TLV 5.5.2. Signature TLV
skipping to change at page 14, line 30 skipping to change at page 14, line 39
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".
A homenet router running a DHCP-server on a homenet-interface MUST A homenet router running a DHCP-server on a homenet-interface MUST
ignore or reject DHCP-Requests containing a DHCP User-Class ignore or reject DHCP-Requests containing a DHCP User-Class
consisting of the ASCII-String "HOMENET". consisting of the ASCII-String "HOMENET".
An interface MUST be considered external if at least one of the The border discovery auto-detection algorithm works as follows, with
following conditions is satisfied: evaluation stopping at first match:
1. The interface has a fixed category classifying it as external. 1. If a fixed category is set for an interface, it MUST be used.
2. A delegated prefix could be acquired by running a DHCPv6-client 2. Any of the following conditions indicate an interface MUST be
on the interface. considered external:
3. An IPv4-address could be acquired by running a DHCP-client on the 1. A delegated prefix could be acquired by running a
interface. DHCPv6-client on the interface.
4. HNCP security is enabled and there are routers on the interface 2. An IPv4-address could be acquired by running a DHCP-client on
which could not be authenticated. 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.
A router SHOULD allow setting a category of either auto-detected,
internal or external for each interface which is suitable for both
internal and external connections. In addition it MAY offer further
categories which modify the local router behavior, such as:
Guest category: This is a specialization of the internal category
which declares an interface used for untrusted clients. The
router MUST NOT send or accept 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
which declares an interface to be in ad-hoc mode. This indicates
to HNCP applications such as prefix assignment that links on this
interface are potentially non-transitive.
Hybrid category: This is a specialization of the internal category
in which the router still accepts external 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 is
out of scope for this document, and therefore it MAY be supported
only via manual configuration on a per-router basis.
A homenet router SHOULD provide basic connectivity to legacy CERs
[RFC7084] connected to internal interfaces in order to allow
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
SHOULD wait for a reasonable time period (5 seconds as a possible SHOULD wait for a reasonable time period (5 seconds as a possible
default) in which the DHCP-clients can acquire a lease before default) in which the DHCP-clients can acquire a lease before
treating a newly activated or previously external interface as treating a newly activated or previously external interface as
internal. Once it treats a certain interface as internal it MUST internal. Once it treats a certain interface as internal it MUST
start forwarding traffic with appropriate source addresses between start forwarding traffic with appropriate source addresses between
its internal interfaces and allow internal traffic to reach external its internal interfaces and allow internal traffic to reach external
networks. Once a router detects an interface to be external it MUST networks. Once a router detects an interface to be external it MUST
stop any previously enabled internal forwarding. In addition it stop any previously enabled internal forwarding. In addition it
SHOULD announce the acquired information for use in the homenet as SHOULD announce the acquired information for use in the homenet as
described in later sections of this draft if the interface appears to described in later sections of this draft if the interface appears to
be connected to an external network. be connected to an external network.
To distribute an external connection in the homenet an edge router To distribute an external connection in the homenet an edge router
announces one or more delegated prefixes and associated announces one or more delegated prefixes and associated DHCP(v6)-
DHCP(v6)-encoded auxiliary information like recursive DNS-servers. encoded auxiliary information like recursive DNS-servers. Each
Each external connection is announced using one container-TLV as external connection is announced using one container-TLV as follows:
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: EXTERNAL-CONNECTION (41)| Length: > 4 | | Type: EXTERNAL-CONNECTION (41)| Length: > 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Nested TLVs | | Nested TLVs |
Auxiliary connectivity information is encoded as a stream of Auxiliary connectivity information is encoded as a stream of
DHCPv6-attributes or DHCP-attributes placed inside a TLV of type DHCPv6-attributes or DHCP-attributes placed inside a TLV of type
skipping to change at page 16, line 4 skipping to change at page 16, line 42
| DHCPv6 attribute stream | | DHCPv6 attribute stream |
and and
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: DHCP-DATA (44) | Length: > 4 | | Type: DHCP-DATA (44) | Length: > 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DHCP attribute stream | | DHCP attribute stream |
Each delegated prefix is encoded using one TLV inside an EXTERNAL- Each delegated prefix is encoded using one TLV inside an EXTERNAL-
CONNECTION TLV. For external IPv4 connections the prefix is encoded CONNECTION TLV. For external IPv4 connections the prefix is encoded
in the form of an IPv4-mapped address [RFC4291] and is usually from a in the form of an IPv4-mapped address [RFC4291] and is usually from a
private address range [RFC1597]. The related TLV is defined as private address range [RFC1918]. The related TLV is defined as
follows. 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: DELEGATED-PREFIX (42) | Length: >= 13 | | Type: DELEGATED-PREFIX (42) | Length: >= 13 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Valid until (milliseconds) | | Valid until (milliseconds) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Preferred until (milliseconds) | | Preferred until (milliseconds) |
skipping to change at page 17, line 22 skipping to change at page 18, line 22
| R. |A| Pref. | Prefix Length | | | R. |A| Pref. | Prefix Length | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Prefix Address + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Prefix Address +
| | | |
Link Identifier is the local HNCP identifier of the link the Link Identifier is the local HNCP identifier of the link the
prefix is assigned to. prefix is assigned to.
R. is reserved for future additions and MUST be set to 0 when R. is reserved for future additions and MUST be set to 0 when
creating TLVs and ignored when parsing them. creating TLVs and ignored when parsing them.
A is the authoritative flag which indicates that an assigment is A is the authoritative flag which indicates that an assignment is
enforced and ignores usual collision detection rules. enforced and ignores usual collision detection rules.
Pref. describes the preference of the assignment and can be used Pref. describes the preference of the assignment and can be used
to differentiate the importance of a given assignment over others. to differentiate the importance of a given assignment over others.
Prefix length specifies the number of significant bits in the Prefix length specifies the number of significant bits in the
prefix. prefix.
Prefix address is of variable length and contains the significant Prefix address is of variable length and contains the significant
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.
In some cases (e.g. IPv4) the set of addresses is very limited and In some cases (e.g. IPv4) the set of addresses is very limited and
stateless mechanisms are not really suitable for address assignment. stateless mechanisms are not really suitable for address assignment.
Therefore HNCP can manage router address in these cases by itself. Therefore HNCP can manage router address in these cases by itself.
Each router assigning an address to one of its interfaces announces Each router assigning an address to one of its interfaces announces
one TLV of the following kind: one TLV of the following kind:
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: ROUTER-ADDRESS (46) | Length: 24 | | Type: ROUTER-ADDRESS (46) | Length: 24 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 19, line 22 skipping to change at page 20, line 22
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 autoconfiguration 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
skipping to change at page 21, line 5 skipping to change at page 22, line 5
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
does not require any additional protocol message exchange. does not require any additional protocol message exchange.
1. Interpret the neighbour information received via HNCP as a graph 1. Interpret the neighbor information received via HNCP as a graph
of connected routers. of connected routers.
2. Use breadth-first traversal to determine the next-hop and hop- 2. Use breadth-first traversal to determine the next-hop and hop-
count in the path to each router in the homenet: count in the path to each router in the homenet:
Start the traversal with the immediate neighbours of the 1. Start the traversal with the immediate neighbors of the
router running the algorithm. router running the algorithm.
Always visit the immediate neighbours of a router in ascending 2. Always visit the immediate neighbors of a router in ascending
order of their router ID. order of their router ID.
Never visit a router more often than once. 3. Never visit a router more often than once.
3. For each delegated prefix P of any router R in the homenet: 3. For each delegated prefix P of any router R in the homenet:
Create a default route via the next-hop for R acquired in #2. Create a default route via the next-hop for R acquired in #2.
Each such route MUST be source-restricted to only apply to Each such route MUST be source-restricted to only apply to
traffic with a source address within P and its metric MUST traffic with a source address within P and its metric MUST
reflect the hop-count to R. reflect the hop-count to R.
4. For each assigned prefix A of a router R: Create a route to A via 4. For each assigned prefix A of a router R: Create a route to A via
the next-hop for R acquired in #2. Each such route MUST NOT be the next-hop for R acquired in #2. Each such route MUST NOT be
source-restricted. source-restricted.
5. For the first router R visited in the traversal annuncing 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 [I-D.ietf-homenet-arch]. The protocols used to setup IP in home
skipping to change at page 22, line 18 skipping to change at page 23, line 18
to securely define a border as well as protect against malicious to securely define a border as well as protect against malicious
attacks and spoofing attempts from inside or outside the border. attacks and spoofing attempts from inside or outside the border.
HNCP itself sends messages as (possibly authenticated) clear text HNCP itself sends messages as (possibly authenticated) clear text
which is as secure, or insecure, as the security of the link below as 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 discussed in [I-D.kline-homenet-default-perimeter]. When no unique
public key is available, a hardware fingerprint or equivalent to public key is available, a hardware fingerprint or equivalent to
identify routers must be available for use by HNCP. identify routers must be available for use by HNCP.
As HNCP messages are sent over UDP/IP, IPsec may be used for As HNCP messages are sent over UDP/IP, IPsec may be used for
confidentiality or additional message authenitation. However, this confidentiality or additional message authentication. However, this
requires manually keyed IPsec per-port granularity for port IANA-UDP- 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 PORT UDP traffic. Also, a pre-shared key has to be utilized in this
case given IKE cannot be used with multicast traffic. case given IKE cannot be used with multicast traffic.
If no router can be trusted and additional guarantees about source of If no router can be trusted and additional guarantees about source of
node status updates is necessary, real public and private keys should 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- 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 node data TLVs as well as across the entire HNCP message. In this
mode, care must be taken in rate limiting verification of invalid mode, care must be taken in rate limiting verification of invalid
packets, as otherwise denial of service may occur due to exhaustion packets, as otherwise denial of service may occur due to exhaustion
skipping to change at page 24, line 8 skipping to change at page 25, line 8
[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.pfister-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-pfister-
homenet-prefix-assignment-00 (work in progress), February homenet-prefix-assignment-01 (work in progress), May 2014.
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-00 (work in progress), February 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
Requirements for IPv6 Customer Edge Routers", RFC 7084, Requirements for IPv6 Customer Edge Routers", RFC 7084,
November 2013. November 2013.
[RFC3004] Stump, G., Droms, R., Gu, Y., Vyaghrapuri, R., Demirtjis, [RFC3004] Stump, G., Droms, R., Gu, Y., Vyaghrapuri, R., Demirtjis,
A., Beser, B., and J. Privat, "The User Class Option for A., Beser, B., and J. Privat, "The User Class Option for
DHCP", RFC 3004, November 2000. DHCP", RFC 3004, November 2000.
skipping to change at page 24, line 41 skipping to change at page 25, line 40
2131, March 1997. 2131, March 1997.
[RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C.,
and M. Carney, "Dynamic Host Configuration Protocol for and M. Carney, "Dynamic Host Configuration Protocol for
IPv6 (DHCPv6)", RFC 3315, July 2003. IPv6 (DHCPv6)", RFC 3315, July 2003.
[RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic
Host Configuration Protocol (DHCP) version 6", RFC 3633, Host Configuration Protocol (DHCP) version 6", RFC 3633,
December 2003. December 2003.
[RFC1597] Rekhter, Y., Moskowitz, R., Karrenberg, D., and G. de [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and
Groot, "Address Allocation for Private Internets", RFC E. Lear, "Address Allocation for Private Internets", BCP
1597, March 1994. 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] [I-D.ietf-homenet-arch]
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", draft- "IPv6 Home Networking Architecture Principles", draft-
ietf-homenet-arch-11 (work in progress), October 2013. 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] [I-D.behringer-homenet-trust-bootstrap]
Behringer, M., Pritikin, M., and S. Bjarnason, Behringer, M., Pritikin, M., and S. Bjarnason,
"Bootstrapping Trust on a Homenet", draft-behringer- "Bootstrapping Trust on a Homenet", draft-behringer-
homenet-trust-bootstrap-00 (work in progress), October homenet-trust-bootstrap-02 (work in progress), February
2012. 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-00 (work in progress), August 2013.
[I-D.kline-homenet-default-perimeter] [I-D.kline-homenet-default-perimeter]
Kline, E., "Default Border Definition", draft-kline- Kline, E., "Default Border Definition", draft-kline-
homenet-default-perimeter-00 (work in progress), March homenet-default-perimeter-00 (work in progress), March
2013. 2013.
[I-D.arkko-homenet-prefix-assignment]
Arkko, J., Lindem, A., and B. Paterson, "Prefix Assignment
in a Home Network", draft-arkko-homenet-prefix-
assignment-04 (work in progress), May 2013.
[I-D.stenberg-homenet-dnssdext-hybrid-proxy-ospf]
Stenberg, M., "Hybrid Unicast/Multicast DNS-Based Service
Discovery Auto-Configuration Using OSPFv3", draft-
stenberg-homenet-dnssdext-hybrid-proxy-ospf-00 (work in
progress), June 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.
11.3. URIs
[2] http://www.openwrt.org
[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?
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 L2 doesn't provide them periodically in any reachability checks if layer 2 does not provide them periodically in
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 Should we use something else than MD5 as hash? It IS somewhat
insecure; however signature stuff (TBD) should rely on it mainly for insecure; however signature stuff (TBD) should rely on it mainly for
security in any case, and MD5 is used in a non-security role. 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 doesn't 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.
Q: Why so long IDs? Why real hash even in insecure mode? Q: Why so long IDs? Why real hash even in insecure mode?
A: Scalability of protocol isn't 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.
Q: Should there be nested container syntax that is actually self- Q: Should there be nested container syntax that is actually self-
skipping to change at page 27, line 4 skipping to change at page 27, line 47
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.
Q: Should there be nested container syntax that is actually self- Q: Should there be nested container syntax that is actually self-
describing? (i.e. type flag that indicates container, no body except describing? (i.e. type flag that indicates container, no body except
sub-TLVs?) sub-TLVs?)
A: Not for now, but perhaps valid design.. TBD. A: Not for now, but perhaps valid design.. TBD.
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-01: Added (MAY) guest, ad-hoc, hybrid
categories for interfaces. Removed old hnetv2 reference, and now
pointing just to OpenWrt + github. Fixed synchronization algorithm
to spread also same update number, but different data hash case.
Made purge step require bidirectional connectivity between nodes when
traversing the graph. Edited few other things to be hopefully
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
assigned address TLV. assigned address TLV.
Appendix D. Draft source Appendix D. Draft source
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/ [3] in source format (with nice Makefile too). Feel free to drafts/ in source format (with nice Makefile too). Feel free to send
send comments and/or pull requests if and when you have changes to comments and/or pull requests if and when you have changes to it!
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.
Authors' Addresses Authors' Addresses
Markus Stenberg Markus Stenberg
Helsinki 00930 Helsinki 00930
 End of changes. 52 change blocks. 
119 lines changed or deleted 162 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/