RFC2073 日本語訳

2073 An IPv6 Provider-Based Unicast Address Format. Y. Rekhter, P.Lothberg, R. Hinden, S. Deering, J. Postel. January 1997. (Format: TXT=15549 bytes) (Obsoleted by RFC2374) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文

Network Working Group                                         Y. Rekhter
Request for Comments: 2073                                         cisco
Category: Standards Track                                    P. Lothberg
                                                                STUPI.AB
                                                               R. Hinden
                                                        Ipsilon Networks
                                                              S. Deering
                                                              Xerox PARC
                                                               J. Postel
                                                                     ISI
                                                                 Editors
                                                            January 1997

Rekhterがコメントのために要求するワーキンググループY.をネットワークでつないでください: 2073年のコクチマスCategory: 規格はS.デアリングゼロックスPARC J.ポステルISIエディターズ1997年1月にP.Lothberg STUPI.AB R.Hinden Ipsilonネットワークを追跡します。

             An IPv6 Provider-Based Unicast Address Format

IPv6のプロバイダーベースのユニキャストアドレス形式

Status of this Memo

このMemoの状態

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。

1.0 Introduction

1.0 序論

   This document defines an IPv6 provider-based unicast address format
   for use in the Internet.  The address format defined in this document
   is consistent with the "IPv6 Addressing Architecture" [ARCH] and the
   "An Architecture for IPv6 Unicast Address Allocation" [ALLOC], and is
   intended to facilitate scalable Internet routing.

このドキュメントはインターネットでの使用のためにIPv6のプロバイダーベースのユニキャストアドレス形式を定義します。 本書では定義されたアドレス形式は、「IPv6アドレッシング体系」[ARCH]と「IPv6ユニキャストアドレス配分のためのアーキテクチャ」[ALLOC]と一致していて、スケーラブルなインターネット・ルーティングを容易にすることを意図します。

   The unicast address format defined in this document doesn't preclude
   the use of other unicast address formats.

本書では定義されたユニキャストアドレス形式は他のユニキャストアドレス形式の使用を排除しません。

2.0 Overview of the IPv6 Address

2.0 IPv6アドレスの概要

   IPv6 addresses are 128-bit identifiers for interfaces and sets of
   interfaces.  There are three types of addresses: Unicast, Anycast,
   and Multicast.  This document defines a specific type of Unicast
   address.

IPv6アドレスはインタフェースのインタフェースとセットのための128ビットの識別子です。 3つのタイプのアドレスがあります: ユニキャスト、Anycast、およびマルチキャスト。 このドキュメントは特定のタイプのUnicastアドレスを定義します。

   In this document, fields in addresses are given specific names, for
   example "subscriber".  When this name is used with the term "ID" (for
   "identifier") after the name (e.g., "subscriber ID"), it refers to
   the contents of the named field.  When it is used with the term
   "prefix" (e.g., "subscriber prefix") it refers to all of the address
   up to and including this field.

本書では、種名、例えば、「加入者」に住所の野原を与えます。 この名前が名前(例えば、「加入者ID」)の後に「ID」という用語(「識別子」のための)と共に使用されるとき、それは命名された分野のコンテンツについて言及します。 「接頭語」という用語と共に使用されるとき(例えば、「加入者接頭語」)、それはこの分野を含めてアドレスのすべてについて言及します。

Rekhter, et. al.            Standards Track                     [Page 1]

RFC 2073       IPv6 Provider-Based Unicast Address Format   January 1997

et Rekhter、アル。 ユニキャストアドレス形式1997年1月のプロバイダーベースの標準化過程[1ページ]RFC2073IPv6

   The specific type of an IPv6 address is indicated by the leading bits
   in the address.  The variable-length field comprising these leading
   bits is called the Format Prefix (FP).

IPv6アドレスの特定のタイプはアドレスで主なビットによって示されます。 これらの主なビットを包括する可変長の分野はFormat Prefix(FP)と呼ばれます。

   This document defines an address format for the 010 (binary) Format
   Prefix for Provider-Based Unicast addresses. The same address format
   could be used for other Format Prefixes, as long as these Format
   Prefixes also identify IPv6 unicast addresses.  Only the "010" Format
   Prefix is defined here.

