RFC2775]. Each device should be globally addressable, and those addresses must not be altered in transit. However, security perimeters can be applied to restrict end-to-end communications, and thus while a host may be globally addressable, it may not be globally reachable. [RFC4864] describes a 'Simple Security' model for IPv6 networks, whereby stateful perimeter filtering can be applied to control the reachability of devices in a homenet. RFC 4864 states in Section 4.2 that "the use of firewalls...is recommended for those that want boundary protection in addition to host defences." It should be noted that a 'default deny' filtering approach would effectively replace the need for IPv4 NAT traversal protocols with a need to use a signalling protocol to request a firewall hole be opened, e.g., a protocol such as PCP [RFC6887]. In networks with multiple CE routers, the signalling would need to handle the cases of flows that may use one or more exit routers. CE routers would need to be able to advertise their existence for such protocols.
[RFC6092] expands on RFC 4864, giving a more detailed discussion of IPv6 perimeter security recommendations, without mandating a 'default deny' approach. Indeed, RFC 6092 does not enforce a particular mode of operation, instead stating that CE routers must provide an easily selected configuration option that permits a 'transparent' mode, thus ensuring a 'default allow' model is available. The topic of whether future home networks as described in this document should have a 'default deny' or 'default allow' position has been discussed at length in various IETF meetings without any consensus being reached on which approach is more appropriate. Further, the choice of which default to apply may be situational, and thus this text makes no recommendation on the default setting beyond what is written on this topic in RFC 6092. We note in Section 3.6.3 below that the implicit firewall function of an IPv4 NAT is commonplace today, and thus future CE routers targeted at home networks should continue to support the option of running in 'default deny mode', whether or not that is the default setting. Section 3.3.1.
Section 3.6, if appropriate filtering is in place on the CE router(s), as mandated by requirement S-2 in RFC 7084, a ULA source address may be taken as an indication of locally sourced traffic. This indication could then be used with security settings to designate between which nodes a particular application is allowed to communicate, provided ULA address space is filtered appropriately at the boundary of the realm.
We note that current zero-configuration service discovery protocols are generally aimed at single subnets. There is thus a choice to make for multi-subnet homenets as to whether such protocols should be proxied or extended to operate across a whole homenet. In this context, that may mean bridging a link-local method, taking care to avoid packets entering looping paths, or extending the scope of multicast traffic used for the purpose. It may mean that some proxy or hybrid service is utilised, perhaps co-resident on the CE router. Or, it may be that a new approach is preferable, e.g., flooding information around the homenet as attributes within the routing protocol (which could allow per-prefix configuration). However, we should prefer approaches that are backward compatible and allow current implementations to continue to be used. Note that this document does not mandate a particular solution; rather, it expresses the principles that should be used for a homenet naming and service discovery environment. One of the primary challenges facing service discovery today is lack of interoperability due to the ever increasing number of service discovery protocols available. While it is conceivable for consumer devices to support multiple discovery protocols, this is clearly not the most efficient use of network and computational resources. One goal of the homenet architecture should be a path to service discovery protocol interoperability through either a standards-based translation scheme, hooks into current protocols to allow some form of communication among discovery protocols, extensions to support a central service repository in the homenet, or simply convergence towards a unified protocol suite.
RFC6762]. When DNS is used as the homenet name service, it typically includes both a resolving service and an authoritative service. The authoritative service hosts the homenet-related zone. One approach when provisioning such a name service, which is designed to facilitate name resolution from the global Internet, is to run an authoritative name service on the CE router and a secondary authoritative name service provided by the ISP or perhaps an external third party. Where zero-configuration name services are used, it is desirable that these can also coexist with the Internet name service. In particular, where the homenet is using a global name space, it is desirable that devices have the ability, where desired, to add entries to that name space. There should also be a mechanism for such entries to be removed or expired from the global name space. To protect against attacks such as cache poisoning, where an attacker is able to insert a bogus DNS entry in the local cache, it is desirable to support appropriate name service security methods, including DNS Security Extensions (DNSSEC) [RFC4033], on both the authoritative server and the resolver sides. Where DNS is used, the homenet router or naming service must not prevent DNSSEC from operating. While this document does not specify hardware requirements, it is worth noting briefly here that, e.g., in support of DNSSEC, appropriate homenet devices should have good random number generation capability, and future homenet specifications should indicate where high-quality random number generators, i.e., with decent entropy, are needed.
Finally, the impact of a change in the CE router must be considered. It would be desirable to retain any relevant state (configuration) that was held in the old CE router. This might imply that state information should be distributed in the homenet, to be recoverable by/to the new CE router, or to the homenet's ISP or a third-party externally provided service by some means.
An alternative approach for a local name space would be to use a Unique Locally Qualified Domain Name (ULQDN) space such as .<UniqueString>.sitelocal. The <UniqueString> could be generated in a variety of ways, one potentially being based on the local /48 ULA prefix being used across the homenet. Such a <UniqueString> should survive a cold restart, i.e., be consistent after a network power- down, or if a value is not set on startup, the CE router or device running the name service should generate a default value. It would be desirable for the homenet user to be able to override the <UniqueString> with a value of their choice, but that would increase the likelihood of a name conflict. Any generated <UniqueString> should not be predictable; thus, adding a salt/hash function would be desirable. In the (likely) event that the homenet is accessible from outside the homenet (using the global name space), it is vital that the homenet name space follow the rules and conventions of the global name space. In this mode of operation, names in the homenet (including those automatically generated by devices) must be usable as labels in the global name space. [RFC5890] describes considerations for Internationalizing Domain Names in Applications (IDNA). Also, with the introduction of new 'dotless' top-level domains, there is also potential for ambiguity between, for example, a local host called 'computer' and (if it is registered) a .computer Generic Top Level Domain (gTLD). Thus, qualified names should always be used, whether these are exposed to the user or not. The IAB has issued a statement that explains why dotless domains should be considered harmful [IABdotless]. There may be use cases where different name spaces may be desired for either different realms in the homenet or segmentation of a single name space within the homenet. Thus, hierarchical name space management is likely to be required. There should also be nothing to prevent an individual device(s) from being independently registered in external name spaces. It may be the case that if there are two or more CE routers serving the home network, if each has a name space delegated from a different ISP, there is the potential for devices in the home to have multiple fully qualified names under multiple domains. Where a user is in a remote network wishing to access devices in their home network, there may be a requirement to consider the domain search order presented where multiple associated name spaces exist. This also implies that a domain discovery function is desirable.
It may be the case that not all devices in the homenet are made available by name via an Internet name space, and that a 'split view' (as described in [RFC6950], Section 4) is preferred for certain devices, whereby devices inside the homenet see different DNS responses to those outside. Finally, this document makes no assumption about the presence or omission of a reverse lookup service. There is an argument that it may be useful for presenting logging information to users with meaningful device names rather than literal addresses. There are also some services, most notably email mail exchangers, where some operators have chosen to require a valid reverse lookup before accepting connections.
There are efforts underway to determine naming and discovery solutions for use by the Constrained Application Protocol (CoAP) [RFC7252] in LLN networks. These are outside the scope of this document. RFC2475] approach with a small number of predefined traffic classes may generally be sufficient, though at present there is little experience of QoS deployment in home networks. It is likely that QoS, or traffic prioritisation, methods will be required at the
CE router and potentially around boundaries between different link media types (where, for example, some traffic may simply not be appropriate for some media and need to be dropped to avoid overloading the constrained media). There may also be complementary mechanisms that could be beneficial to application performance and behaviour in the homenet domain, such as ensuring proper buffering algorithms are used as described in [Gettys11].
It may also be the case that an ISP, or a third party, might wish to offer a remote management service for the homenet on behalf of the user, or to be able to assist the user in the event of some problem they are experiencing, in which case appropriate management and monitoring protocols would be required. Specifying the required protocols to facilitate homenet management and monitoring is out of scope of this document. As stated above, it is expected that a separate document will be produced to describe the operations and management framework for the types of home networks presented in this document. As a final point, we note that it is desirable that all network management and monitoring functions should be available over IPv6 transport, even where the homenet is dual stack.
ability to turn on routing, prefix delegation, and other functions in a backwards-compatible manner. Section 3.6 above. [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998, <http://www.rfc-editor.org/info/rfc2460>. [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic Host Configuration Protocol (DHCP) version 6", RFC 3633, December 2003, <http://www.rfc-editor.org/info/rfc3633>. [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast Addresses", RFC 4193, October 2005, <http://www.rfc-editor.org/info/rfc4193>. [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, February 2006, <http://www.rfc-editor.org/info/rfc4291>. [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, February 1996, <http://www.rfc-editor.org/info/rfc1918>. [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., and W. Weiss, "An Architecture for Differentiated Services", RFC 2475, December 1998, <http://www.rfc-editor.org/info/rfc2475>.
[RFC2775] Carpenter, B., "Internet Transparency", RFC 2775, February 2000, <http://www.rfc-editor.org/info/rfc2775>. [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing", BCP 38, RFC 2827, May 2000, <http://www.rfc-editor.org/info/rfc2827>. [RFC3002] Mitzel, D., "Overview of 2000 IAB Wireless Internetworking Workshop", RFC 3002, December 2000, <http://www.rfc-editor.org/info/rfc3002>. [RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network Address Translator (Traditional NAT)", RFC 3022, January 2001, <http://www.rfc-editor.org/info/rfc3022>. [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "DNS Security Introduction and Requirements", RFC 4033, March 2005, <http://www.rfc-editor.org/info/rfc4033>. [RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and More-Specific Routes", RFC 4191, November 2005, <http://www.rfc-editor.org/info/rfc4191>. [RFC4192] Baker, F., Lear, E., and R. Droms, "Procedures for Renumbering an IPv6 Network without a Flag Day", RFC 4192, September 2005, <http://www.rfc-editor.org/info/rfc4192>. [RFC4607] Holbrook, H. and B. Cain, "Source-Specific Multicast for IP", RFC 4607, August 2006, <http://www.rfc-editor.org/info/rfc4607>. [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless Address Autoconfiguration", RFC 4862, September 2007, <http://www.rfc-editor.org/info/rfc4862>. [RFC4864] Van de Velde, G., Hain, T., Droms, R., Carpenter, B., and E. Klein, "Local Network Protection for IPv6", RFC 4864, May 2007, <http://www.rfc-editor.org/info/rfc4864>. [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy Extensions for Stateless Address Autoconfiguration in IPv6", RFC 4941, September 2007, <http://www.rfc-editor.org/info/rfc4941>.
[RFC5533] Nordmark, E. and M. Bagnulo, "Shim6: Level 3 Multihoming Shim Protocol for IPv6", RFC 5533, June 2009, <http://www.rfc-editor.org/info/rfc5533>. [RFC5890] Klensin, J., "Internationalized Domain Names for Applications (IDNA): Definitions and Document Framework", RFC 5890, August 2010, <http://www.rfc-editor.org/info/rfc5890>. [RFC5969] Townsley, W. and O. Troan, "IPv6 Rapid Deployment on IPv4 Infrastructures (6rd) -- Protocol Specification", RFC 5969, August 2010, <http://www.rfc-editor.org/info/rfc5969>. [RFC6092] Woodyatt, J., "Recommended Simple Security Capabilities in Customer Premises Equipment (CPE) for Providing Residential IPv6 Internet Service", RFC 6092, January 2011, <http://www.rfc-editor.org/info/rfc6092>. [RFC6144] Baker, F., Li, X., Bao, C., and K. Yin, "Framework for IPv4/IPv6 Translation", RFC 6144, April 2011, <http://www.rfc-editor.org/info/rfc6144>. [RFC6145] Li, X., Bao, C., and F. Baker, "IP/ICMP Translation Algorithm", RFC 6145, April 2011, <http://www.rfc-editor.org/info/rfc6145>. [RFC6177] Narten, T., Huston, G., and L. Roberts, "IPv6 Address Assignment to End Sites", BCP 157, RFC 6177, March 2011, <http://www.rfc-editor.org/info/rfc6177>. [RFC6204] Singh, H., Beebee, W., Donley, C., Stark, B., and O. Troan, "Basic Requirements for IPv6 Customer Edge Routers", RFC 6204, April 2011, <http://www.rfc-editor.org/info/rfc6204>. [RFC6296] Wasserman, M. and F. Baker, "IPv6-to-IPv6 Network Prefix Translation", RFC 6296, June 2011, <http://www.rfc-editor.org/info/rfc6296>. [RFC6333] Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual- Stack Lite Broadband Deployments Following IPv4 Exhaustion", RFC 6333, August 2011, <http://www.rfc-editor.org/info/rfc6333>. [RFC6555] Wing, D. and A. Yourtchenko, "Happy Eyeballs: Success with Dual-Stack Hosts", RFC 6555, April 2012, <http://www.rfc-editor.org/info/rfc6555>.
[RFC6724] Thaler, D., Draves, R., Matsumoto, A., and T. Chown, "Default Address Selection for Internet Protocol Version 6 (IPv6)", RFC 6724, September 2012, <http://www.rfc-editor.org/info/rfc6724>. [RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762, February 2013, <http://www.rfc-editor.org/info/rfc6762>. [RFC6824] Ford, A., Raiciu, C., Handley, M., and O. Bonaventure, "TCP Extensions for Multipath Operation with Multiple Addresses", RFC 6824, January 2013, <http://www.rfc-editor.org/info/rfc6824>. [RFC6887] Wing, D., Cheshire, S., Boucadair, M., Penno, R., and P. Selkirk, "Port Control Protocol (PCP)", RFC 6887, April 2013, <http://www.rfc-editor.org/info/rfc6887>. [RFC6950] Peterson, J., Kolkman, O., Tschofenig, H., and B. Aboba, "Architectural Considerations on Application Features in the DNS", RFC 6950, October 2013, <http://www.rfc-editor.org/info/rfc6950>. [RFC7084] Singh, H., Beebee, W., Donley, C., and B. Stark, "Basic Requirements for IPv6 Customer Edge Routers", RFC 7084, November 2013, <http://www.rfc-editor.org/info/rfc7084>. [RFC7157] Troan, O., Miles, D., Matsushima, S., Okimoto, T., and D. Wing, "IPv6 Multihoming without Network Address Translation", RFC 7157, March 2014, <http://www.rfc-editor.org/info/rfc7157>. [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained Application Protocol (CoAP)", RFC 7252, June 2014, <http://www.rfc-editor.org/info/rfc7252>. [IABdotless] IAB, "IAB Statement: Dotless Domains Considered Harmful", February 2013, <http://www.iab.org/documents/ correspondence-reports-documents/2013-2/ iab-statement-dotless-domains-considered-harmful>. [Gettys11] Gettys, J., "Bufferbloat: Dark Buffers in the Internet", March 2011, <http://www.ietf.org/proceedings/80/slides/tsvarea-1.pdf>.