RFC1924 日本語訳

1924 A Compact Representation of IPv6 Addresses. R. Elz. April 1 1996. (Format: TXT=10409 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文

Network Working Group                                             R. Elz
Request for Comments: 1924                       University of Melbourne
Category: Informational                                     1 April 1996

Elzがコメントのために要求するワーキンググループR.をネットワークでつないでください: 1924年のメルボルン大学カテゴリ: 情報の1996年4月1日

               A Compact Representation of IPv6 Addresses

IPv6アドレスのコンパクトな表現

Status of this Memo

このMemoの状態

   This memo provides information for the Internet community.  This memo
   does not specify an Internet standard of any kind.  Distribution of
   this memo is unlimited.

このメモはインターネットコミュニティのための情報を提供します。 このメモはどんな種類のインターネット標準も指定しません。 このメモの分配は無制限です。

1. Abstract

1. 要約

   IPv6 addresses, being 128 bits long, need 32 characters to write in
   the general case, if standard hex representation, is used, plus more
   for any punctuation inserted (typically about another 7 characters,
   or 39 characters total).  This document specifies a more compact
   representation of IPv6 addresses, which permits encoding in a mere 20
   bytes.

または、一般的なケースに書くアドレス、長さ128ビットの存在が32のキャラクタが必要があるIPv6が標準の十六進法表現であるなら使用されて、さらにどんな句読のためにも挿入される、(通常、別の7つのキャラクタに関して39キャラクタ合計) このドキュメントはIPv6アドレスの、よりコンパクトな表現を指定します。(それは、わずか20バイトでコード化することを許可します)。

2. Introduction

2. 序論

   It is always necessary to be able to write in characters the form of
   an address, though in actual use it is always carried in binary.  For
   IP version 4 (IP Classic) the well known dotted quad format is used.
   That is, 10.1.0.23 is one such address.  Each decimal integer
   represents a one octet of the 4 octet address, and consequently has a
   value between 0 and 255 (inclusive).  The written length of the
   address varies between 7 and 15 bytes.

アドレスの書式をキャラクタに書くことができるのがいつも必要です、実際の使用では、それはバイナリーでいつも運ばれますが。 IPバージョン4(IP Classic)において、よく知られている点を打たされた回路形式は使用されています。 すなわち、10.1 .0 .23はそのようなアドレスの1つです。 それぞれの10進整数は、4八重奏アドレスの1つの八重奏を表して、その結果、0と255の間の値を(包括的)であるのに持っています。 アドレスの書かれた長さは7〜15バイト異なります。

   For IPv6 however, addresses are 16 octets long [IPv6], if the old
   standard form were to be used, addresses would be anywhere between 31
   and 63 bytes, which is, of course, untenable.

しかしながら、IPv6に関しては、長い間[IPv6]、アドレスは16の八重奏です、古い標準形式が使用されることであったならアドレスが31と63バイトの間でどこでもあるでしょう。バイトはもちろん支持できません。

   Because of that, IPv6 had chosen to represent addresses using hex
   digits, and use only half as many punctuation characters, which will
   mean addresses of between 15 and 39 bytes, which is still quite long.
   Further, in an attempt to save more bytes, a special format was
   invented, in which a single run of zero octets can be dropped, the
   two adjacent punctuation characters indicate this has happened, the
   number of missing zeroes can be deduced from the fixed size of the
   address.

それのために、IPv6は十六進法ケタを使用することでアドレスを表して、半分だけの同じくらい多くの句読文字を使用するのを選びました。(句読文字は15〜39バイトのアドレスを意味するでしょう)。(バイトはまだかなり長いです)。 さらに、より多くのバイトを節約する試みでは、特別な形式(八重奏がないただ一つの走行を下げることができる)を発明して、2つの隣接している句読文字が、これが起こったのを示して、アドレスの固定サイズからなくなったゼロの数は推論できます。

   In most cases, using genuine IPv6 addresses, one may expect the
   address as written to tend toward the upper limit of 39 octets, as
   long strings of zeroes are likely to be rare, and most of the other

多くの場合、本物のIPv6アドレスを使用して、ゼロのロング・ストリングがまれである傾向があるので39の八重奏の上限の傾向があるように書かれているアドレス、およびもう片方の大部分を予想するかもしれません。

Elz                          Informational                      [Page 1]

RFC 1924       A Compact Representation of IPv6 Addresses   1 April 1996

IPv6のコンパクトな表現が1996年4月1日を扱うElzの情報[1ページ]のRFC1924

   groups of 4 hex digits are likely to be longer than a single non-zero
   digit (just as MAC addresses typically have digits spread throughout
   their length).

4十六進法ケタのグループは1非ゼロケタより長い傾向があります(ちょうどそれらの長さ中でMACアドレスでケタを通常広げるように)。

   This document specifies a new encoding, which can always represent
   any IPv6 address in 20 octets.  While longer than the shortest
   possible representation of an IPv6 address, this is barely longer
   than half the longest representation, and will typically be shorter
   than the representation of most IPv6 addresses.

このドキュメントは新しいコード化を指定します。(それは、いつも20の八重奏におけるどんなIPv6アドレスも表すことができます)。 IPv6アドレスの可能な限り短い表現よりほとんどのIPv6アドレスの表現より長い間である、これは、最も長い表現の半分よりほとんど長くなく、通常短くなるでしょう。

3. Current formats

3. 現在の形式

   [AddrSpec] specifies that the preferred text representation of IPv6
   addresses is in one of three conventional forms.

[AddrSpec]は、IPv6アドレスの都合のよいテキスト表現が3つの伝統的な形式の1つにあると指定します。

   The preferred form is x:x:x:x:x:x:x:x, where the 'x's are the
   hexadecimal values of the eight 16-bit pieces of the address.

好まれた形がそうである、x:x:x:x:x:x:x: 'x'がアドレスの16ビットの8つのつの16進値であることのx

   Examples:

例:

        FEDC:BA98:7654:3210:FEDC:BA98:7654:3210  (39 characters)

FEDC: BA98:7654:3210:FEDC:BA98:7654:3210(39のキャラクタ)

        1080:0:0:0:8:800:200C:417A  (25 characters)

1080:0:0:0:8:800:200C: 417A(25のキャラクタ)

   The second, or zero suppressed, form allows "::" to indicate multiple
   groups of suppressed zeroes, hence:

「2番目、または抑圧されたゼロ、フォームが許容する」:、:、」 したがって、抑圧されることの複数のグループを示すのは以下のゼロに合っています。

        1080:0:0:0:8:800:200C:417A

1080:0:0:0:8:800:200C: 417A

   may be represented as

表されるかもしれません。

        1080::8:800:200C:417A

1080::8:800:200C: 417A

   a saving of just 5 characters from this typical address form, and
   still leaving 21 characters.

この典型的なアドレスフォームからちょうど5つのキャラクタへ取っておいている、まだいなくなっている21のキャラクタ。

   In other cases the saving is more dramatic, in the extreme case, the
   address:

他の場合では、極端なケース、アドレスでは、節約が、より劇的です:

        0:0:0:0:0:0:0:0

0:0:0:0:0:0:0:0

   that is, the unspecified address, can be written as

それがそうであると不特定を、扱って、書くことができます。

        ::

::

   This is just 2 characters, which is a considerable saving.  However
   such cases will rarely be encountered.

これはちょうど2つのキャラクタです(かなりの節約です)。 しかしながら、そのような場合はめったに遭遇しないでしょう。

Elz                          Informational                      [Page 2]

RFC 1924       A Compact Representation of IPv6 Addresses   1 April 1996

IPv6のコンパクトな表現が1996年4月1日を扱うElzの情報[2ページ]のRFC1924

   The third possible form mixes the new IPv6 form with the old IPv4
   form, and is intended mostly for transition, when IPv4 addresses are
   embedded into IPv6 addresses.  These can be considerably longer than
   the longest normal IPv6 representation, and will eventually be phased
   out.  Consequently they will not be considered further here.

3番目の可能なフォームは、新しいIPv6書式を古いIPv4フォームに混ぜて、ほとんど変遷のために意図します、IPv4アドレスがIPv6アドレスに埋め込まれているとき。 これらは、最も長い通常のIPv6表現よりかなり長い場合があり、結局、段階的に廃止されるでしょう。 その結果、それらはここでさらに考えられないでしょう。

4. The New Encoding Format

4. 新しいコード化形式

   The new standard way of writing IPv6 addresses is to treat them as a
   128 bit integer, encode that in base 85 notation, then encode that
   using 85 ASCII characters.

IPv6にアドレスを書く新しい標準の方法は、85人のASCII文字を使用することで128ビットの整数としてそれらを扱って、ベース85記法でそれをコード化して、次に、それをコード化することです。

4.1. Why 85?

4.1. なぜ85?

   2^128 is 340282366920938463463374607431768211456.  85^20 is
   387595310845143558731231784820556640625, and thus in 20 digits of
   base 85 representation all possible 2^128 IPv6 addresses can clearly
   be encoded.

2^128は340282366920938463463374607431768211456です。 85^20は387595310845143558731231784820556640625です、そして、その結果、ベース85表現の20ケタでは、明確に128IPv6が扱うすべての可能な2^はコード化できます。

   84^20 is 305904398238499908683087849324518834176, clearly not
   sufficient, 21 characters would be needed to encode using base 84,
   this wastage of notational space cannot be tolerated.

84^20がベース84を使用する21のキャラクタが必要であるだろうコード化するのが明確に十分でない305904398238499908683087849324518834176である、記号法のスペースのこの消耗を許容できません。

   On the other hand, 94^19 is just
   30862366077815087592879016454695419904, also insufficient to encode
   all 2^128 different IPv6 addresses, so 20 characters would be needed
   even with base 94 encoding.  As there are just 94 ASCII characters
   (excluding control characters, space, and del) base 94 is the largest
   reasonable value that can be used.  Even if space were allowed, base
   95 would still require 20 characters.

他方では、94^19はちょうど30862366077815087592879016454695419904、また、すべての2^128の異なったIPv6アドレスをコード化するために、不十分です、したがって、20のキャラクタがベース94コード化があっても必要であるだろうということです。 ちょうど94人のASCII文字(制御文字、スペース、およびdelを除いた)がいるとき、ベース94は使用できる中で最も大きい適正価値です。 スペースが許容されていたとしても、ベース95はまだ20のキャラクタを必要としているでしょうに。

   Thus, any value between 85 and 94 inclusive could reasonably be
   chosen.  Selecting 85 allows the use of the smallest possible subset
   of the ASCII characters, enabling more characters to be retained for
   other uses, eg, to delimit the address.

したがって、合理的に85と94の間で包括的などんな値も選ぶことができました。 選択85はASCII文字の可能な限り小さい部分集合の使用を許します、より多くのキャラクタが他の用途、アドレスを区切るegのために保有されるのを可能にして。

4.2. The Character Set

4.2. 文字コード

   The character set to encode the 85 base85 digits, is defined to be,
   in ascending order:

文字集合、85base85ケタをコード化して、昇順であるように定義されます:

             '0'..'9', 'A'..'Z', 'a'..'z', '!', '#', '$', '%', '&', '(',
             ')', '*', '+', '-', ';', '<', '=', '>', '?', '@', '^', '_',
             '`', '{', '|', '}', and '~'.

'0'..'9''A'。'Z'、'a'。''z、''!''#''、$、'、'、%、''&''、('、'、)、''*、''+ ''--'';''、<''=''、>、'、'?'、'@、''^、''_'''''、'、'、|、'''}'、および~'、'

   This set has been chosen with considerable care.  From the 94
   printable ASCII characters, the following nine were omitted:

このセットはかなりの注意で選ばれました。 94人の印刷可能なASCII文字から、以下の9は省略されました:

Elz                          Informational                      [Page 3]

RFC 1924       A Compact Representation of IPv6 Addresses   1 April 1996

IPv6のコンパクトな表現が1996年4月1日を扱うElzの情報[3ページ]のRFC1924

      '"' and "'", which allow the representation of IPv6 addresses to
      be quoted in other environments where some of the characters in
      the chosen character set may, unquoted, have other meanings.

'、「'、「'「どれが、引用を終わられて、選ばれた文字集合における何人かのキャラクタが他の意味を持っているかもしれないところにIPv6アドレスの表現が他の環境で引用されるのを許容」'。

      ',' to allow lists of IPv6 addresses to conveniently be written,
      and '.' to allow an IPv6 address to end a sentence without
      requiring it to be quoted.

そして、'''IPv6のリストを許容するのが、便利に書かれていると扱う、'.'それが引用される必要でないIPv6アドレスが文を終わらせるのを許容するために。

      '/' so IPv6 addresses can be written in standard CIDR
      address/length notation, and ':' because that causes problems when
      used in mail headers and URLs.

そして、'標準のCIDRのアドレス/長さの記法でそのように、'/'IPv6というアドレスを書くことができる、':'メールヘッダとURLで使用されるとそれが問題を起こすので。

      '[' and ']', so those can be used to delimit IPv6 addresses when
      represented as text strings, as they often are for IPv4,

'']'、そのように。'、[テキスト文字列として表されるとIPv6アドレスを区切るのにものを使用できます、しばしばそれらがIPv4のためのものであるときに

      And last, '\', because it is often difficult to represent in a way
      where it does not appear to be a quote character, including in the
      source of this document.

そして、最終、それが引用文字であるように見えない方法で表すのがしばしば難しいのでこのドキュメントの源が包含する'\'。

5. Converting an IPv6 address to base 85.

5. 85を基礎づけるためにIPv6アドレスを変換します。

   The conversion process is a simple one of division, taking the
   remainders at each step, and dividing the quotient again, then
   reading up the page, as is done for any other base conversion.

変換プロセスは各ステップで残りを取る分割と、再び商を分割する簡単なものです、次に、ページについて研究して、いかなる他の進法変換のためにもするように。

   For example, consider the address shown above

例えば、上に示されたアドレスを考えてください。

        1080:0:0:0:8:800:200C:417A

1080:0:0:0:8:800:200C: 417A

   In decimal, considered as a 128 bit number, that is
   21932261930451111902915077091070067066.

128ビットの数であるとみなされた小数では、それは21932261930451111902915077091070067066です。

   As we divide that successively by 85 the following remainders emerge:
   51, 34, 65, 57, 58, 0, 75, 53, 37, 4, 19, 61, 31, 63, 12, 66, 46, 70,
   68, 4.

私たちが相次ぐ85にそれを割るとき、以下の残りは現れます: 51, 34, 65, 57, 58, 0, 75, 53, 37, 4, 19, 61, 31, 63, 12, 66, 46, 70, 68, 4.

   Thus in base85 the address is:

したがって、base85では、アドレスは以下の通りです。

        4-68-70-46-66-12-63-31-61-19-4-37-53-75-0-58-57-65-34-51.

4-68-70-46-66-12-63-31-61-19-4-37-53-75-0-58-57-65-34-51.

   Then, when encoded as specified above, this becomes:

次に、上で指定されるとしてコード化されると、これはなります:

        4)+k&C#VzJ4br>0wv%Yp

4) + kとC#VzJ4br>0wv%Yp

   This procedure is trivially reversed to produce the binary form of
   the address from textually encoded format.

この手順は、原文のコード化された形式からアドレスの二部形式を発生させるように些細なことに逆にされます。

Elz                          Informational                      [Page 4]

RFC 1924       A Compact Representation of IPv6 Addresses   1 April 1996

IPv6のコンパクトな表現が1996年4月1日を扱うElzの情報[4ページ]のRFC1924

6. Additional Benefit

6. 追加利益

   Apart from generally reducing the length of an IPv6 address when
   encode in a textual format, this scheme also has the benefit of
   returning IPv6 addresses to a fixed length representation, leading
   zeroes are never omitted, thus removing the ugly and awkward variable
   length representation that has previously been recommended.

また、原文の形式のエンコードであるときに一般に、IPv6アドレスの長さを減少させることは別として、この体系は固定長表現(決して省略されないで、その結果以前にお勧めであった醜くて厄介な可変長表現を取り除く主なゼロ)に戻っているIPv6アドレスの利益を持っています。

7. Implementation Issues

7. 導入問題

   Many current processors do not find 128 bit integer arithmetic, as
   required for this technique, a trivial operation.  This is not
   considered a serious drawback in the representation, but a flaw of
   the processor designs.

多くの現在のプロセッサは、このテクニック、些細な操作に関して128ビットが整数演算であることが必要に応じてわかりません。 これはしかし、表現における重大な欠点、プロセッサデザインの欠点であると考えられません。

   It may be expected that future processors will address this defect,
   quite possibly before any significant IPv6 deployment has been
   accomplished.

将来のプロセッサがこの欠陥を扱うと予想されるかもしれません、どんな重要なIPv6展開もかなり実行されることによると前に。

8. Security Considerations

8. セキュリティ問題

   By encoding addresses in this form, it is less likely that a casual
   observer will be able to immediately detect the binary form of the
   address, and thus will find it harder to make immediate use of the
   address.  As IPv6 addresses are not intended to be learned by humans,
   one reason for which being that they are expected to alter in
   comparatively short timespan, by human perception, the somewhat
   challenging nature of the addresses is seen as a feature.

このフォームでアドレスをコード化することによって、カジュアルな観察者は、すぐにアドレスの二部形式を検出できて、その結果、アドレスの即座の使用をよりしにくいのが、よりわかりそうにないでしょう。 IPv6として、アドレスは人間(彼らが比較的短いtimespanで人間の知覚で変わると予想されるということでありアドレスのいくらかやりがいがある本質が特徴と考えられる1つの理由)によって学習されることを意図しません。

   Further, the appearance of the address, as if it may be random
   gibberish in a compressed file, makes it much harder to detect by a
   packet sniffer programmed to look for bypassing addresses.

さらに、アドレスの外観で、圧縮されたファイルの無作為のおしゃべりであるかもしれないかのように、それはアドレスを迂回させるのを見るようにプログラムされたパケットスニッファーではるかに検出しにくいようになります。

Elz                          Informational                      [Page 5]

RFC 1924       A Compact Representation of IPv6 Addresses   1 April 1996

IPv6のコンパクトな表現が1996年4月1日を扱うElzの情報[5ページ]のRFC1924

9. References

9. 参照

   [IPv6]        Internet Protocol, Version 6 (IPv6) Specification,
                 S. Deering, R. Hinden, RFC 1883, January 4, 1996.

[IPv6]インターネットプロトコル、バージョン6(IPv6)仕様、S.デアリング、R.Hinden、RFC、1883年1月4日、1996

   [AddrSpec]    IP Version 6 Addressing Architecture,
                 R. Hinden, S. Deering, RFC 1884, January 4, 1996.

アーキテクチャ、R.Hinden、S.デアリングRFCに1884年1月4日を扱う[AddrSpec]IPバージョン6、1996。

10. Author's Address

10. 作者のアドレス

   Robert Elz
   Computer Science
   University of Melbourne
   Parkville, Victoria, 3052
   Australia

メルボルンParkville、ビクトリア、3052オーストラリアのロバートElzコンピュータサイエンス大学

   EMail: kre@munnari.OZ.AU

メール: kre@munnari.OZ.AU

Elz                          Informational                      [Page 6]

Elz情報です。[6ページ]

一覧

 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 

スポンサーリンク

Array.splice

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

上に戻る