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



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.


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


Copyright Notice


Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.

著作権(C)2010 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents ( 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トラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。コードコンポーネントは、トラスト法規定のセクションで説明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
1. Introduction
1. はじめに

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.


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を展開するためのプロトコル・メカニズムを指定します。それはSP自身のIPv6アドレスプレフィックスを利用することを重要な差別ではなく、よく知られた接頭辞(2002 :: / 16)で、6to4の[RFC3056]に基づいています。 SPのIPv6プレフィックスを使用することにより、6rdの運用ドメインは、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.


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.


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

6rdドメインは、6rdカスタマーエッジ(CE)ルータと1つまたは複数の6rdボーダーリレー(のBR)から構成されています。 6rdによってカプセル化されたIPv6パケットは、CEとのBRのうちSPネットワーク内のIPv4ルーティングトポロジーに従います。 6rdのBRだけに運命づけられているか、SPの6rdドメイン外から到着しているIPv6パケットのためにトラバースされています。 6rdはステートレスであるため、のBRは、([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の動作のために更なる配慮があるさこの文書の範囲外。 「SP-面する」に(すなわち、「WAN」)6rd CE、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ネットワークと業務へのわずかの変化ではIPv4と一緒に生産品質のIPv6を提供するように設計されています。 6rdでサポートされているサイトへのIPv6サービスを提供しながら、SPネットワーク自体の中で、ネイティブのIPv6の展開はSP自身の目的のために継続してもよいです。 SPネットワークおよび動作は完全にネイティブのIPv6アクセスおよびトランスポートをサポートすることができたら、6rdを中止することができます。

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と同じカプセル化ベースのメカニズムを利用し、(2002 :: / 16に6rdプレフィックスを設定することによって達成することができたの6to4)の6to4のスーパーセットとして見ることができます。 6to4のとは異なり、6rdは、サービスプロバイダが密接にIPv6サービスの配信を管理環境で使用するためのものです。 2002 :: / 16接頭辞の6to4ルートは6rd CEルータに6rdと一緒に存在してもよく、と6to4ルータと直接通信するときにそうすることは、いくつかの効率性を提供することがあります。

The 6rd link model can be extended to support IPv6 multicast. IPv6 multicast support is left for future consideration.

6rdリンクモデルは、IPv6マルチキャストをサポートするように拡張することができます。 IPv6マルチキャストのサポートは、今後の検討のために残されています。

How this mechanism should be used and other deployment and operational considerations are considered out of scope for this document.


2. Requirements Language

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]に記載されているように解釈されます。

3. Terminology

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.

6rdドメインで使用するためのサービスプロバイダによって選択された6rdプレフィックスアンIPv6プレフィックス。与えられた6rdドメインの正確に一つの6rdの接頭辞があります。 SPは、単一の6rdドメインまたは複数6rdドメインと6rd配備することができます。

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.

6rdカスタマエッジ(CE 6rd)6rd配備におけるカスタマエッジルータとして機能するデバイス。家庭用ブロードバンドの展開では、このタイプの装置は、しばしば「レジデンシャルゲートウェイ」(RG)または「顧客宅内機器」(CPE)と呼ばれます。住宅のサイトにサービスを提供する一般的な6rd CEは、一のWAN側インターフェース、一つ以上のLAN側インターフェース、及び6rd仮想インターフェースを有しています。 6rd CEは、単に6rdの文脈内の「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].

6rdは6rdプレフィックスと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.

6rdドメイン同じ仮想6rdリンクに接続6rd CEとのBRのセット。サービスプロバイダは、単一の6rdドメインと6rd配備することができる、又は複数6rdドメインを利用することができます。各ドメインは、別々の6rd接頭辞が必要です。

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)」または「顧客対応」側を提供しています6rd 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側「ワイドエリアネットワーク(WAN)」または「サービスプロバイダー向けの」CEの側面を提供しています6rd 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.

