RFC3582 日本語訳

Network Working Group                                           J. Abley
Request for Comments: 3582                                           ISC
Category: Informational                                         B. Black
                                                         Layer8 Networks
                                                                 V. Gill
                                                         AOL Time Warner
                                                             August 2003

Ableyがコメントのために要求するワーキンググループJ.をネットワークでつないでください: 3582年のISCカテゴリ: 情報のB.黒いLayer8はタイム・ワーナー2003年8月にV.エラAOLをネットワークでつなぎます。

             Goals for IPv6 Site-Multihoming Architectures

IPv6サイトマルチホーミングアーキテクチャの目標

Status of this Memo

この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 (2003).  All Rights Reserved.

Copyright(C)インターネット協会(2003)。 All rights reserved。

Abstract

要約

   This document outlines a set of goals for proposed new IPv6 site-
   multihoming architectures.  It is recognised that this set of goals
   is ambitious and that some goals may conflict with others.  The
   solution or solutions adopted may only be able to satisfy some of the
   goals presented here.

このドキュメントは提案された新しいIPv6サイトマルチホーミングアーキテクチャのための1セットの目標について概説します。 このセットの目標が野心満々であり、いくつかの目標が他のものと衝突するかもしれないと認められます。 採用されたソリューションかソリューションがここに提示された目標のいくつかを満たすことができるだけであるかもしれません。

1.  Introduction

1. 序論

   Site-multihoming, i.e., connecting to more than one IP service
   provider, is an essential component of service for many sites which
   are part of the Internet.

すなわち、サイトマルチホーミング、1つ以上のIPサービスプロバイダーとの接続はインターネットの一部である多くのサイトのためのサービスの必須成分です。

   Current IPv4 site-multihoming practices have been added on to the
   CIDR architecture [1], which assumes that routing table entries can
   be aggregated based upon a hierarchy of customers and service
   providers.

現在のIPv4サイトマルチホーミング習慣をCIDRアーキテクチャ[1]に追加してあります。(それは、顧客とサービスプロバイダーの階層構造に基づいた状態で経路指定テーブルエントリーを集めることができると仮定します)。

   However, it appears that this hierarchy is being supplanted by a
   dense mesh of interconnections [6].  Additionally, there has been an
   enormous growth in the number of multihomed sites.  For purposes of
   redundancy and load-sharing, the multihomed address blocks are
   introduced into the global table even if they are covered by a
   provider aggregate.  This contributes to the rapidly-increasing size
   of both the global routing table and the turbulence exhibited within
   it, and places stress on the inter-provider routing system.

しかしながら、この階層構造がインタコネクト[6]の濃いメッシュによって取って代わられているように見えます。 さらに、「マルチ-家へ帰」っているサイトの数における莫大な成長がありました。 冗長と負荷分割法の目的のために、それらがプロバイダー集合でカバーされていても、「マルチ-家へ帰」っているあて先ブロックはグローバルなテーブルに紹介されます。 これは、グローバルな経路指定テーブルとそれの中に示された乱れの両方の急速に増加するサイズに貢献して、相互プロバイダールーティングシステムに圧力を置きます。

Abley, et al.                Informational                      [Page 1]

RFC 3582              IPv6 Site-Multihoming Goals            August 2003

Abley、他 [1ページ]情報のRFC3582IPv6サイトマルチホーミング目標2003年8月

   Continued growth of both the Internet and the practice of site-
   multihoming will seriously exacerbate this stress.  The site-
   multihoming architecture for IPv6 should allow the routing system to
   scale more pleasantly.

インターネットとサイトマルチホーミングの習慣の両方の継続成長は真剣にこの圧力を悪化させるでしょう。 IPv6のためのサイトマルチホーミングアーキテクチャで、ルーティングシステムは、より楽しく比例するはずです。

2.  Terminology

2. 用語

   A "site" is an entity autonomously operating a network using IP, and
   in particular, determining the addressing plan and routing policy for
   that network.  This definition is intended to be equivalent to
   "enterprise" as defined in [2].

