draft-ietf-homenet-hncp-03.txt   draft-ietf-homenet-hncp-04.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: July 10, 2015 Expires: September 6, 2015
P. Pfister P. Pfister
Cisco Systems Cisco Systems
January 6, 2015 March 5, 2015
Home Networking Control Protocol Home Networking Control Protocol
draft-ietf-homenet-hncp-03 draft-ietf-homenet-hncp-04
Abstract Abstract
This document describes the Home Networking Control Protocol (HNCP), This document describes the Home Networking Control Protocol (HNCP),
an extensible configuration protocol and a set of requirements for an extensible configuration protocol and a set of requirements for
home network devices on top of the Distributed Node Consensus home network devices on top of the Distributed Node Consensus
Protocol (DNCP). It enables automated configuration of addresses, Protocol (DNCP). It enables automated configuration of addresses,
naming, network borders and the seamless use of a routing protocol. naming, network borders and the seamless use of a routing protocol.
Status of This Memo Status of This Memo
skipping to change at page 1, line 37 skipping to change at page 1, line 37
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 July 10, 2015. This Internet-Draft will expire on September 6, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2015 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 50 skipping to change at page 2, line 50
10. HNCP Versioning and Capabilities . . . . . . . . . . . . . . 21 10. HNCP Versioning and Capabilities . . . . . . . . . . . . . . 21
11. Requirements for HNCP Routers . . . . . . . . . . . . . . . . 22 11. Requirements for HNCP Routers . . . . . . . . . . . . . . . . 22
12. Security Considerations . . . . . . . . . . . . . . . . . . . 23 12. Security Considerations . . . . . . . . . . . . . . . . . . . 23
12.1. Border Determination . . . . . . . . . . . . . . . . . . 24 12.1. Border Determination . . . . . . . . . . . . . . . . . . 24
12.2. Security of Unicast Traffic . . . . . . . . . . . . . . 24 12.2. Security of Unicast Traffic . . . . . . . . . . . . . . 24
12.3. Other Protocols in the Home . . . . . . . . . . . . . . 25 12.3. Other Protocols in the Home . . . . . . . . . . . . . . 25
13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25
14. References . . . . . . . . . . . . . . . . . . . . . . . . . 26 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 26
14.1. Normative references . . . . . . . . . . . . . . . . . . 26 14.1. Normative references . . . . . . . . . . . . . . . . . . 26
14.2. Informative references . . . . . . . . . . . . . . . . . 26 14.2. Informative references . . . . . . . . . . . . . . . . . 26
Appendix A. Changelog . . . . . . . . . . . . . . . . . . . . . 28 Appendix A. Some Outstanding Issues . . . . . . . . . . . . . . 28
Appendix B. Draft source . . . . . . . . . . . . . . . . . . . . 28 Appendix B. Changelog . . . . . . . . . . . . . . . . . . . . . 28
Appendix C. Implementation . . . . . . . . . . . . . . . . . . . 28 Appendix C. Draft source . . . . . . . . . . . . . . . . . . . . 28
Appendix D. Acknowledgements . . . . . . . . . . . . . . . . . . 28 Appendix D. Implementation . . . . . . . . . . . . . . . . . . . 28
Appendix E. Acknowledgements . . . . . . . . . . . . . . . . . . 29
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 29 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 29
1. Introduction 1. Introduction
HNCP synchronizes state across a small site in order to allow HNCP synchronizes state across a small site in order to allow
automated network configuration. The protocol enables use of border automated network configuration. The protocol enables use of border
discovery, address prefix distribution discovery, address prefix distribution
[I-D.ietf-homenet-prefix-assignment], naming and other services [I-D.ietf-homenet-prefix-assignment], naming and other services
across multiple links. across multiple links.
skipping to change at page 3, line 36 skipping to change at page 3, line 37
3. DNCP Profile 3. DNCP Profile
HNCP is defined as a profile of DNCP [I-D.ietf-homenet-dncp] with the HNCP is defined as a profile of DNCP [I-D.ietf-homenet-dncp] with the
following parameters: following parameters:
o HNCP uses UDP datagrams on port HNCP-UDP-PORT as a transport over o HNCP uses UDP datagrams on port HNCP-UDP-PORT as a transport over
link-local scoped IPv6, using unicast and multicast (group All- link-local scoped IPv6, using unicast and multicast (group All-
Homenet-Routers). Received datagrams with an IPv6 source or Homenet-Routers). Received datagrams with an IPv6 source or
destination address which is not link-local scoped MUST be destination address which is not link-local scoped MUST be
ignored. ignored. IPv6 fragmentation and reassembly up to TBD bytes MUST
be supported by the stack of the node.
o HNCP operates on multicast-capable interfaces only, thus every o HNCP operates on multicast-capable interfaces only, thus every
DNCP Connection Identifier MUST refer to one, except for the value DNCP Connection Identifier MUST refer to one, except for the value
0 which is reserved for internal purposes and MUST NOT be used for 0 which is reserved for internal purposes and MUST NOT be used for
connection enumeration. Implementations MAY use a value connection enumeration. Implementations MAY use a value
equivalent to the sin6_scope_id for the given interface. equivalent to the sin6_scope_id for the given interface.
o HNCP unicast messages SHOULD be secured using DTLS [RFC6347] as o HNCP unicast messages SHOULD be secured using DTLS [RFC6347] as
described in DNCP if exchanged over unsecured links. UDP on port described in DNCP if exchanged over unsecured links. UDP on port
HNCP-DTLS-PORT is used for this purpose. A node implementing the HNCP-DTLS-PORT is used for this purpose. A node implementing the
skipping to change at page 16, line 15 skipping to change at page 16, line 15
H-capability. In case of a tie, Capability Values and node H-capability. In case of a tie, Capability Values and node
identifiers are considered (greatest value is elected). The elected identifiers are considered (greatest value is elected). The elected
router MUST serve stateful DHCPv6 and Router Advertisements on the router MUST serve stateful DHCPv6 and Router Advertisements on the
given link. Furthermore it MUST provide naming services for acquired given link. Furthermore it MUST provide naming services for acquired
hostnames as outlined in Section 8. Stateful addresses being handed hostnames as outlined in Section 8. Stateful addresses being handed
out SHOULD have a low preferred lifetime (e.g. 1s) to not hinder fast out SHOULD have a low preferred lifetime (e.g. 1s) to not hinder fast
renumbering if either the DHCPv6 server or client do not support the renumbering if either the DHCPv6 server or client do not support the
DHCPv6 reconfigure mechanism and the address is from a prefix for DHCPv6 reconfigure mechanism and the address is from a prefix for
which stateless autoconfiguration is supported as well. In case no which stateless autoconfiguration is supported as well. In case no
router was elected, stateful DHCPv6 is not provided and each router router was elected, stateful DHCPv6 is not provided and each router
assigning IPv6 prefixes on said link MUST serve Router Advertisements assigning IPv6-prefixes on said link MUST provide stateless DHCPv6
and stateless DHCPv6. service.
7.2. Sending Router Advertisements 7.2. Sending Router Advertisements
The HNCP router being elected as DHCPv6 server for addressing or Each HNCP router assigning an IPV6-prefix to an interface MUST send
configuration MUST send Router Advertisements periodically via Router Advertisements periodically via multicast and via unicast in
multicast and via unicast in response to Router Solicitations. In response to Router Solicitations. In addition other routers on the
addition other routers on the link MAY announce Router link MAY announce Router Advertisements. This might result in a more
Advertisements. This might result in a more optimal routing decision optimal routing decision for clients. The following rules MUST be
for clients. The following rules MUST be followed when sending followed when sending Router Advertisements:
Router Advertisements:
The "Managed address configuration" flag MUST be set whenever a The "Managed address configuration" flag MUST be set whenever a
router connected to the link is advertising a non-null router connected to the link is advertising a non-null
H-capability and MUST NOT be set otherwise. The "Other H-capability and MUST NOT be set otherwise. The "Other
configuration" flag MUST always be set. configuration" flag MUST always be set.
The default Router Lifetime MUST be set to an appropriate non-null The default Router Lifetime MUST be set to an appropriate non-null
value whenever an IPv6 default route is known in the HNCP network value whenever an IPv6 default route is known in the HNCP network
and MUST be set to zero otherwise. and MUST be set to zero otherwise.
skipping to change at page 26, line 15 skipping to change at page 26, line 15
HNCP requires allocation of UDP port numbers HNCP-UDP-PORT and HNCP- HNCP requires allocation of UDP port numbers HNCP-UDP-PORT and HNCP-
DTLS-PORT, as well as an IPv6 link-local multicast address All- DTLS-PORT, as well as an IPv6 link-local multicast address All-
Homenet-Routers. Homenet-Routers.
14. References 14. References
14.1. Normative references 14.1. Normative references
[I-D.ietf-homenet-dncp] [I-D.ietf-homenet-dncp]
Stenberg, M. and S. Barth, "Distributed Node Consensus Stenberg, M. and S. Barth, "Distributed Node Consensus
Protocol", draft-ietf-homenet-dncp-00 (work in progress), Protocol", draft-ietf-homenet-dncp-01 (work in progress),
January 2015. March 2015.
[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.
[RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
Security Version 1.2", RFC 6347, January 2012. Security Version 1.2", RFC 6347, January 2012.
[RFC6603] Korhonen, J., Savolainen, T., Krishnan, S., and O. Troan, [RFC6603] Korhonen, J., Savolainen, T., Krishnan, S., and O. Troan,
"Prefix Exclude Option for DHCPv6-based Prefix "Prefix Exclude Option for DHCPv6-based Prefix
Delegation", RFC 6603, May 2012. Delegation", RFC 6603, May 2012.
[RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and [RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and
More-Specific Routes", RFC 4191, November 2005. More-Specific Routes", RFC 4191, November 2005.
[I-D.ietf-homenet-prefix-assignment] [I-D.ietf-homenet-prefix-assignment]
Pfister, P., Paterson, B., and J. Arkko, "Distributed Pfister, P., Paterson, B., and J. Arkko, "Distributed
Prefix Assignment Algorithm", draft-ietf-homenet-prefix- Prefix Assignment Algorithm", draft-ietf-homenet-prefix-
assignment-02 (work in progress), January 2015. assignment-03 (work in progress), February 2015.
14.2. Informative references 14.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 28, line 11 skipping to change at page 28, line 11
[RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast
Addresses", RFC 4193, October 2005. Addresses", RFC 4193, October 2005.
14.3. URIs 14.3. URIs
[3] http://www.openwrt.org [3] http://www.openwrt.org
[4] http://www.homewrt.org/doku.php?id=run-conf [4] http://www.homewrt.org/doku.php?id=run-conf
Appendix A. Changelog Appendix A. Some Outstanding Issues
Should we define in-protocol fragmentation scheme or just use IPv6
fragmentation with 'big enough' minimum acceptable size allowed for
implementations? In the same sense should we use TCP over UDP?
How should we deal with stub-routers requiring reduced complexity
versions? Stub IGPs? An HNCP-based solution? Even a stub-HNCP?
Appendix B. Changelog
draft-ietf-homenet-hncp-03: Split to DNCP (generic protocol) and HNCP draft-ietf-homenet-hncp-03: Split to DNCP (generic protocol) and HNCP
(homenet profile). (homenet profile).
draft-ietf-homenet-hncp-02: Removed any built-in security. Relying draft-ietf-homenet-hncp-02: Removed any built-in security. Relying
on IPsec. Reorganized interface categories, added requirements on IPsec. Reorganized interface categories, added requirements
languages, made manual border configuration a MUST-support. languages, made manual border configuration a MUST-support.
Redesigned routing protocol election to consider non-router devices. 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
skipping to change at page 28, line 33 skipping to change at page 28, line 42
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
assigned address TLV. assigned address TLV.
Appendix B. Draft source Appendix C. Draft source
This draft is available at https://github.com/fingon/ietf-drafts/ in This draft is available at https://github.com/fingon/ietf-drafts/ in
source format. Issues and pull requests are welcome. source format. Issues and pull requests are welcome.
Appendix C. Implementation Appendix D. Implementation
A GPLv2-licensed implementation of HNCP is currently under A GPLv2-licensed implementation of HNCP is currently under
development at https://github.com/sbyx/hnetd/ and binaries are development at https://github.com/sbyx/hnetd/ and binaries are
available in the OpenWrt [3] package repositories. See [4] for more available in the OpenWrt [3] package repositories. See [4] for more
information. Feedback and contributions are welcome. information. Feedback and contributions are welcome.
Appendix D. Acknowledgements Appendix E. Acknowledgements
Thanks to Ole Troan, Mark Baugher, Mark Townsley and Juliusz Thanks to Ole Troan, Mark Baugher, Mark Townsley and Juliusz
Chroboczek for their contributions to the draft. Chroboczek for their contributions to the draft.
Thanks to Eric Kline for the original border discovery work. Thanks to Eric Kline for the original border discovery work.
Authors' Addresses Authors' Addresses
Markus Stenberg Markus Stenberg
Helsinki 00930 Helsinki 00930
 End of changes. 14 change blocks. 
25 lines changed or deleted 35 lines changed or added

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