Internet Architecture Board (IAB) D. Thaler
Request for Comments: 6250 May 2011
Category: Informational
ISSN: 2070-1721
Evolution of the IP Model
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ドキュメント（http://trustee.ietf.org/license-info）に関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。
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サービスモデルは、（その時代遅れのRFCで、その後と）元IENsに記載されていました。マントラは、「IPオーバーすべて」となっているので、IPサービスモデルは、元の定義は想像しませんでした新しい行動を可能にするために、過去30年間で大幅に進化してきました。例えば、1989年、いくつかの混乱ので、[RFC1122]は多くのことを明らかにし、モデルを拡張し、すでにありました。 2004年には、[RFC3819]上位層に影響を与え、この文書に意図で最も近い問題の数にリンク層プロトコルの設計者に助言。今日のIPサービスモデルはよく1つの場所で文書化されますが、暗黙的または多くの異なった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つの対向する方向に進化よりも、一貫性を保つことが重要です。それは時々IPサービスモデルを変更しますIETFのワーキンググループでのケース方向を撮影したとしても考えられたりしていることを今日です。アプリケーション上の意味合いを理解せずにこれを行うことは危険なことができます。
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]及びセクション5及び[NEWARCH]の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）または1のIPv6のホップ限界ライブするためにどの内トポロジーの領域を指します。 （TTL /ホップリミット減少を伴う）は、IP層の転送が2つのノード間で発生していないところがあります。
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）と（次の例の図のように）ファイアウォールアドレス、これはもはや仮定することはできません。今日では、ホスト間の接続は、一般的には困難な場合ではないことは不可能です。なく、その逆もホスト-E間、サーバ（S）に（例えば、図中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].
[WIRELESS]のセクション5.5で議論するように、最終的に、このような802.11のような一般的な無線ネットワークと、この仮定は、真ではないかもしれません。
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に接触することができる場合、この現象の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のファイアウォールとさまざまなルーティングポリシーなどの技術の登場により、これはもはや、インターネット経由で想定していないが、それは多くの場合、まだ真のリンク内であることができます。その結果、上位層プロトコルおよびアプリケーションは、リンク内の推移に依存してもよいです。しかし、このよう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エラーメッセージを配信することができません送信されたパケットに応答して受信されることを前提としています。この例は、パケットが大きすぎて、やtraceroute、パケットがそのTTL /ホップリミットに達し示すメッセージに頼るリング検索[RFC1812]を拡大するのに使用した示すメッセージを頼りパスMTUディスカバリー[RFC1191] [RFC1981]の使用を含みます。
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）というこの仮定に依存しないパス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アドホックモード）が存在します。 / 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）に合図しなければならないことも注目に値します彼らは、ブロードキャストアドレスにトラフィックを送信することができます前に。しかし、ネットワークの観点から、ホストがまだ先験的に信号を送ることなく、送信します。
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.
多くのアプリケーションおよびプロトコルは、候補の数のそれぞれにメッセージを送信応答する最初のものを選んで、そしてその後の通信のためにその宛先を使用して、宛先アドレスを選択します。各宛先への最初のパケットのエンドツーエンドのレイテンシが非定型である場合、これは非常に長いパス（インターネット上したがって高負荷）と低いスループットと、選択された高度に最適でない宛先をもたらすことができます。
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.
[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.
また、単にも、むしろそれをキューイングよりも、最初のパケットをドロップするメカニズムはこの仮定を破ります。並べ替えの結果と同様、彼らが応答する最初のものを使用するアプリケーションによって選択された高度に最適でない宛先をもたらすことができます。指定されたパターンに一致するすべてのパケットが電力節約モードでマシンを覚ますが、唯一のマッチングを落とした後だろう「ウェイクオンLAN」機能をサポートし、このされているネットワークインターフェイスカードを行うように見えるのメカニズムの2つの例パケット、およびデータパケットをカプセル化することはオプションですが、そうすることが、マルチキャストツリーが元のドメインに戻って構築されていながら、バースト性のソースを収容することを可能にする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において、アプリケーションは、いずれかのエンドツーエンドパスが宛先に存在するか、パケットがドロップされることを仮定する。 （-to-ライブ「時間」は、単にホップ数であるので）また、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
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モデルの不可欠な部分は、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]）より成功する願望の間に存在します。一つの解決策は、問題を見るのではなく、それらを隠すために有効にすることができる独立した「知識をひけらかすモード」を提供することです。
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]は、ローカルエリアの周りにローミングしながら、同じアドレスを保存することで、ある程度この仮定を復元しようとします。異なるネットワーク間のローミングの問題は、インターネット接続でどこでもローミング中に安定しているアプリケーションで使用できる追加のアドレスを、追加することによって、この仮定を復元しようとしたモビリティ・ソリューションを提案している[IEN135]少なくとも1980年から知られています。こうしたモバイル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アドレス空間の枯渇と、この仮定はますます少なく、真となります。制約の例では、成功の限られた程度で、この問題を軽減しようとするいくつかの試みがなされてきました。例えば、[RFC2767] "イン・スタックバンプ" との "bump-in-the-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つの用途は、このような用途で使用されるものとすることができ、プロトコルは複数の物理インターフェースとアドレスの複雑さに対処する追加「アドレス」を追加することによって、この仮定が幾分真にすることです。
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.
また、多くのセキュリティメカニズムや構成は1つが、単一の攻撃者が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.
エニーキャストはステートレスで、同じシステムに複数のエニーキャストデータグラムの配信を保証するものではありませんので、アプリケーションは、2つの連続したUDP送信または同じエニーキャストアドレスには、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]で議論されており。
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つのそのようなネットワークにマルチホームされたホストを一意にピアを識別するための宛先アドレスを使用することはできません。例えば、ホストは、もはや一意にTCPコネクションを識別するために、5タプルを使用することはできません。 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]、およびアドレスの一意性に関する追加の議論のための[SHAREDアドレッシング]を参照してください。
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の使用は増加し続けると、これはますます少なく真となるであろう。長い議論のための[SHAREDアドレッシング]のセクション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 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.
ある程度、これは「マスク」は、このような2つのエンドポイントは無関係なアドレス空間の外のアドレスを持っていたポイントツーポイントリンク上として、255.255.255.255たIPv4の例があったことで、真のなかった、とありませんオンリンクサブネットプレフィックスがリンク上で存在していました。しかし、これはすべてのアドレスがオンリンクした「マスク」（またはプレフィックス）を持っていたと仮定してから、多くのプラットフォームやアプリケーションを停止していません。サブネットがオンリンクであるかどうかの仮定（1がARP / NDを使用した後、宛先に直接送信することができ、その場合には）またはオフリンクは、（1だけのルータに送信する場合には）長年にわたって進化してきた、そしてそれもはやアドレスがオンリンクプレフィックスを持っていることを前提とすることはできません。 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-バージョンである必要があります。
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はもともと、新しいトランスポート層プロトコルの追加をサポートするように設計され、[PROTOCOLS]多くのそのようなプロトコルを示しました。
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. クレーム：アドレスのペアの間に1つのストリームを介して取得することができた場合は、そのようにすることができます別
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).
この目標は、トランスポートレベルでのサービスのさまざまな種類のをサポートすることにより、アプリケーションの可能な限り広い範囲をサポートすることでした。サービスは、例えば、速度、遅延、または信頼性によって区別されることがあります。サービスの種類は、信頼性の高い、全二重バイトストリームを提供し、また信頼性や秩序の無保証で個々のパケットを提供するサービスを、データグラムの仮想回線サービスを、含まれることがあります。データグラムサービスのための要件は、（IMPタイプ3のメッセージを使用して）パケット音声による早期ARPAnetの実験によって動機づけられました。
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]は、トランスポート・モードのIPsecが現在広くインターネット上で使用されていないが、アプリケーションを変更せずにこの問題に対処する方法を提供し、IPモデルにセキュリティを追加しました。
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と暗号化生成アドレス（CGAs）[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.
クリスHoppsが、ダウ・ストリート、フィル・ハラム・ベイカー、その他は、この文書につながった様々な点で有益な議論を提供します。イアン・カルダー、ブライアン大工、ジョナサン・ローゼンバーグ、エリックNordmarkと、アラン・デュラン、およびIljitschバン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
ロア・アンダーソンゴンサロ・カマリロスチュアートチェシャーラスHousleyオラフKolkmanグレゴリーLebovitzバリー・レイバカーティスLindqvistアンドリューMalisダニー・マクファーソンデヴィッドオランデーブターラーLixiaチャン
Bernard Aboba Marcelo Bagnulo Ross Callon Spencer Dawkins Russ Housley John Klensin Olaf Kolkman Danny McPherson Jon Peterson Andrei Robachevsky Dave Thaler Hannes Tschofenig
バーナードAbobaマルセロBagnuloロスCallonスペンサーダウキンズラスHousleyジョン・クレンシンオラフKolkmanダニー・マクファーソンジョン・ピーターソンアンドレイRobachevskyデーブターラーハンネスTschofenig
[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
[RFC0791]ポステル、J.、 "インターネットプロトコル"、STD 5、RFC 791、1981年9月。
[RFC1112] Deering, S., "Host extensions for IP multicasting", STD 5, RFC 1112, August 1989.
[RFC1112]デアリング、S.、STD 5、RFC 1112 "IPマルチキャスティングのためのホスト拡大"、1989年8月。
[RFC1122] Braden, R., "Requirements for Internet Hosts - Communication Layers", STD 3, RFC 1122, October 1989.
[RFC1122]ブレーデン、R.、 "インターネットホストのための要件 - 通信層"、STD 3、RFC 1122、1989年10月。
[RFC1546] Partridge, C., Mendez, T., and W. Milliken, "Host Anycasting Service", RFC 1546, November 1993.
[RFC1546]ウズラ、C.、メンデス、T.、およびW.ミリケン、 "ホストエニーキャストサービス"、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.シンプソン、 "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]ケント、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.、シンプソン、W.、およびH.ソリマン、 "IPバージョン6（IPv6）のための近隣探索"、RFC 4861、2007年9月。
[ANYCAST] McPherson, D. and D. Oran, "Architectural Considerations of IP Anycast", Work in Progress, February 2010.
[ANYCAST]マクファーソン、D.とD.オラン、 "IPエニーキャストの建築に関する注意事項"、進歩、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】パターソン、I.、スミス、D.、サンアンドレ、P.、およびJ.モフィット、 "同期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/ien19.txt>。
[IEN023] Cohen, D., "On Names, Addresses and Routings", IEN 23, January 1978, <http://www.rfc-editor.org/ien/ien23.txt>.
[IEN023]コーエン、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]ポステル、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>.
"ARPAインターネット環境でのモバイルホストのアドレス指定" [IEN135]サンシャイン、C.とJ.ポステル、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マルチキャストアドレス>。
[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]クラーク、D.、ら、 "新アーチ：次世代インターネットアーキテクチャ"。、空軍研究所テクニカルレポートAFRL-IF-RS-TR-2004-235、2004年8月、<のhttp：// WWW。 dtic.mil/cgi-bin/ GetTRDoc？AD = ADA426770＆場所= U2＆ドキュメント= GetTRDoc.pdf>。
[ON-OFF-LINK] Singh, H., Beebee, W., and E. Nordmark, "IPv6 Subnet Model", Work in Progress, February 2008.
[ON-OFF-LINK]シン、H.、Beebee、W.、およびE. Nordmarkと、 "IPv6のサブネットモデル"、進歩、2008年2月に作業。
[PROTOCOLS] Internet Assigned Numbers Authority, "Protocol Numbers", <http://www.iana.org/assignments/protocol-numbers>.
[PROTOCOLS]インターネット割り当て番号機関、 "プロトコル番号"、<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】ベネット、J.、ヤマウズラ、C.、およびN. Shectmanは、ネットワーク上のIEEE / ACMトランザクション、VOL "パケットの並び替えは、病的なネットワーク動作ではありません"。図7に示すように、第6号、1999年12月。
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.
[RFC0793]ポステル、J.、 "伝送制御プロトコル"、STD 7、RFC 793、1981年9月。
[RFC0925] Postel, J., "Multi-LAN address resolution", RFC 925, October 1984.
[RFC0925]ポステル、J.、 "マルチLANアドレス解決"、RFC 925、1984年10月。
[RFC0959] Postel, J. and J. Reynolds, "File Transfer Protocol", STD 9, RFC 959, October 1985.
[RFC0959]ポステル、J.、およびJ.レイノルズ、 "ファイル転送プロトコル"、STD 9、RFC 959、1985年10月。
[RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, November 1990.
[RFC1191]ムガール人、J.とS.デアリング、 "パスMTUディスカバリ"、RFC 1191、1990年11月。
[RFC1812] Baker, F., "Requirements for IP Version 4 Routers", RFC 1812, June 1995.
[RFC1812]ベイカー、F.、RFC 1812、1995年6月 "IPバージョン4つのルータのための要件"。
[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.、モスコウィッツ、R.、Karrenberg、D.、グルート、G.、およびE.リア、 "個人的なインターネットのための配分"、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]マッキャン、J.、デアリング、S.、およびJ.ムガール人、RFC 1981、1996年8月 "IPバージョン6のパスMTUディスカバリー"。
[RFC2101] Carpenter, B., Crowcroft, J., and Y. Rekhter, "IPv4 Address Behaviour Today", RFC 2101, February 1997.
[RFC2101]カーペンター、B.、クロウクロフト、J.、およびY. Rekhter、 "IPv4アドレス動作今日"、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.
、RFC 2491、1999年1月 "非ブロードキャスト多重アクセス（NBMA）ネットワーク上のIPv6" [RFC2491]アーミテージ、G.、Schulter、P.、Jorkの、M.、およびG.ハーター、。
[RFC2767] Tsuchiya, K., HIGUCHI, H., and Y. Atarashi, "Dual Stack Hosts using the "Bump-In-the-Stack" Technique (BIS)", RFC 2767, February 2000.
[RFC2767]土屋、K.、樋口、H.、およびY. Atarashi、バンプ・イン・スタック "技術（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]レイヒー、K.、 "パスMTUディスカバリとTCPの問題"、RFC 2923、2000年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]ターラー、D.およびC. Hoppsが、 "ユニキャストとマルチキャストの次ホップの選択におけるマルチパスの問題"、RFC 2991、2000年11月。
[RFC2993] Hain, T., "Architectural Implications of NAT", RFC 2993, November 2000.
[RFC2993]ハイン、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.、ホワイト、R.、フラー、V.、および、RFC 3021、2000年12月、 "IPv4のポイントツーポイントリンク上で31ビットのプレフィックスを使用する" D.マクファーソン、。
[RFC3069] McPherson, D. and B. Dykes, "VLAN Aggregation for Efficient IP Address Allocation", RFC 3069, February 2001.
"効率的なIPアドレス割り当てのためのVLAN集計" [RFC3069]マクファーソン、D.とB.ダイクス、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.、藤井、N.、およびY.チャン、 "単方向リンクのリンク層トンネル機構"、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]リー、S.、シン、MK。、金、YJ。、Nordmarkと、E.、およびA.デュラン、 "（BIA）の "bump-in-the-API 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.、フレデリック、R.、およびV.ヤコブソン、 "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]レスコラ、E.とB.コーバー、BCP 72、RFC 3552、2003年7月、 "セキュリティ上の考慮事項の書き方RFCテキストのためのガイドライン"。
[RFC3618] Fenner, B. and D. Meyer, "Multicast Source Discovery Protocol (MSDP)", RFC 3618, October 2003.
[RFC3618]フェナー、B.とD.マイヤー、 "は、Multicast Source Discovery Protocol（MSDP）"、RFC 3618、2003年10月。
[RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004.
[RFC3775]ジョンソン、D.、パーキンス、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]カーン、P.、ボルマン、C.、Fairhurst、G.、グロスマン、D.、ルートヴィヒ、R.、Mahdavi、J.、モンテネグロ、G.、タッチ、J.、およびL.ウッド、「アドバイスインターネットサブネットワークデザイナー」、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]チェシャー、S.、Aboba、B.、およびE.ガットマン、 "IPv4のリンクローカルアドレスの動的構成"、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]デアリング、S.、ハーバーマン、B.、神明、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：ネットワークアドレス変換を通じてUDP経由トンネリングのIPv6器（NAT）"、RFC 4380、2006年2月。
[RFC4423] Moskowitz, R. and P. Nikander, "Host Identity Protocol (HIP) Architecture", RFC 4423, May 2006.
[RFC4423]モスコウィッツ、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]フェナー、B.、ハンドリー、M.、ホルブルック、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] 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]マシス、M.とJ. Heffner、 "パケット化レイヤのパスMTUディスカバリ"、RFC 4821、2007年3月。
[RFC4890] Davies, E. and J. Mohacsi, "Recommendations for Filtering ICMPv6 Messages in Firewalls", RFC 4890, May 2007.
[RFC4890]デイヴィス、E.およびJ. Mohacsi、 "ファイアウォールでのフィルタリングICMPv6メッセージへの提言"、RFC 4890、2007年5月。
[RFC4903] Thaler, D., "Multi-Link Subnet Issues", RFC 4903, June 2007.
[RFC4903]ターラー、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]アンデション、L.、デイヴィス、E.、およびL.チャン、 "不要なトラフィック月9-10、2006年IABワークショップからの報告書"、RFC 4948、2007年8月。
[RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008.
[Ramphsi 5213] gundavelli、S。、Leunjiは、K.、Devarapalliは、VEの。、Chaudhuriの、K.、aとb。パティル、 "プロキシモバイル20 6"、rphak 5213、2008年8月。
[RFC5218] Thaler, D. and B. Aboba, "What Makes For a Successful Protocol?", RFC 5218, July 2008.
[RFC5218]ターラー、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]キャマリロ、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-アドレッシング]フォード、M.、Boucadair、M.、デュラン、A.、リーバイス、P.、およびP.ロバーツ、進歩、2011年3月に、作業 "IPアドレス共有の問題"。
[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.、ニューポート、C.、およびC.エリオット、 "ワイヤレス・ネットワーク研究の誤公理"、ダートマス大学コンピュータサイエンステクニカルレポート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
デーブターラー1マイクロソフト道、レッドモンド、ワシントン98052 USA
Phone: +1 425 703 8835 EMail: dthaler@microsoft.com
電話：+1 425 703 8835 Eメール：dthaler@microsoft.com
Internet Architecture Board
インターネットアーキテクチャ委員会
EMail: iab@iab.org
メールアドレス：iab@iab.org