[要約] RFC 4241は、IPv6/IPv4デュアルスタックインターネットアクセスサービスのモデルを提案している。このRFCの目的は、IPv6とIPv4の両方をサポートするネットワークアクセスサービスの設計と展開を支援することである。
Network Working Group Y. Shirasaki
Request for Comments: 4241 S. Miyakawa
Category: Informational T. Yamasaki
NTT Communications
A. Takenouchi
NTT
December 2005
A Model of IPv6/IPv4 Dual Stack Internet Access Service
IPv6/IPv4デュアルスタックインターネットアクセスサービスのモデル
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).
Copyright（c）The Internet Society（2005）。
IESG Note
IESGノート
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は、インターネット標準のレベルの候補者ではありません。IETFは、あらゆる目的のためにこのRFCのフィットネスに関する知識を放棄し、公開する決定はIETFワークとの競合に関するIESGレビューとは別にIETFレビューに基づいていないことに注意してください。RFCエディターは、その裁量でこのドキュメントを公開することを選択しました。詳細については、RFC 3932を参照してください。
Abstract
概要
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.
このメモは、NTT通信のデュアルスタックADSLアクセスサービスのユーザーネットワークインターフェイス仕様のダイジェストであり、ホームユーザーにIPv6/IPv4デュアルスタックサービスを提供します。ユーザーのセットアップを簡素化するために、これらのサービスには、IPv6固有のパラメーターを自動的に構成するメカニズムがあります。メモは、ユーザーに割り当てられたプレフィックスとIPv6 DNSサーバーのアドレスの2つの基本パラメーターに焦点を当てており、これらのパラメーターを顧客施設機器（CPE）に自動的に配信する方法を指定します。
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.
このメモは、NTT通信のデュアルスタックADSLアクセスサービスのユーザーネットワークインターフェイス仕様のダイジェストであり、IPv6/IPv4デュアルスタックサービスをホームユーザーに提供します。ユーザーのセットアップを簡素化するために、これらのサービスには、IPv6固有のパラメーターを自動的に構成するメカニズムがあります。メモは、ユーザーに割り当てられたプレフィックスとIPv6 DNSサーバーのアドレスの2つの基本パラメーターに焦点を当てており、これらのパラメーターを顧客施設機器（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固有のパラメーターの自動構成関数の2つのトピックについて説明します。
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サービスを対象としています。顧客施設機器（CPE）とプロバイダーエッジ（PE）機器の間にポイントツーポイントプロトコル（PPP）の論理リンクがあると想定しています。アクセスラインに固有の要因を除外するために、このアーキテクチャは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 Communicationsは、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:
自動構成関数は、ユーザーのセットアップの簡素化を目的としています。通常、ユーザーは、少なくとも2つのIPv6固有のパラメーターを構成する必要があります。[RFC3769]とIPv6 DNSサーバーのアドレスを割り当てたプレフィックス（ES）。この関数は、2つのサブ機能で構成されています。
o Delegation of prefix(es) to be used in the user site.
o ユーザーサイトで使用されるプレフィックス（es）の委任。
o Notification of IPv6 DNS server addresses and/or other server addresses.
o IPv6 DNSサーバーアドレスおよび/またはその他のサーバーアドレスの通知。
Section 2 of this memo details the user/network interface. Section 3 describes an example connection sequence.
このメモのセクション2では、ユーザー/ネットワークインターフェイスを詳しく説明しています。セクション3では、接続シーケンスのサンプルについて説明します。
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関連のパラメーター構成も範囲外です。
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].
このサービスは、PPP接続とチャレンジハンドシェイク認証プロトコル（Chap）認証を使用して、各CPEを識別します。CPEとPEは、PPPインターネットプロトコルコントロールプロトコル（IPCP）[RFC1332]とインターネットプロトコルV6コントロールプロトコル（IPv6CP）[RFC2472]の両方を単一のPPP接続で同時に処理します。これは、CPEまたはPEが、他の副作用なしにいつでもネットワーク制御プロトコル（NCP）セッションを開設/閉じることができることを意味します。ユーザーは、IPv4のみ、IPv6のみ、IPv4/IPv6デュアルスタックの3つのサービスの中から選択できることを意図しています。ADSLラインに接続されたCPEは、PPPOEメカニズムを使用したPEを発見します[RFC2516]。
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.
CPEとPEはIPv6CPとインターフェイス識別子のみをネゴシエートできるため、PEとCPEは以下に説明するプレフィックス委任メカニズムが実行される前に、Link-Local-Scopeアドレスのみを使用できます。
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は、認証、承認、会計（AAA）サーバーまたはローカルプレフィックスプールからの情報を使用して、CPEのグローバルスコーププレフィックスを選択し、プレフィックスをCPEに委任します。接頭辞が委任されると、プレフィックスはサブネット化され、CPEのローカルインターフェイスに割り当てられます。CPEは、各リンクのプレフィックスのルーター広告の送信を開始します。最終的に、ホストは、従来のIPv6ステートレス[RFC2462]またはステートフルな自動構成メカニズム（[RFC3315]など）を介してグローバルスコーププレフィックスを取得し、グローバルスコープアドレスを使用して通信し始めます。
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は、プレフィックス委任オプション[RFC3633]を使用して、IPv6（DHCPV6）[RFC3315]の動的ホスト構成プロトコルを使用して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は、前のセクションで説明され、IA_PDオプションを含むIPv6CPによってネゴシエートされたリンクローカルソースアドレスを持つDHCPV6 SOLICTメッセージを送信することにより、PEからプレフィックス（ES）を要求します。
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サーバーは、PEまたはPEがローカルプールからプレフィックスを選択するプレフィックス（ES）を提供し、PEはIA_PDオプションとIA_PDプレフィックスオプションを含む広告メッセージを返します。IA_PDプレフィックスオプションのプレフィックス長は48です。
IA_PD option and IA_PD Prefix options for the chosen prefix(es) back to the PE.
選択したプレフィックス（es）のIA_PDオプションとIA_PDプレフィックスオプション。
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].
[RFC3633]に記載されているように、CPEは何らかの理由で終了または再起動した場合、CPEは再生/返信メッセージ交換を開始する必要があります。
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のプレフィックスを割り当てます。委任されたプレフィックスに無限の寿命がある場合、[RFC2461]の割り当てられた /64プレフィックスの優先寿命と有効な寿命がデフォルト値である必要があります。
Because a link-local address is already assigned to the CPE's upstream interface, global-scope address assignment for that interface is optional.
Link-LocalアドレスはすでにCPEのアップストリームインターフェイスに割り当てられているため、そのインターフェイスのグローバルスコープアドレスの割り当てはオプションです。
The CPE and PE use static routing between them, and no routing protocol traffic is necessary.
CPEとPEはそれらの間に静的ルーティングを使用し、ルーティングプロトコルトラフィックは必要ありません。
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.
CPEは、プレフィックス委任交換後に自動的に、PPPOE論理インターフェイスまたはPEのLink-LocalアドレスをIPv6デフォルトゲートウェイとして構成します。
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は、委任されたプレフィックスの次のホップとして拒否ルートまたはnullインターフェイスをインストールする必要があります。）
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].
ユーザーネットワークに接続されたデバイスは、[RFC3736]で説明されているメカニズムを使用して、再帰的なDNSサーバーアドレスを学習する場合があります。
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 (192.168.0.1 is a DNS proxy server and a default router in most sites).
CPEは、ローカルDNSプロキシサーバーとして機能し、DNSサーバーアドレスリストにそのアドレスを含めることができます。これは、IPv4 Sohoルーターに類似しているため、簡単に実装できます（192.168.0.1は、ほとんどのサイトでDNSプロキシサーバーとデフォルトのルーターです）。
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.
PEは、ネットワークタイムプロトコルサーバー[RFC4075]、SIPサーバー[RFC3319]など、他のIPv6対応サーバーアドレスに通知する場合があります。
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.
ICMPV6エコーリクエストは、サービス内の接続監視のためにユーザーネットワークに送信されます。CPEは、ICMPV6エコーリクエストパケットを受信したときに、単一のIPv6エコー応答パケットを返す必要があります。ヘルスチェックパケットは、委任されたプレフィックスのサブネットルーターAnyCastアドレスにアドレス指定されます。
The old document of APNIC IPv6 address assignment policy required that APNIC could ping the subnet anycast address to check address usage.
APNIC IPv6アドレスの割り当てポリシーの古いドキュメントでは、APNICがアドレスの使用状況を確認するためにサブネットのAnycastアドレスをpingすることを要求しました。
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.
たとえば、この要件を達成するために、プレフィックス2001：db8：ffff ::/48が委任されると、CPEは2001年に宛てられたICMPv6エコーリクエストに返信する必要があります：db8：ffff :: IPv6CPおよびDHCPV6-PDがアップストリーム方向に登場します。いくつかの実装は2001年：DB8：FFFF ::/64が下流の物理インターフェイスに割り当てられ、インターフェイスがダウンしたときに返信できなかったため、このような実装は2001：db8：ffff ::/64を割り当てる必要があります。
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
図2：接続シーケンスの例
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は、PPPOEの開始からIPv6/IPv4通信の開始まで、通常のリンクアップシーケンスの例です。IPV4通信は、IPCP交渉後に利用可能になります。Link-Local Scopeアドレスを使用したIPv6通信は、IPv6CPの交渉後に可能になります。グローバルスコープアドレスとのIPv6通信は、プレフィックス委任および従来のIPv6アドレス構成メカニズムの後に可能になります。IPCPは、IPv6CPおよびプレフィックス委任に依存しません。
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.
このアーキテクチャでは、PEとCPEはそれらの間のポイントツーポイントリンクを信頼しています。彼らは、中間者がいないと信じており、PPPOE認証を信頼しています。このため、DHCP認証は必要とされておらず、使用されていません。
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とデバイスの関係は、将来考慮されるべきです。
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.
Tatsuya Sato、Hideki Mouri、Koichiro Fujimoto、Hiroki Ishibashi、Ralph Droms、Ole Troan、Pekka Savola、およびIPv6-Ops-Iajapanメンバーによる入力とレビューに感謝します。
[RFC3177] IAB and IESG, "IAB/IESG Recommendations on IPv6 Address Allocations to Sites", RFC 3177, September 2001.
[RFC3177] IABおよびIESG、「IPv6に関するIAB/IESGの推奨事項は、サイトへの割り当てアドレス」、RFC 3177、2001年9月。
[RFC1332] McGregor, G., "The PPP Internet Protocol Control Protocol (IPCP)", RFC 1332, May 1992.
[RFC1332] McGregor、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. Allen、「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.、Carrel、D.、Simone、D。、およびR. Wheeler、「PPPをイーサネット上に送信する方法」、RFC 2516、1999年2月。
[RFC2462] Thomson, S. and T. Narten, "IPv6 Stateless Address Autoconfiguration", RFC 2462, December 1998.
[RFC2462] Thomson、S。およびT. Narten、「IPv6 Stateless Address Autoconfiguration」、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.、Bound、J.、Volz、B.、Lemon、T.、Perkins、C。、およびM. Carney、「IPv6の動的ホスト構成プロトコル」、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、「動的ホスト構成プロトコル（DHCP）バージョン6のIPv6プレフィックスオプション」、RFC 3633、2003年12月、RFC 3633、2003年12月。
[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. Simpson、「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。、「IPv6（DHCPV6）の動的ホスト構成プロトコルのDNS構成オプション」、RFC 3646、2003年12月。
[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のSimple Network Time Protocol（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. Volz、「セッション開始プロトコル（SIP）サーバーの動的ホスト構成プロトコル（DHCPV6）オプション」、RFC 3319、2003年7月。
[RFC3769] Miyakawa, S. and R. Droms, "Requirements for IPv6 Prefix Delegation", RFC 3769, June 2004.
[RFC3769] Miyakawa、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
Yasuhiro shirasaki ntt Communications Corporation Tokyo Opera City Tower 21f 3-20-2西shinjuku、Shinjuku-ku Tokyo 163-1421、日本
EMail: yasuhiro@nttv6.jp
Shin Miyakawa, Ph. D NTT Communications Corporation Tokyo Opera City Tower 21F 3-20-2 Nishi-Shinjuku, Shinjuku-ku Tokyo 163-1421, Japan
Shin Miyakawa、Ph。DNTT Communications Corporation Tokyo Opera City Tower 21f 3-20-2西shinjuku、Shinjuku-ku Tokyo 163-1421、日本
EMail: miyakawa@nttv6.jp
Toshiyuki Yamasaki NTT Communications Corporation 1-1-6 Uchisaiwaicho, Chiyoda-ku Tokyo 100-8019, Japan
ヤマサキntt通信会社1-1-6 uchisaiwaicho、chiyoda-ku tokyo 100-8019、日本
EMail: t.yamasaki@ntt.com
Ayako Takenouchi NTT Cyber Solutions Laboratories, NTT Corporation 3-9-11 Midori-Cho, Musashino-Shi Tokyo 180-8585, Japan
ayako doceouchi ntt cyber Solutions Laboratories、NTT Corporation 3-9-11 Midori-Cho、Musashino-Shi Tokyo 180-8585、日本
EMail: takenouchi.ayako@lab.ntt.co.jp
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2005).
Copyright（c）The Internet Society（2005）。
This document is subject to the rights, licenses and restrictions contained in BCP 78 and at www.rfc-editor.org/copyright.html, and except as set forth therein, the authors retain all their rights.
この文書は、BCP 78およびwww.rfc-editor.org/copyright.htmlに含まれる権利、ライセンス、および制限の対象となり、そこに記載されている場合を除き、著者はすべての権利を保持します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書と本書に含まれる情報は、「現状」に基づいて提供され、貢献者、インターネット社会とインターネットエンジニアリングタスクフォースが代表する、または後援する組織、またはインターネットエンジニアリングタスクフォースは、すべての保証を否認します。
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 http://www.ietf.org/ipr.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得しようとする試みの結果、http://ww.ietf.org/IPRでIETFオンラインIPRリポジトリから取得できます。
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-ipr@ietf.org.
IETFは、関心のある当事者に、著作権、特許、または特許出願、またはこの基準を実装するために必要なテクノロジーをカバーする可能性のあるその他の独自の権利を注意深く招待します。ietf-ipr@ietf.orgのIETFへの情報をお問い合わせください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFCエディター機能の資金は現在、インターネット協会によって提供されています。