RFC2529 日本語訳
2529 Transmission of IPv6 over IPv4 Domains without Explicit Tunnels.B. Carpenter, C. Jung. March 1999. (Format: TXT=21049 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group B. Carpenter
Request for Comments: 2529 IBM
Category: Standards Track C. Jung
3Com
March 1999
コメントを求めるワーキンググループB.大工要求をネットワークでつないでください: 2529年のIBMカテゴリ: 1999年の標準化過程C.ユング3Com行進
Transmission of IPv6 over IPv4 Domains without Explicit Tunnels
明白なTunnelsのいないIPv4ドメインの上の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)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (1999). All Rights Reserved.
Copyright(C)インターネット協会(1999)。 All rights reserved。
Abstract
要約
This memo specifies the frame format for transmission of IPv6 [IPV6] packets and the method of forming IPv6 link-local addresses over IPv4 domains. It also specifies the content of the Source/Target Link- layer Address option used in the Router Solicitation, Router Advertisement, Neighbor Solicitation, and Neighbor Advertisement and Redirect messages, when those messages are transmitted on an IPv4 multicast network.
このメモはIPv6[IPV6]パケットのトランスミッションとIPv6のリンクローカルのアドレスをIPv4ドメインの上に形成するメソッドにフレーム形式を指定します。 また、それはオプションがRouter Solicitation、Router Advertisement、Neighbor Solicitation、Neighbor Advertisement、およびRedirectメッセージで使用した目標Source/Link Address層の内容を指定します、それらのメッセージがIPv4マルチキャストネットワークで送られるとき。
The motivation for this method is to allow isolated IPv6 hosts, located on a physical link which has no directly connected IPv6 router, to become fully functional IPv6 hosts by using an IPv4 domain that supports IPv4 multicast as their virtual local link. It uses IPv4 multicast as a "virtual Ethernet".
このメソッドに関する動機はどんな直接接続されたIPv6ルータも持っていない物理的なリンクに見つけられた孤立しているIPv6ホストが仮想の地元のリンクとしてIPv4がマルチキャストであるとサポートするIPv4ドメインを使用することによって完全に機能的なIPv6ホストになるのを許容することです。 それは「仮想のイーサネット」としてIPv4マルチキャストを使用します。
Table of Contents
目次
1. Introduction....................................................2 2. Maximum Transmission Unit.......................................2 3. Frame Format....................................................3 4. Stateless Autoconfiguration and Link-Local Addresses............3 5. Address Mapping -- Unicast......................................4 6. Address Mapping -- Multicast....................................4 7. Scaling and Transition Isues....................................5 8. IANA Considerations.............................................6 9. Security Considerations.........................................6
1. 序論…2 2. 最大のトランスミッション単位…2 3. 形式を縁どってください…3 4. 状態がない自動構成とリンクローカルのアドレス…3 5. マッピング--ユニキャストを扱ってください…4 6. マッピング--マルチキャストを扱ってください…4 7. スケーリングと変遷Isues…5 8. IANA問題…6 9. セキュリティ問題…6
Carpenter & Jung Standards Track [Page 1] RFC 2529 Transmission of IPv6 Packets over IPv4 March 1999
IPv4 March 1999の上のIPv6パケットの大工とユング標準化過程[1ページ]RFC2529トランスミッション
Acknowledgements...................................................7 References.........................................................7 APPENDIX A: IPv4 Multicast Addresses for Neighbor Discovery........8 Authors' Addresses.................................................9 Full Copyright Notice.............................................10
承認…7つの参照箇所…7 付録A: IPv4マルチキャストは隣人のために発見を扱います…8人の作者のアドレス…9の完全な版権情報…10
1. Introduction
1. 序論
This memo specifies the frame format for transmission of IPv6 [IPV6] packets and the method of forming IPv6 link-local addresses over IPv4 multicast "domains". For the purposes of this document, an IPv4 domain is a fully interconnected set of IPv4 subnets, within the same local multicast scope, on which there are at least two IPv6 nodes conforming to this specification. This IPv4 domain could form part of the globally-unique IPv4 address space, or could form part of a private IPv4 network [RFC 1918].
このメモはIPv4マルチキャスト「ドメイン」の上でIPv6[IPV6]パケットのトランスミッションとIPv6のリンクローカルのアドレスを形成するメソッドにフレーム形式を指定します。 このドキュメントの目的のために、IPv4ドメインは完全にインタコネクトされたセットのIPv4サブネットです、同じ地方のマルチキャスト範囲の中で、どれがこの仕様に従う少なくとも2つのIPv6ノードがあるかに関して。 このIPv4ドメインは、グローバルにユニークなIPv4アドレス空間の一部を形成できたか、または私設のIPv4ネットワーク[RFC1918]の一部を形成するかもしれません。
This memo also specifies the content of the Source/Target Link-layer Address option used in the Router Solicitation, Router Advertisement, Neighbor Solicitation, Neighbor Advertisement and Redirect messages described in [DISC], when those messages are transmitted on an IPv4 multicast domain.
また、このメモはオプションがRouter Solicitationで使用したSource/目標Address Link-層の内容を指定します、とRouter Advertisement、Neighbor Solicitation、Neighbor Advertisement、およびRedirectメッセージは[DISC]で説明しました、それらのメッセージがIPv4マルチキャストドメインで送られるとき。
The motivation for this method is to allow isolated IPv6 hosts, located on a physical link which has no directly connected IPv6 router, to become fully functional IPv6 hosts by using an IPv4 multicast domain as their virtual local link. Thus, at least one IPv6 router using the same method must be connected to the same IPv4 domain if IPv6 routing to other links is required.
このメソッドに関する動機はどんな直接接続されたIPv6ルータも持っていない物理的なリンクに見つけられた孤立しているIPv6ホストが仮想の地元のリンクとしてIPv4マルチキャストドメインを使用することによって完全に機能的なIPv6ホストになるのを許容することです。 したがって、他のリンクへのIPv6ルーティングが必要であるなら、同じメソッドを使用する少なくとも1つのIPv6ルータを同じIPv4ドメインに関連づけなければなりません。
IPv6 hosts connected using this method do not require IPv4-compatible addresses or configured tunnels. In this way IPv6 gains considerable independence of the underlying links and can step over many hops of IPv4 subnets. The mechanism is known formally as "IPv6 over IPv4" or "6over4" and colloquially as "virtual Ethernet".
このメソッドを使用することで接されたIPv6ホストはIPv4コンパチブルアドレスか構成されたトンネルを必要としません。 このように、IPv6は基本的なリンクからのかなりの独立を獲得して、IPv4サブネットの多くのホップをまたぐことができます。 または、メカニズムが正式に知られている、「IPv4"の上のIPv6、「6over4"、口語的である、「仮想のイーサネット」として」
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTは[RFC2119]で説明されるように本書では解釈されることであるべきですか?
2. Maximum Transmission Unit
2. マキシマム・トランスミッション・ユニット
The default MTU size for IPv6 packets on an IPv4 domain is 1480 octets. This size may be varied by a Router Advertisement [DISC] containing an MTU option which specifies a different MTU, or by manual configuration of each node.
IPv4ドメインのIPv6パケットのためのデフォルトMTUサイズは1480の八重奏です。 このサイズは異なったMTUを指定するMTUオプションを含むRouter Advertisement[DISC]、またはそれぞれのノードの手動の構成によって変えられるかもしれません。
Carpenter & Jung Standards Track [Page 2] RFC 2529 Transmission of IPv6 Packets over IPv4 March 1999
IPv4 March 1999の上のIPv6パケットの大工とユング標準化過程[2ページ]RFC2529トランスミッション
Note that if by chance the IPv6 MTU size proves to be too large for some intermediate IPv4 subnet, IPv4 fragmentation will ensue. While undesirable, this is not disastrous. However, the IPv4 "do not fragment" bit MUST NOT be set in the encapsulating IPv4 header.
IPv6 MTUサイズが何らかの中間的IPv4サブネットには大き過ぎると偶然判明すると、IPv4断片化が続くことに注意してください。 望ましくないのですが、これは悲惨ではありません。 しかしながら、要約のIPv4ヘッダーに「断片化しないでください」というIPv4ビットを設定してはいけません。
3. Frame Format
3. フレーム形式
IPv6 packets are transmitted in IPv4 packets [RFC 791] with an IPv4 protocol type of 41, the same as has been assigned in [RFC 1933] for IPv6 packets that are tunneled inside of IPv4 frames. The IPv4 header contains the Destination and Source IPv4 addresses. The IPv4 packet body contains the IPv6 header followed immediately by the payload.
41人のIPv4プロトコルタイプ(中でトンネルを堀られるIPv4フレームのIPv6パケットのために[RFC1933]で割り当てられた同じくらい)でIPv6パケットはIPv4パケット[RFC791]で伝えられます。 IPv4ヘッダーはDestinationとSource IPv4アドレスを含んでいます。 IPv4パケットボディーはIPv6ヘッダーを含みます、続いて、すぐペイロードを含みます。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version| IHL |Type of Service| Total Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identification |Flags| Fragment Offset |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Time to Live | Protocol 41 | Header Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 header and payload ... /
+-------+-------+-------+-------+-------+------+------+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |バージョン| IHL|サービスのタイプ| 全長| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 識別|旗| 断片オフセット| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 生きる時間| プロトコル41| ヘッダーチェックサム| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ソースアドレス| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 送付先アドレス| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | オプション| 詰め物| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv6ヘッダーとペイロード… / +-------+-------+-------+-------+-------+------+------+
If there are IPv4 options, then padding SHOULD be added to the IPv4 header such that the IPv6 header starts on a boundary that is a 32- bit offset from the end of the datalink header.
IPv4オプションがあれば、SHOULDを水増しして、IPv6ヘッダーがデータリンクヘッダーの端から相殺された32ビットである境界を始めるように、IPv4ヘッダーに加えられてください。
The Time to Live field SHOULD be set to a low value, to prevent such packets accidentally leaking from the IPv4 domain. This MUST be a configurable parameter, with a recommended default of 8.
TimeはSHOULDをLiveとしてさばきます。そのようなパケットがIPv4ドメインから偶然漏れるのを防ぐのを低値に用意ができさせてください。 これは8のお勧めのデフォルトがある構成可能なパラメタであるに違いありません。
4. Stateless Autoconfiguration and Link-Local Addresses
4. 状態がない自動構成とリンクローカルのアドレス
The Interface Identifier [AARCH] of an IPv4 interface is the 32-bit IPv4 address of that interface, with the octets in the same order in which they would appear in the header of an IPv4 packet, padded at the left with zeros to a total of 64 bits. Note that the "Universal/ Local" bit is zero, indicating that the Interface Identifer is not globally unique. When the host has more than one IPv4 address in use
IPv4インタフェースのInterface Identifier[AARCH]はそのインタフェースの32ビットのIPv4アドレスです、それらがIPv4パケットのヘッダーに現れる同次における八重奏で、左では、合計64ビットまでのゼロで、そっと歩きます。 Interface Identiferがグローバルにユニークでないことを示して、「普遍的であるか地方」のビットがゼロであることに注意してください。 ホストに1つ以上のIPv4アドレスが使用中にあるとき
Carpenter & Jung Standards Track [Page 3] RFC 2529 Transmission of IPv6 Packets over IPv4 March 1999
IPv4 March 1999の上のIPv6パケットの大工とユング標準化過程[3ページ]RFC2529トランスミッション
on the physical interface concerned, an administrative choice of one of these IPv4 addresses is made.
関する物理インターフェースでは、これらのIPv4アドレスの1つの管理選択をします。
An IPv6 address prefix used for stateless autoconfiguration [CONF] of an IPv4 interface MUST have a length of 64 bits except for a special case mentioned in Section 7.
IPv4インタフェースの状態がない自動構成[CONF]に使用されるIPv6アドレス接頭語で、セクション7で特別なケース以外の64ビットの長さについて言及しなければなりません。
The IPv6 Link-local address [AARCH] for an IPv4 virtual interface is formed by appending the Interface Identifier, as defined above, to the prefix FE80::/64.
IPv4仮想インターフェースへのIPv6 Link-ローカルアドレス[AARCH]はInterface Identifierを追加することによって、形成されます、上で定義されるように、接頭語FE80に:、:/64.
+-------+-------+-------+-------+-------+-------+------+------+
| FE 80 00 00 00 00 00 00 |
+-------+-------+-------+-------+-------+-------+------+------+
| 00 00 | 00 | 00 | IPv4 Address |
+-------+-------+-------+-------+-------+-------+------+------+
+-------+-------+-------+-------+-------+-------+------+------+ | FE80 00 00 00 00 00 00| +-------+-------+-------+-------+-------+-------+------+------+ | 00 00 | 00 | 00 | IPv4アドレス| +-------+-------+-------+-------+-------+-------+------+------+
5. Address Mapping -- Unicast
5. アドレス・マッピング--ユニキャスト
The procedure for mapping IPv6 addresses into IPv4 virtual link-layer addresses is described in [DISC]. The Source/Target Link-layer Address option has the following form when the link layer is IPv4. Since the length field is in units of 8 bytes, the value below is 1.
IPv4の仮想のリンクレイヤアドレスにIPv6アドレスを写像するための手順は[DISC]で説明されます。 リンクレイヤがIPv4であるときに、Source/目標Link-層のAddressオプションには、以下のフォームがあります。 長さの分野が8バイトの単位にあるので、以下の値は1です。
+-------+-------+-------+-------+-------+-------+-------+-------+
| Type |Length | must be zero | IPv4 Address |
+-------+-------+-------+-------+-------+-------+-------+-------+
+-------+-------+-------+-------+-------+-------+-------+-------+ | タイプ|長さ| ゼロでなければなりません。| IPv4アドレス| +-------+-------+-------+-------+-------+-------+-------+-------+
Type:
1 for Source Link-layer address.
2 for Target Link-layer address.
以下をタイプしてください。 1 Source Link-層のアドレスのために。 2 Target Link-層のアドレスのために。
Length:
1 (in units of 8 octets).
長さ: 1 (8つの八重奏のユニットの。)
IPv4 Address:
IPv4アドレス:
The 32 bit IPv4 address, in network byte order. This is the address the interface currently responds to, and may be different from the Interface Identifier for stateless autoconfiguration.
32はネットワークバイトオーダーにおけるIPv4アドレスに噛み付きました。 これは、インタフェースが現在応じるアドレスであり、状態がない自動構成において、Interface Identifierと異なっているかもしれません。
6. Address Mapping -- Multicast
6. アドレス・マッピング--マルチキャスト
IPv4 multicast MUST be available. An IPv6 packet with a multicast destination address DST MUST be transmitted to the IPv4 multicast address of Organization-Local Scope using the mapping below. These IPv4 multicast addresses SHOULD be taken from the block
IPv4マルチキャストは利用可能であるに違いありません。 マルチキャスト送付先アドレスDST MUSTが以下のマッピングを使用するOrganization地方のScopeのIPv4マルチキャストアドレスに伝えられているIPv6パケット。 これらのIPv4マルチキャストがSHOULDを扱う、ブロックから、取ってください。
Carpenter & Jung Standards Track [Page 4] RFC 2529 Transmission of IPv6 Packets over IPv4 March 1999
IPv4 March 1999の上のIPv6パケットの大工とユング標準化過程[4ページ]RFC2529トランスミッション
239.192.0.0/16, a sub-block of the Organization-Local Scope address block, or, if all of those are not available, from the expansion blocks defined in [ADMIN]. Note that when they are formed using the expansion blocks, they use only a /16 sized block.
239.192.0.0/16、または、それらのすべてが利用可能であるというわけではないなら、Organization地方のサブブロックScopeはブロックを扱います、[ADMIN]で定義された拡張ブロックから。 拡張ブロックを使用することで形成されるとき、/16大きさで分けられたブロックだけ、を使用することに注意してください。
+-------+-------+-------+-------+
| 239 | OLS | DST14 | DST15 |
+-------+-------+-------+-------+
+-------+-------+-------+-------+ | 239 | OLS| DST14| DST15| +-------+-------+-------+-------+
DST14, DST15 last two bytes of IPv6 multicast address.
DST14、DST15は2バイトのIPv6マルチキャストアドレスを持続します。
OLS from the configured Organization-Local
Scope address block. SHOULD be 192,
see [ADMIN] for details.
構成されたOrganization地方のScopeからのOLSはブロックを扱います。 SHOULDは192歳であり、詳細に関して[ADMIN]を見ます。
No new IANA registration procedures are required for the above. See appendix A. for a list of all the multicast groups that must be joined to support Neighbor Discovery.
どんな新しいIANA登録手順も上記で必要ではありません。 Neighborがディスカバリーであるとサポートするために加わらなければならないすべてのマルチキャストグループのリストに関して付録A.を見てください。
7. Scaling and Transition Issues
7. スケーリングと変遷問題
The multicast mechanism described in Section 6 above appears to have essentially the same scaling properties as native IPv6 over most media, except for the slight reduction in MTU size which will slightly reduce bulk throughput. On an ATM network, where IPv4 multicast relies on relatively complex mechanisms, it is to be expected that IPv6 over IPv4 over ATM will perform less well than native IPv6 over ATM.
上のセクション6で説明されたマルチキャストメカニズムはほとんどのメディアの上に本質的にはネイティブのIPv6と同じスケーリング特性を持っているように見えます、大量のスループットをわずかに減らすMTUサイズのわずかな減少を除いて。 ATMネットワークでは、ATMの上のIPv4の上のIPv6がATMの上でそれほどネイティブのIPv6よりよくない働かないと予想されることになっています。そこでは、IPv4マルチキャストが比較的複雑なメカニズムを当てにします。
The "IPv6 over IPv4" mechanism is intended to take its place in the range of options available for transition from IPv4 to IPv6. In particular it allows a site to run both IPv4 and IPv6 in coexistence, without having to configure IPv6 hosts either with IPv4-compatible addresses or with tunnels. Interfaces of the IPv6 router and hosts will of course need to be enabled in "6over4" mode.
「IPv4"メカニズムの上のIPv6がIPv4からIPv6までの変遷に利用可能な選択の範囲で代わりをすることを意図します。」 特に、サイトはそれで共存でIPv4とIPv6の両方を実行できます、IPv4コンパチブルアドレスかトンネルでIPv6ホストを構成する必要はなくて。 IPv6ルータとホストのインタフェースは、もちろん「6over4"モード」で可能にされる必要があるでしょう。
A site may choose to start its IPv6 transition by configuring one IPv6 router to support "6over4" on an interface connected to the site's IPv4 domain, and another IPv6 format on an interface connected to the IPv6 Internet. Any enabled "6over4" hosts in the IPv4 domain will then be able to communicate both with the router and with the IPv6 Internet, without manual configuration of a tunnel and without the need for an IPv4-compatible IPv6 address, either stateless or stateful address configuration providing the IPv6 address to the IPv6 host.
サイトは、「IPv6インターネットに関連しているインタフェースでサイトのIPv4ドメイン、および別のIPv6形式に関連しているインタフェースの6over4"」をサポートするために1つのIPv6ルータを構成することによってIPv6変遷を始めるのを選ぶかもしれません。 いずれ「IPv4ドメインの6over4"ホストはその時、ルータとIPv6インターネットでトンネルの手動の構成なしでIPv4コンパチブルIPv6アドレス、IPv6がIPv6ホストに扱う状態がないかstatefulなアドレス構成提供の必要性なしで交信できるでしょう」可能にされた。
Carpenter & Jung Standards Track [Page 5] RFC 2529 Transmission of IPv6 Packets over IPv4 March 1999
IPv4 March 1999の上のIPv6パケットの大工とユング標準化過程[5ページ]RFC2529トランスミッション
During transition, routers may need to advertise at least two IPv6 prefixes, one for the native LAN (e.g. Ethernet) and one for "6over4". As with any IPv6 prefix assigned to an IPv6 subnet, the latter MUST be unique within its scope, whether site-local or global addressing is used.
変遷の間、ルータは、少なくとも2つのIPv6接頭語、ネイティブのLAN(例えば、イーサネット)のためのもの、および"6over4""のための1つの広告を出す必要があるかもしれません。 何かIPv6接頭語がIPv6サブネットに割り当てられている場合、後者は範囲の中でユニークであるに違いありません、サイト地方の、または、グローバルなアドレシングが使用されているか否かに関係なく。
Also note that when a router is handling both native LAN and "6over4" on the same physical interface, during stateless autoconfiguration, there is a period when IPv6 link-local addresses are used, in both cases with the prefix FE80::/64. Note that the prefix-length for these link-local adddress MUST then be 128 so that the two cases can be distinguished.
ルータであるときにともにネイティブのLANを扱っている注意とも「同じ物理インターフェースの6over4"、状態がない自動構成の間、IPv6のリンクローカルのアドレスが使用されている、コネが接頭語FE80と共に以下をともにケースに入れる期間があります」。/64. これらのリンク地方のadddressのための接頭語長さがそしてときに2つのケースを区別できるための128でなければならないことに注意してください。
As the site installs additional IPv6 routers, "6over4" hosts which become physically adjacent to IPv6 routers can be changed to run as native IPv6 hosts, with the the only impact on IPv6 applications being a slight increase in MTU size. At some stage during transition, it might be convenient to dual home hosts in both native LAN and "6over4" mode, but this is not required.
サイトが追加IPv6ルータをインストールするのに従って「ネイティブのIPv6ホストとして稼働するために物理的にIPv6ルータに隣接してなる6over4"ホストは変えることができます、IPv6アプリケーションでのMTUサイズのわずかな増加である唯一の影響で」。 変遷の間の何らかの段階では、ネイティブのLANと「6over4"モード、これだけは必要でないこと」の両方の二元的なホームホストはそれが都合がよいかもしれません。
8. IANA Considerations
8. IANA問題
No assignments by the IANA are required beyond those in [ADMIN].
IANAによる課題は全く[ADMIN]のそれらを超えて必要ではありません。
9. Security Considerations
9. セキュリティ問題
Implementors should be aware that, in addition to posssible attacks against IPv6, security attacks against IPv4 must also be considered. Use of IP security at both IPv4 and IPv6 levels should nevertheless be avoided, for efficiency reasons. For example, if IPv6 is running encrypted, encryption of IPv4 would be redundant except if traffic analysis is felt to be a threat. If IPv6 is running authenticated, then authentication of IPv4 will add little. Conversely, IPv4 security will not protect IPv6 traffic once it leaves the IPv6-over- IPv4 domain. Therefore, implementing IPv6 security is required even if IPv4 security is available.
作成者はまた、IPv6に対するposssible攻撃に加えてIPv4に対するセキュリティー攻撃を考えなければならないのを意識しているべきです。 それにもかかわらず、IPv4とIPv6レベルの両方におけるIPセキュリティの使用は効率理由で避けられるべきです。 例えば、IPv6が暗号化されていた状態で稼働する予定であるなら、IPv4の暗号化は、脅威であるためにはトラヒック分析であるのを除いて、余分であるのが、フェルトであるということでしょう。 IPv6が認証されていた状態で稼働する予定であると、IPv4の認証は少ししか加えないでしょう。 IPv6がいったん残っていると逆に、IPv4セキュリティがIPv6トラフィックを保護しない、-、過剰IPv4ドメイン。 したがって、IPv4セキュリティが利用可能であっても、IPv6がセキュリティであると実装するのが必要です。
There is a possible spoofing attack in which spurious 6over4 packets are injected into a 6over4 domain from outside. Thus, boundary routers MUST discard multicast IPv4 packets with source or destination multicast addresses of organisation local scope as defined in section 6 above, if they arrive on physical interfaces outside that scope. To defend against spurious unicast 6over4 packets, boundary routers MUST discard incoming IPv4 packets with protocol type 41 from unknown sources, i.e. IPv6-in-IPv4 tunnels must only be accepted from trusted sources. Unless IPSEC
偽りの6over4パケットが外部から6over4ドメインに注がれる可能なスプーフィング攻撃があります。 したがって、セクション6の定義されるとしての機構の地方の範囲のソースか送付先マルチキャストアドレスが上で境界ルータはマルチキャストIPv4パケットを捨てなければなりません、その範囲の外の物理インターフェースで到着するなら。 偽りのユニキャスト6over4パケットに対して防御するために、境界ルータは未知の情報源からプロトコルタイプ41で入って来るIPv4パケットを捨てなければなりません、すなわち、信頼できるソースからIPv4のIPv6トンネルを受け入れるだけでよいです。 IPSEC
Carpenter & Jung Standards Track [Page 6] RFC 2529 Transmission of IPv6 Packets over IPv4 March 1999
IPv4 March 1999の上のIPv6パケットの大工とユング標準化過程[6ページ]RFC2529トランスミッション
authentication is available, the RECOMMENDED technique for this is to configure the boundary router only to accept protocol type 41 packets from source addresses within a trusted range or ranges.
認証が利用可能である、これのためのRECOMMENDEDのテクニックが境界ルータを構成することですが、信じられた範囲か範囲の中のソースアドレスからプロトコルタイプ41パケットを受け入れます。
Acknowledgements
承認
The basic idea presented above is not original, and we have had invaluable comments from Matt Crawford, Steve Deering, Dan Harrington, Rich Draves, Erik Nordmark, Quang Nguyen, Thomas Narten, and other members of the IPNG and NGTRANS working groups.
上に提示された基本的な考え方は独創的ではありません、そして、私たちには、マット・クロフォード、スティーブ・デアリング、ダン・ハリントンからの非常に貴重なコメントがありました、リッシュDraves、エリックNordmark、Quang Nguyen、IPNGとNGTRANSワーキンググループのトーマスNartenの、そして、他のメンバー。
This document is seriously ripped off from RFC 1972 written by Matt Crawford. Brian Carpenter was at CERN when the work was started.
マット・クロフォードによって書かれたRFC1972からこのドキュメントを真剣に盗みます。 仕事が始められたとき、ブライアンCarpenterがCERNにありました。
References
参照
[AARCH] Hinden, R., and S. Deering, "IP Version 6 Addressing
Architecture", RFC 2373, July 1998.
[AARCH] Hinden、R.とS.デアリング、「IPバージョン6アドレッシング体系」、RFC2373、1998年7月。
[ADMIN] Meyer, D., "Administratively Scoped IP Multicast", BCP 23,
RFC 2365, July 1998.
[アドミン] マイヤー、D.、「行政上見られたIPマルチキャスト」、BCP23、RFC2365、1998年7月。
[CONF] Thomson, S. and T. Narten, "IPv6 Stateless Address
Autoconfiguration", RFC 2462, December 1998.
[CONF] トムソンとS.とT.Narten、「IPv6の状態がないアドレス自動構成」、RFC2462、1998年12月。
[DISC] Narten, T., Nordmark, E. and W. Simpson, "Neighbor
Discovery for IP Version 6 (IPv6)", RFC 2461, December
1998.
[ディスク]NartenとT.とNordmarkとE.とW.シンプソン、「IPバージョン6(IPv6)のための隣人発見」、RFC2461、1998年12月。
[IPV6] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, December 1998.
[IPV6]デアリング、S.とR.Hinden、「インターネットプロトコル、バージョン6(IPv6)仕様」、RFC2460、12月1998日
[RFC 791] Postel, J., "Internet Protocol", STD 5, RFC 791, September
1981.
[RFC791] ポステル、J.、「インターネットプロトコル」、STD5、RFC791、1981年9月。
[RFC 1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., de Groot, G.
and E. Lear, "Address Allocation for Private Internets",
RFC 1918, February 1996.
[RFC1918] Rekhter(Y.、マスコウィッツ、R.、Karrenberg、D.、deグルート、G.、およびE.リア)は「個人的なインターネットのための配分を扱います」、RFC1918、1996年2月。
[RFC 1933] Gilligan, R. and E. Nordmark, "Transition Mechanisms for
IPv6 Hosts and Routers", RFC 1933, April 1996.
[RFC1933] ギリガンとR.とE.Nordmark、「IPv6ホストとルータのための変遷メカニズム」、RFC1933、1996年4月。
[RFC 2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[RFC 1972] Crawford, M., "A Method for the Transmission of IPv6
Packets over Ethernet Networks", RFC 1972, August 1996.
[RFC1972] クロフォード、M.、「イーサネットネットワークの上のIPv6パケットのトランスミッションのためのメソッド」、RFC1972、1996年8月。
Carpenter & Jung Standards Track [Page 7] RFC 2529 Transmission of IPv6 Packets over IPv4 March 1999
IPv4 March 1999の上のIPv6パケットの大工とユング標準化過程[7ページ]RFC2529トランスミッション
APPENDIX A: IPv4 Multicast Addresses for Neighbor Discovery
付録A: 隣人発見のためのIPv4マルチキャストアドレス
The following IPv4 multicast groups are used to support Neighbor Discovery with this specification. The IPv4 addresses listed in this section were obtained by looking at the IPv6 multicast addresses that Neigbour Discovery uses, and deriving the resulting IPv4 "virtual link-layer" addresses that are generated from them using the algorithm given in Section 6.
以下のIPv4マルチキャストグループは、Neighborがディスカバリーであるとこの仕様でサポートするのに使用されます。 Neigbourディスカバリーが使用するIPv6マルチキャストアドレスを見て、それらからセクション6で与えられたアルゴリズムを使用することで作られる結果として起こるIPv4「仮想のリンクレイヤ」アドレスを引き出すことによって、このセクションで記載されたIPv4アドレスを得ました。
all-nodes multicast address
- the administratively-scoped IPv4 multicast address used to
reach all nodes in the local IPv4 domain supporting this
specification. 239.OLS.0.1
オールノードマルチキャストアドレス--行政上見られたIPv4マルチキャストアドレスは、以前はこの仕様をサポートしながら、地方のIPv4ドメインでよくすべてのノードに達していました。 239. OLS.0.1
all-routers multicast address
- the administratively-scoped IPv4 multicast address to reach
all routers in the local IPv4 domain supporting this
specification. 239.OLS.0.2
オールルータマルチキャストアドレス--この仕様をサポートしながら地方のIPv4ドメインですべてのルータに達する行政上見られたIPv4マルチキャストアドレス。 239. OLS.0.2
solicited-node multicast address
- an administratively scoped multicast address that is computed
as a function of the solicited target's address by taking the
low-order 24 bits of the IPv4 address used to form the IPv6
address, and prepending the prefix FF02:0:0:0:0:1:FF00::/104
[AARCH]. This is then mapped to the IPv4 multicast address by
the method described in this document. For example, if the
IPv4 address used to form the IPv6 address is W.X.Y.Z, then
the IPv6 solicited node multicast address is
FF02::1:255.X.Y.Z and the corresponding IPv4 multicast
address is 239.OLS.Y.Z
請求されたノードマルチキャストアドレス--IPv4アドレスの下位の24ビット取るのによる請求された目標のアドレスの機能が以前はよくIPv6アドレスを形成していたので計算されて、接頭語FF02をprependingしている行政上見られたマルチキャストアドレス:、0:0:1 0:0::FF00、:、:/104[AARCH]。 そして、これは本書では説明されたメソッドでIPv4マルチキャストアドレスに写像されます。 例えば、IPv6アドレスを形成するのに使用されるIPv4アドレスがW.X.Y.Zであるなら、請求されたノードマルチキャストが扱うIPv6はFF02です:、:1: 255.X.Y.Zと対応するIPv4マルチキャストアドレスは239.OLS.Y.Zです。
Carpenter & Jung Standards Track [Page 8] RFC 2529 Transmission of IPv6 Packets over IPv4 March 1999
IPv4 March 1999の上のIPv6パケットの大工とユング標準化過程[8ページ]RFC2529トランスミッション
Authors' Addresses
作者のアドレス
Brian E. Carpenter Internet Division IBM United Kingdom Laboratories MP 185, Hursley Park Winchester, Hampshire S021 2JN, UK
mp185、ブライアンE.大工インターネット事業部IBMイギリスの研究所Hursley Parkウィンチェスター、ハンプシャーS021 2JNイギリス
EMail: brian@hursley.ibm.com
メール: brian@hursley.ibm.com
Cyndi Jung 3Com Corporation 5400 Bayfront Plaza, Mailstop 3219 Santa Clara, California 95052-8145
シンディユング3Com社5400のBayfront広場、サンタクララ、Mailstop3219カリフォルニア95052-8145
EMail: cmj@3Com.com
メール: cmj@3Com.com
Carpenter & Jung Standards Track [Page 9] RFC 2529 Transmission of IPv6 Packets over IPv4 March 1999
IPv4 March 1999の上のIPv6パケットの大工とユング標準化過程[9ページ]RFC2529トランスミッション
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (1999). All Rights Reserved.
Copyright(C)インターネット協会(1999)。 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 assigns.
上に承諾された限られた許容は、永久であり、インターネット協会、後継者または案配によって取り消されないでしょう。
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.
このドキュメントとそして、「そのままで」という基礎とインターネットの振興発展を目的とする組織に、インターネット・エンジニアリング・タスク・フォースが速達の、または、暗示しているすべての保証を放棄するかどうかというここにことであり、他を含んでいて、含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Carpenter & Jung Standards Track [Page 10]
大工とユング標準化過程[10ページ]
一覧
スポンサーリンク