このドキュメントはベースのProvider Unicastアドレスのための010の(2進)の形式Prefixのためにアドレス形式を定義します。 他のFormat Prefixesに同じアドレス形式を使用できました、また、これらのFormat PrefixesがIPv6ユニキャストアドレスを特定する限り。 「10インチの形式接頭語はここで定義されます」だけ

3.0 IPv6 Provider-Based Unicast Address Format

3.0 IPv6のプロバイダーベースのユニキャストアドレス形式

   This document defines an address format for the IPv6 provider-based
   unicast address assignment.  It is expected that this address format
   will be widely used for IPv6 nodes connected to the Internet.

このドキュメントはIPv6のプロバイダーベースのユニキャストアドレス課題のためにアドレス形式を定義します。 このアドレス形式がインターネットに接続されたIPv6ノードに広く使用されると予想されます。

   The address format defined in this document conforms to the
   "Architecture for IPv6 Unicast Address Allocation" [ALLOC].
   Specifically, the format is designed to support aggregation of
   network layer reachability information at multiple levels of routing
   hierarchy.

本書では定義されたアドレス形式は「IPv6ユニキャストアドレス配分のためのアーキテクチャ」[ALLOC]に従います。 明確に、形式は、複数のレベルのルーティング階層構造でネットワーク層可到達性情報の集合をサポートするように設計されています。

   For addresses of the format described in this document the address
   administration is organized into a three level hierarchy -- registry,
   provider, and subscriber.  The address format defined here allows
   flexible address allocation at each level of the address
   administration hierarchy in such a way as to support a wide spectrum
   of demands for address allocation.

本書では説明された形式のアドレスにおいて、アドレス管理は3の平らな階層構造に組織化されます--登録、プロバイダー、および加入者。 ここで定義されたアドレス形式はサポートに関するそのような方法でアドレス管理階層構造の各レベルにおけるフレキシブルなアドレス配分にアドレス配分の要求の広いスペクトルを許容します。

   This document assumes that the Internet routing system doesn't make
   any assumptions about the specific structure and semantics of an IPv6
   address, except for the structure and semantics of the Format Prefix
   part of the address, and the use of the "longest prefix match"
   algorithm (on arbitrary bit boundaries) for making a forwarding
   decision.

このドキュメントは、インターネット・ルーティングシステムがIPv6アドレスの特定の構造と意味論に関する少しの仮定もしないと仮定します、アドレスのFormat Prefix部分の構造と意味論、および「最も長い接頭語マッチ」アルゴリズム(任意のビット境界の)の推進決定をする使用を除いて。

   The address format defined in this document is intended to facilitate
   scalable Internet-wide routing that does not impose any constraints
   on connectivity among the providers, as well as among the providers
   and subscribers.

本書では定義されたアドレス形式がプロバイダーの中と、そして、プロバイダーと加入者の中で少しの規制も接続性に課さないスケーラブルなインターネット全体のルーティングを容易にすることを意図します。

Rekhter, et. al.            Standards Track                     [Page 2]

RFC 2073       IPv6 Provider-Based Unicast Address Format   January 1997

et Rekhter、アル。 ユニキャストアドレス形式1997年1月のプロバイダーベースの標準化過程[2ページ]RFC2073IPv6

3.1 Provider-Based Unicast Address Structure

3.1 プロバイダーベースのユニキャストアドレス構造

   For the purpose of address allocation, the address format defined in
   this document consists of the following parts:  Format Prefix,
   Registry ID, Provider ID, Subscriber ID, and an Intra-Subscriber
   part.  The Intra-Subscriber part definition is the responsibility of
   the subscriber and is not defined in this document.  The provider-
   based unicast address format is as follows:

アドレス配分の目的のために、本書では定義されたアドレス形式は以下の部分から成ります: Prefix、Registry Provider Subscriber ID(ID)(ID)、およびIntra-加入者部分をフォーマットしてください。 Intra-加入者部分定義は、加入者の責任であり、本書では定義されません。 ベースのプロバイダーユニキャストアドレス形式は以下の通りです:

      | 3 |  5 bits  |   n bits   |   56-n bits  |        64 bits     |
      +---+----------+------------+--------------+--------------------+
      |010|RegistryID| ProviderID | SubscriberID |  Intra-Subscriber  |
      +---+----------+------------+--------------+--------------------+