6rdボーダーリレー(BR)6rdドメインのエッジでサービスプロバイダによって管理さ6rd対応ルータ。 IPv4の対応インターフェイス、IPv4トンネルで6rd IPv6のエンドポイント、およびネイティブIPv6ネットワークに接続されたIPv6インタフェースとして作用6rd仮想インターフェース:ボーダー中継ルータは、以下のそれぞれの少なくとも一つを有します。 6rd BRは、単に6rdの文脈内の「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が与えられた6rdのドメインの6rdボーダーリレーのIPv4アドレス。このIPv4アドレスは、6rdドメイン外のIPv6宛先に到達するために、BRにパケットを送信するためにCEによって使用されます。

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.


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、または介して設定)。このアドレスは、6rdドメイン内のグローバルまたはプライベート[RFC1918]かもしれません。このアドレスは、6rd委任プレフィックスを作成するだけでなく、IPv4にカプセル化されたIPv6パケットを送受信するために6rd CEで使用されています。

4. 6rd Prefix Delegation
4. 6rdプレフィックス委任

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

顧客サイトでの使用のための6rd委任プレフィックスは、CE、IPv4アドレスのプレフィックス6rdと全部または一部を組み合わせて作成されます。 IPv4サービスが得られたときに、これらの要素から、6rd委任プレフィックスは自動的にお客様のサイトのためのCEによって作成されます。この6rd委譲されたプレフィックスは、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アドレスを組み込むことにより行われます。 6rdでは、組み込まれたIPv4アドレスのビットのIPv6プレフィックス、並びに位置及び数は、一個の6rdドメインから次へと変化します。 6rdは、SPは、6rdメカニズムによって使用されているどのように多くのビット6rdプレフィックスのサイズを調整することを可能にし、どのように多くのビットが顧客サイトに委任することが残されています。 CE LAN側のステートレスアドレス自動設定を可能にするため、6rd委任プレフィックスが/ 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).

