Network Working Group                                       Y. Shirasaki
Request for Comments: 4241                                   S. Miyakawa
Category: Informational                                      T. Yamasaki
                                                      NTT Communications
                                                           A. Takenouchi
                                                           December 2005
          A Model of IPv6/IPv4 Dual Stack Internet Access Service

Status of This Memo


This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.


Copyright Notice


Copyright (C) The Internet Society (2005).




This RFC is not a candidate for any level of Internet Standard. The IETF disclaims any knowledge of the fitness of this RFC for any purpose and notes that the decision to publish is not based on IETF review apart from IESG review for conflict with IETF work. The RFC Editor has chosen to publish this document at its discretion. See RFC 3932 for more information.

このRFCはインターネットStandardのどんなレベルの候補ではありません。 IETFは、いかなる目的のために、このRFCのフィットネスの知識を否認し、公開する決定がIETF仕事との競合のためのIESGレビューとは別にIETFレビューに基づいていないことを指摘しています。 RFC Editorはその裁量でこの文書を公開することを選択しました。詳細については、RFC 3932を参照してください。



This memo is a digest of the user network interface specification of NTT Communications' dual stack ADSL access service, which provide a IPv6/IPv4 dual stack services to home users. In order to simplify user setup, these services have a mechanism to configure IPv6 specific parameters automatically. The memo focuses on two basic parameters: the prefix assigned to the user and the addresses of IPv6 DNS servers, and it specifies a way to deliver these parameters to Customer Premises Equipment (CPE) automatically.

このメモは、ホームユーザへのIPv6 / IPv4デュアルスタックサービスを提供するNTTコミュニケーションズのデュアルスタックADSLアクセスサービスのユーザネットワークインターフェース仕様のダイジェストです。ユーザーのセットアップを簡素化するために、これらのサービスは自動的にIPv6の特定のパラメータを設定するためのメカニズムを持っています。メモは、2つの基本的なパラメータに焦点を当て:ユーザーとIPv6のDNSサーバのアドレスに割り当てられたプレフィックス、それが自動的に顧客宅内機器(CPE)にこれらのパラメータを提供する方法を指定します。

1. Introduction
1. はじめに

This memo is a digest of the user network interface specification of NTT Communications' dual stack ADSL access service, which provide IPv6/IPv4 dual stack services to home users. In order to simplify user setup, these services have a mechanism to configure IPv6 specific parameters automatically. The memo focuses on two basic parameters: the prefix assigned to the user and the addresses of IPv6 DNS servers, and it specifies a way to deliver these parameters to Customer Premises Equipment (CPE) automatically.

このメモは、ホームユーザへのIPv6 / IPv4デュアルスタックサービスを提供するNTTコミュニケーションズのデュアルスタックADSLアクセスサービスのユーザネットワークインターフェース仕様のダイジェストです。ユーザーのセットアップを簡素化するために、これらのサービスは自動的にIPv6の特定のパラメータを設定するためのメカニズムを持っています。メモは、2つの基本的なパラメータに焦点を当て:ユーザーとIPv6のDNSサーバのアドレスに割り当てられたプレフィックス、それが自動的に顧客宅内機器(CPE)にこれらのパラメータを提供する方法を指定します。

This memo covers two topics: an architecture for IPv6/IPv4 dual stack access service and an automatic configuration function for IPv6- specific parameters.

IPv6の/ IPv4デュアルスタックアクセスサービスのアーキテクチャとIPv6-特定のパラメータの自動設定機能:このメモは、二つのトピックをカバーしています。

The architecture is mainly targeted at a leased-line ADSL service for home users. It assumes that there is a Point-to-Point Protocol (PPP) logical link between Customer Premises Equipment (CPE) and Provider Edge (PE) equipment. In order to exclude factors that are specific to access lines, this architecture only specifies PPP and its upper layers. To satisfy [RFC3177], the prefix length that is delegated to the CPE is /48, but /64 is also a possible option.

