[要約] RFC 5969は、IPv4インフラストラクチャ上でのIPv6の迅速な展開（6rd）のプロトコル仕様に関するものです。このRFCの目的は、IPv6の導入を迅速かつ効果的に行うための6rdプロトコルの仕様を提供することです。
Internet Engineering Task Force (IETF) W. Townsley
Request for Comments: 5969 O. Troan
Category: Standards Track Cisco
ISSN: 2070-1721 August 2010
IPv6 Rapid Deployment on IPv4 Infrastructures (6rd) -- Protocol Specification
IPv4インフラストラクチャ（6RD）でのIPv6迅速な展開 - プロトコル仕様
Abstract
概要
This document specifies an automatic tunneling mechanism tailored to advance deployment of IPv6 to end users via a service provider's IPv4 network infrastructure. Key aspects include automatic IPv6 prefix delegation to sites, stateless operation, simple provisioning, and service, which is equivalent to native IPv6 at the sites that are served by the mechanism.
このドキュメントは、サービスプロバイダーのIPv4ネットワークインフラストラクチャを介してIPv6のエンドユーザーに展開するように調整された自動トンネルメカニズムを指定します。主な側面には、サイトへの自動IPv6プレフィックス委任、ステートレス操作、簡単なプロビジョニング、およびサービスが含まれます。これは、メカニズムが提供するサイトでのネイティブIPv6と同等です。
Status of This Memo
本文書の位置付け
This is an Internet Standards Track document.
これは、インターネット標準トラックドキュメントです。
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). Further information on Internet Standards is available in Section 2 of RFC 5741.
このドキュメントは、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表しています。公開レビューを受けており、インターネットエンジニアリングステアリンググループ（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/rfc5969.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、http：//www.rfc-editor.org/info/rfc5969で取得できます。
Copyright Notice
著作権表示
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2010 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ドキュメント（http://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、単純化されたBSDライセンスで説明されているように保証なしで提供される簡略化されたBSDライセンステキストを含める必要があります。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Requirements Language . . . . . . . . . . . . . . . . . . . . 4
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. 6rd Prefix Delegation . . . . . . . . . . . . . . . . . . . . 5
5. Troubleshooting and Traceability . . . . . . . . . . . . . . . 7
6. Address Selection . . . . . . . . . . . . . . . . . . . . . . 7
7. 6rd Configuration . . . . . . . . . . . . . . . . . . . . . . 7
7.1. Customer Edge Configuration . . . . . . . . . . . . . . . 8
7.1.1. 6rd DHCPv4 Option . . . . . . . . . . . . . . . . . . 9
7.2. Border Relay Configuration . . . . . . . . . . . . . . . . 10
8. Neighbor Unreachability Detection . . . . . . . . . . . . . . 11
9. IPv6 in IPv4 Encapsulation . . . . . . . . . . . . . . . . . . 12
9.1. Maximum Transmission Unit . . . . . . . . . . . . . . . . 13
9.2. Receiving Rules . . . . . . . . . . . . . . . . . . . . . 13
10. Transition Considerations . . . . . . . . . . . . . . . . . . 14
11. IPv6 Address Space Usage . . . . . . . . . . . . . . . . . . . 14
12. Security Considerations . . . . . . . . . . . . . . . . . . . 15
13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16
15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
15.1. Normative References . . . . . . . . . . . . . . . . . . . 16
15.2. Informative References . . . . . . . . . . . . . . . . . . 17
The original idea and the name of the mechanism (6rd) described in [RFC5569] details a successful commercial "rapid deployment" of the 6rd mechanism by a residential service provider and is recommended reading. This document describes the 6rd mechanism, which has been extended for use in more general environments. Throughout this document, the term 6to4 is used to refer to the mechanism described in [RFC3056] and 6rd is the mechanism defined herein.
[RFC5569]に記載されているメカニズムの名前とメカニズムの名前（第6）は、住宅サービスプロバイダーによる第6メカニズムの成功した「迅速な展開」を詳述し、読書を推奨しています。このドキュメントでは、より一般的な環境で使用するために拡張された第6メカニズムについて説明します。このドキュメント全体で、6to4という用語は[RFC3056]で説明されているメカニズムを参照するために使用され、6番目は本明細書で定義されているメカニズムです。
6rd specifies a protocol mechanism to deploy IPv6 to sites via a service provider's (SP's) IPv4 network. It builds on 6to4 [RFC3056], with the key differentiator that it utilizes an SP's own IPv6 address prefix rather than a well-known prefix (2002::/16). By using the SP's IPv6 prefix, the operational domain of 6rd is limited to the SP network and is under its direct control. From the perspective of customer sites and the IPv6 Internet at large, the IPv6 service provided is equivalent to native IPv6.
6RDは、サービスプロバイダー（SP）IPv4ネットワークを介してIPv6をサイトに展開するプロトコルメカニズムを指定します。6to4 [RFC3056]に構築され、よく知られているプレフィックス（2002 ::/16）ではなく、SP独自のIPv6アドレスプレフィックスを使用する重要な差別化要因があります。SPのIPv6プレフィックスを使用することにより、6番目の動作ドメインはSPネットワークに限定され、その直接制御下にあります。顧客サイトとIPv6インターネット全体の観点から見ると、提供されるIPv6サービスはネイティブIPv6と同等です。
The 6rd mechanism relies upon an algorithmic mapping between the IPv6 and IPv4 addresses that are assigned for use within the SP network. This mapping allows for automatic determination of IPv4 tunnel endpoints from IPv6 prefixes, allowing stateless operation of 6rd.
第6メカニズムは、SPネットワーク内で使用するために割り当てられているIPv6アドレスとIPv4アドレスの間のアルゴリズムマッピングに依存しています。このマッピングにより、IPv6プレフィックスからのIPv4トンネルエンドポイントの自動決定が可能になり、第6のステートレス操作が可能になります。
6rd views the IPv4 network as a link layer for IPv6 and supports an automatic tunneling abstraction similar to the Non-Broadcast Multiple Access (NBMA) [RFC2491] model.
6RDは、IPv4ネットワークをIPv6のリンクレイヤーと見なし、非放送マルチアクセス（NBMA）[RFC2491]モデルと同様の自動トンネル抽象化をサポートします。
A 6rd domain consists of 6rd Customer Edge (CE) routers and one or more 6rd Border Relays (BRs). IPv6 packets encapsulated by 6rd follow the IPv4 routing topology within the SP network among CEs and BRs. 6rd BRs are traversed only for IPv6 packets that are destined to or are arriving from outside the SP's 6rd domain. As 6rd is stateless, BRs may be reached using anycast for failover and resiliency (in a similar fashion to [RFC3068]).
第6ドメインは、第6顧客エッジ（CE）ルーターと1つ以上の第6ボーダーリレー（BRS）で構成されています。6番目にカプセル化されたIPv6パケットは、CESとBRSの間のSPネットワーク内のIPv4ルーティングトポロジに従います。6番目のBRSは、SPの6番目のドメインの外側から到着している、または到着しているIPv6パケットのみで移動されます。6番目は無国籍であるため、BRSは、Anycastを使用してフェールオーバーと回復力を使用して到達することができます（[RFC3068]と同様の方法で）。
On the "customer-facing" (i.e., "LAN") side of a CE, IPv6 is implemented as it would be for any native IP service delivered by the SP, and further considerations for IPv6 operation on the LAN side of the CE is out of scope for this document. On the "SP-facing" (i.e., "WAN") side of the 6rd CE, the WAN interface itself, encapsulation over Ethernet, ATM or PPP, as well as control protocols such as PPPoE, IPCP, DHCP, etc. all remain unchanged from current IPv4 operation. Although 6rd was designed primarily to support IPv6 deployment to a customer site (such as a residential home network) by an SP, it can equally be applied to an individual IPv6 host acting as a CE.
CEの「顧客向け」（すなわち、「LAN」）側では、IPv6はSPによって配信されるネイティブIPサービスのために実装され、CEのLAN側でのIPv6操作のさらなる考慮事項は次のとおりです。このドキュメントの範囲外。第6 CEの「SP顔」（つまり、「WAN」）側、WANインターフェイス自体、イーサネット、ATM、またはPPP上のカプセル化、およびPPPOE、IPCP、DHCPなどの制御プロトコルはすべて残っています。現在のIPv4操作から変更されていません。6rdは、主にSPによって顧客サイト（住宅ネットワークなど）へのIPv6の展開をサポートするように設計されていますが、CEとして機能する個々のIPv6ホストに等しく適用できます。
6rd relies on IPv4 and is designed to deliver production-quality IPv6 alongside IPv4 with as little change to IPv4 networking and operations as possible. Native IPv6 deployment within the SP network itself may continue for the SP's own purposes while delivering IPv6 service to sites supported by 6rd. Once the SP network and operations can support fully native IPv6 access and transport, 6rd may be discontinued.
6RDはIPv4に依存しており、IPv4と一緒に生産品質のIPv6を提供するように設計されています。IPv4ネットワーキングと操作は可能な限り変更しません。SPネットワーク内でのネイティブIPv6の展開自体は、SP自身の目的のために継続する可能性があり、第6回サポートされているサイトにIPv6サービスを提供します。SPネットワークと操作が完全にネイティブのIPv6アクセスとトランスポートをサポートできるようになると、6番目が中止される可能性があります。
6rd utilizes the same encapsulation and base mechanism as 6to4 and could be viewed as a superset of 6to4 (6to4 could be achieved by setting the 6rd prefix to 2002::/16). Unlike 6to4, 6rd is for use only in an environment where a service provider closely manages the delivery of IPv6 service. 6to4 routes with the 2002::/16 prefix may exist alongside 6rd in the 6rd CE router, and doing so may offer some efficiencies when communicating directly with 6to4 routers.
6RDは、6to4と同じカプセル化とベースメカニズムを使用し、6to4のスーパーセットと見なすことができます（6to4を2002年::/16に設定することで達成できます）。6to4とは異なり、6番目は、サービスプロバイダーがIPv6サービスの配信を密接に管理する環境でのみ使用するためです。2002年の6to4ルート::/16プレフィックスは、6番目のCEルーターで6番目と一緒に存在する可能性があります。6to4ルーターと直接通信する際には、効率が得られる場合があります。
The 6rd link model can be extended to support IPv6 multicast. IPv6 multicast support is left for future consideration.
第6リンクモデルを拡張して、IPv6マルチキャストをサポートできます。IPv6マルチキャストサポートは、将来の検討のために残されています。
How this mechanism should be used and other deployment and operational considerations are considered out of scope for this document.
このメカニズムをどのように使用するか、およびその他の展開と運用上の考慮事項は、このドキュメントの範囲外であると見なされます。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
この文書のキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", および "OPTIONAL" はRFC 2119 [RFC2119]で説明されているように解釈されます。
6rd prefix An IPv6 prefix selected by the service provider for use by a 6rd domain. There is exactly one 6rd prefix for a given 6rd domain. An SP may deploy 6rd with a single 6rd domain or multiple 6rd domains.
第6ドメインで使用するためにサービスプロバイダーによって選択された6番目のプレフィックスIPv6プレフィックス。特定の第6ドメインには、正確に1つの6番目のプレフィックスがあります。SPは、単一の6rdドメインまたは複数の6rdドメインを備えた6番目の6番目を展開できます。
6rd Customer Edge (6rd CE) A device functioning as a Customer Edge router in a 6rd deployment. In a residential broadband deployment, this type of device is sometimes referred to as a "Residential Gateway" (RG) or "Customer Premises Equipment" (CPE). A typical 6rd CE serving a residential site has one WAN side interface, one or more LAN side interfaces, and a 6rd virtual interface. A 6rd CE may also be referred to simply as a "CE" within the context of 6rd.
第6カスタマーエッジ（第6 CE）第6展開で顧客エッジルーターとして機能するデバイス。住宅用ブロードバンドの展開では、このタイプのデバイスは、「住宅ゲートウェイ」（RG）または「顧客施設機器」（CPE）と呼ばれることがあります。住宅サイトにサービスを提供する典型的な第6 CEには、1つのWAN側インターフェイス、1つ以上のLAN側インターフェイス、および6番目の仮想インターフェイスがあります。第6 CEは、6番目のコンテキスト内で単に「CE」と呼ばれることもあります。
6rd delegated prefix The IPv6 prefix calculated by the CE for use within the customer site by combining the 6rd prefix and the CE IPv4 address obtained via IPv4 configuration methods. This prefix can be considered logically equivalent to a DHCPv6 IPv6 delegated prefix [RFC3633].
第6委任プレフィックス6番目のプレフィックスとIPv4構成法を介して取得したCE IPv4アドレスを組み合わせて、顧客サイト内で使用するためにCEによって計算されたIPv6プレフィックス。このプレフィックスは、DHCPV6 IPv6委任プレフィックス[RFC3633]と論理的に同等であると見なすことができます。
6rd domain A set of 6rd CEs and BRs connected to the same virtual 6rd link. A service provider may deploy 6rd with a single 6rd domain, or may utilize multiple 6rd domains. Each domain requires a separate 6rd prefix.
6番目のドメイン同じ仮想6rdリンクに接続された6番目のCEとBRSのセット。サービスプロバイダーは、単一の6番目のドメインで6番目の展開を展開するか、複数の6番目のドメインを使用する場合があります。各ドメインには、個別の6番目のプレフィックスが必要です。
CE LAN side The functionality of a 6rd CE that serves the "Local Area Network (LAN)" or "customer-facing" side of the CE. The CE LAN side interface is fully IPv6 enabled.
CE LAN側「CEの「ローカルエリアネットワーク（LAN）」または「顧客向け」側にサービスを提供する第6 CEの機能。CE LANサイドインターフェイスは完全にIPv6を有効にしています。
CE WAN side The functionality of a 6rd CE that serves the "Wide Area Network (WAN)" or "Service Provider-facing" side of the CE. The CE WAN side is IPv4-only.
CE WANサイドCEの「ワイドエリアネットワーク（WAN）」または「サービスプロバイダー向け」側にサービスを提供する第6 CEの機能。CE WAN側はIPv4のみです。
6rd Border Relay (BR) A 6rd-enabled router managed by the service provider at the edge of a 6rd domain. A Border Relay router has at least one of each of the following: an IPv4-enabled interface, a 6rd virtual interface acting as an endpoint for the 6rd IPv6 in IPv4 tunnel, and an IPv6 interface connected to the native IPv6 network. A 6rd BR may also be referred to simply as a "BR" within the context of 6rd.
第6ボーダーリレー（BR）第6ドメインの端にあるサービスプロバイダーによって管理される6番目の対応ルーター。ボーダーリレールーターには、以下のそれぞれの少なくとも1つがあります。IPv4対応インターフェイス、IPv4トンネルの6番目のIPv6のエンドポイントとして機能する6番目の仮想インターフェイス、およびネイティブIPv6ネットワークに接続されたIPv6インターフェイス。6番目のBRは、6番目のコンテキスト内で単に「BR」と呼ばれることもあります。
BR IPv4 address The IPv4 address of the 6rd Border Relay for a given 6rd domain. This IPv4 address is used by the CE to send packets to a BR in order to reach IPv6 destinations outside of the 6rd domain.
BR IPv4アドレス指定された第6ドメインの第6ボーダーリレーのIPv4アドレス。このIPv4アドレスは、CEによって使用され、第6ドメインの外側のIPv6宛先に到達するためにパケットをBRに送信します。
6rd virtual interface Internal multi-point tunnel interface where 6rd encapsulation and decapsulation of IPv6 packets inside IPv4 occurs. A typical CE or BR implementation requires only one 6rd virtual interface. A BR operating in multiple 6rd domains may require more than one 6rd virtual interface, but no more than one per 6rd domain.
6番目の仮想インターフェイス内部マルチポイントトンネルインターフェイスでは、IPv4内のIPv6パケットの6番目のカプセル化と脱カプセル化が発生します。典型的なCEまたはBRの実装では、1つの6番目の仮想インターフェイスのみが必要です。複数の6番目のドメインで動作するBRは、6回目のドメインごとに複数の6番目の仮想インターフェイスを必要とする場合があります。
CE IPv4 address The IPv4 address given to the CE as part of normal IPv4 Internet access (i.e., configured via DHCP, PPP, or otherwise). This address may be global or private [RFC1918] within the 6rd domain. This address is used by a 6rd CE to create the 6rd delegated prefix as well as to send and receive IPv4-encapsulated IPv6 packets.
CE IPv4は、通常のIPv4インターネットアクセスの一部としてCEに与えられたIPv4アドレスをアドレスします（つまり、DHCP、PPP、またはその他を介して構成されています）。このアドレスは、第6ドメイン内のグローバルまたはプライベート[RFC1918]である場合があります。このアドレスは、第6 CEで使用され、第6委任されたプレフィックスを作成し、IPv4で覆われたIPv6パケットを送信および受信します。
The 6rd delegated prefix for use at a customer site is created by combining the 6rd prefix and all or part of the CE IPv4 address. From these elements, the 6rd delegated prefix is automatically created by the CE for the customer site when IPv4 service is obtained. This 6rd delegated prefix is used in the same manner as a prefix obtained via DHCPv6 prefix delegation [RFC3633].
顧客サイトで使用するための第6委任されたプレフィックスは、6番目のプレフィックスとCE IPv4アドレスのすべてまたは一部を組み合わせて作成されます。これらの要素から、IPv4サービスが取得されたときに、第6委任されたプレフィックスは、顧客サイトのCEによって自動的に作成されます。この第6委任されたプレフィックスは、DHCPV6プレフィックス委任[RFC3633]を介して取得されたプレフィックスと同じ方法で使用されます。
In 6to4, a similar operation is performed by incorporating an entire IPv4 address at a fixed location following a well-known /16 IPv6 prefix. In 6rd, the IPv6 prefix as well as the position and number of bits of the IPv4 address incorporated varies from one 6rd domain to the next. 6rd allows the SP to adjust the size of the 6rd prefix, how many bits are used by the 6rd mechanism, and how many bits are left to be delegated to customer sites. To allow for stateless address auto-configuration on the CE LAN side, a 6rd delegated prefix SHOULD be /64 or shorter.
6to4では、よく知られている /16 IPv6プレフィックスに続いて、固定場所にIPv4アドレス全体を組み込むことにより、同様の操作が実行されます。6番目では、IPv6アドレスのIPv6プレフィックスとIPv4アドレスのビットの位置と数は、6番目のドメインから次のドメインまで変化します。第6回では、SPが6番目のプレフィックスのサイズ、6番目のメカニズムで使用されるビットの数、および顧客サイトに委任されるビットの数を調整できます。CE LAN側でのステートレスアドレスの自動構成を可能にするには、6番目の委任されたプレフィックスが /64以下である必要があります。
The 6rd delegated prefix is created by concatenating the 6rd prefix and a consecutive set of bits from the CE IPv4 address in order. The length of the 6rd delegated prefix is equal to length of the 6rd prefix (n) plus the number of bits from the CE IPv4 address (o).
第6委任されたプレフィックスは、6番目のプレフィックスとCE IPv4アドレスから連続したビットのセットを順番に連結することにより作成されます。第6委任されたプレフィックスの長さは、6番目のプレフィックス（n）の長さに加えて、CE IPv4アドレス（O）からのビット数に等しくなります。
The figure shows the format of an IPv6 address (Section 2.5.4 of [RFC4291]) with a 6rd prefix and an embedded CE IPv4 address:
この図は、6番目のプレフィックスと埋め込まれたCE IPv4アドレスを備えたIPv6アドレス（[RFC4291]のセクション2.5.4）の形式を示しています。
| n bits | o bits | m bits | 128-n-o-m bits |
+---------------+--------------+-----------+------------------------+
| 6rd prefix | IPv4 address | subnet ID | interface ID |
+---------------+--------------+-----------+------------------------+
|<--- 6rd delegated prefix --->|
Figure 1
図1
For example, if the 6rd prefix is /32 and 24 bits of the CE IPv4 address is used (e.g., all CE IPv4 addresses can be aggregated by a 10.0.0.0/8), then the size of the 6rd delegated prefix for each CE is automatically calculated to be /56 (32 + 24 = 56).
たとえば、CE IPv4アドレスの6番目のプレフィックスが /32および24ビットの場合（たとえば、すべてのCE IPv4アドレスを10.0.0.0/8で集約できます）、各CEの6番目の委任されたプレフィックスのサイズのサイズ/56（32 24 = 56）に自動的に計算されます。
Embedding less than the full 32 bits of a CE IPv4 address is possible only when an aggregated block of IPv4 addresses is available for a given 6rd domain. This may not be practical with global IPv4 addresses, but is quite likely in a deployment where private addresses are being assigned to CEs. If private addresses overlap within a given 6rd deployment, the deployment may be divided into separate 6rd domains, likely along the same topology lines the NAT-based IPv4 deployment itself would require. In this case, each domain is addressed with a different 6rd prefix.
CE IPv4アドレスの完全な32ビット未満の埋め込みは、特定の第6ドメインでIPv4アドレスの集約ブロックが利用可能である場合にのみ可能です。これは、グローバルIPv4アドレスでは実用的ではない場合がありますが、プライベートアドレスがCESに割り当てられている展開では可能性が非常に高いです。特定の第6展開内でプライベートアドレスが重複する場合、展開は、NATベースのIPv4展開自体が必要とする同じトポロジラインに沿って、おそらく別々の第6ドメインに分割される可能性があります。この場合、各ドメインは別の6番目のプレフィックスでアドレス指定されます。
Each 6rd domain may use a different encoding of the embedded IPv4 address, even within the same service provider. For example, if multiple IPv4 address blocks with different levels of aggregation are used at the same service provider, the number of IPv4 bits needed to encode the 6rd delegated prefix may vary between each block. In this case, different 6rd prefixes, and hence separate 6rd domains, may be used to support the different encodings.
各6番目のドメインは、同じサービスプロバイダー内であっても、埋め込まれたIPv4アドレスの異なるエンコードを使用できます。たとえば、同じサービスプロバイダーで異なるレベルの集約を持つ複数のIPv4アドレスブロックが使用されている場合、6番目の委任されたプレフィックスをエンコードするのに必要なIPv4ビットの数は、各ブロック間で異なる場合があります。この場合、異なる第6端のプレフィックス、したがって別の第6ドメインを使用して、異なるエンコーディングをサポートすることができます。
Since 6rd delegated prefixes are selected algorithmically from an IPv4 address, changing the IPv4 address will cause a change in the IPv6 delegated prefix which would ripple through the site's network and could be disruptive. As such, it is recommended that the service provider assign CE IPv4 addresses with relatively long lifetimes.
6番目の委任されたプレフィックスはIPv4アドレスからアルゴリズム的に選択されるため、IPv4アドレスを変更すると、サイトのネットワークを横切って破壊する可能性のあるIPv6委任されたプレフィックスが変更されます。そのため、サービスプロバイダーがCE IPv4アドレスを比較的長い寿命に割り当てることをお勧めします。
6rd IPv6 address assignment, and hence the IPv6 service itself, is tied to the IPv4 address lease; thus, the 6rd service is also tied to this in terms of authorization, accounting, etc. For example, the 6rd delegated prefix has the same lifetime as its associated IPv4 address. The prefix lifetimes advertised in Router Advertisements or used by DHCP on the CE LAN side MUST be equal to or shorter than the IPv4 address lease time. If the IPv4 lease time is not known, the lifetime of the 6rd delegated prefix SHOULD follow the defaults specified in [RFC4861].
6番目のIPv6アドレスの割り当て、したがってIPv6サービス自体は、IPv4アドレスリースに関連付けられています。したがって、第6サービスは、承認、会計などの観点からもこれに関連付けられています。たとえば、第6委任されたプレフィックスは、関連するIPv4アドレスと同じ寿命を持っています。ルーター広告で宣伝されている、またはCE LAN側のDHCPによって使用される接頭辞寿命は、IPv4アドレスリース時間と等しいか短くする必要があります。IPv4リース時間がわからない場合、第6委任されたプレフィックスの寿命は、[RFC4861]で指定されたデフォルトに従う必要があります。
A 6rd IPv6 address and associated IPv4 address for a given customer can always be determined algorithmically by the service provider that operates the given 6rd domain. This may be useful for referencing logs and other data at a service provider that may have more robust operational tools for IPv4 than IPv6. This also allows IPv4 data path, node, and endpoint monitoring to be applicable to IPv6.
特定の顧客の第6 IPv6アドレスと関連するIPv4アドレスは、特定の第6ドメインを操作するサービスプロバイダーによって常にアルゴリズム的に決定できます。これは、IPv6よりもIPv4の堅牢な動作ツールを持つ可能性のあるサービスプロバイダーでログやその他のデータを参照するのに役立つ場合があります。これにより、IPv4データパス、ノード、およびエンドポイントモニタリングをIPv6に適用できるようになります。
The 6rd CE and BR SHOULD support the IPv6 Subnet-Router anycast address [RFC4291] for its own 6rd delegated prefix. This allows, for example, IPv6 ICMP echo messages to be sent to the 6rd virtual interface itself for additional troubleshooting of the internal operation of 6rd at a given CE or BR. In the case of the BR, the IPv4 address used to calculate the 6rd delegated prefix is the configured BR IPv4 address.
第6 CEとBRは、独自の第6委任プレフィックスについて、IPv6サブネットルーターAnycastアドレス[RFC4291]をサポートする必要があります。これにより、たとえば、IPv6 ICMPエコーメッセージを6番目の仮想インターフェイス自体に送信して、特定のCEまたはBRで6番目の内部操作の追加トラブルシューティングを行うことができます。BRの場合、第6委任されたプレフィックスの計算に使用されるIPv4アドレスは、構成されたBR IPv4アドレスです。
All addresses assigned from 6rd delegated prefixes should be treated as native IPv6. No changes to the source address selection or destination address selection policy table [RFC3484] are necessary.
6番目の委任されたプレフィックスから割り当てられたすべてのアドレスは、ネイティブIPv6として扱う必要があります。ソースアドレスの選択または宛先アドレスの選択ポリシーテーブル[RFC3484]の変更は必要ありません。
For a given 6rd domain, the BR and CE MUST be configured with the following four 6rd elements. The configured values for these four 6rd elements are identical for all CEs and BRs within a given 6rd domain.
特定の第6ドメインの場合、BRとCEは、次の4つの6番目の要素で構成する必要があります。これらの4つの6番目の要素の構成された値は、特定の6番目のドメイン内のすべてのCEとBRに対して同一です。
IPv4MaskLen The number of high-order bits that are identical across all CE IPv4 addresses within a given 6rd domain. For example, if there are no identical bits, IPv4MaskLen is 0 and the entire CE IPv4 address is used to create the 6rd delegated prefix. If there are 8 identical bits (e.g., the Private IPv4 address range 10.0.0.0/8 is being used), IPv4MaskLen is equal to 8 and IPv4MaskLen high-order bits are stripped from the IPv4 address before constructing the corresponding 6rd delegated prefix.
IPv4Masklen特定の第6ドメイン内のすべてのCE IPv4アドレスで同一の高次ビットの数。たとえば、同一のビットがない場合、IPv4Masklenは0であり、CE IPv4アドレス全体を使用して6番目の委任されたプレフィックスを作成します。同一のビットが8つある場合（たとえば、プライベートIPv4アドレス範囲10.0.0.0/8が使用されています）、IPv4Masklenは8に等しく、IPv4Masklenの高次ビットはIPv4アドレスから剥がれ、対応する6番目の委任されたプレフィックスを構築します。
6rdPrefix The 6rd IPv6 prefix for the given 6rd domain.
6RDPREFIX指定された第6ドメインの第6 IPv6プレフィックス。
6rdPrefixLen The length of the 6rd IPv6 prefix for the given 6rd domain.
6RDPREFIXLEN指定された第6ドメインの6番目のIPv6プレフィックスの長さ。
6rdBRIPv4Address The IPv4 address of the 6rd Border Relay for a given 6rd domain.
6RDBRIPV4ADDRESS特定の第6ドメインの第6ボーダーリレーのIPv4アドレス。
The four 6rd elements are set to values that are the same across all CEs within a 6rd domain. The values may be configured in a variety of manners, including provisioning methods such as the Broadband Forum's "TR-69" [TR069] Residential Gateway management interface, an XML-based object retrieved after IPv4 connectivity is established, a DNS record, an SMIv2 MIB [RFC2578], PPP IPCP, or manual configuration by an administrator. This document describes how to configure the necessary parameters via a single DHCP option. A CE that allows IPv4 configuration by DHCP SHOULD implement this option. Other configuration and management methods may use the format described by this option for consistency and convenience of implementation on CEs that support multiple configuration methods.
4つの6番目の要素は、6番目のドメイン内のすべてのCEで同じ値に設定されています。値は、ブロードバンドフォーラムの「TR-69」[TR-69]住宅ゲートウェイ管理インターフェイス、IPv4接続が確立された後に取得されたXMLベースのオブジェクト、DNSレコード、SMIV22などのプロビジョニング方法など、さまざまなマナーで構成できます。MIB [RFC2578]、PPP IPCP、または管理者による手動構成。このドキュメントでは、単一のDHCPオプションを介して必要なパラメーターを構成する方法について説明します。DHCPによるIPv4構成を許可するCEは、このオプションを実装する必要があります。その他の構成および管理方法は、複数の構成方法をサポートするCESでの実装の一貫性と利便性のために、このオプションで説明されている形式を使用する場合があります。
The only remaining provisioning information the CE requires in order to calculate the 6rd delegated prefix and enable IPv6 connectivity is an IPv4 address for the CE. This CE IPv4 address is configured as part of obtaining IPv4 Internet access (i.e., configured via DHCP, PPP, or otherwise). This address may be global or private [RFC1918] within the 6rd domain.
第6委任されたプレフィックスを計算し、IPv6接続を有効にするためにCEが必要とする唯一の残りのプロビジョニング情報は、CEのIPv4アドレスです。このCE IPv4アドレスは、IPv4インターネットアクセスの取得の一部として構成されています（つまり、DHCP、PPP、またはその他を介して構成されています）。このアドレスは、第6ドメイン内のグローバルまたはプライベート[RFC1918]である場合があります。
A single 6rd CE MAY be connected to more than one 6rd domain, just as any router may have more than one IPv6-enabled service provider facing interface and more than one set of associated delegated prefixes assigned by DHCPv6 prefix delegation or other means. Each domain a given CE operates within would require its own set of 6rd configuration elements and would generate its own 6rd delegated prefix.
1つの第6 CEは、複数のIPv6対応サービスプロバイダーがインターフェイスに面した複数のIPv6対応サービスプロバイダーと、DHCPV6プレフィックス委任または他の平均によって割り当てられた複数の関連する委任されたプレフィックスを備えている可能性があるため、1つの第6 CEが複数の6番目のドメインに接続される場合があります。特定のCEが操作する各ドメインは、6番目の構成要素の独自のセットを必要とし、独自の6番目の委任されたプレフィックスを生成します。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPTION_6RD | option-length | IPv4MaskLen | 6rdPrefixLen |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| 6rdPrefix |
| (16 octets) |
| |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 6rdBRIPv4Address(es) |
. .
. .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2
図2
option-code OPTION_6RD (212)
オプションコードオプション_6rd（212）
option-length The length of the DHCP option in octets (22 octets with one BR IPv4 address).
オプション長DHCPオプションの長さのオクテット（1つのBR IPv4アドレスを備えた22オクテット）。
IPv4MaskLen The number of high-order bits that are identical across all CE IPv4 addresses within a given 6rd domain. This may be any value between 0 and 32. Any value greater than 32 is invalid.
IPv4Masklen特定の第6ドメイン内のすべてのCE IPv4アドレスで同一の高次ビットの数。これは0〜32の任意の値である場合があります。32を超える値は無効です。
6rdPrefixLen The IPv6 prefix length of the SP's 6rd IPv6 prefix in number of bits. For the purpose of bounds checking by DHCP option processing, the sum of (32 - IPv4MaskLen) + 6rdPrefixLen MUST be less than or equal to 128.
6RDPREFIXLEN SPの6番目のIPv6プレフィックスのIPv6プレフィックスの長さは、ビット数にあります。DHCPオプション処理による境界チェックの目的のために、（32 -IPv4Masklen）6RDPREFIXLENの合計は128以下でなければなりません。
6rdBRIPv4Address One or more IPv4 addresses of the 6rd Border Relay(s) for a given 6rd domain.
6RDBRIPV4ADDRESS特定の第6ドメインの第6ボーダーリレーの1つ以上のIPv4アドレス。
6rdPrefix The service provider's 6rd IPv6 prefix represented as a 16-octet IPv6 address. The bits in the prefix after the 6rdPrefixlen number of bits are reserved and MUST be initialized to zero by the sender and ignored by the receiver.
6RDPREFIXサービスプロバイダーの第6 IPv6プレフィックスは、16オクテットのIPv6アドレスとして表されます。第6回のビット数のビット数が予約された後のプレフィックス内のビットは、送信者によってゼロに初期化され、受信機によって無視される必要があります。
The CE MUST include a Parameter Request List Option [RFC2132] for the OPTION_6RD. Because the OPTION_6RD contains one IPv4MaskLen/ 6rdPrefixLen/6rdPrefix block, and because DHCP cannot convey more than one instance of an option, OPTION_6RD is limited to provision at most a single 6rd domain. Provisioning of a CE router connected to multiple 6rd domains is outside the scope of this protocol specification.
CEには、option_6rdのパラメーター要求リストオプション[RFC2132]を含める必要があります。Option_6rdには1つのIPv4Masklen/ 6RDPREFIXLEN/ 6RDPREFIXブロックが含まれているため、DHCPがオプションの複数のインスタンスを伝えることができないため、Option_6rdは最大の6番目のドメインで制限されます。複数の6RDドメインに接続されたCEルーターのプロビジョニングは、このプロトコル仕様の範囲外です。
The presence of the OPTION_6RD DHCP option is an indication of the availability of the 6rd service. By default, receipt of a valid 6rd DHCP option by a 6rd-capable CE results in configuration of the 6rd virtual interface and associated delegated prefix for use on the CE's LAN side. The CE MUST be able to configure the 6rd mechanism to be disabled, in which case the 6rd DHCP option, if received, is silently ignored.
Option_6rd DHCPオプションの存在は、第6サービスの可用性を示しています。デフォルトでは、6回目のCEによる有効な第6 DHCPオプションの受信により、CEのLAN側で使用するための6番目の仮想インターフェイスと関連する委任されたプレフィックスが構成されます。CEは、無効化する第6メカニズムを構成できる必要があります。その場合、受信した場合、第6 DHCPオプションは静かに無視されます。
A detailed description of CE behavior using multiple BR IPv4 addresses is left for future consideration. In such a case, a CE MUST support at least one BR IPv4 address and MAY support more than one.
複数のBR IPv4アドレスを使用したCEの動作の詳細な説明は、将来の検討のために残されています。そのような場合、CEは少なくとも1つのBR IPv4アドレスをサポートする必要があり、複数のBR IPv4アドレスをサポートする必要があります。
When 6rd is enabled, a typical CE router will install a default route to the BR, a black hole route for the 6rd delegated prefix, and routes for any LAN side assigned and advertised prefixes. For example, using a CE IPv4 address of 10.100.100.1, a BR IPv4 address of 10.0.0.1, an IPv4MaskLen of 8, 2001:db8::/32 as the 6rdPrefix, and one /64 prefix assigned to a LAN side interface, a typical CE routing table will look like:
6RDが有効になると、典型的なCEルーターがBRへのデフォルトルート、6番目の委任されたプレフィックスのブラックホールルート、および割り当ておよび宣伝されたプレフィックスの任意のLAN側のルートをインストールします。たとえば、10.100.100.1のCE IPv4アドレス、10.0.0.1のBR IPv4アドレス、2001年8月のIPv4Masklen：db8 :: /32は6rdprefixとして、およびLAN側界面に割り当てられた1 /64プレフィックスを使用して、典型的なCEルーティングテーブルは次のようになります。
::/0 -> 6rd-virtual-int0 via 2001:db8:0:100:: (default route)
2001:db8::/32 -> 6rd-virtual-int0 (direct connect to 6rd)
2001:db8:6464:100::/56 -> Null0 (delegated prefix null route)
2001:db8:6464:100::/64 -> Ethernet0 (LAN interface)
The 6rd BR MUST be configured with the same 6rd elements as the 6rd CEs operating within the same domain.
第6 BRは、同じドメイン内で動作する第6 CESと同じ第6要素で構成する必要があります。
For increased reliability and load balancing, the BR IPv4 address may be an anycast address shared across a given 6rd domain. As 6rd is stateless, any BR may be used at any time. If the BR IPv4 address is anycast the relay MUST use this anycast IPv4 address as the source address in packets relayed to CEs.
信頼性と負荷分散を増やすために、BR IPv4アドレスは、特定の6番目のドメインで共有されるAnycastアドレスである可能性があります。6番目はステートレスであるため、任意のBRはいつでも使用できます。BR IPv4アドレスがANYCASTの場合、リレーはこのANYCAST IPv4アドレスを使用する必要があります。
Since 6rd uses provider address space, no specific routes need to be advertised externally for 6rd to operate, neither in IPv6 nor IPv4 BGP. However, if anycast is used for the 6rd IPv4 relays, the anycast addresses must be advertised in the service provider's IGP.
6番目はプロバイダーアドレススペースを使用しているため、IPv6またはIPv4 BGPでは、6番目の操作のために外部から特定のルートを宣伝する必要はありません。ただし、6番目のIPv4リレーにanycastが使用されている場合、AnycastアドレスはサービスプロバイダーのIGPで宣伝する必要があります。
Neighbor Unreachability Detection (NUD) for tunnels is described in Section 3.8 of [RFC4213]. In 6rd, all CEs and BRs can be considered as connected to the same virtual link and therefore neighbors to each other. This section describes how to utilize neighbor unreachability detection without negatively impacting the scalability of a 6rd deployment.
トンネルの近隣の到達不能（NUD）は、[RFC4213]のセクション3.8で説明されています。6番目に、すべてのCEとBRSは、同じ仮想リンクに接続されていると見なすことができ、したがって互いに隣接するものと見なすことができます。このセクションでは、6番目の展開のスケーラビリティに悪影響を与えることなく、近隣の到達性検出を利用する方法について説明します。
A typical 6rd deployment may consist of a very large number of CEs within the same domain. Reachability between CEs is based on IPv4 routing, and sending NUD or any periodic packets between 6rd CE devices beyond isolated troubleshooting of the 6rd mechanism is NOT RECOMMENDED.
典型的な第6展開は、同じドメイン内の非常に多数のCEで構成される場合があります。CES間の到達可能性はIPv4ルーティングに基づいており、第6メカニズムの分離されたトラブルシューティングを超えて、NUDまたは第6 CEデバイス間で定期的なパケットを送信することは推奨されません。
While reachability detection between a given 6rd CE and BR is not necessary for the proper operation of 6rd, in cases where a CE has alternate paths for BR reachability to choose from, it could be useful. Sending NUD messages to a BR, in particular periodic messages from a very large number of CEs, could result in overloading of the BR control message processing path, negatively affecting scalability of the 6rd deployment. Instead, a CE that needs to determine BR reachability MUST utilize a method that allows reachability detection packets to follow a typical data forwarding path without special processing by the BR. One such method is described below.
特定の第6 CEとBRの間の到達可能性検出は、第6回の適切な動作には必要ありませんが、CEにBRリーチ性を選択できる代替パスがある場合、有用です。NUDメッセージをBRに送信すると、特に非常に多数のCESからの定期的なメッセージが、BRコントロールメッセージ処理パスの過負荷につながり、第6展開のスケーラビリティに悪影響を与える可能性があります。代わりに、BRリーチ性を決定する必要があるCEは、到達可能性検出パケットがBRによる特別な処理なしに典型的なデータ転送パスに従うことができる方法を利用する必要があります。そのような方法の1つについては、以下に説明します。
1. The CE constructs a payload of any size and content to be sent to the BR (e.g., a zero-length null payload, a padded payload designed to test a certain MTU, a NUD message, etc.). The exact format of the message payload is not important as the BR will not be processing it directly.
1. CEは、BRに送信されるあらゆるサイズとコンテンツのペイロードを構築します（たとえば、ゼロの長さのヌルペイロード、特定のMTUをテストするために設計されたパッド付きペイロード、NUDメッセージなど）。メッセージペイロードの正確な形式は、BRが直接処理しないため、重要ではありません。
2. The desired payload is encapsulated with the inner IPv6 and outer IPv4 headers as follows:
2. 目的のペイロードは、次のように内側のIPv6および外側IPv4ヘッダーでカプセル化されます。
* The IPv6 destination address is set to an address from the CE's 6rd delegated prefix that is assigned to a virtual interface on the CE.
* IPv6宛先アドレスは、CEの仮想インターフェイスに割り当てられたCEの6番目の委任されたプレフィックスのアドレスに設定されています。
* The IPv6 source address is set to an address from the CE's 6rd delegated prefix as well, including the same as used for the IPv6 destination address.
* IPv6ソースアドレスは、IPv6宛先アドレスに使用されるものと同じように、CEの6番目の委任されたプレフィックスのアドレスに設定されています。
* The IPv4 header is then added as it normally would be for any packet destined for the BR. That is, the IPv4 destination address is that of the BR, and the source address is the CE IPv4 address.
* 次に、IPv4ヘッダーは、通常BR専用のパケット用に行われるため、追加されます。つまり、IPv4宛先アドレスはBRのアドレスであり、ソースアドレスはCE IPv4アドレスです。
3. The CE sends the constructed packet out the interface on which BR reachability is being monitored. On successful receipt at the BR, the BR MUST decapsulate and forward the packet normally. That is, the IPv4 header is decapsulated normally, revealing the IPv6 destination as the CE, which in turn results in the packet being forwarded to that CE via the 6rd mechanism (i.e., the IPv4 destination is that of the CE that originated the packet, and the IPv4 source is that of the BR).
3. CEは、BRリーチ性が監視されているインターフェイスを構築したパケットを送信します。BRでの領収書が成功した場合、BRは通常のパケットを脱カプセル化して転送する必要があります。つまり、IPv4ヘッダーは正常に脱カプセル化されており、CEとしてIPv6宛先を明らかにし、第6メカニズムを介してパケットがそのCEに転送されるようになります（つまり、IPv4宛先はパケットを発信したCEの宛先です。IPv4ソースはBRのソースです。
4. Arrival of the constructed IPv6 packet at the CE's IPv6 address completes one round trip to and from the BR, without causing the BR to process the message outside of its normal data forwarding path. The CE then processes the IPv6 packet accordingly (updating keepalive timers, metrics, etc.).
4. CEのIPv6アドレスに構築されたIPv6パケットが到着すると、BRが通常のデータ転送パスの外側でメッセージを処理することなく、BRとの往復旅行が1回完了します。CEは、それに応じてIPv6パケットを処理します（KeepAliveタイマー、メトリックなどを更新します）。
The payload may be empty or could contain values that are meaningful to the CE. Sending a proper NUD message could be convenient for some implementations (note that the BR will decrement the IPv6 hop limit). Since the BR forwards the packet as any other data packet without any processing of the payload itself, the format of the payload is left as a choice to the implementer.
ペイロードは空であるか、CEにとって意味のある値を含めることができます。適切なNUDメッセージを送信すると、一部の実装には便利です（BRはIPv6ホップ制限を減らすことに注意してください）。BRは、ペイロード自体の処理なしに他のデータパケットとしてパケットを転送するため、ペイロードの形式は実装者に選択肢として残されます。
IPv6 in IPv4 encapsulation and forwarding manipulations (e.g., handling packet markings, checksumming, etc.) is performed as specified in Section 3.5 of "Basic Transition Mechanisms for IPv6 Hosts and Routers" [RFC4213], which is the same mechanism used by 6to4 [RFC3056]. ICMPv4 errors are handled as specified in Section 3.4 of [RFC4213]. By default, the IPv6 Traffic Class field MUST be copied to the IPv4 ToS (Type of Service) field. This default behavior MAY be overridden by configuration. See [RFC2983] and [RFC3168] for further information related to IP Differentiated Services and tunneling.
IPv4のIPv6カプセル化および転送操作（例：パケットマーキング、チェックサムなどの取り扱い）は、「IPv6ホストとルーターの基本遷移メカニズム」[RFC4213]のセクション3.5で指定されているように実行されます。RFC3056]。ICMPV4エラーは、[RFC4213]のセクション3.4で指定されているように処理されます。デフォルトでは、IPv6トラフィッククラスフィールドをIPv4 TOS（サービスのタイプ）フィールドにコピーする必要があります。このデフォルトの動作は、構成によってオーバーライドされる場合があります。IP差別化されたサービスとトンネリングに関連する詳細については、[RFC2983]および[RFC3168]を参照してください。
IPv6 packets from a CE are encapsulated in IPv4 packets when they leave the site via its CE WAN side interface. The CE IPv4 address MUST be configured to send and receive packets on this interface.
CEからのIPv6パケットは、CE WANサイドインターフェイスを介してサイトを離れるときにIPv4パケットにカプセル化されます。CE IPv4アドレスは、このインターフェイスでパケットを送信および受信するように構成する必要があります。
The 6rd link is modeled as an NBMA link similar to other automatic IPv6 in IPv4 tunneling mechanisms like [RFC5214], with all 6rd CEs and BRs defined as off-link neighbors from one other. The link-local address of a 6rd virtual interface performing the 6rd encapsulation would, if needed, be formed as described in Section 3.7 of [RFC4213]. However, no communication using link-local addresses will occur.
第6リンクは、[RFC5214]のようなIPv4トンネルメカニズムの他の自動IPv6と同様のNBMAリンクとしてモデル化されており、すべての6番目のCEとBRSがオフリンクネイバーとして定義されています。第6カプセル化を実行する6番目の仮想インターフェイスのリンクローカルアドレスは、必要に応じて[RFC4213]のセクション3.7で説明されているように形成されます。ただし、Link-Localアドレスを使用した通信は発生しません。
Maximum transmission unit (MTU) and fragmentation issues for IPv6 in IPv4 tunneling are discussed in detail in Section 3.2 of RFC 4213 [RFC4213]. 6rd's scope is limited to a service provider network. IPv4 Path MTU discovery MAY be used to adjust the MTU of the tunnel as described in Section 3.2.2 of RFC 4213 [RFC4213], or the 6rd Tunnel MTU might be explicitly configured.
IPv4トンネリングにおけるIPv6の最大透過ユニット（MTU）および断片化の問題については、RFC 4213 [RFC4213]のセクション3.2で詳しく説明しています。6番目のスコープは、サービスプロバイダーネットワークに限定されています。IPv4 PATH MTU発見は、RFC 4213 [RFC4213]のセクション3.2.2で説明されているように、トンネルのMTUを調整するために使用できます。
The use of an anycast source address could lead to any ICMP error message generated on the path being sent to a different BR. Therefore, using dynamic tunnel MTU Section 3.2.2 of [RFC4213] is subject to IPv4 Path MTU blackholes.
Anycastソースアドレスを使用すると、別のBRに送信されるパスで生成されたICMPエラーメッセージが生成される可能性があります。したがって、[RFC4213]の動的トンネルMTUセクション3.2.2を使用することは、IPv4 Path MTUブラックホールの対象となります。
Multiple BRs using the same anycast source address could send fragmented packets to the same IPv6 CE at the same time. If the fragmented packets from different BRs happen to use the same fragment ID, incorrect reassembly might occur. For this reason, a BR using an anycast source address MUST set the IPv4 Don't Fragment flag.
同じAnycastソースアドレスを使用して複数のBRSは、断片化されたパケットを同じIPv6 CEに同時に送信できます。異なるBRの断片化されたパケットが同じフラグメントIDを使用した場合、誤った再組み立てが発生する可能性があります。このため、Anycastソースアドレスを使用するBRは、IPv4 Not Fragmentフラグを設定する必要があります。
If the MTU is well-managed such that the IPv4 MTU on the CE WAN side interface is set so that no fragmentation occurs within the boundary of the SP, then the 6rd Tunnel MTU should be set to the known IPv4 MTU minus the size of the encapsulating IPv4 header (20 bytes). For example, if the IPv4 MTU is known to be 1500 bytes, the 6rd Tunnel MTU might be set to 1480 bytes. Absent more specific information, the 6rd Tunnel MTU SHOULD default to 1280 bytes.
MTUがSPの境界内でフラグメンテーションが発生しないようにCE WAN側インターフェイス上のIPv4 MTUが設定されるように適切に管理されている場合、第6トンネルMTUは、既知のIPv4 MTUマイナスに設定する必要があります。IPv4ヘッダーのカプセル化（20バイト）。たとえば、IPv4 MTUが1500バイトであることが知られている場合、第6トンネルMTUは1480バイトに設定される可能性があります。より具体的な情報がなければ、第6トンネルMTUはデフォルトで1280バイトになるはずです。
In order to prevent spoofing of IPv6 addresses, the 6rd BR and CE MUST validate the embedded IPv4 source address of the encapsulated IPv6 packet with the IPv4 source address it is encapsulated by according to the configured parameters of the 6rd domain. If the two source addresses do not match, the packet MUST be dropped and a counter incremented to indicate that a potential spoofing attack may be underway. Additionally, a CE MUST allow forwarding of packets sourced by the configured BR IPv4 address.
IPv6アドレスのスプーフィングを防ぐために、第6 BRとCEは、第6ドメインの設定されたパラメーターに従ってカプセル化されているIPv4ソースアドレスを使用して、カプセル化されたIPv6パケットの埋め込まれたIPv4ソースアドレスを検証する必要があります。2つのソースアドレスが一致しない場合、パケットをドロップし、潜在的なスプーフィング攻撃が進行中であることを示すためにカウンターを増加させる必要があります。さらに、CEは、構成されたBR IPv4アドレスによって供給されたパケットの転送を許可する必要があります。
By default, the CE router MUST drop packets received on the 6rd virtual interface (i.e., after decapsulation of IPv4) for IPv6 destinations not within its own 6rd delegated prefix.
デフォルトでは、CEルーターは、第6委任されたプレフィックス内ではないIPv6宛先の6番目の仮想インターフェイス（つまり、IPv4の脱カプセル化後）で受信したパケットをドロップする必要があります。
An SP network can migrate to IPv6 at its own pace with little or no effect on customers being provided IPv6 via 6rd. When native IPv6 connectivity is available, an administrator can choose to disable 6rd.
SPネットワークは、6番目を介してIPv6を提供する顧客にほとんどまたはまったく影響を与えず、独自のペースでIPv6に移行できます。ネイティブIPv6接続が利用可能な場合、管理者は6番目を無効にすることを選択できます。
The SP can choose to provision a separate IPv6 address block for native service, or reuse the 6rd prefix block itself. If the SP uses a separate address block, moving from 6rd to native IPv6 is seen as a normal IPv6 renumbering event for the customer. Renumbering may also be avoided by injecting the 6rd delegated prefix into the SP's IPv6 routing domain. Further considerations with regards to transitioning from 6rd to native IPv6 are not covered in this protocol specification.
SPは、ネイティブサービスに個別のIPv6アドレスブロックをプロビジョニングするか、6番目のプレフィックスブロック自体を再利用することを選択できます。SPが別のアドレスブロックを使用している場合、6番目からネイティブIPv6に移動すると、顧客の通常のIPv6の変更イベントと見なされます。また、6番目の委任されたプレフィックスをSPのIPv6ルーティングドメインに注入することにより、変更を回避することもできます。このプロトコル仕様では、6番目からネイティブIPv6への移行に関するさらなる考慮事項はカバーされていません。
As 6rd uses service-provider address space, 6rd uses the normal address delegation a service provider gets from its Regional Internet Registry (RIR) and no global allocation of a single 6rd IANA-assigned address block like the 6to4 2002::/16 is needed.
第6回はサービスプロバイダーアドレススペースを使用しているため、第6回は、サービスプロバイダーが地域インターネットレジストリ（RIR）から取得した通常のアドレス委任を使用し、6to4 2002 ::/16のような単一のIANAが割り当てられた単一のアドレスブロックのグローバル割り当ては必要ありません。。
The service provider's prefix must be short enough to encode the unique bits of all IPv4 addresses within a given 6rd domain and still provide enough IPv6 address space to the residential site. Assuming a worst case scenario using the full 32 bits for the IPv4 address, assigning a /56 for customer sites would mean that each service provider using 6rd would require a /24 for 6rd in addition to other IPv6 addressing needs. Assuming that 6rd would be stunningly successful and taken up by almost all Autonomous System (AS) number holders (32K today), then the total address usage of 6rd would be equivalent to a /9. If the SP instead delegated /60s to sites, the service provider would require a /28, and the total global address consumption by 6rd would be equivalent to a /13. Again, this assumes that 6rd is used by all AS number holders in the IPv4 Internet today at the same time, that none have used any of 6rd's address compression techniques, and that none have moved to native IPv6 and reclaimed the 6rd space that was being used for other purposes.
サービスプロバイダーのプレフィックスは、特定の6番目のドメイン内のすべてのIPv4アドレスの一意のビットをエンコードするのに十分な短くなければなりません。IPv4アドレスに完全な32ビットを使用して最悪のシナリオを想定すると、顧客サイトにA /56を割り当てると、6番目を使用する各サービスプロバイダーが他のIPv6アドレス指定のニーズに加えて6番目にA /24が必要になることを意味します。6番目が驚くほど成功し、ほぼすべての自律システム（AS）の数値（今日32K）に取り上げられると仮定すると、6番目の総アドレス使用量はA /9に相当します。SPが代わりにサイトに委任された場合、サービスプロバイダーはA /28を必要とし、6番目のグローバルアドレス消費量の合計はA /13に相当します。繰り返しますが、これは6番目が今日のIPv4インターネットのすべての人によって同時に数字の所有者として使用され、6番目のアドレス圧縮技術のいずれも使用していないこと、ネイティブIPv6に移動して、他の目的に使用されます。
To alleviate concerns about address usage, 6rd allows for leaving out redundant IPv4 prefix bits in the encoding of the IPv4 address inside the 6rd IPv6 address. This is most useful where the IPv4 address space is very well aggregated. For example, to provide each customer with a /60, if a service provider has all its IPv4 customers under a /12 then only 20 bits needs to be used to encode the IPv4 address and the service provider would only need a /40 IPv6 allocation for 6rd. If private address space is used, then a 10/8 would require a /36. If multiple 10/8 domains are used, then up to 16 could be supported within a /32.
アドレスの使用に関する懸念を軽減するために、6番目のIPv4アドレス内のIPv4アドレスのエンコードで冗長なIPv4プレフィックスビットを除外することができます。これは、IPv4アドレス空間が非常によく集計されている場合に最も便利です。たとえば、各顧客にA /60を提供するには、サービスプロバイダーがA /12未満のすべてのIPv4顧客を持っている場合、IPv4アドレスをエンコードするために20ビットのみを使用する必要があり、サービスプロバイダーはA /40 IPv6割り当てのみが必要です6番目の場合。プライベートアドレススペースを使用する場合、10/8にはA /36が必要です。複数の10/8ドメインを使用すると、A /32内で最大16個がサポートされる可能性があります。
If a service provider has a non-aggregatable IPv4 space and requiring the use of the full 32-bit IPv4 address in the encoding of the 6rd IPv6 address, the 6rd prefix MUST be no longer than /32 in order to offer a 6rd delegated prefix of at least /64.
サービスプロバイダーが凝集不可能なIPv4スペースを持っており、第6 IPv6アドレスのエンコードで32ビットの完全なIPv4アドレスを使用する必要がある場合、6番目の委任状のプレフィックスを提供するために、6番目のプレフィックスは /32以下でなければなりません少なくとも /64の。
The 6rd address block can be reclaimed when all users of it have transitioned to native IPv6 service. This may require renumbering of customer sites and use of additional address space during the transition period.
6番目のアドレスブロックは、ITのすべてのユーザーがネイティブIPv6サービスに移行した場合に再生できます。これには、顧客サイトの変更と、移行期間中に追加の住所スペースの使用が必要になる場合があります。
A 6to4 relay router as specified in [RFC3056] can be used as an open relay. It can be used to relay IPv6 traffic and as a traffic anonymizer. By restricting the 6rd domain to within a provider network, a CE only needs to accept packets from a single or small set of known 6rd BR IPv4 addresses. As such, many of the threats against 6to4 as described in [RFC3964] do not apply.
[RFC3056]で指定されている6to4リレールーターは、オープンリレーとして使用できます。IPv6トラフィックを中継し、トラフィックアノニマ化装置としてリレーするために使用できます。6番目のドメインをプロバイダーネットワーク内に制限することにより、CEは、既知の第6 BR IPv4アドレスの単一または小さなセットからパケットを受け入れる必要があります。そのため、[RFC3964]に記載されているように、6to4に対する脅威の多くは適用されません。
When applying the receiving rules in Section 9.2, IPv6 packets are as well protected against spoofing as IPv4 packets are within an SP network.
セクション9.2で受信ルールを適用する場合、IPv4パケットがSPネットワーク内にあるため、IPv6パケットがスプーフィングから保護されています。
A malicious user that is aware of a 6rd domain and the BR IPv4 address could use this information to construct a packet that would cause a Border Relay to reflect tunneled packets outside of the domain that it is serving. If the attacker constructs the packet accordingly and can inject a packet with an IPv6 source address that looks as if it originates from within another 6rd domain, forwarding loops between 6rd domains may be created, allowing the malicious user to launch a packet amplification attack between 6rd domains [RoutingLoop].
第6ドメインとBR IPv4アドレスを認識している悪意のあるユーザーは、この情報を使用して、ボーダーリレーが提供されているドメインの外側のトンネルパケットを反映するパケットを構築することができます。攻撃者がそれに応じてパケットを構築し、別の6番目のドメイン内から発生するかのように見えるIPv6ソースアドレスをパケットに挿入できる場合、第6ドメイン間の転送ループを作成し、悪意のあるユーザーが第6回のパケット増幅攻撃を起動できるようにすることができますドメイン[Routingloop]。
One possible mitigation for this is to simply not allow the BR IPv4 address to be reachable from outside the SP's 6rd domain. In this case, carefully constructed IPv6 packets still could be reflected off a single BR, but the looping condition will not occur. Tunneled packets with the BR IPv4 address as the source address might also be filtered to prohibit 6rd tunnels from exiting the 6rd domain.
これの可能な緩和の1つは、SPの6番目のドメインの外側からBR IPv4アドレスに到達可能になっていることを単に許可しないことです。この場合、慎重に構築されたIPv6パケットは、単一のBRからまだ反射できますが、ループ条件は発生しません。ソースアドレスとしてBR IPv4アドレスを備えたトンネルパケットもフィルター処理され、第6ドメインの出口の6番目のトンネルが禁止される場合があります。
To avoid forwarding loops via other internal relays, the BR should employ outgoing and incoming IPv4 packets filters, filtering out all known relay addresses for internal 6rd BRs, ISATAP routers, or 6to4 relays, including the well-known anycast address space for 6to4.
他の内部リレーを介した転送ループを回避するために、BRは発信および着信のIPv4パケットフィルターを使用し、6to4の有名なAnycastアドレススペースを含む、内部6rd BRS、ISATAPルーター、または6to4リレーのすべての既知のリレーアドレスをフィルタリングする必要があります。
Another possible mitigation to the routing loop issue is described in [V6OPS-LOOPS].
ルーティングループの問題に対する別の可能な緩和は、[v6ops-loops]で説明されています。
The BR MUST install a null route [RFC4632] for its 6rd delegated prefix created based on its BR IPv4 address, with the exception of the IPv6 Subnet-Router anycast address.
BRは、IPv6サブネットルーターAnycastアドレスを除き、BR IPv4アドレスに基づいて作成された6番目の委任されたプレフィックスのために、NULLルート[RFC4632]をインストールする必要があります。
IANA assigned a new DHCP Option code point for OPTION_6RD (212) with a data length of 18 + N (OPTION_6RD with N/4 6rd BR addresses).
IANAは、18 nのデータ長（n/4 6rd brアドレスを持つOption_6rd）のOption_6rd（212）の新しいDHCPオプションコードポイントを割り当てました。
This RFC is based on Remi Despres' original idea described in [RFC5569] and the work done by Rani Assaf, Alexandre Cassen, and Maxime Bizon at Free Telecom. Brian Carpenter and Keith Moore documented 6to4, which all of this work is based upon. We thank Fred Templin for his review and contributions, and for sharing his experience with ISATAP. Review and encouragement have been provided by many others and in particular Chris Chase, Thomas Clausen, Wouter Cloetens, Wojciech Dec, Bruno Decraene, Remi Despres, Alain Durand, Washam Fan, Martin Gysi, David Harrington, Jerry Huang, Peter McCann, Alexey Melnikov, Dave Thaler, Eric Voit, and David Ward.
このRFCは、[RFC5569]に記載されているRemi Despresの元のアイデアと、Free TelecomでRani Assaf、Alexandre Cassen、Maxime Bizonが行った作業に基づいています。ブライアン・カーペンターとキース・ムーアは6to4を文書化しましたが、この作業はすべてに基づいています。フレッド・テンプリンのレビューと貢献、そして彼の経験をISATAPと共有してくれたことに感謝します。レビューと励ましは、他の多くの人、特にクリス・チェイス、トーマス・クラウセン、ワーター・クロテン、ウォージェチ・デュー、ブルーノ・デカネ、レミ・デスプレス、アラン・デュランド、ワシャム・ファン、マーティン・ギシ、デビッド・ハリントン、ジェリー・ファン、ピーター・マッキャン、アレクセイ・メルニコフ、Dave Thaler、Eric Voit、およびDavid Ward。
[RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, February 1996.
[RFC1918] Rekhter、Y.、Moskowitz、R.、Karrenberg、D.、Groot、G。、およびE. Lear、「Private Internetsのアドレス割り当て」、BCP 5、RFC 1918、1996年2月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor Extensions", RFC 2132, March 1997.
[RFC2132] Alexander、S。およびR. Droms、「DHCPオプションとBOOTPベンダー拡張機能」、RFC 2132、1997年3月。
[RFC2491] Armitage, G., Schulter, P., Jork, M., and G. Harter, "IPv6 over Non-Broadcast Multiple Access (NBMA) networks", RFC 2491, January 1999.
[RFC2491] Armitage、G.、Schulter、P.、Jork、M。、およびG. Harter、「非ブロードキャストマルチアクセス（NBMA）ネットワークを介したIPv6」、RFC 2491、1999年1月。
[RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains via IPv4 Clouds", RFC 3056, February 2001.
[RFC3056] Carpenter、B。およびK. Moore、「IPv4 Cloudsを介したIPv6ドメインの接続」、RFC 3056、2001年2月。
[RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition of Explicit Congestion Notification (ECN) to IP", RFC 3168, September 2001.
[RFC3168] Ramakrishnan、K.、Floyd、S。、およびD. Black、「IPへの明示的な混雑通知（ECN）の追加」、RFC 3168、2001年9月。
[RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms for IPv6 Hosts and Routers", RFC 4213, October 2005.
[RFC4213] Nordmark、E。およびR. Gilligan、「IPv6ホストとルーターの基本的な遷移メカニズム」、RFC 4213、2005年10月。
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, February 2006.
[RFC4291] Hinden、R。およびS. Deering、「IPバージョン6アドレス指定アーキテクチャ」、RFC 4291、2006年2月。
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, September 2007.
[RFC4861] Narten、T.、Nordmark、E.、Simpson、W。、およびH. Soliman、「IPバージョン6（IPv6）の近隣発見」、RFC 4861、2007年9月。
[RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J. Schoenwaelder, Ed., "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999.
[RFC2578] McCloghrie、K.、Ed。、Perkins、D.、ed。、およびJ. Schoenwaelder、ed。、「管理情報の構造バージョン2（SMIV2）」、STD 58、RFC 2578、1999年4月。
[RFC2983] Black, D., "Differentiated Services and Tunnels", RFC 2983, October 2000.
[RFC2983] Black、D。、「差別化されたサービスとトンネル」、RFC 2983、2000年10月。
[RFC3068] Huitema, C., "An Anycast Prefix for 6to4 Relay Routers", RFC 3068, June 2001.
[RFC3068] Huitema、C。、「6to4リレールーターのAnycast Prefix」、RFC 3068、2001年6月。
[RFC3484] Draves, R., "Default Address Selection for Internet Protocol version 6 (IPv6)", RFC 3484, February 2003.
[RFC3484] Draves、R。、「インターネットプロトコルバージョン6（IPv6）のデフォルトアドレス選択」、RFC 3484、2003年2月。
[RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic Host Configuration Protocol (DHCP) version 6", RFC 3633, December 2003.
[RFC3633] Troan、O。およびR. Droms、「動的ホスト構成プロトコル（DHCP）バージョン6のIPv6プレフィックスオプション」、RFC 3633、2003年12月。
[RFC3964] Savola, P. and C. Patel, "Security Considerations for 6to4", RFC 3964, December 2004.
[RFC3964] Savola、P。およびC. Patel、「6to4のセキュリティ上の考慮事項」、RFC 3964、2004年12月。
[RFC4632] Fuller, V. and T. Li, "Classless Inter-domain Routing (CIDR): The Internet Address Assignment and Aggregation Plan", BCP 122, RFC 4632, August 2006.
[RFC4632] Fuller、V。およびT. Li、「クラスレス間ドメインルーティング（CIDR）：インターネットアドレスの割り当てと集約計画」、BCP 122、RFC 4632、2006年8月。
[RFC5214] Templin, F., Gleeson, T., and D. Thaler, "Intra-Site Automatic Tunnel Addressing Protocol (ISATAP)", RFC 5214, March 2008.
[RFC5214] Templin、F.、Gleeson、T。、およびD. Thaler、「敷地内自動トンネルアドレス指定プロトコル（ISATAP）」、RFC 5214、2008年3月。
[RFC5569] Despres, R., "IPv6 Rapid Deployment on IPv4 Infrastructures (6rd)", RFC 5569, January 2010.
[RFC5569] DESPRES、R。、「IPv4インフラストラクチャのIPv6迅速な展開（6rd）」、RFC 5569、2010年1月。
[RoutingLoop] Nakibly and Arov, "Routing Loop Attacks using IPv6 Tunnels", August 2009, <http://www.usenix.org/event/ woot09/tech/full_papers/nakibly.pdf>.
[Routingloop] Nakibly and arov、「IPv6トンネルを使用したルーティングループ攻撃」、2009年8月、<http://www.usenix.org/event/ woot09/tech/full_papers/nakibly.pdf>。
[TR069] "TR-069, CPE WAN Management Protocol v1.1, Version: Issue 1 Amendment 2", December 2007.
[TR069] "TR-069、CPE WAN管理プロトコルV1.1、バージョン：問題1修正2"、2007年12月。
[V6OPS-LOOPS] Nakibly, G. and F. Templin, "Routing Loop Attack using IPv6 Automatic Tunnels: Problem Statement and Proposed Mitigations", Work in Progress, May 2010.
[V6OPS-LOOPS] Nakibly、G。およびF. Templin、「IPv6自動トンネルを使用したルーティングループ攻撃：問題の声明と提案された緩和」、2010年5月の進行中。
Authors' Addresses
著者のアドレス
Mark Townsley Cisco Paris, France
マークタウンズリーシスコパリ、フランス
EMail: mark@townsley.net
Ole Troan Cisco Bergen, Norway
ノルウェーのオレトローンシスコベルゲン
EMail: ot@cisco.com