Network Working Group E. Lear
Request for Comments: 4219 Cisco Systems
Category: Informational October 2005
Network Working Group E. Lear
Request for Comments: 4219 Cisco Systems
Category: Informational October 2005
Things Multihoming in IPv6 (MULTI6) Developers Should Think About
IPv6（MULTI6）中的多宿主开发人员应该考虑的事情
Status of this Memo
本备忘录的状况
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
本备忘录为互联网社区提供信息。它没有规定任何类型的互联网标准。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2005).
版权所有（C）互联网协会（2005年）。
Abstract
摘要
This document specifies a set of questions that authors should be prepared to answer as part of a solution to multihoming with IPv6. The questions do not assume that multihoming is the only problem of interest, nor do they demand a more general solution.
本文档指定了一组问题，作为IPv6多宿主解决方案的一部分，作者应准备回答这些问题。这些问题并不认为多宿是唯一令人感兴趣的问题，也不需要更普遍的解决方案。
Table of Contents
目录
1. Introduction ....................................................3
1.1. Reading this Document ......................................3
2. On the Wire Behavior ............................................4
2.1. How will your solution solve the multihoming problem? ......4
2.2. At what layer is your solution applied, and how? ...........4
2.3. Why is the layer you chose the correct one? ................4
2.4. Does your solution address mobility? .......................4
2.5. Does your solution expand the size of an IP packet? ........4
2.6. Will your solution add additional latency? .................4
2.7. Can multihoming capabilities be negotiated
end-to-end during a ........................................4
2.8. Do you change the way fragmenting is handled? ..............5
2.9. Are there any layer 2 implications to your proposal? .......5
3. Identifiers and Locators ........................................5
3.1. Uniqueness .................................................5
3.2. Does your solution provide for a split between
identifiers and ............................................5
3.3. What is the lifetime of a binding from an
identifier to a locator? ...................................5
3.4. How is the binding updated? ................................5
3.5. How does a host know its identity? .........................5
3.6. Can a host have multiple identifiers? ......................5
1. Introduction ....................................................3
1.1. Reading this Document ......................................3
2. On the Wire Behavior ............................................4
2.1. How will your solution solve the multihoming problem? ......4
2.2. At what layer is your solution applied, and how? ...........4
2.3. Why is the layer you chose the correct one? ................4
2.4. Does your solution address mobility? .......................4
2.5. Does your solution expand the size of an IP packet? ........4
2.6. Will your solution add additional latency? .................4
2.7. Can multihoming capabilities be negotiated
end-to-end during a ........................................4
2.8. Do you change the way fragmenting is handled? ..............5
2.9. Are there any layer 2 implications to your proposal? .......5
3. Identifiers and Locators ........................................5
3.1. Uniqueness .................................................5
3.2. Does your solution provide for a split between
identifiers and ............................................5
3.3. What is the lifetime of a binding from an
identifier to a locator? ...................................5
3.4. How is the binding updated? ................................5
3.5. How does a host know its identity? .........................5
3.6. Can a host have multiple identifiers? ......................5
3.7. If you have separate locators and identifiers, how
will they be ...............................................5
3.8. Does your solution create an alternate "DNS-like"
service? ...................................................5
3.9. Please describe authentication/authorization ...............6
3.10. Is your mechanism hierarchical? ...........................6
3.11. Middlebox interactions ....................................6
3.12. Are there any implications for scoped addressing? .........6
4. Routing System Interactions .....................................6
4.1. Does your solution change existing aggregation methods? ....6
4.2. Does the solution solve traffic engineering requirements? ..7
4.3. Does the solution offer ways for the site to manage
its traffic ................................................7
4.4. If you introduce any new name spaces, do they
require aggregation? .......................................7
4.5. Does your solution interact with Autonomous System
numbering? .................................................7
4.6. Are there any changes to ICMP error semantics? .............7
5. Name Service Interactions .......................................7
5.1. Please explain the relationship of your solution to DNS ....7
5.2. Please explain interactions with "2-faced" DNS .............7
5.3. Does your solution require centralized registration? .......8
5.4. Have you checked for DNS circular dependencies? ............8
5.5. What if a DNS server itself is multihomed? .................8
5.6. What additional load will be placed on DNS servers? ........8
5.7. Any upstream provider support required? ....................8
5.8. How do you debug connectivity? .............................8
6. Application Concerns and Backward Compatibility .................8
6.1. What application/API changes are needed? ...................8
6.2. Is this solution backward compatible with "old" IP
version 6? .................................................9
6.3. Is your solution backward compatible with IPv4? ............9
6.4. Can IPv4 devices take advantage of this solution? ..........9
6.5. What is the impact of your solution on different
types of sites? ............................................9
6.6. How will your solution interact with other middleboxes? ...10
6.7. Referrals .................................................10
6.8. Demonstrate use with a real life complex application ......10
7. Legal Concerns .................................................10
8. Security Considerations ........................................10
9. Acknowledgements ...............................................11
10. References ....................................................11
10.1. Normative References .....................................11
10.2. Informative References ...................................11
3.7. If you have separate locators and identifiers, how
will they be ...............................................5
3.8. Does your solution create an alternate "DNS-like"
service? ...................................................5
3.9. Please describe authentication/authorization ...............6
3.10. Is your mechanism hierarchical? ...........................6
3.11. Middlebox interactions ....................................6
3.12. Are there any implications for scoped addressing? .........6
4. Routing System Interactions .....................................6
4.1. Does your solution change existing aggregation methods? ....6
4.2. Does the solution solve traffic engineering requirements? ..7
4.3. Does the solution offer ways for the site to manage
its traffic ................................................7
4.4. If you introduce any new name spaces, do they
require aggregation? .......................................7
4.5. Does your solution interact with Autonomous System
numbering? .................................................7
4.6. Are there any changes to ICMP error semantics? .............7
5. Name Service Interactions .......................................7
5.1. Please explain the relationship of your solution to DNS ....7
5.2. Please explain interactions with "2-faced" DNS .............7
5.3. Does your solution require centralized registration? .......8
5.4. Have you checked for DNS circular dependencies? ............8
5.5. What if a DNS server itself is multihomed? .................8
5.6. What additional load will be placed on DNS servers? ........8
5.7. Any upstream provider support required? ....................8
5.8. How do you debug connectivity? .............................8
6. Application Concerns and Backward Compatibility .................8
6.1. What application/API changes are needed? ...................8
6.2. Is this solution backward compatible with "old" IP
version 6? .................................................9
6.3. Is your solution backward compatible with IPv4? ............9
6.4. Can IPv4 devices take advantage of this solution? ..........9
6.5. What is the impact of your solution on different
types of sites? ............................................9
6.6. How will your solution interact with other middleboxes? ...10
6.7. Referrals .................................................10
6.8. Demonstrate use with a real life complex application ......10
7. Legal Concerns .................................................10
8. Security Considerations ........................................10
9. Acknowledgements ...............................................11
10. References ....................................................11
10.1. Normative References .....................................11
10.2. Informative References ...................................11
At the time of this writing there are quite a number of proposed solutions to the problem of multihoming within IPv6, and related problems such as the locator/identifier split.
在撰写本文时，对于IPv6中的多宿问题以及诸如定位器/标识符拆分等相关问题，有许多建议的解决方案。
This document contains several sets of questions that attempt to focus these solutions on operational problems. This document does not suggest methods to solve the problem. Rather, we simply want to ensure that while solving a problem the medicine is not worse than the cure. We focus on practical operational problems that both single-homed and multihomed deployments may face.
本文档包含多组问题，试图将这些解决方案集中在操作问题上。本文件不建议解决该问题的方法。相反，我们只是想确保在解决问题时，药物不会比治疗更糟糕。我们关注单宿和多宿部署可能面临的实际操作问题。
It is the hope of the author that perhaps the authors of other proposed solutions will use this document to identify gaps in their solutions, and cooperate to close those gaps.
作者希望，其他拟议解决方案的作者可能会使用本文件来确定其解决方案中的差距，并进行合作以弥补这些差距。
The questions are organized along the following lines:
这些问题按照以下思路组织：
o changes to on the wire behavior; o routing system interactions; o identifier/mapping split; o application concerns and backward compatibility; o name service interactions; o legal concerns; and o security considerations.
o 对在线行为的更改；o路由系统交互；o标识符/映射拆分；o应用程序问题和向后兼容性；o名称服务交互；o法律问题；和o安全考虑。
In reality many questions cut across all of these concerns. For instance, the identifier / locator split has substantial application implications, and every area has security considerations.
事实上，许多问题涉及所有这些问题。例如，标识符/定位器拆分具有实质性的应用影响，每个领域都有安全考虑。
Unless it is blatantly obvious, each question contains some reasoning as to why it is being asked. It is envisioned that no solution will answer every question with completeness, but that there will be tradeoffs to be made. The answers by the various designers of solutions will hopefully shed some light on which tradeoffs we as a community wish to make.
除非它是显而易见的，否则每个问题都包含一些关于为什么要问它的推理。可以预见，没有任何解决方案能够完整地回答每个问题，但需要做出权衡。各种解决方案设计者的回答有望为我们社区希望做出的权衡提供一些启示。
It would seem silly for people who have written detailed answers to these questions to have to repeat the exercise. Therefore, a simple reference to existing documents will suffice, so long as the answer is complete. If it is not complete, then feel free to reference it and add what text is necessary to make the answer complete.
对于那些为这些问题写了详细答案的人来说，重复练习似乎是愚蠢的。因此，只要答案是完整的，简单地参考现有文件就足够了。如果答案不完整，请随意参考，并添加使答案完整所需的文本。
This document presumes a familiarity with RFC 3582 [2], and does not attempt to repeat the requirements work gathered there.
本文件假定熟悉RFC 3582[2]，并不试图重复此处收集的需求工作。
Please scope the problem you are attempting to solve and what you are not attempting to solve.
请确定您试图解决的问题和您不试图解决的问题的范围。
Is it applied in every packet? If so, what fields are used?
它适用于每个包吗？如果是，使用了哪些字段？
Each layer has its benefits and tradeoffs. For instance, transport layer solutions would require that EVERY transport be modified, while IP layer solutions may entail expansion of the packet or a change to the pseudo-header (thus requiring changes to the transport layer).
每一层都有其优点和权衡。例如，传输层解决方案需要修改每个传输，而IP层解决方案可能需要扩展数据包或更改伪报头（因此需要更改传输层）。
If so, how are rendezvous handled? Can your solution handle both locators changing at the same time? If so, please explain. Should it? If not, how will your solution interact with MOBILEIP-V6 [3] (MIPv6)
如果是，会合点是如何处理的？您的解决方案能否同时处理两个定位器的更改？如果是，请解释。应该吗？如果没有，您的解决方案将如何与MOBILEIP-V6[3]（MIPv6）交互
Expanding the size of an IP packet may cause excessive fragmentation in some circumstances.
在某些情况下，扩展IP数据包的大小可能会导致过度碎片化。
Latency is an important factor in many applications, including voice. Any substantial amount of additional latency, including session initiation would be highly undesirable.
延迟是许多应用程序中的一个重要因素，包括语音。任何大量的额外延迟（包括会话启动）都是非常不可取的。
2.7. Can multihoming capabilities be negotiated end-to-end during a connection?
2.7. 在连接过程中是否可以端到端协商多主功能？
If the proposal introduces additional overhead, can the information be somehow piggybacked on messages that are already used? This would be useful in order to keep connection setup constant. Please also indicate any drawbacks that might apply due to this piggybacking.
如果提案引入了额外的开销，那么这些信息是否可以以某种方式承载在已经使用的消息上？这将有助于保持连接设置不变。还请指出由于这种背驮可能存在的任何缺陷。
If you use a shim approach, do you fragment above or below the shim? How are fragments identified, so that they can be reassembled? If you use any additional names, do they need to be associated with fragments? If not, why not? If so, how will that happen?
如果使用填隙片方法，是否在填隙片上方或下方形成碎片？如何识别碎片，以便重新组装？如果您使用任何其他名称，它们是否需要与片段关联？若否，原因为何？如果是的话，那将如何发生？
While IPv6 has a simplified approach to layer 2, perhaps you unsimplified it. If so, please provide details.
虽然IPv6对第2层有一个简化的方法，但您可能没有简化它。如果是，请提供详细信息。
3.2. Does your solution provide for a split between identifiers and locators?
3.2. 您的解决方案是否提供标识符和定位器之间的拆分？
Will transport connections remain up when new paths become available or when old ones become unavailable? How does the end node discover these events?
当新路径可用或旧路径不可用时，传输连接是否保持正常？终端节点如何发现这些事件？
If you are establishing a new identity, how does the host learn it?
如果你正在建立一个新的身份，主人是如何知道的？
If so, how does an application choose an identity?
如果是，应用程序如何选择标识？
3.7. If you have separate locators and identifiers, how will they be mapped?
3.7. 如果有单独的定位器和标识符，它们将如何映射？
Does the mapping work in both directions? How would someone debugging a network determine which end stations are involved?
映射在两个方向都有效吗？调试网络的人员如何确定涉及哪些终端站？
If you use mechanisms other than DNS, first, why was DNS not appropriate? Also, how will this other mechanism interact with DNS? What are its scaling properties?
如果您使用DNS以外的机制，首先，为什么DNS不合适？另外，这个其他机制将如何与DNS交互？它的缩放特性是什么？
How are bindings authenticated and authorized. What technology do you build on for this mechanism?
绑定如何进行身份验证和授权。这种机制基于什么技术？
Please describe the hierarchical breakdown.
请描述层级分解。
What are the implications for firewalls? What are the interactions with Network Address Translation (NAT)? What are the interactions with web caches? What complications are introduced with your solution? For instance, are there implication for ingress filters? If so, what are they?
防火墙的含义是什么？与网络地址转换（NAT）的交互作用是什么？与web缓存的交互是什么？您的解决方案引入了哪些复杂因素？例如，对入口过滤器是否有影响？如果是，它们是什么？
When considering this question, there are really two issues. First, will middleboxes impede your solution by rewriting headers in some way, as NATs do for IP addresses, and web caches do at higher layers? Second, is there a way in which middleboxes are actually part of your solution? In particular, are they required? This would be the case, for example, with Generalized Structure Element (GSE) (8+8).
在考虑这个问题时，实际上有两个问题。首先，中间盒是否会像NAT对IP地址和web缓存在更高层所做的那样，以某种方式重写报头，从而阻碍您的解决方案？第二，是否有一种方式可以让中间包成为您的解决方案的一部分？特别是，它们是必需的吗？例如，广义结构元素（GSE）（8+8）就是这种情况。
Please see RFC 3513 [1]. How does your mechanism interact with multicast?
请参见RFC 3513[1]。您的机制如何与多播交互？
How does your solution interact with link-local addressing
您的解决方案如何与链接本地寻址交互
How does your solution interact with Son-Of-Sitelocal (whatever that will be)?
您的解决方案如何与Sitelocal之子交互（无论是什么）？
Routing on the Internet scales today because hosts and networks can be aggregated into a relatively small number of entries. Does your solution change the way in which route aggregation occurs?
由于主机和网络可以聚合到相对较少的条目中，所以Internet上的路由现在可以扩展。您的解决方案是否会改变路由聚合的发生方式？
One of the significant goals of IPv4 multihoming solutions has been the ability to perform traffic engineering based on appropriately adjusting the BGP advertisements. If the prefixes used by such sites was be aggregated (particularly beyond the site"s border), the site"s ability to perform traffic engineering would be diminished.
IPv4多宿主解决方案的一个重要目标是能够基于适当调整BGP广告执行流量工程。如果这些站点使用的前缀被聚合（特别是在站点边界之外），那么站点执行流量工程的能力就会降低。
4.3. Does the solution offer ways for the site to manage its traffic flows?
4.3. 该解决方案是否为站点提供了管理其流量的方法？
If so, how? Is this controllable on a per-host basis, or on a per-site basis?
如果是，怎么做？这是基于每个主机还是基于每个站点的可控性？
Is it desirable or required that, in order to scale distribution of any mapping information, an aggregation method be introduced?
为了缩放任何映射信息的分布，是否需要引入聚合方法？
If your solution involves address prefixes distributed using BGP4+, does it interact with the use of AS numbers and, if so, how? Will it require additional AS numbers?
如果您的解决方案涉及使用BGP4+分发的地址前缀，那么它是否与AS数字的使用交互，如果是，如何交互？是否需要额外的AS号码？
Do you create new codes? If so, why and what do they mean? Will a host that is not aware of your scheme see them?
你会创建新代码吗？如果是，为什么以及它们的含义是什么？不知道您的方案的主机会看到它们吗？
If your solution uses new names for identifiers, please explain what mappings are defined, and how they are performed?
如果您的解决方案使用新名称作为标识符，请解释定义了哪些映射，以及它们是如何执行的？
If there are any additional administrative requirements, such as new zones or RR types to manage, please explain them as well.
如果有任何额外的管理要求，例如需要管理的新区域或RR类型，请解释它们。
2-faced DNS is used so that hosts behind a NAT get one address for internal hosts, while hosts outside the NAT get another. Similar mechanisms are used for application layer gateways, such as SOCKS [5].
使用双面DNS以便NAT后面的主机为内部主机获取一个地址，而NAT之外的主机获取另一个地址。类似的机制用于应用层网关，如SOCKS[5]。
For instance, if you are using the DNS, what will be the top level domain, and how will the name space distribute through it?
例如，如果您正在使用DNS，那么顶级域是什么，名称空间如何通过它分布？
Also, how will the centralized registration be managed?
此外，如何管理集中注册？
If you are using the DNS in your solution, is it required for connectivity? What happens if the DNS fails? Can communication between the DNS resolver and the server make use of your solution? What about between the application and the resolver?
如果您在解决方案中使用DNS，连接是否需要它？如果DNS失败怎么办？DNS解析程序和服务器之间的通信能否利用您的解决方案？在应用程序和解析器之间呢？
If a link fails or a service is dropped, how will it impact DNS? Again, are there any dependency loops? Perhaps diagram out your dependencies to make sure.
如果链接失败或服务被丢弃，它将如何影响DNS？同样，是否存在依赖循环？也许可以绘制出您的依赖关系图来确保。
Can the load be distributed? Remember that DNS is optimized for READ operations.
负载可以分配吗？请记住，DNS针对读取操作进行了优化。
If so, please describe. For instance, currently reverse mappings are delegated down from upstream providers. How would this work with your solution?
如果是，请说明。例如，当前反向映射是从上游提供者向下委派的。这将如何与您的解决方案配合使用？
How would tools like ping and traceroute need to be enhanced? What additional tools would prove useful or necessary? For instance, if there is an id/locator split, can one ping an identifier? If so, what gets returned?
ping和traceroute等工具需要如何增强？哪些额外的工具将被证明是有用的或必要的？例如，如果存在id/定位器拆分，是否可以使用一个ping-an标识符？如果是，返回的是什么？
Will old code work with the new mechanism? For instance, what about code that uses gethostbyname()?
旧代码能与新机制一起工作吗？例如，使用gethostbyname（）的代码呢？
Will getaddrinfo() need to change?
getaddrinfo（）是否需要更改？
What about other API calls?
其他API调用呢？
There are several possible approaches. For instance, a multihoming service could attempt to require no changes to the API, in which case it is possible that IP addresses might become opaque blobs that work with the API, but might break operational assumptions that applications make about addresses. Consider the case of a web server that wants to log IP addresses. How will it accomplish this task?
有几种可能的方法。例如，多宿主服务可能尝试不要求对API进行任何更改，在这种情况下，IP地址可能会成为与API一起工作的不透明blob，但可能会打破应用程序对地址的操作假设。考虑一个想要记录IP地址的Web服务器的情况。它将如何完成这项任务？
Another approach is to have some sort of compatibility library for legacy applications, but also provide a richer calling interface for transparency.
另一种方法是为遗留应用程序提供某种兼容性库，但也提供更丰富的调用接口以提高透明度。
Yet another approach would be to only provide the new functionality to those applications that make use of a new calling interface.
另一种方法是只向那些使用新调用接口的应用程序提供新功能。
One useful exercise would be to provide code fragments that demonstrate any API changes.
一个有用的练习是提供演示任何API更改的代码片段。
Can it be deployed incrementally? Please describe how.
可以增量部署吗？请描述一下怎么做。
Does your solution impose requirements on non-multihomed/non-mobile hosts?
您的解决方案是否对非多址/非移动主机提出了要求？
What happens if someone plugs in a normal IPv6 node?
如果有人插入正常的IPv6节点，会发生什么情况？
How will your mechanism interact with 6to4 gateways and IPv4 hosts?
您的机制将如何与6to4网关和IPv4主机交互？
Can the same mechanism somehow be used on the existing network? N.B. this is NOT a primary consideration, but perhaps a side benefit of a particular solution.
在现有网络上是否可以使用相同的机制？注意：这不是主要考虑因素，但可能是特定解决方案的附带好处。
What will the impact of your solution be on the following types of systems?
您的解决方案会对以下类型的系统产生什么影响？
o single homed sites o small multihomed sites o large multihomed sites o ad-hoc sites o short lived connections (think aggregator wireless ISPs)
o 单主机站点o小型多主机站点o大型多主机站点o临时站点o短命连接（想想聚合器无线ISP）
In particular, consider ongoing administration, renumbering events, and mobile work forces.
特别是，考虑正在进行的管理，重新编号事件和移动劳动力。
How will your solution handle referrals, such as those within FTP or various conferencing or other peer to peer systems?
您的解决方案将如何处理推荐，例如FTP或各种会议或其他对等系统中的推荐？
Referrals exist within various other protocols, such as so-called "peer to peer" applications. Note that referrals might suffer three types of failure:
引用存在于各种其他协议中，例如所谓的“对等”应用程序。请注意，转介可能会遇到三种类型的失败：
firewall and NAT - Is there failure just as what FTP active mode experiences today with relatively simple firewalls? time-based - Is there something ephemeral about the nature of the solution that might cause a referral (such as a URL) to fail over time, more so than what we have today? location-based - If the binding varies based on where the parties are in the network, and if one moves, will they no longer be able to find each other?
防火墙和NAT—是否存在与当前FTP活动模式使用相对简单的防火墙时所遇到的故障相同的故障？基于时间的-解决方案的性质是否有一些短暂的东西可能会导致转介（如URL）随着时间的推移而失败，比我们现在的情况更严重？基于位置-如果绑定根据双方在网络中的位置而变化，并且如果一方移动，他们是否将无法再找到对方？
Provide a detailed walk-through of SIP + Real Time Streaming Protocol (SIP+RTSP) when one or several of the peers are multihomed. How does your analysis change when encrypted RTSP is used or when SIP with S/MIME end-to-end (e2e) signalling is used?
当一个或多个对等点为多宿时，提供SIP+实时流协议（SIP+RTSP）的详细演练。当使用加密RTSP或使用带S/MIME端到端（e2e）信令的SIP时，您的分析会发生怎样的变化？
Are you introducing a namespace that might involve mnemonics? Doing so might introduce trademark concerns. If so, how do you plan to address such concerns?
您是否正在引入一个可能涉及助记符的名称空间？这样做可能会引起商标问题。如果是，您计划如何解决这些问题？
Are there any organizations required to manage a new name space? If so, please describe what they are and how the method will scale.
是否需要任何组织来管理新的名称空间？如果是，请描述它们是什么以及该方法将如何扩展。
How secure should a multi6 solution be? This is a reasonable question for each solution to answer. The author opines that the worst case should be no worse than what we have today. For example, would a multi6 solution open up a host, on either end of a communication, to a time-based attack? Any such risks should be clearly stated by the authors. Considerable time should be spent on threat analysis. Please see [4] for more details.
multi6解决方案应该有多安全？对于每个解决方案来说，这都是一个合理的问题。作者认为，最坏的情况不应该比我们今天的情况更糟。例如，multi6解决方案是否会使通信两端的主机受到基于时间的攻击？作者应明确说明任何此类风险。应在威胁分析上花费大量时间。有关更多详细信息，请参见[4]。
As IP addresses can often be tied to individuals, are there any auditing or privacy concerns introduced by your solution?
由于IP地址经常与个人绑定，您的解决方案是否引入了审计或隐私问题？
The author wishes to acknowledge everyone in the multi6 group and elsewhere that is putting forward proposals. It is easy to ask questions like the ones found in this document. It is quite a bit harder to develop running code to answer them. Marcelo Bagnulo, Kurt Erik Lindqvist, Joe Touch, Patrik Faltstrom, Brian Carpenter, and Iljitsch van Beijnum provided input to this document.
作者希望感谢multi6小组和其他提出建议的人。提出像本文档中所述的问题很容易。开发运行代码来回答这些问题要困难得多。Marcelo Bagnulo、Kurt Erik Lindqvist、Joe Touch、Patrik Faltstrom、Brian Carpenter和Iljitsch van Beijnum为本文件提供了输入。
[1] Hinden, R. and S. Deering, "Internet Protocol Version 6 (IPv6) Addressing Architecture", RFC 3513, April 2003.
[1] Hinden，R.和S.Deering，“互联网协议版本6（IPv6）寻址体系结构”，RFC 3513，2003年4月。
[2] Abley, J., Black, B., and V. Gill, "Goals for IPv6 Site-Multihoming Architectures", RFC 3582, August 2003.
[2] Abley，J.，Black，B.和V.Gill，“IPv6站点多主架构的目标”，RFC 3582，2003年8月。
[3] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004.
[3] Johnson，D.，Perkins，C.，和J.Arkko，“IPv6中的移动支持”，RFC 37752004年6月。
[4] Nordmark, E., "Threats Relating to IPv6 Multihoming Solutions", RFC 4218, October 2005.
[4] Nordmark，E.“与IPv6多主解决方案有关的威胁”，RFC 4218，2005年10月。
[5] Kitamura, H., "A SOCKS-based IPv6/IPv4 Gateway Mechanism", RFC 3089, April 2001.
[5] Kitamura，H.，“基于SOCKS的IPv6/IPv4网关机制”，RFC 3089，2001年4月。
Author's Address
作者地址
Eliot Lear Cisco Systems GmbH Glatt-com, 2nd Floor CH-8301 Glattzentrum ZH Switzerland
Eliot Lear Cisco Systems GmbH Glatt com，二楼CH-8301瑞士Glattzentrum
EMail: lear@cisco.com
EMail: lear@cisco.com
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2005).
版权所有（C）互联网协会（2005年）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件及其包含的信息是按“原样”提供的，贡献者、他/她所代表或赞助的组织（如有）、互联网协会和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Intellectual Property
知识产权
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息，请参见BCP 78和BCP 79。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。