RFC4817 日本語訳

Network Working Group                                        M. Townsley
Request for Comments: 4817                                  C. Pignataro
Category: Standards Track                                     S. Wainner
                                                           Cisco Systems
                                                                T. Seely
                                                           Sprint Nextel
                                                                J. Young
                                                              March 2007

Townsleyがコメントのために要求するワーキンググループM.をネットワークでつないでください: 4817年のC.Pignataroカテゴリ: 2007年の標準化過程S.WainnerシスコシステムズのT.シーリの短距離競走ネクステルのJ.ヤングの行進

    Encapsulation of MPLS over Layer 2 Tunneling Protocol Version 3

層2のトンネリングプロトコルバージョン3の上のMPLSのカプセル化

Status of This Memo

このメモの状態

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。

Copyright Notice

版権情報

   Copyright (C) The IETF Trust (2007).

IETFが信じる著作権(C)(2007)。

Abstract

要約

   The Layer 2 Tunneling Protocol, Version 3 (L2TPv3) defines a protocol
   for tunneling a variety of payload types over IP networks.  This
   document defines how to carry an MPLS label stack and its payload
   over the L2TPv3 data encapsulation.  This enables an application that
   traditionally requires an MPLS-enabled core network, to utilize an
   L2TPv3 encapsulation over an IP network instead.

Layer2Tunnelingプロトコル、バージョン3(L2TPv3)はIPネットワークの上でさまざまなペイロードタイプにトンネルを堀るためにプロトコルを定義します。 このドキュメントはMPLSラベルスタックとそのペイロードをL2TPv3データカプセル化の上まで運ぶ方法を定義します。 これは代わりにIPネットワークの上でL2TPv3カプセル化を利用するためにMPLSによって可能にされたコアネットワークを伝統的に必要とするアプリケーションを可能にします。

Townsley, et al.            Standards Track                     [Page 1]

RFC 4817                    MPLS over L2TPv3                  March 2007

Townsley、他 L2TPv3 March 2007の上の標準化過程[1ページ]RFC4817MPLS

Table of Contents

目次

   1. Introduction ....................................................2
      1.1. Specification of Requirements ..............................2
   2. MPLS over L2TPv3 Encoding .......................................2
   3. Assigning the L2TPv3 Session ID and Cookie ......................4
   4. Applicability ...................................................4
   5. Congestion Considerations .......................................6
   6. Security Considerations .........................................6
      6.1. In the Absence of IPsec ....................................7
      6.2. Context Validation .........................................7
      6.3. Securing the Tunnel with IPsec .............................8
   7. Acknowledgements ................................................9
   8. References .....................................................10
      8.1. Normative References ......................................10
      8.2. Informative References ....................................10

1. 序論…2 1.1. 要件の仕様…2 2. L2TPv3コード化の上のMPLS…2 3. L2TPv3Session IDとクッキーを割り当てます…4 4. 適用性…4 5. 混雑問題…6 6. セキュリティ問題…6 6.1. IPsecが不在のとき…7 6.2. 文脈合法化…7 6.3. IPsecと共にトンネルを固定します…8 7. 承認…9 8. 参照…10 8.1. 標準の参照…10 8.2. 有益な参照…10

1.  Introduction

1. 序論

   This document defines how to encapsulate an MPLS label stack and its
   payload inside the L2TPv3 tunnel payload.  After defining the MPLS
   over L2TPv3 encapsulation procedure, other MPLS over IP encapsulation
   options, including IP, Generic Routing Encapsulation (GRE), and IPsec
   are discussed in context with MPLS over L2TPv3 in an Applicability
   section.  This document only describes encapsulation and does not
   concern itself with all possible MPLS-based applications that may be
   enabled over L2TPv3.

このドキュメントはL2TPv3トンネルペイロードの中にMPLSラベルスタックとそのペイロードをカプセルに入れる方法を定義します。 L2TPv3カプセル化手順の上でMPLSを定義した後に、Applicability部で状況内においてIP、Genericルート設定Encapsulation(GRE)を含むIPカプセル化オプションの上の他のMPLSとIPsecについてL2TPv3の上のMPLSと議論します。 このドキュメントだけが、カプセル化について説明して、L2TPv3の上で可能にされるかもしれないすべての可能なMPLSベースのアプリケーションに携わりません。

1.1.  Specification of Requirements

1.1. 要件の仕様

   In this document, several words are used to signify the requirements
   of the specification.  These words are often capitalized.  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 [RFC2119].

本書では、いくつかの単語が、仕様の要件を意味するのに使用されます。 これらの単語はしばしば大文字で書かれます。 キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTは[RFC2119]で説明されるように本書では解釈されることであるべきですか?

2.  MPLS over L2TPv3 Encoding

2. L2TPv3コード化の上のMPLS

   MPLS over L2TPv3 allows tunneling of an MPLS stack [RFC3032] and its
   payload over an IP network, utilizing the L2TPv3 encapsulation
   defined in [RFC3931].  The MPLS Label Stack and payload are carried
   in their entirety following IP (either IPv4 or IPv6) and L2TPv3
   headers.

L2TPv3の上のMPLSはIPネットワークの上にMPLSスタック[RFC3032]のトンネリングとそのペイロードを許容します、[RFC3931]で定義されたL2TPv3カプセル化を利用して。 IP(IPv4かIPv6のどちらか)とL2TPv3ヘッダーに続いて、MPLS Label Stackとペイロードは全体として運ばれます。

Townsley, et al.            Standards Track                     [Page 2]