「サイト」は、IPを使用することで自主的にネットワークを経営する存在と、そのネットワークのために特にアドレシングプランとルーティング方針を決定することです。 この定義が[2]で定義されるように「企業」に相当させていることを意図します。

   A "transit provider" operates a site that directly provides
   connectivity to the Internet to one or more external sites.  The
   connectivity provided extends beyond the transit provider's own site.
   A transit provider's site is directly connected to the sites for
   which it provides transit.

「トランジットプロバイダー」は直接接続性をインターネットに提供するサイトを1つ以上の外部のサイトまで操作します。 提供された接続性はトランジットプロバイダーの自己のサイトを超えて広がっています。 トランジットプロバイダーのサイトは直接それがトランジットを提供するサイトにつなげられます。

   A "multihomed" site is one with more than one transit provider.
   "Site-multihoming" is the practice of arranging a site to be
   multihomed.

"「マルチ-家へ帰」り"のサイトは1つ以上のトランジットプロバイダーがある1です。 「サイトマルチホーミング」は「マルチ-家へ帰」るためにサイトをアレンジする習慣です。

   The term "re-homing" denotes a transition of a site between two
   states of connectedness due to a change in the connectivity between
   the site and its transit providers' sites.

「再の家へ帰り」という用語は変化によるサイトとトランジットプロバイダーのサイトの間の接続性の連結性の2つの州の間のサイトの変遷を指示します。

3.  Multihoming Goals

3. マルチホーミング目標

3.1.  Capabilities of IPv4 Multihoming

3.1. IPv4マルチホーミングの能力

   The following capabilities of current IPv4 multihoming practices
   should be supported by an IPv6 multihoming architecture.

現在のIPv4マルチホーミング習慣の以下の能力はIPv6マルチホーミングアーキテクチャによってサポートされるべきです。

3.1.1.  Redundancy

3.1.1. 冗長

   By multihoming, a site should be able to insulate itself from certain
   failure modes within one or more transit providers, as well as
   failures in the network providing interconnection among one or more
   transit providers.

マルチホーミングで、サイトは1つ以上のトランジットプロバイダーの中で、ある故障モードからそれ自体を隔離できるべきです、1つ以上のトランジットプロバイダーにインタコネクトを提供するネットワークにおける失敗と同様に。

   Infrastructural commonalities below the IP layer may result in
   connectivity which is apparently diverse, sharing single points of
   failure.  For example, two separate DS3 circuits ordered from
   different suppliers and connecting a site to independent transit
   providers may share a single conduit from the street into a building;
   in this case, physical disruption (sometimes referred to as
   "backhoe-fade") of both circuits may be experienced due to a single
   incident in the street.  The two circuits are said to "share fate".

IP層の下におけるインフラストラクチャの共通点は単一のポイントの失敗を共有して、明らかに多様な接続性をもたらすかもしれません。 例えば、異なった供給者に注文されて、独立しているトランジットプロバイダーにサイトをつなげる2個の別々のDS3回路が通りからビルとただ一つの経路を共有するかもしれません。 この場合、両方の回路の物理的な分裂(時々「バックホウフェード」と呼ばれる)は単一のインシデントのため通りで経験されるかもしれません。 2個の回路が「運命を共有します。」と言われています。

Abley, et al.                Informational                      [Page 2]

RFC 3582              IPv6 Site-Multihoming Goals            August 2003

Abley、他 [2ページ]情報のRFC3582IPv6サイトマルチホーミング目標2003年8月

   The multihoming architecture should accommodate (in the general case,
   issues of shared fate notwithstanding) continuity of connectivity
   during the following failures:

マルチホーミングアーキテクチャは以下の失敗の間、接続性の連続に対応するべきです(共有された運命の問題にもかかわらず、一般的な場合で):

   o  Physical failure, such as a fiber cut, or router failure,

o ファイバーカット、またはルータ失敗などの物理的な失敗

   o  Logical link failure, such as a misbehaving router interface,