6rd委譲されたプレフィックスは、6rdプレフィックスと順にCE IPv4アドレスからのビットの連続したセットを連結することによって作成されます。 6rd委任プレフィックスの長さは、6rdプレフィックス(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:

図は、6rdプレフィックスと埋め込み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


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, then the size of the 6rd delegated prefix for each CE is automatically calculated to be /56 (32 + 24 = 56).

6rd接頭辞(例えば、すべてのCEのIPv4アドレスは10.0.0.0/8によって集約することができる)CE IPv4アドレスが使用されるの/ 32及び24ビットである場合、例えば、次に6rdのサイズは、各CEのプレフィックスを委任しました自動/ 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.


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.


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.


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

6rd IPv6アドレス割り当て、ひいてはIPv6サービス自体は、IPv4アドレスのリースに接続されています。したがって、6rdサービスはまた、たとえばなど、認可、アカウンティング、という点でこれに縛られ、6rd委任プレフィックスがそれに関連付けられたIPv4アドレスと同じ寿命を持っています。ルータ広告で広告やCE LAN側のDHCPで使用されるプレフィックス寿命に等しいまたはIPv4アドレスのリース時間よりも短くする必要があります。 IPv4のリース時間が知られていない場合は、6rd委任プレフィックスの寿命は[RFC4861]で指定されたデフォルト値に従ってください。

5. Troubleshooting and Traceability

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.

特定の顧客のための6rd IPv6アドレスと関連付けられたIPv4アドレスは、常に与えられた6rdドメインを運営するサービスプロバイダによってアルゴリズム的に決定することができます。これは、IPv6よりもIPv4のためのより堅牢な運用ツールを持っていることがあり、サービスプロバイダにログやその他のデータを参照するために有用である可能性があります。これはまた、IPv6への適用可能とIPv4のデータパス、ノード、およびエンドポイントの監視を可能にします。

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.

6rd CEとBRは、独自の6rd委任プレフィックスのIPv6サブネットルータエニーキャストアドレス[RFC4291]をサポートすべきです。これは、例えば、IPv6のICMPエコーメッセージが所与のCEまたはBrで6rdの内部動作のトラブルシューティングのために6rd仮想インタフェース自体に送信することが、可能となります。 BR、6rd委譲されたプレフィックスを計算するために使用されるIPv4アドレスの場合で構成BR IPv4アドレスです。

6. Address Selection

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.


7. 6rd Configuration
7. 6rdの設定

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.


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 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所与6rdドメイン内のすべてのCEのIPv4アドレスで同一である上位ビットの数。全く同一のビットが存在しない場合、例えば、IPv4MaskLenは0であり、全体のCE IPv4アドレスは、6rd委譲されたプレフィックスを作成するために使用されます。 8つの同一のビット(例えば、プライベートIPv4アドレス範囲10.0.0.0/8が使用されている)がある場合、IPv4MaskLenは8に等しく、IPv4MaskLen上位ビットは、対応する6rd委譲されたプレフィックスを構築する前に、IPv4アドレスから剥離されます。

6rdPrefix The 6rd IPv6 prefix for the given 6rd domain.

与えられた6rdドメインの6rdPrefix 6rd IPv6プレフィックス。

6rdPrefixLen The length of the 6rd IPv6 prefix for the given 6rd domain.

6rdPrefixLen与えられた6rdドメインの6rd IPv6プレフィックスの長さ。

6rdBRIPv4Address The IPv4 address of the 6rd Border Relay for a given 6rd domain.


7.1. Customer Edge Configuration
7.1. カスタマーエッジの設定

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つの6rd要素は6rdドメイン内のすべてのCEにわたって同一である値に設定されています。値は、ブロードバンドフォーラムの「TR-69」[TR069]レジデンシャルゲートウェイ管理インターフェース、IPv4接続が確立された後に検索されたXMLベースのオブジェクト、DNSレコード、SMIv2のようなプロビジョニング方法を含む様々な方法で構成することができますMIB管理者が[RFC2578]、PPP IPCP、または手動設定。この文書では、単一のDHCPオプションを使用して、必要なパラメータを設定する方法について説明します。 DHCPでのIPv4設定することができますCEは、このオプションを実装する必要があります。その他の構成および管理方法は、複数の設定方法をサポートするのCE上の一貫性及び実装の便宜のために、このオプションで記述されたフォーマットを使用してもよいです。

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.

CEは6rd委譲されたプレフィックスを計算し、IPv6接続を可能にするために必要とする唯一の残りのプロビジョニング情報は、CEのためのIPv4アドレスです。このCE IPv4アドレスがIPv4インターネットへのアクセスを得るの一部として構成されている(すなわち、そうでなければ、DHCP、PPP、または介して設定)。このアドレスは、6rdドメイン内のグローバルまたはプライベート[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.

シングル6rd CEは、任意のルータがインターフェイスとDHCPv6のプレフィックス委譲または他の手段によって割り当てられた関連する委任プレフィックスの複数のセットが直面している複数のIPv6対応サービス・プロバイダーを持っていることと同じように、複数の6rdドメインに接続することができます。各ドメインは、与えられたCEは、内6rdの構成要素の独自のセットを必要とし、独自の6rd委任プレフィックスを生成する動作します。

7.1.1. 6rd DHCPv4 Option
7.1.1. 6rd DHCPv4のオプション
   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


option-code OPTION_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.


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.

ビット数のSPの6rd IPv6プレフィックスの6rdPrefixLenザIPv6プレフィックスの長さ。 DHCPオプション処理によって境界チェックの目的のために、の和(32 - IPv4MaskLen)+ 6rdPrefixLenは、より少ない又は128に等しくなければなりません。

6rdBRIPv4Address One or more IPv4 addresses of the 6rd Border Relay(s) for a given 6rd domain.


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サービスプロバイダの6rd IPv6プレフィックスは、16オクテットのIPv6アドレスとして表現しました。ビット6rdPrefixlen番号の後にプレフィックスのビットは予約されており、送信者によってゼロに初期化し、受信機で無視しなければなりません。

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はせいぜい単一6rdドメイン条項に制限されているので。複数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オプションの存在は、6rdサービスの可用性の指標です。デフォルトでは、6rd仮想インタフェースの構成で6rd対応CEの結果によって、有効な6rd DHCPオプションの領収書とCEのLAN側で使用するための関連する委任プレフィックス。 CEを無効にするための6rdメカニズムを設定できなければならない、6rd 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は、少なくとも一つの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, a BR IPv4 address of, 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、6rd委任プレフィックスのブラックホール経路、および任意のLAN側割り当てられ、アドバタイズされたプレフィクスのルートにデフォルトルートをインストールします。例えば、のCE IPv4アドレスを使用して、のBR IPv4アドレス、8のIPv4MaskLen、2001:DB8 :: LAN側インターフェースに割り当て6rdPrefixとして/ 32、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)

:: / 0 - > 6rd-仮想INT0を2001経由:DB8:0:100 ::(デフォルトルート)2001:DB8 :: / 32 - > 6rd-仮想INT0(直接6rdに接続)2001:DB8:6464 :100 :: / 56 - >ヌル0(委譲されたプレフィックスヌルルート)2001:DB8:6464:100 :: / 64 - > Ethernet0に(LANインタフェース)

7.2. Border Relay Configuration
7.2. ボーダーリレー設定

The 6rd BR MUST be configured with the same 6rd elements as the 6rd CEs operating within the same domain.

6rd BRは、同じドメイン内で動作6rdのCEと同じ6rdの要素で構成されなければなりません。

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アドレスは、所与の6rdドメイン間で共有エニーキャストアドレスであってもよいです。 6rdはステートレスであるように、任意のBRは、いつでも使用することができます。 BR IPv4アドレスがエニーキャストであればリレーはCEに中継されるパケットの送信元アドレスとしてこのエニーキャスト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.


8. Neighbor Unreachability Detection

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に記載されています。 6rdでは、すべてのCEとのBRは互いに同じ仮想リンクしたがって隣人に接続とみなすことができます。このセクションでは、マイナスの6rd展開のスケーラビリティに影響を与えることなく、近傍不到達検出を利用する方法について説明します。

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.

典型的6rd展開は、同じドメイン内のCEの非常に多数から成ることができます。 CE間の到達可能性は、IPv4ルーティングに基づいており、6rd機構の単離されたトラブルシューティングを超えNUD又は6rd 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.

所与6rd CEとBRとの間の到達可能性検出は、6rdの適切な動作のために必要ではないが、CEから選択するBRの到達可能性のための代替経路を有する場合には、それが有用であり得ます。 BRにNUDメッセージを送信し、CEの非常に多数の特定の定期的なメッセージに、負6rd配備のスケーラビリティに影響を与える、BR制御メッセージ処理経路の過負荷が生じる可能性があります。代わりに、BRの到達可能性を決定する必要がCEは、到達可能性検出パケットがBRにより特別な処理を行わず、一般的なデータ転送パスをたどることを可能にする方法を利用しなければなりません。そのような方法の一つを以下に説明します。

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:


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

* 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の6rd委任プレフィックスからのアドレスに設定されています。

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

それは通常BR宛てのすべてのパケットのためになるよう* IPv4ヘッダを加えます。すなわち、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ヘッダがパケット内のターン結果に6rd機構を介してそのCEに転送されるCEなどのIPv6宛先を明らかに、正常にデカプセル化される(すなわち、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.).

CEのIPv6アドレスで構成されたIPv6パケットの前記到着BRが通常のデータ転送経路の外にメッセージを処理させることなく、BRへ及びからの1つの往復を完了する。 CEは、それに応じて(キープアライブタイマー、メトリック、等を更新する)IPv6パケットを処理します。

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は、ペイロード自体の任意の処理を行わず、他のデータパケットとしてパケットを転送するので、ペイロードの形式は実装者に選択肢として残っています。

9. IPv6 in IPv4 Encapsulation

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(例えば、パケットマーキング、チェックサム、等の取り扱い)の6to4で使用されるのと同じ機構である「IPv6ホストとルータのための基本的な移行メカニズム」[RFC4213]のセクション3.5で指定されるように実行されますRFC3056]。 [RFC4213]のセクション3.4で指定されるようにICMPv4のエラーが処理されます。デフォルトでは、IPv6のトラフィッククラスフィールドは、IPv4のTOS(Type of Service)フィールドにコピーする必要があります。このデフォルトの動作は、設定によって上書きされることがあります。 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 WAN側インタフェースを介してサイトを離れるときにCEからIPv6パケットを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.