RFC 4817                    MPLS over L2TPv3                  March 2007

Townsley、他 L2TPv3 March 2007の上の標準化過程[2ページ]RFC4817MPLS

                          +-+-+-+-+-+-+-+-+-+-+
                          |        IP         |
                          +-+-+-+-+-+-+-+-+-+-+
                          |      L2TPv3       |
                          +-+-+-+-+-+-+-+-+-+-+
                          | MPLS Label Stack  |
                          +-+-+-+-+-+-+-+-+-+-+
                          |    MPLS Payload   |
                          +-+-+-+-+-+-+-+-+-+-+

+-+-+-+-+-+-+-+-+-+-+ | IP| +-+-+-+-+-+-+-+-+-+-+ | L2TPv3| +-+-+-+-+-+-+-+-+-+-+ | MPLSラベルスタック| +-+-+-+-+-+-+-+-+-+-+ | MPLS有効搭載量| +-+-+-+-+-+-+-+-+-+-+

                 Figure 2.1 MPLS Packet over L2TPv3/IP

図2.1 L2TPv3/IPの上のMPLSパケット

   The L2TPv3 encapsulation carrying a single MPLS label stack entry is
   as follows:

単一のMPLSラベルスタックエントリーを運ぶL2TPv3カプセル化は以下の通りです:

  0                   1                   2                   3
  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                          Session ID                           |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |               Cookie (optional, maximum 64 bits)...
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                               ...                               |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Label
 |                Label                  | Exp |S|       TTL     | Stack
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Entry

0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | セッションID| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | クッキー(任意の、そして、最大の64ビット)… +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... | +++++++++++++++++++++++++++++++++ラベル| ラベル| Exp|S| TTL| スタック+++++++++++++++++++++++++++++++++エントリー

               Figure 2.2 MPLS over L2TPv3 encapsulation

図2.2 L2TPv3カプセル化の上のMPLS

   When encapsulating MPLS over L2TPv3, the L2TPv3 L2-Specific Sublayer
   MAY be present.  It is generally not present; hence, it is not
   included in Figure 2.2.  The L2TPv3 Session ID MUST be present.  The
   Cookie MAY be present.

L2TPv3の上でMPLSをカプセル化するとき、L2TPv3 L2特有のSublayerは存在しているかもしれません。 一般に、それは存在していません。 したがって、それは図2.2に含まれていません。 L2TPv3 Session IDは存在していなければなりません。 Cookieは存在しているかもしれません。

   Session ID

セッションID

      The L2TPv3 Session ID is a 32-bit identifier field locally
      selected as a lookup key for the context of an L2TP Session.  An
      L2TP Session contains necessary context for processing a received
      L2TP packet.  At a minimum, such context contains whether the
      Cookie (see description below) is present, the value it was
      assigned, the presence and type of an L2TPv3 L2-Specific Sublayer,
      as well as what type of tunneled encapsulation follows (i.e.,
      Frame Relay, Ethernet, MPLS, etc.)

L2TPv3 Session IDはL2TP Sessionの文脈に、主要なルックアップとして局所的に選定される32ビットの識別子分野です。 L2TP Sessionは容認されたL2TPパケットを処理するための必要な文脈を含んでいます。 最小限では、そのような文脈はL2TPv3 L2特有のSublayerのCookie(以下での記述を見る)が存在しているか、そして、それが割り当てられた値、存在、およびタイプを含んでいます、どんなタイプのトンネルを堀られたカプセル化が続くかと同様に(すなわち、Frame Relay、イーサネット、MPLSなど)

Townsley, et al.            Standards Track                     [Page 3]

RFC 4817                    MPLS over L2TPv3                  March 2007

Townsley、他 L2TPv3 March 2007の上の標準化過程[3ページ]RFC4817MPLS

   Cookie

クッキー

      The L2TPv3 Cookie field contains a variable-length (maximum 64
      bits), randomly assigned value.  It is intended to provide an
      additional level of guarantee that a data packet has been directed
      to the proper L2TP session by the Session ID.  While the Session
      ID may be encoded and assigned any value (perhaps optimizing for
      local lookup capabilities, redirection in a distributed forwarding
      architecture, etc.), the Cookie MUST be selected as a
      cryptographically random value [RFC4086], with the added
      restriction that it not be the same as a recently used value for a
      given Session ID.  A well-chosen Cookie will prevent inadvertent
      misdirection of a stray packet containing a recently reused
      Session ID, a Session ID that is subject to packet corruption, and
      protection against some specific malicious packet insertion
      attacks, as described in more detail in Section 4 of this
      document.

L2TPv3 Cookie分野は可変長(最大の64ビット)の、そして、手当たりしだいに割り当てられた値を含んでいます。 データ・パケットが適切なL2TPセッションまでSession IDによって指示されたのが追加レベルの保証を提供することを意図します。 Session IDはコード化されて、どんな値も割り当てられるかもしれない間(地方のルックアップ能力、分配された推進アーキテクチャのリダイレクションなどのために恐らく最適化して)、Cookieはaとして暗号で無作為の状態で選定されなければなりません。それが与えられたSession IDへの最近中古の値と同じでないという加えられた制限で[RFC4086]を評価してください。 適切なCookieはいくつかの特定の悪意があるパケット挿入攻撃に対するパケット不正に受けることがある最近再利用されたSession Session ID(ID)、および保護を含む迷っているパケットの不注意な誤まった指示を防ぐでしょう、さらに詳細にこのドキュメントのセクション4で説明されるように。

   Label Stack Entry

