RFC4903 日本語訳
4903 Multi-Link Subnet Issues. D. Thaler. June 2007. (Format: TXT=39671 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group D. Thaler Request for Comments: 4903 Internet Architecture Board Category: Informational June 2007
ターレルがコメントのために要求するワーキンググループD.をネットワークでつないでください: 4903年のインターネット・アーキテクチャ委員会カテゴリ: 情報の2007年6月
Multi-Link Subnet Issues
マルチリンクサブネット問題
Status of This Memo
このメモの状態
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。 それはどんな種類のインターネット標準も指定しません。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The IETF Trust (2007).
IETFが信じる著作権(C)(2007)。
Abstract
要約
There have been several proposals around the notion that a subnet may span multiple links connected by routers. This memo documents the issues and potential problems that have been raised with such an approach.
サブネットがルータによって接続された複数のリンクにかかるかもしれないという概念の周りにいくつかの提案がありました。 このメモはそのようなアプローチで提起された問題と潜在的な問題を記録します。
Table of Contents
目次
1. Introduction ....................................................2
2. Issues ..........................................................3
2.1. IP Model ...................................................3
2.2. TTL/Hop Limit Issues .......................................4
2.3. Link-scoped Multicast and Broadcast ........................6
2.4. Duplicate Address Detection Issues .........................7
3. Security Considerations .........................................8
4. Recommendations .................................................9
4.1. IP Link Model ..............................................9
4.2. IPv6 Address Assignment ...................................10
4.3. Duplicate Address Detection Optimizations .................12
5. Normative References ...........................................12
6. Informative References .........................................13
1. 序論…2 2. 問題…3 2.1. IPモデル…3 2.2. TTL/ホップは問題を制限します…4 2.3. リンクで見られたマルチキャストと放送…6 2.4. アドレス検出問題をコピーしてください…7 3. セキュリティ問題…8 4. 推薦…9 4.1. IPリンクモデル…9 4.2. IPv6は課題を扱います…10 4.3. アドレス検出最適化をコピーしてください…12 5. 標準の参照…12 6. 有益な参照…13
Thaler Informational [Page 1] RFC 4903 Multi-Link Subnet Issues June 2007
情報[1ページ]のRFC4903マルチリンクサブネットが2007年6月に支給するターレル
1. Introduction
1. 序論
The original IPv4 address definition [RFC791] consisted of a Network field, identifying a network number, and a Local Address field, identifying a host within that network. As organizations grew to want many links within their network, their choices were (from [RFC950]) to:
オリジナルのIPv4アドレス定義[RFC791]はNetwork分野から成りました、ネットワーク・ナンバー、およびLocal Address分野を特定して、そのネットワークの中でホストを特定して。 組織がそれらのネットワークの中の多くのリンクが欲しくなったように、以下には彼らの選択がありました([RFC950]から)。
1. Acquire a distinct Internet network number for each cable;
subnets are not used at all.
1. それぞれのケーブルの異なったインターネットネットワーク・ナンバーを取得してください。 サブネットは全く使用されません。
2. Use a single network number for the entire organization, but
assign host numbers without regard to which LAN a host is on
("transparent subnets").
2. 全体の組織のただ一つのネットワーク・ナンバーを使用しなさい、ただし、関係なしでホストが(「透明なサブネット」)のどのLANであるかにホスト番号を割り当ててください。
3. Use a single network number, and partition the host address
space by assigning subnet numbers to the LANs ("explicit
subnets").
3. ただ一つのネットワーク・ナンバーを使用してください、そして、LAN(「明白なサブネット」)にサブネット番号を割り当てることによって、ホストアドレス空間を仕切ってください。
[RFC925] was a proposal for option 2 that defined a specific type of Address Resolution Protocol (ARP) proxy behavior, where the forwarding plane had the properties of decrementing the Time To Live (TTL) to prevent loops when forwarding, not forwarding packets destined to 255.255.255.255, and supporting subnet broadcast by requiring that the ARP-based bridge maintain a list of recent broadcast packets. This approach was never standardized, although [RFC1027] later documented an implementation of a subset of [RFC925].
[RFC925]は特定のタイプのAddress Resolutionプロトコル(ARP)プロキシの振舞いを定義したオプション2のための提案でした。(そこでは、推進飛行機がARPベースのブリッジが最近の放送パケットのリストを維持するのを必要とすることによって255.255.255の.255、およびサポートサブネット放送に運命づけられたパケットを進めるのではなく、進めるとき輪を防ぐために、Time To Live(TTL)を減少させる特性を持っていました)。 [RFC1027]は後で[RFC925]の部分集合の実装を記録しましたが、このアプローチは決して標準化されませんでした。
Instead, the IETF standardized option 3 with [RFC950], whereby hosts were required to learn a subnet mask, and this became the IPv4 model.
代わりに、IETFはホストがサブネットマスクを学ばなければならなかった[RFC950]とのオプション3を標準化しました、そして、これはIPv4モデルになりました。
Over the recent past, there have been several newer protocols proposing to extend the notion of a subnet to be able to span multiple links, similar to [RFC925].
最近の過去の間、複数のリンクにかかることができるようにサブネットの概念について敷衍するよう提案するいくつかの、より新しいプロトコルがあります、[RFC925]と同様です。
Early versions of the IPv6 scoped address architecture [SCOPID] proposed a subnet scope above the link scope, to allow for multi-link subnets. This notion was rejected by the WG due to the issues discussed in this memo, and as a result the final version [RFC4007] has no such notion.
IPv6の早めのバージョンは、アドレス体系[SCOPID]がマルチリンクサブネットを考慮するためにリンク範囲の上のサブネット範囲を提案したのを見ました。 この概念はこのメモで議論した問題のためWGによって拒絶されました、そして、その結果、最終版[RFC4007]には、どんなそのような考えもありません。
There was also a proposal to define multi-link subnets [MLSR] for IPv6. However, this notion was abandoned by the IPv6 WG due to the issues discussed in this memo, and that proposal was replaced by a different mechanism that preserves the notion that a subnet spans only one link [RFC4389].
また、IPv6のために、マルチリンクサブネット[MLSR]を定義するという提案がありました。 しかしながら、IPv6 WGはこのメモで議論した問題のためこの概念を捨てました、そして、その提案をサブネットが1個のリンク[RFC4389]だけにかかっているという概念を保存する異なったメカニズムに取り替えました。
Thaler Informational [Page 2] RFC 4903 Multi-Link Subnet Issues June 2007
情報[2ページ]のRFC4903マルチリンクサブネットが2007年6月に支給するターレル
However, other WGs continued to allow for this concept even though it had been rejected in the IPv6 WG. Mobile IPv6 [RFC3775] allows tunnels to mobile nodes to use the same subnet as a home link, with the Home Agent doing layer 3 forwarding between them.
しかしながら、それはIPv6 WGで拒絶されましたが、他のWGsはずっとこの概念を考慮しました。 モバイルIPv6[RFC3775]はモバイルノードへのトンネルにホームのリンクと同じサブネットを使用させます、それらの間には、ホームエージェントする層3の推進がある状態で。
The notion also arises in Mobile Ad-hoc NETworks (MANETs) with proposals that an entire MANET is a subnet, with routers doing layer 3 forwarding within it.
また、概念はモバイルAd-hoc NETworks(MANETs)に全体のマネがサブネットであるという提案で起こって、ルータがしていて、それの中で進められる3は層にされています。
The use of multi-link subnets has also been considered by other working groups, including NetLMM, 16ng, and Autoconf, and by other external organizations such as WiMax.
また、マルチリンクサブネットの使用はNetLMM、16ng、およびAutoconfを含む他のワーキンググループとWiMaxなどの他の外部の組織によって考えられました。
In this memo, we document the issues raised in the IPv6 WG which motivated the abandonment of the multi-link subnet concept, so that designers of other protocols can (and should) be aware of the issues.
このメモでは、私たちは問題を意識していた状態でしたがってマルチリンクサブネット概念の放棄を動機づけた他のプロトコル缶の(and should)のデザイナーがいるIPv6 WGで提起された問題を記録します。
The key words "MUST", "RECOMMENDED", and "SHOULD" in this document are to be interpreted as described in [RFC2119].
キーワードの“MUST"、「推薦された」、およびこのドキュメントの“SHOULD"は[RFC2119]で説明されるように解釈されることになっています。
2. Issues
2. 問題
2.1. IP Model
2.1. IPモデル
The term "link" is generally used to refer to a topological area bounded by routers that decrement the IPv4 TTL or IPv6 Hop Limit when forwarding the packet. A link-local address prefix is defined in both IPv4 [RFC3927] and IPv6 [RFC4291].
一般に、「リンク」が位相的な領域について言及するのに使用される用語はパケットを進めるときIPv4 TTLかIPv6 Hop Limitを減少させるルータでバウンドしました。 リンクローカルアドレス接頭語はIPv4[RFC3927]とIPv6[RFC4291]の両方で定義されます。
The term "subnet" is generally used to refer to a topological area that uses the same address prefix, where that prefix is not further subdivided except into individual addresses.
一般に、「サブネット」という用語は、個々のアドレス以外に、その接頭語がさらに細分されないのと同じアドレス接頭語を使用する位相的な領域について言及するのに使用されます。
In December 1995, the original IP Version 6 Addressing Architecture [RFC1884] was published, stating: "IPv6 continues the IPv4 model that a subnet is associated with one link. Multiple subnets may be assigned to the same link."
1995年12月に、以下を述べて、オリジナルのIPバージョン6Addressing Architecture[RFC1884]は発行されました。 「IPv6は1個のリンクに関連していた状態でサブネットがそうであるIPv4モデルを続けています。」 「複数のサブネットが同じリンクに割り当てられるかもしれません。」
Thus, it explicitly acknowledges that the current IPv4 model has been that a subnet is associated with one link and that IPv6 does not change this model. Furthermore, a subnet is sometimes considered to be only a subset of a link, when multiple subnets are assigned to the same link.
したがって、それは、現在のIPv4モデルがサブネットが1個のリンクに関連していて、IPv6がこのモデルを変えないということであると明らかに認めます。 その上、サブネットはリンクの部分集合だけであると時々考えられます、複数のサブネットが同じリンクに割り当てられるとき。
The IPv6 addressing architecture has since been updated three times, first in July 1998 [RFC2373], then April 2003 [RFC3513], and finally in February 2006 [RFC4291]. All updates include the language: "Currently IPv6 continues the IPv4 model that a subnet prefix is
以来3回IPv6アドレッシング体系をアップデートしています、最初に、1998[RFC2373]年7月に、そして2003[RFC3513]年4月、および最終的に2006[RFC4291]年2月に。 すべてのアップデートが言語を含んでいます: 「サブネット接頭語はIPv4モデルですが、現在のIPv6は続きます」
Thaler Informational [Page 3] RFC 4903 Multi-Link Subnet Issues June 2007
情報[3ページ]のRFC4903マルチリンクサブネットが2007年6月に支給するターレル
associated with one link. Multiple subnet prefixes may be assigned to the same link."
1個のリンクに関連しています。 「複数のサブネット接頭語が同じリンクに割り当てられるかもしれません。」
Clearly, the notion of a multi-link subnet would be a change to the existing IP model.
明確に、マルチリンクサブネットの概念は既存のIPモデルへの変化でしょう。
Similarly, the Mobility Related Terminology [RFC3753] defines a Foreign subnet prefix as "a bit string that consists of some number of initial bits of an IP address which identifies a node's foreign link within the Internet topology" with a similar definition for a Home subnet prefix. These both state that the subnet prefix identifies a (singular) link.
同様に、Mobilityの関連Terminology[RFC3753]はホームサブネット接頭語のための同様の定義で「少し、それが何らかの数から成るストリングはインターネットトポロジーの中でノードの外国リンクを特定するIPアドレスのビットに頭文字をつける」とForeignサブネット接頭語を定義します。 これらは、サブネット接頭語が(まれ)のリンクを特定するとともに述べます。
2.2. TTL/Hop Limit Issues
2.2. TTL/ホップ限界問題
Since a link is bounded by routers that decrement the IPv4 TTL or IPv6 Hop Limit, there may be issues with applications and protocols that make any assumption about the relationship between TTL/Hop Limit and subnet prefix.
TTL/ホップLimitとサブネット接頭語との関係に関するどんな仮定もするアプリケーションとプロトコルの問題はリンクが境界があるからそこのIPv4 TTLかIPv6 Hop Limitを減少させるルータによるです。
There are two main cases that may arise. Some applications and protocols may send packets with a TTL/Hop Limit of 1. Other applications and protocols may send packets with a TTL/Hop Limit of 255 and verify that the value is 255 on receipt. Both are ways of limiting communication to within a single link, although the effects of these two approaches are quite different. Setting TTL/Hop Limit to 1 ensures that packets that are sent do not leave the link, but it does not prevent an off-link attacker from sending a packet that can reach the link. Checking that TTL/Hop Limit is 255 on receipt prevents a receiver from accepting packets from an off-link sender, but it doesn't prevent a sent packet from being forwarded off-link.
起こるかもしれない2つの主なケースがあります。 いくつかのアプリケーションとプロトコルが1のTTL/ホップLimitがあるパケットを送るかもしれません。 他のアプリケーションとプロトコルは、255のTTL/ホップLimitがあるパケットを送って、値が領収書の上の255であることを確かめるかもしれません。 両方がコミュニケーションを単一のリンクに制限する方法です、これらの2つのアプローチの効果は全く異なっていますが。 TTL/ホップLimitを1に設定するのは、送られるパケットがリンクを残しませんが、オフリンク攻撃者がリンクに達することができるパケットを送るのを防がないのを確実にします。 TTL/ホップLimitが領収書の上の255歳であることをチェックするのが受信機がオフリンク送付者からパケットを受け入れるのを防ぎますが、それは、オフリンクが送られたパケットに送られるのを防ぎません。
As for assumptions about the relationship between TTL/Hop Limit and subnet, let's look at some example references familiar to many protocol and application developers.
TTL/ホップLimitとサブネットとの関係に関する仮定に関して、多くのプロトコルとアプリケーション開発者にとってなじみ深くいくつかの例の参照を見ましょう。
Stevens' "Unix Network Programming", 2nd ed. [UNP], states on page 490, "A TTL of 0 means node-local, 1 means link-local" (this of course being true by the definition of link). Then page 498 states, regarding IP_MULTICAST_TTL and IPV6_MULTICAST_HOPS, "If this is not specified, both default to 1, which restricts the datagram to the local subnet." Here, Unix programmers learn that TTL=1 packets are restricted to a subnet (as opposed to a link). This is typical of many documents that use the terms interchangeably due to the IP model described earlier.
スティーブンスの「unixネットワーク・プログラミング」、2番目の教育。 [UNP]、490ページの州、「0のTTLは、ノード地方であり、1が、リンク地方であることを意味することを意味する」(これがもちろんリンクの定義で本当であることで)。 そして、「これが指定されないなら、両方がデータグラムを地方のサブネットに制限する1をデフォルトとします。」と、498ページは_IP MULTICAST_TTLとIPV6_MULTICAST_ホップスに関して述べます。 ここで、Unixプログラマは、TTL=1パケットがサブネット(リンクと対照的に)に制限されることを学びます。 これは、より早く説明されたIPモデルのため用語を互換性を持って使用する多くのドキュメントの典型です。
Thaler Informational [Page 4] RFC 4903 Multi-Link Subnet Issues June 2007
情報[4ページ]のRFC4903マルチリンクサブネットが2007年6月に支給するターレル
Similarly, "TCP/IP Illustrated", Volume 1 [TCPILL], states on page 182: "By default, multicast datagrams are sent with a TTL of 1. This restricts the datagram to the same subnet."
同様に、「TCP/IPは例証した」Volume1[TCPILL]は182ページに以下を述べます。 「デフォルトで、1のTTLと共にマルチキャストデータグラムを送ります。」 「これはデータグラムを同じサブネットに制限します。」
Steve Deering's original multicast README file [DEERING] contained the statement "multicast datagrams with initial TTL 1 are restricted to the same subnet", and similar statements now appear in many vendors' documentation, including documentation for Windows (e.g., [TCPIP2K]) and Linux (e.g., [LINUX] says a TTL of 1 is "restricted to the same subnet. Won't be forwarded by a router.")
スティーブ・デアリングのオリジナルのマルチキャストREADMEファイル[デアリング]は「初期のTTL1があるマルチキャストデータグラムは同じサブネットに制限され」て、同様の声明が今多くのベンダーのドキュメンテーションに載っているという声明を含みました、Windows(例えば、[TCPIP2K])とリナックスのためのドキュメンテーションを含んでいて(例えば、[リヌクス]は、1のTTLが「同じサブネットに制限される」と言います。 「ルータで、進められないでしょう。」)
The above are only some examples. There is no shortage of places where application developers are being taught that a subnet is confined to a single link, and so we must expect that arbitrary applications may embed such assumptions.
上記はいくつかだけの例です。 場所の不足が全くアプリケーション開発者がサブネットが単一のリンクに閉じ込められるので私たちが、任意のアプリケーションがそのような仮定を埋め込むかもしれないと予想しなければならないことを教えられているところにありません。
Some examples of protocols today that are known to embed some assumption about the relationship between TTL and subnet prefix are the following:
今日のTTLとサブネット接頭語との関係に関する何らかの仮定を埋め込むのが知られているプロトコルに関するいくつかの例が以下です:
o Neighbor Discovery (ND) [RFC2461] uses messages with Hop Limit
255 checked on receipt, to resolve the link-layer address of
any IP address in the subnet.
o 隣人ディスカバリー(ノースダコタ)[RFC2461]は、サブネットにおけるどんなIPアドレスのリンクレイヤアドレスも決議するのに領収書の上でチェックされるHop Limit255と共にメッセージを使用します。
o Older clients of Apple's Bonjour [MDNS] use messages with TTL
255 checked on receipt, and only respond to queries from
addresses in the same subnet. (Note that multi-link subnets do
not necessarily break this, as this behavior is to constrain
communication to within a subnet, where a subnet is only a
subset of a link. However, it will not work across a multi-
link subnet.)
o アップルのBonjour[MDNS]の、より年取ったクライアントは、領収書の上でチェックされるTTL255と共にメッセージを使用して、同じサブネットにおけるアドレスから質問に応じるだけです。 (マルチリンクサブネットが必ずこれを壊すというわけではないことに注意してください、この振舞いがサブネットへのコミュニケーション(サブネットはリンクの部分集合にすぎない)を抑制することであるので。 しかしながら、それはマルチリンクサブネットの向こう側に働かないでしょう。)
Some other examples of protocols today that are known to use a TTL 1 or 255, but do not appear to explicitly have any assumption about the relationship to subnet prefixes (other than the well-known link-local prefix) include the following:
今日のサブネット接頭語(よく知られるリンクローカルの接頭語を除いた)との関係に関するどんな仮定にも以下を明らかに含ませるようにTTL1か255を使用しますが、現れないのが知られているプロトコルに関するある他の例:
o Link-Local Multicast Name Resolution [LLMNR] uses a TTL/Hop
Limit of 1 for TCP.
o リンク地方のMulticast Name Resolution[LLMNR]はTCPに1のTTL/ホップLimitを使用します。
o Multicast Listener Discovery (MLD) [RFC3810] uses a Hop Limit
of 1.
o マルチキャストListenerディスカバリー(MLD)[RFC3810]は1のHop Limitを使用します。
o Reverse tunneling for Mobile IPv4 [RFC3024] uses TTL 255
checked on receipt for Registration Requests sent to foreign
agents.
o モバイルIPv4[RFC3024]のための逆のトンネリングは外国人のエージェントに送られたRegistration Requestsがないかどうか領収書の上でチェックされたTTL255を使用します。
Thaler Informational [Page 5] RFC 4903 Multi-Link Subnet Issues June 2007
情報[5ページ]のRFC4903マルチリンクサブネットが2007年6月に支給するターレル
o [RFC3927] discusses the use of TTL=1 and TTL=255 within the
IPv4 link-local address prefix.
o [RFC3927]はIPv4リンクローカルアドレス接頭語の中でTTL=1とTTL=255の使用について議論します。
It is unknown whether any implementations of such protocols exist that add such assumptions about the relationship to subnet prefixes for other reasons.
何か他の理由でサブネット接頭語との関係に関するそのような仮定を加えるそのようなプロトコルの実装が存在するかどうかが、未知です。
2.3. Link-scoped Multicast and Broadcast
2.3. リンクで見られたマルチキャストと放送
Because multicast routing is not ubiquitous, the notion of a subnet that spans multiple links tends to result in cases where multicast does not work across the subnet. Per [RFC2644], the default behavior is that routers do not forward directed broadcast packets either, nor do they forward limited broadcasts (see [RFC1812], Section 4.2.2.11).
マルチキャストルーティングが遍在していないので、複数のリンクにかかるサブネットの概念は、マルチキャストがサブネットの向こう側に働いていないケースをもたらす傾向があります。 [RFC1812]を見てください、セクション4.2。[RFC2644]あたりデフォルトの振舞いがルータが指示された放送パケットを進めないで、また限られた放送を進めないということである、(.2 .11)。
There are many protocols and applications today that use link-scoped multicast. The list of such applications and protocols that have been assigned their own link-scoped multicast group address (and may also have assumptions about the TTL/Hop Limit as noted above) can be found at:
使用がマルチキャストをリンクで見た今日、多くのプロトコルと利用があります。 以下でそれら自身のリンクで見られたマルチキャストグループアドレス(そして、また、上で述べたようにTTL/ホップLimitに関する仮定を持っているかもしれない)を割り当ててあるそのようなアプリケーションとプロトコルのリストを見つけることができます。
http://www.iana.org/assignments/multicast-addresses
http://www.iana.org/assignments/multicast-addresses
http://www.iana.org/assignments/ipv6-multicast-addresses
http://www.iana.org/assignments/ipv6-multicast-addresses
In addition, an arbitrarily large number of other applications may be using the all-1's broadcast address, or the all-hosts link-scoped multicast address, rather than their own group address.
さらに、他の任意に多くのアプリケーションがall-1の放送演説、またはそれら自身のグループアドレスよりむしろオールホストのリンクで見られたマルチキャストアドレスを使用しているかもしれません。
The well-known examples of protocols using link-scoped multicast or broadcast generally fall into one of the following groups:
一般に、リンクで見られたマルチキャストを使用するか、または放送されたプロトコルのよく知られる例は以下のグループの1つになります:
o Routing protocols: Distance Vector Multicast Routing Protocol
(DVMRP) [RFC1075], OSPF [RFC2328], RIP [RFC2453][RFC2080],
Enhanced Interior Gateway Routing Protocol (EIGRP) [EIGRP],
etc. These protocols exchange routes to subnet prefixes.
o ルーティング・プロトコル: ディスタンス・ベクタ・マルチキャスト・ルーティング・プロトコル(DVMRP)[RFC1075](OSPF[RFC2328])は[RFC2453][RFC2080]、高められた内部のゲートウェイルーティング・プロトコル(EIGRP)[EIGRP]などを裂きます。 これらのプロトコルはサブネット接頭語とルートを交換します。
o Address management protocols: Neighbor Discovery, DHCPv4
[RFC2131], Dynamic Host Configuration Protocol for IPv6
(DHCPv6) [RFC3315], Teredo [RFC4380], etc. By their nature,
this group tends to embed assumptions about the relationship
between a link and a subnet prefix. For example, ND uses
link-scoped multicast to resolve the link-layer address of an
IP address in the same subnet prefix, and to do duplicate
address detection (see Section 2.4 below) within the subnet.
DHCP uses link-scoped multicast or broadcast to obtain an
address in the subnet. Teredo states that the Teredo IPv4
Discovery Address is "an IPv4 multicast address used to
o 管理がプロトコルであると扱ってください: 隣人発見、DHCPv4[RFC2131]、IPv6(DHCPv6)のためのダイナミックなホスト構成プロトコル[RFC3315]、船食虫[RFC4380]など 本質的に、このグループは、リンクとサブネット接頭語との関係に関する仮定を埋め込む傾向があります。 例えば、ノースダコタは、同じサブネット接頭語のIPアドレスのリンクレイヤアドレスを決議して、サブネットの中にアドレス検出(以下のセクション2.4を見る)をコピーするのにリンクで見られたマルチキャストを使用します。 DHCPは、サブネットにおけるアドレスを得るのにリンクで見られたマルチキャストか放送を使用します。 Teredo IPv4ディスカバリーAddressが「IPv4マルチキャストアドレスは以前はよくそうしていました」であった船食虫州
Thaler Informational [Page 6] RFC 4903 Multi-Link Subnet Issues June 2007
情報[6ページ]のRFC4903マルチリンクサブネットが2007年6月に支給するターレル
discover other Teredo clients on the same IPv4 subnet. The
value of this address is 224.0.0.253", which is a link-scoped
multicast address. It also says that "the client MUST silently
discard all local discovery bubbles [...] whose IPv4 source
address does not belong to the local IPv4 subnet".
同じIPv4サブネットで他のTeredoクライアントを発見してください。 このアドレスの値がそうである、224.0、.0、0.253インチ、リンクで見られたマルチキャストアドレスである。 また、「クライアントは静かに、IPv4ソースアドレスが地方のIPv4サブネットに属さないすべての地方の発見気泡[…]を捨てなければなりません。」と、それは示します。
o Service discovery protocols: Simple Service Discovery Protocol
(SSDP) [SSDP], Bonjour, WS-Discovery [WSDISC], etc. These
often do not define any explicit assumption about the
relationship to subnet prefix.
o 発見プロトコルを修理してください: ボンジュール、簡単なサービス発見プロトコル(SSDP)[SSDP]、WS-発見[WSDISC]など これらはしばしばサブネット接頭語との関係に関する少しの明白な仮定も定義するというわけではありません。
o Name resolution protocols: NetBios [RFC1001], Bonjour, LLMNR,
etc. Most often these do not define any explicit assumption
about the relationship to subnet prefix, but Bonjour only
responds to queries from addresses within the same subnet
prefix.
o 名前解決プロトコル: ボンジュール、NetBios[RFC1001]、LLMNRなど たいていこれらはサブネット接頭語との関係に関する少しの明白な仮定も定義しませんが、Bonjourは同じサブネット接頭語の中でアドレスから質問に応じるだけです。
Note that protocols such as Bonjour and Teredo that drop packets that don't come from an address within the subnet are not necessarily broken by multi-link subnets, as this behavior is meant to constrain the behavior to within a subnet, when a link is larger than a single subnet.
サブネットの中でアドレスから来ないパケットを下げるBonjourやTeredoなどのプロトコルが必ずマルチリンクサブネットによって破られるというわけではないことに注意してください、この振舞いがサブネットへの振舞いを抑制することになっているとき、リンクがただ一つのサブネットより大きいときに。
However, regardless of whether any assumption about the relationship to subnet prefixes exists, all protocols mentioned above or on the IANA assignments lists will not work across a multi-link subnet without protocol-specific proxying functionality in routers, and adding proxying for an arbitrary number of protocols and applications does not scale. Furthermore, it may hinder the development and use of future protocols using link-scoped multicast.
しかしながら、サブネット接頭語との関係に関するどんな仮定も存在しているかどうかにかかわらず、前記のようにかIANA課題リストの上のすべてのプロトコルがマルチリンクサブネットの向こう側にルータにおけるプロトコル特有のproxyingの機能性なしで働くというわけではないでしょう、そして、プロトコルとアプリケーションの特殊活字の数字のためにproxyingしながら加えるのは比例しません。 その上、それは、リンクで見られたマルチキャストを使用することで将来のプロトコルの開発と使用を妨げるかもしれません。
2.4. Duplicate Address Detection Issues
2.4. アドレス検出問題をコピーしてください。
Duplicate Address Detection (DAD) uses link-scoped multicast in IPv6 and link-scoped broadcast in IPv4 and so has the issues mentioned in Section 2.3 above.
写しAddress Detection(DAD)には、IPv4でIPv6のリンクで見られたマルチキャストとリンクで見られた放送を使用するので、上のセクション2.3で参照された問題があります。
In addition, [RFC2462] contains the statement:
さらに、[RFC2462]は声明を含んでいます:
"Thus, for a set of addresses formed from the same interface
identifier, it is sufficient to check that the link-local address
generated from the identifier is unique on the link. In such
cases, the link-local address MUST be tested for uniqueness, and
if no duplicate address is detected, an implementation MAY choose
to skip Duplicate Address Detection for additional addresses
derived from the same interface identifier."
「その結果、同じインタフェース識別子から形成された1セットのアドレスでは、識別子から生成されたリンクローカルアドレスがリンクでユニークであることをチェックするのが十分です。」 「そのような場合、ユニークさがないかどうかリンクローカルアドレスをテストしなければなりません、そして、写しアドレスが全く検出されないなら、実装は同じインタフェース識別子から得られた追加アドレスのためにDuplicate Address Detectionをスキップするのを選ぶかもしれません。」
Thaler Informational [Page 7] RFC 4903 Multi-Link Subnet Issues June 2007
情報[7ページ]のRFC4903マルチリンクサブネットが2007年6月に支給するターレル
The last possibility, sometimes referred to as Duplicate Interface Identifier Detection (DIID), has been a matter of much debate, and the current work in progress [2462BIS] states:
時々Duplicate Interface Identifier Detection(DIID)と呼ばれた最後の可能性は、多くの討論の問題と、現在の処理中の作業[2462BIS]州です:
Each individual unicast address SHOULD be tested for uniqueness.
Note that there are implementations deployed that only perform
Duplicate Address Detection for the link-local address and skip
the test for the global address using the same interface
identifier as that of the link-local address. Whereas this
document does not invalidate such implementations, this kind of
"optimization" is NOT RECOMMENDED, and new implementations MUST
NOT do that optimization.
それぞれの個々のユニキャストはSHOULDを扱います。ユニークさがないかどうかテストされます。 リンクローカルアドレスのためにDuplicate Address Detectionを実行するだけであり、グローバルアドレスのためにリンクローカルアドレスのものと同じインタフェース識別子を使用することでテストをサボる配布された実装があることに注意してください。 このドキュメントはそのような実装を無効にしませんが、この種類の「最適化」はNOT RECOMMENDEDです、そして、新しい実装はその最適化をしてはいけません。
The existence of such implementations also causes problems with multi-link subnets. Specifically, a link-local address is only valid within a link, and hence is only tested for uniqueness within a single link. If the same interface identifier is then assumed to be unique across all links within a multi-link subnet, address conflicts can occur.
また、そのような実装の存在はマルチリンクサブネットで問題を起こします。 明確に、リンクローカルアドレスは、リンクの中に有効であるだけであり、したがって、ユニークさがないかどうか単一のリンクの中にテストされるだけです。 次に、同じインタフェース識別子がマルチリンクサブネットの中ですべてのリンクの向こう側に特有であると思われるなら、アドレス闘争は起こることができます。
3. Security Considerations
3. セキュリティ問題
The notion of multi-link subnets can cause problems with any security protocols that either rely on the assumption that a subnet only spans a single link or can leave gaps in the security solution where protocols are only defined for use on a single link.
マルチリンクサブネットの概念はサブネットが単一のリンクにかかるだけであるという仮定に依存するか、またはプロトコルが単一のリンクにおける使用のために定義されるだけであるところにセキュリティソリューションにおけるギャップを残すことができるどんなセキュリティプロトコルでも問題を起こすことができます。
Secure Neighbor Discovery (SEND) [RFC3971], in particular, is currently only defined within a single link. If a subnet were to span multiple links, SEND would not work as currently specified, since it secures Neighbor Discovery messages that include link-layer addresses, and if forwarded to other links, the link-layer address of the sender will be different. This same problem also exists in cases where a subnet does not span multiple links but where Neighbor Discovery is proxied within a link. Section 9 of [RFC4389] discusses some possible future directions in this regard.
安全なNeighborディスカバリー(SEND)[RFC3971]は現在、単一のリンクの中に特に定義されるだけです。 SENDはサブネットが複数のリンクにかかることであるなら、現在指定されているとして働いていません、Neighborディスカバリーがリンクレイヤアドレスを含めてください。そうすれば、他のリンクに送ると、リンクレイヤ送信者のアドレスが異なるというメッセージであると機密保護するので。 また、この同じ問題はサブネットが複数のリンクにかかりませんが、Neighborディスカバリーがリンクの中にproxiedされる場合で存在しています。 [RFC4389]のセクション9はこの点でいくつかの可能な将来の方向について論じます。
Furthermore, as noted above some applications and protocols (ND, Bonjour, Mobile IPv4, etc.) mitigate against off-link spoofing attempts by requiring a TTL or Hop Limit of 255 on receipt. If this restriction were removed, or if alternative protocols were used, then off-link spoofing attempts would become easier, and some alternative way to mitigate such attacks would be needed.
その上、上で述べたようにいくつかのアプリケーションとプロトコル(ノースダコタ、Bonjour、モバイルIPv4など)が、領収書の上でTTLかHop Limitに255を要求することによって試みを偽造しながら、オフリンクを困難にします。 この制限を取り除いたか、または代替のプロトコルを使用するなら、オフリンクスプーフィング試みは、より簡単になるでしょうに、そして、そのような攻撃を緩和する何らかの代替の方法が必要でしょう。
Thaler Informational [Page 8] RFC 4903 Multi-Link Subnet Issues June 2007
情報[8ページ]のRFC4903マルチリンクサブネットが2007年6月に支給するターレル
4. Recommendations
4. 推薦
4.1. IP Link Model
4.1. IPリンクモデル
There are two models that do not have the issues pointed out in the rest of the document.
ドキュメントの残りで問題を指させない2つのモデルがあります。
The IAB recommends that protocol designers use one of the following two models:
IABは、プロトコルデザイナーが以下の2つのモデルのひとりを使用することを勧めます:
o Multi-access link model: In this model, there can be multiple
nodes on the same link, including zero or more routers. Data
packets sent to the IPv4 link-local broadcast address
(255.255.255.255) or to a link-local multicast address can be
received by all other interested nodes on the link. Two nodes
on the link are able to communicate without any IPv4 TTL or
IPv6 Hop Limit decrement. There can be any number of layer 2
devices (bridges, switches, access points, etc.) in the middle
of the link.
o マルチアクセスリンクモデル: 同じくらいの複数のノードがリンクして、包含がゼロであるか以上がルータであるというそこでは、このモデルでは、ことであることができます。 データ・パケットがIPv4リンク地方の放送アドレスに発信した、(255.255、.255、.255、)、リンクローカルのマルチキャストアドレスに、リンクの上の他のすべての関心があるノードは受け取ることができます。 リンクの上の2つのノードが少しもIPv4 TTLやIPv6 Hop Limit減少なしで交信できます。 いろいろな層2のデバイス(ブリッジ、スイッチ、アクセスポイントなど)がリンクの中央にあることができます。
o Point-to-point link model: In this model, there are exactly two
nodes on the same link. Data packets sent to the IPv4 link-
local broadcast address or to a link-local multicast address
can be received by the other node on the link. The two nodes
are able to communicate without any IPv4 TTL or IPv6 Hop Limit
decrement. There can be any number of layer 2 devices
(bridges, switches, access points, etc.) in the middle of the
link.
o ポイントツーポイント接続モデル: このモデルには、同じリンクの上に2つのノードがまさにあります。 IPv4に送られたデータ・パケットは、ローカル放送アドレスをリンクするか、またはリンクの上のもう片方のノードでリンクローカルのマルチキャストアドレスに受け取ることができます。 2つのノードが少しもIPv4 TTLやIPv6 Hop Limit減少なしで交信できます。 いろいろな層2のデバイス(ブリッジ、スイッチ、アクセスポイントなど)がリンクの中央にあることができます。
A variant of the multi-access link model, which has fewer issues, but still some, is the following:
より少ない問題を持っているマルチアクセスリンクモデルの異形(それでも、いくつかだけ)は以下です:
o Non-broadcast multi-access (NBMA) model: Same as the multi-
access link model, except that no broadcast or multicast
packets can be sent, even between two nodes on the same link.
As a result, no protocols or applications that make use of
broadcast or multicast will work.
o 非放送マルチアクセス(NBMA)はモデル化します: マルチアクセスリンクモデルと同じです、どんな放送もマルチキャストパケットも送ることができないのを除いて、同じくらいの2つのノードの間でさえ、リンクしてください。 その結果、放送かマルチキャストを利用するどんなプロトコルもアプリケーションも動作しないでしょう。
Links that appear as NBMA links at layer 3 are problematic. Instead, if a link is an NBMA link at layer 2, then protocol designers should define some mechanism such that it appears as either the multi-access link model or point-to-point link model at layer 3.
NBMAが層3でリンクするとき現れるリンクは問題が多いです。 代わりに、プロトコルデザイナーがリンクが層2のNBMAリンクであるなら何らかのメカニズムを定義するべきであるので、それはマルチアクセスリンクモデルかポイントツーポイント接続モデルとして層3に現れます。
One use of an NBMA link is when the link itself is intended as a wide-area link (e.g., a tunnel such as 6to4 [RFC3056]) where none of the groups of functionality in Section 2.3 are required across the wide area. Admittedly, the definition of wide-area is somewhat subjective. Support for multicast on a wide-area link would be
NBMAリンクの1つの使用がリンク自体がセクション2.3の機能性のグループのいずれも広い領域の向こう側に必要でない広い領域のリンク(例えば、6to4[RFC3056]などのトンネル)として意図する時です。 明白に、広い領域の定義はいくらか主観的です。 広い領域のリンクの上のマルチキャストのサポートはそうでしょう。
Thaler Informational [Page 9] RFC 4903 Multi-Link Subnet Issues June 2007
情報[9ページ]のRFC4903マルチリンクサブネットが2007年6月に支給するターレル
analogous to supporting multicast routing across a series of local- area links. The issues discussed in Section 2.3 will arise, but may be acceptable over a wide area until multicast routing is also supported.
一連の地方の領域のリンクの向こう側にマルチキャストルーティングをサポートするのに類似しています。 セクション2.3で議論した問題は、起こりますが、また、マルチキャストルーティングがサポートされるまで、広い領域にわたって許容できるかもしれません。
Note that the distinction of whether or not a link is a tunnel is orthogonal to the choice of model; there exist tunnel links for all link models mentioned above.
リンクがトンネルであるかどうかに関する区別がモデルの選択と直交していることに注意してください。 前記のようにすべてのリンクモデルのためのトンネルのリンクは存在しています。
A multi-link subnet model should be avoided. IETF working groups using, or considering using, multi-link subnets today should investigate moving to one of the other models. For example, the Mobile IPv6 WG should investigate having the Home Agent not decrement the Hop Limit, and forward multicast traffic.
マルチリンクサブネットモデルは避けられるべきです。 IETFワーキンググループが、使用すると使用するか、または考える場合、今日のマルチリンクサブネットは、他のモデルのひとりに移行しながら、調査されるべきです。 例えば、モバイルIPv6 WGはホームのエージェントにHop Limitを減少させないで、前進のマルチキャストトラフィックを調査するはずです。
When considering changing an existing multi-link subnet solution to another model, the following issues should be considered:
既存のマルチリンクサブネットソリューションを別のモデルに変えると考えるとき、以下の問題は考えられるべきです:
Loop prevention: If physical loops cannot exist within the subnet,
then removing the TTL/Hop Limit decrement is not an issue.
Otherwise, protocol designers can (for example) retain the
decrement but use a separate prefix per link, or use some form of
bridging protocol instead (e.g., [BRIDGE] or [RBRIDGE]).
防止を輪にしてください: 物理的な輪がサブネットの中に存在できないなら、TTL/ホップLimit減少を取り除くのは、問題ではありません。 さもなければ、プロトコルデザイナーは、(例えば) 減少を保有しますが、1リンクあたり1つの別々の接頭語を使用するか、または代わりに(例えば、[BRIDGE]か[RBRIDGE])何らかのフォームのブリッジするプロトコルを使用できます。
Limiting broadcast (including all-hosts multicast): If there is no
efficiency requirement to prevent broadcast from going to other
on-link hosts, then flooding it within the subnet is not an issue.
Otherwise, protocol designers can (for example) use a separate
prefix per link, or flood broadcast other than ARP within the
subnet (ARP is covered below in Section 4.3).
制限は放送されました(オールホストマルチキャストを含んでいて): 防ぐ効率要件が全くなければ、リンクの上の他のホストに行って、次に、サブネットの中にそれをあふれさせるので放送されているのは、問題です。 さもなければ、プロトコルデザイナーが1リンクあたり1つの別々の接頭語を使用できますか(例えば)、またはサブネットの中のARPを除いて、洪水は放送されました(ARPはセクション4.3で以下にカバーされています)。
Limiting the scope of other multicast (including IPv6 Neighbor
Discovery): If there is no efficiency requirement to prevent
multicast from going to other on-link hosts, then flooding
multicast within the subnet is not an issue. Otherwise, protocol
designers can (for example) use a separate prefix per link, or use
Internet Group Management Protocol (IGMP)/MLD snooping [RFC4541]
instead.
他のマルチキャスト(IPv6 Neighborディスカバリーを含んでいる)の範囲を制限します: マルチキャストがリンクの上の他のホストのものになるのを防ぐという効率要件が全くなければ、サブネットの中の氾濫マルチキャストは問題ではありません。 さもなければ、プロトコルデザイナーは、(例えば) 1リンクあたり1つの別々の接頭語を使用するか、または代わりに、インターネットGroup Managementプロトコル(IGMP)/MLD詮索[RFC4541]を使用できます。
4.2. IPv6 Address Assignment
4.2. IPv6アドレス課題
In IPv6, the Prefix Information Option in a Router Advertisement (RA) is defined for use by a router to advertise an on-link prefix. That is, it indicates that a prefix is assigned to the link over which the RA is sent/received. That is, the router and the node both have an on-link route in their routing table (or on-link Prefix List, in the conceptual model of a host in [RFC2461]), and any addresses used in
IPv6では、ルータによる使用がリンクの上の接頭語の広告を出すように、Router Advertisement(RA)のPrefix情報Optionは定義されます。 すなわち、それは、接頭語がRAが送るか、または受け取られているリンクに割り当てられるのを示します。 すなわち、ルータとノードの両方がそれらの経路指定テーブル(または、[RFC2461]のホストの概念モデルのリンクの上のPrefix List)、および中で使用されたどんなアドレスにもリンクの上のルートを持っています。
Thaler Informational [Page 10] RFC 4903 Multi-Link Subnet Issues June 2007
情報[10ページ]のRFC4903マルチリンクサブネットが2007年6月に支給するターレル
the prefix are assigned to an interface (on any node) attached to that.
接頭語はそれに付けられたインタフェース(どんなノードのも)に割り当てられます。
In contrast, DHCPv6 Prefix Delegation (DHCP-PD) [RFC3633] is defined for use by a client to request a prefix for use on a different link. Section 12.1 of RFC 3633 states:
対照的に、クライアントによる使用が異なったリンクにおける使用のために接頭語を要求するように、DHCPv6 Prefix Delegation(DHCP-PD)[RFC3633]は定義されます。 RFC3633州のセクション12.1:
Upon the receipt of a valid Reply message, for each IA_PD the
requesting router assigns a subnet from each of the delegated
prefixes to each of the links to which the associated interfaces
are attached, with the following exception: the requesting router
MUST NOT assign any delegated prefixes or subnets from the
delegated prefix(es) to the link through which it received the
DHCP message from the delegating router.
有効なReplyメッセージの領収書に、各アイオワ_PDに関して、要求ルータはそれぞれの代表として派遣された接頭語から関連インタフェースが以下の例外で付けられているそれぞれのリンクまでサブネットを割り当てます: 要求ルータは代表として派遣された接頭語(es)からそれが代表として派遣するルータからDHCPメッセージを受け取ったリンクまで少しの代表として派遣された接頭語やサブネットも割り当ててはいけません。
Hence, the upstream router has a route in its routing table that is not on-link, but points to the client; the prefix is assigned to a link other than the one over which DHCP-PD was done; and any addresses used in the prefix are assigned to an interface (on any node) attached to that other link.
したがって、上流のルータはリンクの上に経路指定テーブルにルートを持っているのではなく、クライアントを示します。 接頭語はDHCP-PDが行われたもの以外のリンクに割り当てられます。 そして、接頭語に使用されるどんなアドレスもその他のリンクに付けられたインタフェース(どんなノードのも)に割り当てられます。
The IAB believes that the distinction between these two cases (assigning a prefix to the same link vs. another link) is important, and that the IETF protocols noted above are appropriate for the two scenarios noted. The IAB recommends that other protocol designers remain consistent with the IETF-defined scopes of these protocols (e.g., not using DHCP-PD to assign a prefix to the same link, or using RAs to assign a prefix to another link).
IABはこれらの2つのケース(同じリンク対別のリンクに接頭語を割り当てる)の区別が重要であり、注意された2つのシナリオに、上に述べられたIETFプロトコルが適切であると信じています。 IABは、他のプロトコルデザイナーがこれらのプロトコル(例えば、同じリンクに接頭語を割り当てるのにDHCP-PDを使用しないか、または別のリンクに接頭語を割り当てるのにRAsを使用しない)のIETFによって定義された範囲と一致していたままで残ることを勧めます。
In addition, the Prefix Information Option contains an L (on-link) flag. Normally, this flag is set, indicating that this prefix can be used for on-link determination. When not set, the advertisement makes no statement about on-link or off-link properties of the prefix. For instance, the prefix might be used for address configuration with some of the addresses belonging to the prefix being on-link and others being off-link. Care must be taken when the L flag is not set. Specifically, some platforms allow applications to retrieve the prefix length associated with each address of the node. If an implementation were to return the prefix length used for address configuration, then applications may incorrectly assume that TTL=1 is sufficient for communication, and that link-scoped multicast will reach other addresses in the prefix. As a result, the IAB recommends that designers and maintainers of APIs that provide a prefix length to applications address this issue. For example, they might indicate that no prefix length exists when the prefix is not on-link. If the API is not capable of reporting that one does not exist, then they might choose to report a value of 128 when the prefix is not on-link. This would result in such applications
さらに、Prefix情報OptionはL(リンク)の旗を含んでいます。 リンクにおける決断にこの接頭語を使用できるのを示して、通常、この旗は設定されます。 設定されない場合、広告は接頭語のオンリンクかオフリンクの特性に関する声明を全く出しません。 例えば、接頭語に属すアドレスのいくつかがリンクであり、他のものがリンクであるのから接頭語はアドレス構成に使用されるかもしれません。 L旗が設定されないとき、注意しなければなりません。 明確に、いくつかのプラットホームで、アプリケーションはノードの各アドレスに関連している接頭語の長さを検索できます。 アプリケーションは、実装がアドレス構成に使用される接頭語の長さを返すことであったならTTL=1がコミュニケーションに十分であると不当に仮定するかもしれません、そして、そのリンクで見られたマルチキャストは接頭語の他のアドレスに達するでしょう。 その結果、IABは、接頭語の長さをアプリケーションに提供するAPIのデザイナーと維持装置がこの問題を扱うことを勧めます。 例えば、彼らは、接頭語がリンクでないときに、接頭語の長さが全く存在しないのを示すかもしれません。 APIが、1つが存在しないと報告できないなら、彼らは、接頭語がリンクでない128の値を報告するのを選ぶかもしれません。 これはそのようなアプリケーションをもたらすでしょう。
Thaler Informational [Page 11] RFC 4903 Multi-Link Subnet Issues June 2007
情報[11ページ]のRFC4903マルチリンクサブネットが2007年6月に支給するターレル
believing they are on separate subnets, rather than on a multi-link subnet.
彼らがマルチリンクサブネットに関してというよりむしろ別々のサブネットにいると信じています。
4.3. Duplicate Address Detection Optimizations
4.3. アドレス検出最適化をコピーしてください。
One of the reasons sometimes cited for wanting a multi-link subnet model (rather than a multi-access link model), is to minimize the ARP/ND traffic between end-nodes. This is primarily a concern in IPv4 where ARP results in a broadcast that would be seen by all nodes, not just the node with the IPv4 address being resolved. Even if this is a significant concern, the use of a multi-link subnet model is not necessary. The point-to-point link model is one way to avoid this issue entirely.
マルチリンクサブネットが欲しいように時々引用された理由の1つは、モデル化して(マルチアクセスリンクモデルよりむしろ)、エンドノードの間のARP/ノースダコタトラフィックを最小にすることです。 これはIPv4アドレスが決議されているノードだけではなく、主としてARPがすべてのノードによって見られる放送をもたらすIPv4の関心です。 これが重要な関心であっても、マルチリンクサブネットモデルの使用は必要ではありません。 ポイントツーポイント接続モデルはこの問題を完全に避けることにおいて一方通行です。
In the multi-access link model, IPv6 ND traffic can be reduced by using well-known multicast learning techniques (e.g., [RFC4541] at a layer 2 intermediate device (bridge, switch, access point, etc.).
マルチアクセスリンクモデルでは、IPv6ノースダコタトラフィックは、よく知られるマルチキャスト学習手法を使用することによって、減少できます。(例えば[RFC4541]、層2の中間的デバイス(ブリッジ、スイッチ、アクセスポイントなど)で。
Some have suggested that a layer 2 device could maintain an ARP or ND cache and service requests from that cache. However, such a cache prevents any type of fast mobility between layer 2 ports, and breaks Secure Neighbor Discovery [RFC3971]. As a result, the IAB recommends to protocol designers that this approach be avoided, instead using an alternative such as layer 2 learning. For IPv4 (where no Secure ARP exists), the IAB recommends that protocol designers avoid having a device respond from its cache in cases where a node can legitimately move between layer 2 segments of the link without any layer 2 indications at the layer 2 intermediate device. Also, since currently there is no guarantee that any device other than the end- host knows all addresses of the end-host, protocol designers should avoid any dependency on such an assumption. For example, when no cache entry for a given request is found, protocol designers may specify that a node broadcast the request to all nodes.
或るものは、層の2デバイスがARPかノースダコタキャッシュを維持して、そのキャッシュからの要求を修理できたのを示しました。 しかしながら、そのようなキャッシュは、層の2ポートの間のどんなタイプの速い移動性も防いで、Secure Neighborディスカバリー[RFC3971]を壊します。 その結果、IABは、このアプローチが避けられることをプロトコルデザイナーに勧めます、代わりに層2の学習などの代替手段を使用して。 IPv4(どんなSecure ARPも存在しないところ)に関しては、IABはデザイナーが、デバイスをノードが層で少しも層のないリンクの層の2セグメントの間で合法的に2つの指摘を動かすことができる場合におけるキャッシュから反応させるのを避けるそのプロトコルに2の中間的デバイスを推薦します。 また、現在、終わりのホスト以外のどんなデバイスも終わりホストのすべてのアドレスを知っているという保証が全くないので、プロトコルデザイナーはそのような前提でのどんな依存も避けるべきです。 与えられた要求のためのキャッシュエントリーが全く見つけられないとき、例えば、プロトコルデザイナーは、ノードがすべてのノードに要求を放送したと指定するかもしれません。
5. Normative References
5. 引用規格
[RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791, September
1981.
[RFC791] ポステル、J.、「インターネットプロトコル」、STD5、RFC791、1981年9月。
[RFC950] Mogul, J. and J. Postel, "Internet Standard Subnetting
Procedure", STD 5, RFC 950, August 1985.
[RFC950] ムガール人とJ.とJ.ポステル、「インターネットの標準のサブネッティング手順」、STD5、RFC950、1985年8月。
[RFC1812] Baker, F., Ed., "Requirements for IP Version 4 Routers",
RFC 1812, June 1995.
[RFC1812] ベイカー、F.、エド、「IPバージョン4ルータのための要件」、RFC1812、6月1995日
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
Thaler Informational [Page 12] RFC 4903 Multi-Link Subnet Issues June 2007
情報[12ページ]のRFC4903マルチリンクサブネットが2007年6月に支給するターレル
[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)のための隣人発見」、RFC2461、1998年12月。
[RFC2462] Thomson, S. and T. Narten, "IPv6 Stateless Address
Autoconfiguration", RFC 2462, December 1998.
[RFC2462] トムソンとS.とT.Narten、「IPv6の状態がないアドレス自動構成」、RFC2462、1998年12月。
[RFC2644] Senie, D., "Changing the Default for Directed Broadcasts in
Routers", BCP 34, RFC 2644, August 1999.
[RFC2644] Senie、D.、「ルータにおける指示された放送のためのデフォルトを変えます」、BCP34、RFC2644、1999年8月。
[RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic
Host Configuration Protocol (DHCP) version 6", RFC 3633,
December 2003.
[RFC3633] TroanとO.とR.Droms、「Dynamic Host Configuration Protocol(DHCP)バージョン6インチIPv6 Prefix Options、RFC3633、2003年12月。」
[RFC3927] Cheshire, S., Aboba, B., and E. Guttman, "Dynamic
Configuration of IPv4 Link-Local Addresses", RFC 3927, May
2005.
[RFC3927]チェーシャー州(S.、Aboba、B.、およびE.Guttman、「IPv4のリンクローカルのアドレスの動的設定」、RFC3927)は、2005がそうするかもしれません。
[RFC3971] Arkko, J., Ed., Kempf, J., Zill, B., and P. Nikander,
"SEcure Neighbor Discovery (SEND)", RFC 3971, March 2005.
[RFC3971] Arkko、J.、エド、ケンフ、J.、Zill、B.、およびP.Nikander、「安全な隣人発見(発信する)」、RFC3971、3月2005日
[RFC4007] Deering, S., Haberman, B., Jinmei, T., Nordmark, E., and B.
Zill, "IPv6 Scoped Address Architecture", RFC 4007, March
2005.
[RFC4007] デアリングとS.とハーバーマンとB.とJinmeiとT.とNordmark、E.とB.Zill、「IPv6はアドレス体系を見た」RFC4007、2005年3月。
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 4291, February 2006.
[RFC4291] HindenとR.とS.デアリング、「IPバージョン6アドレッシング体系」、RFC4291、2006年2月。
[RFC4541] Christensen, M., Kimball, K., and F. Solensky,
"Considerations for Internet Group Management Protocol
(IGMP) and Multicast Listener Discovery (MLD) Snooping
Switches", RFC 4541, May 2006.
[RFC4541] クリステンセン、M.、キンボール、K.、およびF.Solensky、「スイッチについて詮索して、インターネット集団経営のための問題は(IGMP)とマルチキャストリスナー発見(MLD)について議定書の中で述べます」、RFC4541、2006年5月。
6. Informative References
6. 有益な参照
[2462BIS] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
Address Autoconfiguration", Work in Progress, May 2005.
[2462BIS]トムソンとS.とNarten、T.とT.Jinmei、「IPv6の状態がないアドレス自動構成」は進歩、2005年5月に働いています。
[BRIDGE] T. Jeffree, editor, "Media Access Control (MAC) Bridges",
ANSI/IEEE Std 802.1D, 2004, http://standards.ieee.org/
getieee802/download/802.1D-2004.pdf.
[BRIDGE] T.Jeffree、エディタ、「メディアアクセス制御(MAC)ブリッジ」、ANSI/IEEE Std 802.1D、2004、 http://standards.ieee.org/ getieee802/ダウンロード/802.1D-2004.pdf。
[DEERING] Deering, S., "IP Multicast Extensions for 4.3BSD UNIX and
related systems (MULTICAST 1.2 Release)", June 1989.
http://www.kohala.com/start/mcast.api.txt
[デアリング]デアリング、S.、「4.3BSD UNIXと関連系(MULTICAST1.2Release)のためのIP Multicast Extensions」6月1989日の http://www.kohala.com/start/mcast.api.txt
Thaler Informational [Page 13] RFC 4903 Multi-Link Subnet Issues June 2007
情報[13ページ]のRFC4903マルチリンクサブネットが2007年6月に支給するターレル
[EIGRP] Cisco, "Enhanced Interior Gateway Routing Protocol", Cisco
Document ID 16406, September 2005.
http://www.cisco.com/warp/public/103/eigrp-toc.html
[EIGRP]シスコ、「高められた内部のゲートウェイルーティング・プロトコル」、コクチマスDocument ID 16406、2005年9月の http://www.cisco.com/warp/public/103/eigrp-toc.html
[LINUX] Juan-Mariano de Goyeneche, "Multicast over TCP/IP HOWTO",
March 1998. http://www.linux.com/howtos/Multicast-HOWTO-
2.shtml
[リヌクス]ホアン-マリアーノde Goyeneche、「TCP/IP HOWTOの上のマルチキャスト」、3月1998日の http://www.linux.com/howtos/Multicast-HOWTO- 2.shtml
[LLMNR] Aboba, B., Thaler, D., and L. Esibov, "Link-local Multicast
Name Resolution (LLMNR)", RFC 4795, January 2007.
[LLMNR]Aboba、B.、ターレル、D.、およびL.Esibov、「リンク地方のマルチキャスト名前解決(LLMNR)」、RFC4795、2007年1月。
[MDNS] Cheshire, S. and M. Krochmal, "Multicast DNS", June 2005.
http://files.multicastdns.org/draft-cheshire-dnsext-
multicastdns.txt
[MDNS]チェーシャー州とS.とM.クロフマル、「マルチキャストDNS」6月2005日の http://files.multicastdns.org/draft-cheshire-dnsext- multicastdns.txt
[MLSR] Thaler, D. and C. Huitema, "Multi-link Subnet Support in
IPv6", Proceedings of IETF 54, June 2002.
http://www.ietf.org/proceedings/02jul/I-D/draft-ietf-ipv6-
multilink-subnets-00.txt
[MLSR] ターレルとD.とC.Huitema、「IPv6"でのマルチリンクサブネットサポート、IETF54、6月2002日の http://www.ietf.org/proceedings/02jul/I-D/draft-ietf-ipv6- マルチリンクサブネット00.txtの議事」
[RBRIDGE] Perlman, R., Gai, S., and D. Dutt, "Rbridges: Base Protocol
Specification", Work in Progress, March 2007.
[RBRIDGE] パールマン、R.、ガイ、S.、およびD.ダッタ、「Rbridges:」 「基地のプロトコル仕様」、処理中の作業、2007年3月。
[RFC925] Postel, J., "Multi-LAN address resolution", RFC 925,
October 1984.
[RFC925] ポステル、J.、「マルチLANアドレス解決」、RFC925、1984年10月。
[RFC1001] NetBIOS Working Group in the Defense Advanced Research
Projects Agency, Internet Activities Board, and End-to-End
Services Task Force, "Protocol Standard for a NetBIOS
Service on a TCP/UDP Transport: Concepts and Methods", STD
19, RFC 1001, March 1987.
国防高等研究計画庁、インターネット活動ボード、および終わりから終わりへのサービス特別委員会における[RFC1001]NetBIOS作業部会、「NetBIOSのプロトコル標準はTCP/UDP輸送のときに以下を修理します」。 「概念とメソッド」(STD19、RFC1001)は1987を行進させます。
[RFC1027] Carl-Mitchell, S. and J. Quarterman, "Using ARP to
Implement Transparent Subnet Gateways", RFC 1027, October
1987.
[RFC1027]カール-ミッチェルとS.とJ.Quarterman、「透明なサブネットがゲートウェイであると実装するのにARPを使用します」、RFC1027、1987年10月。
[RFC1075] Waitzman, D., Partridge, C., and S. Deering, "Distance
Vector Multicast Routing Protocol", RFC 1075, November
1988.
[RFC1075] WaitzmanとD.とヤマウズラ、C.とS.デアリング、「ディスタンス・ベクタ・マルチキャスト・ルーティング・プロトコル」、RFC1075、1988年11月。
[RFC1884] Hinden, R., Ed., and S. Deering, Ed., "IP Version 6
Addressing Architecture", RFC 1884, December 1995.
[RFC1884]Hinden、R.、エド、エドS.デアリング、RFC1884、「IPバージョン6はアーキテクチャを扱う」12月1995日
[RFC2080] Malkin, G. and R. Minnear, "RIPng for IPv6", RFC 2080,
January 1997.
[RFC2080] マルキンとG.とR.Minnear、「IPv6"、RFC2080、1997年1月のためのRIPng。」
[RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131,
March 1997.
[RFC2131] Droms、R.、「ダイナミックなホスト構成プロトコル」、RFC2131、1997年3月。
Thaler Informational [Page 14] RFC 4903 Multi-Link Subnet Issues June 2007
情報[14ページ]のRFC4903マルチリンクサブネットが2007年6月に支給するターレル
[RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.
[RFC2328]Moy、J.、「OSPF、バージョン2インチ、STD54、RFC2328、1998インチ年4月。
[RFC2373] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 2373, July 1998.
[RFC2373] HindenとR.とS.デアリング、「IPバージョン6アドレッシング体系」、RFC2373、1998年7月。
[RFC2453] Malkin, G., "RIP Version 2", STD 56, RFC 2453, November
1998.
[RFC2453] マルキン、G.は「1998年11月にバージョン2インチ、STD56、RFC2453を裂きます」。
[RFC3024] Montenegro, G., Ed., "Reverse Tunneling for Mobile IP,
revised", RFC 3024, January 2001.
[RFC3024] モンテネグロ、G.、エドRFC3024、「モバイルIPのためにTunnelingを逆にして、改訂され」て、2001年1月。
[RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains via
IPv4 Clouds", RFC 3056, February 2001.
[RFC3056] 大工とB.とK.ムーア、「IPv4 Cloudsを通したIPv6 Domainsの接続」、RFC3056、2001年2月。
[RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins,
C., and M. Carney, "Dynamic Host Configuration Protocol for
IPv6 (DHCPv6)", RFC 3315, July 2003.
[RFC3315]Droms(R.(エド))はバウンドしています、J.、フォルツ、B.、レモン、パーキンス、C.とM.カーニー、「IPv6(DHCPv6)のためのダイナミックなホスト構成プロトコル」RFC3315、T.、2003年7月。
[RFC3513] Hinden, R. and S. Deering, "Internet Protocol Version 6
(IPv6) Addressing Architecture", RFC 3513, April 2003.
[RFC3513]HindenとR.とS.デアリング、「インターネットプロトコルバージョン6(IPv6)アドレッシング体系」、RFC3513、2003年4月。
[RFC3753] Manner, J., Ed., and M. Kojo, Ed., "Mobility Related
Terminology", RFC 3753, June 2004.
[RFC3753]方法、J.、エド、M.Kojo、エド、「移動性関連用語」、RFC3753、6月2004日
[RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support
in IPv6", RFC 3775, June 2004.
[RFC3775] ジョンソンとD.とパーキンス、C.とJ.Arkko、「IPv6"、RFC3775、2004年6月の移動性サポート。」
[RFC3810] Vida, R., Ed., and L. Costa, Ed., "Multicast Listener
Discovery Version 2 (MLDv2) for IPv6", RFC 3810, June 2004.
[RFC3810]ビーダ、R.、エド、L.コスタ、エド、「IPv6"、RFC3810、2004年6月のためのマルチキャストリスナー発見バージョン2(MLDv2)。」
[RFC4380] Huitema, C., "Teredo: Tunneling IPv6 over UDP through
Network Address Translations (NATs)", RFC 4380, February
2006.
[RFC4380]Huitema、C.、「船食虫:」 「ネットワークアドレス変換(NATs)でUDPの上でIPv6にトンネルを堀る」RFC4380、2006年2月。
[RFC4389] Thaler, D., Talwar, M., and C. Patel, "Neighbor Discovery
Proxies (ND Proxy)", RFC 4389, April 2006.
[RFC4389] ターレル、D.、Talwar、M.、およびC.パテル、「隣人発見プロキシ(第プロキシ)」、RFC4389、2006年4月。
[SCOPID] Deering, S., Haberman, B., Jinmei, T., Nordmark, E., Onoe,
A., and B. Zill, "IPv6 Scoped Address Architecture",
Proceedings of IETF 54, July 2002.
http://www.ietf.org/proceedings/02jul/I-D/draft-ietf-
ipngwg-scoping-arch-04.txt
[SCOPID] IETF54、arch-04.txtを見る7月2002日の http://www.ietf.org/proceedings/02jul/I-D/draft-ietf- ipngwgのデアリングとS.とハーバーマンとB.とJinmeiとT.とNordmarkとE.と尾上、A.とB.Zill、「IPv6はアドレス体系を見た」Proceedings
[SSDP] Goland, Yaron Y., Cai, T., Leach, P., Gu, Y., and S.
Albright, "Simple Service Discovery Protocol (SSDP)", 1999.
http://www.upnp.org/resources/specifications.asp
[SSDP]Goland、ヤロンY.、Cai、T.、リーチ、P.、Gu、Y.、およびS.オルブライト、「簡単なサービス発見プロトコル(SSDP)」、1999 http://www.upnp.org/resources/specifications.asp
Thaler Informational [Page 15] RFC 4903 Multi-Link Subnet Issues June 2007
情報[15ページ]のRFC4903マルチリンクサブネットが2007年6月に支給するターレル
[TCPILL] Stevens, W. Richard, "TCP/IP Illustrated, Volume 1",
Addison-Wesley, 1994.
[TCPILL]スティーブンス、W.リチャード、「TCP/IPはアディソン-ウエスリー、1994をボリューム1インチ例証しました」。
[TCPIP2K] MacDonald, D. and W. Barkley, "Microsoft Windows 2000
TCP/IP Implementation Details". http://www.microsoft.com/
technet/itsolutions/network/deploy/depovg/tcpip2k.mspx
[TCPIP2K] 「マイクロソフトWindows2000TCP/IP実装の詳細」 マクドナルドとD.とW.バークリー、 http://www.microsoft.com/ technet/itsolutions/ネットワーク/は、/がdepovg/tcpip2k. mspxであると配布します。
[UNP] Stevens, W. Richard, "Unix Network Programming, Volume 1,
Second Edition", Prentice Hall, 1998.
[UNP]スティーブンス、W.リチャード、「unixネットワーク・プログラミング、第1巻、第2版」、新米のホール、1998
[WSDISC] Microsoft, "Web Services Dynamic Discovery (WS-Discovery)",
2005. http://specs.xmlsoap.org/ws/2005/04/discovery/ws-
discovery.pdf
[WSDISC]マイクロソフト、「Webサービスのダイナミックなディスカバリー(WS-ディスカバリー)」2005 http://specs.xmlsoap.org/ws/2005/04/discovery/ws- discovery.pdf
IAB Members at the time of this writing
この書くこと時点のIABメンバー
Bernard Aboba Loa Andersson Brian Carpenter Leslie Daigle Elwyn Davies Kevin Fall Olaf Kolkman Kurtis Lindqvist David Meyer David Oran Eric Rescorla Dave Thaler Lixia Zhang
バーナードAboba Loaアンデションブライアン大工レスリーDaigle ElwynデイヴィースケビンFallオラフ・Kolkmanカーティス・リンクヴィスト・デヴィッド・マイヤー・デヴィッド・オラン・エリック・レスコラ・デーヴ・ターレルLixiaチャン
Author's Address
作者のアドレス
Dave Thaler Microsoft One Microsoft Way Redmond, WA 98052
デーヴターレルマイクロソフト1マイクロソフト道、レッドモンド、ワシントン 98052
Phone: +1 425 703 8835 EMail: dthaler@microsoft.com
以下に電話をしてください。 +1 8835年の425 703メール: dthaler@microsoft.com
Thaler Informational [Page 16] RFC 4903 Multi-Link Subnet Issues June 2007
情報[16ページ]のRFC4903マルチリンクサブネットが2007年6月に支給するターレル
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The IETF Trust (2007).
IETFが信じる著作権(C)(2007)。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとここに含まれた情報はその人が代理をするか、または(もしあれば)後援される組織、インターネットの振興発展を目的とする組織、「そのままで」という基礎と貢献者の上で提供していて、IETFはそして、インターネット・エンジニアリング・タスク・フォースがすべての保証を放棄すると信じます、急行である、または暗示していて、他を含んでいて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるということであるかいずれが市場性か特定目的への適合性の黙示的な保証です。
Intellectual Property
知的所有権
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFはどんなIntellectual Property Rightsの正当性か範囲、実装に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するどんな独立している取り組みも作りました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFはこの規格を実装するのに必要であるかもしれない技術をカバーするかもしれないどんな著作権もその注目していただくどんな利害関係者、特許、特許出願、または他の所有権も招待します。 ietf-ipr@ietf.org のIETFに情報を扱ってください。
Acknowledgement
承認
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Thaler Informational [Page 17]
ターレル情報です。[17ページ]
一覧
スポンサーリンク