6rdリンクは、他の一方からオフリンク近隣として定義されているすべての6rd CEとのBRを有するような他の自動IPv6のIPv4のトンネリングメカニズム[RFC5214]と同様NBMAリンクとしてモデル化されます。 [RFC4213]のセクション3.7に記載されているように6rdカプセル化を行う6rd仮想インターフェイスのリンクローカルアドレスは、必要に応じて、形成されるであろう。ただし、リンクローカルアドレスを使用して通信は発生しません。

9.1. Maximum Transmission Unit
9.1. 最大転送単位

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で詳細に考察されています。 6rdの範囲は、サービスプロバイダーのネットワークに限定されています。 IPv4のパスMTU発見は、RFC 4213 [RFC4213]のセクション3.2.2に記載したように、トンネルのMTUを調整するために用いてもよいし、6rdトンネル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.


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.

同じエニーキャスト送信元アドレスを使用して複数のBRは同時に同じIPv6のCEに断片化されたパケットを送信することができます。異なるのBRからの断片化されたパケットは、同じフラグメントIDを使用してしまった場合、不正な再構築が発生することがあります。このため、エニーキャスト送信元アドレスを使用してBRは、Do not FragmentフラグをIPv4のを設定しなければなりません。

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は、CE WAN側インターフェース上でIPv4 MTUが設定されないフラグメンテーションは、SPの境界内に発生しないように、その後、6rdトンネルMTUが知られているIPv4のMTUマイナスのサイズに設定されるべきであるように、十分に管理されている場合カプセル化IPv4ヘッダー(20バイト)。 IPv4のMTUは1500バイトであることが知られている場合、例えば、6rdトンネルMTUは1480バイトに設定されるかもしれません。不在、より具体的な情報、6rdトンネルMTUは1280バイトをデフォルトとすべきです。