ラベルスタックエントリー

      An MPLS label stack entry as defined in [RFC3032].

MPLSは[RFC3032]で定義されるようにスタックエントリーをラベルします。

   The optional L2-Specific Sublayer (defined in [RFC3931]) is generally
   not present for MPLS over L2TPv3.

一般に、任意のL2特有のSublayer([RFC3931]では、定義される)はL2TPv3の上のMPLSのために存在していません。

   Generic IP encapsulation procedures, such as fragmentation and MTU
   considerations, handling of Time to Live (TTL), EXP, and
   Differentiated Services Code Point (DSCP) bits, etc. are the same as
   the "Common Procedures" for IP encapsulation of MPLS defined in
   Section 5 of [RFC4023] and are not reiterated here.

断片化やMTU問題などのジェネリックIPカプセル化手順、Live(TTL)、EXP、およびDifferentiated Services Code Point(DSCP)ビットへのTimeの取り扱いは、[RFC4023]のセクション5で定義されたMPLSのIPカプセル化のための「常法」と同じであり、ここで繰り返されません。

3.  Assigning the L2TPv3 Session ID and Cookie

3. L2TPv3Session IDとクッキーを割り当てます。

   Much like an MPLS label, the L2TPv3 Session ID and Cookie must be
   selected and exchanged between participating nodes before L2TPv3 can
   operate.  These values may be configured manually, or distributed via
   a signaling protocol.  This document concerns itself only with the
   encapsulation of MPLS over L2TPv3; thus, the particular method of
   assigning the Session ID and Cookie (if present) is out of scope.

MPLSラベルのように、L2TPv3が作動できる前に、参加ノードの間でL2TPv3 Session IDとCookieを選択して、交換しなければなりません。 これらの値は、シグナリングプロトコルで手動で構成されるか、または分配されるかもしれません。 このドキュメントはL2TPv3の上で単にMPLSのカプセル化でタッチしています。 したがって、範囲の外にSession IDとCookie(存在しているなら)を割り当てる特定のメソッドがあります。

4.  Applicability

4. 適用性

   The methods defined in [RFC4023], [MPLS-IPSEC], and this document all
   describe methods for carrying MPLS over an IP network.  Cases where
   MPLS over L2TPv3 is comparable to other alternatives are discussed in
   this section.

[RFC4023]、[MPLS-IPSEC]、およびこのドキュメントで定義されたメソッドはすべて、IPネットワークの上までMPLSを運ぶためのメソッドを説明します。 このセクションでL2TPv3の上のMPLSが他の代替手段に匹敵しているケースについて議論します。

Townsley, et al.            Standards Track                     [Page 4]

RFC 4817                    MPLS over L2TPv3                  March 2007

Townsley、他 L2TPv3 March 2007の上の標準化過程[4ページ]RFC4817MPLS

   It is generally simpler to have one's border routers refuse to accept
   an MPLS packet than to configure a router to refuse to accept certain
   MPLS packets carried in IP or GRE to or from certain IP sources or
   destinations.  Thus, the use of IP or GRE to carry MPLS packets
   increases the likelihood that an MPLS label-spoofing attack will
   succeed.  L2TPv3 provides an additional level of protection against
   packet spoofing before allowing a packet to enter a Virtual Private
   Network (VPN) (much like IPsec provides an additional level of
   protection at a Provider Edge (PE) router rather than relying on
   Access Control List (ACL) filters).  Checking the value of the L2TPv3
   Cookie is similar to any sort of ACL that inspects the contents of a
   packet header, except that we give ourselves the luxury of "seeding"
   the L2TPv3 header with a value that is very difficult to spoof.

一般に、人の境界ルータにMPLSパケットを受け入れるのを拒否させるのは、IPかGREで目的地か確信しているIPソースか目的地から運ばれたあるMPLSパケットを受け入れるのを拒否するためにルータを構成するより簡単です。 したがって、MPLSパケットを運ぶIPかGREの使用はラベルを偽造するMPLS攻撃が成功する可能性を広げます。 L2TPv3はパケットがVirtual兵士のNetwork(VPN)に入るのを許可する前に、パケットスプーフィングに対する追加レベルの保護を提供します(IPsecがAccess Control List(ACL)フィルタを当てにするよりProvider Edge(PE)ルータで追加レベルの保護をむしろ提供するように)。 L2TPv3 Cookieの値をチェックするのはパケットのヘッダーのコンテンツを点検するACLのどんな種類とも同様です、私たちがL2TPv3ヘッダーの偽造するのが非常に難しい値で「種子」であるぜいたくを自分達に与えるのを除いて。

   MPLS over L2TPv3 may be advantageous compared to [RFC4023], if:

[RFC4023]と比べて、L2TPv3の上のMPLSが有利であるかもしれない、:

      Two routers are already "adjacent" over an L2TPv3 tunnel
      established for some other reason, and wish to exchange MPLS
      packets over that adjacency.

2つのルータがある他の理由で確立されたL2TPv3トンネル、およびその隣接番組の上とMPLSパケットを交換するという願望の上で既に「隣接しています」。

      Implementation considerations dictate the use of MPLS over L2TPv3.
      For example, a hardware device may be able to take advantage of
      the L2TPv3 encapsulation for faster or distributed processing.