o ふらちな事をしているルータインタフェースなどの論理的なリンクの故障

   o  Routing protocol failure, such as a BGP peer reset,

o BGP同輩リセットなどのプロトコル失敗を発送します。

   o  Transit provider failure, such as a backbone-wide IGP failure, and

o そしてバックボーン全体のIGPの故障などのトランジットプロバイダー失敗。

   o  Exchange failure, such as a BGP reset on an inter-provider
      peering.

o じっと見て、相互プロバイダーにおけるBGPリセットなどの失敗を交換してください。

3.1.2.  Load Sharing

3.1.2. 負荷分割法

   By multihoming, a site should be able to distribute both inbound and
   outbound traffic between multiple transit providers.  This goal is
   for concurrent use of the multiple transit providers, not just the
   usage of one provider over one interval of time and another provider
   over a different interval.

マルチホーミングで、サイトは本国行きで両方を分配できるべきです、そして、倍数の間のアウトバウンドトラフィックはプロバイダーを通過します。 この目標は時間の1回の間隔の間の1つのプロバイダーの用法と異なった間隔の間の別のプロバイダーだけではなく、複数のトランジットプロバイダーの同時発生の使用のためのものです。

3.1.3.  Performance

3.1.3. パフォーマンス

   By multihoming, a site should be able to protect itself from
   performance difficulties directly between the site's transit
   providers.

マルチホーミングで、サイトはサイトのトランジットプロバイダーの直接間の性能困難から我が身をかばうことができるべきです。

   For example, suppose site E obtains transit from transit providers T1
   and T2, and there is long-term congestion between T1 and T2.  The
   multihoming architecture should allow E to ensure that in normal
   operation, none of its traffic is carried over the congested
   interconnection T1-T2.  The process by which this is achieved should
   be a manual one.

例えば、サイトEがトランジットプロバイダーのT1とT2からトランジットを得ると仮定してください。そうすれば、T1とT2の間には、長期の混雑があります。 マルチホーミングアーキテクチャで、Eは、通常の操作では、トラフィックのいずれも混雑しているインタコネクトT1-T2の上まで運ばれないのを保証できるべきです。 これが達成されるプロセスは手動のものであるべきです。

   A multihomed site should be able to distribute inbound traffic from
   particular multiple transit providers according to the particular
   address range within their site which is sourcing or sinking the
   traffic.

トラフィックを出典を明示するか、または沈めているそれらのサイトの中の特定のアドレスの範囲に従って、「マルチ-家へ帰」っているサイトは特定の倍数トランジットプロバイダーからインバウンドトラフィックを分配できるべきです。

Abley, et al.                Informational                      [Page 3]

RFC 3582              IPv6 Site-Multihoming Goals            August 2003

Abley、他 [3ページ]情報のRFC3582IPv6サイトマルチホーミング目標2003年8月

3.1.4.  Policy

3.1.4. 方針

   A customer may choose to multihome for a variety of policy reasons
   beyond technical scope (e.g., cost, acceptable use conditions, etc.)
   For example, customer C homed to ISP A may wish to shift traffic of a
   certain class or application, NNTP, for example, to ISP B as matter
   of policy.  A new IPv6 multihoming proposal should provide support
   for site-multihoming for external policy reasons.

顧客は技術的範囲(例えば、費用、許容できる使用条件など)を超えたさまざまな方針理由による「マルチ-ホーム」に選ぶかもしれません。 例えば、顧客CはAが、あるクラスかアプリケーションのトラフィック(例えば方針の問題としてのISP BへのNNTP)を移行させたがっているかもしれないISPと家へ帰りました。 新しいIPv6マルチホーミング提案はサイトマルチホーミングのサポートを対外政策理由に提供するべきです。

3.1.5.  Simplicity

3.1.5. 簡単さ

   As any proposed multihoming solution must be deployed in real
   networks with real customers, simplicity is paramount.  The current
   multihoming solution is quite straightforward to deploy and maintain.

