Posted at

[Joke-RFC] RFC6214 IPv6 への RFC 1149 の適用


はじめに


  • この文書は RFC6214 を勉強と好奇心のため適当に訳したものです。

  • 翻訳の正確さは全く保証しません。

  • 誤字誤訳等の指摘はいつでも大歓迎です。


Adaptation of RFC 1149 for IPv6(IPv6 への RFC 1149 の適用)


  • Independent Submission

  • Request for Comments: 6214

  • Category: Informational

  • ISSN: 2070-1721


  • B. Carpenter Univ. of Auckland


  • R. Hinden Check Point Software


  • 1 April 2011



Abstract(概要)


This document specifies a method for transmission of IPv6 datagrams

over the same medium as specified for IPv4 datagrams in RFC 1149.


このドキュメントは RFC 1149 で IPv4 データグラムのために指定されるのと同じ媒体の上の IPv6 データグラムの伝送のための方法を指定します。


Status of This Memo(このメモの位置づけ)


This document is not an Internet Standards Track specification; it is

published for informational purposes.


この文書はインターネット標準ではありません。 情報提供を目的として公開されています。


This is a contribution to the RFC Series, independently of any other

RFC stream. The RFC Editor has chosen to publish this document at

its discretion and makes no statement about its value for

implementation or deployment. Documents approved for publication by

the RFC Editor are not a candidate for any level of Internet

Standard; see Section 2 of RFC 5741.


(略)


Information about the current status of this document, any errata,

and how to provide feedback on it may be obtained at

http://www.rfc-editor.org/info/rfc6214.


(略)


Copyright Notice


Copyright (c) 2011 IETF Trust and the persons identified as the

document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal

Provisions Relating to IETF Documents

(http://trustee.ietf.org/license-info) in effect on the date of

publication of this document. Please review these documents

carefully, as they describe your rights and restrictions with respect

to this document.


(略)


Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 2

2. Normative Notation . . . . . . . . . . . . . . . . . . . . . . 2
3. Detailed Specification . . . . . . . . . . . . . . . . . . . . 2
3.1. Maximum Transmission Unit . . . . . . . . . . . . . . . . . 2
3.2. Frame Format . . . . . . . . . . . . . . . . . . . . . . . 3
3.3. Address Configuration . . . . . . . . . . . . . . . . . . . 3
3.4. Multicast . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Quality-of-Service Considerations . . . . . . . . . . . . . . . 4
5. Routing and Tunneling Considerations . . . . . . . . . . . . . 4
6. Multihoming Considerations . . . . . . . . . . . . . . . . . . 5
7. Internationalization Considerations . . . . . . . . . . . . . . 5
8. Security Considerations . . . . . . . . . . . . . . . . . . . . 5
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 5
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6
11.1. Normative References . . . . . . . . . . . . . . . . . . . 6
11.2. Informative References . . . . . . . . . . . . . . . . . . 6


1. Introduction(はじめに)

As shown by [RFC6036], many service providers are actively planning

to deploy IPv6 to alleviate the imminent shortage of IPv4 addresses.

This will affect all service providers who have implemented

[RFC1149]. It is therefore necessary, indeed urgent, to specify a

method of transmitting IPv6 datagrams [RFC2460] over the RFC 1149

medium, rather than obliging those service providers to migrate to a

different medium. This document offers such a specification.

[RFC6036] によって示されるように、多くのサービスプロバイダーは差し迫っている IPv4 アドレスの不足を軽減するために積極的にIPv6を展開することを計画しています。

これは [RFC1149] を実装したすべてのサービスプロバイダーに影響を及ぼします。

したがって、これらのサービスプロバイダに別のメディアへの移行を義務付けるのではなく、RFC 1149 メディアを介して IPv6 データグラム [RFC 2460] を送信する方法を指定することが実際には緊急に必要です。

このドキュメントはそのような仕様を提供します。


2. Normative Notation


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].


(略)


3. Detailed Specification(詳細仕様)


