Thread Border Router Best Practices March 2018 This Thread Technical white paper is provided for reference purposes only. The full technical specification is available publicly. To join gain access, please follow this link: https://www.threadgroup.org/ThreadSpec. If there are questions or comments on these technical papers, please send them to [email protected]. This document and the information contained herein is provided on an “AS IS” basis and THE THREAD GROUP DISCLAIMS ALL WARRANTIES EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO (A) ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OF THIRD PARTIES (INCLUDING WITHOUT LIMITATION ANY INTELLECTUAL PROPERTY RIGHTS INCLUDING PATENT, COPYRIGHT OR TRADEMARK RIGHTS) OR (B) ANY IMPLIED WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, TITLE OR NONINFRINGEMENT. IN NO EVENT WILL THE THREAD GROUP BE LIABLE FOR ANY LOSS OF PROFITS, LOSS OF BUSINESS, LOSS OF USE OF DATA, INTERRUPTION OF BUSINESS, OR FOR ANY OTHER DIRECT, INDIRECT, SPECIAL OR EXEMPLARY, INCIDENTAL, PUNITIVE OR CONSEQUENTIAL DAMAGES OF ANY KIND, IN CONTRACT OR IN TORT, IN CONNECTION WITH THIS DOCUMENT OR THE INFORMATION CONTAINED HEREIN, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH LOSS OR DAMAGE. Copyright © 2015 Thread Group, Inc. All rights reserved. Table of Contents Terminology 4 Introduction 5 Use Cases and Requirements 6 Goals and Non-Goals of This Document 6 Requirements for In-Scope Features 6 Proposed Solution Summary 8 Protocols Summary 8 Assumed Customer Environment Summary 9 Device and Service Discovery Summary 9 Border Router Device Categories 9 Connectivity Summary 10 Global Connectivity 10 Site Connectivity 12 Security and Firewalling 12 Protocol Applicability Summary 13 Best Practices 14 Connectivity to IPv4 Destinations 14 Border Router as IPv4 LAN Host and DHCPv4 Client 14 NAT64: Thread Client Connectivity to IPv4 Servers 14 DNS64: Thread Client Locating IPv4 Servers 15 Thread Servers and IPv4 Clients 15 Connectivity to IPv6 Destinations 17 Routing Differences for IPv6 Connectivity Compared to IPv4 17 IPv6 Routing and Forwarding 19 IPv6 Prefix Allocation and Delegation 20 Prefix Delegation with Dynamic Host Configuration Protocol (DHCPv6-PD) 20 Prefix Allocation with Home Network Control Protocol (HNCP) 20 Mixed HNCP and DHCPv6 Prefix Delegation 21 2 Routing Distinct IPv6 Subnets 21 Router Advertisements on Non-Thread Links 22 Dynamic Routing with Babel 22 IPv6 Thread Servers and Non-Thread Clients 22 Security for Thread Management Framework Communications 22 IP Multicast 23 Appendix: Application Layer Specific Services 24 Service Discovery and Application Layer Proxies 24 Virtual Private Networks (VPNs) 25 IPv4 / IPv6 service and device deployment 25 Public Internet attack surface 25 Network Address Translation (NAT) and service provider traversal and keep-alive and asynchronous Internet ingress traffic 25 API and interaction pervasiveness and consistency 26 Path redundancy 26 VPN Benefits to Cloud Service Providers 26 TCP connection scaling 26 Routing and Addressing 27 References 30 3 Terminology TERM DEFINITION CPE Customer Premises Equipment (Typically an ISP-provided Modem or Modem + Router). DNS64 A technology and technique described in [RFC6147] whereby IPv6- only clients are provided, when used in conjunction with NAT64, with synthesized DNS AAAA records by translating actual IPv4-only A records. ISP Internet Service Provider IPv6 Transition Services needed to migrate the Internet from IPv4 to IPv6. IPv6 Mechanisms for interconnecting IPv6 networks via IPv4 networks. Translation and Tunneling NAT Network Address Translation NAT64 An IPv6 Transition technology that enables communications between IPv6-only nodes and IPv4-only nodes by using a form of network address translation (NAT) among a single IPv4 address and IPv4- embedded IPv6 addresses. See [RFC6146]. ND Neighbor Discovery 4 Introduction In a Thread network, the Border Router is an important piece of infrastructure. It facilitates communication of Internet Protocol (IP) packets into and out of the Thread network. In most Thread networks the Border Router will be responsible for providing full Internet communication to Thread devices. It is highly desirable that Thread device vendors can create products that can be easily commissioned onto a Thread network, after which those devices can rely on standard networking functions for IP communications – be it with other networks in the home, or servers hosted on the Internet. All of this should be done in a way that is broadly interoperable and common for Thread devices and Border Routers from various vendors. Thread Group aims for a functionality and end-user experience similar to that of Wi-Fi access points and home routers, whereby Wi-Fi devices can be relied upon to automatically obtain their IP networking configuration and are automatically provided a route to the wider Internet, as well as IP connectivity to other types of networks in the home such as Ethernet. End-to-end IPv6 routability is not yet available in every home (although Ipv6 availability has grown significantly in the last years and continues to grow). This white paper will go into some detail on the selection and implementation of suitable IPv6 Translation and Tunneling technologies, such as NAT64 and DNS64, to achieve an optimal user experience even when an ISP offers IPv4 only in the user’s home network. This document is not a replacement for any part of the Thread specifications; it is designed to act as a guide suggesting best practices and optimal technology selection for vendors that are looking to create a (generic) Thread Border Router. Any requirements language (capitalized “MUST”, “SHOULD”, etc.) only holds for a device that claims full compliance to these best practices. 5 Use Cases and Requirements Goals and Non-Goals of This Document The goals of this white paper include: ● Detailing how to design a generic Thread Border Router that facilitates ○ Site connectivity: Thread Routers and End-devices achieve end-to-end IP communication with other networks in the home (Wi-Fi, Ethernet) ○ Global connectivity: Thread Routers and End-devices achieve end-to-end IP communication with other networks outside the home (WAN, via home Internet connections such as DSL, DOCSIS, GPON or 3G/4G/5G cellular) ● Referencing the Thread specification and RFCs defined by the IETF, whenever possible to provide guidance for implementers ● Focusing on the most common residential networking scenarios and providing solutions for those ● Listing requirements and services to enable a generic Thread Border Router to support multiple vendor ecosystems and multiple IP-based application-layer technologies. Non-goals of this document include: ● Defining which application-layer technologies a Thread Border Router should implement ● Proposing changes to (the behavior of) any non-Thread equipment such as upstream CPE routers, Wi-Fi access points, or cable modems. ● Provide details for gateway functions to translate communications to or from non- IP networks. Requirements for In-Scope Features The following requirements were used as the basis to draft this best-practices white paper. The term “recommendations” below refers to the recommended best practices as listed in this paper. 1. Standards Based 1.1. Recommendations SHOULD be based on existing standards 1.2. Recommendations SHOULD reference Thread specification and IETF RFCs when possible 1.3. Recommendations SHOULD assume CPE will only implement protocols that are in wide deployment (>80% of homes) as of 2016 2. Global Connectivity 6 2.1. Recommendations MUST allow Thread hosts to connect to global IPv4 networks 2.2. Recommendations MUST allow Thread hosts to receive responses from global IPv4 networks within a realistic time window 2.3. Recommendations MUST allow Thread hosts to connect to global IPv6 networks 2.4. Recommendations MUST allow Thread hosts to receive responses from global IPv6 networks within a realistic time window 2.5. Recommendation SHOULD allow Thread hosts to receive unsolicited IPv6 messages from nodes in global IPv6 networks 2.6. Thread hosts MAY be required to register with the Border Router in order to receive unsolicited messages from off-mesh sources 3. Site Connectivity 3.1. Recommendations MUST allow Thread hosts to connect to on-site IPv4 hosts 3.2. Recommendations MUST allow Thread hosts to connect to on-site IPv6 hosts 3.3. Recommendations SHOULD allow on-site IPv6 hosts, such as laptops or phones, to connect to Thread hosts (and run discovery protocols to discover Thread hosts) 4. Security and Firewall 4.1. Recommendations MUST ensure that only ingress traffic enters a Thread network that Thread hosts have expressed interest in 7 Proposed Solution Summary A summary of the proposed solution, in terms of the recommended best practices and protocols for Thread Border Routers, is presented below. More details can be found in the next section “Best Practices” on page 14. Protocols Summary Not Requirement Solution (Protocols) RECOMMENDED OPTIONAL Recommended NAT64, DNS64, IPv4 Global, stateful firewall, IPv4 Site ✔ Self-election via connectivity Thread Network Data DHCPv6-PD, IPv6 Global, ✔ stateful firewall, IPv6 Site Except when only Self-election via connectivity /64 prefix available Thread Network Data Thread MeshCoP Border Commissioning Agent, DNS-SD (for ✔ / Discovery Commissioning) Security for Site Address PCP ✔ Referral Private ✔ Networking VPN (Global) IPv6 Global via ✔ Cellular Allowed when only ND Proxy