9.2. Receiving Rules
9.2. ルールを受け取ります

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アドレスのスプーフィングを防止するために、6rd BR及びCEは、それが6rdドメインの構成パラメータに従ってによってカプセル化されたIPv4ソースアドレスでカプセル化IPv6パケットの埋め込みIPv4ソースアドレスを検証する必要があります。二つのソースアドレスが一致しない場合、パケットはドロップされなければならないとカウンタは、潜在的なスプーフィング攻撃が進行中であり得ることを示すために、インクリメント。さらに、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.


10. Transition Considerations

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.


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アドレスブロックを選択するか、6rdプレフィックスブロック自体を再利用することができます。 SPは別のアドレスブロックを使用している場合は、6rdからネイティブIPv6への移行は、顧客のために、通常のIPv6リナンバリングイベントとして見られています。リナンバリングもSPのIPv6ルーティングドメインに6rd委任プレフィックスを注入することによって回避することができます。ネイティブIPv6に6rdから移行へに関してさらなる考慮は、このプロトコル仕様でカバーされていません。

11. IPv6 Address Space Usage
11. 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.

6rdは、サービスプロバイダーのアドレス空間を使用すると、6rdが必要とされているサービスプロバイダは、その地域インターネットレジストリ(RIR)からなる通常のアドレス委譲と6to4 2002 :: / 16のような単一の6rd 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.