Unless otherwise stated, the provisions of [RFC1149] and [RFC2460]

apply throughout.


特に明記のない限り、[RFC1149] と [RFC2460] の規定は全体を通して適用されます。


3.1. Maximum Transmission Unit(最大伝送単位)


As noted in RFC 1149, the MTU is variable, and generally increases

with increased carrier age. Since the minimum link MTU allowed by

RFC 2460 is 1280 octets, this means that older carriers MUST be used

for IPv6. RFC 1149 does not provide exact conversion factors between

age and milligrams, or between milligrams and octets. These

conversion factors are implementation dependent, but as an

illustrative example, we assume that the 256 milligram MTU suggested

in RFC 1149 corresponds to an MTU of 576 octets. In that case, the

typical MTU for the present specification will be at least

256*1280/576, which is approximately 569 milligrams. Again as an

illustrative example, this is likely to require a carrier age of at

least 365 days.


RFC 1149 に記載されているように、MTU は可変であり、一般にキャリアの経過時間とともに増加します。

RFC 2460 で許可されている最小リンクMTUは 1280 オクテットであるため、これは IPv6 では古いキャリアをしようしなければならないことを意味します。

RFC 1149 では、経過時間とミリグラムの間、またミリグラムとオクテットの間の正確な変換係数は提示されていません。

これらの変換係数は実装に依存しますが、実例として、RFC 1149 で推奨されている 256 ミリグラムの MTU は 576 オクテットの MTU に対応すると仮定します。

その場合、本仕様の典型的な MTU は少なくとも 256*1280/576 となり、これは約 569 ミリグラムである。

ここでも実例として、少なくとも 365 日のキャリア経過時間を必要とする可能性が高いです。


Furthermore, the MTU issues are non-linear with carrier age. That

is, a young carrier can only carry small payloads, an adult carrier

can carry jumbograms [RFC2675], and an elderly carrier can again

carry only smaller payloads. There is also an effect on transit time

depending on carrier age, affecting bandwidth-delay product and hence

the performance of TCP.


さらに、MTU のこの問題は、キャリアの経過時間とは非線形です。

すなわち、経過時間の少ないキャリアは小さなペイロードしか運ぶことができないが、経過時間の多いキャリアはジャンボグラム[RFC2675] を運ぶことができ、そして経過時間の非常に長いキャリアは再び小さなペイロードしか運ぶことができません。

これは、キャリア経過時間に応じて転送時間が変わり、、帯域幅遅延に影響し、したがってTCPのパフォーマンスに影響します。


3.2. Frame Format(フレームフォーマット)


RFC 1149 does not specify the use of any link layer tag such as an

Ethertype or, worse, an OSI Link Layer or SNAP header [RFC1042].

Indeed, header snaps are known to worsen the quality of service

provided by RFC 1149 carriers. In the interests of efficiency and to

avoid excessive energy consumption while packets are in flight

through the network, no such link layer tag is required for IPv6

packets either. The frame format is therefore a pure IPv6 packet as

defined in [RFC2460], encoded and decoded as defined in [RFC1149].


RFC 1149は、Ethertype やさらには OSI Link Layer や SNAP ヘッダ [RFC1042] などのリンクレイヤタグの使用について指定していません。

実際、ヘッダースナップ(※頭を切り取ること?)は、RFC 1149 キャリアによって提供されるサービス品質を悪化させることが知られています。

効率の観点から、そしてパケットがネットワークを通過している間の過度のエネルギー消費を避けるために、そのようなリンク層タグは IPv6 パケットに対しても必要とされない。

それゆえフレームフォーマットは [RFC 2460] で定義されているように純粋な IPv6 パケットであり、[RFC 1149] で定義されているようにエンコードされ、デコードされる。


One important consequence of this is that in a dual-stack deployment

[RFC4213], the receiver MUST inspect the IP protocol version number

in the first four bits of every packet, as the only means to

demultiplex a mixture of IPv4 and IPv6 packets.