実装問題はL2TPv3の上でMPLSの使用を決めます。 例えば、デバイスが、より速くL2TPv3カプセル化を利用できるかもしれないハードウェアか分散処理。

      Packet spoofing and insertion, service integrity and resource
      protection are of concern, especially given the fact that an IP
      tunnel potentially exposes the router to rogue or inappropriate IP
      packets from unknown or untrusted sources.  IP Access Control
      Lists (ACLs) and numbering methods may be used to protect the PE
      routers from rogue IP sources, but may be subject to error and
      cumbersome to maintain at all edge points at all times.  The
      L2TPv3 Cookie provides a simple means of validating the source of
      an L2TPv3 packet before allowing processing to continue.  This
      validation offers an additional level of protection over and above
      IP ACLs, and a validation that the Session ID was not corrupted in
      transit or suffered an internal lookup error upon receipt and
      processing.  If the Cookie value is assigned and distributed
      automatically, it is less subject to operator error, and if
      selected in a cryptographically random nature, less subject to
      blind guesses than source IP addresses (in the event that a hacker
      can insert packets within a core network).

パケットスプーフィング、挿入、サービス保全、およびリソース保護は重要です、IPトンネルが未知の、または、信頼されていないソースから凶暴であるか不適当なIPパケットにルータを潜在的に暴露するという事実を特に考えて。 IP Access Control Lists(ACLs)と付番メソッドは、縁のポイントを全くいつも維持するために凶暴なIPソースからPEルータを保護するのに使用されるかもしれませんが、誤りを被りやすくて、扱いにくいかもしれません。 L2TPv3 Cookieは処理が続くのを許容する前にL2TPv3パケットの源を有効にする簡潔な方法を提供します。 IPとIPの上の追加レベルの保護にACLsを提供して、この合法化はSession IDがトランジットで崩壊しなかったか、または内部のルックアップ誤りを受けた合法化に領収書と処理を提供します。 Cookie値が自動的に割り当てられて、分配されるなら、中でオペレータエラーを条件として選択されるならより少ない、暗号で、ランダム性、あて推量を条件として、ソースIPアドレス(ハッカーがコアネットワークの中でパケットを挿入できるなら)より少ないです。

   (The first two of the above applicability statements were adopted
   from [RFC4023].)

(2つの最初の上の適用性証明が[RFC4023]から採用されました。)

   In summary, L2TPv3 can provide a balance between the limited security
   against IP spoofing attacks offered by [RFC4023] vs. the greater
   security and associated operational and processing overhead offered

概要では、L2TPv3は、よりすばらしいセキュリティに対して[RFC4023]によって提供されて、操作上で関連づけられたIPスプーフィング攻撃とオーバーヘッドが提供した処理に対して限られたセキュリティの間の残額を提供できます。

Townsley, et al.            Standards Track                     [Page 5]

RFC 4817                    MPLS over L2TPv3                  March 2007

Townsley、他 L2TPv3 March 2007の上の標準化過程[5ページ]RFC4817MPLS

   by [MPLS-IPSEC].  Further, MPLS over L2TPv3 may be faster in some
   hardware, particularly if that hardware is already optimized to
   classify incoming L2TPv3 packets carrying IP framed in a variety of
   ways.  For example, IP encapsulated by High-Level Data Link Control
   (HDLC) or Frame Relay over L2TPv3 may be equivalent in complexity to
   IP encapsulated by MPLS over L2TPv3.

[MPLS-IPSEC]で。 L2TPv3の上のMPLSは何らかのハードウェアでさらに、速いかもしれません、特にそのハードウェアがさまざまな方法で縁どられたIPを運ぶ入って来るL2TPv3パケットを分類するために既に最適化されるなら。 例えば、L2TPv3の上のHigh-レベルData Link Control(HDLC)かFrame Relayによってカプセル化されたIPは複雑さでL2TPv3の上でMPLSによってカプセル化されたIPに同等であるかもしれません。

5.  Congestion Considerations

5. 混雑問題

   This document specifies an encapsulation method for MPLS inside the
   L2TPv3 tunnel payload.  MPLS can carry a number of different
   protocols as payloads.  When an MPLS/L2TPv3 flow carries IP-based
   traffic, the aggregate traffic is assumed to be TCP friendly due to
   the congestion control mechanisms used by the payload traffic.
   Packet loss will trigger the necessary reduction in offered load, and
   no additional congestion avoidance action is necessary.

このドキュメントはL2TPv3トンネルペイロードにおけるMPLSにカプセル化メソッドを指定します。 MPLSはペイロードとして多くの異なったプロトコルを運ぶことができます。 MPLS/L2TPv3流動がIPベースのトラフィックを運ぶとき、集合トラフィックはペイロードトラフィックによって使用される混雑制御機構のために好意的なTCPであると思われます。 パケット損失は提供された負荷の必要な減少の引き金となるでしょう、そして、どんな追加輻輳回避動作も必要ではありません。

   When an MPLS/L2TPv3 flow carries payload traffic that is not known to
   be TCP friendly and the flow runs across an unprovisioned path that
   could potentially become congested, the application that uses the
   encapsulation specified in this document MUST employ additional
   mechanisms to ensure that the offered load is reduced appropriately
   during periods of congestion.  The MPLS/L2TPv3 flow should not exceed
   the average bandwidth that a TCP flow across the same network path
   and experiencing the same network conditions would achieve, measured
   on a reasonable timescale.  This is not necessary in the case of an
   unprovisioned path through an over-provisioned network, where the
   potential for congestion is avoided through the over-provisioning of
   the network.

