[要約] RFC 4903は、単一のIPサブネットが複数の異なる物理リンク（レイヤー2ドメイン）に跨がって構成される「マルチリンクサブネット」が引き起こす様々な技術的課題を分析した文書です。IPv6の近隣探索（Neighbor Discovery）の不整合、重複アドレス検出の失敗、およびルーティングの非効率性など、安易なマルチリンク構成が招くリスクを警告し、適切なネットワーク設計を促しています。
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）The IETF Trust（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. 単一のネットワーク番号を使用し、サブネット番号をLANSに割り当ててホストアドレススペースをパーティション化します（「明示的サブネット」）。
[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].
Instead, the IETF standardized option 3 with [RFC950], whereby hosts were required to learn a subnet mask, and this became the IPv4 model.
代わりに、[RFC950]を備えたIETF標準化オプション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 Scopedアドレスアーキテクチャ[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.
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転送を行っています。
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.
このメモでは、Multi-Link Subnetコンセプトの放棄を動機付けたIPv6 WGで提起された問題を文書化し、他のプロトコルのデザイナーが問題を認識できる（そしてすべき）。
The key words "MUST", "RECOMMENDED", and "SHOULD" in this document are to be interpreted as described in [RFC2119].
このドキュメントのキーワード "MUST"、"RECOMMENDED"、および "SHOULD" は、[RFC2119] で説明されているように解釈されるものとします。
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はサブネットが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 associated with one link. Multiple subnet prefixes may be assigned to the same link."
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/Hop制限とサブネットプレフィックスの関係について仮定するアプリケーションとプロトコルに問題がある可能性があります。
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つの主なケースがあります。一部のアプリケーションおよびプロトコルでは、TTL/ホップ制限1のパケットを送信する場合があります。他のアプリケーションとプロトコルは、255のTTL/ホップ制限付きパケットを送信し、値が受領時に255であることを確認できます。どちらもコミュニケーションを単一のリンク内に制限する方法ですが、これら2つのアプローチの効果はまったく異なります。TTL/ホップ制限を1に設定すると、送信されるパケットがリンクを離れないようにしますが、リンクオフリンク攻撃者がリンクに到達できるパケットを送信することはできません。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]、490ページの状態、「0のTTLはノードローカルを意味し、1はリンクローカルを意味します」（もちろん、これはリンクの定義によって真です）。次に、Page 498は、IP_MULTICAST_TTLおよびIPV6_MULTICAST_HOPSに関して、「これが指定されていない場合、両方ともデフォルト1に、データグラムをローカルサブネットに制限する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 Illustrated」、Volume 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.")
Steve Deeringの元のマルチキャストReadMeファイル[Deering]には、「初期TTL 1を持つマルチキャストデータグラムは同じサブネットに制限されています」というステートメントが含まれており、同様のステートメントが現在、Windowsのドキュメント（[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 Neighbor Discovery（ND）[RFC2461]は、領収書にチェックされたホップ制限255を使用してメッセージを使用して、サブネット内のIPアドレスのリンク層アドレスを解決します。
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
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 Link-Local Multicast Name Resolution [LLMNR]は、TCPに対して1のTTL/ホップ制限を使用します。
o Multicast Listener Discovery (MLD) [RFC3810] uses a Hop Limit of 1.
o マルチキャストリスナーディスカバリー（MLD）[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 Link-Localアドレスプレフィックス内で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).
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.
さらに、他の多数のアプリケーションが、独自のグループアドレスではなく、All-1のブロードキャストアドレス、またはリンクスコープ付きマルチキャストアドレスをすべて使用している場合があります。
The well-known examples of protocols using link-scoped multicast or broadcast generally fall into one of the following groups:
リンクスコープマルチキャストまたはブロードキャストを使用したプロトコルのよく知られた例は、一般に次のグループのいずれかに分類されます。
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 アドレス管理プロトコル：Neighbor Discovery、DHCPV4 [RFC2131]、IPV6（DHCPV6）[RFC3315]の動的ホスト構成プロトコル、Teredo [RFC4380]など。このグループは、リンクとAの関係とAの関係に関する仮定を埋め込む傾向があります。サブネットプレフィックス。たとえば、NDはリンクスコープ付きマルチキャストを使用して、同じサブネットプレフィックス内のIPアドレスのリンクレイヤーアドレスを解決し、サブネット内の複製アドレス検出（下のセクション2.4を参照）を実行します。DHCPは、リンクスコープ付きマルチキャストまたはブロードキャストを使用して、サブネットのアドレスを取得します。Teredoは、Teredo IPv4 Discoveryアドレスは「同じ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 サービスディスカバリープロトコル：Simple Service Discovery Protocol（SSDP）[SSDP]、Bonjour、WS-Discovery [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]、Bonjour、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割り当てリストに記載されているすべてのプロトコルは、ルーターのプロトコル固有のプロキシ機能なしでマルチリンクサブネットで機能し、任意の数のプロキシングを追加することはできません。プロトコルとアプリケーションのスケーリングはありません。さらに、リンクスコープマルチキャストを使用して、将来のプロトコルの開発と使用を妨げる可能性があります。
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.
Duplicate Address Detection（DAD）は、IPv6でリンクスコープマルチキャストとIPv4でリンクスコープブロードキャストを使用しているため、上記のセクション2.3に記載されている問題も使用されます。
"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.
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、Bonjour、Mobile 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 Link-Local Broadcastアドレスまたはリンクローカルマルチキャストアドレスに送信されるデータパケットは、リンク上の他のノードによって受信できます。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.
NBMAリンクの1つの使用は、リンク自体が幅広いエリアリンク（たとえば、6to4 [rfc3056]などのトンネル）として意図されている場合です。ここで、セクション2.3の機能のグループは、広範囲にわたって必要ありません。確かに、広い地域の定義はやや主観的です。広いエリアリンクでのマルチキャストのサポートは、一連のローカルエリアリンク全体のマルチキャストルーティングをサポートすることに類似しています。セクション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/ホップ制限の減少を削除することは問題ではありません。それ以外の場合、プロトコル設計者は（たとえば）減少を保持しますが、リンクごとに個別のプレフィックスを使用するか、代わりに何らかの形のブリッジングプロトコルを使用できます（例：[ブリッジ]または[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).
放送の制限（All-Hosts Multicastを含む）：ブロードキャストが他のオンリンクホストに行くのを防ぐための効率的要件がない場合、サブネット内でそれをあふれさせることは問題ではありません。それ以外の場合、プロトコル設計者は（たとえば）リンクごとに個別のプレフィックスを使用するか、サブネット内の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 Discoveryを含む）：マルチキャストが他のオンリンクホストに到達するのを防ぐための効率的要件がない場合、サブネット内でマルチキャストをフラッディングすることは問題ではありません。それ以外の場合、プロトコル設計者は（たとえば）リンクごとに個別のプレフィックスを使用するか、代わりにインターネットグループ管理プロトコル（IGMP）/MLDスヌーピング[RFC4541]を使用できます。
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 the prefix are assigned to an interface (on any node) attached to that.
IPv6では、ルーター広告（RA）のプレフィックス情報オプションは、ルーターが使用するためにオンリンクプレフィックスを宣伝するために定義されています。つまり、RAが送信/受信されるリンクにプレフィックスが割り当てられていることを示します。つまり、ルーターとノードはどちらもルーティングテーブル（または[RFC2461]のホストの概念モデルにオンリンクプレフィックスリスト）にオンリンクルートを持ち、プレフィックスで使用されるアドレスはに割り当てられますそれに添付されているインターフェイス（任意のノード上）。
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.
有効な Reply メッセージを受信すると、要求側ルーターは各 IA_PD に対して、委任された各プレフィックスから、関連するインターフェースが接続されている各リンクにサブネットを割り当てます。ただし次の例外があります: 要求側ルーターは、委任側ルーターからDHCPメッセージを受信したリンクに対して、委任されたプレフィックスまたは委任されたプレフィックスからのサブネットを割り当ててはなりません (MUST NOT)。
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は、他のプロトコル設計者がこれらのプロトコルのIETF定義のスコープと一致し続けることを推奨しています（たとえば、DHCP-PDを使用して同じリンクにプレフィックスを割り当てるか、RASを使用してプレフィックスを別のリンクに割り当てることができません）。
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が存在しないことを報告できない場合、プレフィックスがオンリンクでない場合、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.
マルチリンクサブネットモデルを（マルチアクセスリンクモデルではなく）必要とすることが必要な理由の1つは、エンドノード間のARP/NDトラフィックを最小限に抑えることです。これは主にIPv4の懸念事項であり、ARPはすべてのノードで見られるブロードキャストをもたらし、IPv4アドレスが解決されるノードだけではありません。これが重大な懸念であっても、マルチリンクサブネットモデルの使用は必要ありません。ポイントツーポイントリンクモデルは、この問題を完全に回避する1つの方法です。
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.).
マルチアクセスリンクモデルでは、Layer 2中間デバイス（ブリッジ、スイッチ、アクセスポイントなど）で有名なマルチキャスト学習技術（[RFC4541]など）を使用することにより、IPv6 ndトラフィックを削減できます。
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.
[RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
[RFC791] Postel, J.、「インターネットプロトコル」、STD 5、RFC 791、1981年9月。
[RFC950] Mogul, J. and J. Postel, "Internet Standard Subnetting Procedure", STD 5, RFC 950, August 1985.
[RFC950] Mogul, J. and J. Postel、「インターネット標準サブネット手順」、STD 5、RFC 950、1985年8月。
[RFC1812] Baker, F., Ed., "Requirements for IP Version 4 Routers", RFC 1812, June 1995.
[RFC1812] Baker, F., Ed.、「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] Bradner, S.、「要件レベルを示すためにRFCで使用するためのキーワード」、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., and W. Simpson、「IPバージョン6（IPv6）の近隣発見」、RFC 2461、1998年12月。
[RFC2462] Thomson, S. and T. Narten, "IPv6 Stateless Address Autoconfiguration", RFC 2462, December 1998.
[RFC2462] Thomson, S. and T. Narten、「IPv6 Stateless Address Autoconfiguration」、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. and R. Droms、「動的ホスト構成プロトコル（DHCP）バージョン6のIPv6プレフィックスオプション」、RFC 3633、2003年12月。
[RFC3927] Cheshire, S., Aboba, B., and E. Guttman, "Dynamic Configuration of IPv4 Link-Local Addresses", RFC 3927, May 2005.
[RFC3927] Cheshire, S., Aboba, B., and E. Guttman、「IPv4 Link-Localアドレスの動的構成」、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., Ed., Kempf, J., Zill, B., and P. Nikander、「Secure Neighbor Discovery（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] Deering, S., Haberman, B., Jinmei, T., Nordmark, E., and 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. and S. Deering、「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] Christensen, M., Kimball, K., and F. Solensky、「インターネットグループ管理プロトコル（IGMP）およびマルチキャストリスナーディスカバリー（MLD）スヌーピングスイッチに関する考慮事項」、RFC 4541、2006年5月。
[2462BIS] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless Address Autoconfiguration", Work in Progress, May 2005.
[2462BIS] Thomson, S., Narten, T., and T. Jinmei、「IPv6 Stateless Address Autoconfiguration」、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, editor、「メディアアクセスコントロール（MAC）ブリッジ」、ANSI/IEEE STD 802.1d、2004、http://standards.ieee.org/ getieee802/download/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
[DEERING] Deering, S.、「4.3bsd Unixおよび関連システムのIPマルチキャスト拡張機能（マルチキャスト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
[LINUX] Juan-Mariano de Goyeneche, "Multicast over TCP/IP HOWTO", March 1998. http://www.linux.com/howtos/Multicast-HOWTO-2.shtml
[LINUX] Juan-Mariano de 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., Thaler, D., and L. Esibov、「Link-Local Multicast Name Resolution（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] Cheshire, S. and M. Krochmal、「Multicast 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] Thaler, D. and C. Huitema、「IPv6のマルチリンクサブネットサポート」、2002年6月、IETF 54の議事録。IPv6-マルチリンクサブネット-00.txt
[RBRIDGE] Perlman, R., Gai, S., and D. Dutt, "Rbridges: Base Protocol Specification", Work in Progress, March 2007.
[RBRIDGE] Perlman, R., Gai, S., and D. Dutt、「Rbridges：Base Protocol Specification」、Progress、2007年3月。
[RFC925] Postel, J., "Multi-LAN address resolution", RFC 925, October 1984.
[RFC925] Postel, J.、「マルチランアドレス解決」、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] Devense Advanced Research Projects Agency、Internet Activity Board、およびEnd-to-End ServicesタスクフォースのNetBIOSワーキンググループ、「TCP/UDP輸送に関するNetBIOSサービスのプロトコル標準：概念と方法」、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] Carl-Mitchell, S. and 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., Partridge, C., and S. Deering、「距離ベクトルマルチキャストルーティングプロトコル」、RFC 1075、1988年11月。
[RFC1884] Hinden, R., Ed., and S. Deering, Ed., "IP Version 6 Addressing Architecture", RFC 1884, December 1995.
[RFC1884] Hinden, R., Ed., and S. Deering, Ed.、「IPバージョン6アドレス指定アーキテクチャ」、RFC 1884、1995年12月。
[RFC2080] Malkin, G. and R. Minnear, "RIPng for IPv6", RFC 2080, January 1997.
[RFC2080] Malkin, G. and R. Minnear、「RIPNG for IPv6」、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] Moy, 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. and S. Deering、「IPバージョン6アドレス指定アーキテクチャ」、RFC 2373、1998年7月。
[RFC2453] Malkin, G., "RIP Version 2", STD 56, RFC 2453, November 1998.
[RFC2453] Malkin, G.、「RIPバージョン2」、STD 56、RFC 2453、1998年11月。
[RFC3024] Montenegro, G., Ed., "Reverse Tunneling for Mobile IP, revised", RFC 3024, January 2001.
[RFC3024] Montenegro, G., Ed.、「モバイルIPの逆トンネル、改訂」、RFC 3024、2001年1月。
[RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains via IPv4 Clouds", RFC 3056, February 2001.
[RFC3056] Carpenter, B. and K. Moore、「IPv4 Cloudsを介したIPv6ドメインの接続」、RFC 3056、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., Ed., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney、「IPv6の動的ホスト構成プロトコル」、RFC 3315、2003年7月。
[RFC3513] Hinden, R. and S. Deering, "Internet Protocol Version 6 (IPv6) Addressing Architecture", RFC 3513, April 2003.
[RFC3513] Hinden, R. and S. Deering、「インターネットプロトコルバージョン6（IPv6）アドレス指定アーキテクチャ」、RFC 3513、2003年4月。
[RFC3753] Manner, J., Ed., and M. Kojo, Ed., "Mobility Related Terminology", RFC 3753, June 2004.
[RFC3753] Manner, J., Ed., and M. Kojo, Ed.、「Mobility関連用語」、RFC 3753、2004年6月。
[RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004.
[RFC3775] Johnson, D., Perkins, C., and 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] Vida, R., Ed., and L. Costa, Ed.、「Multicast Riesder Discoveryバージョン2（MLDV2）のIPv6」、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：ネットワークアドレス翻訳（NAT）を介してUDPを介してIPv6をトンネル化する」、RFC 4380、2006年2月。
[RFC4389] Thaler, D., Talwar, M., and C. Patel, "Neighbor Discovery Proxies (ND Proxy)", RFC 4389, April 2006.
[RFC4389] Thaler, D., Talwar, M., and C. Patel、「Neighbor Discovery Proxies（ND Proxy）」、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] Deering, S., Haberman, B., Jinmei, T., Nordmark, E., Onoe, A., and B. Zill、「IPv6スコープアドレスアーキテクチャ」、IETF 54の議事録、2002年7月。//www.ietf.org/proceedings/02jul/i-d/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, Yaron Y., Cai, T., Leach, P., Gu, Y., and S. Albright、「Simple Service Discovery Protocol（SSDP）」、1999年。http://www.upnp.org/Resources/specifications.asp
[TCPILL] Stevens, W. Richard, "TCP/IP Illustrated, Volume 1", Addison-Wesley, 1994.
[TCPILL] Stevens, W. Richard、「TCP/IP Illustrated、Volume 1」、Addison-Wesley、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] MacDonald, D. and W. Barkley、「Microsoft Windows 2000 TCP/IP実装の詳細」。http://www.microsoft.com/ technet/itholutions/network/deploy/depovg/tcpip2k.mspx
[UNP] Stevens, W. Richard, "Unix Network Programming, Volume 1, Second Edition", Prentice Hall, 1998.
[UNP] Stevens, W. Richard、「UNIXネットワークプログラミング、第1巻、第2版」、1998年Prentice Hall。
[WSDISC] Microsoft, "Web Services Dynamic Discovery (WS-Discovery)", 2005. http://specs.xmlsoap.org/ws/2005/04/discovery/ws-discovery.pdf
[WSDISC] Microsoft、「Web Services Dynamic Discovery（WS-Discovery）」、2005年。http://specs.xmlsoap.org/ws/2005/04/discovery/ws-discovery.pdf
IAB Members at the time of this writing
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
バーナード・アボバ・ロア・アンダーソン・ブライアン・カーペンター・レスリー・デイグル・エルウィン・デイヴィス・ケビン・フォール・フォール・オラフ・コルクマン・カルティス・リンドクヴィスト
Author's Address
著者の連絡先
Dave Thaler Microsoft One Microsoft Way Redmond, WA 98052
Phone: +1 425 703 8835
EMail: dthaler@microsoft.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2007).
著作権（c）The IETF Trust（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.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供され、貢献者、彼/彼女が代表する組織（もしあれば）、インターネット協会、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は、知的財産権またはその他の権利の有効性または範囲に関して、本書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスに基づくライセンスの範囲に関連すると主張される可能性のある他の権利に関しては、立場を取得しません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。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.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得しようとする試みの結果を取得できます。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エディター機能の資金は現在、インターネット協会によって提供されています。