本当の顧客と共に本当のネットワークでどんな提案されたマルチホーミング解決も配布しなければならないので、簡単さは最高のです。 現在のマルチホーミング解決は、配布して、維持するためにかなり簡単です。

   A new IPv6 multihoming solution should not be substantially more
   complex to deploy and operate (for multihomed sites or for the rest
   of the Internet) than current IPv4 multihoming practices.

新しいIPv6マルチホーミング解決は、配布して、作動する(「マルチ-家へ帰」っているサイトかインターネットの残りのために)ために現在のIPv4マルチホーミング習慣より実質的に複雑であるべきではありません。

3.1.6.  Transport-Layer Survivability

3.1.6. トランスポート層の生存性

   Multihoming solutions should provide re-homing transparency for
   transport-layer sessions; i.e., exchange of data between devices on
   the multihomed site and devices elsewhere on the Internet may proceed
   with no greater interruption than that associated with the transient
   packet loss during the re-homing event.

マルチホーミング解決はトランスポート層セッションのために再の家へ帰り透明を提供するべきです。 すなわち、インターネットのほかの場所の「マルチ-家へ帰」っているサイトとデバイスの上のデバイスの間のデータの交換は再の家へ帰りイベントの間、一時的なパケット損失に関連づけられたそれより大きい中断を続けないかもしれません。

   New transport-layer sessions should be able to be created following a
   re-homing event.

再の家へ帰りイベントに続いて、新しいトランスポート層セッションは作成できるべきです。

   Transport-layer sessions include those involving transport-layer
   protocols such as TCP, UDP and SCTP over IP.  Applications which
   communicate over raw IP and other network-layer protocols may also
   enjoy re-homing transparency.

トランスポート層セッションはIPの上でTCPや、UDPやSCTPなどのトランスポート層プロトコルにかかわるものを含んでいます。 また、生のIPの上で伝えるアプリケーションと他のネットワーク層プロトコルは再の家へ帰り透明を楽しむかもしれません。

3.1.7.  Impact on DNS

3.1.7. DNSで影響を与えてください。

   Multi-homing solutions either should be compatible with the observed
   dynamics of the current DNS system, or the solutions should
   demonstrate that the modified name resolution system required to
   support them is readily deployable.

マルチホーミング解決が現在のDNSシステムの観測された力学と互換性があるべきですか、またはソリューションは、それらをサポートするのに必要である変更された名前解決システムが容易に配布可能であることを示すべきです。

3.1.8.  Packet Filtering

3.1.8. パケットフィルタリング

   Multihoming solutions should not preclude filtering packets with
   forged or otherwise inappropriate source IP addresses at the
   administrative boundary of the multihomed site, or at the
   administrative boundaries of any site in the Internet.

マルチホーミング解決は、「マルチ-家へ帰」っているサイトの管理境界において、または、インターネットのどんなサイトの管理境界にも偽造しているかそうでなければ、不適当なソースIPアドレスがある状態でパケットをフィルターにかけるのを排除するべきではありません。

Abley, et al.                Informational                      [Page 4]

RFC 3582              IPv6 Site-Multihoming Goals            August 2003

Abley、他 [4ページ]情報のRFC3582IPv6サイトマルチホーミング目標2003年8月

3.2.  Additional Requirements

3.2. 追加要件

3.2.1.  Scalability

3.2.1. スケーラビリティ

   Current IPV4 multihoming practices contribute to the significant
   growth currently observed in the state held in the global inter-
   provider routing system; this is a concern, both because of the
   hardware requirements it imposes, and also because of the impact on
   the stability of the routing system.  This issue is discussed in
   great detail in [6].

現在のIPV4マルチホーミング習慣は現在グローバルな相互プロバイダールーティングシステムに保持された状態で観測されている重要な成長に貢献します。 それが課すハードウェア要件のためルーティングシステムの安定性の影響のでもこれは関心です。 [6]で丹念にこの問題について議論します。

   A new IPv6 multihoming architecture should scale to accommodate
   orders of magnitude more multihomed sites without imposing
   unreasonable requirements on the routing system.

