[要約] RFC 6674は、Gateway-Initiated Dual-Stack Lite（GDS-Lite）デプロイメントに関するガイドラインです。その目的は、IPv4とIPv6の両方をサポートするネットワーク環境を効果的に展開するための手法を提供することです。
Internet Engineering Task Force (IETF) F. Brockners
Request for Comments: 6674 S. Gundavelli
Category: Standards Track Cisco
ISSN: 2070-1721 S. Speicher
Deutsche Telekom AG
D. Ward
Cisco
July 2012
Gateway-Initiated Dual-Stack Lite Deployment
ゲートウェイ起動のデュアルスタックLite展開
Abstract
概要
Gateway-Initiated Dual-Stack Lite (GI-DS-Lite) is a variant of Dual-Stack Lite (DS-Lite) applicable to certain tunnel-based access architectures. GI-DS-Lite extends existing access tunnels beyond the access gateway to an IPv4-IPv4 NAT using softwires with an embedded Context Identifier that uniquely identifies the end-system to which the tunneled packets belong. The access gateway determines which portion of the traffic requires NAT using local policies and sends/ receives this portion to/from this softwire.
ゲートウェイ開始デュアルスタックライト（GI-DS-Lite）は、特定のトンネルベースのアクセスアーキテクチャに適用可能なデュアルスタックライト（DS-Lite）のバリアントです。 GI-DS-Liteは、トンネルパケットが属するエンドシステムを一意に識別する組み込みのコンテキスト識別子を持つソフトワイヤーを使用して、既存のアクセストンネルをアクセスゲートウェイを越えてIPv4-IPv4 NATに拡張します。アクセスゲートウェイは、ローカルポリシーを使用してNATを必要とするトラフィックの部分を決定し、この部分をこのソフトワイヤーとの間で送受信します。
Status of This Memo
本文書の状態
This is an Internet Standards Track document.
これはInternet Standards Trackドキュメントです。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、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/rfc6674.
このドキュメントの現在のステータス、正誤表、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc6674で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2012 IETF Trustおよびドキュメントの作成者として特定された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、BCP 78およびこの文書の発行日に有効なIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象となります。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Gateway-Initiated DS-Lite . . . . . . . . . . . . . . . . . . 4
4. Protocol and Related Considerations . . . . . . . . . . . . . 6
5. Softwire Management and Related Considerations . . . . . . . . 7
6. Softwire Embodiments . . . . . . . . . . . . . . . . . . . . . 8
7. Security Considerations . . . . . . . . . . . . . . . . . . . 10
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
9.1. Normative References . . . . . . . . . . . . . . . . . . . 11
9.2. Informative References . . . . . . . . . . . . . . . . . . 12
Appendix A. GI-DS-Lite Deployment . . . . . . . . . . . . . . . . 13
A.1. Connectivity Establishment: Example Call Flow . . . . . . 13
A.2. GI-DS-Lite Applicability: Examples . . . . . . . . . . . . 14
Gateway-Initiated Dual-Stack Lite (GI-DS-Lite) is a variant of Dual-Stack Lite (DS-Lite) [RFC6333], applicable to network architectures that use point-to-point tunnels between the access device and the access gateway. The access gateway in these models is designed to serve large numbers of access devices. Mobile architectures based on Mobile IPv6 [RFC6275], Proxy Mobile IPv6 [RFC5213], or GPRS Tunnelling Protocol (GTP) [TS29060], as well as broadband architectures based on PPP or point-to-point VLANs as defined by the Broadband Forum [TR59][TR101], are examples of this type of architecture.
ゲートウェイ開始デュアルスタックライト（GI-DS-Lite）は、デュアルスタックライト（DS-Lite）[RFC6333]のバリアントであり、アクセスデバイスとアクセスの間でポイントツーポイントトンネルを使用するネットワークアーキテクチャに適用できますゲートウェイ。これらのモデルのアクセスゲートウェイは、多数のアクセスデバイスに対応するように設計されています。モバイルIPv6 [RFC6275]、プロキシモバイルIPv6 [RFC5213]、またはGPRSトンネリングプロトコル（GTP）[TS29060]に基づくモバイルアーキテクチャ、およびブロードバンドフォーラムで定義されているPPPまたはポイントツーポイントVLANに基づくブロードバンドアーキテクチャ[ TR59] [TR101]は、このタイプのアーキテクチャの例です。
The DS-Lite approach leverages IPv4-in-IPv6 tunnels (or other tunneling modes) for carrying the IPv4 traffic from the customer network to the Address Family Transition Router (AFTR). An established softwire between the AFTR and the access device is used for traffic-forwarding purposes. This makes the inner IPv4 address irrelevant for traffic routing and allows sharing private IPv4 addresses [RFC1918] between customer sites within the service provider network.
DS-Liteのアプローチは、IPv4-in-IPv6トンネル（または他のトンネリングモード）を利用して、IPv4トラフィックをカスタマーネットワークからアドレスファミリートランジションルーター（AFTR）に伝送します。 AFTRとアクセスデバイス間に確立されたソフトワイヤーは、トラフィック転送の目的で使用されます。これにより、内部IPv4アドレスがトラフィックルーティングに無関係になり、サービスプロバイダーネットワーク内のカスタマーサイト間でプライベートIPv4アドレス[RFC1918]を共有できます。
Similarly to DS-Lite, GI-DS-Lite enables the service provider to share public IPv4 addresses among different customers by combining tunneling and NAT. It allows multiple access devices behind the access gateway to share the same private IPv4 address [RFC1918]. Rather than initiating the tunnel right on the access device, GI-DS-Lite logically extends the already existing access tunnels beyond the access gateway towards the AFTR using a tunneling mechanism with semantics for carrying context state related to the encapsulated traffic. This approach results in supporting overlapping IPv4 addresses in the access network, requiring no changes to either the access device or the access architecture. Additional tunneling overhead in the access network is also omitted. If, for example, an encapsulation mechanism based on Generic Routing Encapsulation (GRE) is chosen, it allows the network between the access gateway and the AFTR to be either IPv4 or IPv6 and allows the operator to migrate to IPv6 in incremental steps.
DS-Liteと同様に、GI-DS-Liteを使用すると、サービスプロバイダーは、トンネリングとNATを組み合わせることにより、さまざまな顧客間でパブリックIPv4アドレスを共有できます。これにより、アクセスゲートウェイの背後にある複数のアクセスデバイスが同じプライベートIPv4アドレス[RFC1918]を共有できます。 GI-DS-Liteは、アクセスデバイスでトンネル権利を開始するのではなく、既存のアクセストンネルを、カプセル化されたトラフィックに関連するコンテキスト状態を伝送するセマンティクスを持つトンネリングメカニズムを使用して、アクセスゲートウェイを超えてAFTRに向けて論理的に拡張します。このアプローチにより、アクセスネットワークでIPv4アドレスのオーバーラップがサポートされ、アクセスデバイスまたはアクセスアーキテクチャを変更する必要がありません。アクセスネットワークでの追加のトンネリングオーバーヘッドも省略されます。たとえば、Generic Routing Encapsulation（GRE）に基づくカプセル化メカニズムを選択すると、アクセスゲートウェイとAFTRの間のネットワークをIPv4またはIPv6にでき、オペレーターはIPv6に段階的に移行できます。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 [RFC2119]で説明されているように解釈されます。
The following abbreviations are used within this document:
このドキュメントでは、次の略語を使用しています。
AFTR: Address Family Transition Router. An AFTR combines IP-in-IP tunnel termination and IPv4-IPv4 NAT.
AFTR：アドレスファミリ遷移ルーター。 AFTRは、IP-in-IPトンネル終端とIPv4-IPv4 NATを組み合わせたものです。
AD: Access Device. It is the end host, also known as the mobile node in mobile architectures.
AD：デバイスにアクセスします。これは、モバイルアーキテクチャではモバイルノードとも呼ばれるエンドホストです。
AG: Access Gateway. A gateway in the access network, such as LMA, Home Agent (HA), GGSN, or PDN-GW in mobile architectures.
AG：Access Gateway。モバイルアーキテクチャのLMA、ホームエージェント（HA）、GGSN、PDN-GWなどのアクセスネットワークのゲートウェイ。
CID: Context Identifier
CID：コンテキスト識別子
DS-Lite: Dual-Stack Lite
DS-Lite：デュアルスタックライト
GGSN: Gateway GPRS Support Node
GGSN：ゲートウェイGPRSサポートノード
GI-DS-Lite: Gateway-Initiated DS-Lite
GI-DS-Lite：ゲートウェイで開始されるDS-Lite
NAT: Network Address Translator
NAT：ネットワークアドレストランスレータ
PDN-GW: Packet Data Network Gateway
PDN-GW：パケットデータネットワークゲートウェイ
SW: Softwire [RFC4925]
SW：Softwire [RFC4925]
SWID: Softwire Identifier
SWID：Softwire Identifier
This section provides an overview of Gateway-Initiated DS-Lite (GI-DS-Lite). Figure 1 outlines the generic deployment scenario for GI-DS-Lite. This generic scenario can be mapped to multiple different access architectures, some of which are described in Appendix A.
このセクションでは、ゲートウェイ開始DS-Lite（GI-DS-Lite）の概要について説明します。図1は、GI-DS-Liteの一般的な展開シナリオの概要を示しています。この一般的なシナリオは、複数の異なるアクセスアーキテクチャにマッピングできます。その一部は、付録Aで説明されています。
In Figure 1, access devices (AD-1 and AD-2) are connected to the access gateway using some form of tunnel technology and the same is used for carrying IPv4 (and optionally IPv6) traffic of the access device. These access devices may also be connected to the access gateway over point-to-point links. The details on how the network delivers the IPv4 address configuration to the access devices are specific to the access architecture and are outside the scope of this document. With GI-DS-Lite, the access gateway and AFTR are connected by a softwire [RFC4925]. The softwire is identified by a softwire identifier (SWID). The SWID does not need to be globally unique, i.e., different SWIDs could be used to identify a softwire at the different ends of a softwire. The form of the SWID depends on the tunneling technology used for the softwire. The SWID could, for example, be the endpoints of a GRE tunnel or a VPN-ID. See Section 6 for details. A Context Identifier (CID) is used to multiplex flows associated with the individual access devices onto the softwire. It is deployment dependent whether the flows from a particular AD are identified using the source IP address or an access tunnel identifier. Local policies at the access gateway determine which part of the traffic received from an access device is tunneled over the softwire to the AFTR. The combination of CID and SWID must be unique between the access gateway and AFTR to identify the flows associated with an AD. The CID is typically a 32-bit-wide identifier and is assigned by the access gateway. It is retrieved either from a local or remote (e.g., Authentication, Authorization, and Accounting (AAA)) repository. Like the SWID, the embodiment of the CID depends on the tunnel mode used and the type of the network connecting the access gateway and AFTR. If, for example, GRE [RFC2784] with GRE Key and Sequence Number extensions [RFC2890] is used as the softwire technology, the network connecting the access gateway and AFTR could be a IPv4-only, IPv6-only, or dual-stack IP network. The CID would be carried within the GRE Key field. Section 6 details the different softwire types supported with GI-DS-Lite.
図1では、アクセスデバイス（AD-1およびAD-2）は、なんらかのトンネル技術を使用してアクセスゲートウェイに接続されており、アクセスデバイスのIPv4（およびオプションでIPv6）トラフィックを伝送するために使用されます。これらのアクセスデバイスは、ポイントツーポイントリンクを介してアクセスゲートウェイに接続することもできます。ネットワークがIPv4アドレス構成をアクセスデバイスに配信する方法の詳細は、アクセスアーキテクチャに固有であり、このドキュメントの範囲外です。 GI-DS-Liteでは、アクセスゲートウェイとAFTRはソフトワイヤー[RFC4925]で接続されます。ソフトワイヤは、ソフトワイヤ識別子（SWID）によって識別されます。 SWIDはグローバルに一意である必要はありません。つまり、異なるSWIDを使用して、ソフトワイヤーの異なる端にあるソフトワイヤーを識別できます。 SWIDの形式は、ソフトワイヤーに使用されるトンネリング技術に依存します。 SWIDは、たとえば、GREトンネルまたはVPN-IDのエンドポイントにすることができます。詳細については、セクション6を参照してください。コンテキスト識別子（CID）は、個々のアクセスデバイスに関連付けられたフローをソフトワイヤーに多重化するために使用されます。特定のADからのフローが送信元IPアドレスまたはアクセストンネル識別子を使用して識別されるかどうかは、展開に依存します。アクセスゲートウェイのローカルポリシーは、アクセスデバイスから受信したトラフィックのどの部分がソフトワイヤーを介してAFTRにトンネルされるかを決定します。 ADに関連付けられたフローを識別するために、CIDとSWIDの組み合わせは、アクセスゲートウェイとAFTRの間で一意である必要があります。 CIDは通常32ビット幅の識別子であり、アクセスゲートウェイによって割り当てられます。ローカルまたはリモート（認証、承認、アカウンティング（AAA）など）のリポジトリから取得されます。 SWIDと同様に、CIDの実施形態は、使用されるトンネルモードと、アクセスゲートウェイとAFTRを接続するネットワークのタイプによって異なります。たとえば、GRE [RFC2784]とGREキーとシーケンス番号の拡張[RFC2890]をソフトワイヤー技術として使用する場合、アクセスゲートウェイとAFTRを接続するネットワークは、IPv4のみ、IPv6のみ、またはデュアルスタックIPになります。通信網。 CIDはGREキーフィールド内に保持されます。セクション6では、GI-DS-Liteでサポートされているさまざまなソフトワイヤータイプについて詳しく説明します。
Access Device: AD-1
Context ID: CID-1
NAT Mappings:
IPv4: a.b.c.d +---+ (CID-1, TCP port1 <->
+------+ access tunnel | | e.f.g.h, TCP port2)
| AD-1 |=================| | +---+
+------+ | | | A |
| | Softwire SWID-1 | F |
| A |==========================| T |
IPv4: a.b.c.d | G | (e.g., IPv4-over-GRE | R |
+------+ | | over IPv4 or IPv6) +---+
| AD-2 |=================| |
+------+ access tunnel | | (CID-2, TCP port3 <->
| | e.f.g.h, TCP port4)
+---+
Access Device: AD-2 Context ID: CID-2
アクセスデバイス：AD-2コンテキストID：CID-2
Figure 1: Gateway-Initiated Dual-Stack Lite Reference Architecture
図1：ゲートウェイ起動のデュアルスタックライトリファレンスアーキテクチャ
The AFTR combines softwire termination and IPv4-IPv4 NAT. The NAT binding of the AD's address could be assigned autonomously by the AFTR from a local address pool, configured on a per-binding basis (either by a remote control entity through a NAT control protocol or through manual configuration), or derived from the CID (e.g., the CID, if 32 bits wide, could be mapped 1:1 to an external IPv4 address). A simple example of a translation table at the AFTR is shown in Figure 2. The choice of the appropriate translation scheme for a traffic flow can take into account parameters such as destination IP address, incoming interface, etc. The IP address of the AFTR, which will either be an IPv6 or an IPv4 address depending on the transport network between the access gateway and the AFTR, is configured on the access gateway. A variety of methods, such as out-of-band mechanisms or manual configuration, apply.
AFTRは、ソフトワイヤー終端とIPv4-IPv4 NATを組み合わせたものです。 ADのアドレスのNATバインディングは、ローカルアドレスプールからAFTRによって自律的に割り当てられたり、バインディングごとに（NAT制御プロトコルを介したリモート制御エンティティによって、または手動構成によって）構成されたり、CIDから派生したりできます。 （たとえば、CIDは、32ビット幅の場合、外部IPv4アドレスに1：1でマッピングできます）。 AFTRでの変換テーブルの簡単な例を図2に示します。トラフィックフローに適した変換スキームの選択では、宛先IPアドレス、着信インターフェイスなどのパラメーターを考慮することができます。AFTRのIPアドレス、これは、アクセスゲートウェイとAFTR間のトランスポートネットワークに応じてIPv6またはIPv4アドレスのいずれかであり、アクセスゲートウェイで構成されます。アウトオブバンドメカニズムや手動設定など、さまざまな方法が適用されます。
+=====================================+======================+
| Softwire-ID/Context-ID/IPv4/Port | Public IPv4/Port |
+=====================================+======================+
| SWID-1/CID-1/a.b.c.d/TCP-port1 | e.f.g.h/TCP-port2 |
| | |
| SWID-1/CID-2/a.b.c.d/TCP-port3 | e.f.g.h/TCP-port4 |
+-------------------------------------+----------------------+
Figure 2: Example Translation Table at the AFTR
図2：AFTRでの変換テーブルの例
GI-DS-Lite does not require a 1:1 relationship between an access gateway and AFTR, but more generally applies to (M:N) scenarios, where M access gateways are connected to N AFTRs. Multiple access gateways could be served by a single AFTR. AFTRs could be dedicated to specific groups of access-devices, groups of access gateways, or geographic regions. An AFTR could be, but does not have to be, co-located with an access gateway.
GI-DS-Liteでは、アクセスゲートウェイとAFTRの間に1対1の関係は必要ありませんが、より一般的には、MのアクセスゲートウェイがN個のAFTRに接続されている（M：N）シナリオに適用されます。複数のアクセスゲートウェイを単一のAFTRで処理できます。 AFTRは、アクセスデバイスの特定のグループ、アクセスゲートウェイのグループ、または地理的領域専用にすることができます。 AFTRは、アクセスゲートウェイと同じ場所に配置できますが、同じ場所に配置する必要はありません。
o Depending on the embodiment of the CID (e.g., for GRE encapsulation with GRE Key), the NAT binding entry maintained at the AFTR, which reflects an active flow between an access device inside the network and a node in the Internet, SHOULD be extended to include the CID and the identifier of the softwire (SWID).
o CIDの実施形態に応じて（たとえば、GREキーを使用したGREカプセル化の場合）、ネットワーク内のアクセスデバイスとインターネット内のノード間のアクティブフローを反映する、AFTRで維持されるNATバインディングエントリは、以下に拡張する必要があります。 CIDとソフトワイヤーの識別子（SWID）を含めます。
o When creating an IPv4-to-IPv4 NAT binding for an IPv4 packet flow received from the access gateway over the softwire, the AFTR SHOULD associate the CID with that NAT binding. It SHOULD use the combination of CID and SWID as the unique identifier and use those parameters in the NAT binding entry.
o ソフトワイヤーを介してアクセスゲートウェイから受信したIPv4パケットフローのIPv4-to-IPv4 NATバインディングを作成する場合、AFTRはCIDをそのNATバインディングに関連付ける必要があります（SHOULD）。一意の識別子としてCIDとSWIDの組み合わせを使用し、NATバインディングエントリでこれらのパラメーターを使用する必要があります（SHOULD）。
o When forwarding a packet to the access device, the AFTR SHOULD obtain the CID from the NAT binding associated with that flow. For example, in case of GRE encapsulation, it SHOULD add the CID to the GRE Key and Sequence Number extension of the GRE header and tunnel it to the access gateway.
o パケットをアクセスデバイスに転送するとき、AFTRはそのフローに関連付けられているNATバインディングからCIDを取得する必要があります（SHOULD）。たとえば、GREカプセル化の場合、GREヘッダーのGREキーとシーケンス番号拡張にCIDを追加し、それをアクセスゲートウェイにトンネリングする必要があります（SHOULD）。
o On receiving any packet from the softwire, the AFTR SHOULD obtain the CID from the incoming packet and use it for performing NAT binding lookup and packet translation before forwarding the packet.
o ソフトワイヤーからパケットを受信すると、AFTR SHOULDは着信パケットからCIDを取得し、それを使用してパケットを転送する前にNATバインディングルックアップとパケット変換を実行します。
o The access gateway, on receiving any IPv4 packet from the access device, SHOULD lookup the CID for that access device. In case of GRE encapsulation, it can, for example, add the CID to the GRE Key and Sequence Number extension of the GRE header and tunnel it to the AFTR.
o アクセスゲートウェイは、アクセスデバイスからIPv4パケットを受信すると、そのアクセスデバイスのCIDを検索する必要があります（SHOULD）。 GREカプセル化の場合、たとえば、CIDをGREヘッダーのGREキーおよびシーケンス番号拡張に追加し、それをAFTRにトンネルすることができます。
o On receiving any packet from the softwire, the access gateway SHOULD obtain the CID from the packet and use it for making the forwarding decision.
o ソフトワイヤーからパケットを受信すると、アクセスゲートウェイは、パケットからCIDを取得して、転送の決定に使用する必要があります（SHOULD）。
o When encapsulating an IPv4 packet, the access gateway and AFTR SHOULD use its Diffserv Codepoint (DSCP) to derive the DSCP (or MPLS Traffic-Class Field in the case of MPLS) of the softwire.
o IPv4パケットをカプセル化する場合、アクセスゲートウェイとAFTRは、Diffservコードポイント（DSCP）を使用して、ソフトワイヤーのDSCP（またはMPLSの場合はMPLSトラフィッククラスフィールド）を導出する必要があります（SHOULD）。
The following are the considerations related to the operational management of the softwire between the AFTR and access gateway.
AFTRとアクセスゲートウェイ間のソフトワイヤの運用管理に関する考慮事項を次に示します。
o The softwire between the access gateway and the AFTR MAY be created at system startup time OR dynamically established on-demand. It is deployment dependent which Operations, Administration, and Maintenance (OAM) mechanisms (such as ICMP, Bidirectional Forwarding Detection (BFD) [RFC5880], or Label Switched Path (LSP) ping [RFC4379]) are employed by the access gateway and AFTR for softwire health management and corresponding protection strategies.
o アクセスゲートウェイとAFTRの間のソフトワイヤーは、システムの起動時に作成することも、オンデマンドで動的に確立することもできます（MAY）。アクセスゲートウェイとAFTRが使用する運用、管理、およびメンテナンス（OAM）メカニズム（ICMP、双方向転送検出（BFD）[RFC5880]、またはラベルスイッチドパス（LSP）ping [RFC4379]など）は、展開に依存します。ソフトワイヤーの健康管理と対応する保護戦略。
o The softwire peers MAY be provisioned to perform policy enforcement, such as for determining the protocol type or overall portion of traffic that gets tunneled or for any other settings related to quality of service. The specific details on how this is achieved or the types of policies that can be applied are outside the scope for this document.
o ソフトワイヤピアは、プロトコルタイプや、トンネルされるトラフィックの全体的な部分を決定したり、サービス品質に関連するその他の設定を決定したりするなど、ポリシーを実施するためにプロビジョニングされる場合があります。これがどのように達成されるか、または適用できるポリシーのタイプに関する具体的な詳細は、このドキュメントの範囲外です。
o The softwire peers SHOULD use the correct path MTU value for the tunnel path between the access gateway and the AFTR. This value MAY be statically configured at softwire creation time or dynamically discovered using the standard path MTU discovery techniques.
o ソフトワイヤピアは、アクセスゲートウェイとAFTR間のトンネルパスに正しいパスMTU値を使用する必要があります（SHOULD）。この値は、ソフトワイヤーの作成時に静的に構成することも、標準パスMTU検出手法を使用して動的に検出することもできます。
o An access gateway and an AFTR can have multiple softwires established between them (e.g., to separate address domains, provide for load-sharing, etc.).
o アクセスゲートウェイとAFTRは、それらの間に確立された複数のソフトワイヤーを持つことができます（たとえば、アドレスドメインを分離するため、負荷共有を提供するためなど）。
Which tunnel technologies can be applied for the softwire connecting an access gateway and AFTR are dependent on the deployment and the requirements. GRE encapsulation with GRE Key extension, MPLS VPNs [RFC4364], or plain IP-in-IP encapsulation can be used. Softwire identification and CID depend on the tunneling technology employed:
アクセスゲートウェイとAFTRを接続するソフトワイヤに適用できるトンネルテクノロジーは、展開と要件によって異なります。 GREキー拡張を使用したGREカプセル化、MPLS VPN [RFC4364]、またはプレーンIP-in-IPカプセル化を使用できます。ソフトワイヤーの識別とCIDは、採用されているトンネリング技術に依存します。
o GRE with GRE Key: SWID is the tunnel identifier of the GRE tunnel between the access gateway and the AFTR. The CID is the GRE Key associated with the AD.
o GREキー付きGRE：SWIDは、アクセスゲートウェイとAFTR間のGREトンネルのトンネル識別子です。 CIDはADに関連付けられたGREキーです。
o MPLS VPN: The SWID is a generic identifier that uniquely identifies the VPN at either the access gateway or AFTR. Depending on whether the access gateway or AFTR is acting as customer edge (CE) or provider edge (PE), the SWID could, for example, be an attachment circuit identifier, an identifier representing the set of VPN route labels pointing to the routes within the VPN, etc. The AD's IPv4 address is the CID. For a given VPN, the AD's IPv4 address must be unique.
o MPLS VPN：SWIDは、アクセスゲートウェイまたはAFTRでVPNを一意に識別する一般的な識別子です。アクセスゲートウェイまたはAFTRがカスタマーエッジ（CE）として機能しているか、プロバイダーエッジ（PE）として機能しているかに応じて、SWIDは、たとえば、接続回線識別子、内のルートを指すVPNルートラベルのセットを表す識別子になるVPNなど。ADのIPv4アドレスはCIDです。特定のVPNでは、ADのIPv4アドレスは一意である必要があります。
o IPv4/IPv6-in-MPLS: The SWID is the top MPLS label. CID might be the next MPLS label in the stack, if present, or the IP address of the AD.
o IPv4 / IPv6-in-MPLS：SWIDはトップMPLSラベルです。 CIDは、スタック内の次のMPLSラベル（存在する場合）、またはADのIPアドレスです。
o IPv4-in-IPv4: SWID is the outer IPv4 source address. The AD's IPv4 address is the CID. For a given outer IPv4 source address, the AD's IPv4 address must be unique.
o IPv4-in-IPv4：SWIDは外部IPv4送信元アドレスです。 ADのIPv4アドレスはCIDです。特定の外部IPv4送信元アドレスの場合、ADのIPv4アドレスは一意である必要があります。
o IPv4-in-IPv6: SWID is the outer IPv6 source address. If the AD's IPv4 address is used as CID, the AD's IPv4 address must be unique. If the IPv6 Flow Label [RFC6437] is used as CID, the IPv4 addresses of the ADs may overlap. Given that the IPv6 Flow Label is 20 bits wide, which is shorter than the recommended 32-bit CID, large-scale deployments may require additional scaling considerations. In addition, one should ensure sufficient randomization of the IP Flow Label to avoid possible interference with other uses of the IP Flow Label, such as Equal Cost Multipath (ECMP) support.
o IPv4-in-IPv6：SWIDは外部IPv6送信元アドレスです。 ADのIPv4アドレスがCIDとして使用される場合、ADのIPv4アドレスは一意である必要があります。 IPv6フローラベル[RFC6437]がCIDとして使用されている場合、ADのIPv4アドレスが重複する可能性があります。 IPv6フローラベルが20ビット幅であり、推奨される32ビットCIDよりも短いことを考えると、大規模な展開では、追加のスケーリングの考慮が必要になる場合があります。さらに、IPフローラベルの十分なランダム化を確実にして、等コストマルチパス（ECMP）サポートなど、IPフローラベルの他の使用との干渉を回避する必要があります。
Figure 3 gives an overview of the different tunnel modes as they apply to different deployment scenarios. "x" indicates that a certain deployment scenario is supported. The following abbreviations are used:
図3は、さまざまな導入シナリオに適用されるさまざまなトンネルモードの概要を示しています。 「x」は、特定の展開シナリオがサポートされていることを示します。以下の略語が使用されています。
o IPv4 address
o IPv4アドレス
* "up": Deployments with "unique private IPv4 addresses" assigned to the access devices are supported.
* 「up」：「一意のプライベートIPv4アドレス」がアクセスデバイスに割り当てられた展開がサポートされます。
* "op": Deployments with "overlapping private IPv4 addresses" assigned to the access devices are supported.
* "op"：アクセスデバイスに割り当てられた "重複するプライベートIPv4アドレス"を持つ展開がサポートされます。
* "s": Deployments where all access devices are assigned the same IPv4 address are supported.
* "s"：すべてのアクセスデバイスに同じIPv4アドレスが割り当てられている展開がサポートされています。
o Network-type
o ネットワーク型
* "v4": The access gateway and AFTR are connected by an IPv4-only network.
* "v4"：アクセスゲートウェイとAFTRはIPv4のみのネットワークで接続されています。
* "v6": The access gateway and AFTR are connected by an IPv6-only network.
* "v6"：アクセスゲートウェイとAFTRはIPv6のみのネットワークで接続されています。
* "v4v6": The access gateway and AFTR are connected by a dual-stack network, supporting IPv4 and IPv6.
* 「v4v6」：アクセスゲートウェイとAFTRは、IPv4とIPv6をサポートするデュアルスタックネットワークで接続されています。
* "MPLS": The access gateway and AFTR are connected by an MPLS network
* 「MPLS」：アクセスゲートウェイとAFTRはMPLSネットワークで接続されています
+===================+==============+=======================+
| | IPv4 address| Network-type |
| Softwire +----+----+---+----+----+------+------+
| | up | op | s | v4 | v6 | v4v6 | MPLS |
+====================+====+====+===+====+====+======+======+
| GRE with GRE Key | x | x | x | x | x | x | |
| MPLS VPN | x | x | | | | | x |
| IPv4/IPv6-in-MPLS | x | x | x | | | | x |
| IPv4-in-IPv4 | x | | | x | | | |
| IPv4-in-IPv6 | x | | | | x | | |
| IPv4-in-IPv6 w/ FL | x | x | x | | x | | |
+====================+====+====+===+====+====+======+======+
Figure 3: Tunnel Modes and Their Applicability
図3：トンネルモードとその適用性
The approach specified in this document allows the use of Dual-Stack Lite for tunnel-based access architectures. Rather than initiating the tunnel from the access device, GI-DS-Lite logically extends the already existing access tunnel beyond the access gateway towards the AFTR and builds a virtual softwire between the AFTR and the access device. This approach requires the use of an additional Context Identifier in the AFTR and at the access gateway, which is required for making IP packet-forwarding decisions.
このドキュメントで指定されているアプローチでは、トンネルベースのアクセスアーキテクチャにDual-Stack Liteを使用できます。 GI-DS-Liteは、アクセスデバイスからトンネルを開始するのではなく、既存のアクセストンネルをアクセスゲートウェイを超えてAFTRに向けて論理的に拡張し、AFTRとアクセスデバイスの間に仮想ソフトワイヤーを構築します。この方法では、AFTRとアクセスゲートウェイで追加のコンテキスト識別子を使用する必要があります。これは、IPパケット転送の決定に必要です。
If a packet is received with an incorrect Context Identifier at the access gateway/AFTR, it will be associated with an incorrect access device. Therefore, care must be taken to ensure an IP packet tunneled between the access gateway and the AFTR is carried with the Context Identifier of the access device associated with that IP packet. The Context Identifier is not carried from the access device, and it is not possible for one access device to claim the Context Identifier of some other access device. However, it is possible that an on-path attacker between the access gateway and the AFTR can potentially modify the Context Identifier in the packet, resulting in association of the packet to an incorrect access device. This threat is no different from an on-path attacker modifying the source/destination address of an IP packet. However, this threat can be prevented by enabling IPsec security with integrity protection turned on, between the access gateway and the AFTR, that will ensure the correct binding of the Context Identifier and the inner packet. This specification does not require any new security considerations other than those specified in the Dual-Stack Lite specification [RFC6333] and in the security considerations specified for the given access architecture, such as Proxy Mobile IPv6, leveraging this transitioning scheme.
パケットがアクセスゲートウェイ/ AFTRで誤ったコンテキスト識別子とともに受信された場合、そのパケットは誤ったアクセスデバイスに関連付けられます。したがって、アクセスゲートウェイとAFTRの間でトンネリングされたIPパケットが、そのIPパケットに関連付けられたアクセスデバイスのコンテキストIDで確実に伝送されるように注意する必要があります。コンテキスト識別子はアクセスデバイスから送信されず、1つのアクセスデバイスが他のアクセスデバイスのコンテキスト識別子を要求することはできません。ただし、アクセスゲートウェイとAFTR間のパス上の攻撃者がパケットのコンテキスト識別子を変更し、パケットを誤ったアクセスデバイスに関連付ける可能性があります。この脅威は、経路上の攻撃者がIPパケットの送信元/宛先アドレスを変更することと同じです。ただし、アクセスゲートウェイとAFTRの間で整合性保護をオンにしてIPsecセキュリティを有効にし、コンテキスト識別子と内部パケットの正しいバインディングを保証することで、この脅威を防ぐことができます。この仕様では、Dual-Stack Lite仕様[RFC6333]で指定されているセキュリティの考慮事項、およびこの移行スキームを活用するプロキシモバイルIPv6などの特定のアクセスアーキテクチャに指定されているセキュリティの考慮事項で、新しいセキュリティに関する考慮事項は必要ありません。
The authors would like to acknowledge the discussions on this topic with Mark Grayson, Jay Iyer, Kent Leung, Vojislav Vucetic, Flemming Andreasen, Dan Wing, Jouni Korhonen, Teemu Savolainen, Parviz Yegani, Farooq Bari, Mohamed Boucadair, Vinod Pandey, Jari Arkko, Eric Voit, Yiu L. Lee, Tina Tsou, Guo-Liang Yang, Cathy Zhou, Olaf Bonness, Paco Cortes, Jim Guichard, Stephen Farrell, Pete Resnik, and Ralph Droms.
著者はこのトピックに関するディスカッションをマークグレイソン、ジェイアイエル、ケントレオン、ヴォージスラフヴーチェティック、フレミングアンドレアセン、ダンウィング、ジョウニコロホネン、ティームサヴォライネン、パルヴィズイェガニ、ファルークバリ、モハメドブーカデール、ヴィノッドパンデイ、ジャリアルコ、Eric Voit、Yiu L. Lee、Tina Tsou、Guo-Liang Yang、Cathy Zhou、Olaf Bonness、Paco Cortes、Jim Guichard、Stephen Farrell、Pete Resnik、Ralph Droms。
[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、「プライベートインターネットのアドレス割り当て」、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月。
[RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, March 2000.
[RFC2784] Farinacci、D.、Li、T.、Hanks、S.、Meyer、D。、およびP. Traina、「Generic Routing Encapsulation（GRE）」、RFC 2784、2000年3月。
[RFC2890] Dommety, G., "Key and Sequence Number Extensions to GRE", RFC 2890, September 2000.
[RFC2890] Dommety、G。、「GREのキーとシーケンス番号の拡張」、RFC 2890、2000年9月。
[RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private Networks (VPNs)", RFC 4364, February 2006.
[RFC4364]ローゼン、E。およびY.レクター、「BGP / MPLS IP仮想プライベートネットワーク（VPN）」、RFC 4364、2006年2月。
[RFC4379] Kompella, K. and G. Swallow, "Detecting Multi-Protocol Label Switched (MPLS) Data Plane Failures", RFC 4379, February 2006.
[RFC4379] Kompella、K。およびG. Swallow、「Detecting Multi-Protocol Label Switched（MPLS）Data Plane Failures」、RFC 4379、2006年2月。
[RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008.
[Rufsey1] Gundavelli、S.、Leunji、K.、Devarapalli、V.、Chowdhury、K。、およびB. Patil、「Proxy Mobile Ipp 1」、Rfak 2、2009年8月。
[RFC5555] Soliman, H., "Mobile IPv6 Support for Dual Stack Hosts and Routers", RFC 5555, June 2009.
[RFC5555]ソリマンH.、「デュアルスタックホストとルーターのモバイルIPv6サポート」、RFC 5555、2009年6月。
[RFC5844] Wakikawa, R. and S. Gundavelli, "IPv4 Support for Proxy Mobile IPv6", RFC 5844, May 2010.
[RFC5844]脇川R.およびS. Gundavelli、「プロキシモバイルIPv6のIPv4サポート」、RFC 5844、2010年5月。
[RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection (BFD)", RFC 5880, June 2010.
[RFC5880] Katz、D。およびD. Ward、「Bidirectional Forwarding Detection（BFD）」、RFC 5880、2010年6月。
[RFC6275] Perkins, C., Johnson, D., and J. Arkko, "Mobility Support in IPv6", RFC 6275, July 2011.
[RFC6275] Perkins、C.、Johnson、D。、およびJ. Arkko、「IPv6でのモビリティサポート」、RFC 6275、2011年7月。
[RFC6333] Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual-Stack Lite Broadband Deployments Following IPv4 Exhaustion", RFC 6333, August 2011.
[RFC6333] Durand、A.、Droms、R.、Woodyatt、J。、およびY. Lee、「IPv4枯渇後のデュアルスタックLiteブロードバンド展開」、RFC 6333、2011年8月。
[RFC6437] Amante, S., Carpenter, B., Jiang, S., and J. Rajahalme, "IPv6 Flow Label Specification", RFC 6437, November 2011.
[RFC6437] Amante、S.、Carpenter、B.、Jiang、S.、J。Rajahalme、「IPv6 Flow Label Specification」、RFC 6437、2011年11月。
[NAT-CONTROL] Brockners, F., Bhandari, S., Singh, V., and V. Fajardo, "Diameter Network Address and Port Translation Control Application", Work in Progress, April 2012.
[NAT-CONTROL] Brockners、F.、Bhandari、S.、Singh、V。、およびV. Fajardo、「Diameterネットワークアドレスおよびポート変換制御アプリケーション」、作業中、2012年4月。
[RFC4925] Li, X., Dawkins, S., Ward, D., and A. Durand, "Softwire Problem Statement", RFC 4925, July 2007.
[RFC4925] Li、X.、Dawkins、S.、Ward、D。、およびA. Durand、「Softwire Problem Statement」、RFC 4925、2007年7月。
[TR101] Broadband Forum, "TR-101: Migration to Ethernet-Based DSL Aggregation", April 2006.
[TR101]ブロードバンドフォーラム、「TR-101：Migration to Ethernet-Based DSL Aggregation」、2006年4月。
[TR59] Broadband Forum, "TR-059: DSL Evolution - Architecture Requirements for the Support of QoS-Enabled IP Services", September 2003.
[TR59]ブロードバンドフォーラム、「TR-059：DSL Evolution-QoS対応IPサービスをサポートするためのアーキテクチャ要件」、2003年9月。
[TS23060] 3GPP, "Technical Specification Group Services and System Aspects; General Packet Radio Service (GPRS); Service description; Stage 2, V11.2.0", TS 23.060, 2012.
[TS23060] 3GPP、「技術仕様グループサービスとシステムの側面、一般パケット無線サービス（GPRS）、サービスの説明、ステージ2、V11.2.0」、TS 23.060、2012。
[TS23401] 3GPP, "Technical Specification Group Services and System Aspects; General Packet Radio Service (GPRS) enhancements for Evolved Universal Terrestrial Radio Access Network (E-UTRAN) access, V11.1.0", TS 23.401, 2012.
[TS23401] 3GPP、「技術仕様グループサービスとシステムの側面、進化型ユニバーサル地上無線アクセスネットワーク（E-UTRAN）アクセス用の一般パケット無線サービス（GPRS）拡張、V11.1.0」、TS 23.401、2012年。
[TS29060] 3GPP, "Technical Specification Group Core Network and Terminals; General Packet Radio Service (GPRS); GPRS Tunnelling Protocol (GTP), V11.3.0", TS 29.060, 2012.
[TS29060] 3GPP、「Technical Specification Group Core Network and Terminals; General Packet Radio Service（GPRS）; GPRS Tunneling Protocol（GTP）、V11.3.0」、TS 29.060、2012。
Figure 4 shows an example call flow - linking access tunnel establishment on the access gateway with the softwire to the AFTR. This simple example assumes that traffic from the AD uses a single access tunnel and that the access gateway will use local policies to decide which portion of the traffic received over this access tunnel needs to be forwarded to the AFTR.
図4は、コールフローの例を示しています。アクセスゲートウェイでのアクセストンネルの確立とソフトワイヤーをAFTRにリンクしています。この簡単な例では、ADからのトラフィックが単一のアクセストンネルを使用し、アクセスゲートウェイがローカルポリシーを使用して、このアクセストンネルを介して受信したトラフィックのどの部分をAFTRに転送する必要があるかを決定することを想定しています。
AD Access Gateway AAA/Policy AFTR
| | | |
|----(1)-------->| | |
| (2)<-------------->| |
| (3) | |
| |<------(4)------------------->|
| (5) | |
|<---(6)-------->| | |
| | | |
Figure 4: Example Call Flow for Session Establishment
図4：セッション確立のコールフローの例
1. The access gateway receives a request to create an access tunnel endpoint.
1. アクセスゲートウェイは、アクセストンネルエンドポイントを作成する要求を受け取ります。
2. The access gateway authenticates and authorizes the access tunnel. Based on local policy or through interaction with the AAA/Policy system, the access gateway recognizes that IPv4 service should be provided using GI-DS-Lite.
2. アクセスゲートウェイは、アクセストンネルを認証および承認します。ローカルポリシーに基づいて、またはAAA / Policyシステムとの対話を通じて、アクセスゲートウェイは、GI-DS-Liteを使用してIPv4サービスを提供する必要があることを認識します。
3. The access gateway creates an access tunnel endpoint. The access tunnel links AD and access gateway.
3. アクセスゲートウェイは、アクセストンネルエンドポイントを作成します。アクセストンネルはADとアクセスゲートウェイをリンクします。
4. (Optional): The access gateway and the AFTR establish a control session between themselves. This session can, for example, be used to exchange accounting or NAT-configuration information. Accounting information could be supplied to the access gateway, AAA/Policy, or other network entities that require information about the externally visible address/port pairs of a particular access device. The Diameter NAT Control Application [NAT-CONTROL] could, for example, be used for this purpose.
4. （オプション）：アクセスゲートウェイとAFTRは、それらの間の制御セッションを確立します。このセッションは、たとえば、アカウンティングまたはNAT構成情報の交換に使用できます。アカウンティング情報は、アクセスゲートウェイ、AAA /ポリシー、または特定のアクセスデバイスの外部から見えるアドレス/ポートのペアに関する情報を必要とするその他のネットワークエンティティに提供できます。 Diameter NAT制御アプリケーション[NAT-CONTROL]は、たとえば、この目的に使用できます。
5. The access gateway allocates a unique CID and associates those flows received from the access tunnel that need to be tunneled towards the AFTR with the softwire linking the access gateway and AFTR. Local forwarding policy on the access gateway determines which traffic will need to be tunneled towards the AFTR.
5. アクセスゲートウェイは、一意のCIDを割り当て、アクセストンネルから受信した、AFTRに向けてトンネリングする必要があるフローを、アクセスゲートウェイとAFTRをリンクするソフトワイヤーに関連付けます。アクセスゲートウェイのローカル転送ポリシーは、AFTRに向けてトンネリングする必要があるトラフィックを決定します。
6. The access gateway and AD complete the access tunnel establishment. Depending on the procedures and mechanisms of the corresponding access network architecture, this step can include the assignment of an IPv4 address to the AD.
6. アクセスゲートウェイとADは、アクセストンネルの確立を完了します。対応するアクセスネットワークアーキテクチャの手順とメカニズムに応じて、このステップには、ADへのIPv4アドレスの割り当てを含めることができます。
The section outlines deployment examples of the generic GI-DS-Lite architecture described in Section 3.
このセクションでは、セクション3で説明した一般的なGI-DS-Liteアーキテクチャの配置例の概要を示します。
o Access architectures based on Mobile-IP: In a network scenario based on Dual-Stack Mobile IPv6 (DSMIPv6) [RFC5555], the Mobile IPv6 home agent will implement the GI-DS-Lite access gateway function along with the dual-stack Mobile IPv6 functionality.
o モバイルIPに基づくアクセスアーキテクチャ：デュアルスタックモバイルIPv6（DSMIPv6）[RFC5555]に基づくネットワークシナリオでは、モバイルIPv6ホームエージェントは、デュアルスタックモバイルIPv6とともにGI-DS-Liteアクセスゲートウェイ機能を実装します機能性。
o Access architectures based on Proxy Mobile IPv6 (PMIPv6): In a PMIPv6 [RFC5213] scenario, the local mobility anchor (LMA) will implement the GI-DS-Lite access gateway function along with the PMIPv6 IPv4 support [RFC5844] functionality.
o プロキシモバイルIPv6（PMIPv6）に基づくアクセスアーキテクチャ：PMIPv6 [RFC5213]シナリオでは、ローカルモビリティアンカー（LMA）がGI-DS-Liteアクセスゲートウェイ機能とPMIPv6 IPv4サポート[RFC5844]機能を実装します。
o GTP-based access architectures: Third Generation Partnership Project (3GPP) TS 23.401 [TS23401] and 3GPP TS 23.060 [TS23060] define mobile access architectures using GTP. For GI-DS-Lite, the PDN-GW or GGSN will also assume the access gateway function.
o GTPベースのアクセスアーキテクチャ：第3世代パートナーシッププロジェクト（3GPP）TS 23.401 [TS23401]および3GPP TS 23.060 [TS23060]は、GTPを使用したモバイルアクセスアーキテクチャを定義しています。 GI-DS-Liteの場合、PDN-GWまたはGGSNもアクセスゲートウェイ機能を担います。
o Fixed Worldwide Interoperability for Microwave Access (WiMAX) architecture: If GI-DS-Lite is applied to fixed WiMAX, the Access Service Network Gateway (ASN-GW) will implement the GI-DS-Lite access gateway function.
o マイクロ波アクセス（WiMAX）アーキテクチャの固定された世界的な相互運用性：固定WiMAXにGI-DS-Liteを適用すると、アクセスサービスネットワークゲートウェイ（ASN-GW）がGI-DS-Liteアクセスゲートウェイ機能を実装します。
o Mobile WiMAX: If GI-DS-Lite is applied to mobile WiMAX, the home agent will implement the access gateway function.
o モバイルWiMAX：GI-DS-LiteがモバイルWiMAXに適用される場合、ホームエージェントはアクセスゲートウェイ機能を実装します。
o PPP-based broadband access architectures: If GI-DS-Lite is applied to PPP-based access architectures, the Broadband Remote Access Server (BRAS) or Broadband Network Gateway (BNG) will implement the GI-DS-Lite access gateway function.
o PPPベースのブロードバンドアクセスアーキテクチャ：GI-DS-LiteがPPPベースのアクセスアーキテクチャに適用される場合、ブロードバンドリモートアクセスサーバー（BRAS）またはブロードバンドネットワークゲートウェイ（BNG）は、GI-DS-Liteアクセスゲートウェイ機能を実装します。
o In broadband access architectures using per-subscriber VLANs, the BNG will implement the GI-DS-Lite access gateway function.
o 加入者ごとのVLANを使用するブロードバンドアクセスアーキテクチャでは、BNGはGI-DS-Liteアクセスゲートウェイ機能を実装します。
Authors' Addresses
著者のアドレス
Frank Brockners Cisco Hansaallee 249, 3rd Floor Duesseldorf, Nordrhein-Westfalen 40549 Germany
フランクブロックナーのCisco Hansaallee 249、3rd Floor Duesseldorf、North Rhine-Westphalia 40549 Germany
EMail: fbrockne@cisco.com
Sri Gundavelli Cisco 170 West Tasman Drive San Jose, CA 95134 USA
Sri Gundavelli Cisco 170 West Tasman Drive San Jose、CA 95134 USA
EMail: sgundave@cisco.com
Sebastian Speicher Deutsche Telekom AG Landgrabenweg 151 Bonn, Nordrhein-Westfalen 53277 Germany
Sebastian Speicher Deutsche Telekom AG Landgrabenweg 151ボンノルトラインヴェストファーレン州ドイツ
EMail: sebastian.speicher@telekom.de
David Ward Cisco 170 West Tasman Drive San Jose, CA 95134 USA
David Ward Cisco 170 West Tasman Drive San Jose、CA 95134 USA
EMail: wardd@cisco.com