Tech-invite3GPPspaceIETF RFCsSIP
93929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 7368

IPv6 Home Networking Architecture Principles

Pages: 49
Informational
Part 3 of 3 – Pages 32 to 49
First   Prev   None

Top   ToC   RFC7368 - Page 32   prevText

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.
Top   ToC   RFC7368 - Page 33
   [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.
Top   ToC   RFC7368 - Page 34

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.
Top   ToC   RFC7368 - Page 35

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.
Top   ToC   RFC7368 - Page 36
   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>.
Top   ToC   RFC7368 - Page 37

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.
Top   ToC   RFC7368 - Page 38
   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.
Top   ToC   RFC7368 - Page 39
   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.
Top   ToC   RFC7368 - Page 40
   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.
Top   ToC   RFC7368 - Page 41
   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
Top   ToC   RFC7368 - Page 42
   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.
Top   ToC   RFC7368 - Page 43
   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
Top   ToC   RFC7368 - Page 44
   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>.
Top   ToC   RFC7368 - Page 45
   [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>.
Top   ToC   RFC7368 - Page 46
   [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>.
Top   ToC   RFC7368 - Page 47
   [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>.
Top   ToC   RFC7368 - Page 48

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.
Top   ToC   RFC7368 - Page 49

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