[要約] RFC 6250は、IPモデルの進化に関する要約であり、IPネットワークの設計と運用の改善を目的としています。
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.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、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.
Copyright（c）2011 IETF Trustおよび文書著者として特定された人。全著作権所有。
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ドキュメント（http://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。
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
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サービスモデルは、元のIENSに文書化されました（その後、それらを廃止するRFCSに）。ただし、マントラは「すべての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モデルの進化がさらに困難になります。したがって、2つの理由で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. 将来の進化を考慮に入れるためのレッスンを文書化する。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 |
+-----+------+ +--+-----+---+ +-----+------+
| | | |
+---------------------+ +--------------------+
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サービスモデルの基礎は、[RFC0791]のセクション2.2に記録されています。一般的に言えば、IPは可変サイズのパケットにコネクションレス配信サービスを提供します。これは、注文、配信、または複製の欠如を保証するものではありませんが、単なる最良の努力です（一部のパケットは他のパケットよりも優れたサービスを受ける可能性があります）。送信者は、アプリオリを合図することなく宛先アドレスに送信でき、受信者はプライリを合図することなく、すでにプロビジョニングされたアドレスで聞くだけです。
Architectural principles of the IP model are further discussed in [RFC1958] and in Sections 5 and 6 of [NEWARCH].
IPモデルのアーキテクチャの原則については、[RFC1958]および[NewArch]のセクション5および6でさらに説明します。
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を配信できるトポロジ領域を指します。つまり、2つのノード間でIP層転送（TTL/ホップ制限の減少を伴う）が発生しない場合。
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間ではありません。ピアツーピア接続性に関する長い説明については、[RFC5694]の付録Aを参照してください。
__________ ___ ___
/ \ ___ ___ / \ ____|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に連絡できる場合、BがCに連絡し、ホストAに連絡する場合を想定しています。この動作の例には、紹介を使用するアプリケーションとプロトコルが含まれます。
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やファイアウォールやさまざまなルーティングポリシーなどのテクノロジーの出現により、これはインターネット全体で想定されることはありませんが、リンク内でまだ当てはまることがよくあります。その結果、上層層プロトコルとアプリケーションは、リンク内の推移性に依存している可能性があります。ただし、802.11アドホックモードなどの一部のラジオテクノロジーは、リンク内でこの仮定に違反しています。
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エラーメッセージが受信されると想定しています。これの例には、PATH 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]).
これにより、この仮定が真である[RFC4821]とファイアウォール管理者へのガイダンス（[RFC4890]および[RFC2979]のセクション3.1.1へのガイダンスに依存しないPath MTU発見の代替メカニズムが生じました。
[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 Ad Hocモードなど）が存在します。ブロードキャストが機能しない別のケースは、A /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_BROADCAST）に信号を送信する必要があります。放送アドレスにトラフィックを送信する前に。ただし、ネットワークの観点から見ると、ホストは先験的に合図することなく送信します。
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.
有線ネットワークでは、リンクに単一のマルチキャストパケットを送信すると、複数のユニキャストパケットの送信よりも一般的に安価です。これは、潜在的な受信機の交渉レートに関係なく、実装が基本レートでのみマルチキャストを送信できるワイヤレスネットワークには当てはまらない場合があります。その結果、複製されたユニキャストは、マルチキャスト/ブロードキャストトラフィックよりも、このようなリンク全体ではるかに高いスループットを達成する可能性があります。
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.
多くのアプリケーションとプロトコルは、多くの候補者にメッセージを送信し、最初の候補者を選択して応答し、その後の通信のためにその目的地を使用して、宛先アドレスを選択します。各宛先への最初のパケットのエンドツーエンドのレイテンシが非定型である場合、これにより、非常に非最適な宛先が選択され、パスがはるかに長く（したがってインターネット上の負荷が高くなります）、スループットが低くなります。
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]などのプロトコルは、1つのパスでパケットを送信し、すぐに切り替えることができます。より短いパスに、その結果、潜時の違いが大きくなります。同様のパススイッチングをもたらす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.
[Reorder]、[RFC2991]、および[RFC3819]のセクション15で説明したように、並べ替えの効果がいくつかあります。たとえば、並べ替えは、多くのアプリケーションやパケットの再組み立てを行うデバイスでバッファリング要件（およびジッター）を増加させます。特に、TCP [RFC0793]は、スループットが大幅に低下する後期パケットの前に3つのパケットが受信されると、高速再送信に入るため、再注文によって悪影響を受けます。最後に、一部の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 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モデルでは、送信者は、ネットワークにアプリオリを合図することなく、ただ送信します。これはある程度機能します。実際には、パスの最後のホップ（およびまれに、他のホップ）は、次のホップ情報（例：宛先のリンク層アドレス）をオンデマンドで解決する必要があります。上に、一部のトラフィックが減少します。これは、破裂したソースが問題になる可能性があることを意味します（実際、断片化される単一の大きなパケットがそのようなバーストになります）。最後のホップ内の解像度が非常に迅速に行われるため、または爆発的なアプリケーションがまれであるため、今日の実際に問題はめったに観察されません。ただし、このような遅延を大幅に増加させたり、新しい解像度を追加したりするプロトコルは、古典的な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.
さらに、最初のパケットを列に並べるのではなく単に落とすメカニズムも、この仮定を破ります。並べ替えの結果と同様に、それらは、最初のアプリケーションを使用して応答するアプリケーションによって選択される非常に非最適な目的地になる可能性があります。これを行うように見えるメカニズムの2つの例は、指定されたパターンに一致するパケットがパワーコンサイビングモードでマシンを目覚めさせる「ウェイクオンラーン」機能をサポートするネットワークインターフェイスカードです。データパケットをカプセル化することがオプションであるPacket、および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.
上記の仮定がますます少なくなっている理由は、リンク層技術の属性によって引き起こされる効果と、ネットワーク層テクノロジーによって引き起こされる効果の2つのカテゴリに分割できるようになります。
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 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.
RFC 3819 [RFC3819]は、リンク層プロトコルデザイナーにこれらの効果を最小限に抑えるようアドバイスします。一般に、リンク層の原因は意図的にIPを破ろうとするのではなく、テクノロジーにIPを追加することで問題が導入されます。したがって、リンク層プロトコル自体がそうしない場合、そのようなリンクプロトコルでIPがどのように定義されるかを指定する場合、設計者は可能な限り最大限に補償する必要があります。例として、[RFC3077]と[RFC2491]は、対称的な到達可能性の欠如とリンク層マルチキャストの欠如をそれぞれ補償します。つまり、IPがリンクタイプで定義されている場合、プロトコル設計者はこのドキュメントにリストされている仮定を復元しようとする必要があります。たとえば、実装は802.11 Ad Hocモードとインフラストラクチャモードを区別できるため、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]）は、不正な当事者による到達可能性を制限することが望ましい。実際、IPモデルの不可欠な部分であるIPSECは、そのための1つの手段を提供します。非対称性、非翻訳性などに問題がある場合、認可された当事者のみに到達可能性を制限する直接的な結果ではない場合（認定された一部の定義のために）、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]）の間に、問題を解決することに圧力をかけたいという欲求の間には、争いが存在します。解決策の1つは、問題をマスクするのではなく、問題を確認できる別の「ペダンティックモード」を提供することです。
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.
多くのアプリケーションとプロトコルは、4バイトの長さのアドレスのみをサポートするように設計されています。これはIPv4にとって十分でしたが、IPv6の出現によりこの仮定が無効になり、IPv4アドレス空間の消耗により、この仮定はますます低くなります。制約された症例では、この問題を限られている成功の程度でこの問題を軽減しようとする試みがいくつかありました。たとえば、「Bumb-in-the-Stack」[RFC2767]および「Bump-in-api」[RFC3338]は、IPv6の宛先に4バイトの「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などのプロトコルの1つの使用は、このようなアプリケーションで使用できる追加の「アドレス」を追加することにより、この仮定をやや真実にすることであり、プロトコルは複数の物理インターフェイスとアドレスの複雑さを扱います。
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サービスモデルにAnycastの概念を導入しました。それは次のように述べています：
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.
AnyCastingはステートレスであり、複数のAnycastデータグラムの同じシステムへの配信を保証しないため、アプリケーションは、2つの連続したUDP送信または同じAnycastアドレスへの2つの連続した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].
Anycastの問題については、[RFC4786]および[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]の両方で定義されているように、スコープアドレスの結果となります。このようなアドレスは複数のネットワーク内で再利用できるため、異なるネットワークのホストは同じアドレスを使用できます。その結果、そのような2つのネットワークにマルチホームされたホストは、宛先アドレスを使用してピアを一意に識別することはできません。たとえば、ホストは5タプルを使用してTCP接続を一意に識別することができなくなりました。これが、IPv6が「ゾーンインデックス」の概念を追加した理由です。
Yet another example is that, in some high-availability solutions, one host takes over the IP address of another failed host.
さらに別の例は、一部の高可用性ソリューションでは、1人のホストが別の失敗したホストのIPアドレスを引き継ぐことです。
See [RFC2101], [RFC2775], and [SHARED-ADDRESSING] for additional discussion on address uniqueness.
アドレスの一意性に関する追加の議論については、[RFC2101]、[RFC2775]、および[共有アドレスリング]を参照してください。
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を参照してください。
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.
一部のアプリケーションは、アプリケーションが使用するアドレスがルーティングで使用されているアドレスと同じであると想定しています。たとえば、一部のアプリケーションでは、RAWソケットを使用して、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や股関節などのプロトコルは、この仮定を特異的に破壊します（上記のように他の仮定を復元しようとして）。最近、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は、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.
ある程度、これは決して真実ではありませんでした。「マスク」が255.255.255.255であったIPv4には、2つのエンドポイントが無関係のアドレススペースからアドレスを持っていたポイントツーポイントリンクなど、リンクにはリンクサブネットプレフィックスが存在していました。ただし、これにより、すべてのアドレスがリンクされている「マスク」（またはプレフィックス）があると仮定することで、多くのプラットフォームやアプリケーションが停止しませんでした。サブネットがオンリンクであるかどうか（この場合、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.
1つの課題は、今日の多くのホストには解決できる名前がないことです。たとえば、ホストには、その名前をホストする完全な資格のあるドメイン名（FQDN）またはドメイン名システム（DNS）サーバーを持たない場合があります。
Applications that, for whatever reason, cannot use names should be IP-version agnostic.
何らかの理由で、名前を使用できないアプリケーションは、IPバージョンに異議を唱える必要があります。
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フェールオーバーをサポートしなければならない結果、より高いレイテンシを維持するためにアプリケーションを設計する必要がある場合があります。
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]は、データと制御チャネルに個別のストリームを使用するこのようなプロトコルの2つの例です。
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は現在インターネットで広く使用されていません。
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を使用する膨大な数のアプリケーションがすでに存在するため、サービスモデルの変更は非常に注意して行う必要があります。既存のアプリケーションに影響を与えることなく追加のオプション機能を追加するだけの拡張機能は、上記のコア仮定の1つ以上を変更する拡張よりもはるかに安全です。上記の仮定の変更は、ミッションクリティカルなアプリケーションを破壊するリスクを最小限に抑えるか軽減するためのいくつかのメカニズムに従ってのみ行う必要があります。歴史的に、変更はそのような考慮事項に関係なく行われてきました。その結果、今日のアプリケーションの状況はすでに問題があります。相互運用可能なインターネットを維持するための鍵は、より高いレイヤーが依存する可能性があるという不変性を文書化および維持することであり、変更に非常に賢明であることです。
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
ロア・アンダーソン・ゴンザロ・カマリロ・スチュアート・チェシャー・ラス・ハウズリー・オラフ・コルクマン・グレゴリー・レボビッツ・バリー・レイバ・カルティス・リンドクヴィスト・アンドリュー・マリス・ダニー・マクファーソン・デイヴィッド・オラン・デイバー・ザン・リキア・ザン
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 791、1981年9月。
[RFC1112] Deering, S., "Host extensions for IP multicasting", STD 5, RFC 1112, August 1989.
[RFC1112] Deering、S。、「IPマルチキャストのホスト拡張」、STD 5、RFC 1112、1989年8月。
[RFC1122] Braden, R., "Requirements for Internet Hosts - Communication Layers", STD 3, RFC 1122, October 1989.
[RFC1122] Braden、R。、「インターネットホストの要件 - 通信レイヤー」、STD 3、RFC 1122、1989年10月。
[RFC1546] Partridge, C., Mendez, T., and W. Milliken, "Host Anycasting Service", RFC 1546, November 1993.
[RFC1546] Partridge、C.、Mendez、T。、およびW. Milliken、「Host Anycasting Service」、RFC 1546、1993年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）の近隣発見」、RFC 2461、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 4301、2005年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 4861、2007年9月。
[ANYCAST] McPherson, D. and D. Oran, "Architectural Considerations of IP Anycast", Work in Progress, February 2010.
[Anycast] McPherson、D。and D. Oran、「IP Anycastの建築上の考慮事項」、2010年2月のWork in Progress。
[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 0124、2010、<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/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 23、1978年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 28、1978年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。and J. Postel、「ARPAインターネット環境でのモバイルホストへの対処」、IEN 135、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-multicast-addresses>。
[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.、et al。、「New Arch：Future Generation Internet Architecture」、空軍研究所技術レポートAFRL-IF-RS-2004-235、2004年8月、<http：// www。dtic.mil/cgi-bin/ gettrdoc？ad = ada426770＆location = u2＆doc = gettrdoc.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 Subnet Model」、Progress、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.
[Reorder] Bennett、J.、Partridge、C。、およびN. Shectman、「パケットの並べ替えは病理学的ネットワークの動作ではありません」、IEEE/ACMトランザクションのネットワーク、Vol。7、No。6、1999年12月。
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.
[RFC0793] Postel、J。、「トランスミッションコントロールプロトコル」、STD 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、「ファイル転送プロトコル」、STD 9、RFC 959、1985年10月。
[RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, November 1990.
[RFC1191] Mogul、J。およびS. Deering、「Path MTU Discovery」、RFC 1191、1990年11月。
[RFC1812] Baker, F., "Requirements for IP Version 4 Routers", RFC 1812, June 1995.
[RFC1812] Baker、F。、「IPバージョン4ルーターの要件」、RFC 1812、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、「Private Internetsのアドレス割り当て」、BCP 5、RFC 1918、1996年2月。
[RFC1958] Carpenter, B., "Architectural Principles of the Internet", RFC 1958, June 1996.
[RFC1958]カーペンター、B。、「インターネットの建築原理」、RFC 1958、1996年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のPath MTU Discovery」、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アドレスToday」、RFC 2101、1997年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、「Bump-in-the-Stack」テクニック（BIS）を使用したデュアルスタックホスト、RFC 2767、2000年2月。
[RFC2775] Carpenter, B., "Internet Transparency", RFC 2775, February 2000.
[RFC2775]カーペンター、B。、「インターネット透明性」、RFC 2775、2000年2月。
[RFC2923] Lahey, K., "TCP Problems with Path MTU Discovery", RFC 2923, September 2000.
[RFC2923] Lahey、K。、「Path MTU DiscoveryのTCP問題」、RFC 2923、2000年9月。
[RFC2979] Freed, N., "Behavior of and Requirements for Internet Firewalls", RFC 2979, October 2000.
[RFC2979] Freed、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、「UnicastおよびMulticast Next-Hop Selectionのマルチパス問題」、RFC 2991、2000年11月。
[RFC2993] Hain, T., "Architectural Implications of NAT", RFC 2993, November 2000.
[RFC2993] Hain、T。、「Natの建築的意味」、RFC 2993、2000年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 3021、2000年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、「Bumb-in-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 3550、2003年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）」、RFC 3618、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 3775、2004年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.、Ludwig、R.、Mahdavi、J.、Montenegro、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 Link-Localアドレスの動的構成」、RFC 3927、2005年5月。
[RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", RFC 3972, March 2005.
[RFC3972]オーラ、T。、「暗号化されたアドレス（CGA）」、RFC 3972、2005年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 4380、2006年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 4601、2006年8月。
[RFC4786] Abley, J. and K. Lindqvist, "Operation of Anycast Services", BCP 126, RFC 4786, December 2006.
[RFC4786] Eabley、J。およびK. Lindqvist、「Anycast Servicesの運用」、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、「Packetization Layer Path MTU Discovery」、RFC 4821、2007年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 4890、2007年5月。
[RFC4903] Thaler, D., "Multi-Link Subnet Issues", RFC 4903, June 2007.
[RFC4903] Thaler、D。、「マルチリンクサブネットの問題」、RFC 4903、2007年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、「2006年3月9〜10日、不要なトラフィックに関するIABワークショップの報告」、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、「Proxy Mobile 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 5694、2009年11月。
[SHARED-ADDRESSING] Ford, M., Boucadair, M., Durand, A., Levis, P., and P. Roberts, "Issues with IP Address Sharing", Work in Progress, March 2011.
[Shared-Addressing] Ford、M.、Boucadair、M.、Durand、A.、Levis、P。、およびP. Roberts、「IPアドレス共有の問題」、2011年3月、進行中の作業。
[WAIST-HOURGLASS] Rosenberg, J., "UDP and TCP as the New Waist of the Internet Hourglass", Work in Progress, February 2008.
[ウエスト・ハーグラス]ローゼンバーグ、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、「ワイヤレスネットワーク研究の誤った公理」、Dartmouth College Computer Science Technical Report 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 One Microsoft Way Redmond、WA 98052 USA
Phone: +1 425 703 8835
EMail: dthaler@microsoft.com
Internet Architecture Board
インターネットアーキテクチャボード
EMail: iab@iab.org