Network Working Group D. Thaler
Request for Comments: 4903 Internet Architecture Board
Category: Informational June 2007
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).
著作権（C）IETFトラスト（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
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]は、そのネットワーク内のホストを識別するネットワーク番号、およびローカルアドレスフィールドを識別する、ネットワークのフィールドから成っていました。組織では、ネットワーク内の多くのリンクを希望するにつれ、彼らの選択は、（[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]転送プレーンは、宛てのパケットを転送しない、転送するときのループを防ぐために生存時間（TTL）をデクリメントの特性を有していたアドレスの特定のタイプの解決プロトコル（ARP）プロキシの動作を定義したオプション2の提案でした255.255.255.255、およびARPベースのブリッジは、最近のブロードキャストパケットのリストを維持することを要求することによって、ブロードキャストサブネットをサポートします。 [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.
代わりに、[RFC950]、ホストがサブネットマスクを学ぶために必要とされたことによって、これはIPv4のモデルになったとIETF標準化オプション3。
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]をまたがるという概念を保持する別のメカニズムによって置き換えられました。
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.
しかし、他のWGは、IPv6のWGに拒否されていたにも関わらず、この概念を可能にするために続けました。モバイル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.
概念はまた、全体MANETは、ルータがその中にレイヤ3転送を行うと、サブネットで提案したモバイルアドホックネットワーク（MANET）において生じます。
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.
このメモでは、我々は、他のプロトコルの設計者は（とすべき）問題を知ることができるように、マルチリンクサブネット概念の放棄を動機のIPv6 WGで提起された問題を文書化します。
The key words "MUST", "RECOMMENDED", and "SHOULD" in this document are to be interpreted as described in [RFC2119].
キーワード「MUST」、「推奨」、および本書では[RFC2119]で説明されるように解釈されるべきである「SHOULD」。
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ホップ限界を減少ルータによって区切らトポロジカル領域を指すために使用されます。リンクローカルアドレスプレフィックスは、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バージョン6アドレス指定アーキテクチャ[RFC1884]は述べ、公表されました：「IPv6はサブネットが一つのリンクに関連付けられている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.
したがって、それは明示的にサブネットが1つのリンクに関連付けられている現在のIPv4モデルがあったことを認め、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 associated with one link. Multiple subnet prefixes may be assigned to the same link."
IPv6のアドレス体系は、以来、最初の1998年7月には、[RFC2373]、2003年4月[RFC3513]、そして最終的に2006年2月[RFC4291]を3回更新されました。すべてのアップデートは、言語のものがあります。「現在、IPv6はサブネットプレフィックスを1つのリンクに関連付けられているIPv4のモデルを続けて複数のサブネットプレフィックスが同じリンクに割り当ててもよいです。。」
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.
同様に、モビリティ関連用語[RFC3753]はホームサブネットの同様の定義で「インターネットトポロジ内のノードの対外リンクを特定するIPアドレスの最初のビットのいくつかの数で構成されたビット列」として外国サブネットプレフィックスを定義します接頭辞。サブネットプレフィックスは、（単数）リンクを特定し、これらの状態の両方。
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.
リンクは、IPv4のTTLまたはIPv6ホップ限界を減少ルータによって囲まれているため、TTL /ホップリミットとサブネット・プレフィックスとの間の関係についての仮定を行うアプリケーションとプロトコルに問題があるかもしれません。
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.
発生する可能性のある二つの主要なケースがあります。いくつかのアプリケーションおよびプロトコルは、255のTTL /ホップリミットを持つパケットを送信した値が受信時に255であることを確認することができる。1.他のアプリケーションおよびプロトコルのTTL /ホップリミットを持つパケットを送信することができます。これら2つのアプローチの効果は全く異なるものの両方が、単一のリンク内への通信を制限する方法です。 1にTTL /ホップ制限を設定すると、送信されるパケットは、リンクを残していないことを保証しますが、それは、リンクに到達することができ、パケットを送信することから、オフリンクの攻撃を防ぐことはできません。 TTL /ホップ制限は受信時に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 /ホップ制限とサブネット間の関係についての仮定については、のは、多くのプロトコルやアプリケーション開発者に馴染みのいくつかの例の参照を見てみましょう。
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]、（もちろんこれはリンクの定義によって真である）が「0のTTLはノードローカルを意味し、1はリンクローカル手段」は、ページ490で述べています。次に、ページ498個の状態、に関するIP_MULTICAST_TTLとIPV6_MULTICAST_HOPS、「これが指定されていない場合は、ローカルサブネットにデータグラムを制限1の両方にデフォルト、。」ここでは、Unixのプログラマは（リンクではなく）TTL = 1つのパケットがサブネットに制限されていることを学びます。これは、先に説明したIPモデルのために、互換的用語を使用する多くの文書の典型です。
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イラスト」、第1巻には、[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ファイル[デアリング]はステートメントを含まWindowsのドキュメントを含め、「初期TTL 1でマルチキャストデータグラムが同じサブネットに制限されている」、および同様の文は現在、多くのベンダーのドキュメントに表示されます（例えば、[TCPIP2K]）とLinuxの（例えば、[LINUX]は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近隣探索（ND）[RFC2461]は、サブネット内の任意のIPアドレスのリンク層アドレスを解決するために、ホップリミット領収書で確認255とメッセージを使用しています。
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 AppleのBonjourのは、[MDNS] TTL 255とメッセージを使うの古いクライアントは、領収書で確認し、必ず同じサブネット内のアドレスからのクエリに応答します。 （この動作はサブネットは、リンクのサブセットのみであるサブネット内に通信を制限することであるとして、マルチリンクサブネットが、必ずしも、これを壊さないことに注意してください。しかし、それはマルチリンクサブネット間では動作しません。）
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:
TTL 1または255を使用することが知られているが、明示的に（よく知られているリンクローカルプレフィックス以外）のサブネットプレフィックスとの関係についての仮定を持っているように見えないプロトコルの他のいくつかの例今日は次のとおりです。
o Link-Local Multicast Name Resolution [LLMNR] uses a TTL/Hop Limit of 1 for TCP.
Oリンクローカルマルチキャスト名前解決は、[LLMNR] TCPのための1のTTL /ホップ制限を使用しています。
o Multicast Listener Discovery (MLD) [RFC3810] uses a Hop Limit of 1.
マルチキャストリスナ発見（MLD）O [RFC3810]は1のホップリミットを使用します。
o Reverse tunneling for Mobile IPv4 [RFC3024] uses TTL 255 checked on receipt for Registration Requests sent to foreign agents.
OモバイルIPv4 [RFC3024]のためのトンネリングをリバースTTL 255は、外国のエージェントに送信された登録要求のための領収書で確認し使用しています。
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.
そのようなプロトコルのいずれかの実装がそれが他の理由のサブネットプレフィックスとの関係について、このような仮定を追加存在するかどうかは不明です。
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).
マルチキャストルーティングが遍在していないので、複数のリンクにまたがるサブネットの概念は、マルチキャストがサブネット間で動作しない場合が発生する傾向があります。パー[RFC2644]は、デフォルトの動作では、ルーターが前方のいずれかブロードキャストパケットを監督し、また彼らが前方に限定されたブロードキャストが（[RFC1812]、セクション4.2.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 /ホップリミットに関する仮定を有していてもよい）は、アプリケーションとプロトコルのリストはで見つけることができます。
http://www.iana.org/assignments/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.
加えて、他のアプリケーションの任意の大きな数は、すべて1のブロードキャストアドレス、又は、むしろ自分のグループアドレスより全ホストリンクスコープのマルチキャストアドレスを使用してもよいです。
The well-known examples of protocols using link-scoped multicast or broadcast generally fall into one of the following groups:
リンクスコープのマルチキャストまたはブロードキャストを使用して、プロトコルのよく知られた例は、一般的に、以下の群のいずれかに分類されます。
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]を、RIP 。
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 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".
Oアドレス管理プロトコルは：近隣探索、のDHCPv4 [RFC2131]、IPv6の動的ホスト構成プロトコル（DHCPv6）[RFC3315]その性質など、Teredoの[RFC4380]は、このグループはリンクとの間の関係についての仮定を埋め込むために傾向がありますサブネットプレフィックス。例えば、NDは同じサブネットプレフィックス内のIPアドレスのリンク層アドレスを解決するために、サブネット内で重複アドレス検出（以下のセクション2.4を参照）を行うには、リンクスコープのマルチキャストを使用しています。 DHCPは、リンクスコープのマルチキャストまたはサブネット内のアドレスを取得するためにブロードキャストを使用します。 TeredoはTeredoのIPv4の検出アドレスがあることを述べ、「同じIPv4サブネット上の他のTeredoクライアントを発見するために使用されるIPv4マルチキャストアドレス。このアドレスの値は224.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.
この現象は、サブネット内に行動を制約することを意味するようにリンクがある場合、サブネット内のアドレスから来ていないパケットをドロップするようボンジュールと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上または上に言及したすべてのプロトコルは、リストはルータ内のプロトコル固有のプロキシ機能なしマルチリンクサブネットを横切って動作しません割り当て、及び任意の数のプロキシを追加しますプロトコルおよびアプリケーションの規模はありません。また、リンクスコープのマルチキャストを使用して、将来のプロトコルの開発と利用を妨げることがあります。
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.
アドレス検出（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."
「このように、同じインタフェース識別子から形成されたアドレスのセットに対して、識別子から生成されたリンクローカルアドレスがリンク上で一意であることを確認するのに十分である。このような場合には、リンクローカルアドレスが一意のために試験されなければなりません重複アドレスが検出されない場合、そして、実装は同じインタフェース識別子から派生し、追加のアドレスに対して重複アドレス検出をスキップすることを選択するかもしれません。」
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:
最後の可能性は、時には重複インタフェース識別子検出（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.
個々のユニキャストアドレスは、一意性のためにテストする必要があります。唯一のリンクローカルアドレスに対して重複アドレス検出を実行し、リンクローカルアドレスと同一のインタフェース識別子を使用してグローバルアドレスのテストをスキップすることを配備実装が存在することに留意されたいです。この文書は、そのような実装を無効にしないのに対し、「最適化」のこの種のはお勧めしません、そして新しい実装はその最適化を行うならありません。
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.
そのような実装の存在はまた、マルチリンクサブネットで問題が発生します。具体的には、リンクローカルアドレスは、リンク内でのみ有効であるため、単一のリンク内の一意性について試験されます。同じインタフェース識別子は、その後、マルチリンクサブネット内のすべてのリンクで一意であると仮定されている場合は、アドレスの競合が発生する可能性があります。
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.
セキュア近隣探索（SEND）[RFC3971]は、具体的には、現在、単一のリンク内で定義されています。サブネットは複数のリンクにまたがるした場合、SENDは、現在、それがリンク層アドレスを含む近隣探索メッセージを確保し、他のリンクに転送すれば、送信者のリンク層アドレスが異なるものになります。以降、指定された動作しませんこの同じ問題は、サブネットが複数のリンクをまたがっていませんが、近隣探索は、リンク内プロキシされた場合には存在しています。 [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.
さらに、いくつかのアプリケーションおよびプロトコル（等ND、ボンジュール、モバイルIPv4）TTLまたはレシート上の255のホップ限界を要求することによって、オフリンクスプーフィングの試みを軽減上述したように。この制限が削除された場合、または別のプロトコルが使用された場合は、オフリンクなりすましの試みが容易になるだろう、と、このような攻撃を軽減するためのいくつかの代替方法が必要とされるであろう。
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ホップ限界減少することなく通信することができます。リンクの中間のレイヤ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ホップ限界減少することなく通信することができます。リンクの中間のレイヤ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.
レイヤ3でのNBMAリンクとして表示されるリンクは問題があります。リンクは、レイヤ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 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に機能性の基のいずれも広い領域にわたって必要とされない広域リンク（例えば、6to4の[RFC3056]としてトンネル）として意図されている場合NBMAリンクのいずれかを使用することです。確かに、広域の定義はやや主観的です。広域リンク上のマルチキャストのサポートは、ローカルエリアリンクのシリーズ全体でマルチキャストルーティングをサポートすることに類似しただろう。セクション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は、ホームエージェントは、ホップ制限をデクリメント、およびマルチキャストトラフィックを転送しませ持つ調査する必要があります。
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 /ホップリミット減少を除去することは問題ではありません。そうでない場合は、プロトコル設計者は、（例えば）減少を維持するが、リンクごとに別々の接頭辞を使用するか、または代わりにプロトコル（例えば、[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).
（全ホストのマルチキャストを含む）の放送を制限：他のオンリンクのホストに行くから放送を防ぐために、何の効率要件が存在しない場合は、サブネット内にフラッディングすることは問題ではありません。それ以外の場合は、（ARPは、4.3節で以下に覆われている）プロトコル設計者は、（例えば）リンクごとに別々の接頭辞を使用することができ、または洪水がサブネット内のARP以外の放送しました。
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の近隣探索を含む）他のマルチキャストの範囲を限定：他のリンク上のホストに行くからマルチキャストを防ぐために、何の効率要件が存在しない場合は、サブネット内のマルチキャストフラッディングすることは問題ではありません。それ以外の場合は、プロトコル設計者は、（例えば）リンクごとに別の接頭辞を使用するか、または/ MLDの代わりに[RFC4541]をスヌーピングIGMP（Internet Group Management Protocol）を使用することができます。
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では、ルータ広告（RA）におけるプレフィックス情報オプションがオンリンクプレフィックスを通知するルータで使用するために定義されています。つまり、接頭辞がRAを受信/送信され、その上のリンクに割り当てられていることを示しています。すなわち、ルータ及びノードの両方が（[RFC2461]にホストの概念モデルに、またはオンリンクプレフィックスリスト）それらのルーティングテーブル内にリンク経路を有する、であり、で使用される任意のアドレス
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のプレフィックス委譲（DHCP-PD）[RFC3633]は異なるリンク上で使用するためのプレフィックスを要求するためにクライアントが使用するために定義されています。 RFC 3633の状態のセクション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.
有効な応答メッセージを受信すると、各IA_PDを要求ルータは、関連するインターフェイスは以下の例外を除いて、結合しているリンクのそれぞれに委任プレフィックスのそれぞれからサブネットを割り当てる：要求ルータは、任意の委任を割り当ててはいけませんそれが委任するルータから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つの場合の区別が重要であり、IETFプロトコルは上述のことは、2つのシナリオを指摘するために適切であると考えています。 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 believing they are on separate subnets, rather than on a multi-link subnet.
また、プレフィックス情報オプションは、L（オンリンク）フラグが含ま。通常、このフラグは、このプレフィックスがオンリンク決定のために使用することができることを示し、設定されています。設定されていない場合は、広告は接頭辞の性質リンク・オンまたはオフリンクについての声明を行うものではありません。たとえば、プレフィックスはオンリンクとオフリンクされて他の人であることのプレフィックスに属するアドレスの一部とアドレス設定に使用される可能性があります。 Lフラグが設定されていない場合には注意が必要です。具体的には、いくつかのプラットフォームは、アプリケーションがノードの各アドレスに関連付けられたプレフィクスの長さを取得することを可能にします。実装がアドレス構成に使用されるプレフィックス長を返すようにした場合、アプリケーションが誤ってTTL = 1は、通信のために十分であると仮定することができる、そのリンクスコープのマルチキャストは、接頭辞の他のアドレスに到達します。その結果、IABは、アプリケーションへのプレフィックス長を提供するAPIの設計者やメンテナがこの問題に対処することをお勧めします。例えば、彼らはプレフィックスがオンリンクでないときに何のプレフィックス長が存在しないことを示している可能性があります。 APIは、1が存在しないことを報告することができない場合、彼らはプレフィックスがオンリンクでない場合に128の値を報告することを選択するかもしれません。これは、彼らが別のサブネット上ではなく、マルチリンクサブネット上にあると信じ、そのような用途につながります。
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.
理由の一つは、時にはマルチリンクサブネットモデル（よりむしろマルチアクセスリンクモデル）を希望するために引用した、エンドノード間のARP / NDトラフィックを最小にすることです。これは主に、ARPは、すべてのノードで見られる放送になりIPv4の関心事である、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のNDトラフィックはレイヤ2の中間デバイス（ブリッジ、スイッチ、アクセスポイント、等）でよく知られているマルチキャスト学習技術（例えば、[RFC4541]を使用することによって低減することができます。
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またはNDキャッシュおよびサービス要求を維持することができることを示唆しています。しかしながら、このようなキャッシュは、レイヤ2つのポート間の高速モビリティの任意のタイプのを防止し、セキュア近隣探索[RFC3971]を破壊します。結果として、IABは、代わりに、そのようなレイヤ2学習などの代替を使用して、このアプローチは回避されることプロトコル設計者に推奨しています。 （何セキュアARPが存在しない）IPv4の場合、IABは、プロトコル設計者は、ノードが正当2つの適応層2の中間デバイスにおいて任意の層がない層との間のリンクの2つのセグメントを移動させることができる場合には、そのキャッシュからデバイス応答を回避することをお勧めします。また、現在、エンドホスト以外のデバイスは、エンドホストのすべてのアドレスを知っているという保証がないので、プロトコル設計者は、そのような仮定上の任意の依存を避けるべきです。特定の要求のためのキャッシュエントリが見つからない場合、例えば、プロトコル設計者は、ノードがすべてのノードに要求をブロードキャストすることを指定することができます。
[RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
[RFC791]ポステル、J.、 "インターネットプロトコル"、STD 5、RFC 791、1981年9月。
[RFC950] Mogul, J. and J. Postel, "Internet Standard Subnetting Procedure", STD 5, RFC 950, August 1985.
[RFC950]モーグル、J.およびJ.ポステル、 "インターネット標準サブネット手順"、STD 5、RFC 950、1985年8月。
[RFC1812] Baker, F., Ed., "Requirements for IP Version 4 Routers", RFC 1812, June 1995.
[RFC1812]ベイカー、F.、エド。、 "IPバージョン4つのルータのための要件"、RFC 1812、1995年6月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[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月。
[RFC2462] Thomson, S. and T. Narten, "IPv6 Stateless Address Autoconfiguration", RFC 2462, December 1998.
[RFC2462]トムソン、S.とT. Narten氏、 "IPv6のステートレスアドレス自動設定"、RFC 2462、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月。
[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、RFC 3633、2003年12月 "動的ホスト構成プロトコル（DHCP）バージョン6のIPv6プレフィックスオプション"。
[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月。
[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、 "セキュア近隣探索（SEND）"、RFC 3971、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月。
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, February 2006.
[RFC4291] HindenとR.とS.デアリング、 "IPバージョン6アドレッシング体系"、RFC 4291、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、RFC 4541、2006年5月、 "インターネットグループ管理プロトコル（IGMP）とMulticast Listener Discovery（MLD）スヌーピングスイッチの考慮事項"。
[2462BIS] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless Address Autoconfiguration", Work in Progress, May 2005.
[2462BIS]トムソン、S.、Narten氏、T.、およびT.神明、 "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規格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.、 "IPマルチキャスト4.3BSD UNIX用の拡張機能および関連システム（マルチキャスト1.2リリース）"、1989年6月http://www.kohala.com/start/mcast.api.txt
[EIGRP] Cisco, "Enhanced Interior Gateway Routing Protocol", Cisco Document ID 16406, September 2005. http://www.cisco.com/warp/public/103/eigrp-toc.html
[EIGRP]シスコ、「拡張インテリアゲートウェイルーティングプロトコル」、シスコドキュメント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
[LINUX]フアン・マリアーノ・デ・GOYENECHE、 "TCP / IPのHOWTOオーバーマルチキャスト"、1998年3月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）"、RFC 4795、2007年1月。
[MDNS] Cheshire, S. and M. Krochmal, "Multicast DNS", June 2005. http://files.multicastdns.org/draft-cheshire-dnsext-multicastdns.txt
[MDNS]チェシャー、S.及びM. Krochmal、 "マルチキャストDNS"、2005年6月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でのマルチリンクサブネットのサポート"、IETF 54年6月の議事録2002年http://www.ietf.org/proceedings/02jul/ID/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アドレス解決"、RFC 925、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輸送に関するサービスについて：概念と方法」、STD 19、 RFC 1001、1987年3月。
[RFC1027] Carl-Mitchell, S. and J. Quarterman, "Using ARP to Implement Transparent Subnet Gateways", RFC 1027, October 1987.
[RFC1027]カール・ミッチェル、S.およびJ. Quarterman、 "透明サブネットのゲートウェイを実装するためにARPを使用する"、RFC 1027、1987年10月。
[RFC1075] Waitzman, D., Partridge, C., and S. Deering, "Distance Vector Multicast Routing Protocol", RFC 1075, November 1988.
[RFC1075] Waitzman、D.、ヤマウズラ、C.、およびS.デアリング、 "距離ベクトルマルチキャストルーティングプロトコル"、RFC 1075、1988年11月。
[RFC1884] Hinden, R., Ed., and S. Deering, Ed., "IP Version 6 Addressing Architecture", RFC 1884, December 1995.
[RFC1884] HindenとR.、エド。、およびS.デアリング、エド。、 "IPバージョン6アドレッシング体系"、RFC 1884、1995年12月。
[RFC2080] Malkin, G. and R. Minnear, "RIPng for IPv6", RFC 2080, January 1997.
[RFC2080]マルキン、G.およびR. Minnear、 "IPv6のためのRIPng"、RFC 2080、1997年1月。
[RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March 1997.
[RFC2131] Droms、R.、 "動的ホスト構成プロトコル"、RFC 2131、1997年3月。
[RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.
[RFC2328]モイ、J.、 "OSPFバージョン2"、STD 54、RFC 2328、1998年4月。
[RFC2373] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 2373, July 1998.
[RFC2373] HindenとR.とS.デアリング、 "IPバージョン6アドレッシング体系"、RFC 2373、1998年7月。
[RFC2453] Malkin, G., "RIP Version 2", STD 56, RFC 2453, November 1998.
[RFC2453]マルキン、G.、 "RIPバージョン2"、STD 56、RFC 2453、1998年11月。
[RFC3024] Montenegro, G., Ed., "Reverse Tunneling for Mobile IP, revised", RFC 3024, January 2001.
[RFC3024]モンテネグロ、G.編、 "モバイルIPのためのリバーストンネリング、改訂版"、RFC 3024、2001年1月。
[RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains via IPv4 Clouds", RFC 3056, February 2001.
[RFC3056]カーペンター、B.およびK.ムーア、RFC 3056、2001年2月 "のIPv4クラウドを介したIPv6ドメインの接続"。
[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.、レモン、T.、パーキンス、C.、およびM.カーニー、 "IPv6のための動的ホスト構成プロトコル（DHCPv6）"、RFC 3315 、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）のアドレス指定アーキテクチャ"、RFC 3513、2003年4月。
[RFC3753] Manner, J., Ed., and M. Kojo, Ed., "Mobility Related Terminology", RFC 3753, June 2004.
[RFC3753]マナー、J.、エド。、およびM.古城、エド。、 "モビリティ関連用語"、RFC 3753、2004年6月。
[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月。
[RFC3810] Vida, R., Ed., and L. Costa, Ed., "Multicast Listener Discovery Version 2 (MLDv2) for IPv6", RFC 3810, June 2004.
[RFC3810]ビダ、R.、エド。、およびL.コスタ、エド。、 "IPv6のマルチキャストリスナ発見バージョン2（MLDv2の）"、RFC 3810、2004年6月。
[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月。
[RFC4389] Thaler, D., Talwar, M., and C. Patel, "Neighbor Discovery Proxies (ND Proxy)", RFC 4389, April 2006.
[RFC4389]ターラー、D.、Talwar、M.、およびC.パテル、 "近隣探索プロキシ（NDプロキシ）"、RFC 4389、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]デアリング、S.、ハーバーマン、B.、神明、T.、Nordmarkと、E.、尾上、A.およびB. Zill、 "IPv6のスコープアドレスアーキテクチャ"、IETF 54の議事録、2002年7月のhttp： //www.ietf.org/proceedings/02jul/ID/draft-ietf-ipngwg-scoping-arch-04.txt
[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.、カイ、T.、リーチ、P.、区、Y.、およびS.オルブライト、 "シンプル・サービス発見プロトコル（SSDP）"、1999年http://www.upnp.org /resources/specifications.asp
[TCPILL] Stevens, W. Richard, "TCP/IP Illustrated, Volume 1", Addison-Wesley, 1994.
[TCPILL]スティーブンス、W.リチャード、 "TCP / IPイラスト、第1巻"、アディソン・ウェズリー、1994。
[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]マクドナルド、D.およびW.バークレイ、 "マイクロソフトのWindows 2000 TCP / IP実装の詳細"。 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ロア・アンダーソン、ブライアン・カーペンターレスリーDaigle氏エルウィン・デイビスケビン秋オラフKolkmanカーティスLindqvistデビッド・マイヤーデヴィッドオランエリックレスコラデーブターラー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 425 703 8835 Eメール：dthaler@microsoft.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2007).
著作権（C）IETFトラスト（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.
この文書では、BCP 78に含まれる権利と許可と制限の適用を受けており、その中の記載を除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, 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.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットSOCIETY、（もしあれば）を後援し、IETF TRUST ANDインターネットエンジニアリングタスクフォース放棄ALLに設けられています。保証は、明示または黙示、この情報の利用および特定目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証がこれらに限定されません。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 RFC文書の権利に関する手続きの情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、その注意にこの標準を実装するために必要とされる技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 ietf-ipr@ietf.orgのIETFに情報を記述してください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。