これによる 1 つの重要な結果はデュアルスタックデプロイ [RFC4213] では、IPv4 と IPv6 パケットの混合を逆多重化する唯一の手段として、受信側はすべてのパケットの最初の 4 ビットで IP プロトコルバージョン番号を調べなければならないということです。


3.3. Address Configuration(アドレス設定)


The lack of any form of link layer protocol means that link-local

addresses cannot be formed, as there is no way to address anything

except the other end of the link.


リンク層プロトコルの形式がないということは、リンクのもう一方の端以外にアドレスを指定する方法がないため、リンクローカルアドレスを形成できないことを意味します。


Similarly, there is no method to map an IPv6 unicast address to a

link layer address, since there is no link layer address in the first

place. IPv6 Neighbor Discovery [RFC4861] is therefore impossible.


同様に、IPv6 ユニキャストアドレスをリンク層アドレスにマッピングする方法はありません。

そもそもリンク層アドレスがないからです。

したがって、IPv6近隣探索 [RFC4861] は不可能です。


Implementations SHOULD NOT even try to use stateless address auto-

configuration [RFC4862]. This recommendation is because this

mechanism requires a stable interface identifier formed in a way

compatible with [RFC4291]. Unfortunately the transmission elements

specified by RFC 1149 are not generally stable enough for this and

may become highly unstable in the presence of a cross-wind.


実装はステートレスアドレス自動設定 [RFC4862] を使用しようとさえすべきではありません(SHOULD NOT)。

それはこのメカニズムが [RFC4291] と互換性のある方法で形成された安定したインタフェース識別子を必要とするからです。

残念ながら、RFC 1149 で指定されている伝送要素は一般的に十分に安定しているわけではなく、横風があると非常に不安定になる可能性があります。


In most deployments, either the end points of the link remain

unnumbered, or a /127 prefix and static addresses MAY be assigned.

See [IPv6-PREFIXLEN] for further discussion.


ほとんどの展開では、リンクのエンドポイントは番号付けされていないままか、

または /127 プレフィックスと静的アドレスが割り当てられる場合があります。

さらなる議論については[IPv6-PREFIXLEN]を見てください。


3.4. Multicast(マルチキャスト)


RFC 1149 does not specify a multicast address mapping. It has been

reported that attempts to implement IPv4 multicast delivery have

resulted in excessive noise in transmission elements, with subsequent

drops of packet digests. At the present time, an IPv6 multicast

mapping has not been specified, to avoid such problems.


RFC 1149 ではマルチキャストアドレスマッピングを指定していません。

IPv4 マルチキャスト配信を実装しようとすると、送信要素に過剰なノイズが発生し、その後にパケットダイジェストがドロップされることが報告されています。

現在のところ、このような問題を回避するために、IPv6マルチキャストマッピングは指定されていません。


4. Quality-of-Service Considerations(サービス品質について)


[RFC2549] is also applicable in the IPv6 case. However, the author

of RFC 2549 did not take account of the availability of the

Differentiated Services model [RFC2474]. IPv6 packets carrying a

non-default Differentiated Services Code Point (DSCP) value in their

Traffic Class field [RFC2460] MUST be specially encoded using green

or blue ink such that the DSCP is externally visible. Note that red

ink MUST NOT be used to avoid confusion with the usage of red paint

specified in RFC 2549.


[RFC 2549] は IPv6 の場合にも適用可能です。

しかしながら、RFC 2549 の作者は、Differentiated Servicesモデル [RFC 2474] の有用性を考慮に入れていません。

Traffic Classフィールド [RFC 2460] にデフォルト以外の DSCP 値を持つ IPv6 パケットは、DSCP が外部から見えるように、緑色または青色のインクを使用して特別に符号化されなければなりません。

赤のインクは、RFC 2549 で規定されている赤の塗料の使用との混同を避けるために使用してはいけないことに注意してください。


RFC 2549 did not consider the impact on quality of service of

different types of carriers. There is a broad range. Some are very

