はじめに

この文書は draft-lohsen-ip-burrito-00 を勉強と好奇心のため適当に訳したものです。
翻訳の正確さは全く保証しません。
誤字誤訳等の指摘はいつでも大歓迎です。

draft-lohsen-ip-burrito-00 は 2005 年 4 月 1 日（エイプリルフール）に発行された、internet-draft です。
internet-draft とは、一言でいえばインターネット RFC の草稿文書です(RFC にしない予定の物もあるみたいですが)。
内容を見てもらえばわかる通り、いわゆるジョーク RFC の仲間です。

IP over Burrito Carriers（ブリトーキャリアによる IP 伝送）

Network Working Group
Internet-Draft
April 1, 2005

Status of this Memo（このメモの位置づけ）

This memo defines an Experimental Protocol for the Internet community.
It does not specify an Internet standard of any kind.
Discussion and suggestions for improvement are requested.
Distribution of this memo is unlimited.

このメモでは、インターネットコミュニティのための実験的なプロトコルを定義する。
このメモは、いかなる種類のインターネット標準も規定しない。
議論と改善のための提案が求められている。
このメモの配布は無制限である。

   By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668.

   Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups.
   Note that other groups may also distribute working documents as Internet-Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time.
   It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html.

   This Internet-Draft will expire in October, 2005.

（略）

Copyright Notice

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

Abstract（要旨）

IP over Burrito Carriers describes an experimental method for the creation of edible data packets.
This standard is intended to be implemented in metropolitan area networks due to the preexisting burrito delivery infrastructure.
While currently only flour tortillas have been found acceptable for encapsulating the data contained in the packet, tests are underway to determine the viability of using corn tortillas.
One must be wary of disreputable IP over Burrito service providers as packet corruption and bad data handling can result in damage to the receiving unit and may result in an extremely messy packet rejection.
Conveniently, there is a rating system already in place.
While the rating by the health department doesn't ensure proper data encapsulation, it does allow the end user to determine if the service provider's quality to cost ratio is adequate.
This is an experimental standard, not a recommended standard.

IP over ブリトーキャリアは、食べられるデータパケットを作成する実験的な方法を説明する。
この規格は、既存のブリトー・デリバリー・インフラのために、メトロポリタン・エリア・ネットワークでの実装を意図している。
現在、パケットに含まれるデータのカプセル化には小麦粉のトルティーヤのみが許容されることが判明しているが、コーントルティーヤを使用した場合の可能性を判断するためのテストが進行中である。
パケットの破損やデータの扱いが悪いと、受信ユニットにダメージを与え、非常に面倒なパケット拒否を引き起こす可能性があるため、評判の悪い IP over ブリトーサービスプロバイダには注意しなければならない。
便利なことに、すでにレーティング制度がある。
保健所による格付けは、適切なデータのカプセル化を保証するものではないが、エンドユーザーは、サービスプロバイダーの品質対コスト比が適切かどうかを判断することができる。
これは実験的な規格であり、推奨される規格ではない。

Introduction（導入）

In today's wireless hotspot, WAP enabled, WiFi zoned world of dining there exists a discrimination against diners who prefer to eat outside the established confines of the restaurant.
The IP over Burrito standard was developed to create an edible solution to the growing rift in the availability of free internet access between sit-down and delivery/carry out diners.
While considerable research has yet to be performed on the IP over Burrito standard, multiple simulations in a controlled environment have proven to be both successful and filling.
Some concerns that must be addressed in the future include the ability of the hosts buffer to accommodate a large number of packets while they are processed.
Also the fact that a buffer overflow would cause a catastrophic system failure resulting in a purging of all previously processed datagrams is of major concern.
Currently datagrams are encapsulated in a flour tortilla.
Future projects will determine the viability of using corn tortillas but for now the standard requires the use of a flour tortilla for all datagram encapsulation.

今日の無線ホットスポット、WAP、WiFi の世界では、レストランの枠にとらわれない食事を好む人たちに対する差別が存在する。
IP over ブリトー規格は、レストランとデリバリー/キャリーアウトのレストランで無料インターネットアクセスの可用性に生じる溝を解消するために開発されたものである。
IP over ブリトー規格に関する研究はまだ十分に行われていないが、制御された環境での複数のシミュレーションは、成功し、かつ満足のいくものであることが証明されている。
今後の課題としては、ホスト側のバッファが大量のパケットを処理できるようにすることが挙げられる。
また、バッファのオーバーフローは、以前に処理されたすべてのデータグラムのパージにつながる壊滅的なシステム障害を引き起こすという事実が大きな懸念材料である。
現在、データグラムは小麦粉のトルティーヤでカプセル化されている。
将来のプロジェクトでコーントルティヤの使用可能性が決定されるが、現在のところ、規格ではすべてのデータグラムカプセル化に小麦粉トルティヤを使用することを要求している。

