RFC 7368
IPv6 Home Networking Architecture Principles
Pages: 49
Informational
Informational
Part 3 of 3 – Pages 32 to 49
3.6. Security
The security of an IPv6 homenet is an important consideration. The most notable difference to the IPv4 operational model is the removal of NAT, the introduction of global addressability of devices, and thus a need to consider whether devices should have global reachability. Regardless, hosts need to be able to operate securely, end to end where required, and also be robust against malicious traffic directed towards them. However, there are other challenges introduced, e.g., default filtering policies at the borders between various homenet realms.3.6.1. Addressability vs. Reachability
An IPv6-based home network architecture should embrace the transparent end-to-end communications model as described in [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.3.6.2. Filtering at Borders
It is desirable that there are mechanisms to detect different types of borders within the homenet, as discussed previously, and further mechanisms to then apply different types of filtering policies at those borders, e.g., whether naming and service discovery should pass a given border. Any such policies should be able to be easily applied by typical home users, e.g., to give a user in a guest network access to media services in the home or access to a printer. Simple mechanisms to apply policy changes, or associations between devices, will be required. There are cases where full internal connectivity may not be desirable, e.g., in certain utility networking scenarios, or where filtering is required for policy reasons against a guest network subnet(s). As a result, some scenarios/models may involve running an isolated subnet(s) with their own CE routers. In such cases, connectivity would only be expected within each isolated network (though traffic may potentially pass between them via external providers). LLNs provide another example of where there may be secure perimeters inside the homenet. Constrained LLN nodes may implement network key security but may depend on access policies enforced by the LLN border router. Considerations for differentiating neighbouring homenets are discussed in Section 3.3.1.
3.6.3. Partial Effectiveness of NAT and Firewalls
Security by way of obscurity (address translation) or through firewalls (filtering) is at best only partially effective. The very poor security track record of home computers, home networking, and business PC computers and networking is testimony to this. A security compromise behind the firewall of any device exposes all others, making an entire network that relies on obscurity or a firewall as vulnerable as the most insecure device on the private side of the network. However, given current evidence of home network products with very poor default device security, putting a firewall in place does provide some level of protection. The use of firewalls today, whether a good practice or not, is common practice, and the capability to afford protection via a 'default deny' setting, even if marginally effective, should not be lost. Thus, while it is highly desirable that all hosts in a homenet be adequately protected by built-in security functions, it should also be assumed that all CE routers will continue to support appropriate perimeter defence functions, as per [RFC7084].3.6.4. Exfiltration Concerns
As homenets become more complex, with more devices, and with service discovery potentially enabled across the whole home, there are potential concerns over the leakage of information should devices use discovery protocols to gather information and report it to equipment vendors or application service providers. While it is not clear how such exfiltration could be easily avoided, the threat should be recognised, be it from a new piece of hardware or some 'app' installed on a personal device.3.6.5. Device Capabilities
In terms of the devices, homenet hosts should implement their own security policies in accordance to their computing capabilities. They should have the means to request transparent communications that can be initiated to them through security filters in the homenet, for either all ports or specific services. Users should have simple methods to associate devices to services that they wish to operate transparently through (CE router) borders.
3.6.6. ULAs as a Hint of Connection Origin
As noted in 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.3.7. Naming and Service Discovery
The homenet requires devices to be able to determine and use unique names by which they can be accessed on the network and that are not used by other devices on the network. Users and devices will need to be able to discover devices and services available on the network, e.g., media servers, printers, displays, or specific home automation devices. Thus, naming and service discovery must be supported in the homenet, and given the nature of typical home network users, the service(s) providing this function must as far as possible support unmanaged operation. The naming system will be required to work internally or externally, whether the user is within or outside of the homenet, i.e., the user should be able to refer to devices by name, and potentially connect to them, wherever they may be. The most natural way to think about such naming and service discovery is to enable it to work across the entire homenet residence (site), disregarding technical borders such as subnets but respecting policy borders such as those between guest and other internal network realms. Remote access may be desired by the homenet residents while travelling but also potentially by manufacturers or other 'benevolent' third parties.3.7.1. Discovering Services
Users will typically perform service discovery through graphical user interfaces (GUIs) that allow them to browse services on their network in an appropriate and intuitive way. Devices may also need to discover other devices, without any user intervention or choice. Either way, such interfaces are beyond the scope of this document, but the interface should have an appropriate application programming interface (API) for the discovery to be performed. Such interfaces may also typically hide the local domain name element from users, especially where only one name space is available. However, as we discuss below, in some cases the ability to discover available domains may be useful.
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.3.7.2. Assigning Names to Devices
Given the large number of devices that may be networked in the future, devices should have a means to generate their own unique names within a homenet and to detect clashes should they arise, e.g., where a second device of the same type/vendor as an existing device with the same default name is deployed or where a new subnet is added to the homenet that already has a device of the same name. It is expected that a device should have a fixed name while within the scope of the homenet. Users will also want simple ways to (re)name devices, again most likely through an appropriate and intuitive interface that is beyond the scope of this document. Note that the name a user assigns to a device may be a label that is stored on the device as an attribute of the device, and it may be distinct from the name used in a name service, e.g., 'Study Laser Printer' as opposed to printer2.<somedomain>.
3.7.3. The Homenet Name Service
The homenet name service should support both lookups and discovery. A lookup would operate via a direct query to a known service, while discovery may use multicast messages or a service where applications register in order to be found. It is highly desirable that the homenet name service must at the very least coexist with the Internet name service. There should also be a bias towards proven, existing solutions. The strong implication is thus that the homenet service is DNS based, or DNS compatible. There are naming protocols that are designed to be configured and operate Internet-wide, like unicast-based DNS, but also protocols that are designed for zero-configuration local environments, like Multicast DNS (mDNS) [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.3.7.4. Name Spaces
If access to homenet devices is required remotely from anywhere on the Internet, then at least one globally unique name space is required, though the use of multiple name spaces should not be precluded. One approach is that the name space(s) used for the homenet would be served authoritatively by the homenet, most likely by a server resident on the CE router. Such name spaces may be acquired by the user or provided/generated by their ISP or an alternative externally provided service. It is likely that the default case is that a homenet will use a global domain provided by the ISP, but advanced users wishing to use a name space that is independent of their provider in the longer term should be able to acquire and use their own domain name. For users wanting to use their own independent domain names, such services are already available. Devices may also be assigned different names in different name spaces, e.g., by third parties who may manage systems or devices in the homenet on behalf of the resident(s). Remote management of the homenet is out of scope of this document. If, however, a global name space is not available, the homenet will need to pick and use a local name space, which would only have meaning within the local homenet (i.e., it would not be used for remote access to the homenet). The .local name space currently has a special meaning for certain existing protocols that have link-local scope and is thus not appropriate for multi-subnet home networks. A different name space is thus required for the homenet. One approach for picking a local name space is to use an Ambiguous Local Qualified Domain Name (ALQDN) space, such as .sitelocal (or an appropriate name reserved for the purpose). While this is a simple approach, there is the potential in principle for devices that are bookmarked somehow by name by an application in one homenet to be confused with a device with the same name in another homenet. In practice, however, the underlying service discovery protocols should be capable of handling moving to a network where a new device is using the same name as a device used previously in another homenet.
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.3.7.5. Independent Operation
Name resolution and service discovery for reachable devices must continue to function if the local network is disconnected from the global Internet, e.g., a local media server should still be available even if the Internet link is down for an extended period. This implies that the local network should also be able to perform a complete restart in the absence of external connectivity and have local naming and service discovery operate correctly. As described above, the approach of a local authoritative name service with a cache would allow local operation for sustained ISP outages. Having an independent local trust anchor is desirable, to support secure exchanges should external connectivity be unavailable. A change in ISP should not affect local naming and service discovery. However, if the homenet uses a global name space provided by the ISP, then this will obviously have an impact if the user changes their network provider.3.7.6. Considerations for LLNs
In some parts of the homenet, in particular LLNs or any devices where battery power is used, devices may be sleeping, in which case a proxy for such nodes may be required that could respond (for example) to multicast service discovery requests. Those same devices or parts of the network may have less capacity for multicast traffic that may be flooded from other parts of the network. In general, message utilisation should be efficient considering the network technologies and constrained devices that the service may need to operate over.
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.3.7.7. DNS Resolver Discovery
Automatic discovery of a name service to allow client devices in the homenet to resolve external domains on the Internet is required, and such discovery must support clients that may be a number of router hops away from the name service. Similarly, it may be desirable to convey any DNS domain search list that may be in effect for the homenet.3.7.8. Devices Roaming to/from the Homenet
It is likely that some devices that have registered names within the homenet Internet name space and that are mobile will attach to the Internet at other locations and acquire an IP address at those locations. Devices may move between different homenets. In such cases, it is desirable that devices may be accessed by the same name as is used in their home network. Solutions to this problem are not discussed in this document. They may include the use of Mobile IPv6 or Dynamic DNS -- either of which would put additional requirements on the homenet -- or establishment of a (VPN) tunnel to a server in the home network.3.8. Other Considerations
This section discusses two other considerations for home networking that the architecture should not preclude but that this text is neutral towards.3.8.1. Quality of Service
Support for Quality of Service (QoS) in a multi-service homenet may be a requirement, e.g., for a critical system (perhaps health care related) or for differentiation between different types of traffic (file sharing, cloud storage, live streaming, Voice over IP (VoIP), etc). Different link media types may have different such properties or capabilities. However, homenet scenarios should require no new QoS protocols. A Diffserv [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].3.8.2. Operations and Management
In this section, we briefly review some initial considerations for operations and management in the type of homenet described in this document. It is expected that a separate document will define an appropriate operations and management framework for such homenets. As described in this document, the homenet should have the general goal of being self-organising and self-configuring from the network- layer perspective, e.g., prefixes should be able to be assigned to router interfaces. Further, applications running on devices should be able to use zero-configuration service discovery protocols to discover services of interest to the home user. In contrast, a home user would not be expected, for example, to have to assign prefixes to links or manage the DNS entries for the home network. Such expert operation should not be precluded, but it is not the norm. The user may still be required to, or wish to, perform some configuration of the network and the devices on it. Examples might include entering a security key to enable access to their wireless network or choosing to give a 'friendly name' to a device presented to them through service discovery. Configuration of link- and application-layer services is out of scope of this architectural principles document but is likely to be required in an operational homenet. While not being expected to actively configure the networking elements of their homenet, users may be interested in being able to view the status of their networks and the devices connected to it, in which case appropriate network monitoring protocols will be required to allow them to view their network, and its status, e.g., via a web interface or equivalent. While the user may not understand how the network operates, it is reasonable to assume they are interested in understanding what faults or problems may exist on it. Such monitoring may extend to other devices on the network, e.g., storage devices or web cameras, but such devices are beyond the scope of this document.
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.3.9. Implementing the Architecture on IPv6
This architecture text encourages reuse of existing protocols. Thus, the necessary mechanisms are largely already part of the IPv6 protocol set and common implementations, though there are some exceptions. For automatic routing, it is expected that solutions can be found based on existing protocols. Some relatively smaller updates are likely to be required, e.g., a new mechanism may be needed in order to turn a selected protocol on by default, or a mechanism may be required to automatically assign prefixes to links within the homenet. Some functionality, if required by the architecture, may need more significant changes or require development of new protocols, e.g., support for multihoming with multiple exit routers would likely require extensions to support source and destination address-based routing within the homenet. Some protocol changes are, however, required in the architecture, e.g., for name resolution and service discovery, extensions to existing zero-configuration link-local name resolution protocols are needed to enable them to work across subnets, within the scope of the home network site. Some of the hardest problems in developing solutions for home networking IPv6 architectures include discovering the right borders where the 'home' domain ends and the service provider domain begins, deciding whether some of the necessary discovery mechanism extensions should affect only the network infrastructure or also hosts, and the
ability to turn on routing, prefix delegation, and other functions in a backwards-compatible manner.4. Conclusions
This text defines principles and requirements for a homenet architecture. The principles and requirements documented here should be observed by any future texts describing homenet protocols for routing, prefix management, security, naming, or service discovery.5. Security Considerations
Security considerations for the homenet architecture are discussed in Section 3.6 above.6. References
6.1. Normative References
[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>.6.2. Informative References
[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>.
Acknowledgments
The authors would like to thank Mikael Abrahamsson, Aamer Akhter, Mark Andrews, Dmitry Anipko, Ran Atkinson, Fred Baker, Ray Bellis, Teco Boot, John Brzozowski, Cameron Byrne, Brian Carpenter, Stuart Cheshire, Julius Chroboczek, Lorenzo Colitti, Robert Cragie, Elwyn Davies, Ralph Droms, Lars Eggert, Jim Gettys, Olafur Gudmundsson, Wassim Haddad, Joel M. Halpern, David Harrington, Lee Howard, Ray Hunter, Joel Jaeggli, Heather Kirksey, Ted Lemon, Acee Lindem, Kerry Lynn, Daniel Migault, Erik Nordmark, Michael Richardson, Mattia Rossi, Barbara Stark, Sander Steffann, Markus Stenberg, Don Sturek, Andrew Sullivan, Dave Taht, Dave Thaler, Michael Thomas, Mark Townsley, JP Vasseur, Curtis Villamizar, Russ White, Dan Wing, and James Woodyatt for their comments and contributions within homenet WG meetings and on the WG mailing list. An acknowledgment generally means that a person's text made it into the document or was helpful in clarifying or reinforcing an aspect of the document. It does not imply that each contributor agrees with every point in the document.
Authors' Addresses
Tim Chown (editor) University of Southampton Highfield Southampton, Hampshire SO17 1BJ United Kingdom EMail: tjc@ecs.soton.ac.uk Jari Arkko Ericsson Jorvas 02420 Finland EMail: jari.arkko@piuha.net Anders Brandt Sigma Designs Emdrupvej 26A, 1 Copenhagen DK-2100 Denmark EMail: anders_brandt@sigmadesigns.com Ole Troan Cisco Systems, Inc. Philip Pedersensvei 1 Lysaker, N-1325 Norway EMail: ot@cisco.com Jason Weil Time Warner Cable 13820 Sunrise Valley Drive Herndon, VA 20171 United States EMail: jason.weil@twcable.com