アーキテクチャは、主にホームユーザー向けの専用線ADSLサービスを対象としています。それはそこにあることを前提としてポイントツーポイントプロトコル(PPP)顧客宅内機器(CPE)およびプロバイダーエッジ(PE)機器間の論理リンク。アクセス回線に固有の要因を排除するために、このアーキテクチャは、PPPとその上層を指定します。 [RFC3177]満たすために、CPEに委任されたプレフィックス長が/ 48であるが、/ 64はまた、可能なオプションです。

In this architecture, IPv6/IPv4 dual stack service is specified as follows.

次のようにこのアーキテクチャでは、IPv6の/ IPv4デュアルスタックサービスが指定されています。

o IPv6 and IPv4 connectivities are provided over a single PPP logical link.

O IPv6とIPv4の接続性は、単一のPPPの論理リンクを介して提供されています。

o IPv6 connectivity is independent of IPv4 connectivity. IPV6CP and IPCP work independently over a single PPP logical link.

O IPv6接続は、IPv4接続とは無関係です。 IPV6CPとIPCPは、単一のPPPの論理リンクを介して独立して動作します。

Figure 1 shows an outline of the service architecture. NTT Communications has been providing a commercial service based on this architecture since the Summer 2002.

図1は、サービスアーキテクチャの概要を示しています。 NTTコミュニケーションズは、2002年夏以降、このアーキテクチャに基づいた商用サービスを提供してきました。

          |                                             _____________
   [HOST]-+ +-----------+               +----------+   /             \
          | | Customer  |   ADSL line   | Provider |  | ISP core and  |
          +-+ Premises  +---------------+   Edge   |--| The internet  |
          | | Equipment | to subscriber +-----+----+   \_____________/
   [HOST]-+ +-----------+                     |         |   |
          |                             +-----+------+  | +-+----------+
                                        | AAA server |  | | DNS server |
                                        +------------+  | +------------+
                                                      | NTP server etc.|
    Figure 1: Dual Stack Access Service Architecture  +----------------+

The automatic configuration function aims at simplification of user setup. Usually, users have to configure at least two IPv6-specific parameters: prefix(es) assigned to them [RFC3769] and IPv6 DNS servers' addresses. The function is composed of two sub-functions:


o Delegation of prefix(es) to be used in the user site.


o Notification of IPv6 DNS server addresses and/or other server addresses.


Section 2 of this memo details the user/network interface. Section 3 describes an example connection sequence.


2. User/Network Interface

This section describes details of the user/network interface specification. Only PPP over Ethernet (PPPoE) and its upper layers are mentioned; the other layers, such as Ethernet and lower layers, are out of scope. IPv4-related parameter configuration is also out of scope.

このセクションでは、ユーザ/ネットワーク・インターフェース仕様の詳細について説明します。イーサネット上のPPP(PPPoEの)とその上層のみが記載されています。イーサネットおよび下部層のような他の層が、範囲外です。 IPv4の関連パラメータの設定範囲外でもあります。

2.1. Below the IP Layer
2.1. IP層の下

The service uses PPP connection and Challenge Handshake Authentication Protocol (CHAP) authentication to identify each CPE. The CPE and PE handle both the PPP Internet Protocol Control Protocol (IPCP) [RFC1332] and the Internet Protocol V6 Control Protocol (IPV6CP) [RFC2472] identically and simultaneously over a single PPP connection. This means either the CPE or the PE can open/close any Network Control Protocol (NCP) session at any time without any side-effect for the other. It is intended that users can choose among three services: IPv4 only, IPv6 only, and IPv4/IPv6 dual stack. A CPE connected to an ADSL line discovers a PE with the PPPoE mechanism [RFC2516].