Packet Format（パケットフォーマット）

Packets will follow the standard Internet Header Format [RFC-791] (Figure 1).
Each field (Figure 1) has been sublimated with a tangible equivalent (Figure 2) to binary representation that is both tasty and filling.

パケットは標準的なインターネットヘッダー形式 [RFC-791] に従う (図1)。
各フィールド(図1)は、具体的な等価物(図2)を用いて、おいしさと充足感のある 2 進表現に昇華されている。

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |Version|  IHL  |Type of Service|          Total Length         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |         Identification        |Flags|      Fragment Offset    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Time to Live |    Protocol   |         Header Checksum       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Source Address                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    Destination Address                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                              Data                             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

               The Internet Header Format [RFC-791]

                              Figure 1.

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |Obvious|  Onion    |  Jalapenos  |    Physical Length (mm)     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Number Written on Foil      |Bean Type|  Number of Beans  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Given Delivery Time | Guacamole |       Receipt               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                             Lettuce                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                              Rice                             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                              Beef                             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                  The Burrito Internet Header Format

                              Figure 2.

Version: Obvious（バージョン：明白）

The Version field is indicated by the obvious.
It is a burrito.
As the IP over Burrito standard is designed to work solely with modern equipment, it supports only IPv4 packets.

Version のフィールドは、一目瞭然である。
それはブリトーである。
IP over ブリトー規格は最新の機器のみで動作するように設計されているため、IPv4 パケットのみをサポートしている。

IHL: Onion（IHL：玉ねぎ）

Internet Header Length is specified by the number of onions placed in the burrito.

インターネットヘッダ長は、ブリトーに入れられたタマネギの数で指定される。

Type of Service: Jalapenos（サービスの種類：ハラペーニョ）

The 8 bits of this header are specified by 8 jalapeno slices.
A half slice indicates a zero and a whole slice indicates a one.

このヘッダの 8 ビットは、8 枚のハラペーニョのスライスで指定されている。
半切りは 0 を、全切りは 1 を示す。

Total Length: Physical Burrito Length（全体の長さ：ブリトーの物理的な長さ）

The length of the burrito in centimeters multiplied by 4096 gives the total length of the datagram, in octets.

ブリトーの長さ (センチメートル) に 4096 を掛けたものが、データグラムの全体の長さ (オクテット) になる。

Identification: Number written on foil wrapper.（ID：ホイルに記載の番号）

（訳注：見出しのみ）

Flags: Type of Beans（フラグ：豆の種類）

Black Beans = Don't Fragment

Red Beans = Fragment

Pinto Beans = Last Fragment

Kidney Beans = More Fragments

ブラックビーンズ = フラグメンテーションを起こさない
レッドビーンズ = フラグメント
ピントビーンズ = 最後のフラグメント
キドニービーンズ = より多くのフラグメント

Fragment Offset: Total Number of Beans.（フラグメントオフセット：豆の総数）

（訳注：見出しのみ）

Time to Live: Specified by source host in minutes.（TTL：ソースホストによって分単位で指定）

Commonly in the range of 35-45 minutes, given traffic conditions.

送信元ホストから分単位で指定される。
交通状況を考慮し、35～45分程度が一般的である。

Protocol: Guacamole（プロトコル：ワカモレ）

The chunkiness, quality, and amount of Guacamole determine this data.

ワカモレのかたさ、質、量によってこのデータは決まる。

Header Checksum: Receipt（ヘッダーチェックサム：レシート）

The data on the receipt should match the specifications of the burrito datagram.

レシートのデータは、ブリトーのデータグラムの仕様と一致する必要がある。

Source Address: Lettuce（ソースアドレス：レタス）

Given the size of this field it is necessary to break it down into subsections.
The lettuce is placed in 4 discrete groups.
Also, the lettuce is colored with food coloring to be either red, green, or blue.
Red lettuce indicates the most significant digit, green the middle digit, and blue the least significant digit.
Thus limiting the amount of lettuce on the burrito to a manageable level in respect to determining the data and fitting in the tortilla.

このフィールドの大きさを考えると、サブセクションに分ける必要がある。
レタスは 4 つのグループにバラバラに配置されている。
また、レタスは食紅で赤、緑、青のいずれかに着色されている。
赤いレタスは最上位桁、緑は中位桁、青は最下位桁を示す。
こうして、ブリトーに載せるレタスの量を、データの判定とトルティーヤへの収まりに配慮して、管理しやすい量に制限している。

