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

はじめに

• この文書は RFC6214 を勉強と好奇心のため適当に訳したものです。
  • ジョークRFCとしては一番有名なRFC1149 鳥類キャリアによるIPデータグラムの伝送規格 を IPv6 でも使えるようにするもののようです。
• 翻訳の正確さは全く保証しません。
• 誤字誤訳等の指摘はいつでも大歓迎です。

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: [e-mail]


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

   Phone: [phone]
   EMail: [e-mail]
```