サービスは、各CPEを識別するために、PPP接続およびチャレンジハンドシェイク認証プロトコル(CHAP)認証を使用します。 CPEとPEは、単一のPPP接続上同一と同時にPPPインターネットプロトコル制御プロトコル(IPCP)[RFC1332]とインターネット・プロトコルV6制御プロトコル(IPV6CP)[RFC2472]の両方を扱います。これは、CPE又はPEのいずれかが他のための任意の副作用なしに、いつでも任意のネットワーク制御プロトコル(NCP)セッションを閉じる/開くことができることを意味します。 IPv4のみ、IPv6のみ、とIPv4 / IPv6デュアルスタック:ユーザーが3つのサービスの中から選ぶことができることが意図されています。 ADSL回線に接続されたCPEは、PPPoEメカニズム[RFC2516]とPEを発見します。

Note that, because CPE and PE can negotiate only their interface identifiers with IPV6CP, PE and CPE can use only link-local-scope addresses before the prefix delegation mechanism described below is run.


2.2. IP Layer
2.2. IPレイヤ

After IPV6CP negotiation, the CPE initiates a prefix delegation request. The PE chooses a global-scope prefix for the CPE with information from an Authentication, Authorization, and Accounting (AAA) server or local prefix pools, and it delegates the prefix to the CPE. Once the prefix is delegated, the prefix is subnetted and assigned to the local interfaces of the CPE. The CPE begins sending router advertisements for the prefixes on each link. Eventually, hosts can acquire global-scope prefixes through conventional IPv6 stateless [RFC2462] or stateful auto-configuration mechanisms ([RFC3315], etc.) and begin to communicate using global-scope addresses.

IPV6CP交渉の後、CPEは、プレフィックス委任要求を開始します。 PEは、CPEにプレフィックスを認証、許可、アカウンティング(AAA)サーバまたはローカルプレフィックスプールからの情報とCPEのグローバルスコーププレフィックスを選択し、それが委任。プレフィックスが委任されると、プレフィックスはサブネットとCPEのローカルインタフェースに割り当てられています。 CPEは、各リンク上のプレフィックスのルータ通知の送信を開始します。最終的には、ホストは、従来のIPv6ステートレス[RFC2462]またはステートフル自動設定メカニズム([RFC3315]など)を介してグローバルスコーププレフィックスを取得し、グローバルスコープのアドレスを使用して通信を開始することができます。

2.3. Prefix Delegation
2.3. プレフィックス委任

The PE delegates prefixes to CPE using Dynamic Host Configuration Protocol for IPv6 (DHCPv6) [RFC3315] with the prefix delegation options [RFC3633]. The sequence for prefix delegation is as follows:

PE代議員IPv6の動的ホスト構成プロトコル(DHCPv6)プレフィックス委任オプションと[RFC3315] [RFC3633]を使用してCPEに接頭辞。次のようにプレフィックス委任のためのシーケンスは次のとおりです。

o The CPE requests prefix(es) from a PE by sending a DHCPv6 Solicit message that has a link-local source address negotiated by IPV6CP, mentioned in the previous section, and includes an IA_PD option.

O CPEは、前のセクションで述べたIPV6CPによってネゴシエートされたリンクローカル送信元アドレスを有したDHCPv6要請メッセージを送信することにより、PEから接頭語(es)を要求し、IA_PDオプションを含みます。

o An AAA server provides prefix(es) to the PE or the PE chooses prefix(es) from its local pool, and the PE returns an Advertise message that contains an IA_PD option and IA_PD Prefix options. The prefix-length in the IA_PD Prefix option is 48.

O AAAサーバは、そのローカルプールから接頭語(es)を選択し、PEはIA_PDオプションとIA_PDプレフィックスオプションを含む広告メッセージを返しPEまたはPEにプレフィックス(ES)を提供します。 IA_PD Prefixオプションでプレフィックス長は48です。

IA_PD option and IA_PD Prefix options for the chosen prefix(es) back to the PE.


o The PE confirms the prefix(es) in the Request message in a Reply message.

O PEは、応答メッセージ内の要求メッセージに接頭語(es)を確認します。