MPLS/L2TPv3流動がTCP好意的であることは知られないペイロードトラフィックを運んで、流れが潜在的に混雑するようになることができた非食糧を供給された経路の向こう側に稼働するとき、本書では指定されたカプセル化を使用するアプリケーションは、提供された負荷が混雑の期間適切に減少するのを保証するのに追加メカニズムを使わなければなりません。 MPLS/L2TPv3流動は同じネットワーク経路と同じネットワーク状態を経験することの向こう側のTCP流動が実現する平均した帯域幅を超えるべきではありません、妥当なスケールで測定されて。 これは食糧を供給され過ぎるネットワークを通した非食糧を供給された経路の場合で必要ではありません。そこでは、混雑の可能性がネットワークの食糧を供給し過ぎることで避けられます。

   The comparison to TCP cannot be specified exactly but is intended as
   an "order-of-magnitude" comparison in timescale and throughput.  The
   timescale on which TCP throughput is measured is the roundtrip time
   of the connection.  In essence, this requirement states that it is
   not acceptable to deploy an application using the encapsulation
   specified in this document on the best-effort Internet, which
   consumes bandwidth arbitrarily and does not compete fairly with TCP
   within an order of magnitude.  One method of determining an
   acceptable bandwidth is described in [RFC3448].  Other methods exist,
   but are outside the scope of this document.

TCPとの比較は、まさに指定できませんが、スケールとスループットにおける1「桁」比較として意図します。 TCPスループットが測定されるスケールは接続の往復の時間です。 本質では、この要件は、アプリケーションを配布するのが本書では1桁以内で任意に帯域幅を消費して、TCPと公正に競争しないベストエフォート型インターネットで指定されたカプセル化を使用することで許容できないと述べます。 許容できる帯域幅を決定する1つのメソッドが[RFC3448]で説明されます。 他のメソッドは、存在していますが、このドキュメントの範囲の外にあります。

6.  Security Considerations

6. セキュリティ問題

   There are three main concerns when transporting MPLS-labeled traffic
   between PEs using IP tunnels.  The first is the possibility that a
   third party may insert packets into a packet stream between two PEs.
   The second is that a third party might view the packet stream between
   two PEs.  The third is that a third party may alter packets in a

IPトンネルを使用することでPEsの間のMPLSによってラベルされたトラフィックを輸送するとき、3回の主な関心事があります。 1番目は第三者が2PEsの間のパケットストリームにパケットを挿入するかもしれない可能性です。 2番目は第三者が2PEsの間のパケットストリームを見るかもしれないということです。 3番目は第三者がaでパケットを変更するかもしれないということです。

Townsley, et al.            Standards Track                     [Page 6]

RFC 4817                    MPLS over L2TPv3                  March 2007

Townsley、他 L2TPv3 March 2007の上の標準化過程[6ページ]RFC4817MPLS

   stream between two PEs.  The security requirements of the
   applications whose traffic is being sent through the tunnel
   characterizes how significant these issues are.  Operators may use
   multiple methods to mitigate the risk, including access lists,
   authentication, encryption, and context validation.  Operators should
   consider the cost to mitigate the risk.

2PEsの間を流れてください。 トラフィックがトンネルを通して送るのが重要な状態でどのようにを特徴付けるかということであるアプリケーションには、これらの問題があるというセキュリティ要件。 オペレータはアクセスリスト、認証、暗号化、および文脈合法化を含む危険を緩和する複数のメソッドを使用するかもしれません。 オペレータは、費用が危険を緩和すると考えるべきです。

   Security is also discussed as part of the applicability discussion in
   Section 4 of this document.

また、セキュリティは適用性議論の一部としてこのドキュメントのセクション4で議論されています。

6.1.  In the Absence of IPsec

6.1. IPsecが不在のとき

   If the tunnels are not secured with IPsec, then some other method
   should be used to ensure that packets are decapsulated and processed
   by the tunnel tail only if those packets were encapsulated by the
   tunnel head.  If the tunnel lies entirely within a single
   administrative domain, address filtering at the boundaries can be
   used to ensure that no packet with the IP source address of a tunnel
   endpoint or with the IP destination address of a tunnel endpoint can
   enter the domain from outside.

それらのパケットがトンネルヘッドによってカプセルに入れられてだけ、トンネルがIPsecと共に固定されていないなら、ある他のメソッドは、パケットがdecapsulatedされるのを保証するのに使用されて、トンネルテールによって処理されます。 トンネルがただ一つの管理ドメインに完全に属すなら、トンネル終点のIPソースアドレスかトンネル終点の受信者IPアドレスがあるどんなパケットも外部からドメインに入ることができないのを保証するのに境界のアドレスフィルタリングを使用できます。

   However, when the tunnel head and the tunnel tail are not in the same
   administrative domain, this may become difficult, and filtering based
   on the destination address can even become impossible if the packets
   must traverse the public Internet.

しかしながら、トンネルヘッドとトンネルテールが同じ管理ドメインにないとき、これは難しくなるかもしれません、そして、パケットが公共のインターネットを横断しなければならないなら、送付先アドレスに基づくフィルタリングは不可能になることさえできます。

   Sometimes, only source address filtering (but not destination address
   filtering) is done at the boundaries of an administrative domain.  If
   this is the case, the filtering does not provide effective protection
   at all unless the decapsulator of MPLS over L2TPv3 validates the IP
   source address of the packet.

管理ドメインの境界でソースアドレスフィルタリング(どんな送付先アドレスもフィルターにかけられないのを除いて)だけをします。 これがそうであり、L2TPv3の上のMPLSのdecapsulatorがパケットのIPソースアドレスを有効にしない場合、フィルタリングは全く有効保護を提供しません。

   Additionally, the "Data Packet Spoofing" considerations in Section
   8.2 of [RFC3931] and the "Context Validation" considerations in
   Section 6.2 of this document apply.  Those two sections highlight the
   benefits of the L2TPv3 Cookie.

