Network Working Group N. Shen, Ed.
Request for Comments: 5309 Cisco Systems
Category: Informational A. Zinin, Ed.
Alcatel-Lucent
October 2008
Point-to-Point Operation over LAN
in Link State Routing Protocols
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.
このメモはインターネットコミュニティのための情報を提供します。それはどんな種類のインターネット標準を指定しません。このメモの配布は無制限です。
Abstract
抽象
The two predominant circuit types used by link state routing protocols are point-to-point and broadcast. It is important to identify the correct circuit type when forming adjacencies, flooding link state database packets, and representing the circuit topologically. This document describes a simple mechanism to treat the broadcast network as a point-to-point connection from the standpoint of IP routing.
リンクステートルーティングプロトコルによって使用される二つの主要な回路のタイプは、ポイントツーポイント及び放送されます。隣接関係、フラッディングリンク状態データベースのパケットを形成し、トポロジー的回路を表す場合、正しい回路タイプを識別することが重要です。この文書では、IPルーティングの観点から、ポイントツーポイント接続として放送ネットワークを治療するための簡単なメカニズムについて説明します。
Point-to-point and broadcast are the two predominant circuit types used by link state routing protocols such as IS-IS [ISO10589] [RFC1195] and OSPF [RFC2328] [RFC5340]. They are treated differently with respect to establishing neighbor adjacencies, flooding link state information, representing the topology, and calculating the Shortest Path First (SPF) and protocol packets. The most important differences are that broadcast circuits utilize the concept of a designated router and are represented topologically as virtual nodes in the network topology graph.
ポイントツーポイント及び放送のようなリンク状態ルーティングプロトコルによって使用される二つの主要な回路タイプであるIS-IS [ISO10589] [RFC1195]とOSPF [RFC2328]、[RFC5340]。これらは、隣接隣接関係、フラッディングリンク状態情報を確立トポロジを表し、そして最短パス優先（SPF）とプロトコル・パケットを計算に対して異なる方法で処理されます。最も重要な違いは、ブロードキャスト回路は、指定ルータの概念を利用し、ネットワークトポロジグラフ内の仮想ノードとして位相幾何学的に表現されているということです。
Compared with broadcast circuits, point-to-point circuits afford more straightforward IGP operation. There is no designated router involved, and there is no representation of the pseudonode or network Link State Advertisement (LSA) in the link state database. For IS-IS, there also is no periodic database synchronization. Conversely, if there are more than two routers on the LAN media, the traditional view of the broadcast circuit will reduce the routing information in the network.
放送回路と比較すると、ポイントツーポイント回線は、より簡単IGP操作を与えます。関与なし指定ルータはありません、とのリンク状態データベース内擬似ノードまたはネットワークリンクステートアドバタイズメント（LSA）の表現はありません。 IS-ISのために、また、定期的なデータベースの同期はありません。 LANメディア上の二つ以上のルータが存在する場合には逆に、放送回路の伝統的な見方は、ネットワーク内のルーティング情報を削減します。
When there are only two routers on the LAN, it makes more sense to treat the connection between the two routers as a point-to-point circuit. This document describes the mechanism to allow link state routing protocols to operate using point-to-point connections over a LAN under this condition. Some implications related to forwarding IP packets on this type of circuit are also discussed. We will refer to this as a p2p-over-lan circuit in this document.
LAN上の2つだけルータが存在する場合は、ポイントツーポイント回線として2つのルータ間の接続を処理するために、より理にかなっています。この文書では、リンク状態ルーティングプロトコルは、この条件の下でLAN上のポイントツーポイント接続を使用して動作できるようにするメカニズムを説明しています。このタイプの回路にIPパケットを転送に関連するいくつかの意味合いも議論されています。私たちは、この文書に記載されているP2PオーバーLAN回路としてこれを参照します。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
この文書のキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", および "OPTIONAL" はRFC 2119 [RFC2119]に記載されているように解釈されます。
Even though a broadcast circuit is meant to handle more than two devices, there are cases where only two routers are connected over either the physical or logical LAN segment:
ブロードキャスト回路はつ以上のデバイスを扱うことを意図しているにもかかわらず、2つだけのルータが物理的または論理的なLANセグメントのいずれかを介して接続されている場合があります。
1. The media itself is being used for point-to-point operation between two routers. This is mainly for long-haul operation. 2. There are only two routers on the physical LAN. 3. There are only two routers on a virtual LAN (vLAN).
1.メディア自体は、2つのルータ間のポイントツーポイント動作のために使用されています。これは、長距離運転のために主にあります。 2.物理的なLAN上の唯一の2台のルータがあります。 3.仮想LAN（VLAN）上の唯一の2台のルータがあります。
In any of the above cases, the link state routing protocols will normally still treat the media as a broadcast circuit. Hence, they will have the overhead involved with protocol LAN operation without the benefits of reducing routing information and optimized flooding.
上記いずれの場合も、リンク状態ルーティングプロトコルは、通常、依然としてブロードキャスト回路としてメディアを扱います。したがって、彼らは、ルーティング情報と最適化された洪水を軽減するメリットなしプロトコルLAN操作に伴うオーバーヘッドを持っています。
Being able to treat a LAN as a point-to-point circuit provides the benefit of reduction in the amount of information routing protocols must carry and manage. DR/DIS (Designated Router / Designated Intermediate System) election can be omitted. Flooding can be done as in p2p links without the need for using "LSA reflection" by the DR in OSPF or periodic Complete Sequence Number Packets (CSNPs) in IS-IS.
ポイントツーポイント回線としてのLANを扱うことができることは、ルーティングプロトコルが運ぶと管理しなければならない情報の量の減少の利点を提供します。 DR / DIS（指定ルーター/指定中間システム）選挙を省略することができます。フラッディングは、IS-ISにOSPFにおけるDRまたは周期完全な配列番号のパケットが「LSA反射」（のcSNP）を使用する必要なしにP2Pリンクと同様に行うことができます。
Also, if a broadcast segment wired as a point-to-point link can be treated as a point-to-point link, only the connection between the two routers would need to be advertised as a topological entity.
ポイントツーポイントリンクとして有線放送セグメントがポイントツーポイントリンクとして扱うことができる場合にも、2つのルータ間の唯一の接続が位相幾何学的エンティティとしてアドバタイズする必要があります。
Even when there are multiple routers on the LAN, an ISP may want to sub-group the routers into multiple vLANs, since this allows them to assign different costs to IGP neighbors. When there are only two routers in some of the vLANs, this LAN can be viewed by the IGP as a mesh of point-to-point connections.
これは彼らがIGP隣人に異なるコストを割り当てることができますので、LAN上の複数のルータが存在する場合でも、ISPは、複数のVLANにサブグループにルータをしたいことがあります。 VLANの一部では2つだけルータが存在する場合は、このLANは、ポイントツーポイント接続のメッシュとしてIGPで見ることができます。
The IP unnumbered configuration is widely used in networks. It enables IP processing on a point-to-point interface without an explicit IP address. The IP unnumbered interface can "borrow" the IP address of another interface on the node. The advantages of unnumbered point-to-point links are obvious in the current IP addressing environment where addresses are a scarce resource. The unnumbered interface can also be applied over p2p-over-lan circuits. Separating the concept of network type from media type will allow LANs, e.g., ethernet, to be unnumbered and realize the IP address space savings. Another advantage is in simpler network management and configuration. In the case of an IPv6 network, a link local address used in IS-IS [RFC5308] and OSPFv3 [RFC5340] serves the same purpose.
IPアンナンバードの設定は、ネットワークで広く使用されています。これは、明示的なIPアドレスを持たないポイントツーポイントインターフェイス上のIP処理を可能にします。 IPアンナンバードインターフェイスは、ノード上の別のインターフェイスのIPアドレスを「借りる」ことができます。番号なしポイントツーポイントリンクの利点は、アドレスが乏しい資源である現在のIPアドレス指定の環境の中で明らかにされています。無数のインタフェースはまた、P2PオーバーLAN回路上に塗布することができます。メディアタイプからネットワークタイプの概念を分離するLANは、例えば、イーサネットは、アンナンバードこととIPアドレススペースの節約を実現することができます。もう一つの利点は、シンプルなネットワーク管理および構成です。 IPv6ネットワークの場合、IS-ISに使用されるリンクローカルアドレス[RFC5308]とのOSPFv3 [RFC5340]は、同じ目的を果たします。
When an IP network includes multi-access segments, each segment is usually assigned a separate subnet, and each router connected to it is assigned a distinct IP address within that subnet. The role of the IP address assigned to a multi-access interface can be outlined as follows:
IPネットワークは、マルチアクセスセグメントを含む場合、各セグメントは、通常、別々のサブネットを割り当てられ、それに接続された各ルータは、そのサブネット内の異なるIPアドレスが割り当てられます。次のようにマルチアクセスインターフェイスに割り当てられたIPアドレスの役割を概説することができます。
1. Source IP address - The interface address can be used by the router as the source IP address in locally originated IP packets that are destined for that subnet or have a best path next hop on that subnet.
1.送信元IPアドレス - インターフェースアドレス、ローカルにそのサブネット宛てのか、そのサブネット上の次のホップの最適なパスを持っているIPパケットの発信元の送信元IPアドレスとしてルータで使用することができます。
2. Destination IP address - The interface address can be used by other devices in the network as a destination address for packets to router applications (examples include telnet, SMTP, TFTP, OSPF, BGP, etc).
2.宛先IPアドレス - アドレスは、ルータのアプリケーションへのパケットの宛先アドレスとして、ネットワーク内の他のデバイスで使用することができるインタフェース（例は、Telnet、SMTP、TFTP、OSPF、BGPなどを含みます）。
3. Next-hop identifier - If other routers connected to the same segment need to forward traffic through the router, the corresponding routes in their routing tables will include the router's interface IP address. This address will be used to find the router's MAC (Media Access Control) address using the ARP/ND (Address Resolution Protocol / Neighbor Discovery) protocol. Effectively, the interface IP addresses help other routers find the data-link layer details that are required to specify the destination of the encapsulating data-link frame when it is sent on the segment.
3.ネクストホップ識別子 - 同じセグメントに接続された他のルータは、ルータを介してトラフィックを転送する必要がある場合は、そのルーティングテーブル内の対応するルートは、ルータのインターフェイスのIPアドレスを含むことになります。このアドレスは、ARP / ND（アドレス解決プロトコル/近隣探索）プロトコルを使用して、ルータのMAC（Media Access Control）アドレスを見つけるために使用されます。効果的に、インターフェイスのIPアドレスは、他のルータは、それがセグメント上で送信されたときにカプセル化データリンクフレームの送信先を指定するために必要とされるデータリンク層の詳細を見つけます。
The IP addressing scheme includes an option that allows the administrators to not assign any subnets to point-to-point links (links connecting only two devices and using protocols like PPP, SLIP, or HDLC for IP encapsulation). This is possible because the routers do not need next-hop identifiers on point-to-point links (there is only one destination for any transmission), and an interface-independent IP address can be used as the source and destination. Using the unnumbered option for a point-to-point link essentially makes it a purely topological entity used only to reach other destinations.
アドレッシング方式IPは、管理者が（リンクは、2つだけのデバイスを接続し、PPP、SLIP、またはIPカプセル化のためのHDLCなどのプロトコルを使用して）ポイントツーポイントリンクを任意のサブネットを割り当てないことを可能にするオプションを含みます。ルータは、ポイントツーポイントリンク上の次ホップ識別子を必要としないので、これは（任意の送信のための唯一の宛先が存在する）ことが可能であり、インターフェイスに依存しないIPアドレスは、送信元と宛先として使用することができます。ポイントツーポイントリンクのための非番号オプションを使用すると、基本的に、それは純粋にトポロジカルエンティティが他の目的地に到達するためにのみ使用します。
The idea is very simple: provide a configuration mechanism to inform the IGP that the circuit is type point-to-point, irrespective of the physical media type. For the IGP, this implies that it will send protocol packets with the appropriate point-to-point information, and it expects to receive protocol packets as they would be received on a point-to-point circuit. Over LAN media, the MAC header must contain the correct multicast MAC address to be received by the other side of the connection. For vLAN environments, the MAC header must also contain the proper vLAN ID.
アイデアは非常に単純である：回路にかかわらず、物理メディアタイプの、ポイント・ツー・ポイントのタイプであることをIGPに通知する構成機構を提供します。 IGPのため、これは適切なポイント・ツー・ポイントの情報をプロトコルパケットを送信することを意味し、そしてそれは、ポイントツーポイント回線上で受信されるようにプロトコル・パケットを受信することを期待します。 LAN媒体上に、MACヘッダは、接続のもう一方の側が受信する正しいマルチキャストMACアドレスを含んでいなければなりません。 VLAN環境のために、MACヘッダはまた、適切なVLAN IDを含んでいなければなりません。
In order to allow LAN links used to connect only two routers to be treated as unnumbered point-to-point interfaces, the MAC address resolution and nexthop IP address issues need to be addressed.
無数のポイントツーポイントインターフェイスとして扱われる2つだけのルータを接続するためのLANのリンクを可能にするために、MACアドレス解決とネクストホップIPアドレスの問題に対処する必要があります。
This p2p-over-lan circuit extension for IS-IS is only concerned with pure IP routing and forwarding operation.
IS-ISのためのこのP2PオーバーLAN回線拡張は、純粋なIPルーティングおよび転送操作にのみ関係しています。
Since physically the circuit is a broadcast one, the IS-IS protocol packets need to have MAC addresses for this p2p-over-lan circuit. From a link-layer point of view, those packets are IS-IS LAN packets. The Multi-destination address including AllISs, AllL1ISs, and AllL2ISs, defined in [ISO10589], can be used for link-layer encapsulation; the use of AllISs is recommended.
物理的に回路がブロードキャスト一つであるため、プロトコルパケットIS-ISは、このP2PオーバーLAN回線用のMACアドレスを持っている必要があります。ビューのリンク層の観点から、これらのパケットは、IS-IS LANパケットです。 [ISO10589]で定義AllISs、AllL1ISs、及びAllL2ISs含むマルチ宛先アドレスは、リンク層のカプセル化のために使用することができます。 AllISsの使用が推奨されます。
The circuit needs to have IP address(es), and the p2p IS-IS Hello (IIH) over this circuit MUST include the IP interface address(es) as defined in [RFC1195]. The IPv4 address(es) included in the IIHs is either the IP address assigned to the interface in the case of a numbered interface or the interface-independent IP address in the case of an unnumbered interface. The IPv6 addresses are link-local IPv6 address(es) [RFC5308].
回路は、IPアドレスを持っている必要があり、[RFC1195]で定義されるように、この回路上のP2P IS-ISハロー（IIH）はIPインタフェースアドレスを含まなければなりません。 IPv4アドレス（ES）はIIHSに含ま番号インターフェースまたはアンナンバードインターフェイスの場合にインターフェイスに依存しないIPアドレスの場合にはインターフェイスに割り当てられたIPアドレスのいずれかです。 IPv6アドレスは、リンクローカルIPv6アドレス（複数可）[RFC5308]です。
OSPF and OSPFv3 [RFC5340] routers supporting the capabilities described herein should support an additional interface configuration parameter specifying the interface topology type. For a LAN (i.e., broadcast-capable) interface, the interface may be viewed as a point-to-point interface. Both routers on the LAN will simply join the AllSPFRouters multicast group and send all OSPF packets with a destination address of AllSPFRouters. AllSPFRouters is 224.0.0.5 for OSPF and FF02::5 for OSPFv3. This is identical to operation over a physical point-to-point link as described in Sections 8.1 and 8.2 of [RFC2328].
本明細書に記載の機能をサポートするOSPFおよびOSPFv3の[RFC5340]ルータは、インタフェース・トポロジ・タイプを指定する追加のインターフェイス・コンフィギュレーション・パラメータをサポートしなければなりません。 LAN（すなわち、放送対応）インタフェース、インタフェースは、ポイントツーポイントインターフェイスと見なすことができます。 LAN上の両方のルータは単にAllSPFRoutersマルチキャストグループに参加し、AllSPFRoutersの宛先アドレスを持つすべてのOSPFパケットを送信します。 AllSPFRoutersは、OSPFv3のためのOSPFのために224.0.0.5とFF02 :: 5です。セクション8.1と[RFC2328]の8.2に記載されているように、これは物理的なポイントツーポイントリンク上の動作と同一です。
Unlike a normal point-to-point IGP circuit, the IP nexthop for the routes using this p2p-over-lan circuit as an outbound interface is not optional. The IP nexthop address has to be a valid interface or internal address on the adjacent router. This address is used by a local router to obtain the MAC address for IP packet forwarding. The ARP process has to be able to resolve the internal IPv4 address used for the unnumbered p2p-over-lan circuits. For the ARP implementation (which checks that the subnet of the source address of the ARP request matches the local interface address), this check needs to be relaxed for the unnumbered p2p-over-lan circuits. The misconfiguration detection is handled by the IGPs and is described in Section 4.5. In the IPv6 case, the ND resolves the MAC for the link-local address on the p2p-over-lan circuit, which is part of the IPv6 neighbor discovery process [RFC4861].
通常のポイントツーポイントIGP回路とは異なり、送信インタフェースとしてこのP2PオーバーLAN回路を使用してルートのIPネクストホップはオプションではありません。 IPネクストホップアドレスは、隣接するルータ上で有効なインターフェイスまたは内部アドレスである必要があります。このアドレスは、IPパケット転送のためのMACアドレスを取得するために、ローカルルータが使用されます。 ARPプロセスがアンナンバードP2PオーバーLAN回線に使用される内部のIPv4アドレスを解決できなければなりません。 （ARP要求の送信元アドレスのサブネットがローカルインタフェースアドレスと一致することを確認）ARPの実装のために、このチェックは、無数のP2PオーバーLAN回路に緩和する必要があります。設定ミスの検出はのIGPによって処理され、4.5節に記述されています。 IPv6のケースでは、NDは、IPv6近隣探索プロセス[RFC4861]の一部であるP2PオーバーLAN回線上のリンクローカルアドレス用のMACを解決します。
In more general cases, while p2p-over-lan circuit is used as an unnumbered link, other MAC address resolution mechanisms are needed for IP packet forwarding; for example, if link state IGP is not configured over this p2p-over-lan link, or if the mechanism described in Section 4.3 is not possible. The following techniques can be used to acquire the MAC address and/or the next-hop IP address of the remote device on an unnumbered point-to-point LAN link.
P2PオーバーLAN回路は、無数のリンクとして使用されている間、より一般的なケースでは、他のMACアドレス解決メカニズムは、IPパケット転送に必要とされます。リンク状態IGPこのP2PオーバーLANリンクを介して設定されていない場合、例えば、セクション4.3で説明されたメカニズムが可能であるかどうか。以下の技術は、MACアドレス及び/又は無数のポイントツーポイントLANリンク上のリモートデバイスのネクストホップIPアドレスを取得するために使用することができます。
1. Static configuration. A router can be statically configured with the MAC address that should be used as the destination MAC address when sending data out of the interface.
1.静的な構成。ルータは、静的インタフェースからデータを送信するとき、宛先MACアドレスとして使用されるべきMACアドレスを設定することができます。
2. MAC address gleaning. If a dynamic routing protocol is running between the routers connected to the link, the MAC address of the remote device can be taken from a data-link frame carrying a packet of the corresponding routing protocol.
落穂拾い2. MACアドレス。動的ルーティングプロトコルは、リンクに接続されたルータ間で実行されている場合、リモートデバイスのMACアドレスは、対応するルーティング・プロトコルのパケットを搬送するデータリンクフレームから採取することができます。
With this p2p-over-lan extension, the difference between a LAN and a point-to-point circuit can be made purely by configuration. It is important to implement the mechanisms for early detection of misconfiguration.
このP2PオーバーLAN拡張と、LANとポイントツーポイント回路との間の差は、構成によって純粋に製造することができます。設定ミスの早期発見のためのメカニズムを実装することが重要です。
If the circuit is configured as the point-to-point type and receives LAN hello packets, the router MUST discard the incoming packets; if the circuit is a LAN type and receives point-to-point hello packets, it MUST discard the incoming packets. If the system ID or the router ID of an incoming hello packet does not match the system ID or the router ID for an established adjacency over a p2p-over-lan circuit, the packet MUST be discarded. Furthermore, if OSPF hello suppression (as described in [RFC1793]) is active for the adjacency, the hello suppression MUST be terminated for a period of RouterIntervalSeconds. After this interval, either the neighbor adjacency will time out and an adjacency may be formed with a neighbor with a different router ID, or hello suppression may be renegotiated. The implementation should offer logging and debugging information of the above events.
回路は、ポイントツーポイントタイプとして構成され、LANのハローパケットを受信している場合、ルータは、着信パケットを廃棄しなければなりません。回路は、LANタイプであり、ポイントツーポイントのハローパケットを受信すると、着信パケットを破棄しなければなりません。システムIDまたは着信ハローパケットのルータIDがP2PオーバーLAN回線を介して確立隣接のシステムIDまたはルータIDと一致しない場合、パケットは廃棄されなければなりません。 OSPFハロー抑制が（[RFC1793]に記載されているように）隣接に対してアクティブである場合また、ハロー抑制はRouterIntervalSecondsの期間で終了しなければなりません。この期間後、ネイバー隣接関係がタイムアウトするかと隣接関係は、異なるルータIDと隣接して形成されていてもよい、又はハロー抑制が再交渉されてもよいです。実装は、上記のイベントのログとデバッグ情報を提供する必要があります。
Both routers on a LAN must support the p2p-over-lan extension and both must have the LAN segment configured as a p2p-over-lan circuit for successful operation. Both routers SHOULD support at least one of the above listed methods for mapping IP addresses on the link to MAC address. If a proprietary method of IP address to MAC address resolution is used by one router, both routers must be capable of using the same method. Otherwise, the link should be configured as a standard LAN link, with traditional IGP LAN models used.
LAN上の両方のルータは、P2PオーバーLAN拡張をサポートしなければならないとの両方が成功した動作のためにP2PオーバーLAN回路として設定されたLANセグメントを有していなければなりません。両方のルータがMACアドレスへのリンクにマッピングするIPアドレスについて、上記の方法のうちの少なくとも1つをサポートする必要があります。 MACアドレス解決にIPアドレスの独自の方法は、1つのルータによって使用されている場合、両方のルータは同じ方法を使用することができなければなりません。それ以外の場合は、リンクが使用される伝統的なIGP LANモデルで、標準LANリンクとして設定する必要があります。
While there is advantage to using this extension on the LANs that are connected back to back or only contain two routers, there are trade offs when modeling a LAN as multiple vLANs and using this extension since one does sacrifice the inherent scalability benefits of multi-access networks. In general, it will increase the link state database size, the amount of packets flooded, and the route calculation overhead.
バックアップまたは2台のだけのルータを含むように戻って接続されたLAN上でこの拡張機能を使用する利点があるが、複数のVLANとしてLANをモデル化し、この拡張機能を使用するときに1がマルチアクセスの固有のスケーラビリティの利益を犠牲にないので、トレードオフがありますネットワーク。一般的に、リンク状態データベースのサイズ、フラッディングパケットの量、及び経路計算オーバーヘッドを増加させるであろう。
Deployment of the described technique brings noticeable benefits from the perspective of IP address usage: the network management and the router configuration. Note, however, that use of the IP unnumbered option for point-to-point LAN links inherits the same problems as those present for serial links, i.e., not being able to ping or monitor a specific interface between routers.
ネットワーク管理とルータの設定：記載された技術の展開は、IPアドレスの使用率の観点から顕著な利点をもたらします。ノートは、しかしながら、ポイントツーポイントLANリンクのIP非番号オプションの使用は、シリアルリンクのための本と同様の問題を継承し、すなわち、ルータ間の特定のインターフェイスにpingを実行または監視することができません。
This document does not introduce any new security issues to IS-IS, OSPF, ARP, or ND. Implementations may have 'source address subnet checks' that need to be relaxed as described in Section 4.3. These are used to manage misconfigurations, not so much to secure ARP -- if an attacker would be attached to the LAN, (s)he could pick a subnet-wise correct address as well.
この文書では、IS-IS、OSPF、ARP、またはNDにどんな新しいセキュリティ問題を紹介しません。実装は4.3節で説明したように緩和する必要がある「送信元アドレス、サブネット・チェック」を持っていることがあります。これらは、ARPを確保することはあまりない、設定ミスを管理するために使用されている - 攻撃者がLANに接続されるだろうと、（S）、彼は同様に、サブネットごとの正しいアドレスを選ぶことができます。
If one router on a link thinks that a LAN should be either broadcast or p2p-over-lan, and the other router has a different opinion, the adjacencies will never form, as specified in Section 4.5. There are no fallbacks at either end to resolve the situation, except by a manual configuration change.
リンク上のルータは、LANがブロードキャストまたはP2PオーバーLANのいずれかであることを考えて、そして他のルータは異なる見解を持っている場合、隣接関係は、セクション4.5で指定されるように、形成することはありません。状況を解決するためにどちらの側にもフォールバックは、手動設定の変更による場合を除いて、ありません。
The authors would like to acknowledge the following individuals (in alphabetical order by last name): Pedro Marques, Christian Martin, Danny McPherson, Ajay Patel, Jeff Parker, Tony Przygienda, Alvaro Retana, and Pekka Savola.
ペドロ・マルケス、クリスチャン・マーティン、ダニー・マクファーソン、アジャイ・パテル、ジェフ・パーカー、トニーPrzygienda、アルバロRetana、およびペッカSavola：著者は、（姓のアルファベット順）以下の個人を確認したいと思います。
[ISO10589] ISO, "Intermediate System to Intermediate System intra-domain routeing information exchange protocol for use in conjunction with the protocol for providing the connectionless-mode network service (ISO 8473)", International Standard 10589:2002, Second Edition, 2002.
[ISO10589] ISO、「（ISO 8473）接続モード・ネットワーク・サービスを提供するためのプロトコルと組み合わせて使用するための情報交換プロトコルをrouteingする中間システム中間システムへのイントラドメイン」、国際標準10589：2002、第2版、2002。
[RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and dual environments", RFC 1195, December 1990.
[RFC1195] Callon、R.は、RFC 1195、1990年12月 "OSIの使用は、TCP / IPやデュアル環境でのルーティングのためIS-IS"。
[RFC1793] Moy, J., "Extending OSPF to Support Demand Circuits", RFC 1793, April 1995.
[RFC1793]モイ、J.、 "オンデマンド・サーキットをサポートするためのOSPFの拡張"、RFC 1793、1995年4月。
[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月。
[RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.
[RFC2328]モイ、J.、 "OSPFバージョン2"、STD 54、RFC 2328、1998年4月。
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, September 2007.
[RFC4861] Narten氏、T.、Nordmarkと、E.、シンプソン、W.、およびH.ソリマン、 "IPバージョン6（IPv6）のための近隣探索"、RFC 4861、2007年9月。
[RFC5308] Hopps, C., "Routing IPv6 with IS-IS", RFC 5308, October 2008.
"IS-ISとルーティングのIPv6" [RFC5308] Hoppsが、C.、RFC 5308、2008年10月。
[RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF for IPv6", RFC 5340, July 2008.
[RFC5340] Coltun、R.、ファーガソン、D.、モイ、J.、およびA. Lindem、 "IPv6のためのOSPF"、RFC 5340、2008年7月。
Contributors
協力者
The following individuals are the authors that contributed to the contents of this document.
以下の個人は、この文書の内容に貢献した作家です。
Acee Lindem Cisco Systems 7025 Kit Creek Road Research Triangle Park, NC 27709 USA EMail: acee@cisco.com
ACEE Lindemシスコシステムズ7025キットクリーク道路リサーチトライアングルパーク、NC 27709 USA Eメール：acee@cisco.com
Jenny Yuan Cisco Systems 225 West Tasman Drive San Jose, CA 95134 USA EMail: jenny@cisco.com
ジェニー元シスコシステムズ225西タスマン・ドライブサンノゼ、CA 95134 USA電子メール：jenny@cisco.com
Russ White Cisco Systems, Inc. 7025 Kit Creek Rd. Research Triangle Park, NC 27709 EMail: riw@cisco.com
ラスホワイトシスコシステムズ株式会社7025キットクリークRdを。リサーチトライアングルパーク、NC 27709 Eメール：riw@cisco.com
Stefano Previdi Cisco Systems, Inc. De Kleetlaan 6A 1831 Diegem - Belgium EMail: sprevidi@cisco.com
ステファノPrevidiシスコシステムズ、株式会社デKleetlaan 6A 1831ディーゲム - ベルギーの電子メール：sprevidi@cisco.com
Editors' Addresses
エディタのアドレス
Naiming Shen Cisco Systems 225 West Tasman Drive San Jose, CA 95134 USA EMail: naiming@cisco.com
Naimingシェンシスコシステムズ225西タスマン・ドライブサンノゼ、CA 95134 USA電子メール：naiming@cisco.com
Alex Zinin Alcatel-Lucent 750D Chai Chee Rd, #06-06 Technopark@ChaiChee Singapore 469004
アレックスジニンアルカテル・ルーセント750DチャイチーRdを、＃06-06テクノ@ ChaiCheeシンガポール469004
EMail: alex.zinin@alcatel-lucent.com
メールアドレス：alex.zinin@alcatel-lucent.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2008).
著作権（C）IETFトラスト（2008）。
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に情報を記述してください。