新しいIPv6マルチホーミングアーキテクチャは、無理な要件をルーティングシステムに課さないで何桁もさらに「マルチ-家へ帰」っているサイトに対応するために比例するべきです。

3.2.2.  Impact on Routers

3.2.2. ルータで影響を与えてください。

   The solutions may require changes to IPv6 router implementations, but
   these changes should be either minor, or in the form of logically
   separate functions added to existing functions.

ソリューションがIPv6ルータ実装への変化を必要とするかもしれませんが、これらの変化は、小さい方であり、論理的に別々の機能の形で従来の機能に加えられるべきです。

   Such changes should not prevent normal single-homed operation, and
   routers implementing these changes should be able to interoperate
   fully with hosts and routers not implementing them.

そのような変化が防ぐはずがない、標準がシングル家へ帰った、操作、そして、これらの変化を実装するとホストとルータがそれらを実装していなく完全に共同利用できるべきであるルータ。

3.2.3.  Impact on Hosts

3.2.3. ホストの上で影響を与えてください。

   The solution should not destroy IPv6 connectivity for a legacy host
   implementing RFC 3513 [3], RFC 2460 [4], RFC 3493 [5], and other
   basic IPv6 specifications current in April 2003.  That is to say, if
   a host can work in a single-homed site, it should still be able to
   work in a multihomed site, even if it cannot benefit from site-
   multihoming.

ソリューションはRFC3513[3]、RFC2460[4]、RFC3493[5]、および他の基本的なIPv6に2003年4月の現在の仕様を履行するレガシーホストのためにIPv6の接続性を無効にするべきではありません。 ホストが中ですなわち、働くことができる、aがシングル家へ帰った、サイト、それは「マルチ-家へ帰」っているサイトでまだ働くことができるべきです、サイトマルチホーミングの利益を得ることができないでも。

   It would be compatible with this goal for such a host to lose
   connectivity if a site lost connectivity to one transit provider,
   despite the fact that other transit provider connections were still
   operational.

サイトが1つのトランジットプロバイダーに接続性を失うなら、そのようなホストが接続性を失うのは、この目標と互換性があるでしょうに、他のトランジットプロバイダー接続がまだ操作上であったという事実にもかかわらず。

   If the solution requires changes to the host stack, these changes
   should be either minor, or in the form of logically separate
   functions added to existing functions.

ソリューションがホストスタックへの変化を必要とするなら、これらの変化は、小さい方であり、論理的に別々の機能の形で従来の機能に加えられるべきです。

   If the solution requires changes to the socket API and/or the
   transport layer, it should be possible to retain the original socket
   API and transport protocols in parallel, even if they cannot benefit
   from multihoming.

ソリューションがソケットAPI、そして/または、トランスポート層への変化を必要とするなら、オリジナルのソケットAPIと平行なトランスポート・プロトコルを保有するのは可能であるべきです、マルチホーミングの利益を得ることができないでも。

Abley, et al.                Informational                      [Page 5]

RFC 3582              IPv6 Site-Multihoming Goals            August 2003

Abley、他 [5ページ]情報のRFC3582IPv6サイトマルチホーミング目標2003年8月

   The multihoming solution may allow host or application changes if
   that would enhance transport-layer survivability.

それがトランスポート層の生存性を高めるなら、マルチホーミング解決はホストかアプリケーションに変化を許容するかもしれません。

3.2.4.  Interaction between Hosts and the Routing System

3.2.4. ホストとルート設定システムとの相互作用

   The solution may involve interaction between a site's hosts and its
   routing system; such an interaction should be simple, scalable and
   securable.

ソリューションはサイトのホストとそのルーティングシステムとの相互作用にかかわるかもしれません。 そのような相互作用は、簡単で、スケーラブルで手に入れられるべきです。

3.2.5.  Operations and Management

3.2.5. 操作と管理

   It should be possible for staff responsible for the operation of a
   site to monitor and configure the site's multihoming system.

