RFC5309 日本語訳

Network Working Group                                       N. Shen, Ed.
Request for Comments: 5309                                 Cisco Systems
Category: Informational                                    A. Zinin, Ed.
                                                          Alcatel-Lucent
                                                            October 2008

ワーキンググループのN.シン、エドをネットワークでつないでください。コメントのために以下を要求してください。 5309年のシスコシステムズカテゴリ: エド情報のA.ジニン、アルカテル透明な2008年10月

                   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ルーティングの見地から二地点間接続として放送網を扱うために簡単なメカニズムについて説明します。

1.  Introduction

1. 序論

   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.

ポイントツーポイントと放送がリンクのそばで中古のタイプがルーティング・プロトコルを述べる2の支配的な回路である、-、[ISO10589][RFC1195]とOSPF[RFC2328][RFC5340]。 それらは隣人隣接番組を確立することに関して異なって扱われます、氾濫リンク州の情報、トポロジーを表して、Shortest Path First(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操作を提供します。 かかわったどんな代表ルータもありません、そして、リンク州のデータベースにおける、pseudonodeかネットワークLink州Advertisement(LSA)の表現が全くありません。 存在、あって、また、どんな周期的なデータベース同期もありません。 逆に、2つ以上のルータがLANメディアにあると、放送回路の伝統的な視点はネットワークでルーティング情報を減らすでしょう。

Shen & Zinin                 Informational                      [Page 1]

RFC 5309                      P2P over LAN                  October 2008

LAN2008年10月の上のシンとジニン情報[1ページ]のRFC5309P2P

   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.

2つのルータしかLANにないとき、それは2つのルータの間の関係を二地点間回路として扱うより多くの意味になります。 このドキュメントは、リンク州のルーティング・プロトコルが作動するのをこの条件のもとでLANの上の二地点間接続を使用することで許容するためにメカニズムについて説明します。 また、このタイプの回路の上にIPパケットを進めると関連するいくつかの含意について議論します。 私たちは本書ではp2p過剰lan回路にこれについて言及するつもりです。

1.1.  Terminology

1.1. 用語

   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"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはRFC2119[RFC2119]で説明されるように本書では解釈されることであるべきですか?

2.  Motivation

2. 動機

   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台以上のデバイスを扱うことになっていますが、ケースが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. 2つのルータしか物理的なLANにありません。 3. 2つのルータしかバーチャルLAN(vLAN)にありません。

   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(Router/指定されたIntermediate Systemに指定される)選挙を省略できます。 中でOSPFか周期的なComplete Sequence Number Packets(CSNPs)でDRが「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は複数のvLANsへのルータをサブグループに必要とするかもしれません、彼らがこれで異なったコストをIGP隣人に割り当てることができるので。 2つのルータしかいくつかのvLANsにないとき、IGPは二地点間接続のメッシュとしてこのLANを見なすことができます。

Shen & Zinin                 Informational                      [Page 2]

RFC 5309                      P2P over LAN                  October 2008

LAN2008年10月の上のシンとジニン情報[2ページ]のRFC5309P2P

   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アドレス空間貯蓄がわかるためにタイプがLAN、例えばイーサネットを許容するメディアとネットワークタイプの概念を切り離します。 より簡単なネットワークマネージメントと構成には別の利点があります。 IPv6ネットワークの場合に、リンクローカルアドレスがコネを使用した、-、[RFC5308]と[RFC5340]が同じ目的に役立つOSPFv3。

3.  IP Multi-Access Subnets

3. IPマルチアクセスサブネット

   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アドレスを含むでしょう。 このアドレスは、ルータのMAC(メディアAccess Control)がアドレスであることがARP/ノースダコタ(アドレスResolutionプロトコル/隣人ディスカバリー)プロトコルを使用することでわかるのに使用されるでしょう。 事実上、インタフェース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

IPアドレシング体系は管理者がポイントツーポイント接続(IPカプセル化にPPP、SLIP、またはHDLCのように2台のデバイスだけを接続して、プロトコルを使用するリンク)に少しのサブネットも割り当てることができないオプションを含んでいます。 ルータがポイントツーポイント接続に関する次のホップ識別子を必要としないので、これは可能です。

Shen & Zinin                 Informational                      [Page 3]

RFC 5309                      P2P over LAN                  October 2008

LAN2008年10月の上のシンとジニン情報[3ページ]のRFC5309P2P

   (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.

(どんなトランスミッションのための1つの目的地しかもありません)、ソースと目的地としてインタフェースから独立しているIPアドレスを使用できます。 ポイントツーポイント接続に本質的には無数のオプションを使用すると、それは使用される他の目的地に達する純粋に位相的な実体にします。

4.  Point-to-Point Connection over LAN Media

4. LANメディアの上の二地点間接続

   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アドレス問題は、扱われる必要があります。

4.1.  Operation of IS-IS

4.1. 操作、-

   This p2p-over-lan circuit extension for IS-IS is only concerned with
   pure IP routing and forwarding operation.

この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.

回路が物理的に放送1であるので-、プロトコルパケットはこのp2p過剰lan回路へのMACアドレスを必要とします。 それらのパケットがリンクレイヤ観点からの、そうである、-、LANパケット。 リンクレイヤカプセル化に[ISO10589]で定義されたAllISs、AllL1ISsを含むMulti-送付先アドレスと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アドレス(es)、およびp2pを必要とする、-、この回路の上のHello(IIH)は[RFC1195]で定義されるようにIPインターフェース・アドレス(es)を含まなければなりません。 IIHsにIPv4アドレス(es)を含むのは、無数のインタフェースの場合で番号付のインタフェースの場合におけるインタフェースに割り当てられたIPアドレスかインタフェースから独立しているIPアドレスのどちらかです。 IPv6アドレスはリンクローカルのIPv6アドレス(es)[RFC5308]です。

4.2.  Operation of OSPF and OSPFv3

4.2. OSPFとOSPFv3の操作

   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

ここに説明された能力をサポートするOSPFとOSPFv3[RFC5340]ルータは、追加インタフェースがインタフェーストポロジータイプを指定する設定パラメータであるとサポートするべきです。 LAN(すなわち、できた状態で、放送する)インタフェースに関しては、インタフェースはaとして見なされるかもしれません。

Shen & Zinin                 Informational                      [Page 4]

RFC 5309                      P2P over LAN                  October 2008

LAN2008年10月の上のシンとジニン情報[4ページ]のRFC5309P2P

   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].

二地点間インタフェース。 LANに関する両方のルータは、単にAllSPFRoutersマルチキャストグループに加わって、AllSPFRoutersの送付先アドレスがあるすべてのOSPFパケットを送るでしょう。 224.0 .0 AllSPFRoutersがそうである、OSPFのための.5とFF02:、:5 OSPFv3のために。 これは[RFC2328]のセクション8.1と8.2で説明されるように物理的なポイントツーポイント接続の上の操作と同じです。

4.3.  ARP and ND

4.3. ARPとノースダコタ

   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 nexthopは任意ではありません。 IP nexthopアドレスは、隣接しているルータに関する有効なインタフェースか内部のアドレスでなければなりません。 このアドレスはローカルルータによって使用されて、IPパケット推進のためのMACアドレスを得ます。 ARPプロセスは無数のp2p過剰lan回路に使用される内部のIPv4アドレスを決議できなければなりません。 ARP実装(ARP要求のソースアドレスのサブネットが局所界面アドレスに合っているのをチェックする)のために、このチェックは、無数のp2p過剰lan回路に弛緩する必要があります。 misconfiguration検出は、IGPsによって扱われて、セクション4.5で説明されます。 IPv6場合では、ノースダコタはp2p過剰lan回路の上のリンクローカルアドレスのためのMACを決議します。回路はIPv6隣人発見プロセス[RFC4861]の一部です。

4.4.  Other MAC Address Resolution Mechanisms

4.4. 他のマックーアドレス解決メカニズム

   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アドレスを取ることができます。

Shen & Zinin                 Informational                      [Page 5]

RFC 5309                      P2P over LAN                  October 2008

LAN2008年10月の上のシンとジニン情報[5ページ]のRFC5309P2P

4.5.  Detection of Misconfiguration

4.5. Misconfigurationの検出

   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と二地点間回路の違いを純粋に作ることができます。 misconfigurationの早期発見のためにメカニズムを実装するのは重要です。

   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である、こんにちは、パケットは確立した隣接番組のためのシステムIDかルータIDをp2p過剰lan回路の上に合わせないで、パケットを捨てなければなりません。 その上、OSPFである、こんにちは、隣接番組に、抑圧([RFC1793]で説明されるように)が活発である、こんにちは、しばらく、RouterIntervalSecondsについて抑圧を終えなければなりません。 この間隔、隣人隣接番組が、タイムアウトと隣接番組が隣人と共に異なったルータIDで形成されるかもしれないか、こんにちはを望んだ後に、抑圧は再交渉されるかもしれません。 実装は上のイベントの伐採とデバッグ情報を提供するべきです。

5.  Compatibility Considerations

5. 互換性問題

   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セグメントを構成しなければなりません。 ともに、ルータSHOULDは少なくともMACアドレスへのリンクに関するIPアドレスを写像するための上の記載されたメソッドの1つをサポートします。 MACアドレス解決へのIPアドレスの独占メソッドが1つのルータによって使用されるなら、両方のルータは同じメソッドを使用できなければなりません。 さもなければ、リンクは使用される伝統的なIGP LANモデルとの標準のLANリンクとして構成されるべきです。

6.  Scalability and Deployment Considerations

6. スケーラビリティと展開問題

   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でこの拡張子を使用する利点がありますが、人がマルチアクセスネットワークの固有のスケーラビリティ利益を犠牲にするので、複数のvLANsとしてLANをモデル化して、この拡張子を使用するとき、貿易offsがあります。 一般に、それはリンク州のデータベース規模、あふれるパケットの量、およびルート計算オーバーヘッドを増強するでしょう。

   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

説明されたテクニックの展開はIPアドレス用法の見解からめぼしい利益をもたらします: ネットワークマネージメントとルータ構成。 しかしながら、IPのその使用に注意してください、無数

Shen & Zinin                 Informational                      [Page 6]

RFC 5309                      P2P over LAN                  October 2008

LAN2008年10月の上のシンとジニン情報[6ページ]のRFC5309P2P

   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.

すなわち、二地点間LANリンクのためのオプションは、ルータの間の特定のインタフェースを確認できないか、モニターできないので、連続のリンクに出席しているそれらと同じ問題を引き継ぎます。

7.  Security Considerations

7. セキュリティ問題

   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.

このドキュメントが少しの新しい安全保障問題も紹介しない、-、OSPF、ARP、またはノースダコタ。 実装には、セクション4.3で説明されるように弛緩する必要がある'ソースアドレスサブネットチェック'があるかもしれません。 これらはARPを固定するほど多くではなくmisconfigurationsを管理するのにおいて使用されています--攻撃者が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過剰lanのどちらかであるべきであると考えて、もう片方のルータに異なった意見があると、隣接番組は決して形成されないでしょう、セクション4.5で指定されるように。 どちらの終わりにも、手動の構成変更以外に、局面を打開するために、後退は全くありません。

8.  Acknowledgments

8. 承認

   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.

作者は以下の個人(アルファベット順に姓による)を承認したがっています: ペドロ・マルケス、クリスチャンのマーチン、ダニーMcPherson、Ajayパテル、ジェフ・パーカー、トニーPrzygienda、アルバロ・レタナ、およびペッカSavola。

9.  Normative References

9. 引用規格

   [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、「Intermediate Systemイントラドメインrouteing情報交換への中間的Systemは使用のためにコネクションレスなモードネットワーク・サービス(ISO8473)を提供するためのプロトコルに関連して議定書を作ります」、国際規格。10589:2002 Second Edition、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存在、」、RFC1195、12月1990日

   [RFC1793]  Moy, J., "Extending OSPF to Support Demand Circuits", RFC
              1793, April 1995.

[RFC1793] Moy、J.、「要求が回路であるとサポートするためにOSPFを広げています」、RFC1793、1995年4月。

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

[RFC2119] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。

   [RFC2328]  Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.

[RFC2328]Moy、J.、「OSPF、バージョン2インチ、STD54、RFC2328、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)」、RFC4861(2007年9月)。

Shen & Zinin                 Informational                      [Page 7]

RFC 5309                      P2P over LAN                  October 2008

LAN2008年10月の上のシンとジニン情報[7ページ]のRFC5309P2P

   [RFC5308]  Hopps, C., "Routing IPv6 with IS-IS", RFC 5308, October
              2008.

[RFC5308]ホップス、C.、「IPv6を発送する、-、」、RFC5308、10月2008日

   [RFC5340]  Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF
              for IPv6", RFC 5340, July 2008.

[RFC5340] ColtunとR.とファーガソンとD.とMoy、J.とA.Lindem、「IPv6"、RFC5340、2008年7月のためのOSPF。」

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年のAcee Lindemシスコシステムズキットクリーク道路リサーチトライアングル公園、NC27709米国メール: acee@cisco.com

   Jenny Yuan
   Cisco Systems
   225 West Tasman Drive
   San Jose, CA 95134
   USA
   EMail: jenny@cisco.com

西タスマン・Driveジェニー元のシスコシステムズ225カリフォルニア95134サンノゼ(米国)はメールされます: jenny@cisco.com

   Russ White
   Cisco Systems, Inc.
   7025 Kit Creek Rd.
   Research Triangle Park, NC 27709
   EMail: riw@cisco.com

ラス白いシスコシステムズInc.7025キットCreek通り 三角形公園について研究してください、そして、NC 27709はメールされます: riw@cisco.com

   Stefano Previdi
   Cisco Systems, Inc.
   De Kleetlaan 6A
   1831 Diegem - Belgium
   EMail: sprevidi@cisco.com

ステファーノPrevidiシスコシステムズInc.De Kleetlaan 6A1831Diegem--ベルギーメール: sprevidi@cisco.com

Shen & Zinin                 Informational                      [Page 8]

RFC 5309                      P2P over LAN                  October 2008

LAN2008年10月の上のシンとジニン情報[8ページ]のRFC5309P2P

Editors' Addresses

エディタのアドレス

   Naiming Shen
   Cisco Systems
   225 West Tasman Drive
   San Jose, CA  95134
   USA
   EMail: naiming@cisco.com

シンシスコシステムズ225の西タスマンDriveサンノゼ、カリフォルニア95134米国をNaimingして、メールしてください: naiming@cisco.com

   Alex Zinin
   Alcatel-Lucent
   750D Chai Chee Rd, #06-06
   Technopark@ChaiChee
   Singapore 469004

アレックスのジニンのアルカテル透明な750DチャイChee、#06-06 Technopark@ChaiChee 第シンガポール469004

   EMail: alex.zinin@alcatel-lucent.com

メール: alex.zinin@alcatel-lucent.com

Shen & Zinin                 Informational                      [Page 9]

RFC 5309                      P2P over LAN                  October 2008

LAN2008年10月の上のシンとジニン情報[9ページ]のRFC5309P2P

Full Copyright Statement

完全な著作権宣言文

   Copyright (C) The IETF Trust (2008).

IETFが信じる著作権(C)(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.

このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

このドキュメントとここに含まれた情報はその人が代理をするか、または(もしあれば)後援される組織、インターネットの振興発展を目的とする組織、「そのままで」という基礎と貢献者の上で提供していて、IETFはそして、インターネット・エンジニアリング・タスク・フォースがすべての保証を放棄すると信じます、急行である、または暗示していて、他を含んでいて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるということであるかいずれが市場性か特定目的への適合性の黙示的な保証です。

Intellectual Property

知的所有権

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

IETFはどんなIntellectual Property Rightsの正当性か範囲、実装に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するどんな独立している取り組みも作りました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.

IETFはこの規格を実装するのに必要であるかもしれない技術をカバーするかもしれないどんな著作権もその注目していただくどんな利害関係者、特許、特許出願、または他の所有権も招待します。 ietf-ipr@ietf.org のIETFに情報を扱ってください。

Shen & Zinin                 Informational                     [Page 10]

シンとジニンInformationalです。[10ページ]