サービスプロバイダの接頭辞が与えられ6rdドメイン内のすべてのIPv4アドレスのユニークなビットを符号化し、まだ住宅サイトへの十分なIPv6アドレス空間を提供するのに十分短くなければなりません。顧客サイトの/ 56を割り当てるIPv4アドレスの完全な32ビットを使用して、最悪の場合のシナリオを想定すると、6rdを使用して、各サービスプロバイダが他のIPv6アドレッシングのニーズに加えて、6rd用/ 24を必要とするであろうことを意味します。その6rdと仮定すると、驚くほど成功し、ほぼすべての自律システム(AS)番号の所有者(32K今日)で取り上げなり、その後、6rdの合計アドレスの使用は/ 9に相当します。 SPはなく、サイトへの/ 60代を委任した場合、サービスプロバイダは、/ 28を必要とする、と6rdにより、合計グローバルアドレスの消費量は、/ 13に相当します。繰り返しますが、これは、6rdはどれも6rdのアドレス圧縮技術のいずれかを使用していない、そのどれもが、ネイティブIPv6へ移動していないとされていた6rdスペースを再利用していること、同時に、今日のIPv4インターネットで数ホルダとしてすべてで使用されていることを前提としてい他の目的に使用します。

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.

アドレスの使用についての懸念を軽減するために、6rdは6rd IPv6アドレス内のIPv4アドレスの符号化冗長IPv4プレフィクスビットを除外することを可能にします。これは、IPv4アドレス空間は非常によく集約された場合に最も有用です。サービスプロバイダは、/ 12の下にあるすべてのIPv4の顧客を持っている場合、例えば、/ 60と各顧客に提供するためにのみ20ビットIPv4アドレスをエンコードするために使用する必要があり、サービス・プロバイダは、/ 40のIPv6割り当てを必要とします6rdのため。プライベートアドレス空間を使用する場合は、10月8日には、/ 36を必要とします。複数10/8ドメインが使用される場合、16まで/ 32内に支持することができます。

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空間と6rd IPv6アドレスの符号化における完全な32ビットのIPv4アドレスを使用する必要がある場合、6rdプレフィックスが6rd委譲されたプレフィックスを提供するために、もはや/ 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.


12. Security Considerations

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トラフィックとトラフィックアノニマイザーとを中継するために使用することができます。プロバイダネットワーク内に6rdドメインを制限することにより、CEのみ知ら6rd 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.


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