さらに、[RFC3931]のセクション8.2の「データ・パケットスプーフィング」問題とこのドキュメントのセクション6.2の「文脈合法化」問題は適用されます。 それらの2つのセクションがL2TPv3 Cookieの利益を強調します。

6.2.  Context Validation

6.2. 文脈合法化

   The L2TPv3 Cookie does not provide protection via encryption.
   However, when used with a sufficiently random, 64-bit value that is
   kept secret from an off-path attacker, the L2TPv3 Cookie may be used
   as a simple yet effective packet source authentication check which is
   quite resistant to brute force packet-spoofing attacks.  It also
   alleviates the need to rely solely on filter lists based on a list of
   valid source IP addresses, and thwarts attacks that could benefit by
   spoofing a permitted source IP address.  The L2TPv3 Cookie provides a
   means of validating the currently assigned Session ID on the packet

L2TPv3 Cookieは暗号化で保護を提供しません。 しかしながら、オフ経路攻撃者から秘密にされる十分無作為の、そして、64ビットの値と共に使用されると、L2TPv3 Cookieは力任せのパケットを偽造する攻撃にかなり抵抗力がある簡単な、しかし、有効なパケットソース認証チェックとして使用されるかもしれません。 それは、また、唯一有効なソースIPアドレスのリストに基づくフィルタリストを当てにする必要性を軽減して、受入れられたソースIPにアドレスを偽造することによって利益を得ることができるだろう攻撃を阻みます。 L2TPv3 Cookieはパケットの上で現在割り当てられたSession IDを有効にする手段を提供します。

Townsley, et al.            Standards Track                     [Page 7]

RFC 4817                    MPLS over L2TPv3                  March 2007

Townsley、他 L2TPv3 March 2007の上の標準化過程[7ページ]RFC4817MPLS

   flow, providing context protection, and may be deemed complimentary
   to securing the tunnel utilizing IPsec.  In the absence of
   cryptographic security on the data plane (such as that provided by
   IPsec), the L2TPv3 Cookie provides a simple method of validating the
   Session ID lookup performed on each L2TPv3 packet.  If the Cookie is
   sufficiently random and remains unknown to an attacker (that is, the
   attacker has no way to predict Cookie values or monitor traffic
   between PEs), then the Cookie provides an additional measure of
   protection against malicious spoofed packets inserted at the PE over
   and above that of typical IP address and port ACLs.

文脈保護を提供して、流れてください、そして、IPsecを利用するトンネルを固定するのに賞賛であると考えられてもよいです。 データ飛行機(IPsecによって提供されたそれなどの)の上の暗号のセキュリティがないとき、L2TPv3 CookieはそれぞれのL2TPv3パケットに実行されたSession IDルックアップを有効にする簡単なメソッドを提供します。 Cookieが十分無作為であり、攻撃者にとって未知のままで残っているなら(すなわち、攻撃者には、Cookie値を予測するか、またはPEsの間のトラフィックをモニターする方法が全くありません)、Cookieはものと典型的なIPアドレスとポートACLsのものの上のPEに挿入された悪意がある偽造しているパケットに対する保護の追加手段を提供します。

6.3.  Securing the Tunnel with IPsec

6.3. IPsecと共にトンネルを固定します。

   L2TPv3 tunnels may also be secured using IPsec, as specified in
   Section 4.1.3 of [RFC3931].  IPSec may provide authentication,
   privacy protection, integrity checking, and replay protection.  These
   functions may be deemed necessary by the operator.  When using IPsec,
   the tunnel head and the tunnel tail should be treated as the
   endpoints of a Security Association.  A single IP address of the
   tunnel head is used as the source IP address, and a single IP address
   of the tunnel tail is used as the destination IP address.  The means
   by which each node knows the proper address of the other is outside
   the scope of this document.  However, if a control protocol is used
   to set up the tunnels, such control protocol MUST have an
   authentication mechanism, and this MUST be used when the tunnel is
   set up.  If the tunnel is set up automatically as the result of, for
   example, information distributed by BGP, then the use of BGP's
   Message Digest 5 (MD5)-based authentication mechanism can serve this
   purpose.

また、L2TPv3トンネルは、.3セクション4.1[RFC3931]で指定されるようにIPsecを使用することで固定されるかもしれません。 IPSecは認証、プライバシー保護、保全の照合、および反復操作による保護を提供するかもしれません。 これらの機能は必要であるとオペレータによって考えられるかもしれません。 IPsecを使用するとき、トンネルヘッドとトンネルテールはSecurity Associationの終点として扱われるべきです。 トンネルヘッドのただ一つのIPアドレスはソースIPアドレスとして使用されます、そして、トンネルテールのただ一つのIPアドレスは送付先IPアドレスとして使用されます。 このドキュメントの範囲の外に各ノードがもう片方の適切なアドレスを知っている手段があります。 しかしながら、制御プロトコルがトンネルを設立するのに使用されるなら、そのような制御プロトコルには、認証機構がなければなりません、そして、トンネルが設立されるとき、これを使用しなければなりません。 トンネルが例えばBGPによって分配された情報の結果として自動的に設立されるなら、BGPのMessage Digest5の(MD5)ベースの認証機構の使用はこの目的に役立つことができます。

   The MPLS over L2TPv3 encapsulated packets should be considered as
   originating at the tunnel head and being destined for the tunnel
   tail; IPsec transport mode SHOULD thus be used.