サイトの操作に責任があるスタッフがサイトのマルチホーミングシステムをモニターして、構成するのは、可能であるべきです。

3.2.6.  Cooperation between Transit Providers

3.2.6. トランジットプロバイダーの間の協力

   A multihoming strategy may require cooperation between a site and its
   transit providers, but should not require cooperation (relating
   specifically to the multihomed site) directly between the transit
   providers.

マルチホーミング戦略は、サイトとそのトランジットプロバイダーの間で協力を必要とするかもしれませんが、トランジットプロバイダーの直接間で協力は必要とするべきではありません(特に「マルチ-家へ帰」っているサイトに関連します)。

   The impact of any inter-site cooperation that might be required to
   facilitate the multihoming solution should be examined and assessed
   from the point of view of operational practicality.

マルチホーミング解決を容易にするのに必要である相互サイト協力の影響は、操作上の実用性の観点から調べられて、評価されるべきです。

3.2.7.  Multiple Solutions

3.2.7. 複数解

   There may be more than one approach to multihoming, provided all
   approaches are orthogonal (i.e., each approach addresses a distinct
   segment or category within the site multihoming problem).  Multiple
   solutions will incur a greater management overhead, however, and the
   adopted solutions should attempt to cover as many multihoming
   scenarios and goals as possible.

マルチホーミングへの1つ以上のアプローチがあるかもしれません、すべてのアプローチが直交しているなら(すなわち各アプローチはサイトマルチホーミング問題の中で異なったセグメントかカテゴリを扱います)。 しかしながら、複数解は、よりすばらしい管理オーバーヘッドを被るでしょう、そして、採用されたソリューションは可能であるとしての多くのマルチホーミングシナリオと目標としてのカバーに試みられるべきです。

4.  Security Considerations

4. セキュリティ問題

   A multihomed site should not be more vulnerable to security breaches
   than a traditionally IPv4-multihomed site.

「マルチ-家へ帰」っているサイトはaよりセキュリティに被害を受け易い不履行が伝統的にIPv4-multihomedサイトであるならそうしないでしょうに。

   Any changes to routing practices made to accommodate multihomed sites
   should not cause non-multihomed sites to become more vulnerable to
   security breaches.

「マルチ-家へ帰」っているサイトが対応させられたルーティング習慣へのどんな変化によっても、非「マルチ-家へ帰」っているサイトは機密保護違反により被害を受け易くなるべきではありません。

Abley, et al.                Informational                      [Page 6]

RFC 3582              IPv6 Site-Multihoming Goals            August 2003

Abley、他 [6ページ]情報のRFC3582IPv6サイトマルチホーミング目標2003年8月

5.  Intellectual Property Statement

5. 知的所有権声明

   The IETF takes no position regarding the validity or scope of any
   intellectual property 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; neither does it represent that it
   has made any effort to identify any such rights.  Information on the
   IETF's procedures with respect to rights in standards-track and
   standards-related documentation can be found in BCP-11.  Copies of
   claims of rights made available for publication 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 implementors or users of this specification can
   be obtained from the IETF Secretariat.

IETFはどんな知的所有権の正当性か範囲、実装に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 どちらも、それはそれを表しません。どんなそのような権利も特定するためにいずれも取り組みにしました。 BCP-11で標準化過程の権利と規格関連のドキュメンテーションに関するIETFの手順に関する情報を見つけることができます。 権利のクレームのコピーで利用可能に作られるべきライセンスの保証、または一般的なライセンスか許可が作成者によるそのような所有権の使用に得させられた試みの結果が公表といずれにも利用可能になったか、またはIETF事務局からこの仕様のユーザを得ることができます。

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

IETFはこの規格を練習するのに必要であるかもしれない技術をカバーするかもしれないどんな著作権もその注目していただくどんな利害関係者、特許、特許出願、または他の所有権も招待します。 IETF専務に情報を扱ってください。

6.  Normative References

