idnits 2.17.1 draft-fujiwara-smallest-homenet-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (Oct 22, 2012) is 4204 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-17) exists of draft-ietf-homenet-arch-06 Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Homenet K. Fujiwara 3 Internet-Draft JPRS 4 Intended status: Informational Oct 22, 2012 5 Expires: April 25, 2013 7 Smallest home network 8 draft-fujiwara-smallest-homenet-01.txt 10 Abstract 12 Although access control for home servers is very important, 13 managements and setups of access controls are difficult for most of 14 users. "Connecting a new node to the same link" is easiest way of 15 access control. One of solutions is to use link-local addresses for 16 communications of clients and servers. 18 Status of This Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at http://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on April 25, 2013. 35 Copyright Notice 37 Copyright (c) 2012 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (http://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 1.1. Problem statement . . . . . . . . . . . . . . . . . . . . . 3 54 1.2. Possible solution . . . . . . . . . . . . . . . . . . . . . 3 55 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 3. Homenet using Link-Local address . . . . . . . . . . . . . . . 3 57 4. Homenet using ULA . . . . . . . . . . . . . . . . . . . . . . . 4 58 5. Homenet using global addresses . . . . . . . . . . . . . . . . 5 59 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 60 7. IANA considerations . . . . . . . . . . . . . . . . . . . . . . 5 61 8. Normative References . . . . . . . . . . . . . . . . . . . . . 5 62 Appendix A. Link-local Examples . . . . . . . . . . . . . . . . . 5 63 A.1. Example 1: 1 local net + 1 guest net . . . . . . . . . . . 5 64 A.2. Example 2: 2 local net + 1 guest net . . . . . . . . . . . 6 66 1. Introduction 68 The homenet architecture [I-D.ietf-homenet-arch] treats large, 69 complex home networks. There may not be network experts to manage 70 home networks. Considering simple and small home network is useful. 72 1.1. Problem statement 74 Homenet may have local networks and guest networks. The access 75 control to home network servers is very important because some 76 servers should not be accessed from guest networks. 78 Initial setups and operations of access controls are difficult for 79 most of users. WiFi and Bluetooth support easy configuration 80 mechanism. "Connecting a new node to the same link", or "connecting 81 a new node and push a button/pin" are easiest way to configure the 82 new node that can relate with a home server. 84 1.2. Possible solution 86 There are some solutions. Using link-local address between clients 87 and servers restricts access to servers. "Connecting a new node to 88 the same link" is usable as an access control. It is described in 89 Section 3. 91 Using Unique Local Address (ULA) address between clients and servers 92 limits access to servers. It is described in Section 4. 94 Otherwise, we need another solutions. 96 2. Terminology 98 A guest network is a network which can access the Internet and cannot 99 access home servers. A local network is a network which can access 100 the Internet and home servers. 102 3. Homenet using Link-Local address 104 Suppose there is only a local network in a home and there may be a 105 guest network. Two types of networks are common because recent CPEs 106 have multiple SSID function which separates internal network and 107 guest network. Link-Local addresses are able to point entities in 108 the local network. Link-local servers within the local network serve 109 services to clients using link-local address only. Link-local 110 servers will accept requests from link-local addresses. Link-local 111 servers should reject requests from another addresses. Link-local 112 servers may act as a normal IPv6 client (for its internal use: They 113 can get IPv6 prefixes from CPEs and can connect to the internet via 114 CPEs). 116 Name resolutions inside the local network may be performed by "ICMPv6 117 Node Information Queries" [RFC4620] or another methods (mDNS 118 [RFC4795]). The problem is that [RFC4620] is an EXPERIMENTAL RFC. 120 Pros: 122 * It does not need internet connectivity and can work without 123 CPEs 125 * Other communications are not affected by this proposal. 127 * Easy to manage by users. 129 * mDNS or IPv6 Node Information Queries are usable for name 130 resolutions. 132 * Easy to separate local networks and guest networks 134 * DNS is used for global name resolution only 136 Cons: 138 * Existing client applications may not support link-local 139 addresses 141 * Link-local client should cache link-local server information 142 with symbolic name and link-local addresses. 144 * Existing server software may not support link-local addresses 145 correctly. 147 * It does not support multiple links easily. Link-local servers 148 can have multiple network interfaces and they can support 149 multiple links. 151 4. Homenet using ULA 153 ULAs are able to point entities in the network. Connecting new nodes 154 into a homenet gives access to home servers. 156 Pros: 158 * It supports multiple links easily 160 * It does not need internet connectivity 161 * Easy to manage by users. 163 Cons: 165 * Some filtering or access control method is required for 166 protecting servers. 168 * CPEs and internal routers need to know ULAs. (need to develop 169 ULA configuration methods) 171 * Requires new name resolution mechanism. (site mDNS?) 173 5. Homenet using global addresses 175 Global addresses are able to point entities in the network. This 176 case is the same as enterprise networks. 178 6. Security Considerations 180 7. IANA considerations 182 8. Normative References 184 [RFC4620] Crawford, M. and B. Haberman, "IPv6 Node 185 Information Queries", RFC 4620, August 2006. 187 [RFC4795] Aboba, B., Thaler, D., and L. Esibov, "Link- 188 local Multicast Name Resolution (LLMNR)", 189 RFC 4795, January 2007. 191 [I-D.ietf-homenet-arch] Chown, T., Arkko, J., Brandt, A., Troan, O., 192 and J. Weil, "Home Networking Architecture 193 for IPv6", draft-ietf-homenet-arch-06 (work 194 in progress), October 2012. 196 Appendix A. Link-local Examples 198 A.1. Example 1: 1 local net + 1 guest net 200 Figure 1 shows 1 local network and 1 guest network example. Guest1 201 and Guest2 cannot access to Server1 and Server2. Guest1 and Guest2 202 can access the Internet. Client1 can access Server1, Server2 and the 203 Internet. 205 +---------+ Server1 Server2 Client1 206 | | | | | 207 | CPE +-----+--------+---------+---------------- 208 | | local network (may have wireless bridge) 209 Internet===+ | 210 | | 211 | +----------------+---------+--- 212 | | guest network | | 213 +---------+ Guest1 Guest2 215 Figure 1: Example 1: 1 local net + 1 guest net 217 A.2. Example 2: 2 local net + 1 guest net 219 Figure 2 shows 2 local network and 1 guest network example. Client1 220 can access Server1, Server2 and SharedServer. Client2 can access 221 SharedServer. Guest1 and Guest2 cannot access Server1, Server2 and 222 SharedServer. 224 +---------+ Server1 Server2 Client1 225 | | | | | 226 | CPE +-----+--------+---------+---------------- 227 | | | local net 1 228 | | SharedServer 229 Internet===+ | | 230 | +----+---------+-------------------------- 231 | | | local net2 232 | | Client2 233 | | 234 | +----------------+---------+--- 235 | | guest network | | 236 +---------+ Guest1 Guest2 238 Figure 2: Example 2: 2 local net + 1 guest net 240 Author's Address 242 Kazunori Fujiwara 243 Japan Registry Services Co., Ltd. 244 Chiyoda First Bldg. East 13F, 3-8-1 Nishi-Kanda 245 Chiyoda-ku, Tokyo 101-0065 246 Japan 248 Phone: +81 3 5215 8451 249 EMail: fujiwara@wide.ad.jp, fujiwara@jprs.co.jp