パケットであるとカプセル化されたL2TPv3の上のMPLSはトンネルヘッドで起因して、トンネルテールのために運命づけられていながら、みなされるべきです。 IPsecはモードSHOULDを輸送します、その結果、使用されてください。

   Note that the tunnel tail and the tunnel head are Label Switched Path
   (LSP) adjacencies (for label distribution adjacencies, see
   [RFC3031]), which means that the topmost label of any packet sent
   through the tunnel must be one that was distributed by the tunnel
   tail to the tunnel head.  The tunnel tail MUST know precisely which
   labels it has distributed to the tunnel heads of IPsec-secured
   tunnels.  Labels in this set MUST NOT be distributed by the tunnel
   tail to any LSP adjacencies other than those that are tunnel heads of
   IPsec-secured tunnels.  If an MPLS packet is received without an
   IPsec encapsulation, and if its topmost label is in this set, then
   the packet MUST be discarded.

トンネルテールとトンネルヘッドがLabel Switched Path(LSP)隣接番組(ラベル分配隣接番組に関して、[RFC3031]を見る)であるというメモ。(そのメモはトンネルを通して送られたどんなパケットの最上のラベルもトンネルテールによってトンネルヘッドに分配されたものであるに違いないことを意味します)。 トンネルテールは、それがトンネルヘッドにどのラベルを分配したかを正確にIPsecによって機密保護されたトンネルを知らなければなりません。 このセットにおけるラベルはトンネルテールによってIPsecによって機密保護されたトンネルのトンネルヘッドであるそれら以外のどんなLSP隣接番組にも分配されてはいけません。 IPsecカプセル化なしでMPLSパケットを受け取って、このセットに最上のラベルがあるなら、パケットを捨てなければなりません。

Townsley, et al.            Standards Track                     [Page 8]

RFC 4817                    MPLS over L2TPv3                  March 2007

Townsley、他 L2TPv3 March 2007の上の標準化過程[8ページ]RFC4817MPLS

   Securing L2TPv3 using IPsec MUST provide authentication and
   integrity.  (Note that the authentication and integrity provided will
   apply to the entire MPLS packet, including the MPLS label stack.)

IPsecを使用することでL2TPv3を固定すると、認証と保全は提供されなければなりません。 (認証と保全が提供されたというメモはMPLSラベルスタックを含む全体のMPLSパケットに適用されるでしょう)

   Consequently, the implementation MUST support Encapsulating Security
   Payload (ESP) with null encryption.  ESP with encryption MAY be
   supported if a source requires confidentiality.  If ESP is used, the
   tunnel tail MUST check that the source IP address of any packet
   received on a given Security Association (SA) is the one expected.

その結果、実装は、Encapsulating Securityがヌル暗号化がある有効搭載量(超能力)であるとサポートしなければなりません。 ソースが秘密性を必要とするなら、暗号化がある超能力はサポートされるかもしれません。 超能力が使用されているなら、トンネルテールは、どんなパケットのアドレスも与えられたSecurity Association(SA)で受けたソースIPが期待されたものであることをチェックしなければなりません。

   Key distribution may be done either manually or automatically by
   means of the Internet Key Exchange (IKE) Protocol [RFC2409] or IKEv2
   [RFC4306].  Manual keying MUST be supported.  If automatic keying is
   implemented, IKE in main mode with preshared keys MUST be supported.
   A particular application may escalate this requirement and request
   implementation of automatic keying.  Manual key distribution is much
   simpler, but also less scalable, than automatic key distribution.  If
   replay protection is regarded as necessary for a particular tunnel,
   automatic key distribution should be configured.

インターネット・キー・エクスチェンジ(IKE)のプロトコル[RFC2409]かIKEv2[RFC4306]によって手動的か自動的に主要な分配をするかもしれません。 手動の合わせることをサポートしなければなりません。 自動合わせることが実装されるなら、前共有されたキーがある主なモードによるIKEをサポートしなければなりません。 特定用途は自動合わせることのこの要件と要求実装を徐々に拡大するかもしれません。 手動の主要な分配も、自動主要な分配ほどはるかに簡単ですが、また、スケーラブルではありません。 反復操作による保護が特定のトンネルに必要であると見なされるなら、自動主要な分配は構成されるべきです。

7.  Acknowledgements

7. 承認

   Thanks to Robert Raszuk, Clarence Filsfils, and Eric Rosen for their
   review of this document.  Some text was adopted from [RFC4023].

彼らのこのドキュメントのレビューをロバートRaszuk、クラレンスFilsfils、およびエリック・ローゼンをありがとうございます。 何らかのテキストが[RFC4023]から採用されました。

Townsley, et al.            Standards Track                     [Page 9]

RFC 4817                    MPLS over L2TPv3                  March 2007

Townsley、他 L2TPv3 March 2007の上の標準化過程[9ページ]RFC4817MPLS

8.  References

8. 参照

8.1.  Normative References

