tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Glossaries     Architecture     IMS     UICC    |    search     info

RFC 7368

 
 
 

IPv6 Home Networking Architecture Principles

Part 3 of 3, p. 32 to 49
Prev RFC Part

 


prevText      Top      Up      ToC       Page 32 
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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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