Internet Architecture Board (IAB) D. Thaler
Request for Comments: 6250 May 2011
Category: Informational
ISSN: 2070-1721
Internet Architecture Board (IAB) D. Thaler
Request for Comments: 6250 May 2011
Category: Informational
ISSN: 2070-1721
Evolution of the IP Model
IP模式的演变
Abstract
摘要
This RFC attempts to document various aspects of the IP service model and how it has evolved over time. In particular, it attempts to document the properties of the IP layer as they are seen by upper-layer protocols and applications, especially properties that were (and, at times, still are) incorrectly perceived to exist as well as properties that would cause problems if changed. The discussion of these properties is organized around evaluating a set of claims, or misconceptions. Finally, this document provides some guidance to protocol designers and implementers.
这个RFC试图记录IP服务模型的各个方面，以及它是如何随着时间的推移而发展的。特别是，它试图记录上层协议和应用程序看到的IP层属性，特别是错误地认为（有时仍然认为）存在的属性，以及如果更改会导致问题的属性。对这些属性的讨论是围绕评估一组声明或误解展开的。最后，本文档为协议设计者和实现者提供了一些指导。
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 Architecture Board (IAB) and represents information that the IAB has deemed valuable to provide for permanent record. Documents approved for publication by the IAB are not a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
本文件是互联网体系结构委员会（IAB）的产品，代表IAB认为有价值提供永久记录的信息。IAB批准发布的文件不适用于任何级别的互联网标准；见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/rfc6250.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6250.
Copyright Notice
版权公告
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2011 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.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。
Table of Contents
目录
1. Introduction ....................................................3
2. The IP Service Model ............................................4
2.1. Links and Subnets ..........................................5
3. Common Application Misconceptions ...............................5
3.1. Misconceptions about Routing ...............................5
3.1.1. Claim: Reachability is symmetric ....................5
3.1.2. Claim: Reachability is transitive ...................6
3.1.3. Claim: Error messages can be received in
response to data packets ............................7
3.1.4. Claim: Multicast is supported within a link .........7
3.1.5. Claim: IPv4 broadcast is supported ..................8
3.1.6. Claim: Multicast/broadcast is less expensive
than replicated unicast .............................8
3.1.7. Claim: The end-to-end latency of the first
packet to a destination is typical ..................8
3.1.8. Claim: Reordering is rare ...........................9
3.1.9. Claim: Loss is rare and probabilistic, not
deterministic .......................................9
3.1.10. Claim: An end-to-end path exists at a
single point in time ..............................10
3.1.11. Discussion ........................................10
3.2. Misconceptions about Addressing ...........................11
3.2.1. Claim: Addresses are stable over long
periods of time ....................................11
3.2.2. Claim: An address is four bytes long ...............12
3.2.3. Claim: A host has only one address on one interface 12
3.2.4. Claim: A non-multicast/broadcast address
identifies a single host over a long period of time 13
3.2.5. Claim: An address can be used as an
indication of physical location ....................14
3.2.6. Claim: An address used by an application is
the same as the address used for routing ...........14
3.2.7. Claim: A subnet is smaller than a link .............14
3.2.8. Claim: Selecting a local address selects
the interface ......................................15
3.2.9. Claim: An address is part of an on-link
subnet prefix ......................................15
3.2.10. Discussion ........................................15
3.3. Misconceptions about Upper-Layer Extensibility ............16
3.3.1. Claim: New transport-layer protocols can
work across the Internet ...........................16
3.3.2. Claim: If one stream between a pair of
addresses can get through, then so can another .....17
3.3.3. Discussion .........................................17
3.4. Misconceptions about Security .............................17
3.4.1. Claim: Packets are unmodified in transit ...........17
1. Introduction ....................................................3
2. The IP Service Model ............................................4
2.1. Links and Subnets ..........................................5
3. Common Application Misconceptions ...............................5
3.1. Misconceptions about Routing ...............................5
3.1.1. Claim: Reachability is symmetric ....................5
3.1.2. Claim: Reachability is transitive ...................6
3.1.3. Claim: Error messages can be received in
response to data packets ............................7
3.1.4. Claim: Multicast is supported within a link .........7
3.1.5. Claim: IPv4 broadcast is supported ..................8
3.1.6. Claim: Multicast/broadcast is less expensive
than replicated unicast .............................8
3.1.7. Claim: The end-to-end latency of the first
packet to a destination is typical ..................8
3.1.8. Claim: Reordering is rare ...........................9
3.1.9. Claim: Loss is rare and probabilistic, not
deterministic .......................................9
3.1.10. Claim: An end-to-end path exists at a
single point in time ..............................10
3.1.11. Discussion ........................................10
3.2. Misconceptions about Addressing ...........................11
3.2.1. Claim: Addresses are stable over long
periods of time ....................................11
3.2.2. Claim: An address is four bytes long ...............12
3.2.3. Claim: A host has only one address on one interface 12
3.2.4. Claim: A non-multicast/broadcast address
identifies a single host over a long period of time 13
3.2.5. Claim: An address can be used as an
indication of physical location ....................14
3.2.6. Claim: An address used by an application is
the same as the address used for routing ...........14
3.2.7. Claim: A subnet is smaller than a link .............14
3.2.8. Claim: Selecting a local address selects
the interface ......................................15
3.2.9. Claim: An address is part of an on-link
subnet prefix ......................................15
3.2.10. Discussion ........................................15
3.3. Misconceptions about Upper-Layer Extensibility ............16
3.3.1. Claim: New transport-layer protocols can
work across the Internet ...........................16
3.3.2. Claim: If one stream between a pair of
addresses can get through, then so can another .....17
3.3.3. Discussion .........................................17
3.4. Misconceptions about Security .............................17
3.4.1. Claim: Packets are unmodified in transit ...........17
3.4.2. Claim: Packets are private .........................18
3.4.3. Claim: Source addresses are not forged .............18
3.4.4. Discussion .........................................18
4. Security Considerations ........................................18
5. Conclusion .....................................................19
6. Acknowledgements ...............................................20
7. IAB Members at the Time of This Writing ........................20
8. IAB Members at the Time of Approval ............................20
9. References .....................................................20
9.1. Normative References ......................................20
9.2. Informative References ....................................21
3.4.2. Claim: Packets are private .........................18
3.4.3. Claim: Source addresses are not forged .............18
3.4.4. Discussion .........................................18
4. Security Considerations ........................................18
5. Conclusion .....................................................19
6. Acknowledgements ...............................................20
7. IAB Members at the Time of This Writing ........................20
8. IAB Members at the Time of Approval ............................20
9. References .....................................................20
9.1. Normative References ......................................20
9.2. Informative References ....................................21
Since the Internet Protocol was first published as [IEN028] in 1978, IP has provided a network-layer connectivity service to upper-layer protocols and applications. The basic IP service model was documented in the original IENs (and subsequently in the RFCs that obsolete them). However, since the mantra has been "Everything Over IP", the IP service model has evolved significantly over the past 30 years to enable new behaviors that the original definition did not envision. For example, by 1989 there was already some confusion and so [RFC1122] clarified many things and extended the model. In 2004, [RFC3819] advised link-layer protocol designers on a number of issues that affect upper layers and is the closest in intent to this document. Today's IP service model is not well documented in a single place, but is either implicit or discussed piecemeal in many different RFCs. As a result, today's IP service model is actually not well known, or at least is often misunderstood.
自1978年互联网协议首次以[IEN028]的形式发布以来，IP为上层协议和应用程序提供了网络层连接服务。基本IP服务模型记录在原始IEN中（随后在淘汰它们的RFC中）。然而，由于口头禅是“IP上的一切”，IP服务模型在过去30年中有了显著的发展，以支持原始定义没有预见到的新行为。例如，到1989年，已经出现了一些混乱，因此[RFC1122]澄清了许多事情并扩展了模型。2004年，[RFC3819]就一些影响上层的问题向链路层协议设计人员提供建议，这与本文档的意图最为接近。今天的IP服务模型并没有在一个地方得到很好的记录，但在许多不同的RFC中要么是隐式的，要么是零碎的讨论。因此，今天的IP服务模型实际上并不广为人知，或者至少经常被误解。
In the early days of IP, changing or extending the basic IP service model was easier since it was not as widely deployed and there were fewer implementations. Today, the ossification of the Internet makes evolving the IP model even more difficult. Thus, it is important to understand the evolution of the IP model for two reasons:
在IP的早期，更改或扩展基本IP服务模型比较容易，因为它没有得到广泛的部署，实现也较少。如今，互联网的僵化使得IP模式的发展更加困难。因此，了解IP模型的演变非常重要，原因有两个：
1. To clarify what properties can and cannot be depended upon by upper-layer protocols and applications. There are many misconceptions on which applications may be based and which are problematic.
1. 阐明上层协议和应用程序可以依赖和不能依赖哪些属性。应用程序可能基于许多误解，这些误解是有问题的。
2. To document lessons for future evolution to take into account. It is important that the service model remain consistent, rather than evolving in two opposing directions. It is sometimes the case in IETF Working Groups today that directions are considered or even taken that would change the IP service model. Doing this without understanding the implications on applications can be dangerous.
2. 记录经验教训，以供将来的发展考虑。重要的是服务模型保持一致，而不是朝两个相反的方向发展。在今天的IETF工作组中，有时会考虑甚至采取改变IP服务模式的方向。在不了解应用程序的含义的情况下这样做可能是危险的。
This RFC attempts to document various aspects of the IP service model and how it has evolved over time. In particular, it attempts to document the properties of the IP layer, as seen by upper-layer protocols and applications, especially properties that were (and at times still are) incorrectly perceived to exist. It also highlights properties that would cause problems if changed.
这个RFC试图记录IP服务模型的各个方面，以及它是如何随着时间的推移而发展的。特别是，它试图记录IP层的属性，正如上层协议和应用程序所看到的，尤其是错误地认为存在（有时仍然存在）的属性。它还突出显示如果更改会导致问题的属性。
In this document, we use the term "IP service model" to refer to the model exposed by IP to higher-layer protocols and applications. This is depicted in Figure 1 by the horizontal line.
在本文中，我们使用术语“IP服务模型”来指IP向更高层协议和应用程序公开的模型。这在图1中用水平线表示。
+-------------+ +-------------+
| Application | | Application |
+------+------+ +------+------+
| |
+------+------+ +------+------+
| Upper-Layer | | Upper-Layer |
| Protocol | | Protocol |
+------+------+ +------+------+
| |
------------------------------------------------------------------
| |
+--+--+ +-----+ +--+--+
| IP | | IP | | IP |
+--+--+ +--+--+ +--+--+
| | |
+-----+------+ +-----+------+ +-----+------+
| Link Layer | | Link Layer | | Link Layer |
+-----+------+ +--+-----+---+ +-----+------+
| | | |
+---------------------+ +--------------------+
+-------------+ +-------------+
| Application | | Application |
+------+------+ +------+------+
| |
+------+------+ +------+------+
| Upper-Layer | | Upper-Layer |
| Protocol | | Protocol |
+------+------+ +------+------+
| |
------------------------------------------------------------------
| |
+--+--+ +-----+ +--+--+
| IP | | IP | | IP |
+--+--+ +--+--+ +--+--+
| | |
+-----+------+ +-----+------+ +-----+------+
| Link Layer | | Link Layer | | Link Layer |
+-----+------+ +--+-----+---+ +-----+------+
| | | |
+---------------------+ +--------------------+
Source Destination
源目的地
IP Service Model
IP服务模型
Figure 1
图1
The foundation of the IP service model today is documented in Section 2.2 of [RFC0791]. Generally speaking, IP provides a connectionless delivery service for variable size packets, which does not guarantee ordering, delivery, or lack of duplication, but is merely best effort (although some packets may get better service than others). Senders can send to a destination address without signaling a priori, and receivers just listen on an already provisioned address, without signaling a priori.
今天IP服务模型的基础被记录在[RCF0791]的第2.2节中。一般来说，IP为可变大小的数据包提供无连接的传递服务，这并不能保证订购、传递或不存在重复，而只是尽最大努力（尽管某些数据包可能比其他数据包获得更好的服务）。发送方可以发送到目的地地址，而无需事先发信号，接收方只需监听已设置的地址，而无需事先发信号。
Architectural principles of the IP model are further discussed in [RFC1958] and in Sections 5 and 6 of [NEWARCH].
[RFC1958]和[NEWARCH]第5节和第6节进一步讨论了IP模型的架构原理。
Section 2.1 of [RFC4903] discusses the terms "link" and "subnet" with respect to the IP model.
[RFC4903]第2.1节讨论了与IP模型相关的术语“链路”和“子网”。
A "link" in the IP service model refers to the topological area within which a packet with an IPv4 Time to Live (TTL) or IPv6 Hop Limit of 1 can be delivered. That is, where no IP-layer forwarding (which entails a TTL/Hop Limit decrement) occurs between two nodes.
IP服务模型中的“链路”是指可以在其中传递IPv4生存时间（TTL）或IPv6跃点限制为1的数据包的拓扑区域。也就是说，在两个节点之间不发生IP层转发（这需要TTL/Hop限制递减）。
A "subnet" in the IP service model refers to the topological area within which addresses from the same subnet prefix are assigned to interfaces.
IP服务模型中的“子网”指的是将同一子网前缀中的地址分配给接口的拓扑区域。
Below is a list of properties that are often assumed by applications and upper-layer protocols, but which have become less true over time.
下面是应用程序和上层协议通常假定的属性列表，但随着时间的推移，这些属性变得不太真实。
Many applications assume that if a host A can contact a host B, then the reverse is also true. Examples of this behavior include request-response patterns, which require reverse reachability only after forward reachability, as well as callbacks (e.g., as used by the File Transfer Protocol (FTP) [RFC0959]).
许多应用程序假定，如果主机a可以与主机B联系，则反过来也是如此。此行为的示例包括请求-响应模式（仅在前向可达性之后才需要反向可达性）以及回调（例如，由文件传输协议（FTP）[RFC0959]使用）。
Originally, it was the case that reachability was symmetric (although the path taken may not be), both within a link and across the Internet. With the advent of technologies such as Network Address Translators (NATs) and firewalls (as in the following example figure), this can no longer be assumed. Today, host-to-host connectivity is challenging if not impossible in general. It is relatively easy to initiate communication from hosts (A-E in the example diagram) to servers (S), but not vice versa, nor between hosts A-E. For a longer discussion on peer-to-peer connectivity, see Appendix A of [RFC5694].
最初，无论是在链路内还是在互联网上，可达性都是对称的（尽管所采用的路径可能不是对称的）。随着诸如网络地址转换器（NAT）和防火墙（如下图所示）等技术的出现，这一点不再是可以假设的。如今，主机到主机的连接即使不是不可能，也是一项挑战。从主机（示例图中的A-E）到服务器的通信相对容易，但从主机（示例图中的A-E）到服务器的通信相对容易，反之亦然，主机A-E之间也不容易。有关对等连接的详细讨论，请参阅[RFC5694]的附录A。
__________ ___ ___
/ \ ___ ___ / \ ____|FW |__A
/ \ ___ / \ _____|NAT|__| | |___|
| |__|NAT|__| | |___| | |__B
| | |___| | |__C \___/
| | \___/ ___
S__| Internet | ___ ___ / \
| | ___ / \ _____|NAT|__| |__D
| |__|FW |__| | |___| | |
| | |___| | |__E \___/
\ / \___/
\__________/
__________ ___ ___
/ \ ___ ___ / \ ____|FW |__A
/ \ ___ / \ _____|NAT|__| | |___|
| |__|NAT|__| | |___| | |__B
| | |___| | |__C \___/
| | \___/ ___
S__| Internet | ___ ___ / \
| | ___ / \ _____|NAT|__| |__D
| |__|FW |__| | |___| | |
| | |___| | |__E \___/
\ / \___/
\__________/
Figure 2
图2
However, it is still the case that if a request can be sent, then a reply to that request can generally be received, but an unsolicited request in the other direction may not be received. [RFC2993] discusses this in more detail.
然而，如果可以发送请求，则通常可以收到对该请求的答复，但可能不会收到另一方向的未经请求的请求。[RFC2993]对此进行了更详细的讨论。
There are also links (e.g., satellite) that were defined as unidirectional links and hence an address on such a link results in asymmetric reachability. [RFC3077] explicitly addresses this problem for multihomed hosts by tunneling packets over another interface in order to restore symmetric reachability.
还有一些链路（例如卫星链路）被定义为单向链路，因此这种链路上的地址会导致不对称可达性。[RFC3077]通过在另一个接口上通过隧道传输数据包以恢复对称可达性，明确解决了多宿主主机的此问题。
Finally, even with common wireless networks such as 802.11, this assumption may not be true, as discussed in Section 5.5 of [WIRELESS].
最后，即使使用802.11等普通无线网络，该假设也可能不成立，如[无线]第5.5节所述。
Many applications assume that if a host A can contact host B, and B can contact C, then host A can contact C. Examples of this behavior include applications and protocols that use referrals.
许多应用程序假定，如果主机a可以联系主机B，主机B可以联系主机C，那么主机a可以联系主机C。这种行为的示例包括使用引用的应用程序和协议。
Originally, it was the case that reachability was transitive, both within a link and across the Internet. With the advent of technologies such as NATs and firewalls and various routing policies, this can no longer be assumed across the Internet, but it is often still true within a link. As a result, upper-layer protocols and applications may be relying on transitivity within a link. However, some radio technologies, such as 802.11 ad hoc mode, violate this assumption within a link.
最初的情况是，无论是在链接内还是在互联网上，可达性都是可传递的。随着NAT和防火墙等技术以及各种路由策略的出现，这一点在Internet上已不再适用，但在链路中仍然适用。因此，上层协议和应用程序可能依赖于链路内的传递性。然而，某些无线电技术，如802.11自组织模式，在链路中违反了这一假设。
3.1.3. Claim: Error messages can be received in response to data packets
3.1.3. 声明：可以接收错误消息以响应数据包
Some upper-layer protocols and applications assume that ICMP error messages will be received in response to packets sent that cannot be delivered. Examples of this include the use of Path MTU Discovery [RFC1191] [RFC1981] relying on messages indicating packets were too big, and traceroute and the use of expanding ring search [RFC1812] relying on messages indicating packets reached their TTL/Hop Limit.
一些上层协议和应用程序假定ICMP错误消息将被接收，以响应发送的无法传递的数据包。这方面的示例包括使用路径MTU发现[RFC1191][RFC1981]依赖于指示数据包过大的消息，以及traceroute和使用扩展环搜索[RFC1812]依赖于指示数据包达到其TTL/Hop限制的消息。
Originally, this assumption largely held, but many ICMP senders then chose to rate-limit responses in order to mitigate denial-of-service attacks, and many firewalls now block ICMP messages entirely. For a longer discussion, see Section 2.1 of [RFC2923].
最初，这一假设基本成立，但许多ICMP发送者随后选择对响应进行速率限制，以减轻拒绝服务攻击，许多防火墙现在完全阻止ICMP消息。有关详细讨论，请参见[RFC2923]第2.1节。
This led to an alternate mechanism for Path MTU Discovery that does not rely on this assumption being true [RFC4821] and guidance to firewall administrators ([RFC4890] and Section 3.1.1 of [RFC2979]).
这导致了路径MTU发现的替代机制，该机制不依赖于此假设为真[RFC4821]和防火墙管理员指南（[RFC4890]和[RFC2979]第3.1.1节）。
[RFC1112] introduced multicast to the IP service model. In this evolution, senders still just send to a destination address without signaling a priori, but in contrast to the original IP model, receivers must signal to the network before they can receive traffic to a multicast address.
[RFC1112]将多播引入IP服务模型。在这种演变中，发送方仍然只是发送到目的地地址，而没有事先发出信号，但与原始IP模型不同，接收方必须先向网络发出信号，然后才能接收到多播地址的流量。
Today, many applications and protocols use multicast addresses, including protocols for address configuration, service discovery, etc. (See [MCAST4] and [MCAST6] for those that use well-known addresses.)
如今，许多应用程序和协议使用多播地址，包括用于地址配置、服务发现等的协议（使用已知地址的请参阅[MCAST4]和[MCAST6]）
Most of these only assume that multicast works within a link and may or may not function across a wider area. While network-layer multicast works over most link types, there are Non-Broadcast Multi-Access (NBMA) links over which multicast does not work (e.g., X.25, ATM, frame relay, 6to4, Intra-Site Automatic Tunnel Addressing Protocol (ISATAP), Teredo) and this can interfere with some protocols and applications. Similarly, there are links such as 802.11 ad hoc mode where multicast packets may not get delivered to all receivers on the link. [RFC4861] states:
其中大多数只假设多播在链路中工作，可能在更大的范围内工作，也可能不工作。虽然网络层多播可在大多数链路类型上工作，但存在多播不工作的非广播多址（NBMA）链路（例如，X.25、ATM、帧中继、6to4、站点内自动隧道寻址协议（ISATAP）、Teredo），这可能会干扰某些协议和应用程序。类似地，存在诸如802.11自组织模式之类的链路，其中多播分组可能不会被传送到链路上的所有接收器。[RFC4861]声明：
Note that all link types (including NBMA) are expected to provide multicast service for applications that need it (e.g., using multicast servers).
请注意，所有链路类型（包括NBMA）都应为需要的应用程序（例如，使用多播服务器）提供多播服务。
and its predecessor [RFC2461] contained similar wording.
其前身[RFC2461]也包含类似的措辞。
However, not all link types today meet this expectation.
然而，今天并非所有链接类型都满足这一期望。
IPv4 broadcast support was originally defined on a link, across a network, and for subnet-directed broadcast, and it is used by many applications and protocols. For security reasons, however, [RFC2644] deprecated the forwarding of broadcast packets. Thus, since 1999, broadcast can only be relied on within a link. Still, there exist NBMA links over which broadcast does not work, and there exist some "semi-broadcast" links (e.g., 802.11 ad hoc mode) where broadcast packets may not get delivered to all nodes on the link. Another case where broadcast fails to work is when a /32 or /31 is assigned to a point-to-point interface (e.g., [RFC3021]), leaving no broadcast address available.
IPv4广播支持最初是在链路上定义的，用于跨网络和子网定向广播，许多应用程序和协议都使用它。但是，出于安全原因，[RFC2644]不推荐转发广播数据包。因此，自1999年以来，只能在链路内依赖广播。尽管如此，仍然存在广播不起作用的NBMA链路，并且存在一些“半广播”链路（例如，802.11 adhoc模式），其中广播分组可能不会传送到链路上的所有节点。广播无法工作的另一种情况是，将/32或/31分配给点到点接口（例如，[RFC3021]），导致广播地址不可用。
To a large extent, the addition of link-scoped multicast to the IP service model obsoleted the need for broadcast. It is also worth noting that the broadcast API model used by most platforms allows receivers to just listen on an already provisioned address, without signaling a priori, but in contrast to the unicast API model, senders must signal to the local IP stack (SO_BROADCAST) before they can send traffic to a broadcast address. However, from the network's perspective, the host still sends without signaling a priori.
在很大程度上，将链路范围的多播添加到IP服务模型中，消除了对广播的需求。还值得注意的是，大多数平台使用的广播API模型允许接收器只监听已设置的地址，而无需事先发送信号，但与单播API模型不同，发送者必须先向本地IP堆栈发送信号（SO_广播），然后才能向广播地址发送流量。然而，从网络的角度来看，主机仍然在没有事先发出信号的情况下发送。
3.1.6. Claim: Multicast/broadcast is less expensive than replicated unicast
3.1.6. 声明：多播/广播比复制单播便宜
Some applications and upper-layer protocols that use multicast or broadcast do so not because they do not know the addresses of receivers, but simply to avoid sending multiple copies of the same packet over the same link.
一些使用多播或广播的应用程序和上层协议这样做并不是因为它们不知道接收器的地址，而是为了避免在同一链路上发送同一数据包的多个副本。
In wired networks, sending a single multicast packet on a link is generally less expensive than sending multiple unicast packets. This may not be true for wireless networks, where implementations can only send multicast at the basic rate, regardless of the negotiated rates of potential receivers. As a result, replicated unicast may achieve much higher throughput across such links than multicast/broadcast traffic.
在有线网络中，在链路上发送单个多播数据包通常比发送多个单播数据包便宜。这对于无线网络可能不是真的，在无线网络中，实现只能以基本速率发送多播，而不管潜在接收器的协商速率如何。因此，复制单播可以在这些链路上实现比多播/广播流量高得多的吞吐量。
3.1.7. Claim: The end-to-end latency of the first packet to a destination is typical
3.1.7. 声明：第一个数据包到目的地的端到端延迟是典型的
Many applications and protocols choose a destination address by sending a message to each of a number of candidates, picking the first one to respond, and then using that destination for subsequent communication. If the end-to-end latency of the first packet to each
许多应用程序和协议通过向多个候选地址中的每一个发送消息来选择目标地址，选择第一个要响应的地址，然后使用该目标进行后续通信。如果第一个数据包的端到端延迟
destination is atypical, this can result in a highly non-optimal destination being chosen, with much longer paths (and hence higher load on the Internet) and lower throughput.
目的地是非典型的，这可能导致选择高度非最优的目的地，路径更长（因此在Internet上的负载更高），吞吐量更低。
Today, there are a number of reasons this is not true. First, when sending to a new destination there may be some startup latency resulting from the link-layer or network-layer mechanism in use, such as the Address Resolution Protocol (ARP), for instance. In addition, the first packet may follow a different path from subsequent packets. For example, protocols such as Mobile IPv6 [RFC3775], Protocol Independent Multicast - Sparse Mode (PIM-SM) [RFC4601], and the Multicast Source Discovery Protocol (MSDP) [RFC3618] send packets on one path, and then allow immediately switching to a shorter path, resulting in a large latency difference. There are various proposals currently being evaluated by the IETF Routing Research Group that result in similar path switching.
今天，有很多原因证明这是不正确的。首先，当发送到一个新的目的地时，可能会由于使用的链路层或网络层机制（例如地址解析协议（ARP））而导致一些启动延迟。此外，第一分组可以遵循与后续分组不同的路径。例如，诸如移动IPv6[RFC3775]、协议独立多播稀疏模式（PIM-SM）[RFC4601]和多播源发现协议（MSDP）[RFC3618]等协议在一条路径上发送数据包，然后允许立即切换到较短路径，从而导致较大的延迟差异。IETF路由研究组目前正在评估各种方案，这些方案会导致类似的路径切换。
As discussed in [REORDER], [RFC2991], and Section 15 of [RFC3819], there are a number of effects of reordering. For example, reordering increases buffering requirements (and jitter) in many applications and in devices that do packet reassembly. In particular, TCP [RFC0793] is adversely affected by reordering since it enters fast-retransmit when three packets are received before a late packet, which drastically lowers throughput. Finally, some NATs and firewalls assume that the initial fragment arrives first, resulting in packet loss when this is not the case.
正如[重新排序]、[RFC2991]和[RFC3819]第15节中所述，重新排序有许多影响。例如，在许多应用程序和进行数据包重组的设备中，重新排序增加了缓冲要求（和抖动）。特别是，TCP[RFC0793]受到重新排序的不利影响，因为当在延迟数据包之前收到三个数据包时，它进入快速重传，这大大降低了吞吐量。最后，一些NAT和防火墙假定初始片段首先到达，否则会导致数据包丢失。
Today, there are a number of things that cause reordering. For example, some routers do per-packet, round-robin load balancing, which, depending on the topology, can result in a great deal of reordering. As another example, when a packet is fragmented at the sender, some hosts send the last fragment first. Finally, as discussed in Section 3.1.7, protocols that do path switching after the first packet result in deterministic reordering within the first burst of packets.
今天，有许多事情会导致重新排序。例如，一些路由器对每个数据包进行循环负载平衡，这取决于拓扑结构，可能导致大量的重新排序。另一个例子是，当数据包在发送方被分割时，一些主机首先发送最后一个片段。最后，如第3.1.7节所述，在第一个数据包之后进行路径切换的协议会导致在第一个数据包突发中进行确定性重新排序。
In the original IP model, senders just send, without signaling the network a priori. This works to a degree. In practice, the last hop (and in rare cases, other hops) of the path needs to resolve next hop information (e.g., the link-layer address of the destination) on demand, which results in queuing traffic, and if the queue fills up, some traffic gets dropped. This means that bursty sources can be problematic (and indeed a single large packet that gets fragmented becomes such a burst). The problem is rarely observed in practice
在原始的IP模型中，发送方只是发送，没有事先向网络发送信号。这在一定程度上有效。实际上，路径的最后一个跃点（在极少数情况下是其他跃点）需要按需解析下一个跃点信息（例如，目的地的链路层地址），这会导致排队流量，如果队列已满，则会丢弃一些流量。这意味着突发数据源可能会有问题（事实上，一个大数据包变得支离破碎，就变成了突发数据）。在实践中很少观察到这个问题
today, either because the resolution within the last hop happens very quickly, or because bursty applications are rarer. However, any protocol that significantly increases such delays or adds new resolutions would be a change to the classic IP model and may adversely impact upper-layer protocols and applications that result in bursts of packets.
今天，要么是因为最后一跳内的分辨率发生得非常快，要么是因为突发性应用程序越来越少。然而，任何显著增加此类延迟或添加新分辨率的协议都将是对经典IP模型的更改，并且可能会对导致数据包突发的上层协议和应用程序产生不利影响。
In addition, mechanisms that simply drop the first packet, rather than queuing it, also break this assumption. Similar to the result of reordering, they can result in a highly non-optimal destination being chosen by applications that use the first one to respond. Two examples of mechanisms that appear to do this are network interface cards that support a "Wake-on-LAN" capability where any packet that matches a specified pattern will wake up a machine in a power-conserving mode, but only after dropping the matching packet, and MSDP, where encapsulating data packets is optional, but doing so enables bursty sources to be accommodated while a multicast tree is built back to the source's domain.
此外，简单地丢弃第一个数据包而不是将其排队的机制也打破了这一假设。与重新排序的结果类似，它们可能导致使用第一个响应的应用程序选择高度非最优的目的地。两种机制的示例是支持“LAN唤醒”功能的网络接口卡，其中任何与指定模式匹配的数据包都将以省电模式唤醒机器，但仅在丢弃匹配的数据包之后，以及MSDP，其中封装数据包是可选的，但是这样做可以在多播树构建回源的域时容纳突发源。
In classic IP, applications assume that either an end-to-end path exists to a destination or that the packet will be dropped. In addition, IP today tends to assume that the packet delay is relatively short (since the "Time"-to-Live is just a hop count). In IP's earlier history, the TTL field was expected to also be decremented each second (not just each hop).
在传统IP中，应用程序假定存在到目的地的端到端路径，或者数据包将被丢弃。此外，如今的IP倾向于假设数据包延迟相对较短（因为“生存时间”只是一个跳数）。在IP的早期历史中，TTL字段预计也会每秒递减（而不仅仅是每一跳）。
In general, this assumption is still true today. However, the IRTF Delay Tolerant Networking Research Group is investigating ways for applications to use IP in networks where this assumption is not true, such as store-and-forward networks (e.g., packets carried by vehicles or animals).
总的来说，这一假设在今天仍然成立。然而，IRTF耐延迟网络研究小组正在研究应用程序在这种假设不成立的网络中使用IP的方法，例如存储转发网络（例如，车辆或动物携带的数据包）。
The reasons why the assumptions listed above are increasingly less true can be divided into two categories: effects caused by attributes of link-layer technologies and effects caused by network-layer technologies.
上述假设越来越不真实的原因可分为两类：链路层技术属性造成的影响和网络层技术造成的影响。
RFC 3819 [RFC3819] advises link-layer protocol designers to minimize these effects. Generally, the link-layer causes are not intentionally trying to break IP, but rather adding IP over the technology introduces the problem. Hence, where the link-layer protocol itself does not do so, when specifying how IP is defined over such a link protocol, designers should compensate to the maximum extent possible. As examples, [RFC3077] and [RFC2491] compensate for
RFC 3819[RFC3819]建议链路层协议设计者将这些影响降至最低。一般来说，链路层的原因不是故意试图破坏IP，而是在技术上添加IP引入了问题。因此，在链路层协议本身不这样做的情况下，当指定如何在这样的链路协议上定义IP时，设计者应该尽可能地进行补偿。例如，[RFC3077]和[RFC2491]补偿
the lack of symmetric reachability and the lack of link-layer multicast, respectively. That is, when IP is defined over a link type, the protocol designers should attempt to restore the assumptions listed in this document. For example, since an implementation can distinguish between 802.11 ad hoc mode versus infrastructure mode, it may be possible to define a mechanism below IP to compensate for the lack of transitivity over such links.
缺乏对称可达性和缺乏链路层组播。也就是说，当通过链路类型定义IP时，协议设计者应尝试恢复本文档中列出的假设。例如，由于实现可以区分802.11自组织模式和基础设施模式，因此可以在IP下定义一种机制来补偿这种链路上缺乏传递性。
At the network layer, as a general principle, we believe that reachability is good. For security reasons ([RFC4948]), however, it is desirable to restrict reachability by unauthorized parties; indeed IPsec, an integral part of the IP model, provides one means to do so. Where there are issues with asymmetry, non-transitivity, and so forth, which are not direct results of restricting reachability to only authorized parties (for some definition of authorized), the IETF should attempt to avoid or solve such issues. Similar to the principle outlined in Section 3.9 of [RFC1958], the general theme when defining a protocol is to be liberal in what effects you accept, and conservative in what effects you cause.
在网络层，作为一般原则，我们认为可达性是好的。然而，出于安全原因（[RFC4948]），需要限制未经授权方的可达性；事实上，IPsec是IP模型的一个组成部分，它提供了一种实现这一点的方法。如果存在不对称性、不及物性等问题，而这些问题不是将可达性限制为仅授权方的直接结果（对于授权方的某些定义），IETF应尝试避免或解决此类问题。与[RFC1958]第3.9节中概述的原则类似，定义协议时的总主题是在您接受的影响方面自由，在您造成的影响方面保守。
However, in being liberal in what effects you accept, it is also important to remember that diagnostics are important, and being too liberal can mask problems. Thus, a tussle exists between the desire to provide a better experience to one's own users or applications and thus be more successful ([RFC5218]), versus the desire to put pressure on getting problems fixed. One solution is to provide a separate "pedantic mode" that can be enabled to see the problems rather than mask them.
然而，在你接受什么样的影响时，同样重要的是要记住诊断是重要的，过于自由会掩盖问题。因此，一种是希望为自己的用户或应用程序提供更好的体验，从而获得更大的成功（[RFC5218]），另一种是希望对解决问题施加压力。一个解决方案是提供一个单独的“迂腐模式”，使其能够看到问题，而不是掩盖问题。
Originally, addresses were manually configured on fixed machines, and hence addresses were very stable. With the advent of technologies such as DHCP, roaming, and wireless, addresses can no longer be assumed to be stable for long periods of time. However, the APIs provided to applications today typically still assume stable addresses (e.g., address lifetimes are not exposed to applications that get addresses). This can cause problems when addresses become stale.
最初，地址是在固定机器上手动配置的，因此地址非常稳定。随着DHCP、漫游和无线等技术的出现，地址不再被认为是长期稳定的。然而，今天提供给应用程序的API通常仍然假定有稳定的地址（例如，地址生存期不会暴露给获得地址的应用程序）。当地址过时时，这可能会导致问题。
For example, many applications resolve names to addresses and then cache them without any notion of lifetime. In fact, the classic name resolution APIs do not even provide applications with the lifetime of entries.
例如，许多应用程序将名称解析为地址，然后在没有任何生存期概念的情况下缓存它们。事实上，经典的名称解析API甚至没有为应用程序提供条目的生存期。
Proxy Mobile IPv6 [RFC5213] tries to restore this assumption to some extent by preserving the same address while roaming around a local area. The issue of roaming between different networks has been known since at least 1980 when [IEN135] proposed a mobility solution that attempted to restore this assumption by adding an additional address that can be used by applications, which is stable while roaming anywhere with Internet connectivity. More recent protocols such as Mobile IPv6 (MIP6) [RFC3775] and the Host Identity Protocol (HIP) [RFC4423] follow in this same vein.
代理移动IPv6[RFC5213]试图通过在本地区域漫游时保留相同的地址，在一定程度上恢复这一假设。至少从1980年[IEN135]提出一种移动解决方案以来，不同网络之间的漫游问题就已为人所知，该解决方案试图通过添加一个可供应用程序使用的附加地址来恢复这一假设，该地址在任何具有互联网连接的地方漫游时都是稳定的。最近的协议，如移动IPv6（MIP6）[RFC3775]和主机标识协议（HIP）[RFC4423]也遵循同样的思路。
Many applications and protocols were designed to only support addresses that are four bytes long. Although this was sufficient for IPv4, the advent of IPv6 made this assumption invalid and with the exhaustion of IPv4 address space this assumption will become increasingly less true. There have been some attempts to try to mitigate this problem with limited degrees of success in constrained cases. For example, "Bump-In-the-Stack" [RFC2767] and "Bump-in-the-API" [RFC3338] attempt to provide four-byte "IPv4" addresses for IPv6 destinations, but have many limitations including (among a number of others) all the problems of NATs.
许多应用程序和协议设计为仅支持四字节长的地址。虽然这对于IPv4来说已经足够了，但IPv6的出现使得这一假设无效，并且随着IPv4地址空间的耗尽，这一假设将变得越来越不真实。已经有一些尝试试图缓解这一问题，但在有限的情况下成功的程度有限。例如，“堆栈中的Bump”[RFC2767]和“API中的Bump”[RFC3338]试图为IPv6目的地提供四字节的“IPv4”地址，但有许多限制，包括（在许多其他限制中）NAT的所有问题。
Although many applications assume this (e.g., by calling a name resolution function such as gethostbyname and then just using the first address returned), it was never really true to begin with, even if it was the common case. Even [RFC0791] states:
尽管许多应用程序都假设这一点（例如，通过调用名称解析函数，如gethostbyname，然后只使用返回的第一个地址），但它一开始就不是真的，即使是常见情况。偶数[RFC0791]表示：
... provision must be made for a host to have several physical interfaces to the network with each having several logical Internet addresses.
... 必须为主机提供多个网络物理接口，每个接口都有多个逻辑互联网地址。
However, this assumption is increasingly less true today, with the advent of multiple interfaces (e.g., wired and wireless), dual-IPv4/ IPv6 nodes, multiple IPv6 addresses on the same interface (e.g., link-local and global), etc. Similarly, many protocol specifications such as DHCP only describe operations for a single interface, whereas obtaining host-wide configuration from multiple interfaces presents a merging problem for nodes in practice. Too often, this problem is simply ignored by Working Groups, and applications and users suffer as a result from poor merging algorithms.
然而，如今，随着多个接口（如有线和无线）、双IPv4/IPv6节点、同一接口上的多个IPv6地址（如链路本地和全局）等的出现，这种假设越来越不正确。类似地，许多协议规范（如DHCP）仅描述单个接口的操作，然而，从多个接口获取主机范围的配置在实践中会给节点带来合并问题。很多时候，工作组只是简单地忽略了这个问题，应用程序和用户因为糟糕的合并算法而受到影响。
One use of protocols such as MIP6 and HIP is to make this assumption somewhat more true by adding an additional "address" that can be the one used by such applications, and the protocol will deal with the complexity of multiple physical interfaces and addresses.
MIP6和HIP等协议的一个用途是通过添加一个额外的“地址”（可以是此类应用程序使用的地址）使这一假设更加真实，该协议将处理多个物理接口和地址的复杂性。
3.2.4. Claim: A non-multicast/broadcast address identifies a single host over a long period of time
3.2.4. 声明：非多播/广播地址在很长一段时间内标识单个主机
Many applications and upper-layer protocols maintain a communication session with a destination over some period of time. If that address is reassigned to another host, or if that address is assigned to multiple hosts and the host at which packets arrive changes, such applications can have problems.
许多应用程序和上层协议在一段时间内维护与目的地的通信会话。如果该地址被重新分配给另一个主机，或者如果该地址被分配给多个主机，并且数据包到达的主机发生更改，则此类应用程序可能会出现问题。
In addition, many security mechanisms and configurations assume that one can block traffic by IP address, implying that a single attacker can be identified by IP address. If that IP address can also identify many legitimate hosts, applying such a block can result in denial of service.
此外，许多安全机制和配置假定可以通过IP地址阻止通信，这意味着可以通过IP地址识别单个攻击者。如果该IP地址还可以识别许多合法主机，则应用这样的块可能会导致拒绝服务。
[RFC1546] introduced the notion of anycast to the IP service model. It states:
[RFC1546]在IP服务模型中引入了选播的概念。它说：
Because anycasting is stateless and does not guarantee delivery of multiple anycast datagrams to the same system, an application cannot be sure that it is communicating with the same peer in two successive UDP transmissions or in two successive TCP connections to the same anycast address.
由于选播是无状态的，并且不能保证将多个选播数据报传送到同一系统，因此应用程序无法确保它在两次连续UDP传输或两次连续TCP连接到同一选播地址时与同一对等方通信。
The obvious solutions to these issues are to require applications which wish to maintain state to learn the unicast address of their peer on the first exchange of UDP datagrams or during the first TCP connection and use the unicast address in future conversations.
这些问题的显而易见的解决方案是要求希望保持状态的应用程序在第一次UDP数据报交换或第一次TCP连接期间了解其对等方的单播地址，并在未来的对话中使用单播地址。
The issues with anycast are further discussed in [RFC4786] and [ANYCAST].
[RFC4786]和[anycast]中进一步讨论了anycast的问题。
Another mechanism by which multiple hosts use the same address is as a result of scoped addresses, as defined for both IPv4 [RFC1918] [RFC3927] and IPv6 [RFC4007]. Because such addresses can be reused within multiple networks, hosts in different networks can use the same address. As a result, a host that is multihomed to two such networks cannot use the destination address to uniquely identify a peer. For example, a host can no longer use a 5-tuple to uniquely identify a TCP connection. This is why IPv6 added the concept of a "zone index".
多台主机使用同一地址的另一种机制是作用域地址的结果，如IPv4[RFC1918][RFC3927]和IPv6[RFC4007]所定义。因为这样的地址可以在多个网络中重用，所以不同网络中的主机可以使用相同的地址。因此，多址到两个这样的网络的主机不能使用目标地址来唯一标识对等方。例如，主机不能再使用5元组来唯一标识TCP连接。这就是IPv6添加“区域索引”概念的原因。
Yet another example is that, in some high-availability solutions, one host takes over the IP address of another failed host.
另一个例子是，在一些高可用性解决方案中，一台主机接管另一台故障主机的IP地址。
See [RFC2101], [RFC2775], and [SHARED-ADDRESSING] for additional discussion on address uniqueness.
有关地址唯一性的更多讨论，请参见[RFC2101]、[RFC2775]和[SHARED-ADDRESSING]。
3.2.5. Claim: An address can be used as an indication of physical location
3.2.5. 声明：地址可以用作物理位置的指示
Some applications attempt to use an address to infer some information about the physical location of the host with that address. For example, geo-location services are often used to provide targeted content or ads.
一些应用程序试图使用地址来推断具有该地址的主机的物理位置的一些信息。例如，地理位置服务通常用于提供目标内容或广告。
Various forms of tunneling have made this assumption less true, and this will become increasingly less true as the use of IPv4 NATs for large networks continues to increase. See Section 7 of [SHARED-ADDRESSING] for a longer discussion.
各种形式的隧道使这一假设变得不那么正确，随着IPv4 NAT在大型网络中的使用不断增加，这一假设将变得越来越不正确。有关详细讨论，请参见[共享地址]第7节。
3.2.6. Claim: An address used by an application is the same as the address used for routing
3.2.6. 声明：应用程序使用的地址与路由使用的地址相同
Some applications assume that the address the application uses is the same as that used by routing. For example, some applications use raw sockets to read/write packet headers, including the source and destination addresses in the IP header. As another example, some applications make assumptions about locality (e.g., whether the destination is on the same subnet) by comparing addresses.
一些应用程序假定应用程序使用的地址与路由使用的地址相同。例如，一些应用程序使用原始套接字来读/写数据包头，包括IP头中的源地址和目标地址。另一个例子是，一些应用程序通过比较地址来假设位置（例如，目的地是否在同一子网上）。
Protocols such as Mobile IPv6 and HIP specifically break this assumption (in an attempt to restore other assumptions as discussed above). Recently, the IRTF Routing Research Group has been evaluating a number of possible mechanisms, some of which would also break this assumption, while others preserve this assumption near the edges of the network and only break it in the core of the Internet.
移动IPv6和HIP等协议特别打破了这一假设（试图恢复上述其他假设）。最近，IRTF路由研究小组一直在评估一些可能的机制，其中一些机制也会打破这一假设，而另一些则在网络边缘附近保留这一假设，只在互联网的核心部分打破这一假设。
Breaking this assumption is sometimes referred to as an "identifier/ locator" split. However, as originally defined in 1978 ([IEN019], [IEN023]), an address was originally defined as only a locator, whereas names were defined to be the identifiers. However, the TCP protocol then used addresses as identifiers.
打破这一假设有时被称为“标识符/定位器”拆分。然而，正如1978年（[IEN019]、[IEN023]）最初定义的那样，地址最初仅定义为定位器，而名称则定义为标识符。然而，TCP协议随后使用地址作为标识符。
Finally, in a liberal sense, any tunneling mechanism might be said to break this assumption, although, in practice, applications that make this assumption will continue to work, since the address of the inside of the tunnel is still used for routing as expected.
最后，从自由的意义上讲，任何隧道机制都可以说是打破了这一假设，尽管在实践中，做出这一假设的应用程序将继续工作，因为隧道内部的地址仍按预期用于路由。
In the classic IP model, a "subnet" is smaller than, or equal to, a "link". Destinations with addresses in the same on-link subnet prefix can be reached with TTL (or Hop Count) = 1. Link-scoped multicast packets, and all-ones broadcast packets will be delivered (in a best-effort fashion) to all listening nodes on the link.
在经典IP模型中，“子网”小于或等于“链路”。使用TTL（或跃点计数）=1可以到达地址在同一链路子网前缀中的目的地。链路范围的多播数据包，以及所有的广播数据包将（以最大努力的方式）传送到链路上的所有侦听节点。
Subnet broadcast packets will be delivered (in a best effort fashion) to all listening nodes in the subnet. There have been some efforts in the past (e.g., [RFC0925], [RFC3069]) to allow multi-link subnets and change the above service model, but the adverse impact on applications that have such assumptions recommend against changing this assumption.
子网广播数据包将（以最佳方式）传送到子网中的所有侦听节点。过去曾做出一些努力（例如，[RFC0925]、[RFC3069]）以允许多链路子网并更改上述服务模型，但对具有此类假设的应用程序的不利影响建议不要更改此假设。
[RFC4903] discusses this topic in more detail and surveys a number of protocols and applications that depend on this assumption. Specifically, some applications assume that, if a destination address is in the same on-link subnet prefix as the local machine, then therefore packets can be sent with TTL=1, or that packets can be received with TTL=255, or link-scoped multicast or broadcast can be used to reach the destination.
[RFC4903]更详细地讨论了此主题，并调查了依赖于此假设的许多协议和应用程序。具体地说，一些应用程序假设，如果目标地址与本地计算机位于相同的链路子网前缀中，则可以使用TTL=1发送数据包，或者使用TTL=255接收数据包，或者可以使用链路范围的多播或广播来到达目标。
Some applications assume that binding to a given local address constrains traffic reception to the interface with that address, and that traffic from that address will go out on that address's interface. However, Section 3.3.4.2 of [RFC1122] defines two models: the Strong End System (or strong host) model where this is true, and the Weak End System (or weak host) model where this is not true. In fact, any router is inherently a weak host implementation, since packets can be forwarded between interfaces.
一些应用程序假设绑定到给定的本地地址会限制到具有该地址的接口的流量接收，并且来自该地址的流量将在该地址的接口上流出。然而，[RFC1122]第3.3.4.2节定义了两种模型：适用于强端系统（或强主机）模型和不适用于弱端系统（或弱主机）模型。事实上，任何路由器本质上都是弱主机实现，因为数据包可以在接口之间转发。
To some extent, this was never true, in that there were cases in IPv4 where the "mask" was 255.255.255.255, such as on a point-to-point link where the two endpoints had addresses out of unrelated address spaces, and no on-link subnet prefix existed on the link. However, this didn't stop many platforms and applications from assuming that every address had a "mask" (or prefix) that was on-link. The assumption of whether a subnet is on-link (in which case one can send directly to the destination after using ARP/ND) or off-link (in which case one just sends to a router) has evolved over the years, and it can no longer be assumed that an address has an on-link prefix. In 1998, [RFC2461] introduced the distinction as part of the core IPv6 protocol suite. This topic is discussed further in [ON-OFF-LINK], and [RFC4903] also touches on this topic with respect to the service model seen by applications.
在某种程度上，这是不正确的，因为在IPv4中存在“掩码”为255.255.255.255的情况，例如在点到点链路上，两个端点的地址超出了不相关的地址空间，并且链路上不存在链路子网前缀。然而，这并没有阻止许多平台和应用程序假设每个地址都有一个链接上的“掩码”（或前缀）。子网是在链路上（在这种情况下，使用ARP/ND后可以直接发送到目的地）还是在断开链路上（在这种情况下，只发送到路由器）的假设多年来一直在发展，不能再假设地址具有链路前缀。1998年，[RFC2461]作为核心IPv6协议套件的一部分引入了这一区别。该主题将在[ON-OFF-LINK]中进一步讨论，[RFC4903]还涉及应用程序看到的服务模型。
Section 4.1 of RFC 1958 [RFC1958] states: "In general, user applications should use names rather than addresses".
RFC 1958[RFC1958]第4.1节规定：“一般而言，用户应用程序应使用名称而不是地址”。
We emphasize the above point, which is too often ignored. Many commonly used APIs unnecessarily expose addresses to applications that already use names. Similarly, some protocols are defined to carry addresses, rather than carrying names (instead of or in addition to addresses). Protocols and applications that are already dependent on a naming system should be designed in such a way that they avoid or minimize any dependence on the notion of addresses.
我们强调上述一点，这一点常常被忽视。许多常用的API不必要地向已经使用名称的应用程序公开地址。类似地，一些协议被定义为携带地址，而不是携带名称（代替或附加地址）。已经依赖于命名系统的协议和应用程序的设计应避免或尽量减少对地址概念的依赖。
One challenge is that many hosts today do not have names that can be resolved. For example, a host may not have a fully qualified domain name (FQDN) or a Domain Name System (DNS) server that will host its name.
一个挑战是，今天许多主机都没有可以解析的名称。例如，主机可能没有将承载其名称的完全限定域名（FQDN）或域名系统（DNS）服务器。
Applications that, for whatever reason, cannot use names should be IP-version agnostic.
无论出于何种原因，不能使用名称的应用程序应该是IP版本无关的。
3.3.1. Claim: New transport-layer protocols can work across the Internet
3.3.1. 声明：新的传输层协议可以在互联网上运行
IP was originally designed to support the addition of new transport-layer protocols, and [PROTOCOLS] lists many such protocols.
IP最初设计用于支持添加新的传输层协议，[协议]列出了许多这样的协议。
However, as discussed in [WAIST-HOURGLASS], NATs and firewalls today break this assumption and often only allow UDP and TCP (or even just HTTP).
然而，正如在[腰部沙漏]中所讨论的，今天的NAT和防火墙打破了这一假设，通常只允许UDP和TCP（甚至只允许HTTP）。
Hence, while new protocols may work from some places, they will not necessarily work from everywhere, such as from behind such NATs and firewalls.
因此，虽然新协议可能在某些地方起作用，但它们不一定在任何地方都起作用，比如在NAT和防火墙后面。
Since even UDP and TCP may not work from everywhere, it may be necessary for applications to support "HTTP failover" modes. The use of HTTP as a "transport of last resort" has become common (e.g., [BOSH] among others) even in situations where it is sub-optimal, such as in real-time communications or where bidirectional communication is required. Also, the IETF HyBi Working Group is now in the process of designing a standards-based solution for layering other protocols on top of HTTP. As a result of having to support HTTP failover, applications may have to be engineered to sustain higher latency.
由于UDP和TCP可能无法在任何地方工作，因此应用程序可能需要支持“HTTP故障切换”模式。使用HTTP作为“最后手段的传输”已经变得很普遍（例如，[BOSH]等），即使在次优的情况下，例如在实时通信或需要双向通信的情况下。此外，IETF HyBi工作组目前正在设计一个基于标准的解决方案，用于在HTTP之上分层其他协议。由于必须支持HTTP故障切换，应用程序可能必须进行设计以维持更高的延迟。
3.3.2. Claim: If one stream between a pair of addresses can get through, then so can another
3.3.2. 声明：如果一对地址之间的一个流可以通过，那么另一个也可以通过
Some applications and protocols use multiple upper-layer streams of data between the same pair of addresses and initiated by the same party. Passive-mode FTP [RFC0959], and RTP [RFC3550], are two examples of such protocols, which use separate streams for data versus control channels.
一些应用程序和协议在同一对地址之间使用由同一方发起的多个上层数据流。被动模式FTP[RFC0959]和RTP[RFC3550]是此类协议的两个示例，它们分别使用数据流和控制信道。
Today, there are many reasons why this may not be true. Firewalls, for example, may selectively allow/block specific protocol numbers and/or values in upper-layer protocol fields (such as port numbers). Similarly, middleboxes such as NATs that create per-stream state may cause other streams to fail once they run out of space to store additional stream state.
今天，有很多原因说明这可能不是真的。例如，防火墙可以选择性地允许/阻止上层协议字段中的特定协议号和/或值（例如端口号）。类似地，创建每个流状态的NAT之类的中间盒可能会导致其他流在耗尽存储额外流状态的空间后失败。
Section 5.1 of [NEWARCH] discusses the primary requirements of the original Internet architecture, including Service Generality. It states:
[NEWARCH]第5.1节讨论了原始互联网体系结构的主要要求，包括服务通用性。它说：
This goal was to support the widest possible range of applications, by supporting a variety of types of service at the transport level. Services might be distinguished by speed, latency, or reliability, for example. Service types might include virtual circuit service, which provides reliable, full-duplex byte streams, and also datagram service, which delivers individual packets with no guarantees of reliability or ordering. The requirement for datagram service was motivated by early ARPAnet experiments with packet speech (using IMP Type 3 messages).
这一目标是通过在传输级别支持各种类型的服务来支持尽可能广泛的应用。例如，服务可以通过速度、延迟或可靠性来区分。服务类型可能包括虚拟电路服务（提供可靠的全双工字节流）和数据报服务（提供单个数据包而不保证可靠性或顺序）。对数据报服务的需求是由早期ARPAnet对分组语音（使用IMP类型3消息）的实验推动的。
The reasons that the assumptions in this section are becoming less true are due to network-layer (or higher-layer) techniques being introduced that interfere with the original requirement. Generally, these are done either in the name of security or as a side effect of solving some other problem such as address shortage. Work is needed to investigate ways to restore the original behavior while still meeting today's security requirements.
本节中的假设变得不太真实的原因是由于引入了干扰原始需求的网络层（或更高层）技术。通常，这些都是以安全的名义进行的，或者是作为解决地址短缺等其他问题的副作用。需要研究恢复原始行为的方法，同时仍然满足当今的安全要求。
Some applications and upper-layer protocols assume that a packet is unmodified in transit, except for a few well-defined fields (e.g., TTL). Examples of this behavior include protocols that define their own integrity-protection mechanism such as a checksum.
一些应用程序和上层协议假定数据包在传输过程中未被修改，但一些定义良好的字段除外（例如TTL）。这种行为的示例包括定义自身完整性保护机制（如校验和）的协议。
This assumption is broken by NATs as discussed in [RFC2993] and other middleboxes that modify the contents of packets. There are many tunneling technologies (e.g., [RFC4380]) that attempt to restore this assumption to some extent.
[RFC2993]中讨论的NAT和修改数据包内容的其他中间盒打破了这一假设。有许多隧道技术（例如，[RFC4380]）试图在某种程度上恢复这一假设。
The IPsec architecture [RFC4301] added security to the IP model, providing a way to address this problem without changing applications, although transport-mode IPsec is not currently widely used over the Internet.
IPsec体系结构[RFC4301]为IP模型增加了安全性，提供了一种在不改变应用程序的情况下解决此问题的方法，尽管传输模式IPsec目前未在Internet上广泛使用。
The assumption that data is private has never really been true. However, many old applications and protocols (e.g., FTP) transmit passwords or other sensitive data in the clear.
数据是私有的假设从来都不是真的。然而，许多旧的应用程序和协议（如FTP）以明文形式传输密码或其他敏感数据。
IPsec provides a way to address this problem without changing applications, although it is not yet widely deployed, and doing encryption/decryption for all packets can be computationally expensive.
IPsec提供了一种在不改变应用程序的情况下解决此问题的方法，尽管它尚未广泛部署，并且对所有数据包进行加密/解密在计算上可能非常昂贵。
Most applications and protocols use the source address of some incoming packet when generating a response, and hence assume that it has not been forged (and as a result can often be vulnerable to various types of attacks such as reflection attacks).
大多数应用程序和协议在生成响应时使用一些传入数据包的源地址，因此假设它没有被伪造（因此通常容易受到各种类型的攻击，例如反射攻击）。
Various mechanisms that restore this assumption include, for example, IPsec and Cryptographically Generated Addresses (CGAs) [RFC3972].
恢复此假设的各种机制包括，例如，IPsec和加密生成地址（CGA）[RFC3972]。
A good discussion of threat models and common tools can be found in [RFC3552]. Protocol designers and applications developers are encouraged to be familiar with that document.
[RFC3552]中有关于威胁模型和常用工具的详细讨论。鼓励协议设计人员和应用程序开发人员熟悉该文档。
This document discusses assumptions about the IP service model made by many applications and upper-layer protocols. Whenever these assumptions are broken, if the application or upper-layer protocol has some security-related behavior that is based on the assumption, then security can be affected.
本文讨论了许多应用程序和上层协议对IP服务模型的假设。每当这些假设被打破时，如果应用程序或上层协议有一些基于该假设的安全相关行为，那么安全性就会受到影响。
For example, if an application assumes that binding to the IP address of a "trusted" interface means that it will never receive traffic from an "untrusted" interface, and that assumption is broken (as discussed in Section 3.2.8), then an attacker could get access to private information.
例如，如果应用程序假设绑定到“受信任”接口的IP地址意味着它永远不会从“不受信任”接口接收流量，并且该假设被打破（如第3.2.8节所述），则攻击者可以访问私有信息。
As a result, great care should be taken when expanding the extent to which an assumption is false. On the other hand, application and upper-layer protocol developers should carefully consider the impact of basing their security on any of the assumptions enumerated in this document.
因此，在扩大假设的虚假程度时，应格外小心。另一方面，应用程序和上层协议开发人员应该仔细考虑其安全性对本文档中列举的任何假设的影响。
It is also worth noting that many of the changes that have occurred over time (e.g., firewalls, dropping directed broadcasts, etc.) that are discussed in this document were done in the interest of improving security at the expense of breaking some applications.
还值得注意的是，本文档中讨论的许多随时间推移而发生的更改（例如，防火墙、丢弃定向广播等）都是为了提高安全性而进行的，代价是破坏一些应用程序。
Because a huge number of applications already exist that use TCP/IP for business-critical operations, any changes to the service model need to be done with extreme care. Extensions that merely add additional optional functionality without impacting any existing applications are much safer than extensions that change one or more of the core assumptions discussed above. Any changes to the above assumptions should only be done in accordance with some mechanism to minimize or mitigate the risks of breaking mission-critical applications. Historically, changes have been done without regard to such considerations and, as a result, the situation for applications today is already problematic. The key to maintaining an interoperable Internet is documenting and maintaining invariants that higher layers can depend on, and being very judicious with changes.
由于已经存在大量使用TCP/IP进行业务关键型操作的应用程序，因此对服务模型的任何更改都需要格外小心。仅添加额外可选功能而不影响任何现有应用程序的扩展比更改上述一个或多个核心假设的扩展安全得多。对上述假设的任何更改只能根据某种机制进行，以最大限度地降低或减轻中断关键任务应用程序的风险。从历史上看，在进行更改时没有考虑这些因素，因此，今天的应用情况已经存在问题。维护一个可互操作的互联网的关键是记录和维护更高层可以依赖的不变量，并且对更改非常明智。
In general, lower-layer protocols should document the contract they provide to higher layers; that is, what assumptions the upper layer can rely on (sometimes this is done in the form of an applicability statement). Conversely, higher-layer protocols should document the assumptions they rely on from the lower layer (sometimes this is done in the form of requirements).
一般来说，较低层协议应记录其向较高层提供的合同；也就是说，上层可以依赖什么样的假设（有时这是以适用性声明的形式完成的）。相反，高层协议应记录其所依赖的来自下层的假设（有时以需求的形式完成）。
We must also recognize that a successful architecture often evolves as success brings growth and as technology moves forward. As a result, the various assumptions made should be periodically reviewed when updating protocols.
我们还必须认识到，一个成功的体系结构往往随着成功带来的增长和技术的进步而发展。因此，在更新协议时，应定期审查所做的各种假设。
Chris Hopps, Dow Street, Phil Hallam-Baker, and others provided helpful discussion on various points that led to this document. Iain Calder, Brian Carpenter, Jonathan Rosenberg, Erik Nordmark, Alain Durand, and Iljitsch van Beijnum also provided valuable feedback.
Chris Hopps、Dow Street、Phil Hallam Baker和其他人就本文件的各个要点进行了有益的讨论。Iain Calder、Brian Carpenter、Jonathan Rosenberg、Erik Nordmark、Alain Durand和Iljitsch van Beijnum也提供了宝贵的反馈。
Loa Andersson Gonzalo Camarillo Stuart Cheshire Russ Housley Olaf Kolkman Gregory Lebovitz Barry Leiba Kurtis Lindqvist Andrew Malis Danny McPherson David Oran Dave Thaler Lixia Zhang
Loa Andersson Gonzalo Camarillo Stuart Cheshire Russ Housley Olaf Kolkman Gregory Lebovitz Barry Leiba Kurtis Lindqvist Andrew Malis Danny McPherson David Oran Dave Thaler Lixia Zhang
Bernard Aboba Marcelo Bagnulo Ross Callon Spencer Dawkins Russ Housley John Klensin Olaf Kolkman Danny McPherson Jon Peterson Andrei Robachevsky Dave Thaler Hannes Tschofenig
伯纳德·阿博巴·马塞洛·巴格努洛·罗斯·卡隆·斯宾塞·道金斯·罗斯·霍斯利·约翰·克莱森·奥拉夫·科尔克曼·丹尼·麦克弗森·乔恩·彼得森·安德烈·罗巴切夫斯基·戴夫·泰勒·汉内斯·茨霍芬尼
[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
[RFC0791]Postel，J.，“互联网协议”，STD 5，RFC 7911981年9月。
[RFC1112] Deering, S., "Host extensions for IP multicasting", STD 5, RFC 1112, August 1989.
[RFC1112]Deering，S.，“IP多播的主机扩展”，STD 5，RFC11121989年8月。
[RFC1122] Braden, R., "Requirements for Internet Hosts - Communication Layers", STD 3, RFC 1122, October 1989.
[RFC1122]Braden，R.，“互联网主机的要求-通信层”，标准3，RFC 1122，1989年10月。
[RFC1546] Partridge, C., Mendez, T., and W. Milliken, "Host Anycasting Service", RFC 1546, November 1993.
[RFC1546]帕特里奇，C.，门德斯，T.，和W.米利肯，“主持任意广播服务”，RFC15461993年11月。
[RFC2461] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery for IP Version 6 (IPv6)", RFC 2461, December 1998.
[RFC2461]Narten，T.，Nordmark，E.，和W.Simpson，“IP版本6（IPv6）的邻居发现”，RFC2461，1998年12月。
[RFC2644] Senie, D., "Changing the Default for Directed Broadcasts in Routers", BCP 34, RFC 2644, August 1999.
[RFC2644]Senie，D.，“更改路由器中定向广播的默认设置”，BCP 34，RFC 2644，1999年8月。
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
[RFC4301]Kent，S.和K.Seo，“互联网协议的安全架构”，RFC 43012005年12月。
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, September 2007.
[RFC4861]Narten，T.，Nordmark，E.，Simpson，W.，和H.Soliman，“IP版本6（IPv6）的邻居发现”，RFC 48612007年9月。
[ANYCAST] McPherson, D. and D. Oran, "Architectural Considerations of IP Anycast", Work in Progress, February 2010.
[ANYCAST]McPherson，D.和D.Oran，“IP ANYCAST的架构考虑”，正在进行的工作，2010年2月。
[BOSH] Paterson, I., Smith, D., Saint-Andre, P., and J. Moffitt, "Bidirectional-streams Over Synchronous HTTP (BOSH)", XEP 0124, 2010, <http://xmpp.org/extensions/xep-0124.html>.
[BOSH]Paterson，I.，Smith，D.，Saint Andre，P.，和J.Moffitt，“同步HTTP上的双向流（BOSH）”，XEP 01242010<http://xmpp.org/extensions/xep-0124.html>.
[IEN019] Shoch, J., "A note on Inter-Network Naming, Addressing, and Routing", IEN 19, January 1978, <http://www.rfc-editor.org/ien/ien19.txt>.
[IEN019]Shoch，J.“关于网络间命名、寻址和路由的说明”，IEN 19，1978年1月<http://www.rfc-editor.org/ien/ien19.txt>.
[IEN023] Cohen, D., "On Names, Addresses and Routings", IEN 23, January 1978, <http://www.rfc-editor.org/ien/ien23.txt>.
[IEN023]Cohen，D.“关于姓名、地址和路线”，IEN 231978年1月<http://www.rfc-editor.org/ien/ien23.txt>.
[IEN028] Postel, J., "Draft Internetwork Protocol Specification", IEN 28, February 1978, <http://www.rfc-editor.org/ien/ien28.pdf>.
[IEN028]Postel，J.，“互联网协议规范草案”，IEN 281978年2月<http://www.rfc-editor.org/ien/ien28.pdf>.
[IEN135] Sunshine, C. and J. Postel, "Addressing Mobile Hosts in the ARPA Internet Environment", IEN 135, March 1980, <http://www.rfc-editor.org/ien/ien135.txt>.
[IEN135]Sunshine，C.和J.Postel，“在ARPA互联网环境中寻址移动主机”，IEN135，1980年3月<http://www.rfc-editor.org/ien/ien135.txt>.
[MCAST4] Internet Assigned Numbers Authority, "IPv4 Multicast Addresses", <http://www.iana.org/assignments/multicast-addresses>.
[MCAST4]互联网分配号码管理局，“IPv4多播地址”<http://www.iana.org/assignments/multicast-addresses>.
[MCAST6] Internet Assigned Numbers Authority, "INTERNET PROTOCOL VERSION 6 MULTICAST ADDRESSES", <http://www.iana.org/assignments/ ipv6-multicast-addresses>.
[MCAST6]互联网分配号码管理局，“互联网协议版本6多播地址”<http://www.iana.org/assignments/ ipv6多播地址>。
[NEWARCH] Clark, D., et al., "New Arch: Future Generation Internet Architecture", Air Force Research Laboratory Technical Report AFRL-IF-RS-TR-2004-235, August 2004, <http:// www.dtic.mil/cgi-bin/ GetTRDoc?AD=ADA426770&Location=U2&doc=GetTRDoc.pdf>.
[NEWARCH]Clark，D.等人，“新一代互联网架构”，空军研究实验室技术报告AFRL-IF-RS-TR-2004-235，2004年8月，<http://www.dtic.mil/cgi-bin/getterdoc？AD=ADA426770&Location=U2&doc=getterdoc.pdf>。
[ON-OFF-LINK] Singh, H., Beebee, W., and E. Nordmark, "IPv6 Subnet Model", Work in Progress, February 2008.
[ON-OFF-LINK]Singh，H.，Beebee，W.，和E.Nordmark，“IPv6子网模型”，正在进行的工作，2008年2月。
[PROTOCOLS] Internet Assigned Numbers Authority, "Protocol Numbers", <http://www.iana.org/assignments/protocol-numbers>.
[协议]互联网分配号码管理局，“协议号码”<http://www.iana.org/assignments/protocol-numbers>.
[REORDER] Bennett, J., Partridge, C., and N. Shectman, "Packet reordering is not pathological network behavior", IEEE/ACM Transactions on Networking, Vol. 7, No. 6, December 1999.
[重新排序]Bennett，J.，Partridge，C.，和N.Shectman，“数据包重新排序不是病态的网络行为”，IEEE/ACM网络交易，第7卷，第6期，1999年12月。
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.
[RFC0793]Postel，J.，“传输控制协议”，标准7，RFC 793，1981年9月。
[RFC0925] Postel, J., "Multi-LAN address resolution", RFC 925, October 1984.
[RFC0925]Postel，J.，“多局域网地址解析”，RFC 925，1984年10月。
[RFC0959] Postel, J. and J. Reynolds, "File Transfer Protocol", STD 9, RFC 959, October 1985.
[RFC0959]Postel，J.和J.Reynolds，“文件传输协议”，标准9，RFC 959，1985年10月。
[RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, November 1990.
[RFC1191]Mogul，J.和S.Deering，“MTU发现路径”，RFC1191，1990年11月。
[RFC1812] Baker, F., "Requirements for IP Version 4 Routers", RFC 1812, June 1995.
[RFC1812]Baker，F.，“IP版本4路由器的要求”，RFC1812，1995年6月。
[RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, February 1996.
[RFC1918]Rekhter，Y.，Moskowitz，R.，Karrenberg，D.，Groot，G.，和E.Lear，“私人互联网地址分配”，BCP 5，RFC 1918，1996年2月。
[RFC1958] Carpenter, B., "Architectural Principles of the Internet", RFC 1958, June 1996.
[RFC1958]Carpenter，B.，“互联网的建筑原理”，RFC19581996年6月。
[RFC1981] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery for IP version 6", RFC 1981, August 1996.
[RFC1981]McCann，J.，Deering，S.，和J.Mogul，“IP版本6的路径MTU发现”，RFC 1981，1996年8月。
[RFC2101] Carpenter, B., Crowcroft, J., and Y. Rekhter, "IPv4 Address Behaviour Today", RFC 2101, February 1997.
[RFC2101]Carpenter，B.，Crowcroft，J.，和Y.Rekhter，“今天的IPv4地址行为”，RFC 21011997年2月。
[RFC2491] Armitage, G., Schulter, P., Jork, M., and G. Harter, "IPv6 over Non-Broadcast Multiple Access (NBMA) networks", RFC 2491, January 1999.
[RFC2491]Armitage，G.，Schulter，P.，Jork，M.，和G.Harter，“非广播多址（NBMA）网络上的IPv6”，RFC 2491，1999年1月。
[RFC2767] Tsuchiya, K., HIGUCHI, H., and Y. Atarashi, "Dual Stack Hosts using the "Bump-In-the-Stack" Technique (BIS)", RFC 2767, February 2000.
[RFC2767]Tsuchiya，K.，HIGUCHI，H.，和Y.Atarashi，“使用“堆栈中的凹凸”技术（BIS）的双堆栈主机”，RFC 2767，2000年2月。
[RFC2775] Carpenter, B., "Internet Transparency", RFC 2775, February 2000.
[RFC2775]Carpenter，B.，“互联网透明度”，RFC 27752000年2月。
[RFC2923] Lahey, K., "TCP Problems with Path MTU Discovery", RFC 2923, September 2000.
[RFC2923]Lahey，K.，“路径MTU发现的TCP问题”，RFC 29232000年9月。
[RFC2979] Freed, N., "Behavior of and Requirements for Internet Firewalls", RFC 2979, October 2000.
[RFC2979]弗里德，N.，“互联网防火墙的行为和要求”，RFC 2979，2000年10月。
[RFC2991] Thaler, D. and C. Hopps, "Multipath Issues in Unicast and Multicast Next-Hop Selection", RFC 2991, November 2000.
[RFC2991]Thaler，D.和C.Hopps，“单播和多播下一跳选择中的多路径问题”，RFC 29912000年11月。
[RFC2993] Hain, T., "Architectural Implications of NAT", RFC 2993, November 2000.
[RFC2993]Hain，T.，“NAT的建筑含义”，RFC 29932000年11月。
[RFC3021] Retana, A., White, R., Fuller, V., and D. McPherson, "Using 31-Bit Prefixes on IPv4 Point-to-Point Links", RFC 3021, December 2000.
[RFC3021]Retana，A.，White，R.，Fuller，V.，和D.McPherson，“在IPv4点到点链路上使用31位前缀”，RFC 30212000年12月。
[RFC3069] McPherson, D. and B. Dykes, "VLAN Aggregation for Efficient IP Address Allocation", RFC 3069, February 2001.
[RFC3069]McPherson，D.和B.Dykes，“有效IP地址分配的VLAN聚合”，RFC 3069，2001年2月。
[RFC3077] Duros, E., Dabbous, W., Izumiyama, H., Fujii, N., and Y. Zhang, "A Link-Layer Tunneling Mechanism for Unidirectional Links", RFC 3077, March 2001.
[RFC3077]Duros，E.，Dabbous，W.，Izumiyama，H.，Fujii，N.，和Y.Zhang，“单向链路的链路层隧道机制”，RFC 3077，2001年3月。
[RFC3338] Lee, S., Shin, M-K., Kim, Y-J., Nordmark, E., and A. Durand, "Dual Stack Hosts Using "Bump-in-the-API" (BIA)", RFC 3338, October 2002.
[RFC3338]Lee，S.，Shin，M-K.，Kim，Y-J.，Nordmark，E.，和A.Durand，“使用“API中的凹凸”（BIA）的双堆栈主机”，RFC 3338，2002年10月。
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003.
[RFC3550]Schulzrinne，H.，Casner，S.，Frederick，R.，和V.Jacobson，“RTP：实时应用的传输协议”，STD 64，RFC 35502003年7月。
[RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC Text on Security Considerations", BCP 72, RFC 3552, July 2003.
[RFC3552]Rescorla，E.和B.Korver，“关于安全考虑的RFC文本编写指南”，BCP 72，RFC 3552，2003年7月。
[RFC3618] Fenner, B. and D. Meyer, "Multicast Source Discovery Protocol (MSDP)", RFC 3618, October 2003.
[RFC3618]Fenner，B.和D.Meyer，“多播源发现协议（MSDP）”，RFC3618，2003年10月。
[RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004.
[RFC3775]Johnson，D.，Perkins，C.，和J.Arkko，“IPv6中的移动支持”，RFC 37752004年6月。
[RFC3819] Karn, P., Bormann, C., Fairhurst, G., Grossman, D., Ludwig, R., Mahdavi, J., Montenegro, G., Touch, J., and L. Wood, "Advice for Internet Subnetwork Designers", BCP 89, RFC 3819, July 2004.
[RFC3819]Karn，P.，Bormann，C.，Fairhurst，G.，Grossman，D.，路德维希，R.，Mahdavi，J.，黑山，G.，Touch，J.，和L.Wood，“互联网子网络设计师的建议”，BCP 89，RFC 3819，2004年7月。
[RFC3927] Cheshire, S., Aboba, B., and E. Guttman, "Dynamic Configuration of IPv4 Link-Local Addresses", RFC 3927, May 2005.
[RFC3927]Cheshire，S.，Aboba，B.和E.Guttman，“IPv4链路本地地址的动态配置”，RFC 3927，2005年5月。
[RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", RFC 3972, March 2005.
[RFC3972]Aura，T.，“加密生成地址（CGA）”，RFC 39722005年3月。
[RFC4007] Deering, S., Haberman, B., Jinmei, T., Nordmark, E., and B. Zill, "IPv6 Scoped Address Architecture", RFC 4007, March 2005.
[RFC4007]Deering，S.，Haberman，B.，Jinmei，T.，Nordmark，E.，和B.Zill，“IPv6作用域地址体系结构”，RFC 4007，2005年3月。
[RFC4380] Huitema, C., "Teredo: Tunneling IPv6 over UDP through Network Address Translations (NATs)", RFC 4380, February 2006.
[RFC4380]Huitema，C.，“Teredo：通过网络地址转换（NAT）通过UDP传输IPv6”，RFC 43802006年2月。
[RFC4423] Moskowitz, R. and P. Nikander, "Host Identity Protocol (HIP) Architecture", RFC 4423, May 2006.
[RFC4423]Moskowitz，R.和P.Nikander，“主机身份协议（HIP）体系结构”，RFC 4423，2006年5月。
[RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, "Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised)", RFC 4601, August 2006.
[RFC4601]Fenner，B.，Handley，M.，Holbrook，H.，和I.Kouvelas，“协议独立多播-稀疏模式（PIM-SM）：协议规范（修订版）”，RFC 46012006年8月。
[RFC4786] Abley, J. and K. Lindqvist, "Operation of Anycast Services", BCP 126, RFC 4786, December 2006.
[RFC4786]Abley，J.和K.Lindqvist，“任意广播服务的运营”，BCP 126，RFC 4786，2006年12月。
[RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU Discovery", RFC 4821, March 2007.
[RFC4821]Mathis，M.和J.Heffner，“打包层路径MTU发现”，RFC 48212007年3月。
[RFC4890] Davies, E. and J. Mohacsi, "Recommendations for Filtering ICMPv6 Messages in Firewalls", RFC 4890, May 2007.
[RFC4890]Davies，E.和J.Mohacsi，“防火墙中过滤ICMPv6消息的建议”，RFC 48902007年5月。
[RFC4903] Thaler, D., "Multi-Link Subnet Issues", RFC 4903, June 2007.
[RFC4903]Thaler，D.，“多链路子网问题”，RFC 49032007年6月。
[RFC4948] Andersson, L., Davies, E., and L. Zhang, "Report from the IAB workshop on Unwanted Traffic March 9-10, 2006", RFC 4948, August 2007.
[RFC4948]Andersson，L.，Davies，E.，和L.Zhang，“IAB 2006年3月9日至10日不必要交通研讨会报告”，RFC 4948，2007年8月。
[RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008.
[RFC5213]Gundavelli，S.，Leung，K.，Devarapalli，V.，Chowdhury，K.，和B.Patil，“代理移动IPv6”，RFC 5213，2008年8月。
[RFC5218] Thaler, D. and B. Aboba, "What Makes For a Successful Protocol?", RFC 5218, July 2008.
[RFC5218]Thaler，D.和B.Aboba，“什么是成功的方案？”RFC 5218，2008年7月。
[RFC5694] Camarillo, G. and IAB, "Peer-to-Peer (P2P) Architecture: Definition, Taxonomies, Examples, and Applicability", RFC 5694, November 2009.
[RFC5694]Camarillo，G.和IAB，“对等（P2P）架构：定义、分类、示例和适用性”，RFC 56942009年11月。
[SHARED-ADDRESSING] Ford, M., Boucadair, M., Durand, A., Levis, P., and P. Roberts, "Issues with IP Address Sharing", Work in Progress, March 2011.
[共享地址]福特，M.，布卡代尔，M.，杜兰德，A.，利维斯，P.，和P.罗伯茨，“IP地址共享的问题”，正在进行的工作，2011年3月。
[WAIST-HOURGLASS] Rosenberg, J., "UDP and TCP as the New Waist of the Internet Hourglass", Work in Progress, February 2008.
[腰部沙漏]Rosenberg，J.，“UDP和TCP作为互联网沙漏的新腰部”，正在进行的工作，2008年2月。
[WIRELESS] Kotz, D., Newport, C., and C. Elliott, "The mistaken axioms of wireless-network research", Dartmouth College Computer Science Technical Report TR2003-467, July 2003, < http://www.cs.dartmouth.edu/cms_file/SYS_techReport/337/ TR2003-467.pdf>.
[WIRELESS]Kotz，D.，Newport，C.和C.Elliott，“无线网络研究的错误公理”，达特茅斯学院计算机科学技术报告TR2003-467，2003年7月，<http://www.cs.dartmouth.edu/cms_file/SYS_techReport/337/ TR2003-467.pdf>。
Authors' Addresses
作者地址
Dave Thaler One Microsoft Way Redmond, WA 98052 USA
Dave Thaler美国华盛顿州雷德蒙微软大道一号，邮编：98052
Phone: +1 425 703 8835
EMail: dthaler@microsoft.com
Phone: +1 425 703 8835
EMail: dthaler@microsoft.com
Internet Architecture Board
互联网架构委员会
EMail: iab@iab.org
EMail: iab@iab.org