6rdドメインを認識しており、悪意のあるユーザーとBR IPv4アドレスは、それがサービスを提供しているドメインの外側のトンネルパケットを反映するために、ボーダーリレーを引き起こすパケットを構築するために、この情報を使用することができます。攻撃者は、それに応じてパケットを構築し、それが別の6rdドメイン内に由来するかのように見えるIPv6ソースアドレスを持つパケットを注入することができる場合、6rdドメイン間の転送ループは6rd間のパケット増幅攻撃を起動するため、悪意のあるユーザーを可能に作成することができますドメイン[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.

このための一つの可能​​な緩和策は、単にBR IPv4アドレスがSPの6rdドメインの外部からアクセス可能であることを許可しないことです。この場合には、注意深く構築IPv6パケットは、依然として単一BRを反射することができたが、ループ状態が発生しません。ソースアドレスとしてBR IPv4アドレスを有するトンネルパケットも6rdドメインから出る6rdトンネルを禁止するためにフィルタリングされるかもしれません。

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.


Another possible mitigation to the routing loop issue is described in [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サブネット・ルータのエニーキャストアドレスを除いて、そのBR IPv4アドレスに基づいて作成され、その6rd委譲されたプレフィックスにnull経路[RFC4632]をインストールする必要があります。

13. IANA Considerations
13. IANAの考慮事項

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オプションコードポイントを割り当て。

14. Acknowledgements

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]で説明したアイデアや無料テレコムでラニアサフ、アレクサンドルCassenの、およびマキシムBizonによって行われた作業に基づいています。ブライアン・カーペンターとキース・ムーアは、この作品のすべてが基づいているの6to4を、文書化。私たちは、彼のレビューと貢献のため、およびISATAPと彼の経験を共有するためのフレッド・テンプリンに感謝します。レビューや励ましは多くの人で特にクリス・チェイス、トーマス・クラウゼン、はWouter Cloetens、ヴォイチェフ12月、ブルーノDecraene、レミ・デプレ、アラン・デュラン、Washamファン、マーティンGysi、デヴィッド・ハリントン、ジェリー黄、ピーター・マッキャン、アレクセイ・メルニコフで提供されています、デーブターラー、エリック・フォイト、とDavidウォード。

15. References
15.1. Normative References
15.1. 引用規格

[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.、モスコウィッツ、R.、Karrenberg、D.、グルート、G.、およびE.リア、 "個人的なインターネットのための配分"、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]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。

[RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor Extensions", RFC 2132, March 1997.

[RFC2132]アレクサンダー、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.

、RFC 2491、1999年1月 "非ブロードキャスト多重アクセス(NBMA)ネットワーク上のIPv6" [RFC2491]アーミテージ、G.、Schulter、P.、Jorkの、M.、およびG.ハーター、。

[RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains via IPv4 Clouds", RFC 3056, February 2001.

"IPv4の雲を介したIPv6ドメインの接続" [RFC3056]カーペンター、B.およびK.ムーア、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.

"IPに明示的輻輳通知の添加(ECN)" [RFC3168]ラマクリシュナン、K.、フロイド、S.、およびD.ブラック、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.ギリガン、 "IPv6ホストとルータのための基本的な変遷メカニズム"、RFC 4213、2005年10月。

[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, February 2006.

[RFC4291] HindenとR.とS.デアリング、 "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.、シンプソン、W.、およびH.ソリマン、 "IPバージョン6(IPv6)のための近隣探索"、RFC 4861、2007年9月。

15.2. Informative References
15.2. 参考文献

[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.、エド。、パーキンス、D.、編、及びJ. Schoenwaelder、編、STD 58、RFC 2578、 "経営情報バージョン2(SMIv2)の構造"、1999年4月。

[RFC2983] Black, D., "Differentiated Services and Tunnels", RFC 2983, October 2000.

[RFC2983]ブラック、D.、 "差別化サービスおよびトンネル"、RFC 2983、2000年10月。

[RFC3068] Huitema, C., "An Anycast Prefix for 6to4 Relay Routers", RFC 3068, June 2001.

[RFC3068]のHuitema、C.、 "6to4のリレールーターのエニーキャストプレフィックス"、RFC 3068、2001年6月。

[RFC3484] Draves, R., "Default Address Selection for Internet Protocol version 6 (IPv6)", RFC 3484, February 2003.

[RFC3484] Draves、R.、RFC 3484 "インターネットプロトコルバージョン6(IPv6)のデフォルトのアドレス選択"、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、RFC 3633、2003年12月 "動的ホスト構成プロトコル(DHCP)バージョン6のIPv6プレフィックスオプション"。

[RFC3964] Savola, P. and C. Patel, "Security Considerations for 6to4", RFC 3964, December 2004.

[RFC3964] Savola、P.とC.パテル、 "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]フラー、V.およびT.李、 "クラスレスドメイン間ルーティング(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]テンプリン、F.、グリーソン、T.、およびD.ターラーは、 "イントラサイト自動トンネルは、プロトコル(ISATAP)をアドレス指定"、RFC 5214、2008年3月。

[RFC5569] Despres, R., "IPv6 Rapid Deployment on IPv4 Infrastructures (6rd)", RFC 5569, January 2010.

[RFC5569]デプレ、R.、 "IPv4の基盤のIPv6のRapid Deployment(6rd)"、RFC 5569、2010年1月。

[RoutingLoop] Nakibly and Arov, "Routing Loop Attacks using IPv6 Tunnels", August 2009, < woot09/tech/full_papers/nakibly.pdf>.

[RoutingLoop] NakiblyとArov、 "IPv6トンネルを使用してルーティングループ攻撃"、2009年8月、< woot09 /ハイテク/ full_papers / nakibly.pdf>。

[TR069] "TR-069, CPE WAN Management Protocol v1.1, Version: Issue 1 Amendment 2", December 2007.

[TR069] "TR069、CPE WAN管理プロトコルバージョン1.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.テンプリン、「IPv6の自動トンネルを使用してルーティングループ攻撃:問題文と提案た軽減」、進歩、2010年5月での作業。

Authors' Addresses


Mark Townsley Cisco Paris, France




Ole Troan Cisco Bergen, Norway