| 3 | 5ビット| nビット| 56-nビット| 64ビット| +---+----------+------------+--------------+--------------------+ |010|RegistryID| ProviderID| SubscriberID| イントラ加入者| +---+----------+------------+--------------+--------------------+

   The following sections specify each part of the IPv6 Provider-Based
   Unicast address format.  In general other allocation strategies are
   possible within this framework, but the ones described in this
   document will be used to assign IPv6 provider-based addresses.

以下のセクションはベースのIPv6 Provider Unicastアドレス形式の各部分を指定します。 一般に、他の配分戦略はこのフレームワークの中で可能ですが、本書では説明されたのは、プロバイダーベースのアドレスをIPv6に割り当てるのに使用されるでしょう。

   3.2 Registry ID

3.2 Registry ID

   With the growth of the Internet and its increasing globalization,
   much thought has been given to the evolution of the Network Layer
   address space allocation and assignment process.  RFC 1466,
   "Guidelines for Management of IP Address Space", proposes a plan that
   defines distributed allocation and assignment of the IPv4 address
   space.

インターネットの成長とその増加するグローバル化と共に、Network Layerアドレス空間配分と課題プロセスの発展に多くの考えを与えました。 「IP管理アドレス空間のためのガイドライン」というRFC1466はIPv4アドレス空間の分配された配分と課題を定義するプランを提案します。

   As the Internet transitions to IPv6, the plan for distributed
   allocation and assignment of the IPv4 address space established in
   RFC1466 forms a base for the distributed allocation and assignment of
   the IPv6 address space.

インターネットがIPv6に移行するので、IPv4アドレス空間の分配された配分と課題のためのプランはIPv6アドレス空間の分配された配分と課題のためのベースをRFC1466フォームに確立しました。

   The Internet Assigned Number Authority (IANA) is the principal
   registry for the IPv6 address space.  The IANA may allocate blocks of
   IPv6 addresses and delegate the assignment of those blocks to
   qualified Regional Registries.  The IANA will serve as the default
   registry in cases where no delegated registration authority has been
   identified.

ISOCの機関の一つで(IANA)はIPv6アドレス空間のための主要な登録です。 IANAはブロックのIPv6アドレスを割り当てて、それらのブロックの課題を適切なRegional Registriesへ代表として派遣するかもしれません。 IANAは代表として派遣された登録局が全く特定されていないケースの中のデフォルト登録として機能するでしょう。

   The Registry ID of the IPv6 provider-based unicast address format is
   intended to facilitate a broad geographic address allocation and
   facilitate the operations of the distributed Regional Registries.

IPv6のプロバイダーベースのユニキャストアドレス形式のRegistry IDは、広い地理的なアドレス配分を容易にして、分配されたRegional Registriesの操作を容易にすることを意図します。

   The Registry ID immediately follows the format prefix part of an IPv6
   address.

Registry IDはすぐに、IPv6アドレスの形式接頭語部分に続きます。

Rekhter, et. al.            Standards Track                     [Page 3]

RFC 2073       IPv6 Provider-Based Unicast Address Format   January 1997

et Rekhter、アル。 ユニキャストアドレス形式1997年1月のプロバイダーベースの標準化過程[3ページ]RFC2073IPv6

   At present there are three Regional Registries: INTERNIC, RIPE NCC,
   and APNIC.  In addition, address allocation could be done directly by
   the IANA.  Corresponding to this division of address allocation, this
   document defines the following Registry IDs:

現在のところ、3Regional Registriesがあります: INTERNIC、熟しているNCC、およびAPNIC。 さらに、直接IANAはアドレス配分ができました。 アドレス配分のこの分割に対応している、このドキュメントは以下のRegistry IDを定義します:

        Regional Registry                     Value (binary)
        --------------------                  --------------

地方の登録値(バイナリー)-------------------- --------------

        Multi-Regional (IANA)                 10000
        RIPE NCC                              01000
        INTERNIC                              11000
        APNIC                                 00100

