Internet Engineering Task Force (IETF) T. Chown, Ed.
Request for Comments: 7368 University of Southampton
Category: Informational J. Arkko
ISSN: 2070-1721 Ericsson
A. Brandt
Sigma Designs
O. Troan
Cisco Systems, Inc.
J. Weil
Time Warner Cable
October 2014
Internet Engineering Task Force (IETF) T. Chown, Ed.
Request for Comments: 7368 University of Southampton
Category: Informational J. Arkko
ISSN: 2070-1721 Ericsson
A. Brandt
Sigma Designs
O. Troan
Cisco Systems, Inc.
J. Weil
Time Warner Cable
October 2014
IPv6 Home Networking Architecture Principles
IPv6家庭网络体系结构原理
Abstract
摘要
This text describes evolving networking technology within residential home networks with increasing numbers of devices and a trend towards increased internal routing. The goal of this document is to define a general architecture for IPv6-based home networking, describing the associated principles, considerations, and requirements. The text briefly highlights specific implications of the introduction of IPv6 for home networking, discusses the elements of the architecture, and suggests how standard IPv6 mechanisms and addressing can be employed in home networking. The architecture describes the need for specific protocol extensions for certain additional functionality. It is assumed that the IPv6 home network is not actively managed and runs as an IPv6-only or dual-stack network. There are no recommendations in this text for the IPv4 part of the network.
本文描述了随着设备数量的增加和内部路由的增加，住宅家庭网络中不断发展的网络技术。本文档的目标是定义基于IPv6的家庭网络的通用体系结构，描述相关的原则、注意事项和要求。本文简要强调了IPv6引入家庭网络的具体含义，讨论了体系结构的要素，并建议如何在家庭网络中使用标准IPv6机制和寻址。该体系结构描述了对特定附加功能的特定协议扩展的需求。假定IPv6家庭网络不是主动管理的，并作为仅IPv6或双栈网络运行。本文中没有关于网络IPv4部分的建议。
Status of This Memo
关于下段备忘
This document is not an Internet Standards Track specification; it is published for informational purposes.
本文件不是互联网标准跟踪规范；它是为了提供信息而发布的。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。并非IESG批准的所有文件都适用于任何级别的互联网标准；见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7368.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7368.
Copyright Notice
版权公告
Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2014 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Terminology and Abbreviations . . . . . . . . . . . . . . 5
2. Effects of IPv6 on Home Networking . . . . . . . . . . . . . 6
2.1. Multiple Subnets and Routers . . . . . . . . . . . . . . 7
2.2. Global Addressability and Elimination of NAT . . . . . . 8
2.3. Multi-Addressing of Devices . . . . . . . . . . . . . . . 8
2.4. Unique Local Addresses (ULAs) . . . . . . . . . . . . . . 9
2.5. Avoiding Manual Configuration of IP Addresses . . . . . . 10
2.6. IPv6-Only Operation . . . . . . . . . . . . . . . . . . . 11
3. Homenet Architecture Principles . . . . . . . . . . . . . . . 11
3.1. General Principles . . . . . . . . . . . . . . . . . . . 12
3.1.1. Reuse Existing Protocols . . . . . . . . . . . . . . 12
3.1.2. Minimise Changes to Hosts and Routers . . . . . . . . 13
3.2. Homenet Topology . . . . . . . . . . . . . . . . . . . . 13
3.2.1. Supporting Arbitrary Topologies . . . . . . . . . . . 13
3.2.2. Network Topology Models . . . . . . . . . . . . . . . 14
3.2.3. Dual-Stack Topologies . . . . . . . . . . . . . . . . 18
3.2.4. Multihoming . . . . . . . . . . . . . . . . . . . . . 19
3.2.5. Mobility Support . . . . . . . . . . . . . . . . . . 20
3.3. A Self-Organising Network . . . . . . . . . . . . . . . . 21
3.3.1. Differentiating Neighbouring Homenets . . . . . . . . 21
3.3.2. Largest Practical Subnets . . . . . . . . . . . . . . 21
3.3.3. Handling Varying Link Technologies . . . . . . . . . 22
3.3.4. Homenet Realms and Borders . . . . . . . . . . . . . 22
3.3.5. Configuration Information from the ISP . . . . . . . 23
3.4. Homenet Addressing . . . . . . . . . . . . . . . . . . . 24
3.4.1. Use of ISP-Delegated IPv6 Prefixes . . . . . . . . . 24
3.4.2. Stable Internal IP Addresses . . . . . . . . . . . . 26
3.4.3. Internal Prefix Delegation . . . . . . . . . . . . . 27
3.4.4. Coordination of Configuration Information . . . . . . 28
3.4.5. Privacy . . . . . . . . . . . . . . . . . . . . . . . 28
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Terminology and Abbreviations . . . . . . . . . . . . . . 5
2. Effects of IPv6 on Home Networking . . . . . . . . . . . . . 6
2.1. Multiple Subnets and Routers . . . . . . . . . . . . . . 7
2.2. Global Addressability and Elimination of NAT . . . . . . 8
2.3. Multi-Addressing of Devices . . . . . . . . . . . . . . . 8
2.4. Unique Local Addresses (ULAs) . . . . . . . . . . . . . . 9
2.5. Avoiding Manual Configuration of IP Addresses . . . . . . 10
2.6. IPv6-Only Operation . . . . . . . . . . . . . . . . . . . 11
3. Homenet Architecture Principles . . . . . . . . . . . . . . . 11
3.1. General Principles . . . . . . . . . . . . . . . . . . . 12
3.1.1. Reuse Existing Protocols . . . . . . . . . . . . . . 12
3.1.2. Minimise Changes to Hosts and Routers . . . . . . . . 13
3.2. Homenet Topology . . . . . . . . . . . . . . . . . . . . 13
3.2.1. Supporting Arbitrary Topologies . . . . . . . . . . . 13
3.2.2. Network Topology Models . . . . . . . . . . . . . . . 14
3.2.3. Dual-Stack Topologies . . . . . . . . . . . . . . . . 18
3.2.4. Multihoming . . . . . . . . . . . . . . . . . . . . . 19
3.2.5. Mobility Support . . . . . . . . . . . . . . . . . . 20
3.3. A Self-Organising Network . . . . . . . . . . . . . . . . 21
3.3.1. Differentiating Neighbouring Homenets . . . . . . . . 21
3.3.2. Largest Practical Subnets . . . . . . . . . . . . . . 21
3.3.3. Handling Varying Link Technologies . . . . . . . . . 22
3.3.4. Homenet Realms and Borders . . . . . . . . . . . . . 22
3.3.5. Configuration Information from the ISP . . . . . . . 23
3.4. Homenet Addressing . . . . . . . . . . . . . . . . . . . 24
3.4.1. Use of ISP-Delegated IPv6 Prefixes . . . . . . . . . 24
3.4.2. Stable Internal IP Addresses . . . . . . . . . . . . 26
3.4.3. Internal Prefix Delegation . . . . . . . . . . . . . 27
3.4.4. Coordination of Configuration Information . . . . . . 28
3.4.5. Privacy . . . . . . . . . . . . . . . . . . . . . . . 28
3.5. Routing Functionality . . . . . . . . . . . . . . . . . . 28
3.5.1. Unicast Routing within the Homenet . . . . . . . . . 30
3.5.2. Unicast Routing at the Homenet Border . . . . . . . . 31
3.5.3. Multicast Support . . . . . . . . . . . . . . . . . . 31
3.6. Security . . . . . . . . . . . . . . . . . . . . . . . . 32
3.6.1. Addressability vs. Reachability . . . . . . . . . . . 32
3.6.2. Filtering at Borders . . . . . . . . . . . . . . . . 33
3.6.3. Partial Effectiveness of NAT and Firewalls . . . . . 34
3.6.4. Exfiltration Concerns . . . . . . . . . . . . . . . . 34
3.6.5. Device Capabilities . . . . . . . . . . . . . . . . . 34
3.6.6. ULAs as a Hint of Connection Origin . . . . . . . . . 35
3.7. Naming and Service Discovery . . . . . . . . . . . . . . 35
3.7.1. Discovering Services . . . . . . . . . . . . . . . . 35
3.7.2. Assigning Names to Devices . . . . . . . . . . . . . 36
3.7.3. The Homenet Name Service . . . . . . . . . . . . . . 37
3.7.4. Name Spaces . . . . . . . . . . . . . . . . . . . . . 38
3.7.5. Independent Operation . . . . . . . . . . . . . . . . 40
3.7.6. Considerations for LLNs . . . . . . . . . . . . . . . 40
3.7.7. DNS Resolver Discovery . . . . . . . . . . . . . . . 41
3.7.8. Devices Roaming to/from the Homenet . . . . . . . . . 41
3.8. Other Considerations . . . . . . . . . . . . . . . . . . 41
3.8.1. Quality of Service . . . . . . . . . . . . . . . . . 41
3.8.2. Operations and Management . . . . . . . . . . . . . . 42
3.9. Implementing the Architecture on IPv6 . . . . . . . . . . 43
4. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 44
5. Security Considerations . . . . . . . . . . . . . . . . . . . 44
6. References . . . . . . . . . . . . . . . . . . . . . . . . . 44
6.1. Normative References . . . . . . . . . . . . . . . . . . 44
6.2. Informative References . . . . . . . . . . . . . . . . . 44
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 48
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 49
3.5. Routing Functionality . . . . . . . . . . . . . . . . . . 28
3.5.1. Unicast Routing within the Homenet . . . . . . . . . 30
3.5.2. Unicast Routing at the Homenet Border . . . . . . . . 31
3.5.3. Multicast Support . . . . . . . . . . . . . . . . . . 31
3.6. Security . . . . . . . . . . . . . . . . . . . . . . . . 32
3.6.1. Addressability vs. Reachability . . . . . . . . . . . 32
3.6.2. Filtering at Borders . . . . . . . . . . . . . . . . 33
3.6.3. Partial Effectiveness of NAT and Firewalls . . . . . 34
3.6.4. Exfiltration Concerns . . . . . . . . . . . . . . . . 34
3.6.5. Device Capabilities . . . . . . . . . . . . . . . . . 34
3.6.6. ULAs as a Hint of Connection Origin . . . . . . . . . 35
3.7. Naming and Service Discovery . . . . . . . . . . . . . . 35
3.7.1. Discovering Services . . . . . . . . . . . . . . . . 35
3.7.2. Assigning Names to Devices . . . . . . . . . . . . . 36
3.7.3. The Homenet Name Service . . . . . . . . . . . . . . 37
3.7.4. Name Spaces . . . . . . . . . . . . . . . . . . . . . 38
3.7.5. Independent Operation . . . . . . . . . . . . . . . . 40
3.7.6. Considerations for LLNs . . . . . . . . . . . . . . . 40
3.7.7. DNS Resolver Discovery . . . . . . . . . . . . . . . 41
3.7.8. Devices Roaming to/from the Homenet . . . . . . . . . 41
3.8. Other Considerations . . . . . . . . . . . . . . . . . . 41
3.8.1. Quality of Service . . . . . . . . . . . . . . . . . 41
3.8.2. Operations and Management . . . . . . . . . . . . . . 42
3.9. Implementing the Architecture on IPv6 . . . . . . . . . . 43
4. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 44
5. Security Considerations . . . . . . . . . . . . . . . . . . . 44
6. References . . . . . . . . . . . . . . . . . . . . . . . . . 44
6.1. Normative References . . . . . . . . . . . . . . . . . . 44
6.2. Informative References . . . . . . . . . . . . . . . . . 44
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 48
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 49
This document focuses on evolving networking technology within residential home networks with increasing numbers of devices and a trend towards increased internal routing, as well as the associated challenges with their deployment and operation. There is a growing trend in home networking for the proliferation of networking technology through an increasingly broad range of devices and media. This evolution in scale and diversity sets requirements on IETF protocols. Some of these requirements relate to the introduction of IPv6, while others relate to the introduction of specialised networks for home automation and sensors.
本文档重点介绍随着设备数量的增加和内部路由增加的趋势，住宅家庭网络中不断发展的网络技术，以及与它们的部署和操作相关的挑战。随着网络技术通过越来越广泛的设备和媒体的普及，家庭网络的发展趋势越来越明显。这种规模和多样性的演变对IETF协议提出了要求。其中一些要求与IPv6的引入有关，而另一些要求与家庭自动化和传感器专用网络的引入有关。
While at the time of writing some complex home network topologies exist, most are relatively simple single subnet networks and ostensibly operate using just IPv4. While there may be IPv6 traffic within the network, e.g., for service discovery, the homenet is provisioned by the ISP as an IPv4 network. Such networks also typically employ solutions that should be avoided, such as private [RFC1918] addressing with (cascaded) Network Address Translation (NAT) [RFC3022], or they may require expert assistance to set up.
虽然在撰写本文时存在一些复杂的家庭网络拓扑，但大多数都是相对简单的单子网网络，表面上仅使用IPv4进行操作。虽然网络中可能存在IPv6通信量，例如用于服务发现，但家庭网络由ISP提供为IPv4网络。此类网络通常还采用应避免的解决方案，如带有（级联）网络地址转换（NAT）的专用[RFC1918]寻址[RFC3022]，或者可能需要专家协助进行设置。
In contrast, emerging IPv6-capable home networks are very likely to have multiple internal subnets, e.g., to facilitate private and guest networks, heterogeneous link layers, and smart grid components, and have enough address space available to allow every device to have a globally unique address. This implies that internal routing functionality is required, and that the homenet's ISP delegates a large enough address block, to allow assignment of a prefix to each subnet in the home network.
相比之下，新兴的支持IPv6的家庭网络很可能具有多个内部子网，例如，用于促进专用和来宾网络、异构链路层和智能电网组件，并且具有足够的可用地址空间，以允许每个设备具有全球唯一的地址。这意味着需要内部路由功能，并且家庭网络的ISP委托足够大的地址块，以便为家庭网络中的每个子网分配前缀。
It is not practical to expect home users to configure their networks. Thus, the assumption of this document is that the homenet is as far as possible self-organising and self-configuring, i.e., it should function without proactive management by the residential user.
期望家庭用户配置他们的网络是不现实的。因此，本文件的假设是，家庭网络尽可能是自组织和自配置的，也就是说，它应该在没有住宅用户主动管理的情况下运行。
The architectural constructs in this document are focused on the problems to be solved when introducing IPv6, with an eye towards a better result than what we have today with IPv4, as well as aiming for a more consistent solution that addresses as many of the identified requirements as possible. This document aims to provide the basis and guiding principles for how standard IPv6 mechanisms and addressing [RFC2460] [RFC4291] can be employed in home networking, while coexisting with existing IPv4 mechanisms. In emerging dual-stack home networks, it is vital that introducing IPv6 does not adversely affect IPv4 operation. We assume that the IPv4 network architecture in home networks is what it is and cannot be modified by new recommendations. This document does not discuss how IPv4 home
本文档中的体系结构结构关注引入IPv6时要解决的问题，着眼于比我们今天使用IPv4时获得更好的结果，并旨在找到一个更一致的解决方案，尽可能多地满足已确定的需求。本文件旨在为标准IPv6机制和寻址[RFC2460][RFC4291]如何在家庭网络中与现有IPv4机制共存提供基础和指导原则。在新兴的双栈家庭网络中，引入IPv6不会对IPv4操作产生不利影响至关重要。我们假设家庭网络中的IPv4网络体系结构就是这样，不能被新的建议修改。本文档不讨论如何使用IPv4 home
networks provision or deliver support for multiple subnets. It should not be assumed that any future new functionality created with IPv6 in mind will be backward compatible to include IPv4 support. Further, future deployments, or specific subnets within an otherwise dual-stack home network, may be IPv6-only, in which case considerations for IPv4 impact would not apply.
网络为多个子网提供或提供支持。我们不应该假设，将来使用IPv6创建的任何新功能都将向后兼容，以包括IPv4支持。此外，未来的部署或双栈家庭网络中的特定子网可能仅为IPv6，在这种情况下，IPv4影响的考虑因素将不适用。
This document proposes a baseline homenet architecture, using protocols and implementations that are as far as possible proven and robust. The scope of the document is primarily the network-layer technologies that provide the basic functionality to enable addressing, connectivity, routing, naming, and service discovery. While it may, for example, state that homenet components must be simple to deploy and use, it does not discuss specific user interfaces, nor does it discuss specific physical, wireless, or data-link-layer considerations. Likewise, we also do not specify the whole design of a homenet router from top to bottom; rather, we focus on the Layer 3 aspects. This means that Layer 2 is largely out of scope, we're assuming a data-link layer that supports IPv6 is present, and we react accordingly. Any IPv6-over-Foo definitions occur elsewhere.
本文档提出了一个基准homenet体系结构，使用的协议和实现尽可能经验证且健壮。本文档的范围主要是网络层技术，这些技术提供了实现寻址、连接、路由、命名和服务发现的基本功能。例如，虽然它可能声明homenet组件必须易于部署和使用，但它没有讨论特定的用户界面，也没有讨论特定的物理、无线或数据链路层注意事项。同样，我们也没有从上到下详细说明家庭网络路由器的整体设计；相反，我们将重点放在第3层方面。这意味着第2层在很大程度上超出了范围，我们假设存在支持IPv6的数据链路层，并做出相应的反应。任何IPv6 over Foo定义都会出现在其他地方。
[RFC7084], which has obsoleted [RFC6204], defines basic requirements for Customer Edge (CE) routers. The update includes the definition of requirements for specific transition tools on the CE router, specifically Dual-Stack Lite (DS-Lite) [RFC6333] and IPv6 Rapid Deployment on IPv4 Infrastructures (6rd) [RFC5969]. Such detailed specification of CE router devices is considered out of scope of this architecture document, and we assume that any required update of the CE router device specification as a result of adopting this architecture will be handled as separate and specific updates to these existing documents. Further, the scope of this text is the internal homenet, and thus specific features on the WAN side of the CE router are out of scope for this text.
已淘汰[RFC6204]的[RFC7084]定义了客户边缘（CE）路由器的基本要求。更新包括对CE路由器上特定转换工具需求的定义，特别是双栈Lite（DS Lite）[RFC6333]和IPv4基础设施上的IPv6快速部署（6rd）[RFC5969]。CE路由器设备的此类详细规范不在本体系结构文件的范围内，我们假设，由于采用该体系结构，CE路由器设备规范的任何必要更新将作为对这些现有文件的单独和特定更新处理。此外，本文的范围是内部homenet，因此CE路由器WAN端的特定功能超出了本文的范围。
In this section, we define terminology and abbreviations used throughout the text.
在本节中，我们将定义全文中使用的术语和缩写。
o Border: A point, typically resident on a router, between two networks, e.g., between the main internal homenet and a guest network. This defines a point(s) at which filtering and forwarding policies for different types of traffic may be applied.
o 边界：两个网络之间的一个点，通常位于路由器上，例如，主内部家庭网络和客户网络之间。这定义了一个点，在该点上可以应用不同类型流量的过滤和转发策略。
o CE router: Customer Edge router. A border router intended for use in a homenet. A CE router connects the homenet to a service provider network.
o CE路由器：客户边缘路由器。用于家庭网络的边界路由器。CE路由器将家庭网络连接到服务提供商网络。
o FQDN: Fully Qualified Domain Name. A globally unique name.
o FQDN：完全限定的域名。全局唯一的名称。
o Guest network: A part of the home network intended for use by visitors or guests to the home(net). Devices on the guest network may typically not see or be able to use all services in the home(net).
o 访客网络：家庭网络的一部分，供访客或访客使用。来宾网络上的设备通常可能看不到或无法使用家庭（网络）中的所有服务。
o Homenet: A home network, comprising host and router equipment, with one or more CE routers providing connectivity to a service provider network(s).
o 家庭网络：家庭网络，包括主机和路由器设备，一个或多个CE路由器提供与服务提供商网络的连接。
o ISP: Internet Service Provider. An entity that provides access to the Internet. In this document, a service provider specifically offers Internet access using IPv6 and may also offer IPv4 Internet access. The service provider can provide such access over a variety of different transport methods such as DSL, cable, wireless, and others.
o ISP：互联网服务提供商。提供互联网接入的实体。在本文档中，服务提供商专门提供使用IPv6的Internet访问，也可以提供IPv4 Internet访问。服务提供商可以通过各种不同的传输方法（例如DSL、有线、无线等）提供这种访问。
o LLN: Low-power and Lossy Network.
o LLN：低功耗和有损网络。
o LQDN: Locally Qualified Domain Name. A name local to the homenet.
o LQDN：本地限定域名。家庭网络的本地名称。
o NAT: Network Address Translation. Typically referring to IPv4 Network Address Port Translation (NAPT) [RFC3022].
o NAT：网络地址转换。通常指IPv4网络地址端口转换（NAPT）[RFC3022]。
o NPTv6: IPv6-to-IPv6 Network Prefix Translation [RFC6296].
o NPTv6:IPv6到IPv6网络前缀转换[RFC6296]。
o PCP: Port Control Protocol [RFC6887].
o 端口控制协议[RFC6887]。
o Realm: A network delimited by a defined border. A guest network within a homenet may form one realm.
o 领域：由定义的边界分隔的网络。家庭网络中的来宾网络可以形成一个领域。
o 'Simple Security': Defined in [RFC4864] and expanded further in [RFC6092]; describes recommended perimeter security capabilities for IPv6 networks.
o “简单安全性”：在[RFC4864]中定义，并在[RFC6092]中进一步扩展；介绍IPv6网络的推荐外围安全功能。
o ULA: IPv6 Unique Local Address [RFC4193].
o ULA:IPv6唯一本地地址[RFC4193]。
o VM: Virtual Machine.
o 虚拟机：虚拟机。
While IPv6 resembles IPv4 in many ways, there are some notable differences in the way it may typically be deployed. It changes address allocation principles, making multi-addressing the norm, and through the vastly increased address space, it allows globally unique IP addresses to be used for all devices in a home network. This section presents an overview of some of the key implications of the
虽然IPv6在许多方面与IPv4相似，但在通常的部署方式上存在一些显著的差异。它改变了地址分配原则，使多寻址成为常态，并通过大幅增加的地址空间，允许家庭网络中的所有设备使用全局唯一的IP地址。本节概述了
introduction of IPv6 for home networking that are simultaneously both promising and problematic.
为家庭网络引入IPv6既有希望又有问题。
While simple Layer 3 topologies involving as few subnets as possible are preferred in home networks, the incorporation of dedicated (routed) subnets remains necessary for a variety of reasons. For instance, an increasingly common feature in modern home routers is the ability to support both guest and private network subnets. Likewise, there may be a need to separate home automation or corporate extension LANs (whereby a home worker can have their corporate network extended into the home using a virtual private network, commonly presented as one port on an Ethernet device) from the main Internet access network, or different subnets may in general be associated with parts of the homenet that have different routing and security policies. Further, link-layer networking technology is poised to become more heterogeneous as networks begin to employ both traditional Ethernet technology and link layers designed for Low-power and Lossy Networks (LLNs), such as those used for certain types of sensor devices. Constraining the flow of certain traffic from Ethernet links to links of much lower capacity thus becomes an important topic.
虽然在家庭网络中首选涉及尽可能少的子网的简单第3层拓扑，但出于各种原因，合并专用（路由）子网仍然是必要的。例如，在现代家庭路由器中，一个越来越常见的功能是能够同时支持来宾和专用网络子网。类似地，可能需要将家庭自动化或公司扩展LAN（家庭工作者可以使用虚拟专用网络将其公司网络扩展到家庭，通常显示为以太网设备上的一个端口）与主互联网接入网络分离，或者，不同的子网通常可能与家庭网络中具有不同路由和安全策略的部分相关联。此外，随着网络开始采用传统以太网技术和为低功耗和有损网络（LLN）设计的链路层，例如用于某些类型传感器设备的链路层，链路层网络技术将变得更加异构。因此，限制从以太网链路到低容量链路的特定流量成为一个重要的话题。
The introduction of IPv6 for home networking makes it possible for every home network to be delegated enough address space from its ISP to provision globally unique prefixes for each such subnet in the home. While the number of addresses in a standard /64 IPv6 prefix is practically unlimited, the number of prefixes available for assignment to the home network is not. As a result, the growth inhibitor for the home network shifts from the number of addresses to the number of prefixes offered by the provider; this topic is discussed in BCP 157 [RFC6177], which recommends that "end sites always be able to obtain a reasonable amount of address space for their actual and planned usage."
为家庭网络引入IPv6使每个家庭网络都有可能从其ISP获得足够的地址空间，以便为家庭中的每个这样的子网提供全局唯一的前缀。虽然标准/64 IPv6前缀中的地址数量实际上是无限的，但可分配给家庭网络的前缀数量却不是无限的。结果，家庭网络的增长抑制器从地址的数量转移到提供商提供的前缀的数量；BCP 157[RFC6177]中讨论了该主题，该主题建议“终端站点始终能够为其实际和计划使用获得合理数量的地址空间。”
The addition of routing between subnets raises a number of issues. One is a method by which prefixes can be efficiently allocated to each subnet, without user intervention. Another issue is how to extend mechanisms such as zero-configuration service discovery that currently only operate within a single subnet using link-local traffic. In a typical IPv4 home network, there is only one subnet, so such mechanisms would normally operate as expected. For multi-subnet IPv6 home networks, there are two broad choices to enable such protocols to work across the scope of the entire homenet: extend existing protocols to work across that scope or introduce proxies for existing link-layer protocols. This topic is discussed in Section 3.7.
在子网之间添加路由引起了许多问题。一种方法是在不需要用户干预的情况下，将前缀有效地分配给每个子网。另一个问题是如何扩展诸如零配置服务发现之类的机制，这些机制目前仅使用链路本地流量在单个子网内运行。在典型的IPv4家庭网络中，只有一个子网，因此此类机制通常会按预期运行。对于多子网IPv6家庭网络，有两种广泛的选择可以使此类协议在整个家庭网络范围内工作：扩展现有协议以在该范围内工作，或为现有链路层协议引入代理。本主题将在第3.7节中讨论。
The possibility for direct end-to-end communication on the Internet to be restored by the introduction of IPv6 is, on the one hand, an incredible opportunity for innovation and simpler network operation, but on the other hand, it is also a concern as it potentially exposes nodes in the internal networks to receipt of unwanted and possibly malicious traffic from the Internet.
通过引入IPv6恢复互联网上的直接端到端通信的可能性，一方面是创新和简化网络操作的绝佳机会，但另一方面，这也是一个值得关注的问题，因为它可能会使内部网络中的节点接收到来自Internet的不需要的、可能是恶意的流量。
With devices and applications able to talk directly to each other when they have globally unique addresses, there may be an expectation of improved host security to compensate for this. It should be noted that many devices may (for example) ship with default settings that make them readily vulnerable to compromise by external attackers if globally accessible, or they may simply not be robust by design because it was assumed that either such devices would only be used on private networks or the devices don't have the computing power to apply the necessary security methods. In addition, the upgrade cycle for devices (or their firmware) may be slow and/or lack auto-update mechanisms.
当设备和应用程序具有全局唯一地址时，它们能够直接相互通信，因此可能需要改进主机安全性来弥补这一缺陷。需要注意的是，许多设备可能（例如）附带默认设置，使其在全局可访问的情况下容易受到外部攻击者的攻击，或者，它们在设计上可能根本不可靠，因为假设这些设备只能在专用网络上使用，或者这些设备不具备应用必要安全方法的计算能力。此外，设备（或其固件）的升级周期可能较慢和/或缺乏自动更新机制。
It is thus important to distinguish between addressability and reachability. While IPv6 offers global addressability through the use of globally unique addresses in the home, whether devices are globally reachable or not would depend on any firewall or filtering configuration, and not, as is commonly the case with IPv4, the presence or use of NAT. In this respect, IPv6 networks may or may not have filters applied at their borders to control such traffic, i.e., at the homenet CE router. [RFC4864] and [RFC6092] discuss such filtering and the merits of 'default allow' against 'default deny' policies for external traffic initiated into a homenet. This topic is discussed further in Section 3.6.1.
因此，区分可寻址性和可达性很重要。虽然IPv6通过在家庭中使用全局唯一地址提供全局可寻址性，但设备是否可全局访问取决于任何防火墙或过滤配置，而不像IPv4那样，取决于NAT的存在或使用。在这方面，IPv6网络可以或不可以在其边界处应用过滤器来控制此类流量，即在homenet CE路由器处。[RFC4864]和[RFC6092]讨论了此类过滤，以及针对启动到家庭网络的外部流量的“默认允许”和“默认拒绝”策略的优点。本主题将在第3.6.1节中进一步讨论。
In an IPv6 network, devices will often acquire multiple addresses, typically at least a link-local address and one or more globally unique addresses (GUAs). Where a homenet is multihomed, a device would typically receive a GUA from within the delegated prefix from each upstream ISP. Devices may also have an IPv4 address if the network is dual stack, an IPv6 Unique Local Address (ULA) [RFC4193] (see below), and one or more IPv6 privacy addresses [RFC4941].
在IPv6网络中，设备通常会获取多个地址，通常至少是一个链路本地地址和一个或多个全局唯一地址（GUA）。如果家庭网络是多址的，则设备通常会从每个上游ISP的委派前缀中接收到一个GUA。如果网络为双栈，则设备还可能具有IPv4地址、IPv6唯一本地地址（ULA）[RFC4193]（见下文）和一个或多个IPv6隐私地址[RFC4941]。
It should thus be considered the norm for devices on IPv6 home networks to be multi-addressed and to need to make appropriate address selection decisions for the candidate source and destination address pairs for any given connection. In multihoming scenarios, nodes will be configured with one address from each upstream ISP
因此，应将IPv6家庭网络上的设备视为多地址的标准，并需要为任何给定连接的候选源地址对和目标地址对做出适当的地址选择决策。在多主场景中，节点将配置来自每个上游ISP的一个地址
prefix. In such cases, the presence of upstream ingress filtering as described in BCP 38 [RFC2827] requires such multi-addressed nodes to select the correct source address to be used for the corresponding uplink. Default address selection for IPv6 [RFC6724] provides a solution for this, but a challenge here is that the node may not have the information it needs to make that decision based on addresses alone. We discuss this challenge in Section 3.2.4.
前缀在这种情况下，如BCP 38[RFC2827]中所述的上游入口过滤的存在要求这种多寻址节点选择用于相应上行链路的正确源地址。IPv6的默认地址选择[RFC6724]为此提供了一个解决方案，但这里的一个挑战是节点可能不具备仅基于地址做出决策所需的信息。我们将在第3.2.4节中讨论这一挑战。
[RFC4193] defines ULAs for IPv6 that may be used to address devices within the scope of a single site. Support for ULAs for IPv6 CE routers is described in [RFC7084]. A home network running IPv6 should deploy ULAs alongside its globally unique prefix(es) to allow stable communication between devices (on different subnets) within the homenet where that externally allocated globally unique prefix may change over time, e.g., due to renumbering within the subscriber's ISP, or where external connectivity may be temporarily unavailable. A homenet using provider-assigned global addresses is exposed to its ISP renumbering the network to a much larger degree than before whereas, for IPv4, NAT isolated the user against ISP renumbering to some extent.
[RFC4193]定义了IPv6的ULA，这些ULA可用于寻址单个站点范围内的设备。[RFC7084]中描述了对IPv6 CE路由器的ULA的支持。运行IPv6的家庭网络应在其全局唯一前缀旁边部署ULA，以允许家庭网络内（不同子网上）设备之间的稳定通信，其中外部分配的全局唯一前缀可能会随时间而变化，例如，由于在订户的ISP内重新编号，或者外部连接可能暂时不可用。使用提供商分配的全局地址的家庭网络暴露给其ISP，使网络重新编号的程度比以前大得多，而对于IPv4，NAT在某种程度上隔离了用户与ISP的重新编号。
While setting up a network, there may be a period where it has no external connectivity, in which case ULAs would be required for inter-subnet communication. In the case where home automation networks are being set up in a new home/deployment (as early as during construction of the home), such networks will likely need to use their own /48 ULA prefix. Depending upon circumstances beyond the control of the owner of the homenet, it may be impossible to renumber the ULA used by the home automation network so routing between ULA /48s may be required. Also, some devices, particularly constrained devices, may have only a ULA (in addition to a link-local), while others may have both a GUA and a ULA.
设置网络时，可能会有一段时间网络没有外部连接，在这种情况下，子网间通信需要ULAs。如果家庭自动化网络正在新家庭/部署中建立（最早在家庭建设期间），则此类网络可能需要使用自己的/48 ULA前缀。根据家庭网络所有者无法控制的情况，可能无法对家庭自动化网络使用的ULA重新编号，因此可能需要ULA/48之间的路由。此外，一些设备，特别是受约束的设备，可能只有一个ULA（除了本地链路之外），而其他设备可能同时有一个GUA和一个ULA。
Note that unlike private IPv4 space as described in RFC 1918, the use of ULAs does not imply use of an IPv6 equivalent of a traditional IPv4 NAT [RFC3022] or of NPTv6 prefix-based NAT [RFC6296]. When an IPv6 node in a homenet has both a ULA and a globally unique IPv6 address, it should only use its ULA address internally and use its additional globally unique IPv6 address as a source address for external communications. This should be the natural behaviour given support for default address selection for IPv6 [RFC6724]. By using such globally unique addresses between hosts and devices in remote networks, the architectural cost and complexity, particularly to applications, of NAT or NPTv6 translation are avoided. As such, neither IPv6 NAT nor NPTv6 is recommended for use in the homenet architecture. Further, the homenet border router(s) should filter
请注意，与RFC 1918中描述的专用IPv4空间不同，ULAs的使用并不意味着使用传统IPv4 NAT[RFC3022]或基于NPTv6前缀的NAT[RFC6296]的IPv6等效物。当家庭网络中的IPv6节点同时具有ULA和全局唯一IPv6地址时，它应仅在内部使用其ULA地址，并将其附加的全局唯一IPv6地址用作外部通信的源地址。这应该是支持IPv6默认地址选择的自然行为[RFC6724]。通过在远程网络中的主机和设备之间使用这种全局唯一地址，避免了NAT或NPTv6转换的体系结构成本和复杂性，特别是对应用程序而言。因此，不建议在homenet体系结构中使用IPv6 NAT或NPTv6。此外，homenet边界路由器应进行过滤
packets with ULA source/destination addresses as discussed in Section 3.4.2.
具有第3.4.2节中讨论的源/目的地址的数据包。
Devices in a homenet may be given only a ULA as a means to restrict reachability from outside the homenet. ULAs can be used by default for devices that, without additional configuration (e.g., via a web interface), would only offer services to the internal network. For example, a printer might only accept incoming connections on a ULA until configured to be globally reachable, at which point it acquires a global IPv6 address and may be advertised via a global name space.
家庭网络中的设备可能只提供一个ULA，作为限制家庭网络外部可访问性的一种手段。默认情况下，ULAs可用于无需额外配置（例如，通过web界面）就只能向内部网络提供服务的设备。例如，打印机可能只接受ULA上的传入连接，直到配置为全局可访问，此时它获取全局IPv6地址，并可通过全局名称空间进行播发。
Where both a ULA and a global prefix are in use, the ULA source address is used to communicate with ULA destination addresses when appropriate, i.e., when the ULA source and destination lie within the /48 ULA prefix(es) known to be used within the same homenet. In cases where multiple /48 ULA prefixes are in use within a single homenet (perhaps because multiple homenet routers each independently auto-generate a /48 ULA prefix and then share prefix/routing information), utilising a ULA source address and a ULA destination address from two disjoint internal ULA prefixes is preferable to using GUAs.
在同时使用ULA和全局前缀的情况下，在适当的情况下，即当ULA源和目标位于同一家庭网络中已知使用的/48 ULA前缀内时，使用ULA源地址与ULA目标地址通信。在单个家庭网络中使用多个/48 ULA前缀的情况下（可能是因为多个家庭网络路由器各自独立地自动生成/48 ULA前缀，然后共享前缀/路由信息），使用两个不相交的内部ULA前缀中的ULA源地址和ULA目的地地址比使用GUA更可取。
While a homenet should operate correctly with two or more /48 ULAs enabled, a mechanism for the creation and use of a single /48 ULA prefix is desirable for addressing consistency and policy enforcement.
虽然homenet应在启用两个或多个/48 ULA的情况下正常运行，但创建和使用单个/48 ULA前缀的机制对于解决一致性和策略实施是可取的。
A counter argument to using ULAs is that it is undesirable to aggressively deprecate global prefixes for temporary loss of connectivity, so for a host to lose its global address, there would have to be a connection breakage longer than the lease period, and even then, deprecating prefixes when there is no connectivity may not be advisable. However, it is assumed in this architecture that homenets should support and use ULAs.
使用ULAs的一个相反论点是，不希望为了暂时失去连接而积极地弃用全局前缀，因此对于主机来说，丢失其全局地址，连接中断的时间必须超过租赁期，即使如此，在没有连接的情况下弃用前缀也可能是不可取的。然而，在这种体系结构中，家庭网络应该支持并使用ULA。
Some IPv4 home networking devices expose IPv4 addresses to users, e.g., the IPv4 address of a home IPv4 CE router that may be configured via a web interface. In potentially complex future IPv6 homenets, users should not be expected to enter IPv6 literal addresses in devices or applications, given their much greater length and the apparent randomness of such addresses to a typical home user. Thus, even for the simplest of functions, simple naming and the associated (minimal, and ideally zero configuration) discovery of services are imperative for the easy deployment and use of homenet devices and applications.
一些IPv4家庭网络设备向用户公开IPv4地址，例如，可以通过web接口配置的家庭IPv4 CE路由器的IPv4地址。在潜在复杂的未来IPv6家庭网络中，不应期望用户在设备或应用程序中输入IPv6文本地址，因为这些地址的长度要长得多，而且对于典型的家庭用户来说，这些地址显然是随机的。因此，即使是最简单的功能，简单的命名和相关的服务发现（最小，理想情况下为零配置）对于homenet设备和应用程序的轻松部署和使用也是必不可少的。
It is likely that IPv6-only networking will be deployed first in new home network deployments, often referred to as 'greenfield' scenarios, where there is no existing IPv4 capability, or perhaps as one element of an otherwise dual-stack network. Running IPv6-only adds additional requirements, e.g., for devices to get configuration information via IPv6 transport (not relying on an IPv4 protocol such as IPv4 DHCP) and for devices to be able to initiate communications to external devices that are IPv4-only.
在新的家庭网络部署（通常称为“绿地”场景）中，可能会首先部署仅限IPv6的网络，在这种场景中，没有现有的IPv4功能，或者可能作为双栈网络的一个元素。运行IPv6只会增加额外的要求，例如，设备通过IPv6传输获取配置信息（不依赖IPv4协议，如IPv4 DHCP）以及设备能够启动与仅IPv4的外部设备的通信。
Some specific transition technologies that may be deployed by the homenet's ISP are discussed in [RFC7084]. In addition, certain other functions may be desirable on the CE router, e.g., to access content in the IPv4 Internet, NAT64 [RFC6144] and DNS64 [RFC6145] may be applicable.
[RFC7084]中讨论了homenet的ISP可能部署的一些特定过渡技术。此外，CE路由器上可能需要某些其他功能，例如，访问IPv4因特网中的内容，NAT64[RFC6144]和DNS64[RFC6145]可能适用。
The widespread availability of robust solutions to these types of requirements will help accelerate the uptake of IPv6-only homenets. The specifics of these are, however, beyond the scope of this document, especially those functions that reside on the CE router.
针对这些类型需求的强健解决方案的广泛可用性将有助于加快只采用IPv6的家庭网络的普及。但是，这些功能的细节超出了本文档的范围，尤其是驻留在CE路由器上的功能。
The aim of this text is to outline how to construct advanced IPv6- based home networks involving multiple routers and subnets using standard IPv6 addressing and protocols [RFC2460] [RFC4291] as the basis. As described in Section 3.1, solutions should as far as possible reuse existing protocols and minimise changes to hosts and routers, but some new protocols or extensions are likely to be required. In this section, we present the elements of the proposed home networking architecture with discussion of the associated design principles.
本文的目的是概述如何以标准IPv6寻址和协议[RFC2460][RFC4291]为基础，构建包含多个路由器和子网的基于IPv6的高级家庭网络。如第3.1节所述，解决方案应尽可能重用现有协议，并尽量减少对主机和路由器的更改，但可能需要一些新的协议或扩展。在本节中，我们将介绍拟议家庭网络体系结构的要素，并讨论相关的设计原则。
In general, home network equipment needs to be able to operate in networks with a range of different properties and topologies, where home users may plug components together in arbitrary ways and expect the resulting network to operate. Significant manual configuration is rarely, if at all, possible or even desirable given the knowledge level of typical home users. Thus, the network should, as far as possible, be self-configuring, though configuration by advanced users should not be precluded.
通常，家庭网络设备需要能够在具有一系列不同属性和拓扑的网络中运行，其中家庭用户可以以任意方式将组件插入到一起，并期望由此产生的网络能够运行。考虑到典型家庭用户的知识水平，重要的手动配置几乎是不可能的，甚至是可取的。因此，网络应尽可能自我配置，尽管不应排除高级用户的配置。
The homenet needs to be able to handle or provision at least the following:
homenet至少需要能够处理或提供以下内容：
o Routing
o 路由
o Prefix configuration for routers
o 路由器的前缀配置
o Name resolution
o 名称解析
o Service discovery
o 服务发现
o Network security
o 网络安全
The remainder of this document describes the principles by which the homenet architecture may deliver these properties.
本文档的其余部分描述了homenet体系结构交付这些属性所依据的原则。
There is little that the Internet standards community can do about the physical topologies or the need for some networks to be separated at the network layer for policy or link-layer compatibility reasons. However, there is a lot of flexibility in using IP addressing and internetworking mechanisms. This text discusses how such flexibility should be used to provide the best user experience and ensure that the network can evolve with new applications in the future. The principles described in this text should be followed when designing homenet protocol solutions.
对于物理拓扑或出于策略或链路层兼容性的原因在网络层分离某些网络的需要，互联网标准团体几乎无能为力。然而，在使用IP寻址和互联机制时有很大的灵活性。本文将讨论如何利用这种灵活性来提供最佳的用户体验，并确保网络能够在未来随着新的应用程序而发展。在设计homenet协议解决方案时，应遵循本文中描述的原则。
Existing protocols will be used to meet the requirements of home networks. Where necessary, extensions will be made to those protocols. When no existing protocol is found to be suitable, a new or emerging protocol may be used. Therefore, it is important that no design or architectural decisions be made that would preclude the use of new or emerging protocols.
现有协议将用于满足家庭网络的要求。必要时，将对这些协议进行扩展。当没有发现任何现有协议适用时，可以使用新的或新兴的协议。因此，重要的是，不得做出任何设计或体系结构决策，以排除使用新的或新兴的协议。
A generally conservative approach, giving weight to running (and available) code, is preferable. Where new protocols are required, evidence of commitment to implementation by appropriate vendors or development communities is highly desirable. Protocols used should be backward compatible and forward compatible where changes are made.
最好采用一种通常较为保守的方法，即重视正在运行（和可用）的代码。在需要新协议的情况下，适当供应商或开发社区承诺实施的证据是非常可取的。在进行更改时，使用的协议应该是向后兼容和向前兼容的。
In order to maximise the deployability of new homenets, any requirement for changes to hosts and routers should be minimised where possible; however, solutions that, for example, incrementally improve capability via host or router changes may be acceptable. There may be cases where changes are unavoidable, e.g., to allow a given homenet routing protocol to be self-configuring or to support routing based on source addresses in addition to destination addresses (to improve multihoming support, as discussed in Section 3.2.4).
为了最大限度地提高新家庭网络的部署能力，应尽可能减少对主机和路由器的任何更改要求；但是，例如，通过主机或路由器更改来逐步提高性能的解决方案是可以接受的。在某些情况下，更改是不可避免的，例如，允许给定的homenet路由协议进行自我配置，或支持基于源地址和目标地址的路由（如第3.2.4节所述，改进多归属支持）。
This section considers homenet topologies and the principles that may be applied in designing an architecture to support as wide a range of such topologies as possible.
本节将讨论homenet拓扑以及在设计架构时可能应用的原则，以支持尽可能广泛的此类拓扑。
There should ideally be no built-in assumptions about the topology in home networks, as users are capable of connecting their devices in 'ingenious' ways. Thus, arbitrary topologies and arbitrary routing will need to be supported, or at least the failure mode for when the user makes a mistake should be as robust as possible, e.g., deactivating a certain part of the infrastructure to allow the rest to operate. In such cases, the user should ideally have some useful indication of the failure mode encountered.
理想情况下，家庭网络中的拓扑结构不应存在内置假设，因为用户能够以“巧妙”的方式连接设备。因此，需要支持任意拓扑和任意路由，或者至少用户出错时的故障模式应尽可能可靠，例如，停用基础设施的某个部分以允许其余部分运行。在这种情况下，用户最好对遇到的故障模式有一些有用的指示。
There should be no topology scenarios that cause a loss of connectivity, except when the user creates a physical island within the topology. Some potentially pathological cases that can be created include bridging ports of a router together; however, this case can be detected and dealt with by the router. Loops within a routed topology are in a sense good in that they offer redundancy. Topologies that include potential bridging loops can be dangerous but are also detectable when a switch learns the Media Access Control (MAC) address of one of its interfaces on another or runs a spanning tree or link-state protocol. It is only topologies with such potential loops using simple repeaters that are truly pathological.
除非用户在拓扑中创建物理孤岛，否则不应存在导致连接丢失的拓扑方案。一些可能产生的病理病例包括将路由器的端口桥接在一起；但是，这种情况可以由路由器检测和处理。路由拓扑中的循环在某种意义上是好的，因为它们提供冗余。包含潜在桥接环路的拓扑可能很危险，但当交换机在另一个接口上学习其一个接口的媒体访问控制（MAC）地址或运行生成树或链路状态协议时，也可以检测到这种拓扑。只有使用简单中继器的具有这种潜在环路的拓扑才是真正病态的。
The topology of the homenet may change over time, due to the addition or removal of equipment but also due to temporary failures or connectivity problems. In some cases, this may lead to, for example, a multihomed homenet being split into two isolated homenets or, after such a fault is remedied, two isolated parts reconfiguring back to a single network.
家庭网络的拓扑结构可能会随着时间的推移而变化，这可能是由于添加或删除了设备，也可能是由于临时故障或连接问题。在某些情况下，这可能会导致，例如，多宿家庭网络被拆分为两个独立的家庭网络，或者，在修复此类故障后，两个独立的部分重新配置回单个网络。
As hinted above, while the architecture may focus on likely common topologies, it should not preclude any arbitrary topology from being constructed.
如上所述，虽然架构可能关注可能的公共拓扑，但不应排除任何任意拓扑的构建。
At the time of writing, most IPv4 home network models tend to be relatively simple, typically a single NAT router to the ISP and a single internal subnet but, as discussed earlier, evolution in network architectures is driving more complex topologies, such as the separation of guest and private networks. There may also be some cascaded IPv4 NAT scenarios, which we mention in the next section. For IPv6 homenets, the network architectures described in [RFC7084] should, as a minimum, be supported.
在撰写本文时，大多数IPv4家庭网络模型往往相对简单，通常是ISP的单个NAT路由器和单个内部子网，但如前所述，网络体系结构的演变正在推动更复杂的拓扑结构，如来宾网络和专用网络的分离。可能还有一些级联IPv4 NAT场景，我们将在下一节中提到。对于IPv6家庭网络，至少应支持[RFC7084]中描述的网络体系结构。
There are a number of properties or attributes of a home network that we can use to describe its topology and operation. The following properties apply to any IPv6 home network:
我们可以使用家庭网络的许多属性来描述其拓扑结构和操作。以下属性适用于任何IPv6家庭网络：
o Presence of internal routers. The homenet may have one or more internal routers or may only provide subnetting from interfaces on the CE router.
o 存在内部路由器。家庭网络可以有一个或多个内部路由器，或者只能从CE路由器上的接口提供子网。
o Presence of isolated internal subnets. There may be isolated internal subnets, with no direct connectivity between them within the homenet (with each having its own external connectivity). Isolation may be physical or implemented via IEEE 802.1q VLANs. The latter is, however, not something a typical user would be expected to configure.
o 存在孤立的内部子网。可能存在孤立的内部子网，它们之间在家庭网络中没有直接连接（每个子网都有自己的外部连接）。隔离可以是物理的，也可以通过IEEE 802.1q VLAN实现。然而，后者并不是一个典型用户需要配置的东西。
o Demarcation of the CE router. The CE router(s) may or may not be managed by the ISP. If the demarcation point is such that the customer can provide or manage the CE router, its configuration must be simple. Both models must be supported.
o CE路由器的划分。CE路由器可能由ISP管理，也可能不由ISP管理。如果分界点是客户可以提供或管理CE路由器，则其配置必须简单。这两种模式都必须得到支持。
Various forms of multihoming are likely to become more prevalent with IPv6 home networks, where the homenet may have two or more external ISP connections, as discussed further below. Thus, the following properties should also be considered for such networks:
各种形式的多宿可能在IPv6家庭网络中变得更加普遍，家庭网络可能有两个或多个外部ISP连接，如下所述。因此，此类网络还应考虑以下特性：
o Number of upstream providers. The majority of home networks today consist of a single upstream ISP, but it may become more common in the future for there to be multiple ISPs, whether for resilience or provision of additional services. Each would offer its own prefix. Some may or may not provide a default route to the public Internet.
o 上游供应商的数量。如今，大多数家庭网络都由一个上游ISP组成，但将来可能会出现多个ISP，无论是为了恢复能力还是提供额外服务。每个都会提供自己的前缀。有些可能会也可能不会提供到公共互联网的默认路由。
o Number of CE routers. The homenet may have a single CE router, which might be used for one or more providers, or multiple CE routers. The presence of multiple CE routers adds additional complexity for multihoming scenarios and protocols like PCP that may need to manage connection-oriented state mappings on the same CE router as used for subsequent traffic flows.
o CE路由器的数量。家庭网络可能有一个CE路由器，可用于一个或多个提供商，或多个CE路由器。多个CE路由器的存在增加了多归属场景和协议（如PCP）的额外复杂性，这些场景和协议可能需要在用于后续通信流的同一CE路由器上管理面向连接的状态映射。
In the following sections, we give some examples of the types of homenet topologies we may see in the future. This is not intended to be an exhaustive or complete list but rather an indicative one to facilitate the discussion in this text.
在以下部分中，我们将给出一些我们将来可能看到的家庭网络拓扑类型的示例。这并不是一份详尽或完整的清单，而是一份指示性清单，以便于在本文中进行讨论。
Figure 1 shows a home network with multiple local area networks. These may be needed for reasons relating to different link-layer technologies in use or for policy reasons, e.g., classic Ethernet in one subnet and an LLN link-layer technology in another. In this example, there is no single router that a priori understands the entire topology. The topology itself may also be complex, and it may not be possible to assume a pure tree form, for instance (because home users may plug routers together to form arbitrary topologies, including those with potential loops in them).
图1显示了具有多个局域网的家庭网络。由于与使用中的不同链路层技术相关的原因或出于政策原因，例如，一个子网中的经典以太网和另一个子网中的LLN链路层技术，可能需要这些技术。在本例中，没有一个路由器能够先验地理解整个拓扑结构。拓扑本身也可能很复杂，例如，可能不可能采用纯树形式（因为家庭用户可能将路由器插在一起形成任意拓扑，包括那些具有潜在环路的路由器）。
+-------+-------+ \
| Service | \
| Provider | | Service
| Router | | Provider
+-------+-------+ | Network
| /
| Customer /
| Internet Connection
|
+------+--------+ \
| IPv6 | \
| Customer Edge | \
| Router | |
+----+-+---+----+ |
Network A | | | Network B(E) |
----+-------------+----+ | +---+-------------+------+ |
| | | | | | |
+----+-----+ +-----+----+ | +----+-----+ +-----+----+ | |
|IPv6 Host | |IPv6 Host | | | IPv6 Host| |IPv6 Host | | |
| H1 | | H2 | | | H3 | | H4 | | |
+----------+ +----------+ | +----------+ +----------+ | |
| | | | |
Link F | ---+------+------+-----+ |
| | Network E(B) |
+------+--------+ | | End-User
| IPv6 | | | Networks
| Interior +------+ |
| Router | |
+---+-------+-+-+ |
Network C | | Network D |
----+-------------+---+ +---+-------------+--- |
| | | | |
+----+-----+ +-----+----+ +----+-----+ +-----+----+ |
|IPv6 Host | |IPv6 Host | | IPv6 Host| |IPv6 Host | |
| H5 | | H6 | | H7 | | H8 | /
+----------+ +----------+ +----------+ +----------+ /
+-------+-------+ \
| Service | \
| Provider | | Service
| Router | | Provider
+-------+-------+ | Network
| /
| Customer /
| Internet Connection
|
+------+--------+ \
| IPv6 | \
| Customer Edge | \
| Router | |
+----+-+---+----+ |
Network A | | | Network B(E) |
----+-------------+----+ | +---+-------------+------+ |
| | | | | | |
+----+-----+ +-----+----+ | +----+-----+ +-----+----+ | |
|IPv6 Host | |IPv6 Host | | | IPv6 Host| |IPv6 Host | | |
| H1 | | H2 | | | H3 | | H4 | | |
+----------+ +----------+ | +----------+ +----------+ | |
| | | | |
Link F | ---+------+------+-----+ |
| | Network E(B) |
+------+--------+ | | End-User
| IPv6 | | | Networks
| Interior +------+ |
| Router | |
+---+-------+-+-+ |
Network C | | Network D |
----+-------------+---+ +---+-------------+--- |
| | | | |
+----+-----+ +-----+----+ +----+-----+ +-----+----+ |
|IPv6 Host | |IPv6 Host | | IPv6 Host| |IPv6 Host | |
| H5 | | H6 | | H7 | | H8 | /
+----------+ +----------+ +----------+ +----------+ /
Figure 1
图1
In this diagram, there is one CE router. It has a single uplink interface. It has three additional interfaces connected to Network A, Link F, and Network B. The IPv6 Internal Router (IR) has four interfaces connected to Link F, Network C, Network D, and Network E. Network B and Network E have been bridged, likely inadvertently. This could be as a result of connecting a wire between a switch for Network B and a switch for Network E.
在此图中，有一个CE路由器。它有一个单一的上行接口。它有三个额外的接口连接到网络A、链路F和网络B。IPv6内部路由器（IR）有四个接口连接到链路F、网络C、网络D和网络E。网络B和网络E可能是无意中桥接的。这可能是由于在网络B的交换机和网络E的交换机之间连接了一根导线。
Any of logical Networks A through F might be wired or wireless. Where multiple hosts are shown, this might be through one or more physical ports on the CE router or IPv6 (IR), wireless networks, or through one or more Ethernet switches that are Layer 2 only.
逻辑网络A到F中的任何一个都可以是有线或无线的。在显示多个主机的情况下，这可能是通过CE路由器或IPv6（IR）上的一个或多个物理端口、无线网络，或通过一个或多个仅为第2层的以太网交换机实现的。
+-------+-------+ +-------+-------+ \
| Service | | Service | \
| Provider A | | Provider B | | Service
| Router | | Router | | Provider
+------+--------+ +-------+-------+ | Network
| | /
| Customer | /
| Internet Connections | /
| |
+------+--------+ +-------+-------+ \
| IPv6 | | IPv6 | \
| Customer Edge | | Customer Edge | \
| Router 1 | | Router 2 | /
+------+--------+ +-------+-------+ /
| | /
| | | End-User
---+---------+---+---------------+--+----------+--- | Network(s)
| | | | \
+----+-----+ +-----+----+ +----+-----+ +-----+----+ \
|IPv6 Host | |IPv6 Host | | IPv6 Host| |IPv6 Host | /
| H1 | | H2 | | H3 | | H4 | /
+----------+ +----------+ +----------+ +----------+
+-------+-------+ +-------+-------+ \
| Service | | Service | \
| Provider A | | Provider B | | Service
| Router | | Router | | Provider
+------+--------+ +-------+-------+ | Network
| | /
| Customer | /
| Internet Connections | /
| |
+------+--------+ +-------+-------+ \
| IPv6 | | IPv6 | \
| Customer Edge | | Customer Edge | \
| Router 1 | | Router 2 | /
+------+--------+ +-------+-------+ /
| | /
| | | End-User
---+---------+---+---------------+--+----------+--- | Network(s)
| | | | \
+----+-----+ +-----+----+ +----+-----+ +-----+----+ \
|IPv6 Host | |IPv6 Host | | IPv6 Host| |IPv6 Host | /
| H1 | | H2 | | H3 | | H4 | /
+----------+ +----------+ +----------+ +----------+
Figure 2
图2
Figure 2 illustrates a multihomed homenet model, where the customer has connectivity via CE router 1 to ISP A and via CE router 2 to ISP B. This example shows one shared subnet where IPv6 nodes would potentially be multihomed and receive multiple IPv6 global prefixes, one per ISP. This model may also be combined with that shown in Figure 1 to create a more complex scenario with multiple internal routers. Or, the above shared subnet may be split in two, such that each CE router serves a separate isolated subnet, which is a scenario seen with some IPv4 networks today.
图2说明了多宿家庭网络模型，其中客户通过CE路由器1连接到ISP a，通过CE路由器2连接到ISP B。此示例显示了一个共享子网，其中IPv6节点可能是多宿的，并接收多个IPv6全局前缀，每个ISP一个。该模型还可以与图1所示的模型相结合，以创建一个具有多个内部路由器的更复杂场景。或者，可以将上述共享子网一分为二，以便每个CE路由器为一个单独的隔离子网提供服务，这是目前某些IPv4网络中出现的情况。
+-------+-------+ +-------+-------+ \
| Service | | Service | \
| Provider A | | Provider B | | Service
| Router | | Router | | Provider
+-------+-------+ +------+--------+ | Network
| | /
| Customer | /
| Internet | /
| Connections |
+-----------+-----------+ \
| IPv6 | \
| Customer Edge | \
| Router | /
+-----------+-----------+ /
| /
| | End-User
---+------------+-------+--------+-------------+--- | Network(s)
| | | | \
+----+-----+ +----+-----+ +----+-----+ +-----+----+ \
|IPv6 Host | |IPv6 Host | | IPv6 Host| |IPv6 Host | /
| H1 | | H2 | | H3 | | H4 | /
+----------+ +----------+ +----------+ +----------+
+-------+-------+ +-------+-------+ \
| Service | | Service | \
| Provider A | | Provider B | | Service
| Router | | Router | | Provider
+-------+-------+ +------+--------+ | Network
| | /
| Customer | /
| Internet | /
| Connections |
+-----------+-----------+ \
| IPv6 | \
| Customer Edge | \
| Router | /
+-----------+-----------+ /
| /
| | End-User
---+------------+-------+--------+-------------+--- | Network(s)
| | | | \
+----+-----+ +----+-----+ +----+-----+ +-----+----+ \
|IPv6 Host | |IPv6 Host | | IPv6 Host| |IPv6 Host | /
| H1 | | H2 | | H3 | | H4 | /
+----------+ +----------+ +----------+ +----------+
Figure 3
图3
Figure 3 illustrates a model where a home network may have multiple connections to multiple providers or multiple logical connections to the same provider, with shared internal subnets.
图3说明了一个模型，其中家庭网络可能与多个提供商有多个连接，或者与同一提供商有多个逻辑连接，并且具有共享的内部子网。
For the immediate future, it is expected that most homenet deployments will be dual-stack IPv4/IPv6. In such networks, it is important not to introduce new IPv6 capabilities that would cause a failure if used alongside IPv4+NAT, given that such dual-stack homenets will be commonplace for some time. That said, it is desirable that IPv6 works better than IPv4 in as many scenarios as possible. Further, the homenet architecture must operate in the absence of IPv4.
在不久的将来，预计大多数homenet部署将是双栈IPv4/IPv6。在这种网络中，重要的是不要引入新的IPv6功能，如果与IPv4+NAT一起使用，将导致故障，因为这种双栈家庭网络将在一段时间内很常见。也就是说，IPv6在尽可能多的场景中比IPv4工作得更好是可取的。此外，homenet体系结构必须在没有IPv4的情况下运行。
A general recommendation is to follow the same topology for IPv6 as is used for IPv4 but not to use NAT. Thus, there should be routed IPv6 where an IPv4 NAT is used, and where there is no NAT, routing or bridging may be used. Routing may have advantages when compared to bridging together high- and lower-speed shared media, and in
一般建议IPv6采用与IPv4相同的拓扑，但不要使用NAT。因此，在使用IPv4 NAT的情况下应该有路由IPv6，而在没有NAT的情况下，可以使用路由或桥接。与桥接高速和低速共享介质相比，路由可能具有优势，并且
addition, bridging may not be suitable for some networks, such as ad hoc mobile networks.
此外，桥接可能不适用于某些网络，例如自组织移动网络。
In some cases, IPv4 home networks may feature cascaded NATs. End users are frequently unaware that they have created such networks, as 'home routers' and 'home switches' are frequently confused. In addition, there are cases where NAT routers are included within Virtual Machine Hypervisors or where Internet connection-sharing services have been enabled. This document applies equally to such hidden NAT 'routers'. IPv6-routed versions of such cases will be required. We should thus also note that routers in the homenet may not be separate physical devices; they may be embedded within other devices.
在某些情况下，IPv4家庭网络可能具有级联NAT。终端用户通常不知道他们创建了这样的网络，因为“家庭路由器”和“家庭交换机”经常被混淆。此外，在某些情况下，NAT路由器包含在虚拟机管理程序中，或者启用了Internet连接共享服务。本文件同样适用于此类隐藏NAT“路由器”。将需要此类情况的IPv6路由版本。因此，我们还应该注意，家庭网络中的路由器可能不是单独的物理设备；它们可以嵌入其他设备中。
A homenet may be multihomed to multiple providers, as the network models above illustrate. This may take a form where there are either multiple isolated networks within the home or a more integrated network where the connectivity selection needs to be dynamic. Current practice is typically of the former kind, but the latter is expected to become more commonplace.
如上面的网络模型所示，一个家庭网络可以是多个提供商的多址网络。这可能采取这样一种形式，即在家庭中存在多个孤立的网络，或者是连接选择需要动态的更集成的网络。目前的做法通常是前者，但后者预计将变得更为普遍。
In the general homenet architecture, multihomed hosts should be multi-addressed with a global IPv6 address from the global prefix delegated from each ISP they communicate with or through. When such multi-addressing is in use, hosts need some way to pick source and destination address pairs for connections. A host may choose a source address to use by various methods, most commonly [RFC6724]. Applications may of course do different things, and this should not be precluded.
在一般的homenet体系结构中，多宿主主机应该使用全局IPv6地址进行多址寻址，该地址来自与多宿主主机通信或通过多宿主主机进行通信的每个ISP委派的全局前缀。当使用这种多重寻址时，主机需要某种方式来选择连接的源地址对和目标地址对。主机可以选择各种方法使用的源地址，最常见的是[RFC6724]。应用程序当然可以做不同的事情，这不应该被排除。
For the single CE Router Network Model C illustrated above, multihoming may be offered by source-based routing at the CE router. With multiple exit routers, as in CE Router Network Model B, the complexity rises. Given a packet with a source address on the home network, the packet must be routed to the proper egress to avoid ingress filtering as described in BCP 38 if exiting through the wrong ISP. It is highly desirable that the packet is routed in the most efficient manner to the correct exit, though as a minimum requirement the packet should not be dropped.
对于上面所示的单CE路由器网络模型C，可以通过CE路由器处基于源的路由来提供多归属。对于多个出口路由器，如CE路由器网络模型B，复杂性增加。给定家庭网络上具有源地址的数据包，如果通过错误的ISP退出，则该数据包必须路由到正确的出口，以避免BCP 38中所述的进入过滤。非常希望以最有效的方式将数据包路由到正确的出口，尽管作为最低要求，数据包不应被丢弃。
The homenet architecture should support both the above models, i.e., one or more CE routers. However, the general multihoming problem is broad, and solutions suggested to date within the IETF have included complex architectures for monitoring connectivity, traffic engineering, identifier-locator separation, connection survivability across multihoming events, and so on. It is thus important that the
homenet体系结构应支持上述两种型号，即一个或多个CE路由器。然而，一般的多宿问题是广泛的，迄今为止在IETF中提出的解决方案包括用于监控连接、流量工程、标识符-定位器分离、跨多宿事件的连接生存性等的复杂体系结构。因此，重要的是
homenet architecture should as far as possible minimise the complexity of any multihoming support.
homenet体系结构应尽可能降低任何多主支持的复杂性。
An example of such a 'simpler' approach has been documented in [RFC7157]. Alternatively, a flooding/routing protocol could potentially be used to pass information through the homenet, such that internal routers and ultimately end hosts could learn per-prefix configuration information, allowing better address selection decisions to be made. However, this would imply router and, most likely, host changes. Another avenue is to introduce support throughout the homenet for routing that is based on the source as well as the destination address of each packet. While greatly improving the 'intelligence' of routing decisions within the homenet, such an approach would require relatively significant router changes but avoid host changes.
[RFC7157]中记录了此类“更简单”方法的示例。或者，泛洪/路由协议可以潜在地用于通过家庭网络传递信息，这样内部路由器和最终终端主机可以学习每个前缀的配置信息，从而做出更好的地址选择决策。然而，这将意味着路由器和主机的改变。另一个途径是在整个家庭网络中引入基于每个数据包的源地址和目标地址的路由支持。虽然极大地提高了家庭网络内路由决策的“智能”，但这种方法需要相对重大的路由器更改，但可以避免主机更改。
As explained previously, while NPTv6 has been proposed for providing multihoming support in networks, its use is not recommended in the homenet architecture.
如前所述，虽然NPTv6已被提议用于在网络中提供多归属支持，但不建议在homenet体系结构中使用它。
It should be noted that some multihoming scenarios may see one upstream being a "walled garden" and thus only appropriate for connectivity to the services of that provider; an example may be a VPN service that only routes back to the enterprise business network of a user in the homenet. As per Section 4.2.1 of [RFC3002], we do not specifically target walled-garden multihoming as a goal of this document.
应注意的是，一些多主场景可能会将一个上游视为“围墙花园”，因此仅适用于连接到该提供商的服务；例如，VPN服务只能路由回家庭网络中用户的企业业务网络。根据[RFC3002]第4.2.1节的规定，本文件的目标并非专门针对有墙花园多人居住。
The homenet architecture should also not preclude use of host or application-oriented tools, e.g., Shim6 [RFC5533], Multipath TCP (MPTCP) [RFC6824], or Happy Eyeballs [RFC6555]. In general, any incremental improvements obtained by host changes should give benefit for the hosts introducing them but should not be required.
homenet体系结构也不应排除使用面向主机或应用程序的工具，例如Shim6[RFC5533]、多路径TCP（MPTCP）[RFC6824]或Happy Eyball[RFC6555]。一般来说，通过主机更改获得的任何增量改进都应该有利于引入它们的主机，但不应该是必需的。
Devices may be mobile within the homenet. While resident on the same subnet, their address will remain persistent, but should devices move to a different (wireless) subnet, they will acquire a new address in that subnet. It is desirable that the homenet supports internal device mobility. To do so, the homenet may either extend the reach of specific wireless subnets to enable wireless roaming across the home (availability of a specific subnet across the home) or support mobility protocols to facilitate such roaming where multiple subnets are used.
设备可以在家庭网络中移动。虽然驻留在同一子网上，但它们的地址将保持不变，但如果设备移动到不同的（无线）子网上，它们将在该子网上获取新地址。家庭网络支持内部设备移动性是可取的。为此，家庭网络可以扩展特定无线子网的覆盖范围以实现家庭内的无线漫游（家庭内特定子网的可用性），或者支持移动协议以促进使用多个子网的漫游。
The home network infrastructure should be naturally self-organising and self-configuring under different circumstances relating to the connectivity status to the Internet, number of devices, and physical topology. At the same time, it should be possible for advanced users to manually adjust (override) the current configuration.
家庭网络基础设施应在与互联网连接状态、设备数量和物理拓扑相关的不同情况下自然自组织和自配置。同时，高级用户应该可以手动调整（覆盖）当前配置。
While a goal of the homenet architecture is for the network to be as self-organising as possible, there may be instances where some manual configuration is required, e.g., the entry of a cryptographic key to apply wireless security or to configure a shared routing secret. The latter may be relevant when considering how to bootstrap a routing configuration. It is highly desirable that the number of such configurations is minimised.
虽然homenet体系结构的目标是使网络尽可能自组织，但在某些情况下可能需要一些手动配置，例如，输入加密密钥以应用无线安全性或配置共享路由秘密。在考虑如何引导路由配置时，后者可能是相关的。将此类配置的数量降至最低是非常理想的。
It is important that self-configuration with 'unintended' devices be avoided. There should be a way for a user to administratively assert in a simple way whether or not a device belongs to a given homenet. The goal is to allow the establishment of borders, particularly between two adjacent homenets, and to avoid unauthorised devices from participating in the homenet. Such an authorisation capability may need to operate through multiple hops in the homenet.
避免使用“意外”设备进行自我配置非常重要。应该有一种方法让用户以简单的方式管理性地断言设备是否属于给定的homenet。目标是允许建立边界，特别是在两个相邻的家庭网络之间，并避免未经授权的设备参与家庭网络。这种授权功能可能需要通过家庭网络中的多个跃点进行操作。
The homenet should thus support a way for a homenet owner to claim ownership of their devices in a reasonably secure way. This could be achieved by a pairing mechanism by, for example, pressing buttons simultaneously on an authenticated and a new homenet device or by an enrollment process as part of an autonomic networking environment.
因此，家庭网络应支持家庭网络所有者以合理安全的方式声明其设备的所有权。这可以通过配对机制来实现，例如，在经过身份验证的家庭网络设备和新的家庭网络设备上同时按下按钮，或者作为自主网络环境的一部分，通过注册过程来实现。
While there may be scenarios where one homenet may wish to intentionally gain access through another, e.g., to share external connectivity costs, such scenarios are not discussed in this document.
虽然可能存在这样的情况，一个家庭网络可能希望通过另一个家庭网络有意获得访问权，例如共享外部连接成本，但本文档中不讨论此类情况。
Today's IPv4 home networks generally have a single subnet, and early dual-stack deployments have a single congruent IPv6 subnet, possibly with some bridging functionality. More recently, some vendors have started to introduce 'home' and 'guest' functions, which in IPv6 would be implemented as two subnets.
今天的IPv4家庭网络通常只有一个子网，早期的双栈部署有一个相同的IPv6子网，可能具有一些桥接功能。最近，一些供应商开始引入“主”和“来宾”功能，在IPv6中，这两个功能将作为两个子网实现。
Future home networks are highly likely to have one or more internal routers and thus need multiple subnets for the reasons described earlier. As part of the self-organisation of the network, the
未来的家庭网络很可能有一个或多个内部路由器，因此出于前面描述的原因，需要多个子网。作为网络自组织的一部分
homenet should subdivide itself into the largest practical subnets that can be constructed within the constraints of link-layer mechanisms, bridging, physical connectivity, and policy, and where applicable, performance or other criteria. In such subdivisions, the logical topology may not necessarily match the physical topology. This text does not, however, make recommendations on how such subdivision should occur. It is expected that subsequent documents will address this problem.
homenet应将自身细分为最大的实用子网，这些子网可在链路层机制、桥接、物理连接和策略以及性能或其他标准（如适用）的约束下构建。在这种细分中，逻辑拓扑可能不一定与物理拓扑匹配。然而，本文并未就如何进行此类细分提出建议。预计后续文件将解决这一问题。
While it may be desirable to maximise the chance of link-local protocols operating across a homenet by maximising the size of a subnet, multi-subnet home networks are inevitable, so their support must be included.
虽然通过最大化子网的大小来最大化在家庭网络上运行的链路本地协议的机会是可取的，但多子网家庭网络是不可避免的，因此必须包括它们的支持。
Homenets tend to grow organically over many years, and a homenet will typically be built over link-layer technologies from different generations. Current homenets typically use links ranging from 1 Mbit/s up to 1 Gbit/s -- a throughput discrepancy of three orders of magnitude. We expect this discrepancy to widen further as both high-speed and low-power technologies are deployed.
家庭网络往往经过多年的有机发展，家庭网络通常是通过不同世代的链路层技术构建的。当前的家庭网络通常使用从1 Mbit/s到1 Gbit/s的链路，这是三个数量级的吞吐量差异。我们预计，随着高速和低功耗技术的部署，这种差异将进一步扩大。
Homenet protocols should be designed to deal well with interconnecting links of very different throughputs. In particular, flows local to a link should not be flooded throughout the homenet, even when sent over multicast, and, whenever possible, the homenet protocols should be able to choose the faster links and avoid the slower ones.
Homenet协议的设计应该能够很好地处理不同吞吐量的互连链路。特别是，链接的本地流不应在整个家庭网络中泛滥，即使通过多播发送，并且，只要可能，家庭网络协议应能够选择更快的链接并避免较慢的链接。
Links (particularly wireless links) may also have limited numbers of transmit opportunities (txops), and there is a clear trend driven by both power and downward compatibility constraints toward aggregation of packets into these limited txops while increasing throughput. Transmit opportunities may be a system's scarcest resource and, therefore, also strongly limit actual throughput available.
链路（尤其是无线链路）也可能具有有限数量的传输机会（TXOP），并且在功率和向下兼容性约束的驱动下，有一个明显的趋势，即在增加吞吐量的同时将数据包聚合到这些有限的TXOP中。传输机会可能是一个系统最稀缺的资源，因此也强烈限制了可用的实际吞吐量。
The homenet will need to be aware of the extent of its own 'site', which will, for example, define the borders for ULA and site scope multicast traffic and may require specific security policies to be applied. The homenet will have one or more such borders with external connectivity providers.
家庭网络需要了解其自身“站点”的范围，例如，它将定义ULA和站点范围多播流量的边界，并且可能需要应用特定的安全策略。家庭网络将与外部连接提供商有一个或多个这样的边界。
A homenet will most likely also have internal borders between internal realms, e.g., a guest realm or a corporate network extension realm. It is desirable that appropriate borders can be configured to
家庭网络很可能在内部领域之间有内部边界，例如，来宾领域或公司网络扩展领域。希望可以配置适当的边界以
determine, for example, the scope of where network prefixes, routing information, network traffic, service discovery, and naming may be shared. The default mode internally should be to share everything.
例如，确定共享网络前缀、路由信息、网络流量、服务发现和命名的范围。内部默认模式应该是共享所有内容。
It is expected that a realm would span at least an entire subnet, and thus the borders lie at routers that receive delegated prefixes within the homenet. It is also desirable, for a richer security model, that hosts are able to make communication decisions based on available realm and associated prefix information in the same way that routers at realm borders can.
预计一个领域将至少跨越整个子网，因此边界位于家庭网络内接收委派前缀的路由器上。对于更丰富的安全模型，还希望主机能够根据可用领域和相关前缀信息做出通信决策，就像领域边界上的路由器一样。
A simple homenet model may just consider three types of realms and the borders between them, namely the internal homenet, the ISP, and a guest network. In this case, the borders will include the border from the homenet to the ISP, the border from the guest network to the ISP, and the border from the homenet to the guest network. Regardless, it should be possible for additional types of realms and borders to be defined, e.g., for some specific LLN-based network, such as Smart Grid, and for these to be detected automatically and for an appropriate default policy to be applied as to what type of traffic/data can flow across such borders.
一个简单的家庭模型可以只考虑三种领域和它们之间的边界，即内部家庭网络、ISP和访客网络。在这种情况下，边界将包括从家庭网络到ISP的边界、从来宾网络到ISP的边界以及从家庭网络到来宾网络的边界。无论如何，应该可以定义其他类型的领域和边界，例如，对于某些特定的基于LLN的网络，例如智能电网，并且可以自动检测这些领域和边界，并且可以应用适当的默认策略，以确定哪些类型的流量/数据可以跨越这些边界。
It is desirable to classify the external border of the home network as a unique logical interface separating the home network from a service provider network(s). This border interface may be a single physical interface to a single service provider, multiple Layer 2 sub-interfaces to a single service provider, or multiple connections to a single or multiple providers. This border makes it possible to describe edge operations and interface requirements across multiple functional areas including security, routing, service discovery, and router discovery.
希望将家庭网络的外部边界分类为将家庭网络与服务提供商网络分离的唯一逻辑接口。该边界接口可以是单个服务提供商的单个物理接口，单个服务提供商的多个第2层子接口，或者单个或多个提供商的多个连接。这个边界使得描述边缘操作和跨多个功能领域的接口需求成为可能，包括安全性、路由、服务发现和路由器发现。
It should be possible for the homenet user to override any automatically determined borders and the default policies applied between them, the exception being that it may not be possible to override policies defined by the ISP at the external border.
homenet用户应该可以覆盖任何自动确定的边界以及它们之间应用的默认策略，例外情况是可能无法覆盖ISP在外部边界定义的策略。
In certain cases, it may be useful for the homenet to get certain configuration information from its ISP. For example, the homenet DHCP server may request and forward some options that it gets from its upstream DHCP server, though the specifics of the options may vary across deployments. There is potential complexity here, of course, should the homenet be multihomed.
在某些情况下，家庭网络从其ISP获取某些配置信息可能很有用。例如，homenet DHCP服务器可能会请求并转发它从其上游DHCP服务器获得的一些选项，尽管这些选项的细节可能因部署而异。当然，如果家庭网络是多址的，那么这里就有潜在的复杂性。
The IPv6 addressing scheme used within a homenet must conform to the IPv6 addressing architecture [RFC4291]. In this section, we discuss how the homenet needs to adapt to the prefixes made available to it by its upstream ISP, such that internal subnets, hosts, and devices can obtain and configure the necessary addressing information to operate.
家庭网络中使用的IPv6寻址方案必须符合IPv6寻址体系结构[RFC4291]。在本节中，我们将讨论家庭网络需要如何适应其上游ISP提供给它的前缀，以便内部子网、主机和设备可以获取和配置必要的寻址信息以进行操作。
Discussion of IPv6 prefix allocation policies is included in [RFC6177]. In practice, a homenet may receive an arbitrary length IPv6 prefix from its provider, e.g., /60, /56, or /48. The offered prefix may be stable or change from time to time; it is generally expected that ISPs will offer relatively stable prefixes to their residential customers. Regardless, the home network needs to be adaptable as far as possible to ISP prefix allocation policies and assume nothing about the stability of the prefix received from an ISP or the length of the prefix that may be offered.
[RFC6177]中包含了对IPv6前缀分配策略的讨论。实际上，家庭网络可以从其提供商处接收任意长度的IPv6前缀，例如/60、/56或/48。所提供的前缀可以是稳定的，也可以不时地改变；一般预期ISP将为其住宅客户提供相对稳定的前缀。无论如何，家庭网络需要尽可能地适应ISP前缀分配策略，并且不假设从ISP接收的前缀的稳定性或可能提供的前缀的长度。
However, if, for example, only a /64 is offered by the ISP, the homenet may be severely constrained or even unable to function. BCP 157 [RFC6177] states the following:
但是，例如，如果ISP仅提供a/64，家庭网络可能会受到严重限制，甚至无法正常工作。BCP 157[RFC6177]规定如下：
A key principle for address management is that end sites always be able to obtain a reasonable amount of address space for their actual and planned usage, and over time ranges specified in years rather than just months. In practice, that means at least one /64, and in most cases significantly more. One particular situation that must be avoided is having an end site feel compelled to use IPv6-to-IPv6 Network Address Translation or other burdensome address conservation techniques because it could not get sufficient address space.
地址管理的一个关键原则是，终端站点始终能够为其实际和计划使用获得合理数量的地址空间，并且在指定的时间范围内以年为单位，而不仅仅是以月为单位。在实践中，这意味着至少有1/64，而且在大多数情况下要多得多。必须避免的一种特殊情况是，由于无法获得足够的地址空间，终端站点不得不使用IPv6到IPv6的网络地址转换或其他繁重的地址保存技术。
This architecture document assumes that the guidance in the quoted text is being followed by ISPs.
本架构（architecture）文件假设ISP遵守引用文本中的指南。
There are many problems that would arise from a homenet not being offered a sufficient prefix size for its needs. Rather than attempt to contrive a method for a homenet to operate in a constrained manner when faced with insufficient prefixes, such as the use of subnet prefixes longer than /64 (which would break stateless address autoconfiguration [RFC4862]), the use of NPTv6, or falling back to bridging across potentially very different media, it is recommended that the receiving router instead enters an error state and issues appropriate warnings. Some consideration may need to be given to how
如果家庭网络没有提供足够的前缀大小来满足其需求，那么就会出现许多问题。而不是试图设计一种方法，让家庭网络在面临前缀不足时以受限的方式运行，例如使用长度超过/64的子网前缀（这将破坏无状态地址自动配置[RFC4862]）、使用NPTv6或退回到跨可能非常不同的媒体桥接，建议接收路由器改为进入错误状态并发出相应的警告。可能需要考虑如何进行
such a warning or error state should best be presented to a typical home user.
此类警告或错误状态最好呈现给典型的家庭用户。
Thus, a homenet CE router should request, for example, via DHCP Prefix Delegation (DHCP PD) [RFC3633], that it would like a /48 prefix from its ISP, i.e., it asks the ISP for the maximum size prefix it might expect to be offered, even if in practice it may only be offered a /56 or /60. For a typical IPv6 homenet, it is not recommended that an ISP offers less than a /60 prefix, and it is highly preferable that the ISP offers at least a /56. It is expected that the allocated prefix to the homenet from any single ISP is a contiguous, aggregated one. While it may be possible for a homenet CE router to issue multiple prefix requests to attempt to obtain multiple delegations, such behaviour is out of scope of this document.
因此，homenet CE路由器应例如通过DHCP前缀委派（DHCP PD）[RFC3633]请求其希望从其ISP获得/48前缀，即，它向ISP请求其可能期望提供的最大前缀大小，即使在实践中可能仅提供/56或/60。对于典型的IPv6家庭网络，建议ISP提供的前缀不少于a/60，并且最好ISP至少提供a/56。预计从任何单个ISP分配给homenet的前缀都是连续的聚合前缀。虽然homenet CE路由器可能会发出多个前缀请求以尝试获得多个授权，但此类行为超出了本文档的范围。
The norm for residential customers of large ISPs may be similar to their single IPv4 address provision; by default it is likely to remain persistent for some time, but changes in the ISP's own provisioning systems may lead to the customer's IP (and in the IPv6 case their prefix pool) changing. It is not expected that ISPs will generally support Provider Independent (PI) addressing for residential homenets.
大型ISP的住宅用户的标准可能类似于其单一IPv4地址规定；默认情况下，它可能会持续一段时间，但ISP自身供应系统的更改可能会导致客户的IP（以及在IPv6情况下其前缀池）发生更改。预计ISP通常不会支持住宅家庭网络的独立提供商（PI）寻址。
When an ISP does need to restructure, and in doing so renumber its customer homenets, 'flash' renumbering is likely to be imposed. This implies a need for the homenet to be able to handle a sudden renumbering event that, unlike the process described in [RFC4192], would be a 'flag day' event, which means that a graceful renumbering process moving through a state with two active prefixes in use would not be possible. While renumbering can be viewed as an extended version of an initial numbering process, the difference between flash renumbering and an initial 'cold start' is the need to provide service continuity.
当一家ISP确实需要重组，并在重组过程中对其客户家庭网络重新编号时，很可能会实施“闪存”重新编号。这意味着homenet需要能够处理一个突然的重新编号事件，与[RFC4192]中描述的过程不同，该事件将是一个“国旗日”事件，这意味着不可能在使用两个活动前缀的状态中进行优雅的重新编号过程。虽然重新编号可视为初始编号过程的扩展版本，但闪存重新编号和初始“冷启动”之间的区别在于需要提供服务连续性。
There may be cases where local law means some ISPs are required to change IPv6 prefixes (current IPv4 addresses) for privacy reasons for their customers. In such cases, it may be possible to avoid an instant 'flash' renumbering and plan a non-flag day renumbering as per RFC 4192. Similarly, if an ISP has a planned renumbering process, it may be able to adjust lease timers, etc., appropriately.
在某些情况下，当地法律意味着出于客户隐私的原因，某些ISP需要更改IPv6前缀（当前IPv4地址）。在这种情况下，可以避免即时“闪光”重新编号，并根据RFC 4192计划非卖旗日重新编号。类似地，如果ISP有计划的重新编号过程，它可能能够适当地调整租赁计时器等。
The customer may of course also choose to move to a new ISP and thus begin using a new prefix. In such cases, the customer should expect a discontinuity, and not only may the prefix change, but potentially also the prefix length if the new ISP offers a different default size prefix. The homenet may also be forced to renumber itself if significant internal 'replumbing' is undertaken by the user.
客户当然也可以选择迁移到新的ISP，从而开始使用新的前缀。在这种情况下，客户应该期望不连续，并且如果新ISP提供不同的默认大小前缀，不仅前缀可能会更改，而且前缀长度也可能会更改。如果用户进行了重大的内部“回复”，家庭网络也可能被迫重新编号。
Regardless, it's desirable that homenet protocols support rapid renumbering and that operational processes don't add unnecessary complexity for the renumbering process. Further, the introduction of any new homenet protocols should not make any form of renumbering any more complex than it already is.
无论如何，homenet协议支持快速重新编号，并且操作过程不会为重新编号过程增加不必要的复杂性是可取的。此外，任何新家庭网络协议的引入不应使任何形式的重新编号变得比现在更复杂。
Finally, the internal operation of the home network should also not depend on the availability of the ISP network at any given time, other than, of course, for connectivity to services or systems off the home network. This reinforces the use of ULAs for stable internal communication and the need for a naming and service discovery mechanism that can operate independently within the homenet.
最后，家庭网络的内部操作也不应取决于ISP网络在任何给定时间的可用性，当然，除了与家庭网络以外的服务或系统的连接。这加强了对ULA的使用，以实现稳定的内部通信，以及对命名和服务发现机制的需求，该机制可以在homenet中独立运行。
The network should by default attempt to provide IP-layer connectivity between all internal parts of the homenet as well as to and from the external Internet, subject to the filtering policies or other policy constraints discussed later in the security section.
默认情况下，网络应尝试在家庭网络的所有内部部分之间以及与外部Internet之间提供IP层连接，但需遵守过滤策略或安全部分稍后讨论的其他策略约束。
ULAs should be used within the scope of a homenet to support stable routing and connectivity between subnets and hosts regardless of whether a globally unique ISP-provided prefix is available. In the case of a prolonged external connectivity outage, ULAs allow internal operations across routed subnets to continue. ULA addresses also allow constrained devices to create permanent relationships between IPv6 addresses, e.g., from a wall controller to a lamp, where symbolic host names would require additional non-volatile memory, and updating global prefixes in sleeping devices might also be problematic.
ULA应在家庭网络的范围内使用，以支持子网和主机之间的稳定路由和连接，无论是否有全球唯一的ISP提供的前缀可用。在外部连接长期中断的情况下，ULA允许跨路由子网的内部操作继续进行。ULA地址还允许受约束的设备在IPv6地址之间创建永久关系，例如，从墙控制器到lamp，其中符号主机名将需要额外的非易失性内存，更新休眠设备中的全局前缀也可能有问题。
As discussed previously, it would be expected that ULAs would normally be used alongside one or more global prefixes in a homenet, such that hosts become multi-addressed with both globally unique and ULA prefixes. ULAs should be used for all devices, not just those intended to only have internal connectivity. Default address selection would then enable ULAs to be preferred for internal communications between devices that are using ULA prefixes generated within the same homenet.
如前所述，可以预期，在家庭网络中，ULA通常与一个或多个全局前缀一起使用，这样主机就可以使用全局唯一前缀和ULA前缀进行多地址处理。ULA应用于所有设备，而不仅仅是那些仅具有内部连接的设备。默认地址选择将使ULA成为使用同一家庭网络中生成的ULA前缀的设备之间进行内部通信的首选。
In cases where ULA prefixes are in use within a homenet but there is no external IPv6 connectivity (and thus no GUAs in use), recommendations ULA-5, L-3, and L-4 in RFC 7084 should be followed to ensure correct operation, in particular where the homenet may be dual stack with IPv4 external connectivity. The use of the Route Information Option described in [RFC4191] provides a mechanism to advertise such more-specific ULA routes.
如果在家庭网络中使用ULA前缀，但没有外部IPv6连接（因此没有使用GUA），则应遵循RFC 7084中的建议ULA-5、L-3和L-4，以确保正确操作，特别是在家庭网络可能是具有IPv4外部连接的双堆栈的情况下。[RFC4191]中描述的路由信息选项的使用提供了一种机制来公布此类更具体的路由。
The use of ULAs should be restricted to the homenet scope through filtering at the border(s) of the homenet, as mandated by RFC 7084 requirement S-2.
根据RFC 7084要求s-2的规定，应通过在家庭网络的边界进行过滤，将ULA的使用限制在家庭网络范围内。
Note that in some cases, it is possible that multiple /48 ULA prefixes may be in use within the same homenet, e.g., when the network is being deployed, perhaps also without external connectivity. In cases where multiple ULA /48s are in use, hosts need to know that each /48 is local to the homenet, e.g., by inclusion in their local address selection policy table.
请注意，在某些情况下，可能在同一家庭网络中使用多个/48 ULA前缀，例如，在部署网络时，可能也没有外部连接。在使用多个ULA/48的情况下，主机需要知道每个ULA/48都是家庭网络本地的，例如，通过包含在其本地地址选择策略表中。
As mentioned above, there are various sources of prefixes. From the homenet perspective, a single global prefix from each ISP should be received on the border CE router [RFC3633]. Where multiple CE routers exist with multiple ISP prefix pools, it is expected that routers within the homenet would assign themselves prefixes from each ISP they communicate with/through. As discussed above, a ULA prefix should be provisioned for stable internal communications or for use on constrained/LLN networks.
如上所述，前缀的来源多种多样。从homenet的角度来看，应在border CE路由器[RFC3633]上接收来自每个ISP的单个全局前缀。如果存在具有多个ISP前缀池的多个CE路由器，则家庭网络中的路由器将从与之通信/通过其通信的每个ISP为自己分配前缀。如上所述，应为稳定的内部通信或在受限/LLN网络上使用提供ULA前缀。
The delegation or availability of a prefix pool to the homenet should allow subsequent internal autonomous assignment of prefixes for use within the homenet. Such internal assignment should not assume a flat or hierarchical model, nor should it make an assumption about whether the assignment of internal prefixes is distributed or centralised. The assignment mechanism should provide reasonable efficiency, so that typical home network prefix allocation sizes can accommodate all the necessary /64 allocations in most cases, and not waste prefixes. Further, duplicate assignment of multiple /64s to the same network should be avoided, and the network should behave as gracefully as possible in the event of prefix exhaustion (though the options in such cases may be limited).
向homenet委派或提供前缀池时，应允许随后在homenet内部自主分配前缀以供使用。这样的内部分配不应该假设一个平面或层次模型，也不应该假设内部前缀的分配是分布式的还是集中式的。分配机制应该提供合理的效率，以便典型的家庭网络前缀分配大小能够在大多数情况下容纳所有必要的/64分配，而不是浪费前缀。此外，应避免向同一网络重复分配多个/64，并且在前缀耗尽的情况下，网络应尽可能优雅地运行（尽管在这种情况下的选项可能有限）。
Where the home network has multiple CE routers and these are delegated prefix pools from their attached ISPs, the internal prefix assignment would be expected to be served by each CE router for each prefix associated with it. Where ULAs are used, it is preferable that only one /48 ULA covers the whole homenet, from which /64s can be assigned to the subnets. In cases where two /48 ULAs are generated within a homenet, the network should still continue to function, meaning that hosts will need to determine that each ULA is local to the homenet.
如果家庭网络具有多个CE路由器，并且这些路由器是来自其连接的ISP的委派前缀池，则内部前缀分配将由每个CE路由器为与其相关联的每个前缀提供服务。在使用ULA的情况下，最好只有一个/48 ULA覆盖整个家庭网络，从中可以将/64分配给子网。在家庭网络中生成两个/48个ULA的情况下，网络仍应继续运行，这意味着主机需要确定每个ULA都是家庭网络的本地ULA。
Prefix assignment within the homenet should result in each link being assigned a stable prefix that is persistent across reboots, power outages, and similar short-term outages. The availability of
家庭网络中的前缀分配应导致为每个链路分配一个稳定的前缀，该前缀在重新启动、停电和类似的短期停电期间保持不变。可用性
persistent prefixes should not depend on the router boot order. The addition of a new routing device should not affect existing persistent prefixes, but persistence may not be expected in the face of significant 'replumbing' of the homenet. However, assigned ULA prefixes within the homenet should remain persistent through an ISP-driven renumbering event.
持久前缀不应取决于路由器引导顺序。添加新的路由设备不应影响现有的持久化前缀，但在家庭网络出现重大的“重新连接”时，持久化可能不会出现。但是，在ISP驱动的重新编号事件中，家庭网络中分配的ULA前缀应保持持久性。
Provisioning such persistent prefixes may imply the need for stable storage on routing devices and also a method for a home user to 'reset' the stored prefix should a significant reconfiguration be required (though ideally the home user should not be involved at all).
提供此类持久前缀可能意味着需要路由设备上的稳定存储，并且如果需要重大的重新配置，家庭用户也需要一种方法来“重置”存储的前缀（尽管理想情况下家庭用户根本不应该参与）。
This document makes no specific recommendation towards solutions but notes that it is very likely that all routing devices participating in a homenet must use the same internal prefix delegation method. This implies that only one delegation method should be in use.
本文档未对解决方案提出具体建议，但指出很可能参与家庭网络的所有路由设备都必须使用相同的内部前缀委派方法。这意味着只能使用一种委托方法。
The network elements will need to be integrated in a way that takes account of the various lifetimes on timers that are used on different elements, e.g., DHCPv6 PD, router, valid prefix, and preferred prefix timers.
网络元件需要以一种考虑不同元件（例如DHCPv6 PD、路由器、有效前缀和首选前缀定时器）上使用的定时器的不同寿命的方式进行集成。
If ISPs offer relatively stable IPv6 prefixes to customers, the network prefix part of addresses associated with the homenet may not change over a reasonably long period of time.
如果ISP向客户提供相对稳定的IPv6前缀，则与家庭网络相关的地址中的网络前缀部分在相当长的时间内可能不会改变。
The exposure of which traffic is sourced from the same homenet is thus similar to IPv4; the single IPv4 global address seen through use of IPv4 NAT gives the same hint as the global IPv6 prefix seen for IPv6 traffic.
因此，来自同一家庭网络的流量暴露类似于IPv4；通过使用IPv4 NAT看到的单个IPv4全局地址给出了与IPv6流量看到的全局IPv6前缀相同的提示。
While IPv4 NAT may obfuscate to an external observer which internal devices traffic is sourced from, IPv6, even with use of privacy addresses [RFC4941], adds additional exposure of which traffic is sourced from the same internal device through use of the same IPv6 source address for a period of time.
虽然IPv4 NAT可能会使外部观察者混淆内部设备流量来源，但IPv6即使使用隐私地址[RFC4941]，也会通过在一段时间内使用相同的IPv6源地址，增加来自相同内部设备的流量的额外暴露。
Routing functionality is required when there are multiple routers deployed within the internal home network. This functionality could be as simple as the current 'default route is up' model of IPv4 NAT,
当内部家庭网络中部署了多个路由器时，需要路由功能。此功能可以像IPv4 NAT的当前“默认路由已启动”模型一样简单，
or more likely, it would involve running an appropriate routing protocol.
或者更可能的是，它将涉及运行适当的路由协议。
A mechanism is required to discover which router(s) in the homenet is providing the CE router function. Borders may include but are not limited to the interface to the upstream ISP, a gateway device to a separate home network such as an LLN network, or a gateway to a guest or private corporate extension network. In some cases, there may be no border present, which may, for example, occur before an upstream connection has been established.
需要一种机制来发现家庭网络中提供CE路由器功能的路由器。边界可以包括但不限于到上游ISP的接口、到独立家庭网络（例如LLN网络）的网关设备或到来宾或私有公司扩展网络的网关。在某些情况下，可能不存在边界，例如，可能在建立上游连接之前出现边界。
The routing environment should be self-configuring, as discussed previously. The homenet self-configuration process and the routing protocol must interact in a predictable manner, especially during startup and reconvergence. The border discovery functionality and other self-configuration functionality may be integrated into the routing protocol itself but may also be imported via a separate discovery mechanism.
如前所述，路由环境应该是自配置的。homenet自配置过程和路由协议必须以可预测的方式交互，尤其是在启动和重新聚合期间。边界发现功能和其他自配置功能可以集成到路由协议本身中，但也可以通过单独的发现机制导入。
It is preferable that configuration information is distributed and synchronised within the homenet by a separate configuration protocol.
优选地，配置信息通过单独的配置协议在家庭网络内分发和同步。
The homenet routing protocol should be based on a previously deployed protocol that has been shown to be reliable and robust. This does not preclude the selection of a newer protocol for which a high-quality open source implementation becomes available. The resulting code must support lightweight implementations and be suitable for incorporation into consumer devices, where both fixed and temporary storage and processing power are at a premium.
homenet路由协议应基于先前部署的协议，该协议已被证明是可靠和健壮的。这并不排除选择一个新的协议，为其提供高质量的开源实现。由此产生的代码必须支持轻量级实现，并且适合合并到消费类设备中，在消费类设备中，固定和临时存储和处理能力都很高。
At most, one unicast and one multicast routing protocol should be in use at a given time in a given homenet. In some simple topologies, no routing protocol may be needed. If more than one routing protocol is supported by routers in a given homenet, then a mechanism is required to ensure that all routers in that homenet use the same protocol.
在给定的家庭网络中，在给定的时间最多只能使用一个单播和一个多播路由协议。在一些简单的拓扑中，可能不需要路由协议。如果给定家庭网络中的路由器支持多个路由协议，则需要一种机制来确保该家庭网络中的所有路由器使用相同的协议。
The homenet architecture is IPv6-only. In practice, dual-stack homenets are still likely for the foreseeable future, as described in Section 3.2.3. Whilst support for IPv4 and other address families may therefore be beneficial, it is not an explicit requirement to carry the routing information in the same routing protocol.
homenet体系结构仅适用于IPv6。实际上，如第3.2.3节所述，在可预见的未来，双栈家庭网络仍有可能出现。因此，虽然支持IPv4和其他地址系列可能是有益的，但并不明确要求在同一路由协议中携带路由信息。
Multiple types of physical interfaces must be accounted for in the homenet routing topology. Technologies such as Ethernet, Wi-Fi, Multimedia over Coax Alliance (MoCA), etc., must be capable of coexisting in the same environment and should be treated as part of any routed deployment. The inclusion of physical-layer
homenet路由拓扑中必须考虑多种类型的物理接口。以太网、Wi-Fi、同轴电缆多媒体联盟（MoCA）等技术必须能够在同一环境中共存，并应视为任何路由部署的一部分。物理层的包含
characteristics in path computation should be considered for optimising communication in the homenet.
为了优化家庭网络中的通信，应考虑路径计算的特点。
The role of the unicast routing protocol is to provide good enough end-to-end connectivity often enough, where good/often enough is defined by user expectations.
单播路由协议的作用是提供足够好的端到端连接，而“足够好/足够经常”是由用户期望定义的。
Due to the use of a variety of diverse underlying link technologies, path selection in a homenet may benefit from being more refined than minimising hop count. It may also be beneficial for traffic to use multiple paths to a given destination within the homenet where available rather than just a single best path.
由于使用了各种不同的底层链路技术，家庭网络中的路径选择可能会受益于比最小化跳数更精细的选择。如果家庭网络中有多条路径可供使用，而不仅仅是一条最佳路径，那么使用多条路径到家庭网络中给定的目的地也可能对通信量有利。
Minimising convergence time should be a goal in any routed environment. It is reasonable to assume that convergence time should not be significantly longer than network outages users are accustomed to should their CE router reboot.
在任何路由环境中，最小化收敛时间都应该是一个目标。可以合理地假设，如果CE路由器重新启动，聚合时间不应明显长于用户习惯的网络中断时间。
The homenet architecture is agnostic as to the choice of underlying routing technology, e.g., link state versus Bellman-Ford.
homenet体系结构对于底层路由技术的选择是不可知的，例如链路状态与Bellman Ford。
The routing protocol should support the generic use of multiple customer Internet connections and the concurrent use of multiple delegated prefixes. A routing protocol that can make routing decisions based on source and destination addresses is thus highly desirable, to avoid problems with upstream ISP ingress filtering as described in BCP 38. Multihoming support may also include load balancing to multiple providers and failover from a primary to a backup link when available. The protocol should not require upstream ISP connectivity to be established to continue routing within the homenet.
路由协议应支持多个客户互联网连接的通用使用和多个委派前缀的并发使用。因此，非常需要一种能够根据源地址和目的地址做出路由决定的路由协议，以避免如BCP 38中所述的上游ISP入口过滤问题。多宿主支持还可能包括到多个提供程序的负载平衡以及从主链路到备份链路的故障切换（如果可用）。协议不应要求建立上游ISP连接以继续在家庭网络内进行路由。
The homenet architecture is agnostic on a minimum hop count that has to be supported by the routing protocol. The architecture should, however, be scalable to other scenarios where homenet technology may be deployed, which may include small office and small enterprise sites. To allow for such cases, it would be desirable that the architecture is scalable to higher hop counts and to larger numbers of routers than would be typical in a true home network.
homenet体系结构对于路由协议必须支持的最小跳数是不可知的。但是，该体系结构应可扩展到可能部署homenet技术的其他场景，包括小型办公室和小型企业站点。为了允许这种情况，与真正的家庭网络中的典型情况相比，该体系结构可扩展到更高的跳数和更多的路由器是可取的。
At the time of writing, link-layer networking technology is poised to become more heterogeneous, as networks begin to employ both traditional Ethernet technology and link layers designed for LLNs, such as those used for certain types of sensor devices.
在撰写本文时，随着网络开始采用传统以太网技术和为LLN设计的链路层（如用于某些类型传感器设备的链路层），链路层网络技术将变得更加异构。
Ideally, LLN or other logically separate networks should be able to exchange routes such that IP traffic may be forwarded among the networks via gateway routers that interoperate with both the homenet and any LLNs. Current home deployments use largely different mechanisms in sensor and basic Internet connectivity networks. IPv6 virtual machine (VM) solutions may also add additional routing requirements.
理想情况下，LLN或其他逻辑上独立的网络应该能够交换路由，以便IP流量可以通过与家庭网络和任何LLN互操作的网关路由器在网络之间转发。当前的家庭部署在传感器和基本互联网连接网络中使用了很大不同的机制。IPv6虚拟机（VM）解决方案还可能增加额外的路由要求。
In this homenet architecture, LLNs and other specialised networks are considered stub areas of the homenet and are thus not expected to act as a transit for traffic between more traditional media.
在这种家庭网络体系结构中，LLN和其他专业网络被视为家庭网络的存根区域，因此不应充当更传统媒体之间通信的中转站。
The current practice defined in [RFC7084] would suggest that routing between the homenet CE router and the service provider router follow the WAN-side requirements model in [RFC7084], Section 4 (WAN-side requirements), at least in initial deployments. However, consideration of whether a routing protocol is used between the homenet CE router and the service provider router is out of scope of this document.
[RFC7084]中定义的当前实践将建议homenet CE路由器和服务提供商路由器之间的路由至少在初始部署时遵循[RFC7084]第4节（WAN侧要求）中的WAN侧要求模型。但是，是否在homenet CE路由器和服务提供商路由器之间使用路由协议的考虑超出了本文档的范围。
It is desirable that, subject to the capacities of devices on certain media types, multicast routing is supported across the homenet, including source-specific multicast (SSM) [RFC4607].
根据特定媒体类型上设备的容量，希望在整个家庭网络上支持多播路由，包括源特定多播（SSM）[RFC4607]。
[RFC4291] requires that any boundary of scope 4 or higher (i.e., admin-local or higher) be administratively configured. Thus, the boundary at the homenet-ISP border must be administratively configured, though that may be triggered by an administrative function such as DHCP PD. Other multicast forwarding policy borders may also exist within the homenet, e.g., to/from a guest subnet, whilst the use of certain link media types may also affect where specific multicast traffic is forwarded or routed.
[RFC4291]要求以管理方式配置范围4或更高级别的任何边界（即管理本地或更高级别）。因此，必须以管理方式配置homenet ISP边界处的边界，尽管这可能由诸如DHCP PD之类的管理功能触发。其他多播转发策略边界也可能存在于家庭网络中，例如，到/从来宾子网，而某些链路媒体类型的使用也可能影响转发或路由特定多播流量的位置。
There may be different drivers for multicast to be supported across the homenet -- for example,
在homenet上支持多播可能有不同的驱动程序，例如，
o for homenet-wide service discovery, should a multicast service discovery protocol of scope greater than link-local be defined
o 对于homenet范围的服务发现，是否应定义范围大于本地链路的多播服务发现协议
o for multicast-based streaming or file-sharing applications
o 用于基于多播的流或文件共享应用程序
Where multicast is routed across a homenet, an appropriate multicast routing protocol is required, one that as per the unicast routing protocol should be self-configuring. As hinted above, it must be
如果多播是通过家庭网络路由的，则需要一个适当的多播路由协议，根据单播路由协议，该协议应该是自配置的。正如上面所暗示的，它必须是
possible to scope or filter multicast traffic to avoid it being flooded to network media where devices cannot reasonably support it.
可以对多播流量进行范围或过滤，以避免其被淹没到设备无法合理支持的网络媒体。
A homenet may not only use multicast internally, it may also be a consumer or provider of external multicast traffic, where the homenet's ISP supports such multicast operation. This may be valuable, for example, where live video applications are being sourced to/from the homenet.
家庭网络不仅可以在内部使用多播，还可以是外部多播流量的消费者或提供者，家庭网络的ISP支持这种多播操作。这可能很有价值，例如，当实时视频应用程序来源于家庭网络时。
The multicast environment should support the ability for applications to pick a unique multicast group to use.
多播环境应支持应用程序选择要使用的唯一多播组的能力。
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.
IPv6家庭网络的安全性是一个重要的考虑因素。与IPv4操作模型最显著的区别是去除NAT，引入设备的全局可寻址性，因此需要考虑设备是否应该具有全局可达性。无论如何，主机需要能够安全地运行，在需要时端到端，并且对指向它们的恶意流量具有鲁棒性。但是，还引入了其他挑战，例如，在不同homenet领域之间的边界上采用默认过滤策略。
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.
基于IPv6的家庭网络体系结构应采用[RFC2775]中所述的透明端到端通信模型。每个设备都应该是全局可寻址的，并且这些地址在传输过程中不得更改。然而，安全周界可用于限制端到端通信，因此，虽然主机可能是全局可寻址的，但它可能无法全局可访问。
[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.
[RFC4864]描述了IPv6网络的“简单安全”模型，通过该模型，可以应用有状态周界过滤来控制家庭网络中设备的可达性。RFC 4864在第4.2节中指出，“建议除了主机防御之外，还需要边界保护的人使用防火墙。”应该注意的是，“默认拒绝”过滤方法将有效地将IPv4 NAT穿越协议的需要替换为使用信令协议请求打开防火墙漏洞的需要，例如PCP[RFC6887]等协议。在具有多个CE路由器的网络中，信令将需要处理可能使用一个或多个出口路由器的流的情况。CE路由器需要能够为此类协议宣传它们的存在。
[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.
[RFC6092]在RFC 4864的基础上进行了扩展，对IPv6外围安全建议进行了更详细的讨论，但没有强制使用“默认拒绝”方法。事实上，RFC 6092并未强制执行特定的操作模式，而是指出CE路由器必须提供一个易于选择的配置选项，以允许“透明”模式，从而确保“默认允许”模式可用。
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.
本文件中所述的未来家庭网络是否应具有“默认拒绝”或“默认允许”位置的主题已在各种IETF会议上进行了详细讨论，但未就哪种方法更合适达成任何共识。此外，应用哪种默认设置的选择可能是情境性的，因此除了RFC 6092中关于此主题的内容外，本文对默认设置不作任何建议。我们在下面的第3.6.3节中注意到，IPv4 NAT的隐式防火墙功能在今天很常见，因此，面向家庭网络的未来CE路由器应继续支持在“默认拒绝模式”下运行的选项，无论这是否是默认设置。
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).
在某些情况下，可能不需要完全的内部连接，例如，在某些公用事业网络场景中，或者出于策略原因需要对来宾网络子网进行过滤。因此，某些场景/模型可能涉及使用自己的CE路由器运行隔离子网。在这种情况下，只能在每个隔离网络内实现连接（尽管流量可能通过外部提供商在它们之间传递）。
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.
LLN提供了另一个示例，说明家庭网络中可能存在安全周界。受约束的LLN节点可以实现网络密钥安全，但可能取决于LLN边界路由器强制实施的访问策略。
Considerations for differentiating neighbouring homenets are discussed in Section 3.3.1.
第3.3.1节讨论了区分相邻家庭网络的注意事项。
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.
通过模糊（地址转换）或防火墙（过滤）实现的安全性充其量只能部分有效。家庭电脑、家庭网络、商用PC电脑和网络的安全记录非常差，这就是证明。任何设备的防火墙后面的安全隐患都会暴露所有其他设备，使得依赖隐蔽性或防火墙的整个网络与网络私有端最不安全的设备一样容易受到攻击。
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].
然而，鉴于目前有证据表明家庭网络产品的默认设备安全性非常差，设置防火墙确实提供了一定程度的保护。如今，防火墙的使用，无论是否是一种良好的做法，都是一种常见的做法，通过“默认拒绝”设置提供保护的能力，即使只是略微有效，也不应丧失。因此，尽管非常希望家庭网络中的所有主机都能受到内置安全功能的充分保护，但也应假设所有CE路由器将继续支持[RFC7084]中规定的适当周界防御功能。
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.
虽然目前尚不清楚如何轻松避免此类外渗，但应该认识到这种威胁，无论是来自新的硬件还是安装在个人设备上的某些“应用程序”。
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.
就设备而言，homenet主机应根据其计算能力实施自己的安全策略。他们应该能够请求透明的通信，这些通信可以通过家庭网络中的安全过滤器启动，用于所有端口或特定服务。用户应该有简单的方法将设备与他们希望通过（CE路由器）边界透明操作的服务相关联。
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.6节所述，如果按照RFC 7084中要求s-2的规定，CE路由器上有适当的过滤，则可以将ULA源地址作为本地源流量的指示。该指示随后可与安全设置一起使用，以指定允许特定应用程序在哪些节点之间通信，前提是在领域边界处适当过滤ULA地址空间。
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.
homenet要求设备能够确定和使用唯一的名称，通过这些名称可以在网络上访问这些设备，并且网络上的其他设备不使用这些设备。用户和设备需要能够发现网络上可用的设备和服务，例如媒体服务器、打印机、显示器或特定的家庭自动化设备。因此，homenet中必须支持命名和服务发现，鉴于典型家庭网络用户的性质，提供此功能的服务必须尽可能支持非托管操作。
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.
命名系统需要在内部或外部工作，无论用户是在家庭网络内部还是外部，也就是说，用户应该能够通过名称引用设备，并可能连接到设备，无论它们位于何处。考虑此类命名和服务发现最自然的方式是使其能够跨整个homenet住宅（站点）工作，而不考虑子网等技术边界，但尊重来宾和其他内部网络领域之间的政策边界。homenet居民在旅行时可能需要远程访问，但制造商或其他“善意”第三方也可能需要远程访问。
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.
用户通常会通过图形用户界面（GUI）执行服务发现，图形用户界面允许他们以适当和直观的方式浏览网络上的服务。设备可能还需要在没有任何用户干预或选择的情况下发现其他设备。无论哪种方式，此类接口都超出了本文档的范围，但该接口应具有适当的应用程序编程接口（API），以便执行发现。
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.
我们注意到，当前的零配置服务发现协议通常针对单个子网。因此，对于多子网家庭网络，可以选择是否应代理或扩展此类协议以跨整个家庭网络运行。在此上下文中，这可能意味着桥接链路本地方法，注意避免分组进入循环路径，或者扩展用于此目的的多播通信量的范围。这可能意味着使用了一些代理或混合服务，可能共同驻留在CE路由器上。或者，新方法可能更可取，例如，将家庭网络周围的信息作为路由协议内的属性进行泛洪（这可能允许每个前缀配置）。然而，我们应该更喜欢向后兼容并允许继续使用当前实现的方法。请注意，本文件并未规定特定的解决方案；相反，它表达了homenet命名和服务发现环境应该使用的原则。
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.
当今服务发现面临的主要挑战之一是，由于可用的服务发现协议数量不断增加，因此缺乏互操作性。虽然消费者设备可以支持多种发现协议，但这显然不是对网络和计算资源的最有效利用。homenet体系结构的一个目标应该是通过基于标准的转换方案、与当前协议挂钩以允许发现协议之间进行某种形式的通信、扩展以支持homenet中的中央服务存储库来实现服务发现协议互操作性，或者简单地向统一的协议套件靠拢。
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.
考虑到未来可能联网的设备数量巨大，设备应能够在家庭网络中生成自己的唯一名称，并在发生冲突时检测冲突，例如。，部署与具有相同默认名称的现有设备具有相同类型/供应商的第二个设备，或者将新子网添加到已具有相同名称设备的homenet。在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>.
用户还需要简单的方法来（重新）命名设备，同样最有可能的是通过一个合适的、直观的界面，这超出了本文档的范围。请注意，用户分配给设备的名称可能是存储在设备上作为设备属性的标签，并且可能不同于名称服务中使用的名称，例如“研究激光打印机”，而不是printer2。<somedomain>。
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.
homenet名称服务应同时支持查找和发现。查找将通过对已知服务的直接查询进行操作，而发现可能使用多播消息或应用程序注册以进行查找的服务。
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].
非常希望homenet名称服务至少必须与Internet名称服务共存。还应偏向于已证实的现有解决方案。因此，这意味着homenet服务是基于DNS的，或与DNS兼容的。有一些命名协议设计用于在Internet范围内配置和运行，如基于单播的DNS，也有一些协议设计用于零配置本地环境，如多播DNS（MDN）[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.
当DNS用作homenet名称服务时，它通常包括解析服务和权威服务。权威服务托管homenet相关区域。当提供这样的名称服务时，一种方法是在CE路由器上运行权威名称服务，以及由ISP或外部第三方提供的第二权威名称服务，该名称服务旨在促进从全球互联网解析名称。
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.
在使用零配置名称服务的情况下，希望这些服务也可以与Internet名称服务共存。特别是，在homenet使用全局名称空间的情况下，希望设备能够在需要时向该名称空间添加条目。还应该有一种从全局名称空间中删除或过期此类条目的机制。
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.
为了防止诸如缓存中毒之类的攻击，其中攻击者能够在本地缓存中插入伪造的DNS条目，需要在权威服务器和解析程序端支持适当的名称服务安全方法，包括DNS安全扩展（DNSSEC）[RFC4033]。在使用DNS的情况下，homenet路由器或命名服务不得阻止DNSSEC运行。
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.
虽然本文件未规定硬件要求，但值得在此简要指出的是，例如，为了支持DNSSEC，适当的家庭网络设备应具有良好的随机数生成能力，未来的家庭网络规范应指明哪里需要高质量的随机数生成器，即具有适当的熵。
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.
最后，必须考虑CE路由器变更的影响。希望保留旧CE路由器中保存的任何相关状态（配置）。这可能意味着状态信息应该分布在家庭网络中，可以通过新的CE路由器或家庭网络的ISP或通过某种方式由外部提供的第三方服务进行恢复。
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.
如果需要从Internet上的任何位置远程访问homenet设备，则至少需要一个全局唯一的名称空间，但不应排除使用多个名称空间。一种方法是，家庭网络使用的名称空间将由家庭网络提供授权服务，最有可能是由驻留在CE路由器上的服务器提供服务。此类名称空间可由用户获取，或由其ISP或其他外部提供的服务提供/生成。默认情况下，homenet可能会使用ISP提供的全局域，但希望长期使用独立于提供商的名称空间的高级用户应该能够获取和使用自己的域名。对于希望使用自己独立域名的用户，此类服务已经可用。
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.
但是，如果全局名称空间不可用，homenet将需要选择并使用本地名称空间，该名称空间仅在本地homenet中具有意义（即，它不会用于远程访问homenet）。.local名称空间目前对某些具有链路本地范围的现有协议具有特殊意义，因此不适用于多子网家庭网络。因此，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.
选择本地名称空间的一种方法是使用不明确的本地限定域名（ALQDN）空间，例如.sitelocal（或为此目的保留的适当名称）。虽然这是一种简单的方法，但从原则上讲，一个家庭网络中的应用程序以某种方式通过名称为设备添加书签的设备可能会与另一个家庭网络中具有相同名称的设备混淆。然而，在实践中，底层服务发现协议应该能够处理移动到网络的情况，其中新设备使用的名称与以前在另一个家庭网络中使用的设备相同。
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.
本地名称空间的另一种方法是使用唯一的本地限定域名（ULQDN）空间，例如。<UniqueString>.sitelocal。<UniqueString>可以通过多种方式生成，其中一种可能基于整个homenet中使用的本地/48 ULA前缀。这样的<UniqueString>应该能够经受冷重启，即在网络断电后保持一致，或者如果启动时未设置值，则运行名称服务的CE路由器或设备应该生成默认值。homenet用户希望能够使用自己选择的值覆盖<UniqueString>，但这会增加名称冲突的可能性。任何生成的<UniqueString>都不应是可预测的；因此，需要添加salt/hash函数。
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).
如果（可能）可以从homenet外部访问homenet（使用全局名称空间），homenet名称空间必须遵循全局名称空间的规则和约定。在此操作模式下，homenet中的名称（包括设备自动生成的名称）必须可用作全局名称空间中的标签。[RFC5890]介绍了在应用程序（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].
此外，随着新的“无点”顶级域的引入，例如，名为“计算机”的本地主机和（如果已注册）计算机通用顶级域（gTLD）之间也可能存在歧义。因此，无论是否向用户公开，都应始终使用限定名称。IAB已经发布了一份声明，解释了为什么无点域名应该被认为是有害的[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.
可能的情况是，如果有两个或多个CE路由器服务于家庭网络，如果每个路由器都有一个由不同ISP授权的名称空间，则家庭中的设备有可能在多个域下具有多个完全限定的名称。
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.
可能的情况是，并非家庭网络中的所有设备都通过互联网名称空间按名称提供，并且对于某些设备而言，“拆分视图”（如[RFC6950]第4节所述）是首选的，因此家庭网络内的设备可以看到与外部设备不同的DNS响应。
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.
最后，本文对反向查找服务的存在或不存在不作任何假设。有一种观点认为，它可能有助于使用有意义的设备名称而不是文字地址向用户显示日志信息。还有一些服务，尤其是电子邮件交换器，一些运营商选择在接受连接之前要求有效的反向查找。
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.
如上所述，使用缓存的本地权威名称服务的方法将允许对持续的ISP中断进行本地操作。
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.
ISP的更改不应影响本地命名和服务发现。但是，如果homenet使用ISP提供的全局名称空间，那么如果用户更改其网络提供商，这显然会产生影响。
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.
在家庭网络的某些部分，特别是LLN或使用电池供电的任何设备中，设备可能处于休眠状态，在这种情况下，可能需要此类节点的代理，该代理可以响应（例如）多播服务发现请求。这些相同的设备或网络的部分可能具有较少的多播流量容量，这些流量可能来自网络的其他部分。一般来说，考虑到网络技术和服务可能需要通过的受限设备，消息利用应该是高效的。
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.
目前正在努力确定LLN网络中受约束应用程序协议（CoAP）[RFC7252]使用的命名和发现解决方案。这些不在本文件的范围内。
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.
需要自动发现名称服务，以允许homenet中的客户端设备解析Internet上的外部域，并且此类发现必须支持远离名称服务的多个路由器跃点的客户端。类似地，可能希望传递可能对家庭网有效的任何DNS域搜索列表。
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.
一些在homenet Internet名称空间中注册了名称的移动设备可能会在其他位置连接到Internet，并在这些位置获取IP地址。设备可能在不同的家庭网络之间移动。在这种情况下，期望设备可以用其家庭网络中使用的相同名称来访问。
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.
本文档中未讨论此问题的解决方案。它们可能包括使用移动IPv6或动态DNS（其中任何一种都会对家庭网络提出额外的要求），或者建立到家庭网络中服务器的（VPN）隧道。
This section discusses two other considerations for home networking that the architecture should not preclude but that this text is neutral towards.
本节讨论了家庭网络的两个其他注意事项，该架构不应排除这两个注意事项，但本文对这两个注意事项保持中立。
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.
支持多服务家庭网络中的服务质量（QoS）可能是一项要求，例如，对于关键系统（可能与医疗保健相关）或不同类型流量（文件共享、云存储、实时流媒体、IP语音（VoIP）等）的区分。不同的链接媒体类型可能具有不同的此类属性或功能。
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
但是，homenet场景不需要新的QoS协议。具有少量预定义通信量类别的Diffserv[RFC2475]方法通常是足够的，尽管目前在家庭网络中很少有QoS部署的经验。很有可能需要QoS或流量优先级方法
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).
CE路由器和可能在不同链路介质类型之间的边界附近（例如，某些通信可能根本不适合某些介质，需要丢弃以避免受约束介质过载）。
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].
还可能存在有助于homenet域中的应用程序性能和行为的补充机制，如确保使用[Gettys11]中所述的适当缓冲算法。
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.
在本节中，我们将简要回顾本文档中描述的homenet类型中操作和管理的一些初始注意事项。预计将有一份单独的文件为此类家庭网络定义适当的运营和管理框架。
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.
如本文档所述，家庭网络的总体目标应该是从网络层的角度进行自组织和自配置，例如，前缀应该能够分配给路由器接口。此外，在设备上运行的应用程序应该能够使用零配置服务发现协议来发现家庭用户感兴趣的服务。相反，例如，家庭用户不需要为链路分配前缀或管理家庭网络的DNS条目。不应排除此类专家操作，但这并非常态。
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.
用户可能仍然需要或希望执行网络及其设备的一些配置。示例可能包括输入安全密钥以允许访问其无线网络，或选择为通过服务发现提供给他们的设备提供“友好名称”。链接层和应用层服务的配置不在本体系结构原则文档的范围内，但在可操作的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.
虽然不希望用户主动配置其家庭网络的网络元素，但用户可能希望能够查看其网络和连接到该网络的设备的状态，在这种情况下，需要适当的网络监控协议来允许用户查看其网络及其状态，例如。，通过web界面或同等方式。虽然用户可能不了解网络如何运行，但可以合理地假设他们有兴趣了解网络上可能存在哪些故障或问题。此类监控可以扩展到网络上的其他设备，例如存储设备或网络摄像机，但此类设备超出了本文档的范围。
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.
也可能是ISP或第三方希望代表用户为家庭网络提供远程管理服务，或者在用户遇到问题时能够帮助用户，在这种情况下，需要适当的管理和监控协议。
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.
指定促进homenet管理和监视所需的协议超出了本文档的范围。如上所述，预计将编制一份单独的文件，描述本文件中所述家庭网络类型的运营和管理框架。
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.
最后一点，我们注意到，所有网络管理和监视功能都应该通过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.
此体系结构文本鼓励重用现有协议。因此，必要的机制在很大程度上已经是IPv6协议集和常见实现的一部分，尽管也有一些例外。
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
在为家庭网络IPv6体系结构开发解决方案时，一些最难解决的问题包括发现“家庭”域结束和服务提供商域开始的正确边界，决定某些必要的发现机制扩展是否应仅影响网络基础设施或主机，以及
ability to turn on routing, prefix delegation, and other functions in a backwards-compatible manner.
能够以向后兼容的方式打开路由、前缀委派和其他功能。
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.
本文定义了homenet体系结构的原则和要求。任何未来描述homenet路由、前缀管理、安全性、命名或服务发现协议的文本都应遵守此处记录的原则和要求。
Security considerations for the homenet architecture are discussed in Section 3.6 above.
上文第3.6节讨论了homenet体系结构的安全注意事项。
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998, <http://www.rfc-editor.org/info/rfc2460>.
[RFC2460]Deering，S.和R.Hinden，“互联网协议，第6版（IPv6）规范”，RFC 2460，1998年12月<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>.
[RFC3633]Troan，O.和R.Droms，“动态主机配置协议（DHCP）版本6的IPv6前缀选项”，RFC 3633，2003年12月<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>.
[RFC4193]Hinden，R.和B.Haberman，“唯一本地IPv6单播地址”，RFC 41932005年10月<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>.
[RFC4291]Hinden，R.和S.Deering，“IP版本6寻址体系结构”，RFC 42912006年2月<http://www.rfc-editor.org/info/rfc4291>.
[RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, February 1996, <http://www.rfc-editor.org/info/rfc1918>.
[RFC1918]Rekhter，Y.，Moskowitz，R.，Karrenberg，D.，Groot，G.，和E.Lear，“私人互联网地址分配”，BCP 5，RFC 1918，1996年2月<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>.
[RFC2475]Blake，S.，Black，D.，Carlson，M.，Davies，E.，Wang，Z.，和W.Weiss，“差异化服务架构”，RFC 24751998年12月<http://www.rfc-editor.org/info/rfc2475>.
[RFC2775] Carpenter, B., "Internet Transparency", RFC 2775, February 2000, <http://www.rfc-editor.org/info/rfc2775>.
[RFC2775]Carpenter，B.，“互联网透明度”，RFC 27752000年2月<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>.
[RFC2827]Ferguson，P.和D.Senie，“网络入口过滤：击败利用IP源地址欺骗的拒绝服务攻击”，BCP 38，RFC 2827，2000年5月<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>.
[RFC3002]Mitzel，D.，“2000年IAB无线互联车间概述”，RFC 30022000年12月<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>.
[RFC3022]Srisuresh，P.和K.Egevang，“传统IP网络地址转换器（传统NAT）”，RFC 30222001年1月<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>.
[RFC4033]Arends，R.，Austein，R.，Larson，M.，Massey，D.，和S.Rose，“DNS安全介绍和要求”，RFC 4033，2005年3月<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>.
[RFC4191]Draves，R.和D.Thaler，“默认路由器首选项和更具体的路由”，RFC 41912005年11月<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>.
[RFC4192]Baker，F.，Lear，E.和R.Droms，“在没有国旗日的情况下重新编号IPv6网络的程序”，RFC 41922005年9月<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>.
[RFC4607]Holbrook，H.和B.Cain，“IP的源特定多播”，RFC4607，2006年8月<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>.
[RFC4862]Thomson，S.，Narten，T.和T.Jinmei，“IPv6无状态地址自动配置”，RFC 48622007年9月<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>.
[RFC4864]Van de Velde，G.，Hain，T.，Droms，R.，Carpenter，B.，和E.Klein，“IPv6的本地网络保护”，RFC 4864，2007年5月<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>.
[RFC4941]Narten，T.，Draves，R.，和S.Krishnan，“IPv6中无状态地址自动配置的隐私扩展”，RFC 49412007年9月<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>.
[RFC5533]Nordmark，E.和M.Bagnulo，“Shim6:IPv6的3级多主垫片协议”，RFC 55332009年6月<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>.
[RFC5890]Klensin，J.“应用程序的国际化域名（IDNA）：定义和文档框架”，RFC 58902010年8月<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>.
[RFC5969]Townsley，W.和O.Troan，“IPv4基础设施上的IPv6快速部署（第6条）——协议规范”，RFC 5969，2010年8月<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>.
[RFC6092]Woodyatt，J.，“提供住宅IPv6互联网服务的客户场所设备（CPE）中推荐的简单安全功能”，RFC 6092，2011年1月<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>.
[RFC6144]Baker，F.，Li，X.，Bao，C.，和K.Yin，“IPv4/IPv6转换框架”，RFC 61442011年4月<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>.
[RFC6145]Li，X.，Bao，C.，和F.Baker，“IP/ICMP转换算法”，RFC61452011年4月<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>.
[RFC6177]Narten，T.，Huston，G.和L.Roberts，“终端站点的IPv6地址分配”，BCP 157，RFC 6177，2011年3月<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>.
[RFC6204]Singh，H.，Beebee，W.，Donley，C.，Stark，B.，和O.Troan，“IPv6客户边缘路由器的基本要求”，RFC 62042011年4月<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>.
[RFC6296]Wasserman，M.和F.Baker，“IPv6到IPv6网络前缀转换”，RFC 62962011年6月<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>.
[RFC6333]Durand，A.，Droms，R.，Woodyatt，J.，和Y.Lee，“IPv4耗尽后的双栈Lite宽带部署”，RFC 63332011年8月<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>.
[RFC6555]Wing，D.和A.Yourtchenko，“快乐眼球：双堆栈主机的成功”，RFC 65552012年4月<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>.
[RFC6724]Thaler，D.，Draves，R.，Matsumoto，A.，和T.Chown，“互联网协议版本6（IPv6）的默认地址选择”，RFC 67242012年9月<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>.
[RFC6762]Cheshire，S.和M.Krochmal，“多播DNS”，RFC 67622013年2月<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>.
[RFC6824]Ford，A.，Raiciu，C.，Handley，M.，和O.Bonaventure，“多地址多路径操作的TCP扩展”，RFC 68242013年1月<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>.
[RFC6887]南柴郡Wing，D.，布卡达尔，M.，佩诺，R.，和P.Selkirk，“港口控制协议（PCP）”，RFC 6887，2013年4月<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>.
[RFC6950]Peterson，J.，Kolkman，O.，Tschofenig，H.，和B.Aboba，“DNS中应用程序功能的架构考虑”，RFC 69502013年10月<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>.
[RFC7084]Singh，H.，Beebee，W.，Donley，C.，和B.Stark，“IPv6客户边缘路由器的基本要求”，RFC 7084，2013年11月<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>.
[RFC7157]Troan，O.，Miles，D.，Matsushima，S.，Okimoto，T.，和D.Wing，“无网络地址转换的IPv6多宿主”，RFC 7157，2014年3月<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>.
[RFC7252]Shelby，Z.，Hartke，K.和C.Bormann，“受限应用协议（CoAP）”，RFC 7252，2014年6月<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>.
[IABdotless]IAB，“IAB声明：被认为有害的无点域名”，2013年2月<http://www.iab.org/documents/ 通信报告文件/2013-2/iab声明被认为有害的无点域>。
[Gettys11] Gettys, J., "Bufferbloat: Dark Buffers in the Internet", March 2011, <http://www.ietf.org/proceedings/80/slides/tsvarea-1.pdf>.
[Gettys11]Gettys，J.，“缓冲区膨胀：互联网中的暗缓冲区”，2011年3月<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.
作者要感谢米凯尔·阿布拉罕松、艾默尔·阿克特、马克·安德鲁斯、德米特里·阿尼普科、冉·阿特金森、弗雷德·贝克、雷·贝利斯、特科·布特、约翰·布佐夫斯基、卡梅隆·伯恩、布赖恩·卡彭特、斯图尔特·切希尔、朱利叶斯·克洛博切克、洛伦佐·科利蒂、罗伯特·克拉吉、埃尔温·戴维斯、拉尔夫·德罗姆斯、拉尔斯·艾格特、吉姆·盖蒂斯、奥拉弗·古德蒙森、瓦西姆·哈达德，乔尔·哈尔彭、大卫·哈林顿、李·霍华德、雷·亨特、乔尔·贾格利、希瑟·柯克西、特德·莱蒙、艾西·林登、克里·林恩、丹尼尔·米高、埃里克·诺德马克、迈克尔·理查森、马蒂亚·罗西、芭芭拉·斯塔克、桑德·斯特凡、马库斯·斯滕伯格、唐·斯特雷克、安德鲁·沙利文、戴夫·塔特、戴夫·泰勒、迈克尔·托马斯、马克·汤斯利、JP·瓦修尔、，感谢Curtis Villamizar、Russ White、Dan Wing和James Woodyatt在homenet工作组会议和工作组邮件列表中的评论和贡献。确认通常意味着一个人的文本进入了文档，或者有助于澄清或加强文档的某个方面。这并不意味着每个投稿人都同意文件中的每一点。
Authors' Addresses
作者地址
Tim Chown (editor) University of Southampton Highfield Southampton, Hampshire SO17 1BJ United Kingdom
Tim Chown（编辑）南安普敦大学HiFrfield南安普顿，汉普郡SO17 1BJ英国
EMail: tjc@ecs.soton.ac.uk
EMail: tjc@ecs.soton.ac.uk
Jari Arkko Ericsson Jorvas 02420 Finland
雅丽爱立信芬兰公司02420
EMail: jari.arkko@piuha.net
EMail: jari.arkko@piuha.net
Anders Brandt Sigma Designs Emdrupvej 26A, 1 Copenhagen DK-2100 Denmark
丹麦哥本哈根DK-2100，安德斯·勃兰特·西格玛设计公司Emdrupvej 26A
EMail: anders_brandt@sigmadesigns.com
EMail: anders_brandt@sigmadesigns.com
Ole Troan Cisco Systems, Inc. Philip Pedersensvei 1 Lysaker, N-1325 Norway
Ole Troan Cisco Systems，Inc.Philip Pedersensvei 1 Lysaker，N-1325挪威
EMail: ot@cisco.com
EMail: ot@cisco.com
Jason Weil Time Warner Cable 13820 Sunrise Valley Drive Herndon, VA 20171 United States
Jason Weil时代华纳有线电视13820美国弗吉尼亚州赫恩登日出谷大道20171
EMail: jason.weil@twcable.com
EMail: jason.weil@twcable.com