6. 引用規格

   [1] Fuller, V., Li, T., Yu, J. and K. Varadhan, "Classless Inter-
       Domain Routing (CIDR): an Address Assignment and Aggregation
       Strategy", RFC 1519, September 1993.

[1] フラーとV.と李とT.とユーとJ.とK.Varadhan、「以下を掘る(CIDR)階級のない相互ドメイン」 「アドレス課題と集合戦略」、RFC1519、9月1993日

   [2] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G. and E.
       Lear, "Address Allocation for Private Internets", BCP 5, RFC
       1918, February 1996.

[2] Rekhter(Y.、マスコウィッツ、B.、Karrenberg、D.、deグルート、G.、およびE.リア)は「個人的なインターネットのための配分を扱います」、BCP5、RFC1918、1996年2月。

   [3] Hinden, R. and S. Deering, "Internet Protocol Version 6 (IPv6)
       Addressing Architecture", RFC 3513, April 2003.

[3]HindenとR.とS.デアリング、「インターネットプロトコルバージョン6(IPv6)アドレッシング体系」、RFC3513、2003年4月。

   [4] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6)
       Specification", RFC 2460, December 1998.

[4] デアリング、S.とR.Hinden、「インターネットプロトコル、バージョン6(IPv6)仕様」、RFC2460、12月1998日

   [5] Gilligan, R., Thomson, S., Bound, J., McCann, J. and W. Stevens,
       "Basic Socket Interface Extensions for IPv6", RFC 3493, February
       2003.

[5] ギリガンとR.とトムソンとS.とバウンドとJ.とマッキャンとJ.とW.スティーブンス、「IPv6"、RFC3493、2003年2月のための基本的なソケットインタフェース拡大。」

   [6] Huston, G., "Commentary on Inter-Domain Routing in the Internet",
       RFC 3221, December 2001.

[6] ヒューストン、G.、「インターネットの相互ドメインルート設定の論評」、RFC3221、2001年12月。

Abley, et al.                Informational                      [Page 7]

RFC 3582              IPv6 Site-Multihoming Goals            August 2003

Abley、他 [7ページ]情報のRFC3582IPv6サイトマルチホーミング目標2003年8月

7.  Authors' Addresses

7. 作者のアドレス

   Joe Abley
   Internet Software Consortium
   950 Charter Street
   Redwood City, CA  94063
   USA

ジョーAbleyインターネットソフトウェア共同体950憲章通りカリフォルニア94063レッドウッドシティー(米国)

   Phone: +1 650 423 1317
   EMail: jabley@isc.org

以下に電話をしてください。 +1 1317年の650 423メール: jabley@isc.org

   Benjamin Black
   Layer8 Networks

Layer8がネットワークでつなぐベンジャミンBlack

   EMail: ben@layer8.net

メール: ben@layer8.net

   Vijay Gill
   AOL Time Warner

ビジェイエラAOLタイム・ワーナー

   EMail: vijaygill9@aol.com

メール: vijaygill9@aol.com

Abley, et al.                Informational                      [Page 8]

RFC 3582              IPv6 Site-Multihoming Goals            August 2003

Abley、他 [8ページ]情報のRFC3582IPv6サイトマルチホーミング目標2003年8月

8.  Full Copyright Statement

8. 完全な著作権宣言文

   Copyright (C) The Internet Society (2003).  All Rights Reserved.

Copyright(C)インターネット協会(2003)。 All rights reserved。

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部分配された実装を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsプロセスで定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assignees.

上に承諾された限られた許容は、永久であり、そのインターネット協会、後継者または指定代理人によって取り消されないでしょう。

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS 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.

このドキュメントとそして、「そのままで」という基礎とインターネットの振興発展を目的とする組織に、インターネット・エンジニアリング・タスク・フォースが速達の、または、暗示しているすべての保証を放棄するかどうかというここにことであり、他を含んでいて、含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。

Acknowledgement

承認

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

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

Abley, et al.                Informational                      [Page 9]

Abley、他 情報[9ページ]