マルチ地方の(IANA)10000熟しているNCC01000INTERNIC11000APNIC00100

   All other values of the Registry ID are reserved by the IANA.

Registry IDの他のすべての値がIANAによって予約されます。

   Use of the Multi-regional Registry ID permits flexibility in address
   assignments which are outside of the geographical regions already
   allocated.  The IANA will be responsible for managing address space
   registration under the Multi-Regional Registry ID.

Multi地方のRegistry IDの使用は既に割り当てられた地理的な領域の外にあるアドレス課題における柔軟性を可能にします。 IANAはMulti地方のRegistry IDの下でアドレス空間登録を管理するのに責任があるでしょう。

   It is expected that the IANA, and any designated Regional Registries,
   allocate addresses in conformance with this overall scheme.  Where
   there are qualifying Regional Registries established, primary
   responsibility for allocation from within that block will be
   delegated to that registry.

IANA、およびどんな指定されたRegional Registriesもこの総合的な体系がある順応におけるアドレスを割り当てると予想されます。 確立した資格を得るRegional Registriesがあるところでは、そのブロックからの配分への責務をその登録へ代表として派遣するでしょう。

   A Regional Registry may have more than one block of addresses
   allocated to it (as a result the Registry would have multiple
   Registry IDs associated with it).

Regional Registryは1ブロック以上のアドレスをそれに割り当てさせるかもしれません(その結果、Registryには、それに関連している複数のRegistry IDがあるでしょう)。

3.3 Provider ID and Subscriber ID

3.3 Provider IDと加入者ID

   This document leaves the organization of the Provider ID and
   Subscriber ID portions of address up to individual registries.
   Particularly the registry needs to define how much address space is
   given to providers and their subscribers.  There are several issues
   which must be addressed when doing this.  These include:

このドキュメントは、個々の登録にProviderの組織をIDに任せて、アドレスの部分にSubscriber IDを任せます。 特に登録は、どのくらいのアドレス空間がプロバイダーと彼らの加入者に与えられているかを定義する必要があります。 これをするとき扱わなければならないいくつかの問題があります。 これらは:

      o There will likely be a mixture of providers of different sizes.
      o Small providers will grow to become large providers.
      o Large providers will lose customers and become small providers.
        In extreme cases, the registry will require them to return some
        of their address space to the registry.
      o Organizations which need to be multi-homed to more than one
        provider will request a Provider ID assignment.

o 異なったサイズのプロバイダーの混合物がおそらくあるでしょう。o Smallプロバイダーは大きいプロバイダーになるようになるでしょう。o Largeプロバイダーは、客足が落ちて、小さいプロバイダーになるでしょう。 極端な場合は、登録がリターンにそれらを必要とする、マルチ、家へ帰り、1以上まで、プロバイダーはProvider ID課題を要求するでしょう。

   It is important that a registry design its Provider ID space to allow
   flexibility and at the same time use the address space efficiently.

登録が柔軟性を許容して、同時に効率的にアドレス空間を使用するようにProvider IDスペースを設計するのは、重要です。

Rekhter, et. al.            Standards Track                     [Page 4]

RFC 2073       IPv6 Provider-Based Unicast Address Format   January 1997

et Rekhter、アル。 ユニキャストアドレス形式1997年1月のプロバイダーベースの標準化過程[4ページ]RFC2073IPv6

3.3.1 Provider ID

3.3.1 Provider ID

   The value of the Provider ID associated with an address block a
   registry allocates to a particular provider uniquely identifies this
   provider within the registry.

登録が唯一特定のプロバイダーに割り当てるあて先ブロックに関連しているProvider IDの値は登録の中でこのプロバイダーを特定します。

   This document assumes that some subscribers may decide to acquire
   their address space directly from a registry, thus making their
   addresses independent of the provider(s) they are directly attached.

このドキュメントは、何人かの加入者が、直接登録から彼らのアドレス空間を取得すると決めるかもしれないと仮定します、その結果、プロバイダーの如何にかかわらず彼らのアドレスを(s)にして、それらは直接付けられています。

3.3.2 Subscriber ID

3.3.2 加入者ID

   The structure and assignment strategy of Subscriber ID's is specified
   by each provider.

