[要約] 要約：RFC 5309は、リンクステートルーティングプロトコルにおけるLAN上のポイントツーポイント操作に関するガイドラインです。 目的：このRFCの目的は、リンクステートルーティングプロトコルを使用してLAN上でポイントツーポイント操作を実現するための手法とベストプラクティスを提供することです。
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
リンク状態ルーティングプロトコルのLAN上のポイントツーポイント操作
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.
リンク状態ルーティングプロトコルで使用される2つの主要な回路タイプは、ポイントツーポイントで放送されます。隣接を形成し、リンク状態データベースパケットをフラッディングし、回路をトポロジカルに表現するときに、正しい回路タイプを特定することが重要です。このドキュメントでは、ブロードキャストネットワークを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 [ISO10589] [RFC1195]やOSPF [RFC2328] [RFC5340]などのリンク状態ルーティングプロトコルで使用される2つの主要な回路タイプです。それらは、近隣の隣接を確立し、状態情報をリンクすること、トポロジを表すリンクの洪水、および最初の最短経路（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メディアに2つ以上のルーターがある場合、ブロードキャスト回路の従来のビューはネットワーク内のルーティング情報を減らします。
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オーバーラン回路と呼びます。
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:
ブロードキャスト回路は3つ以上のデバイスを処理するためのものですが、物理的または論理的なLANセグメントのいずれかで2つのルーターのみが接続されている場合があります。
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のDRまたは定期的な完全なシーケンス番号パケット（CSNP）による「LSA反射」を使用する必要なく、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.
LANに複数のルーターがある場合でも、ISPはルーターを複数のVLANにサブグループにしたい場合があります。これにより、IGPネイバーに異なるコストを割り当てることができるためです。いくつかの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、たとえばイーサネットを自由にして、IPアドレスのスペースの節約を実現することができます。もう1つの利点は、より単純なネットワーク管理と構成です。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. Next -Hop識別子 - 同じセグメントに接続されている他のルーターがルーターを介してトラフィックを転送する必要がある場合、ルーティングテーブルの対応するルートにはルーターのインターフェイスIPアドレスが含まれます。このアドレスは、ARP / ND（アドレス解像度プロトコル /ネイバーディスカバリー）プロトコルを使用して、ルーターのMac（メディアアクセス制御）アドレスを見つけるために使用されます。効果的に、インターフェイス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つのデバイスのみを接続し、IPカプセル化のためにPPP、スリップ、HDLCなどのプロトコルを使用するリンク）が含まれています。これは、ルーターがポイントツーポイントリンクでネクストホップ識別子を必要としないため（伝送には1つの宛先のみ）、インターフェイスに依存しない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アドレス解像度とNexthop IPアドレスの問題に対処する必要があります。
This p2p-over-lan circuit extension for IS-IS is only concerned with pure IP routing and forwarding operation.
IS-ISのこのP2Pオーバーラン回路拡張は、純粋な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オーバーラン回路のMACアドレスが必要です。リンク層の観点から、これらのパケットはLANパケットです。[ISO10589]で定義されているAlliss、Alll1iss、およびAlll2issを含む多留置アドレスは、リンク層カプセル化に使用できます。アリスの使用をお勧めします。
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アドレスが必要である必要があり、この回路上のP2P IS-IS Hello（IIH）には、[RFC1195]で定義されているIPインターフェイスアドレス（ES）を含める必要があります。IIHSに含まれるIPv4アドレス（ES）は、番号付きインターフェイスの場合、インターフェイスに割り当てられたIPアドレスまたは非仮定インターフェイスの場合のインターフェイスに依存しないIPアドレスのいずれかです。IPv6アドレスは、Link-Local IPv6アドレス（ES）[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マルチキャストグループに参加し、すべてのOSPFパケットをAllSPFRouterの宛先アドレスで送信します。AllSPFRouterは、OSPFの場合は224.0.0.5、FF02 :: 5はOSPFV3の場合は5です。これは、[RFC2328]のセクション8.1および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オーバーラン回路をアウトバウンドインターフェイスとして使用するルートのIP Nexthopはオプションではありません。IP Nexthopアドレスは、隣接するルーターの有効なインターフェイスまたは内部アドレスでなければなりません。このアドレスは、ローカルルーターによって使用され、IPパケット転送のMACアドレスを取得します。ARPプロセスは、非仮定されていないP2Pオーバーラン回路に使用される内部IPv4アドレスを解決できる必要があります。ARP実装（ARPリクエストのソースアドレスのサブネットがローカルインターフェイスアドレスと一致することをチェックする）の場合、このチェックは、数え切れないほどのP2Pオーバーラン回路でリラックスする必要があります。ミス構成検出はIGPSによって処理され、セクション4.5で説明されています。IPv6の場合、NDは、IPv6隣接発見プロセス[RFC4861]の一部であるP2Pオーバーラン回路のリンクローカルアドレスの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オーバーラン回路は数本のリンクとして使用されますが、IPパケット転送には他のMACアドレス解像度メカニズムが必要です。たとえば、リンク状態IGPがこのP2Pオーバーランリンクで構成されていない場合、またはセクション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とポイントツーポイント回路の違いは、純粋に構成によって作成できます。誤解の早期検出のためのメカニズムを実装することが重要です。
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 Helloパケットを受信する場合、ルーターは着信パケットを破棄する必要があります。回路がLANタイプであり、ポイントツーポイントのハローパケットを受信する場合、着信パケットを破棄する必要があります。着信ハローパケットのシステムIDまたはルーターIDが、P2Pオーバーラン回路上の確立された隣接性のシステムIDまたはルーターIDと一致しない場合、パケットを破棄する必要があります。さらに、OSPF Hello Septression（[RFC1793]で説明されている）が隣接するためにアクティブな場合、Hello Septressionは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オーバーラン拡張をサポートする必要があり、両方のランセグメントをP2Pオーバーラン回路として構成して、動作を成功させる必要があります。両方のルーターは、MACアドレスへのリンク上のIPアドレスをマッピングするための上記のリストされた方法の少なくとも1つをサポートする必要があります。IPアドレスの独自の方法がMACアドレス解像度を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をモデル化し、マルチアクセスの固有のスケーラビリティ利点を犠牲にするため、この拡張機能を使用する場合、トレードオフがありますネットワーク。一般に、リンク状態のデータベースサイズ、浸水したパケットの量、およびルート計算のオーバーヘッドが増加します。
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 Numbumberedオプションを使用すると、シリアルリンクに存在する問題、つまりルーター間の特定のインターフェイスを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に取り付けられている場合、サブネットごとの正しいアドレスを選ぶこともできます。
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.
リンク上の1つのルーターが、LANを放送またはP2Pオーバーランのいずれかであると考え、もう1つのルーターが異なる意見を持っている場合、セクション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.
著者は、ペドロ・マルケス、クリスチャン・マーティン、ダニー・マクファーソン、アジャイ・パテル、ジェフ・パーカー、トニー・プリジエンダ、アルバロ・レタナ、ペッカ・サヴォラ：次の個人（姓によるアルファベット順）を認めたいと考えています。
[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、「Connectionless-Mode Network Service（ISO 8473）を提供するためのプロトコルと併せて使用するための情報交換プロトコルの中間システムへの中間システム（ISO 8473）を提供するための情報交換プロトコル」、International Standard 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。、「TCP/IPおよびデュアル環境でのルーティングのためのOSI IS-I-ISの使用」、RFC 1195、1990年12月。
[RFC1793] Moy, J., "Extending OSPF to Support Demand Circuits", RFC 1793, April 1995.
[RFC1793] Moy、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] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、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月。
[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.、Simpson、W。、およびH. Soliman、「IPバージョン6（IPv6）の近隣発見」、RFC 4861、2007年9月。
[RFC5308] Hopps, C., "Routing IPv6 with IS-IS", RFC 5308, October 2008.
[RFC5308] HOPPS、C。、「IS-ISを使用したIPv6をルーティング」、RFC 5308、2008年10月。
[RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF for IPv6", RFC 5340, July 2008.
[RFC5340] Coltun、R.、Ferguson、D.、Moy、J。、およびA. Lindem、「OSPF for IPv6」、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
エースリンデムシスコシステム7025キットクリークロードリサーチトライアングルパーク、NC 27709 USAメール：acee@cisco.com
Jenny Yuan Cisco Systems 225 West Tasman Drive San Jose, CA 95134 USA EMail: jenny@cisco.com
Jenny Yuan Cisco Systems 225 West Tasman Drive San Jose、CA 95134 USAメール：jenny@cisco.com
Russ White Cisco Systems, Inc. 7025 Kit Creek Rd. Research Triangle Park, NC 27709 EMail: riw@cisco.com
Russ White Cisco Systems、Inc。7025 Kit Creek Rd。研究トライアングルパーク、NC 27709メール：riw@cisco.com
Stefano Previdi Cisco Systems, Inc. De Kleetlaan 6A 1831 Diegem - Belgium EMail: sprevidi@cisco.com
Stefano Previdi Cisco Systems、Inc。de Kleetlaan 6a 1831 Diegem -belgiumメール：sprevidi@cisco.com
Editors' Addresses
編集者のアドレス
Naiming Shen Cisco Systems 225 West Tasman Drive San Jose, CA 95134 USA EMail: naiming@cisco.com
Naiming Shen Cisco Systems 225 West Tasman Drive San Jose、CA 95134 USAメール：naiming@cisco.com
Alex Zinin Alcatel-Lucent 750D Chai Chee Rd, #06-06 Technopark@ChaiChee Singapore 469004
Alex Zinin Alcatel-Lucent 750d Chai Chee Rd、＃06-06 Technopark@Chaichee Singapore 469004
EMail: alex.zinin@alcatel-lucent.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2008).
著作権（c）The IETF Trust（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.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供され、貢献者、彼/彼女が代表する組織（もしあれば）、インターネット協会、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への情報をお問い合わせください。