8.1. 引用規格

   [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月。

   [RFC3032]     Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y.,
                 Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack
                 Encoding", RFC 3032, January 2001.

[RFC3032] ローゼン、E.、タッパン、D.、Fedorkow、G.、Rekhter、Y.、ファリナッチ、D.、李、T.、およびA.コンタ、「MPLSラベルスタックコード化」、RFC3032(2001年1月)。

   [RFC3931]     Lau, J., Townsley, M., and I. Goyret, "Layer Two
                 Tunneling Protocol - Version 3 (L2TPv3)", RFC 3931,
                 March 2005.

[RFC3931] ラウ、J.、Townsley、M.、およびI.Goyret、「2トンネリングプロトコルを層にしてください--バージョン3(L2TPv3)」、RFC3931、3月2005日

   [RFC4023]     Worster, T., Rekhter, Y., and E. Rosen, "Encapsulating
                 MPLS in IP or Generic Routing Encapsulation (GRE)", RFC
                 4023, March 2005.

[RFC4023] オースター、T.、Rekhter、Y.、およびE.ローゼン、「IPか一般ルーティングのカプセル化(GRE)でMPLSをカプセル化します」、RFC4023(2005年3月)。

   [RFC4086]     Eastlake, D., 3rd, Schiller, J., and S. Crocker,
                 "Randomness Requirements for Security", BCP 106, RFC
                 4086, June 2005.

[RFC4086]イーストレークとD.と3番目、シラー、J.とS.クロッカー、「セキュリティのための偶発性要件」BCP106、2005年6月のRFC4086。

8.2.  Informative References

8.2. 有益な参照

   [MPLS-IPSEC]  Rosen, E., De Clercq, J., Paridaens, O., T'Joens, Y.,
                 and C. Sargor, "Architecture for the Use of PE-PE IPsec
                 Tunnels in BGP/MPLS IP VPNs", Work in Progress, August
                 2005.

[MPLS-IPSEC]ローゼン、E.、J.、Paridaens、O.、T'Joens、Y.、およびC.Sargor、「BGP/MPLS IP VPNsにおけるPE-PE IPsec Tunnelsの使用のためのアーキテクチャ」というDe Clercqは進行中(2005年8月)で働いています。

   [RFC3031]     Rosen, E., Viswanathan, A., and R. Callon,
                 "Multiprotocol Label Switching Architecture", RFC 3031,
                 January 2001.

[RFC3031] ローゼンとE.とViswanathan、A.とR.Callon、「Multiprotocolラベル切り換えアーキテクチャ」、RFC3031、2001年1月。

   [RFC2409]     Harkins, D. and D. Carrel, "The Internet Key Exchange
                 (IKE)", RFC 2409, November 1998.

[RFC2409]ハーキンとD.とD.個人閲覧室、「インターネット・キー・エクスチェンジ(IKE)」、RFC2409 1998年11月。

   [RFC4306]     Kaufman, C., "Internet Key Exchange (IKEv2) Protocol",
                 RFC 4306, December 2005.

[RFC4306] コーフマン、C.、「インターネット・キー・エクスチェンジ(IKEv2)プロトコル」、RFC4306、2005年12月。

   [RFC3448]     Handley, M., Floyd, S., Padhye, J., and J. Widmer, "TCP
                 Friendly Rate Control (TFRC): Protocol Specification",
                 RFC 3448, January 2003.

[RFC3448] ハンドレー、M.、フロイド、S.、Padhye、J.、およびJ.ウィトマー、「TCPの好意的なレートは(TFRC)を制御します」。 「プロトコル仕様」、RFC3448、2003年1月。

Townsley, et al.            Standards Track                    [Page 10]

RFC 4817                    MPLS over L2TPv3                  March 2007

Townsley、他 L2TPv3 March 2007の上の標準化過程[10ページ]RFC4817MPLS

Authors' Addresses

作者のアドレス

   W. Mark Townsley
   Cisco Systems
   USA

W.マークTownsleyシスコシステムズ米国

   Phone: +1-919-392-3741
   EMail: mark@townsley.net

以下に電話をしてください。 +1-919-392-3741 メールしてください: mark@townsley.net

   Carlos Pignataro
   Cisco Systems
   7025 Kit Creek Road
   PO Box 14987
   Research Triangle Park, NC 27709
   USA

7025年のカルロスPignataroシスコシステムズキットクリーク道路私書箱14987リサーチトライアングル公園、NC27709米国

   Phone: +1-919-392-7428
   EMail: cpignata@cisco.com

以下に電話をしてください。 +1-919-392-7428 メールしてください: cpignata@cisco.com

   Scott Wainner
   Cisco Systems
   13600 Dulles Technology Drive
   Herndon, VA 20171
   USA

スコットWainnerシスコシステムズ13600ダレス技術Driveヴァージニア20171ハーンドン(米国)

   EMail: swainner@cisco.com

メール: swainner@cisco.com

   Ted Seely
   Sprint Nextel
   12502 Sunrise Valley Drive
   Reston, VA 20196
   USA

テッドシーリ短距離競走ネクステル12502SunriseバレーDriveレストン(ヴァージニア)20196米国

   Phone: +1-703-689-6425
   EMail: tseely@sprint.net

以下に電話をしてください。 +1-703-689-6425 メールしてください: tseely@sprint.net

   Jeff Young

ジェフ・ヤング

   EMail: young@jsyoung.net

メール: young@jsyoung.net

Townsley, et al.            Standards Track                    [Page 11]

RFC 4817                    MPLS over L2TPv3                  March 2007

Townsley、他 L2TPv3 March 2007の上の標準化過程[11ページ]RFC4817MPLS

Full Copyright Statement

完全な著作権宣言文

   Copyright (C) The IETF Trust (2007).

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

このドキュメントは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に情報を記述してください。

Acknowledgement

承認

   Funding for the RFC Editor function is currently provided by the
   Internet Society.

RFC Editor機能のための基金は現在、インターネット協会によって提供されます。

Townsley, et al.            Standards Track                    [Page 12]

Townsley、他 標準化過程[12ページ]