fast but can only carry small payloads and transit short distances,

others are slower but carry large payloads and transit very large

distances. It may be appropriate to select the individual carrier

for a packet on the basis of its DSCP value. Indeed, different

carriers will implement different per-hop behaviors according to RFC

2474.


RFC 2549 は、異なる種類のキャリアのサービス品質への影響を考慮していませんでした。

それは広い範囲があります。

いくつかは非常に速いですが小さいペイロードを、短い距離を伝送できるだけですが、

他はより遅いが大きいペイロードを、非常に長い距離を伝送できます。

その DSCP 値に基づいてパケットのための個々のキャリアを選択することは適切であるかもしれません。

確かに、RFC 2474 によれば、キャリアが異なればホップごとの動作も異なります。


5. Routing and Tunneling Considerations(ルーティングとトンネリングについて)


Routing carriers through the territory of similar carriers, without

peering agreements, will sometimes cause abrupt route changes,

looping packets, and out-of-order delivery. Similarly, routing

carriers through the territory of predatory carriers may potentially

cause severe packet loss. It is strongly recommended that these

factors be considered in the routing algorithm used to create carrier

routing tables. Implementers should consider policy-based routing to

ensure reliable packet delivery by routing around areas where

territorial and predatory carriers are prevalent.


ピアリング契約なしで、類似のキャリアの領空を経由してキャリアをルーティングすると、突然の経路変更、パケットのループ、および順不同配信が発生することがあります。

同様に、捕食キャリアの領空を介してキャリアをルーティングすると、深刻なパケット損失が発生する可能性があります。

キャリアルーティングテーブルの作成に使用されるルーティングアルゴリズムでは、これらの要素を考慮することを強くお勧めします。

実装者は、領空問題や捕食キャリアが多いエリア付近をルーティングする場合には、信頼性の高いパケット配信を確保するために、ポリシーベースのルーティングを考慮する必要があります。


There is evidence that some carriers have a propensity to eat other

carriers and then carry the eaten payloads. Perhaps this provides a

new way to tunnel an IPv4 packet in an IPv6 payload, or vice versa.


一部のキャリアは他のキャリアを食べて、その後食べられたペイロードを運ぶ傾向があるという証拠があります。

おそらくこれは、IPv6ペイロードでIPv4パケットをトンネリングする、またはその逆の新しい方法を提供します。


However, the decapsulation mechanism is unclear at the time of this

writing.


ただし、この文書の執筆時点では、カプセル化解除メカニズムは不明です。


6. Multihoming Considerations(マルチホームについて)


Some types of carriers are notoriously good at homing. Surprisingly,

this property is not mentioned in RFC 1149. Unfortunately, they

prove to have no talent for multihoming, and in fact enter a routing

loop whenever multihoming is attempted. This appears to be a

fundamental restriction on the topologies in which both RFC 1149 and

the present specification can be deployed.


いくつかの種類のキャリアは、ホーミングが得意です。

驚くべきことに、このプロパティは RFC 1149 には記載されていません。

残念ながら、マルチホーミング機能がないことが証明されており、実際にはマルチホーミングが試みられるたびにルーティングループに入ります。

これは、RFC 1149 と現在の仕様の両方のデプロイできるトポロジに対する基本的な制限のようです。


7. Internationalization Considerations(国際化について)


In some locations, such as New Zealand, a significant proportion of

carriers are only able to execute short hops, and only at times when

the background level of photon emission is extremely low. This will

impact the availability and throughput of the solution in such

locations.


たとえばニュージーランドのようないくつかの場所では、ほとんどのキャリアが短いホップしか実行ができず、それも光子放出のバックグラウンドレベルが極端に低い時にだけに限られる。

これは、そのような場所でのソリューションの可用性とスループットに影響を与えます。


8. Security Considerations


The security considerations of [RFC1149] apply. In addition, recent

experience suggests that the transmission elements are exposed to

many different forms of denial-of-service attacks, especially when

perching. Also, the absence of link layer identifiers referred to