Subscriber IDの構造と課題戦略は各プロバイダーによって指定されます。

   A (direct) provider may decide to group its subscribers into regions.
   This grouping may be useful when the (direct) provider is attached to
   another (indirect) provider at multiple points, as it allows the
   direct provider to exert a certain degree of control over the
   coupling between the attachment points and flow of the traffic
   destined to a particular subscriber (see Section 5.3.1 of [ALLOC]).

(ダイレクト)のプロバイダーは、加入者を領域に分類すると決めるかもしれません。 (ダイレクト)のプロバイダーが複数のポイントの別の(間接的)のプロバイダーに付けられているとき、この組分けは役に立つかもしれません、ダイレクトプロバイダーがそれで付着点の間のカップリングのある度合いのコントロールと特定の加入者に運命づけられたトラフィックの流れを及ぼすことができるとき(.1セクション5.3[ALLOC]を見てください)。

   To accommodate such a grouping the (direct) provider may allocate
   some small number of high-order bits of the Subscriber ID as a
   Subscriber-Region ID.  The purpose of a Subscriber-Region ID is to
   identify a group of subscribers that are within a close topological
   proximity to each other (from the provider's point of view), and thus
   could be reachable through a particular attachment point between the
   (direct) provider and other (indirect) provider(s).

そのような組分けを収容するために、(ダイレクト)のプロバイダーはSubscriber-Region IDとしてSubscriber IDの何らかの少ない数の高位のビットを割り当てるかもしれません。 Subscriber-Region IDの目的が互い(プロバイダーの観点からの)の厳密な位相的な近接の中にいる加入者のグループを特定することであり、その結果、(ダイレクト)のプロバイダーと他の(間接的)のプロバイダーの間の特定の付着点を通して届くかもしれません。

3.4 Intra-Subscriber Part

3.4 イントラ加入者部分

   This document leaves the organization of Intra-Subscriber portion of
   the address up to individual subscribers.

このドキュメントはアドレスのIntra-加入者部分の組織を個々の加入者に任せます。

   The provider-based unicast address format described in this document
   leaves 64 bits for the local portion of the address.  The editors of
   this document recommend that subscribers use IPv6 auto-configuration
   capabilities [AUTO] to generate addresses using link-specific
   addresses as Interface ID such as 48 bit IEEE-802 MAC addresses.  In
   this case 16 bits are left for the Subnet ID.  This should sufficient
   (e.g., 65,535 subnets) for all but the largest of subscribers.  This
   is shown as follows:

本書では説明されたプロバイダーベースのユニキャストアドレス形式はアドレスの地方の部分に64ビットを残します。 このドキュメントのエディタは、加入者が48などのInterface IDがIEEE-802 MACアドレスに噛み付きながらリンク特有のアドレスを使用することでアドレスを作るIPv6自動構成能力[AUTO]を使用することを勧めます。 この場合、16ビットはSubnet IDに残されます。 これはすべてに十分な、しかし、(例えば、6万5535サブネット)最も大きい加入者がそうするべきです。 これは以下の通り示されます:

      |            64 bits             |  16 bits  |     48 bits      |
      +--------------------------------+-----------+------------------+
      |       Subscriber Prefix        | Subnet ID |   Interface ID   |
      +--------------------------------+-----------+------------------+

| 64ビット| 16ビット| 48ビット| +--------------------------------+-----------+------------------+ | 加入者接頭語| サブネットID| インタフェースID| +--------------------------------+-----------+------------------+

Rekhter, et. al.            Standards Track                     [Page 5]

RFC 2073       IPv6 Provider-Based Unicast Address Format   January 1997

et Rekhter、アル。 ユニキャストアドレス形式1997年1月のプロバイダーベースの標準化過程[5ページ]RFC2073IPv6

   Subscribers who need additional subnets (and who desire to continue
   to use 48 bit IEEE-802 MAC addresses for Interface ID's) can be
   accommodated by having the provider assign them a block of subscriber
   prefixes.  Alternatively, an extremely large subscriber could be
   assigned its own Provider ID which would give it additional bits of
   address space to create its own local address hierarchy.

プロバイダーに1ブロックの加入者接頭語をそれらに割り当てさせることによって、追加サブネット(だれが、48ビットのIEEE-802 MACを使用し続けていることを望んでいるかがInterfaceのためにIDのものを扱う)を必要とする加入者は設備することができます。 あるいはまた、アドレス空間がそれ自身のローカルアドレス階層構造を作成するのを追加ビットに与えるそれ自身のProvider IDは非常に大きい加入者に割り当てることができました。

4.0 National Registries

4.0 国家の登録

   A Regional Registry may allocate blocks of address space to several
   National Registries.  The National Registry then becomes the entity
   that allocates address space to individual providers within the
   country served by the National Registry.

Regional Registryはブロックのアドレス空間を数個のNational Registriesに割り当てるかもしれません。 そして、National RegistryはNational Registryによって国内で役立たれた個々のプロバイダーにアドレス空間を割り当てる実体になります。

   To create National Registries the Regional Registry may add a layer
   of hierarchy in the Provider ID field to create National Registries.
   The resulting Provider Prefix is as follows:

National Registries Regional Registryを作成するのは、National Registriesを作成するためにProvider ID分野の階層構造の層を加えるかもしれません。 結果として起こるProvider Prefixは以下の通りです:

   | 3 |  5 bits  |  n bits  |  m bits  |   56-n-m   |    64 bits     |
   +---+----------+----------+----------+------------+----------------+
   |010|RegistryID| National | Provider | Subscriber |Intra-Subscriber|
   |   |          |RegistryID|   ID     |     ID     |                |
   +---+----------+----------+----------+------------+----------------+

| 3 | 5ビット| nビット| mビット| 56-n-m| 64ビット| +---+----------+----------+----------+------------+----------------+ |010|RegistryID| 国家| プロバイダー| 加入者|イントラ加入者| | | |RegistryID| ID| ID| | +---+----------+----------+----------+------------+----------------+

   This document assumes that within each regional registry there will
   be a relatively small number of national registries.  The size of the
   National-Registry ID should be related to the number of countries in
   the region administrated by the regional registry and the number of
   providers expected to be in each country.

このドキュメントは、そこでのそれぞれの地方の登録の中のそれが比較的少ない数の国家の登録になると仮定します。 National-Registry IDの大きさはその領域の地方の登録によって管理された国の数と各国にあると予想されたプロバイダーの数に関連するべきです。

5.0 Acknowledgments

5.0 承認

   The editors would like to express our thanks to Jim Bound (Digital),
   Scott Bradner (Harvard), Brian Carpenter (CERN), Geoff Huston
   (AANET), and Tony Li (cisco) for their review and constructive
   comments.

エディタは彼らのレビューと建設的なコメントのためにジムBound(デジタル)、スコット・ブラドナー(ハーバード)、ブライアンCarpenter(CERN)、ジェフ・ヒューストン(AANET)、およびトニー・李(コクチマス)に感謝したがっています。

6.0 References

6.0の参照箇所

   [ALLOC] Rekhter, Y., Li, T., "An Architecture for IPv6 Unicast
           Address Allocation", RFC 1887, December 1995.

[ALLOC] Rekhter、Y.、李、T.、「IPv6ユニキャストアドレス配分のためのアーキテクチャ」、RFC1887、1995年12月。

   [ARCH]  Hinden, R., "IP Version 6 Addressing Architecture",
           RFC 1884, December 1995.

[アーチ]Hinden、R.、「IPバージョン6アドレッシング体系」、RFC1884、1995年12月。

   [AUTO]  Thompson, S., "IPv6 Stateless Address Autoconfiguration",
           RFC 1972, August 1996.

[自動] トンプソン、S.、「IPv6の状態がないアドレス自動構成」、RFC1972、1996年8月。

Rekhter, et. al.            Standards Track                     [Page 6]

RFC 2073       IPv6 Provider-Based Unicast Address Format   January 1997

et Rekhter、アル。 ユニキャストアドレス形式1997年1月のプロバイダーベースの標準化過程[6ページ]RFC2073IPv6

7.0 Security Considerations

7.0 セキュリティ問題

   Security issues are not discussed in this memo.

このメモで安全保障問題について議論しません。

8.0 Editors' Addresses

8.0 エディタのアドレス

   Yakov Rekhter
   Cisco Systems, Inc.
   170 West Tasman Drive
   San Jose, CA 95134-1706
   USA
   Phone:  +1 914 528-0090
   EMail:  yakov@cisco.com

西タスマン・DriveヤコフRekhterシスコシステムズInc.170カリフォルニア95134-1706サンノゼ(米国)は以下に電話をします。 +1 914 528-0090 メールしてください: yakov@cisco.com

   Peter Lothberg
   STUPI.AB
   Box 9129
   S-102 72 Stockholm
   Sweden
   Phone:+46 8 6699720
   EMail: roll@Stupi.SE

ピーターLothberg STUPI.AB箱の9129秒間-102 72ストックホルムスウェーデン電話: +46 8 6699720 メール: roll@Stupi.SE

   Robert M. Hinden
   Ipsilon Networks, Inc.
   2191 E. Bayshore Road
   Palo Alto, CA 94303
   USA
   Phone: +1 415 846 4604
   EMail: hinden@ipsilon.com

ロバートM.Hinden IpsilonはE.Bayshore Roadカリフォルニア94303パロアルト(米国)が電話をするInc.2191をネットワークでつなぎます: +1 4604年の415 846メール: hinden@ipsilon.com

   Stephen E. Deering
   Xerox Palo Alto Research Center
   3333 Coyote Hill Road
   Palo Alto, CA 94304
   USA
   Phone: +1 415 812 4839
   Fax:   +1 415 812 4471
   EMail: deering@parc.xerox.com

スティーブンE.デアリングゼロックスパロアルト研究センター3333コヨーテヒル・Roadカリフォルニア94304パロアルト(米国)は以下に電話をします。 +1 415 812、4839Fax: +1 4471年の415 812メール: deering@parc.xerox.com

   Jon Postel
   Information Sciences Institute
   4676 Admiralty Way
   Marina del Rey, CA 90292-6695
   USA
   Phone: +1 310 822 1511
   Fax:   +1 310 823 6714
   EMail: postel@isi.edu

ジョンポステル情報Sciences Institute4676海軍本部Wayマリナデルレイ、カリフォルニア90292-6695米国電話: +1 310 822、1511Fax: +1 6714年の310 823メール: postel@isi.edu

Rekhter, et. al.            Standards Track                     [Page 7]

et Rekhter、アル。 標準化過程[7ページ]

一覧

 RFC 1〜100  RFC 1401〜1500  RFC 2801〜2900  RFC 4201〜4300 
 RFC 101〜200  RFC 1501〜1600  RFC 2901〜3000  RFC 4301〜4400 
 RFC 201〜300  RFC 1601〜1700  RFC 3001〜3100  RFC 4401〜4500 
 RFC 301〜400  RFC 1701〜1800  RFC 3101〜3200  RFC 4501〜4600 
 RFC 401〜500  RFC 1801〜1900  RFC 3201〜3300  RFC 4601〜4700 
 RFC 501〜600  RFC 1901〜2000  RFC 3301〜3400  RFC 4701〜4800 
 RFC 601〜700  RFC 2001〜2100  RFC 3401〜3500  RFC 4801〜4900 
 RFC 701〜800  RFC 2101〜2200  RFC 3501〜3600  RFC 4901〜5000 
 RFC 801〜900  RFC 2201〜2300  RFC 3601〜3700  RFC 5001〜5100 
 RFC 901〜1000  RFC 2301〜2400  RFC 3701〜3800  RFC 5101〜5200 
 RFC 1001〜1100  RFC 2401〜2500  RFC 3801〜3900  RFC 5201〜5300 
 RFC 1101〜1200  RFC 2501〜2600  RFC 3901〜4000  RFC 5301〜5400 
 RFC 1201〜1300  RFC 2601〜2700  RFC 4001〜4100  RFC 5401〜5500 
 RFC 1301〜1400  RFC 2701〜2800  RFC 4101〜4200 

スポンサーリンク

CakePHPのバージョンごとのシステム要件

ホームページ製作・web系アプリ系の製作案件募集中です。

上に戻る