If IPV6CP is terminated or restarted by any reason, CPE must initiate a Rebind/Reply message exchange as described in [RFC3633].


2.4. Address Assignment
2.4. アドレスの割り当て

The CPE assigns global-scope /64 prefixes, subnetted from the delegated prefix, to its downstream interfaces. When the delegated prefix has an infinite lifetime, the preferred and valid lifetimes of assigned /64 prefixes should be the default values in [RFC2461].

CPEは、委譲されたプレフィックスから、その下流インタフェースにサブネットグローバルスコープ/ 64プレフィックスを割り当てます。委任プレフィックスが無限の寿命を持っている場合は、割り当てられた/ 64プレフィックスの優先及び有効寿命は[RFC2461]のデフォルト値でなければなりません。

Because a link-local address is already assigned to the CPE's upstream interface, global-scope address assignment for that interface is optional.


2.5. Routing
2.5. ルーティング

The CPE and PE use static routing between them, and no routing protocol traffic is necessary.


The CPE configures its PPPoE logical interface or the link-local address of PE as the IPv6 default gateway, automatically after the prefix delegation exchange.


When the CPE receives packets that are destined for the addresses in the delegated /48 prefix, the CPE must not forward the packets to a PE. The CPE should return ICMPv6 Destination Unreachable message to a source address or silently discard the packets, when the original packet is destined for the unassigned prefix in the delegated prefix. (For example, the CPE should install a reject route or null interface as next hop for the delegated prefix.)

CPEは、委任/ 48プレフィックスのアドレス宛てのパケットを受信した場合、CPEは、PEにパケットを転送してはなりません。 CPEは、送信元アドレスへのICMPv6宛先到達不能メッセージを返すか、静かに元のパケットが委任プレフィックス内の未割り当てのプレフィックスのために運命づけられているとき、パケットを破棄しなければなりません。 (例えば、CPEは、委譲されたプレフィックスの次のホップとしてリジェクト経路またはヌルインターフェイスをインストールしてください。)

2.6. Obtaining Addresses of DNS Servers
2.6. DNSサーバのアドレスを取得します

The service provides IPv6 recursive DNS servers in the ISP site. The PE notifies the global unicast addresses of these servers with the Domain Name Server option that is described in [RFC3646], in Advertise/Reply messages on the prefix delegation message exchange.

サービスは、ISPのサイトでのIPv6再帰的なDNSサーバを提供します。 PEは、中/広告プレフィックス委任メッセージ交換にメッセージを返信、[RFC3646]に記述されているドメインネームサーバオプションを使用して、これらのサーバのグローバルユニキャストアドレスに通知します。

Devices connected to user network may learn a recursive DNS server address with the mechanism described in [RFC3736].


The CPE may serve as a local DNS proxy server and include its address in the DNS server address list. This is easy to implement, because it is analogous to IPv4 SOHO router ( is a DNS proxy server and a default router in most sites).

CPEは、ローカルDNSプロキシサーバとして機能し、DNSサーバーのアドレスリスト内のアドレスを含んでいてもよいです。それは(は、DNSプロキシサーバとほとんどのサイトでデフォルトルータである)のIPv4 SOHOルータに類似しているので、これは、実装が容易です。

2.7. Miscellaneous Information
2.7. その他の情報

The PE may notify other IPv6-enabled server addresses, such as Network Time Protocol servers [RFC4075], SIP servers [RFC3319], etc., in an Advertise/Reply message on the prefix delegation message exchange, if those are available.


2.8. Connectivity Monitoring
2.8. 接続の監視

ICMPv6 Echo Request will be sent to the user network for connectivity monitoring in the service. The CPE must return a single IPv6 Echo Reply packet when it receives an ICMPv6 Echo Request packet. The health-check packets are addressed to a subnet-router anycast address for the delegated prefix.


The old document of APNIC IPv6 address assignment policy required that APNIC could ping the subnet anycast address to check address usage.