Destination Address: Rice（宛先アドレス：ライス）

Given the size of this field it is necessary to break it down into subsections.
The rice is placed in 4 discrete groups.
Also, the rice is colored with food coloring to be either red, green, or blue.
Red rice indicates the most significant digit, green the middle digit, and blue the least significant digit.
Thus limiting the amount of rice on the burrito to a manageable level in respect to determining the data and fitting in the tortilla.

このフィールドの大きさを考えると、サブセクションに分ける必要がある。
ライスは 4 つのグループに分かれて置かれている。
また、ライスは食用色素で赤、緑、青のいずれかに着色されている。
赤いライスは最上位桁、緑は中位桁、青は最下位桁を示す。
こうして、ブリトーに載せるライスの量を、データの判定とトルティーヤへの収まりに配慮して、扱いやすい量に抑えている。

Data: Beef（データ：ビーフ）

The data will be transmitted in a beef representation of hexadecimal.
Each beef cluster will be counted as a decimal representation of a hexadecimal digit.
Each beef field will be separated by a slice of chicken.
There will be a maximum of 15 chunks of beef and a minimum of 0 chunks of beef per unit chicken.
Approximately 16 bytes of data can be stored per burrito packet.

データは 16 進数のビーフ表現で送信される。
各ビーフのクラスタは、16 進数の 10 進表現としてカウントされる。
各ビーフのフィールドは、チキンのスライスで区切られる。
1 つのチキンにつき最大 15 個のビーフの塊があり、最小 0 個のビーフの塊がある。
1 つのブリトー・パケットには約 16 バイトのデータを格納することができる。

Packet Routing（パケットルーティング）

Should a node become damaged or congested (i.e. traffic jam, construction, etc) and be unable to accommodate Burrito encapsulated packets in a timely fashion then the packet will be routed by the delivery boy around any obstructions in an attempt to make a delivery inside of the packets given TTL.

ノードが損傷したり混雑したり（交通渋滞、工事など）して、ブリトーカプセル化パケットを適時に収容できない場合、パケットは配達少年によって障害物を回避して、パケットが与えられた TTL 内に配達できるように試みられる。

Security Considerations（セキュリティに関する考慮事項）

The IP over Burrito service can be considered secure for almost any non-tactical use.
Before transmission, the data contents of the packet are sterilized, killing most viruses that might be transmitted via the packet.
Unfortunately, due to the nature of the packet, this uninfected state is only temporary.
Unlike the current IP transmission standard, packets created by the IP over Burrito Carrier service are vulnerable to infection during transmission.
Infected packets will usually be detected two to four hours after the packet is destroyed.

IP over ブリトーサービスは、非戦術的な用途であれば、ほとんど安全であると考えることができる。
送信前に、パケットのデータコンテンツは殺菌され、パケット経由で感染する可能性のあるほとんどのウイルスを殺すことができる。
しかし残念ながら、パケットの性質上、この無感染状態は一時的なものに過ぎない。
現在の IP 伝送規格とは異なり、IP over ブリトーキャリアサービスで作成されたパケットは、伝送中に感染する可能性があるのだ。
感染したパケットは、通常、パケットが破壊されてから 2〜4 時間後に検出される。

As every packet is encapsulated in an opaque wrapper, the data inside the packet is impossible to access via standard packet sniffing procedures.
Attempts to breach the encapsulation of the package in transit will likely cause permanent damage to the encapsulation, thereby signaling to the original recipients of the packet that data interception was attempted.
Re-encapsulation of the original data is impossible, as the packet data is tightly integrated with the encapsulation.
Due to the long delay between packet transmission and packet reception, however, there is sufficient time for a third party to duplicate the packet data and forward it to the original recipient.
The detection of this interception is likely only if the recipient should follow the standard packet disposal process and be well acquainted with the peculiarities of packets created by a given server.

すべてのパケットは不透明な包み紙でカプセル化されているので、パケット内のデータは標準的なパケットスニッフィング手順でアクセスすることは不可能である。
輸送中のパッケージのカプセル化を破ろうとすると、おそらくカプセル化に永久的な損傷を与え、それによってパケットの元の受信者にデータの傍受が試みられたことを知らせることになる。
パケットデータはカプセル化と密接に統合されているため、元のデータを再カプセル化することは不可能である。
しかし、パケット送信から受信までの時間が長いため、第三者がパケットデータを複製し、元の受信者に転送することは十分可能である。
この傍受は、受信者が標準的なパケット廃棄プロセスに従い、特定のサーバーが作成するパケットの特殊性を熟知している場合にのみ検知される可能性がある。

