[要約] RFC 7404は、IPv6ネットワーク内でリンクローカルアドレッシングのみを使用するためのガイドラインです。その目的は、リンクローカルアドレッシングの利点と使用方法を説明し、IPv6ネットワークの設計と運用をサポートすることです。
Internet Engineering Task Force (IETF) M. Behringer
Request for Comments: 7404 E. Vyncke
Category: Informational Cisco
ISSN: 2070-1721 November 2014
Using Only Link-Local Addressing inside an IPv6 Network
IPv6ネットワーク内でのリンクローカルアドレス指定のみの使用
Abstract
概要
In an IPv6 network, it is possible to use only link-local addresses on infrastructure links between routers. This document discusses the advantages and disadvantages of this approach to facilitate the decision process for a given network.
IPv6ネットワークでは、ルーター間のインフラストラクチャリンクでリンクローカルアドレスのみを使用できます。このドキュメントでは、特定のネットワークの決定プロセスを容易にするためのこのアプローチの利点と欠点について説明します。
Status of This Memo
本文書の状態
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントはInternet Standards Trackの仕様ではありません。情報提供を目的として公開されています。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。 IESGによって承認されたすべてのドキュメントが、あらゆるレベルのインターネット標準の候補になるわけではありません。 RFC 5741のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7404.
このドキュメントの現在のステータス、エラッタ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7404で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2014 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、BCP 78およびこの文書の発行日に有効なIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象となります。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Using Link-Local Addressing on Infrastructure Links . . . . . 2
2.1. The Approach . . . . . . . . . . . . . . . . . . . . . . 3
2.2. Advantages . . . . . . . . . . . . . . . . . . . . . . . 4
2.3. Caveats . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.4. Internet Exchange Points . . . . . . . . . . . . . . . . 6
2.5. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 7
3. Security Considerations . . . . . . . . . . . . . . . . . . . 8
4. Informative References . . . . . . . . . . . . . . . . . . . 8
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10
An infrastructure link between a set of routers typically does not require global or unique local addresses [RFC4193]. Using only link-local addressing on such links has a number of advantages; for example, routing tables do not need to carry link addressing and can therefore be significantly smaller. This helps to decrease failover times in certain routing convergence events. An interface of a router is also not reachable beyond the link boundaries, therefore reducing the attack surface.
ルーターのセット間のインフラストラクチャリンクは、通常、グローバルまたは一意のローカルアドレスを必要としません[RFC4193]。このようなリンクでリンクローカルアドレス指定のみを使用すると、多くの利点があります。たとえば、ルーティングテーブルはリンクアドレッシングを実行する必要がないため、大幅に小さくすることができます。これは、特定のルーティング収束イベントでのフェイルオーバー時間を短縮するのに役立ちます。ルーターのインターフェイスもリンクの境界を超えて到達できないため、攻撃対象が減少します。
This document discusses the advantages and caveats of this approach.
このドキュメントでは、このアプローチの利点と注意点について説明します。
Note that some traditional techniques used to operate a network, such as pinging interfaces or seeing interface information in a traceroute, do not work with this approach. Details are discussed below.
pingインターフェースやtracerouteでのインターフェース情報の表示など、ネットワークの操作に使用されるいくつかの従来の手法は、このアプローチでは機能しないことに注意してください。詳細については、以下で説明します。
During WG and IETF last call, the technical correctness of the document was reviewed; however, debate exists as to whether to recommend this technique. The deployment of this technique is appropriate where it is found to be necessary.
WGとIETFの前回の電話中に、ドキュメントの技術的な正確性がレビューされました。ただし、この手法を推奨するかどうかについては議論があります。この手法の展開は、必要であることがわかっている場合に適しています。
This document discusses the approach of using only link-local addresses (LLAs) on all router interfaces on infrastructure links. Routers don't typically need to receive packets from hosts or nodes outside the network. For a network operator, there may be reasons to use addresses that are greater than link-local scope on infrastructure interfaces for certain operational tasks, such as pings to an interface or traceroutes across the network. This document discusses such cases and proposes alternative procedures.
このドキュメントでは、インフラストラクチャリンク上のすべてのルーターインターフェイスでリンクローカルアドレス（LLA）のみを使用する方法について説明します。ルーターは通常、ネットワーク外のホストまたはノードからパケットを受信する必要はありません。ネットワークオペレーターの場合、インターフェイスへのpingやネットワーク全体のtracerouteなどの特定の運用タスクでは、インフラストラクチャインターフェイスのリンクローカルスコープよりも大きいアドレスを使用する理由がある場合があります。このドキュメントでは、このようなケースについて説明し、代替手順を提案します。
In this approach, neither globally routed IPv6 addresses nor unique local addresses are configured on infrastructure links. In the absence of specific global or unique local address definitions, the default behavior of routers is to use link-local addresses, notably for routing protocols.
このアプローチでは、グローバルにルーティングされるIPv6アドレスも一意のローカルアドレスもインフラストラクチャリンクで構成されません。特定のグローバルまたは一意のローカルアドレス定義がない場合、ルーターのデフォルトの動作は、特にルーティングプロトコルに対してリンクローカルアドレスを使用することです。
The sending of ICMPv6 [RFC4443] error messages ("packet-too-big", "time-exceeded", etc.) is required for routers. Therefore, another interface must be configured with an IPv6 address that has a greater scope than link-local. This address will usually be a loopback interface with a global scope address belonging to the operator and part of an announced prefix (with a suitable prefix length) to avoid being dropped by other routers implementing ingress filtering [RFC3704]. This is implementation dependent. For the remainder of this document, we will refer to this interface as a "loopback interface".
ルーターでは、ICMPv6 [RFC4443]エラーメッセージ（「packet-too-big」、「time-exceeded」など）の送信が必要です。したがって、別のインターフェイスは、リンクローカルよりもスコープが広いIPv6アドレスで構成する必要があります。このアドレスは通常、オペレーターに属するグローバルスコープアドレスと、入力フィルター（RFC3704）を実装する他のルーターによるドロップを回避するために（適切なプレフィックス長で）アナウンスされたプレフィックスの一部を持つループバックインターフェイスになります。これは実装に依存します。このドキュメントの残りの部分では、このインターフェイスを「ループバックインターフェイス」と呼びます。
[RFC6724] recommends that IPv6 addresses that are greater than link-local scope be used as the source IPv6 address for all generated ICMPv6 messages sent to a non-link-local address, with the exception of ICMPv6 redirect messages (as defined in Section 4.5 of [RFC4861]).
[RFC6724]は、リンクローカルスコープよりも大きいIPv6アドレスを、リンクローカル以外のアドレスに送信されるすべての生成されたICMPv6メッセージの送信元IPv6アドレスとして使用することを推奨しています。ただし、ICMPv6リダイレクトメッセージは例外です（セクション4.5で定義） [RFC4861]の）。
The effect on specific traffic types is as follows:
特定のトラフィックタイプへの影響は次のとおりです。
o Most control plane protocols (such as BGP [RFC4271], IS-IS [IS-IS], OSPFv3 [RFC5340], Routing Information Protocol Next Generation (RIPng) [RFC2080], and PIM [RFC4609]) work by default or can be configured to work with link-local addresses. Exceptions are explained in the caveats section (Section 2.3).
o ほとんどのコントロールプレーンプロトコル（BGP [RFC4271]、IS-IS [IS-IS]、OSPFv3 [RFC5340]、Routing Information Protocol Next Generation（RIPng）[RFC2080]、PIM [RFC4609]など）は、デフォルトで機能するか、またはリンクローカルアドレスで動作するように構成されています。例外については、警告のセクション（セクション2.3）で説明されています。
o Management plane traffic (such as Secure SHell (SSH) Protocol [RFC4251], Telnet [RFC0495], Simple Network Management Protocol (SNMP) [RFC1157], and ICMPv6 Echo Request [RFC4443]) can use the address of the router loopback interface as the destination address. Router management can also be done over out-of-band channels.
o 管理プレーントラフィック（セキュアシェル（SSH）プロトコル[RFC4251]、Telnet [RFC0495]、簡易ネットワーク管理プロトコル（SNMP）[RFC1157]、およびICMPv6エコー要求[RFC4443]など）は、ルーターループバックインターフェイスのアドレスを使用できます。宛先アドレス。ルーターの管理は、帯域外チャネルを介して行うこともできます。
o ICMP error messages are usually sourced from a loopback interface with a scope that is greater than link-local. Section 4.5 of [RFC4861] explains one exception: ICMP redirect messages can also be sourced from a link-local address.
o ICMPエラーメッセージは通常、リンクローカルよりも大きなスコープを持つループバックインターフェイスから送信されます。 [RFC4861]のセクション4.5では、1つの例外について説明しています。ICMPリダイレクトメッセージは、リンクローカルアドレスから送信されることもあります。
o Data plane traffic is forwarded independently of the link address type.
o データプレーントラフィックは、リンクアドレスタイプとは無関係に転送されます。
o Neighbor discovery (neighbor solicitation and neighbor advertisement) is done by using link-local unicast and multicast addresses. Therefore, neighbor discovery is not affected.
o 近隣探索（近隣要請と近隣通知）は、リンクローカルユニキャストアドレスとマルチキャストアドレスを使用して行われます。したがって、ネイバー探索は影響を受けません。
Thus, we conclude that it is possible to construct a working network in this way.
したがって、このようにして実際のネットワークを構築することが可能であると結論付けます。
The following list of advantages is in no particular order.
以下の利点のリストは、特定の順序ではありません。
Smaller routing tables: Since the routing protocol only needs to carry one global address (the loopback interface) per router, it is smaller than the traditional approach where every infrastructure link address is carried in the routing protocol. This reduces memory consumption and increases the convergence speed in some routing failover cases. Because the Forwarding Information Base to be downloaded to line cards is smaller, and there are fewer prefixes in the Routing Information Base, the routing algorithm is accelerated. Note that smaller routing tables can also be achieved by putting interfaces in passive mode for the Interior Gateway Protocol (IGP).
ルーティングテーブルの小型化：ルーティングプロトコルはルーターごとに1つのグローバルアドレス（ループバックインターフェイス）を伝送するだけでよいため、すべてのインフラストラクチャリンクアドレスがルーティングプロトコルで伝送される従来のアプローチよりも小さくなります。これにより、メモリの消費量が削減され、一部のルーティングフェールオーバーの場合の収束速度が向上します。ラインカードにダウンロードされる転送情報ベースが小さく、ルーティング情報ベースのプレフィックスが少ないため、ルーティングアルゴリズムが高速化されます。より小さいルーティングテーブルは、Interior Gateway Protocol（IGP）のインターフェイスをパッシブモードにすることでも実現できることに注意してください。
Simpler address management: Only loopback interface addresses need to be considered in an addressing plan. This also allows for easier renumbering.
よりシンプルなアドレス管理：ループバックインターフェイスアドレスのみをアドレス計画で考慮する必要があります。これにより、番号の付け直しも簡単になります。
Lower configuration complexity: Link-local addresses require no specific configuration, thereby lowering the complexity and size of router configurations. This also reduces the likelihood of configuration mistakes.
構成の複雑さの軽減：リンクローカルアドレスは特定の構成を必要としないため、ルーター構成の複雑さとサイズが低くなります。これにより、設定ミスの可能性も減少します。
Simpler DNS: Less routable address space in use also means less reverse and forward mapping DNS resource records to maintain. Of course, if the operator selects not to enter any global interface addresses in the DNS anyway, then this is less of an advantage.
シンプルなDNS：使用中のルーティング可能なアドレススペースが少ないということは、維持するリバースおよびフォワードマッピングDNSリソースレコードも少ないことを意味します。もちろん、オペレーターがDNSにグローバルインターフェイスアドレスを入力しないことを選択した場合、これはあまりメリットがありません。
Reduced attack surface: Every routable address on a router constitutes a potential attack point; a remote attacker can send traffic to that address, for example, a TCP SYN flood (see [RFC4987]). If a network only uses the addresses of the router loopback interface(s), only those addresses need to be protected from outside the network. This may ease protection measures, such as Infrastructure Access Control Lists (iACL). Without using link-local addresses, it is still possible to achieve the simple iACL if the network addressing scheme is set up such that all link and loopback interfaces have addresses that are greater than link-local and are aggregatable, and if the infrastructure access list covers that entire aggregated space. See also [RFC6752] for further discussion on this topic. [RFC6860] describes another approach to hide addressing on infrastructure links for OSPFv2 and OSPFv3 by modifying the existing protocols. This document does not modify any protocol and applies only to IPv6.
攻撃対象領域の削減：ルーター上のルーティング可能なすべてのアドレスは、潜在的な攻撃ポイントを構成します。リモートの攻撃者は、TCP SYNフラッドなどのトラフィックをそのアドレスに送信できます（[RFC4987]を参照）。ネットワークがルーターループバックインターフェイスのアドレスのみを使用する場合、それらのアドレスのみをネットワークの外部から保護する必要があります。これにより、インフラストラクチャアクセスコントロールリスト（iACL）などの保護対策が容易になります。リンクローカルアドレスを使用しなくても、すべてのリンクおよびループバックインターフェイスがリンクローカルより大きく、集約可能なアドレスを持つようにネットワークアドレッシングスキームが設定されていて、インフラストラクチャアクセスリストがあれば、簡単なiACLを実現できます。集計されたスペース全体をカバーします。このトピックの詳細については、[RFC6752]も参照してください。 [RFC6860]は、既存のプロトコルを変更することにより、OSPFv2およびOSPFv3のインフラストラクチャリンクのアドレッシングを隠す別のアプローチについて説明しています。このドキュメントはプロトコルを変更せず、IPv6にのみ適用されます。
The caveats listed in this section are in no particular order.
このセクションに記載されている警告は、特定の順序ではありません。
Interface ping: If an interface doesn't have a routable address, it can only be pinged from a node on the same link. Therefore, it is not possible to ping a specific link interface remotely. A possible workaround is to ping the loopback address of a router instead. In most cases today, it is not possible to see which link the packet was received on; however, [RFC5837] suggests including the interface identifier of the interface a packet was received on in the ICMPv6 response. It must be noted that there are few implementations of this ICMPv6 extension. With this approach, it would be possible to ping a router on the addresses of loopback interfaces, yet see which interface the packet was received on. To check liveliness of a specific interface, it may be necessary to use other methods, such as connecting to the router via SSH and checking locally or using SNMP.
インターフェイスのping：インターフェイスにルーティング可能なアドレスがない場合、同じリンク上のノードからのみpingを実行できます。したがって、特定のリンクインターフェイスをリモートでpingすることはできません。可能な回避策は、代わりにルーターのループバックアドレスにpingを実行することです。今日のほとんどの場合、パケットが受信されたリンクを確認することはできません。ただし、[RFC5837]は、ICMPv6応答でパケットが受信されたインターフェイスのインターフェイス識別子を含めることを提案しています。このICMPv6拡張機能の実装はほとんどないことに注意してください。このアプローチを使用すると、ループバックインターフェイスのアドレスでルーターにpingを送信し、パケットが受信されたインターフェイスを確認できます。特定のインターフェイスの活性を確認するには、SSH経由でルーターに接続してローカルで確認したり、SNMPを使用したりするなど、他の方法を使用する必要がある場合があります。
Traceroute: Similar to the ping case, a reply to a traceroute packet would come from the address of a loopback interface, and current implementations do not display the specific interface the packets came in on. Again, [RFC5837] provides a solution. As in the ping case above, it is not possible to traceroute to a particular interface if it only has a link-local address. Conversely, this approach may make network topology discovery from outside the network simpler: instead of responding with multiple different interface IP addresses, which have to be correlated by the outsider, a router will always respond with the same loopback address. If reverse DNS mapping is used, the mapping is trivial in either case.
Traceroute：pingの場合と同様に、tracerouteパケットへの応答はループバックインターフェイスのアドレスから送信され、現在の実装では、パケットが着信した特定のインターフェイスは表示されません。ここでも、[RFC5837]がソリューションを提供します。上記のpingの場合と同様に、リンクローカルアドレスしかない場合、特定のインターフェイスへのtracerouteはできません。逆に、このアプローチでは、ネットワークトポロジーの検出をネットワークの外部からより簡単にすることができます。外部の人と関連付ける必要がある複数の異なるインターフェースIPアドレスで応答する代わりに、ルーターは常に同じループバックアドレスで応答します。逆DNSマッピングが使用されている場合、マッピングはどちらの場合でも簡単です。
Hardware dependency: LLAs have usually been based on 64-bit Extended Unique Identifiers (EUI-64); hence, they change when the Message Authentication Code (MAC) address is changed. This could pose a problem in a case where the routing neighbor must be configured explicitly (e.g., BGP) and a line card needs to be physically replaced, hence changing the EUI-64 LLA and breaking the routing neighborship. LLAs can be statically configured, such as fe80::1 and fe80::2, which can be used to configure any required static routing neighborship. However, this static LLA configuration may be more complex to operate than statically configured addresses that are greater than link-local scope. This is because LLAs are inherently ambiguous. For a multi-link node, such as a router, to deal with the ambiguity, the link zone index must also be considered explicitly, e.g., using the extended textual notation described in [RFC4007], as in this example, 'BGP neighbor fe80::1%eth0 is down'.
ハードウェアの依存関係：LLAは通常、64ビットの拡張一意識別子（EUI-64）に基づいています。したがって、メッセージ認証コード（MAC）アドレスが変更されると、それらは変更されます。これは、ルーティングネイバーを明示的に構成する必要があり（BGPなど）、ラインカードを物理的に交換する必要がある場合に問題を引き起こす可能性があり、EUI-64 LLAが変更され、ルーティングネイバーシップが切断されます。 LLAは、fe80 :: 1やfe80 :: 2などの静的に構成できます。これを使用して、必要な静的ルーティングネイバーシップを構成できます。ただし、この静的LLA構成は、リンクローカルスコープよりも大きい静的に構成されたアドレスよりも操作が複雑になる場合があります。これは、LLAが本質的にあいまいであるためです。ルーターなどのマルチリンクノードでは、あいまいさを処理するために、リンクゾーンインデックスも明示的に考慮する必要があります。たとえば、この例のように、[RFC4007]で説明されている拡張テキスト表記を使用して、 'BGP neighbor fe80 :: 1％eth0がダウンしています。
Network Management System (NMS) toolkits: If there is any NMS tool that makes use of an interface IP address of a router to carry out any of its NMS functions, then it would no longer work if the interface does not have a routable address. A possible workaround for such tools is to use the routable address of the router loopback interface instead. Most vendor implementations allow the specification of loopback interface addresses for SYSLOG, IPFIX, and SNMP. The Link Layer Discovery Protocol (LLDP) (IEEE 802.1AB-2009) runs directly over Ethernet and does not require any IPv6 address, so dynamic network discovery is not hindered by using only LLA when using LLDP. But, network discovery based on Neighbor Discovery Protocol (NDP) cache content will only display the link-local addresses and not the addresses of the loopback interfaces; therefore, network discovery should rather be based on the Route Information Base to detect adjacent nodes.
ネットワーク管理システム（NMS）ツールキット：ルーターのインターフェースIPアドレスを使用してNMS機能のいずれかを実行するNMSツールがある場合、インターフェースにルーティング可能なアドレスがないと機能しません。このようなツールの考えられる回避策は、代わりにルーターのループバックインターフェイスのルーティング可能なアドレスを使用することです。ほとんどのベンダー実装では、SYSLOG、IPFIX、およびSNMPのループバックインターフェイスアドレスを指定できます。リンク層検出プロトコル（LLDP）（IEEE 802.1AB-2009）はイーサネット上で直接実行され、IPv6アドレスを必要としないため、LLDPを使用するときにLLAのみを使用しても動的ネットワーク検出が妨げられることはありません。ただし、近隣探索プロトコル（NDP）のキャッシュコンテンツに基づくネットワーク探索では、リンクローカルアドレスのみが表示され、ループバックインターフェイスのアドレスは表示されません。したがって、隣接ノードを検出するには、ネットワーク検出はルート情報ベースに基づいている必要があります。
MPLS and RSVP-Traffic Engineering (RSVP-TE) [RFC3209] allow the establishment of an MPLS Label Switched Path (LSP) on a path that is explicitly identified by a strict sequence of IP prefixes or addresses (each pertaining to an interface or a router on the path). This is commonly used for Fast Reroute (FRR). However, if an interface uses only a link-local address, then such LSPs cannot be established. At the time of writing this document, there is no workaround for this case; therefore, where RSVP-TE is being used, the approach described in this document does not work.
MPLSおよびRSVP-Traffic Engineering（RSVP-TE）[RFC3209]により、IPプレフィックスまたはアドレスの厳密なシーケンス（それぞれがインターフェイスまたはインターフェイスに関係する）によって明示的に識別されるパス上にMPLSラベルスイッチドパス（LSP）を確立できます。パス上のルーター）。これは一般的に高速再ルーティング（FRR）に使用されます。ただし、インターフェイスがリンクローカルアドレスのみを使用する場合、そのようなLSPは確立できません。このドキュメントの執筆時点では、このケースに対する回避策はありません。したがって、RSVP-TEが使用されている場合、このドキュメントで説明されているアプローチは機能しません。
Internet Exchange Points (IXPs) have a special importance in the global Internet because they connect a high number of networks in a single location and because a significant part of Internet traffic passes through at least one IXP. An IXP requires, therefore, a very high level of security. The address space used on an IXP is generally known, as it is registered in the global Internet Route Registry, or it is easily discoverable through traceroute. The IXP prefix is especially critical because practically all addresses on this prefix are critical systems in the Internet.
インターネットエクスチェンジポイント（IXP）は、単一の場所で多数のネットワークを接続し、インターネットトラフィックのかなりの部分が少なくとも1つのIXPを通過するため、グローバルインターネットで特に重要です。したがって、IXPには非常に高いレベルのセキュリティが必要です。 IXPで使用されるアドレス空間は、グローバルインターネットルートレジストリに登録されているか、tracerouteを介して簡単に検出できるため、一般的に知られています。 IXPプレフィックスは、このプレフィックスの実質的にすべてのアドレスがインターネットの重要なシステムであるため、特に重要です。
Apart from general device security guidelines, there are basically two additional ways to raise security (see also [BGP-OPSEC]):
一般的なデバイスセキュリティガイドラインとは別に、基本的にセキュリティを強化する方法が2つあります（[BGP-OPSEC]も参照）。
1. Not to announce the prefix in question, and
1. 問題の接頭辞を発表しないこと、および
2. To drop all traffic from remote locations destined to the IXP prefixes.
2. リモートロケーションからIXPプレフィックスに向かうすべてのトラフィックをドロップします。
Not announcing the prefix of the IXP would frequently result in traceroute and similar packets (required for Path MTU Discovery (PMTUD)) being dropped due to unicast Reverse Path Forwarding (uRPF) checks. Given that PMTUD is critical, this is generally not acceptable. Dropping all external traffic to the IXP prefix is hard to implement because if only one service provider connected to an IXP does not filter correctly, then all IXP routers are reachable from at least that service provider network.
IXPのプレフィックスをアナウンスしないと、ユニキャストリバースパスフォワーディング（uRPF）チェックにより、tracerouteおよび類似のパケット（パスMTUディスカバリー（PMTUD）に必要）がドロップされることがよくあります。 PMTUDが重要であることを考えると、これは一般に受け入れられません。すべての外部トラフィックをIXPプレフィックスにドロップすることは実装が困難です。これは、IXPに接続された1つのサービスプロバイダーだけが正しくフィルタリングしない場合、すべてのIXPルーターが少なくともそのサービスプロバイダーネットワークから到達可能だからです。
As the prefix used in the IXP is usually longer than a /48, it is frequently dropped by route filters on the Internet having the same net effect as not announcing the prefix.
IXPで使用されるプレフィックスは通常/ 48より長いので、プレフィックスをアナウンスしないのと同じ最終的な効果を持つインターネット上のルートフィルターによって頻繁にドロップされます。
Using link-local addresses on the IXP may help in this scenario. In this case, the generated ICMPv6 packets would be generated from loopback interfaces or from any other interface with a globally routable address without any configuration. However, in this case, each service provider would use their own address space, making a generic attack against all devices on the IXP harder. All of an IXP's loopback interface addresses can be discovered by a potential attacker with a simple traceroute; a generic attack is, therefore, still possible, but it would require more work.
IXPでリンクローカルアドレスを使用すると、このシナリオで役立つ場合があります。この場合、生成されたICMPv6パケットは、ループバックインターフェイスから、または設定なしでグローバルにルーティング可能なアドレスを持つ他のインターフェイスから生成されます。ただし、この場合、各サービスプロバイダーは独自のアドレススペースを使用するため、IXP上のすべてのデバイスに対する一般的な攻撃が困難になります。 IXPのループバックインターフェイスアドレスはすべて、単純なtracerouteを使用して潜在的な攻撃者が発見できます。したがって、一般的な攻撃は依然として可能ですが、さらに多くの作業が必要になります。
In some cases, service providers carry the IXP addresses in their IGP for certain forms of traffic engineering across multiple exit points. Link-local addresses cannot be used for this purpose; in this case, the service provider would have to employ other methods of traffic engineering.
場合によっては、サービスプロバイダーは、複数の出口ポイントにまたがる特定の形式のトラフィックエンジニアリングのためにIGPでIXPアドレスを伝送します。リンクローカルアドレスはこの目的には使用できません。この場合、サービスプロバイダーは他のトラフィックエンジニアリング方法を採用する必要があります。
If an Internet Exchange Point is using a global prefix registered for this purpose, a traceroute will indicate whether the trace crosses an IXP rather than a private interconnect. If link-local addressing is used instead, a traceroute will not provide this distinction.
Internet Exchange Pointがこの目的で登録されたグローバルプレフィックスを使用している場合、tracerouteは、トレースがプライベートインターコネクトではなくIXPを通過するかどうかを示します。代わりにリンクローカルアドレス指定が使用されている場合、tracerouteはこの区別を提供しません。
Exclusively using link-local addressing on infrastructure links has a number of advantages and disadvantages, both of which are described in detail in this document. A network operator can use this document to evaluate whether or not using link-local addressing on infrastructure links is a good idea in the context of his/her network. This document makes no particular recommendation either in favor or against.
インフラストラクチャリンクでリンクローカルアドレッシングを排他的に使用することには、多くの利点と欠点があります。この両方について、このドキュメントで詳しく説明します。ネットワークオペレーターは、このドキュメントを使用して、インフラストラクチャリンクでリンクローカルアドレッシングを使用することがネットワークのコンテキストで適切かどうかを評価できます。この文書は、賛成にも反対にも特定の推奨事項はありません。
Using only LLAs on infrastructure links reduces the attack surface of a router. Loopback interfaces with routed addresses are still reachable and must be secured, but infrastructure links can only be attacked from the local link. This simplifies security of control and management planes. The approach does not impact the security of the data plane. The link-local-only approach does not address control plane [RFC6192] attacks generated by data plane packets (such as hop-limit expiration or packets containing a hop-by-hop extension header).
インフラストラクチャリンクでLLAのみを使用すると、ルーターの攻撃面が減少します。ルーティングされたアドレスを持つループバックインターフェイスは引き続き到達可能であり、セキュリティで保護する必要がありますが、インフラストラクチャリンクはローカルリンクからのみ攻撃できます。これにより、制御プレーンと管理プレーンのセキュリティが簡素化されます。このアプローチは、データプレーンのセキュリティには影響しません。リンクローカルのみのアプローチは、データプレーンパケット（ホップ制限の有効期限やホップバイホップの拡張ヘッダーを含むパケットなど）によって生成されたコントロールプレーン[RFC6192]攻撃には対処しません。
For additional security considerations, as previously stated, see also [RFC5837] and [BGP-OPSEC].
前述のとおり、セキュリティに関するその他の考慮事項については、[RFC5837]と[BGP-OPSEC]も参照してください。
[BGP-OPSEC] Durand, J., Pepelnjak, I., and G. Doering, "BGP operations and security", Work in Progress, draft-ietf-opsec-bgp-security-05, August 2014.
[BGP-OPSEC] Durand、J.、Pepelnjak、I。、およびG. Doering、「BGPの運用とセキュリティ」、Work in Progress、draft-ietf-opsec-bgp-security-05、2014年8月。
[IS-IS] International Organization for Standardization, "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)", ISO Standard 10589, 2002.
[IS-IS]国際標準化機構、「コネクションレスモードのネットワークサービス（ISO 8473）を提供するためのプロトコルと組み合わせて使用するための中間システム間ドメイン内ルーティング情報交換プロトコル」、ISO標準10589、2002。
[RFC0495] McKenzie, A., "Telnet Protocol specifications", RFC 495, May 1973, <http://www.rfc-editor.org/info/rfc0495>.
[RFC0495]マッケンジーA。、「Telnetプロトコル仕様」、RFC 495、1973年5月、<http://www.rfc-editor.org/info/rfc0495>。
[RFC1157] Case, J., Fedor, M., Schoffstall, M., and J. Davin, "Simple Network Management Protocol (SNMP)", STD 15, RFC 1157, May 1990, <http://www.rfc-editor.org/info/rfc1157>.
[RFC1157] Case、J.、Fedor、M.、Schoffstall、M。、およびJ. Davin、「Simple Network Management Protocol（SNMP）」、STD 15、RFC 1157、1990年5月、<http：//www.rfc -editor.org/info/rfc1157>。
[RFC2080] Malkin, G. and R. Minnear, "RIPng for IPv6", RFC 2080, January 1997, <http://www.rfc-editor.org/info/rfc2080>.
[RFC2080] Malkin、G。およびR. Minnear、「RIPng for IPv6」、RFC 2080、1997年1月、<http://www.rfc-editor.org/info/rfc2080>。
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, December 2001, <http://www.rfc-editor.org/info/rfc3209>.
[RFC3209] Awduche、D.、Berger、L.、Gan、D.、Li、T.、Srinivasan、V。、およびG. Swallow、「RSVP-TE：Extensions for RSVP for LSP Tunnels」、RFC 3209、12月2001、<http://www.rfc-editor.org/info/rfc3209>。
[RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed Networks", BCP 84, RFC 3704, March 2004, <http://www.rfc-editor.org/info/rfc3704>.
[RFC3704]ベイカー、F。およびP.サボラ、「マルチホームネットワークの入力フィルタリング」、BCP 84、RFC 3704、2004年3月、<http://www.rfc-editor.org/info/rfc3704>。
[RFC4007] Deering, S., Haberman, B., Jinmei, T., Nordmark, E., and B. Zill, "IPv6 Scoped Address Architecture", RFC 4007, March 2005, <http://www.rfc-editor.org/info/rfc4007>.
[RFC4007] Deering、S.、Haberman、B.、Jinmei、T.、Nordmark、E。、およびB. Zill、「IPv6 Scoped Address Architecture」、RFC 4007、2005年3月、<http：//www.rfc- editor.org/info/rfc4007>。
[RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast Addresses", RFC 4193, October 2005, <http://www.rfc-editor.org/info/rfc4193>.
[RFC4193] Hinden、R。およびB. Haberman、「Unique Local IPv6 Unicast Addresses」、RFC 4193、2005年10月、<http://www.rfc-editor.org/info/rfc4193>。
[RFC4251] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) Protocol Architecture", RFC 4251, January 2006, <http://www.rfc-editor.org/info/rfc4251>.
[RFC4251] Ylonen、T。およびC. Lonvick、「The Secure Shell（SSH）Protocol Architecture」、RFC 4251、2006年1月、<http://www.rfc-editor.org/info/rfc4251>。
[RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, January 2006, <http://www.rfc-editor.org/info/rfc4271>.
[RFC4271] Rekhter、Y.、Li、T。、およびS. Hares、「A Border Gateway Protocol 4（BGP-4）」、RFC 4271、2006年1月、<http://www.rfc-editor.org/ info / rfc4271>。
[RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification", RFC 4443, March 2006, <http://www.rfc-editor.org/info/rfc4443>.
[RFC4443] Conta、A.、Deering、S。、およびM. Gupta、「インターネットプロトコルバージョン6（IPv6）仕様のインターネット制御メッセージプロトコル（ICMPv6）」、RFC 4443、2006年3月、<http：// www .rfc-editor.org / info / rfc4443>。
[RFC4609] Savola, P., Lehtonen, R., and D. Meyer, "Protocol Independent Multicast - Sparse Mode (PIM-SM) Multicast Routing Security Issues and Enhancements", RFC 4609, October 2006, <http://www.rfc-editor.org/info/rfc4609>.
[RFC4609] Savola、P.、Lehtonen、R。、およびD. Meyer、「Protocol Independent Multicast-Sparse Mode（PIM-SM）Multicast Routing Security Issues and Enhancements」、RFC 4609、2006年10月、<http：// www .rfc-editor.org / info / rfc4609>。
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, September 2007, <http://rfc-editor.org/info/rfc4861>.
[RFC4861] Narten、T.、Nordmark、E.、Simpson、W。、およびH. Soliman、「Neighbor Discovery for IP version 6（IPv6）」、RFC 4861、2007年9月、<http：// rfc-editor。 org / info / rfc4861>。
[RFC4987] Eddy, W., "TCP SYN Flooding Attacks and Common Mitigations", RFC 4987, August 2007, <http://www.rfc-editor.org/info/rfc4987>.
[RFC4987] Eddy、W。、「TCP SYN Flooding Attacks and Common Mitigations」、RFC 4987、2007年8月、<http://www.rfc-editor.org/info/rfc4987>。
[RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF for IPv6", RFC 5340, July 2008, <http://www.rfc-editor.org/info/rfc5340>.
[RFC5340] Coltun、R.、Ferguson、D.、Moy、J。、およびA. Lindem、「OSPF for IPv6」、RFC 5340、2008年7月、<http://www.rfc-editor.org/info/ rfc5340>。
[RFC5837] Atlas, A., Bonica, R., Pignataro, C., Shen, N., and JR. Rivers, "Extending ICMP for Interface and Next-Hop Identification", RFC 5837, April 2010, <http://www.rfc-editor.org/info/rfc5837>.
[RFC5837] Atlas、A.、Bonica、R.、Pignataro、C.、Shen、N.、JR。 Rivers、「Extending ICMP for Interface and Next-Hop Identification」、RFC 5837、2010年4月、<http://www.rfc-editor.org/info/rfc5837>。
[RFC6192] Dugal, D., Pignataro, C., and R. Dunn, "Protecting the Router Control Plane", RFC 6192, March 2011, <http://www.rfc-editor.org/info/rfc6192>.
[RFC6192] Dugal、D.、Pignataro、C。、およびR. Dunn、「Protecting the Router Control Plane」、RFC 6192、2011年3月、<http://www.rfc-editor.org/info/rfc6192>。
[RFC6724] Thaler, D., Draves, R., Matsumoto, A., and T. Chown, "Default Address Selection for Internet Protocol Version 6 (IPv6)", RFC 6724, September 2012, <http://www.rfc-editor.org/info/rfc6724>.
[RFC6724] Thaler、D.、Draves、R.、Matsumoto、A。、およびT. Chown、「インターネットプロトコルバージョン6（IPv6）のデフォルトアドレス選択」、RFC 6724、2012年9月、<http：// www。 rfc-editor.org/info/rfc6724>。
[RFC6752] Kirkham, A., "Issues with Private IP Addressing in the Internet", RFC 6752, September 2012, <http://www.rfc-editor.org/info/rfc6752>.
[RFC6752] Kirkham、A。、「インターネットでのプライベートIPアドレッシングの問題」、RFC 6752、2012年9月、<http://www.rfc-editor.org/info/rfc6752>。
[RFC6860] Yang, Y., Retana, A., and A. Roy, "Hiding Transit-Only Networks in OSPF", RFC 6860, January 2013, <http://www.rfc-editor.org/info/rfc6860>.
[RFC6860] Yang、Y.、Retana、A。、およびA. Roy、「OSPFでの通過専用ネットワークの非表示」、RFC 6860、2013年1月、<http://www.rfc-editor.org/info/rfc6860 >。
Acknowledgments
謝辞
The authors would like to thank Salman Asadullah, Brian Carpenter, Bill Cerveny, Benoit Claise, Rama Darbha, Simon Eng, Wes George, Fernando Gont, Jen Linkova, Harald Michl, Janos Mohacsi, Ivan Pepelnjak, Alvaro Retana, Jinmei Tatuya, and Peter Yee for their useful comments about this work.
著者は、Salman Asadullah、Brian Carpenter、Bill Cerveny、Benoit Claise、Rama Darbha、Simon Eng、Wes George、Fernando Gont、Jen Linkova、Harald Michl、Janos Mohacsi、Ivan Pepelnjak、Alvaro Retana、Jinmei Tatuya、およびPeterに感謝します。この作業についての有益なコメントをありがとう。
Authors' Addresses
著者のアドレス
Michael Behringer Cisco Building D, 45 Allee des Ormes Mougins 06250 France
Michael BehringerシスコビルディングD、45アリーデオルムムジャン06250フランス
EMail: mbehring@cisco.com
Eric Vyncke Cisco De Kleetlaan, 6A Diegem 1831 Belgium
Eric Vyncke Cisco De Kleetlaan、6A Diegem 1831 Belgium
EMail: evyncke@cisco.com