To achieve this requirement, for example, once the prefix 2001:db8:ffff::/48 is delegated, the CPE must reply to the ICMPv6 Echo Request destined for 2001:db8:ffff:: any time that IPV6CP and DHCPv6-PD are up for the upstream direction. Because some implementations couldn't reply when 2001:db8:ffff::/64 was assigned to its downstream physical interface and the interface was down, such an implementation should assign 2001:db8:ffff::/64 for the loopback interface, which is always up, and 2001:db8:ffff:1::/64, 2001:db8:ffff:2::/64, etc., to physical interfaces.

DB8::プレフィックス2001一度この要件を達成するために、例えば、DB8::FFFF :: / 48を委任され、CPEは、2001年に宛てICMPv6エコー要求に応答しなければならないFFFF :: IPV6CPとDHCPv6-PDであることをいつでも上流方向で最大。 DB8:いくつかの実装は、2001ときに応答できなかったためFFFF :: / 64をその下流物理インターフェースに割り当てられ、インターフェイスがダウンした、そのような実装2001を割り当てる必要があり:DB8:FFFF :: / 64をループバックインタフェースのためいます常にアップして、そして2001:DB8:FFFF:1 :: / 64、2001:DB8:FFFF:2 :: / 64等、物理インターフェイスに。

3. An Example of Connection Sequence
         CPE                      PE
          |                       |
          |----------PADI-------->| \
          |<---------PADO---------|  | PPPoE
          |----------PADR-------->|  | Discovery Stage
          |<---------PADS---------| /
          |                       |
          |---Configure-Request-->| \
          |<--Configure-Request---|  | PPP Link Establishment Phase
          |<----Configure-Ack-----|  | (LCP)
          |-----Configure-Ack---->| /
          |                       |
          |<------Challenge-------| \
          |-------Response------->|  | PPP Authentication Phase (CHAP)
          |<-------Success--------| /
          |                       |
          |---Configure-Request-->| \
          |<--Configure-Request---|  |
          |<----Configure-Nak-----|  | PPP Network Layer Protocol Phase
          |<----Configure-Ack-----|  | (IPCP)
          |---Configure-Request-->|  |
          |<----Configure-Ack-----| /
          |                       |
          |---Configure-Request-->| \
          |<--Configure-Request---|  | PPP Network Layer Protocol Phase
          |<----Configure-Ack-----|  | (IPV6CP)
          |-----Configure-Ack---->| /
          |                       |
          |--------Solicit------->| \
          |<------Advertise-------|  | DHCPv6
          |--------Request------->|  |
          |<--------Reply---------| /
          |                       |

Figure 2: Example of Connection Sequence


Figure 2 is an example of a normal link-up sequence, from start of PPPoE to start of IPv6/IPv4 communications. IPv4 communication becomes available after IPCP negotiation. IPv6 communication with link-local scope addresses becomes possible after IPV6CP negotiation. IPv6 communication with global-scope addresses becomes possible after prefix delegation and conventional IPv6 address configuration mechanism. IPCP is independent of IPV6CP and prefix delegation.

図2は、IPv6 / IPv4の通信を開始するためのPPPoEの開始から正常リンクアップシーケンスの一例です。 IPv4の通信は、IPCPネゴシエーション後に使用可能になります。リンクローカルスコープのアドレスを持つIPv6通信はIPV6CP交渉の後に可能となります。グローバルスコープアドレスを持つIPv6通信は、プレフィックス委任と従来のIPv6アドレス設定メカニズムの後に可能となります。 IPCPはIPV6CPとプレフィックス委任とは無関係です。

4. Security Considerations

In this architecture, the PE and CPE trust the point-to-point link between them; they trust that there is no man-in-the-middle and they trust PPPoE authentication. Because of this, DHCP authentication is not considered necessary and is not used.