Packet transportation uses a highly advanced algorithm to prevent damage to the packet and to prevent its reception by third parties.
As the packet transportation system is highly vulnerable to social engineering, however, the use of encryption is recommended for the transmission of any secure data.

パケット輸送では、パケットの破損や第三者による受信を防ぐため、高度なアルゴリズムが使用されている。
しかし、パケット通信はソーシャルエンジニアリングに対して非常に脆弱であるため、安全なデータの送信には暗号化の利用が推奨される。

Although the packets decay naturally over time, the slow rate of natural packet decay will likely make user-induced destruction mandatory to prevent third parties from examining the packet data after the packet has been received.
Unfortunately, the packet delivery system works poorly in a tactical environment, as the packet can be easily waylaid by hostile forces.

パケットは時間の経過とともに自然に減衰するが、パケットの自然減衰の速度が遅いため、パケット受信後に第三者がパケットデータを調べることを防ぐために、ユーザーによる破壊が必須となりそうである。
残念ながら、パケット配信システムは、敵対勢力によってパケットが簡単に横取りされてしまうため、戦術的な環境ではうまく機能しない。

Due to the extended time that packet creation requires, servers will be highly vulnerable to message flooding. and responses will be delayed greatly; however, the likeliness of a IP over Burrito DOS attack can be considered negligible, as the clients are charged for each packet that the server sends to them.

パケット作成に時間がかかるため、サーバーはメッセージフラッディングの影響を強く受け、応答が大幅に遅れる。しかし、IP over ブリトー DOS 攻撃の可能性は、サーバーからクライアントへのパケット送信ごとに課金されるため、無視できると考えてよい。

Of more concern is the extended time that packet processing requires on the receiving hosts end.
Should a host attempt to process more than 5 packets a in a one hour period a buffer overflow could occur and data might be lost, or worse: it could be disseminated in a disorganized and partially processed state all over any nearby objects.
This could result in damage to secondary systems and the server storage facility.
Unfortunately a buffer overflow on one host can cause hosts in the immediate vicinity to suffer similar buffer overflows.

さらに懸念されるのは、受信側のホストでパケットを処理するのに必要な時間が長くなることである。
もしホストが 1 時間に 5 個以上のパケットを処理しようとすると、バッファオーバーフローが起こり、データが失われる可能性がある。
その結果、セカンダリシステムやサーバーのストレージ設備に損害を与える可能性がある。
残念なことに、あるホストでバッファオーバーフローが発生すると、すぐ近くにあるホストにも同様のバッファオーバーフローが発生する可能性がある。

Also a matter of great concern is the ability of viruses to spread by IP over Burrito.
Should the server or packet itself be infected then infection of the host is highly likely.
When dealing with an unknown server it is advisable to carefully examine the packet for any sign of damage or infection (i.e. rotten smell, slick covering to the meat, etc).

また、ブリトー上の IP でウイルスが拡散することも懸念される。
サーバやパケット自体が感染している場合、そのホストに感染する可能性が高い。
未知のサーバーを扱う場合は、パケットにダメージや感染の兆候がないか注意深く調べることを勧める（例：腐った臭い、肉にぬめりがある、など）。

IANA Considerations（IANA に関する考慮事項）

This document has no actions for IANA.

本書は IANA に対するアクションはない。

Normative References

   [RFC791]  Postel, J., "Internet Protocol", STD 5, RFC 791, September
             1981.

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

   [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an
             IANA Considerations Section in RFCs", BCP 26, RFC 2434,
             October 1998.

Authors' Addresses

   Matthew Schulze
   Paragon Systems International
   1000 Windward Concourse Parkway, suite 140
   Alpharetta, GA, 30005

   EMail: Matthew.Schulze@mapics.com


   William Lohsen
   Georgia Tech Research Institute
   347 Ferst Drive
   Atlanta, Georgia 30332-0821

   EMail: William.Lohsen@GTRI.gatech.edu

Full Copyright Statement

   Copyright (C) The Internet Society (2005). This document is subject
   to the rights, licenses and restrictions contained in BCP 78, and
   except as set forth therein, the authors retain all their rights.

   This document and the information contained herein are provided on
   an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
   REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE
   INTERNET ENGINEERING TASK FORCE DISCLAIM 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.

Disclaimer of Validity

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights 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; nor does it
   represent that it has made any independent effort to identify any
   such rights.  Information on the procedures with respect to rights
   in RFC documents can be found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat 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 implementers or users of this
   specification can be obtained from the IETF on-line IPR repository
   at http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention
   any copyrights, patents or patent applications, or other
   proprietary rights that may cover technology that may be required
   to implement this standard.  Please address the information to the
   IETF at ietf-ipr@ietf.org.