above, combined with the lack of checksums in the IPv6 header,

basically means that any transmission element could be mistaken for

any other, with no means of detecting the substitution at the network

layer. The use of an upper-layer security mechanism of some kind

seems like a really good idea.


[RFC1149] のセキュリティ問題が適用されます。

さらに、最近の経験では、特に止まっているときに、伝送要素がさまざまな形式のサービス拒否攻撃にさらされることが示唆されています。

また、上記で言及したリンク層識別子の欠如は、IPv6 ヘッダ内のチェックサムの欠如と相まって、

基本的に、ネットワーク層で置換を検出する手段がなく、任意の送信要素を他の要素と間違える可能性があることを意味する。

ある種の上位層セキュリティメカニズムを使用することはよいアイデアです。


There is a known risk of infection by the so-called H5N1 virus.

Appropriate detection and quarantine measures MUST be available.


いわゆるH5N1ウイルスによる感染の既知のリスクがあります。

適切な検出と検疫措置が利用可能でなければなりません。


9. IANA Considerations


This document requests no action by IANA. However, registry clean-up

may be necessary after interoperability testing, especially if

multicast has been attempted.


この文書は IANA による行動を要求しない。

ただし、相互運用性テストの後、特にマルチキャストが試行された場合は、レジストリのクリーンアップが必要になることがあります。


10. Acknowledgements(謝辞)


Steve Deering was kind enough to review this document for conformance

with IPv6 requirements. We acknowledge in advance the many errata in

this document that will be reported by Alfred Hoenes.


Steve Deering のこの文書を IPv6 要件への適合性についてレビューについて感謝します。

この文書には、Alfred Hoenes 氏によって報告される予定の多くの正誤表がありますので、あらかじめご了承ください。


This document was produced using the xml2rfc tool [RFC2629].


このドキュメントはxml2rfcツール[RFC2629]を使用して作成されました。


11. References


11.1. Normative References

   [RFC1149]         Waitzman, D., "Standard for the transmission of IP

datagrams on avian carriers", RFC 1149, April 1990.

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.

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

[RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black,
"Definition of the Differentiated Services Field
(DS Field) in the IPv4 and IPv6 Headers", RFC 2474,
December 1998.

[RFC2675] Borman, D., Deering, S., and R. Hinden, "IPv6
Jumbograms", RFC 2675, August 1999.

[RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition
Mechanisms for IPv6 Hosts and Routers", RFC 4213,
October 2005.


11.2. Informative References

   [IPv6-PREFIXLEN]  Kohno, M., Nitzan, B., Bush, R., Matsuzaki, Y.,

Colitti, L., and T. Narten, "Using 127-bit IPv6
Prefixes on Inter-Router Links", Work in Progress,
October 2010.

[RFC1042] Postel, J. and J. Reynolds, "Standard for the
transmission of IP datagrams over IEEE 802
networks", STD 43, RFC 1042, February 1988.

[RFC2549] Waitzman, D., "IP over Avian Carriers with Quality
of Service", RFC 2549, April 1999.

[RFC2629] Rose, M., "Writing I-Ds and RFCs using XML",
RFC 2629, June 1999.

[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 4291, February 2006.

[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H.
Soliman, "Neighbor Discovery for IP version 6
(IPv6)", RFC 4861, September 2007.

[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6
Stateless Address Autoconfiguration", RFC 4862,
September 2007.

[RFC6036] Carpenter, B. and S. Jiang, "Emerging Service
Provider Scenarios for IPv6 Deployment", RFC 6036,
October 2010.


Authors' Addresses

   Brian Carpenter

Department of Computer Science
University of Auckland
PB 92019
Auckland, 1142
New Zealand

EMail: brian.e.carpenter@gmail.com

Robert M. Hinden
Check Point Software Technologies, Inc.
800 Bridge Parkway
Redwood City, CA 94065
US

Phone: +1.650.387.6118
EMail: bob.hinden@gmail.com
```