The service provides an always-on global-scope prefix for users. Each device connected to user network has global-scope addresses. Without any packet filters, devices might be accessible from outside the user network in that case. The CPE and each device involved in the service should have functionality to protect against unauthorized accesses, such as a stateful inspection packet filter. The relationship between CPE and devices connected to the user network for this problem should be considered in the future.

サービスは、ユーザーのために常時オンのグローバル・スコープ接頭辞を提供します。ユーザネットワークに接続された各デバイスは、グローバルスコープのアドレスを有しています。任意のパケットフィルタがなければ、デバイスは、その場合のユーザのネットワークの外部からアクセス可能であるかもしれません。 CPEおよびサービスに関わる各デバイスは、ステートフルインスペクションパケットフィルタとして不正アクセスから保護する機能を持っている必要があります。この問題のCPEとユーザネットワークに接続されたデバイスとの間の関係は、将来的に考慮されるべきです。

5. Acknowledgements

Thanks are given for the input and review by Tatsuya Sato, Hideki Mouri, Koichiro Fujimoto, Hiroki Ishibashi, Ralph Droms, Ole Troan, Pekka Savola, and IPv6-ops-IAJapan members.


6. References
6.1. Normative References
6.1. 引用規格

[RFC3177] IAB and IESG, "IAB/IESG Recommendations on IPv6 Address Allocations to Sites", RFC 3177, September 2001.

[RFC3177] IABとIESG、RFC 3177、2001年9月 "サイトへのIPv6アドレスの割り当てにIAB / IESG勧告"。

[RFC1332] McGregor, G., "The PPP Internet Protocol Control Protocol (IPCP)", RFC 1332, May 1992.

[RFC1332]マクレガー、G.、 "PPPインターネットプロトコル制御プロトコル(IPCP)"、RFC 1332、1992年5月。

[RFC2472] Haskin, D. and E. Allen, "IP Version 6 over PPP", RFC 2472, December 1998.

[RFC2472] Haskin、D.およびE.アレン、 "PPPオーバーIPバージョン6"、RFC 2472、1998年12月。

[RFC2516] Mamakos, L., Lidl, K., Evarts, J., Carrel, D., Simone, D., and R. Wheeler, "A Method for Transmitting PPP Over Ethernet (PPPoE)", RFC 2516, February 1999.

[RFC2516] Mamakos、L.、Lidlの、K.、Evarts、J.、カレル、D.、シモン、D.、およびR.ウィーラー、 "PPPオーバーイーサネット(PPPoEを)送信するための方法"、RFC 2516年2月1999。

[RFC2462] Thomson, S. and T. Narten, "IPv6 Stateless Address Autoconfiguration", RFC 2462, December 1998.

[RFC2462]トムソン、S.とT. Narten氏、 "IPv6のステートレスアドレス自動設定"、RFC 2462、1998年12月。

[RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003.

[RFC3315] Droms、R.、バウンド、J.、フォルツ、B.、レモン、T.、パーキンス、C.、およびM.カーニー、 "IPv6のための動的ホスト構成プロトコル(DHCPv6)"、RFC 3315、2003年7月。

[RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic Host Configuration Protocol (DHCP) version 6", RFC 3633, December 2003. RFC 3633, December 2003.

[RFC3633] Troan、O.とR. Droms、RFC 3633、2003年12月RFC 3633、2003年12月 "動的ホスト構成プロトコル(DHCP)バージョン6のIPv6プレフィックスオプション"。

[RFC2461] Narten, T., Nordmark, E. and W. Simpson, "Neighbor Discovery for IP Version 6 (IPv6)", RFC 2461, December 1998.

[RFC2461] Narten氏、T.、Nordmarkと、E.およびW.シンプソン、 "IPバージョン6のための近隣探索(IPv6)の"、RFC 2461、1998年12月。

[RFC3646] Droms, R., "DNS Configuration options for Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3646, December 2003.

[RFC3646] Droms、R.、RFC 3646、2003年12月の "IPv6のための動的ホスト構成プロトコル(DHCPv6)のためのDNSの設定オプション"。

[RFC3736] Droms, R., "Stateless Dynamic Host Configuration Protocol (DHCP) Service for IPv6", RFC 3736, April 2004.

[RFC3736] Droms、R.、 "IPv6のステートレス動的ホスト構成プロトコル(DHCP)サービス"、RFC 3736、2004年4月。

[RFC4075] Kalusivalingam, V., "Simple Network Time Protocol (SNTP) Configuration Option for DHCPv6", RFC 4075, May 2005.

[RFC4075] Kalusivalingam、V.、 "DHCPv6の簡易ネットワークタイムプロトコル(SNTP)設定オプション"、RFC 4075、2005年5月。

[RFC3319] Schulzrinne, H. and B. Volz, "Dynamic Host Configuration Protocol (DHCPv6) Options for Session Initiation Protocol (SIP) Servers", RFC 3319, July 2003.

[RFC3319] Schulzrinneと、H.、およびB.フォルツ、RFC 3319、2003年7月 "セッション開始プロトコル(SIP)サーバーの動的ホスト構成プロトコル(DHCPv6)オプション"。

6.2. Informative References
6.2. 参考文献

[RFC3769] Miyakawa, S. and R. Droms, "Requirements for IPv6 Prefix Delegation", RFC 3769, June 2004.

[RFC3769]宮川、S.とR. Droms、 "IPv6のプレフィックス委任のための要件"、RFC 3769、2004年6月。

Authors' Addresses


Yasuhiro Shirasaki NTT Communications Corporation Tokyo Opera City Tower 21F 3-20-2 Nishi-Shinjuku, Shinjuku-ku Tokyo 163-1421, Japan

やすひろ しらさき んっt こっむにかちおんs こrぽらちおん ときょ おぺら しty とうぇr 21F 3ー20ー2 にしーしんじゅく、 しんじゅくーく ときょ 163ー1421、 じゃぱん



Shin Miyakawa, Ph. D NTT Communications Corporation Tokyo Opera City Tower 21F 3-20-2 Nishi-Shinjuku, Shinjuku-ku Tokyo 163-1421, Japan

しん みやかわ、 Ph。 D んっt こっむにかちおんs こrぽらちおん ときょ おぺら しty とうぇr 21F 3ー20ー2 にしーしんじゅく、 しんじゅくーく ときょ 163ー1421、 じゃぱん



Toshiyuki Yamasaki NTT Communications Corporation 1-1-6 Uchisaiwaicho, Chiyoda-ku Tokyo 100-8019, Japan

としゆき やまさき んっt こっむにかちおんs こrぽらちおん 1ー1ー6 うちさいわいちょ、 ちよだーく ときょ 100ー8019、 じゃぱん



Ayako Takenouchi NTT Cyber Solutions Laboratories, NTT Corporation 3-9-11 Midori-Cho, Musashino-Shi Tokyo 180-8585, Japan

あやこ たけのうち んっt Cyべr そぅちおんs ぁぼらとりえs、 んっt こrぽらちおん 3ー9ー11 みどりーちょ、 むさしのーし ときょ 180ー8585、 じゃぱん



Full Copyright Statement


Copyright (C) The Internet Society (2005).


This document is subject to the rights, licenses and restrictions contained in BCP 78 and at, and except as set forth therein, the authors retain all their rights.

この文書では、BCP 78に及びに含まれる権利と許可と制限の適用を受けており、その中の記載を除いて、作者は彼らのすべての権利を保有します。


この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示または、(もしあれば)後援ISに設けられています。黙示、情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されません。

Intellectual Property


The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.

IETFは、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 RFC文書の権利に関する手続きの情報は、BCP 78およびBCP 79に記載されています。

Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at


The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at

IETFは、その注意にこの標準を実装するために必要とされる技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 ietf-ipr@ietf.orgのIETFに情報を記述してください。



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

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