RFC4241 日本語訳
4241 A Model of IPv6/IPv4 Dual Stack Internet Access Service. Y.Shirasaki, S. Miyakawa, T. Yamasaki, A. Takenouchi. December 2005. (Format: TXT=20580 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group Y. Shirasaki
Request for Comments: 4241 S. Miyakawa
Category: Informational T. Yamasaki
NTT Communications
A. Takenouchi
NTT
December 2005
Shirasakiがコメントのために要求するワーキンググループY.をネットワークでつないでください: 4241秒間Miyakawaカテゴリ: 情報のT.の山崎NTTコミュニケーションA.Takenouchi NTT2005年12月
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)インターネット協会(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はインターネットStandardのどんなレベルの候補ではありません。 IETFはどんな目的と発行するという決定がIETF仕事との闘争のためのIESGレビューは別としてIETFレビューに基づいていないというメモのためにもこのRFCのフィットネスに関するどんな知識も放棄します。 RFC Editorは、自己判断でこのドキュメントを発表するのを選びました。 詳しい情報に関してRFC3932を見てください。
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 CommunicationsのデュアルスタックADSLアクセス・サービスに関するユーザネットワークインターフェース仕様のダイジェストである、どれがIPv6/IPv4デュアルスタックを提供するかがユーザにホームにサービスを提供します。 ユーザセットアップを簡素化するために、これらのサービスには自動的にIPv6の特定のパラメタを構成するメカニズムがあります。 メモは2つの基本のパラメタに焦点を合わせます: 接頭語はユーザとIPv6 DNSのアドレスにサーバを割り当てました、そして、それは自動的にCustomer Premises Equipment(CPE)にこれらのパラメタを提供する方法を指定します。
Shirasaki, et al. Informational [Page 1] RFC 4241 Dual Stack Access Service December 2005
Shirasaki、他 [1ページ]情報のRFC4241デュアルスタックアクセス・サービス2005年12月
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.
このメモがNTT CommunicationsのデュアルスタックADSLアクセス・サービスに関するユーザネットワークインターフェース仕様のダイジェストである、どれがIPv6/IPv4デュアルスタックを提供するかがユーザにホームにサービスを提供します。 ユーザセットアップを簡素化するために、これらのサービスには自動的にIPv6の特定のパラメタを構成するメカニズムがあります。 メモは2つの基本のパラメタに焦点を合わせます: 接頭語はユーザとIPv6 DNSのアドレスにサーバを割り当てました、そして、それは自動的にCustomer Premises Equipment(CPE)にこれらのパラメタを提供する方法を指定します。
This memo covers two topics: an architecture for IPv6/IPv4 dual stack access service and an automatic configuration function for IPv6- specific parameters.
このメモは2つの話題をカバーしています: 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サービスのときに家庭でのユーザのために主に狙います。 それは、Customer Premises Equipment(CPE)とProvider Edge(PE)設備とのPointからポイントへのプロトコル(PPP)の論理的なリンクがあると仮定します。 系列にアクセスするために特定の要素を除くために、このアーキテクチャはPPPとその上側の層を指定するだけです。 CPEへ代表として派遣される接頭語の長さは[RFC3177]を満たすためには、/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 単一のPPP論理的なリンクの上にIPv6とIPv4の接続性を提供します。
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はSummer2002以来このアーキテクチャに基づく商業サービスを提供しています。
| _____________
[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 +----------------+
| _____________ [ホスト]-++-----------+ +----------+ / \ | | 顧客| ADSL系列| プロバイダー| | そしてISPコア。| ++構内+---------------+ 縁|--| インターネット| | | 設備| 加入者+に-----+----+ \_____________/[ホスト]-++-----------+ | | | | +-----+------+ | +-+----------+ | AAAサーバ| | | DNSサーバ| +------------+ | +------------+ +-+--------------+ | NTP、サーバなど| 図1: デュアルスタックアクセス・サービスアーキテクチャ+----------------+
Shirasaki, et al. Informational [Page 2] RFC 4241 Dual Stack Access Service December 2005
Shirasaki、他 [2ページ]情報のRFC4241デュアルスタックアクセス・サービス2005年12月
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特有のパラメタを構成しなければなりません: 接頭語(es)はそれら[RFC3769]とIPv6 DNSにサーバのアドレスを割り当てました。 機能は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は例の接続系列について説明します。
2. User/Network Interface
2. ユーザ/ネットワーク・インターフェース
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.
このセクションはユーザ/ネットワークインターフェース仕様の細目について説明します。 イーサネット(PPPoE)とその上側の層の上のPPPだけが言及されます。 範囲の外にイーサネットや下層などの他の層があります。 範囲のも外に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インターネットプロトコルControlプロトコル(IPCP)[RFC1332]とインターネットプロトコルV6 Controlプロトコル(IPV6CP)[RFC2472]の両方を扱います。 これは、CPEかPEのどちらかがいつでもどんなNetwork Controlプロトコル(NCP)セッションのときにももう片方のために少しもサイド効果なしで開くか、または閉じることができることを意味します。 ユーザが3つのサービスの中で選ぶことができることを意図します: IPv4だけ、IPv6だけ、およびIPv4/IPv6デュアルスタック。 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.
CPEとPEがそれらのインタフェース識別子しかIPV6CPと交渉できないので、以下で説明された接頭語委譲メカニズムが動かされる前に、PEとCPEが地方の範囲をリンクしているアドレスしか使用できないことに注意してください。
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
IPV6CP交渉の後に、CPEは接頭語委譲要求を開始します。 PEはAuthentication、Authorization、およびAccounting(AAA)サーバか地方の接頭語プールからの情報でCPEのためのグローバルな範囲接頭語を選びます、そして、それは接頭語をCPEへ代表として派遣します。 いったん接頭語を代表として派遣すると、CPEの局所界面に接頭語を「副-網で覆」って、割り当てます。 CPEは発信し始めます。
Shirasaki, et al. Informational [Page 3] RFC 4241 Dual Stack Access Service December 2005
Shirasaki、他 [3ページ]情報のRFC4241デュアルスタックアクセス・サービス2005年12月
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.
それぞれの接頭語のためのルータ通知はリンクされます。 結局、ホストは、従来のIPv6状態がない[RFC2462]を通してグローバルな範囲接頭語を習得し始めるか、自動構成メカニズム([RFC3315]など)をstatefulして、またはグローバルな範囲アドレスを使用することで交信し始めることができます。
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:
IPv6(DHCPv6)[RFC3315]に接頭語委譲オプション[RFC3633]でDynamic Host Configuration Protocolを使用するCPEへのPE代表接頭語。 接頭語委譲のための系列は以下の通りです:
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 DHCPv6 Solicitメッセージにそれを送るのによるPEからのCPE要求接頭語(es)は、前項で言及されたIPV6CPにリンク地元筋アドレスを交渉させて、アイオワ_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に供給するか、PEが地方のプールから接頭語(es)を選んで、PEはアイオワ_PDオプションを含むメッセージを広告に返して、アイオワ_PD Prefixにオプションを返します。 アイオワ_PD Prefixオプションにおける接頭語長さは48です。
IA_PD option and IA_PD Prefix options for the chosen prefix(es)
back to the PE.
選ぶアイオワの_PDオプションとアイオワの_PD Prefixオプションは(es)をPEへ前に置いて戻します。
o The PE confirms the prefix(es) in the Request message in a Reply
message.
o PEはReplyメッセージのRequestメッセージの接頭語(es)を確認します。
If IPV6CP is terminated or restarted by any reason, CPE must initiate a Rebind/Reply message exchange as described in [RFC3633].
IPV6CPがどんな理由によっても終えられるか、または再開されるなら、CPEは[RFC3633]で説明されるようにRebind/回答交換処理に着手しなければなりません。
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.
リンクローカルアドレスが既にCPEの上流のインタフェースに割り当てられるので、そのインタフェースのためのグローバルな範囲アドレス課題は任意です。
2.5. Routing
2.5. ルート設定
The CPE and PE use static routing between them, and no routing protocol traffic is necessary.
CPEとPEはそれらの間のスタティックルーティングを使用します、そして、どんなルーティング・プロトコルトラフィックも必要ではありません。
Shirasaki, et al. Informational [Page 4] RFC 4241 Dual Stack Access Service December 2005
Shirasaki、他 [4ページ]情報のRFC4241デュアルスタックアクセス・サービス2005年12月
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は接頭語委譲交換の後にIPv6デフォルトゲートウェイとして自動的にPPPoEの論理的なインタフェースかPEのリンクローカルアドレスを構成します。
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 Destination Unreachableメッセージをソースアドレスに返すはずであるか、または静かにパケットを捨てるはずです、オリジナルのパケットが代表として派遣された接頭語の割り当てられなかった接頭語のために運命づけられているとき。 (例えば、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サイトの再帰的なDNSサーバをIPv6に供給します。 PEが中の[RFC3646]で説明されるDomain Name Serverオプションでこれらのサーバのグローバルなユニキャストアドレスに通知する、広告、/回答は接頭語委譲交換処理で通信します。
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ソーホールータに類似しているので(192.168、.0、.1がDNSプロキシサーバとほとんどのサイトのデフォルトルータである、)
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.
それらが利用可能であるなら、Network Timeプロトコルサーバ[RFC4075]などのような広告のSIPサーバ[RFC3319]などに接頭語委譲交換処理に関する/応答メッセージを扱いますPEが、他のIPv6によって可能にされたサーバに通知するかもしれない。
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.
サービスにおける接続性モニターのためにユーザネットワークにICMPv6 Echo Requestを送るでしょう。 ICMPv6 Echo Requestパケットを受けるとき、CPEは単一のIPv6 Echo Replyパケットを返さなければなりません。 検診パケットは代表として派遣された接頭語のためのサブネットルータ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アドレスを確認できるのを必要としました。
Shirasaki, et al. Informational [Page 5] RFC 4241 Dual Stack Access Service December 2005
Shirasaki、他 [5ページ]情報のRFC4241デュアルスタックアクセス・サービス2005年12月
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を達成するためには以下のこと、:CPEは、/48が代表として派遣されると2001:db8:ffffのために運命づけられたICMPv6 Echo Requestに返答しなければなりません:、: 上流の方向において、何時でもそのIPV6CPとDHCPv6-PDは上がっています。 2001:db8:ffffであるときに、いくつかの実装が返答できなかったので以下のこと、:/64は川下の物理インターフェースに割り当てられました、そして、インタフェースが下がっていた、そのような実装は2001:db8:ffffを割り当てるべきです:、:いつも上がっているループバックインタフェースと2001:db8:ffff: 1のための/64:、:/64、2001: db8:ffff:2:、:物理インターフェースへの/64など。
3. An Example of Connection Sequence
3. 接続系列に関する例
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---------| /
| |
CPE PE| | |----------PADI-------->| \ | <、-、-、-、-、-、-、-、--PADO---------| | PPPoE|----------PADR-------->|、| 発見ステージ| <、-、-、-、-、-、-、-、--パッド---------| / | | |---要求を構成します-->| \ | <--要求を構成します。---| | pppリンク確立段階| <、-、-、--Ackを構成します。-----| | (LCP) |-----Ackを構成します。---->| / | | | <、-、-、-、-、--挑戦-------| \ |-------応答------->|、| ppp認証フェーズ(やつ)| <、-、-、-、-、-、--成功--------| / | | |---要求を構成します-->| \ | <--要求を構成します。---| | | <、-、-、--Nakを構成します。-----| | pppネットワーク層プロトコルフェーズ| <、-、-、--Ackを構成します。-----| | (IPCP) |---要求を構成します-->|、| | <、-、-、--Ackを構成します。-----| / | | |---要求を構成します-->| \ | <--要求を構成します。---| | pppネットワーク層プロトコルフェーズ| <、-、-、--Ackを構成します。-----| | (IPV6CP) |-----Ackを構成します。---->| / | | |--------請求してください。------->| \ | <、-、-、-、-、--広告-------| | DHCPv6|--------要求------->|、| | <、-、-、-、-、-、-、--返信---------| / | |
Figure 2: Example of Connection Sequence
図2: 接続系列に関する例
Shirasaki, et al. Informational [Page 6] RFC 4241 Dual Stack Access Service December 2005
Shirasaki、他 [6ページ]情報のRFC4241デュアルスタックアクセス・サービス2005年12月
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交渉の後に利用可能になります。 リンクローカルの範囲アドレスとのIPv6コミュニケーションはIPV6CP交渉の後に可能になります。 接頭語委譲と従来のIPv6が構成メカニズムを扱った後にグローバルな範囲アドレスとのIPv6コミュニケーションは可能になります。 IPCPはIPV6CPと接頭語委譲から独立しています。
4. Security Considerations
4. セキュリティ問題
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とデバイスとの関係は将来、考えられるべきです。
5. Acknowledgements
5. 承認
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佐藤による入力とレビューのために感謝を与えます、Hideki Mouri、Koichiro藤本、石橋博樹、ラルフDroms、Ole Troan、ペッカSavola、およびIPv6オプアートIAJapanメンバー。
6. References
6. 参照
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、「サイトへのIPv6アドレス配分のIAB/IESG推薦」、RFC3177、2001年9月。
[RFC1332] McGregor, G., "The PPP Internet Protocol Control Protocol
(IPCP)", RFC 1332, May 1992.
[RFC1332]マクレガー(G.、「pppインターネットプロトコル制御プロトコル(IPCP)」RFC1332)は1992がそうするかもしれません。
[RFC2472] Haskin, D. and E. Allen, "IP Version 6 over PPP", RFC 2472,
December 1998.
[RFC2472] ハスキンとD.とE.アレン、「pppの上のIPバージョン6」、RFC2472、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.、エバーツ、J.、個人閲覧室、D.、シモン、D.、およびR.ウィーラー、「イーサネットの上にpppを伝えるためのメソッド(PPPoE)」、RFC2516(1999年2月)。
Shirasaki, et al. Informational [Page 7] RFC 4241 Dual Stack Access Service December 2005
Shirasaki、他 [7ページ]情報のRFC4241デュアルスタックアクセス・サービス2005年12月
[RFC2462] Thomson, S. and T. Narten, "IPv6 Stateless Address
Autoconfiguration", RFC 2462, December 1998.
[RFC2462] トムソンとS.とT.Narten、「IPv6の状態がないアドレス自動構成」、RFC2462、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.、レモン、パーキンス、C.とM.カーニー、「IPv6(DHCPv6)のためのダイナミックなホスト構成プロトコル」RFC3315、T.、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、「Dynamic Host Configuration Protocol(DHCP)バージョン6インチIPv6 Prefix Options、RFC3633、2003年12月。」 2003年12月のRFC3633。
[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)のための隣人発見」、RFC2461、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)のためのDynamic Host Configuration ProtocolのためのDNS Configurationオプション」、RFC3646、2003年12月。
[RFC3736] Droms, R., "Stateless Dynamic Host Configuration Protocol
(DHCP) Service for IPv6", RFC 3736, April 2004.
[RFC3736] Droms、R.「(DHCP)がIPv6"、RFC3736年のために修理する状態がないダイナミックなホスト構成プロトコル、2004年4月」。
[RFC4075] Kalusivalingam, V., "Simple Network Time Protocol (SNTP)
Configuration Option for DHCPv6", RFC 4075, May 2005.
[RFC4075] Kalusivalingam、V.、「DHCPv6"、RFC4075、2005年5月のための簡単なネットワーク時間プロトコル(SNTP)設定オプション。」
[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.フォルツ、「セッション開始のためのDynamic Host Configuration Protocol(DHCPv6)オプションは(一口)サーバについて議定書の中で述べます」、RFC3319、2003年7月。
6.2. Informative References
6.2. 有益な参照
[RFC3769] Miyakawa, S. and R. Droms, "Requirements for IPv6 Prefix
Delegation", RFC 3769, June 2004.
[RFC3769] MiyakawaとS.とR.Droms、「IPv6接頭語委譲のための要件」、RFC3769、2004年6月。
Shirasaki, et al. Informational [Page 8] RFC 4241 Dual Stack Access Service December 2005
Shirasaki、他 [8ページ]情報のRFC4241デュアルスタックアクセス・サービス2005年12月
Authors' Addresses
作者のアドレス
Yasuhiro Shirasaki NTT Communications Corporation Tokyo Opera City Tower 21F 3-20-2 Nishi-Shinjuku, Shinjuku-ku Tokyo 163-1421, Japan
塔の21F3-20-2西新宿、Yasuhiro Shirasaki NTTコミュニケーションズ株式会社オペラ市の新宿区東京日本東京163-1421
EMail: yasuhiro@nttv6.jp
メール: 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
西新宿、塔の21Ph向こうずねのMiyakawa、D NTTコミュニケーションズ株式会社東京Opera市のF3-20-2東京新宿区163-1421(日本)
EMail: miyakawa@nttv6.jp
メール: miyakawa@nttv6.jp
Toshiyuki Yamasaki NTT Communications Corporation 1-1-6 Uchisaiwaicho, Chiyoda-ku Tokyo 100-8019, Japan
敏幸山崎NTTコミュニケーションズ株式会社1-1-6内幸町、東京千代田区100-8019(日本)
EMail: t.yamasaki@ntt.com
メール: t.yamasaki@ntt.com
Ayako Takenouchi NTT Cyber Solutions Laboratories, NTT Corporation 3-9-11 Midori-Cho, Musashino-Shi Tokyo 180-8585, Japan
綾子Takenouchi NTTサイバーソリューション研究所、3 9-11テロのNTT社の美土里町、東京180-8585、武蔵野市日本
EMail: takenouchi.ayako@lab.ntt.co.jp
メール: takenouchi.ayako@lab.ntt.co.jp
Shirasaki, et al. Informational [Page 9] RFC 4241 Dual Stack Access Service December 2005
Shirasaki、他 [9ページ]情報のRFC4241デュアルスタックアクセス・サービス2005年12月
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2005).
Copyright(C)インターネット協会(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.
このドキュメントはBCP78と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.
このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
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はどんなIntellectual Property Rightsの正当性か範囲、実装に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するどんな独立している取り組みも作りました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
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.
IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
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 Editor機能のための基金は現在、インターネット協会によって提供されます。
Shirasaki, et al. Informational [Page 10]
Shirasaki、他 情報[10ページ]
一覧
スポンサーリンク
