[要約] RFC 5952は、IPv6アドレスのテキスト表現に関する推奨事項を提供するものであり、IPv6アドレスの表記方法を統一し、可読性と相互運用性を向上させることを目的としています。
Internet Engineering Task Force (IETF) S. Kawamura
Request for Comments: 5952 NEC BIGLOBE, Ltd.
Updates: 4291 M. Kawashima
Category: Standards Track NEC AccessTechnica, Ltd.
ISSN: 2070-1721 August 2010
A Recommendation for IPv6 Address Text Representation
IPv6アドレステキスト表現の推奨
Abstract
概要
As IPv6 deployment increases, there will be a dramatic increase in the need to use IPv6 addresses in text. While the IPv6 address architecture in Section 2.2 of RFC 4291 describes a flexible model for text representation of an IPv6 address, this flexibility has been causing problems for operators, system engineers, and users. This document defines a canonical textual representation format. It does not define a format for internal storage, such as within an application or database. It is expected that the canonical format will be followed by humans and systems when representing IPv6 addresses as text, but all implementations must accept and be able to handle any legitimate RFC 4291 format.
IPv6の展開が増加すると、テキストでIPv6アドレスを使用する必要性が劇的に増加します。RFC 4291のセクション2.2のIPv6アドレスアーキテクチャは、IPv6アドレスのテキスト表現のための柔軟なモデルを説明していますが、この柔軟性はオペレーター、システムエンジニア、およびユーザーに問題を引き起こしています。このドキュメントは、標準的なテキスト表現形式を定義します。アプリケーションやデータベース内など、内部ストレージの形式を定義しません。IPv6アドレスをテキストとして表現する場合、標準形式の後に人間とシステムが続くことが予想されますが、すべての実装は、正当なRFC 4291形式を受け入れ、処理することができなければなりません。
Status of This Memo
本文書の位置付け
This is an Internet Standards Track document.
これは、インターネット標準トラックドキュメントです。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
このドキュメントは、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表しています。公開レビューを受けており、インターネットエンジニアリングステアリンググループ（IESG）からの出版が承認されています。インターネット標準の詳細については、RFC 5741のセクション2で入手できます。
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/rfc5952.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、http：//www.rfc-editor.org/info/rfc5952で取得できます。
Copyright Notice
著作権表示
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2010 IETF Trustおよび文書著者として特定された人。全著作権所有。
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. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
このドキュメントは、BCP 78およびIETFドキュメント（http://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、単純化されたBSDライセンスで説明されているように保証なしで提供される簡略化されたBSDライセンステキストを含める必要があります。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4
2. Text Representation Flexibility of RFC 4291 . . . . . . . . . 4
2.1. Leading Zeros in a 16-Bit Field . . . . . . . . . . . . . 4
2.2. Zero Compression . . . . . . . . . . . . . . . . . . . . . 5
2.3. Uppercase or Lowercase . . . . . . . . . . . . . . . . . . 6
3. Problems Encountered with the Flexible Model . . . . . . . . . 6
3.1. Searching . . . . . . . . . . . . . . . . . . . . . . . . 6
3.1.1. General Summary . . . . . . . . . . . . . . . . . . . 6
3.1.2. Searching Spreadsheets and Text Files . . . . . . . . 6
3.1.3. Searching with Whois . . . . . . . . . . . . . . . . . 6
3.1.4. Searching for an Address in a Network Diagram . . . . 7
3.2. Parsing and Modifying . . . . . . . . . . . . . . . . . . 7
3.2.1. General Summary . . . . . . . . . . . . . . . . . . . 7
3.2.2. Logging . . . . . . . . . . . . . . . . . . . . . . . 7
3.2.3. Auditing: Case 1 . . . . . . . . . . . . . . . . . . . 8
3.2.4. Auditing: Case 2 . . . . . . . . . . . . . . . . . . . 8
3.2.5. Verification . . . . . . . . . . . . . . . . . . . . . 8
3.2.6. Unexpected Modifying . . . . . . . . . . . . . . . . . 8
3.3. Operating . . . . . . . . . . . . . . . . . . . . . . . . 8
3.3.1. General Summary . . . . . . . . . . . . . . . . . . . 8
3.3.2. Customer Calls . . . . . . . . . . . . . . . . . . . . 9
3.3.3. Abuse . . . . . . . . . . . . . . . . . . . . . . . . 9
3.4. Other Minor Problems . . . . . . . . . . . . . . . . . . . 9
3.4.1. Changing Platforms . . . . . . . . . . . . . . . . . . 9
3.4.2. Preference in Documentation . . . . . . . . . . . . . 9
3.4.3. Legibility . . . . . . . . . . . . . . . . . . . . . . 9
4. A Recommendation for IPv6 Text Representation . . . . . . . . 10
4.1. Handling Leading Zeros in a 16-Bit Field . . . . . . . . . 10
4.2. "::" Usage . . . . . . . . . . . . . . . . . . . . . . . . 10
4.2.1. Shorten as Much as Possible . . . . . . . . . . . . . 10
4.2.2. Handling One 16-Bit 0 Field . . . . . . . . . . . . . 10
4.2.3. Choice in Placement of "::" . . . . . . . . . . . . . 10
4.3. Lowercase . . . . . . . . . . . . . . . . . . . . . . . . 10
5. Text Representation of Special Addresses . . . . . . . . . . . 11
6. Notes on Combining IPv6 Addresses with Port Numbers . . . . . 11
7. Prefix Representation . . . . . . . . . . . . . . . . . . . . 12
8. Security Considerations . . . . . . . . . . . . . . . . . . . 12
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
10.1. Normative References . . . . . . . . . . . . . . . . . . . 12
10.2. Informative References . . . . . . . . . . . . . . . . . . 13
Appendix A. For Developers . . . . . . . . . . . . . . . . . . . 14
A single IPv6 address can be text represented in many ways. Examples are shown below.
単一のIPv6アドレスは、多くの点で表されるテキストにすることができます。例を以下に示します。
2001:db8:0:0:1:0:0:1
2001:0db8:0:0:1:0:0:1
2001:db8::1:0:0:1
2001:db8::0:1:0:0:1
2001:0db8::1:0:0:1
2001:db8:0:0:1::1
2001:db8:0000:0:1::1
2001:DB8:0:0:1::1
All of the above examples represent the same IPv6 address. This flexibility has caused many problems for operators, systems engineers, and customers. The problems are noted in Section 3. A canonical representation format to avoid problems is introduced in Section 4.
上記の例はすべて、同じIPv6アドレスを表しています。この柔軟性は、オペレーター、システムエンジニア、顧客に多くの問題を引き起こしています。問題はセクション3に記載されています。問題を回避するための標準表現形式をセクション4に導入します。
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].
「必須」、「そうしない」、「必須」、「必要」、「しない」、「そうしない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、[RFC2119]に記載されているように解釈される。
Examples of flexibility in Section 2.2 of [RFC4291] are described below.
[RFC4291]のセクション2.2の柔軟性の例を以下に説明します。
'It is not necessary to write the leading zeros in an individual field.'
「個々の分野で主要なゼロを書く必要はありません。」
Conversely, it is also not necessary to omit leading zeros. This means that it is possible to select from representations such as those in the following example. The final 16-bit field is different, but all of these addresses represent the same address.
逆に、主要なゼロを省略する必要もありません。これは、次の例のような表現から選択できることを意味します。最後の16ビットフィールドは異なりますが、これらのアドレスはすべて同じアドレスを表しています。
2001:db8:aaaa:bbbb:cccc:dddd:eeee:0001
2001:db8:aaaa:bbbb:cccc:dddd:eeee:001
2001:db8:aaaa:bbbb:cccc:dddd:eeee:01
2001:db8:aaaa:bbbb:cccc:dddd:eeee:1
'A special syntax is available to compress the zeros. The use of "::" indicates one or more groups of 16 bits of zeros.'
「ゼロを圧縮するために特別な構文が利用できます。「::」の使用は、16ビットのゼロの1つ以上のグループを示します。
It is possible to select whether or not to omit just one 16-bit 0 field.
1つの16ビット0フィールドのみを省略するかどうかを選択することができます。
2001:db8:aaaa:bbbb:cccc:dddd::1
2001:db8:aaaa:bbbb:cccc:dddd:0:1
In cases where there is more than one field of only zeros, there is a choice of how many fields can be shortened.
ゼロのみのフィールドが複数ある場合、短縮できるフィールドの数が選択されています。
2001:db8:0:0:0::1
2001:db8:0:0::1
2001:db8:0::1
2001:db8::1
In addition, Section 2.2 of [RFC4291] notes,
さらに、[RFC4291]のセクション2.2は、
'The "::" can only appear once in an address.'
'"::"はアドレスに一度しか表示できません。」
This gives a choice on where in a single address to compress the zero.
これにより、ゼロを圧縮するための単一のアドレスの場所が選択されます。
2001:db8::aaaa:0:0:1
2001:db8:0:0:aaaa::1
[RFC4291] does not mention any preference of uppercase or lowercase.
[RFC4291]は、大文字や小文字の好みについては言及していません。
2001:db8:aaaa:bbbb:cccc:dddd:eeee:aaaa
2001:db8:aaaa:bbbb:cccc:dddd:eeee:AAAA
2001:db8:aaaa:bbbb:cccc:dddd:eeee:AaAa
A search of an IPv6 address if conducted through a UNIX system is usually case sensitive and extended options that allow for regular expression use will come in handy. However, there are many applications in the Internet today that do not provide this capability. When searching for an IPv6 address in such systems, the system engineer will have to try each and every possibility to search for an address. This has critical impacts, especially when trying to deploy IPv6 over an enterprise network.
UNIXシステムを介して実施された場合のIPv6アドレスの検索は通常、ケースに敏感であり、正規表現の使用を可能にする拡張オプションが役立ちます。ただし、今日、インターネットにはこの機能を提供しない多くのアプリケーションがあります。このようなシステムでIPv6アドレスを検索する場合、システムエンジニアはアドレスを検索するためにあらゆる可能性を試す必要があります。これは、特にエンタープライズネットワーク上にIPv6を展開しようとする場合に重大な影響を及ぼします。
Spreadsheet applications and text editors on GUI systems rarely have the ability to search for text using regular expression. Moreover, there are many non-engineers (who are not aware of case sensitivity and regular expression use) that use these applications to manage IP addresses. This has worked quite well with IPv4 since text representation in IPv4 has very little flexibility. There is no incentive to encourage these non-engineers to change their tool or learn regular expression when they decide to go dual-stack. If the entry in the spreadsheet reads, 2001:db8::1:0:0:1, but the search was conducted as 2001:db8:0:0:1::1, this will show a result of no match. One example where this will cause a problem is, when the search is being conducted to assign a new address from a pool, and a check is being done to see if it is not in use. This may cause problems for the end-hosts or end-users. This type of address management is very often seen in enterprise networks and ISPs.
GUIシステムのスプレッドシートアプリケーションとテキストエディターが、正規表現を使用してテキストを検索することはめったにありません。さらに、これらのアプリケーションを使用してIPアドレスを管理する多くの非エンジニア（ケースの感度と正規表現の使用を認識していない）があります。IPv4のテキスト表現は柔軟性がほとんどないため、これはIPv4で非常にうまく機能しています。これらの非エンジニアがツールを変更したり、デュアルスタックに行くことを決めたときに正規表現を学ぶことを奨励するインセンティブはありません。スプレッドシートのエントリが2001年：db8 :: 1：0：0：1に読み取られているが、検索は2001：db8：0：0：1 :: 1として実施された場合、これは一致しない結果を示します。これが問題を引き起こす1つの例は、プールから新しいアドレスを割り当てるために検索が実施されている場合、それが使用されていないかどうかを確認するためにチェックが行われています。これにより、エンドホストまたはエンドユーザーの問題が発生する可能性があります。このタイプのアドレス管理は、エンタープライズネットワークとISPで非常によく見られます。
The "whois" utility is used by a wide range of people today. When a record is set to a database, one will likely check the output to see if the entry is correct. If an entity was recorded as 2001:db8::/48, but the whois output showed 2001:0db8:0000::/48, most non-engineers would think that their input was wrong and will likely retry several times or make a frustrated call to the database hostmaster. If there was a need to register the same prefix on different systems, and each system showed a different text representation, this would confuse people even more. Although this document focuses on addresses rather than prefixes, it is worth mentioning the prefix problems because the problems encountered with addresses and prefixes are mostly equal.
「Whois」ユーティリティは、今日の幅広い人々によって使用されています。レコードがデータベースに設定されている場合、出力をチェックしてエントリが正しいかどうかを確認する可能性があります。エンティティが2001：db8 ::/48として記録されたが、WHOIS出力が2001：0DB8：0000 ::/48を示した場合、ほとんどの非エンジニアは自分の入力が間違っていると考えるでしょう。データベースホストマスターに電話します。異なるシステムに同じプレフィックスを登録する必要があり、各システムが異なるテキスト表現を示した場合、これは人々をさらに混乱させるでしょう。このドキュメントはプレフィックスではなくアドレスに焦点を当てていますが、アドレスとプレフィックスで発生する問題はほとんど等しいため、プレフィックスの問題に言及する価値があります。
Network diagrams and blueprints often show what IP addresses are assigned to a system devices. In times of trouble shooting there may be a need to search through a diagram to find the point of failure (for example, if a traceroute stopped at 2001:db8::1, one would search the diagram for that address). This is a technique quite often in use in enterprise networks and managed services. Again, the different flavors of text representation will result in a time-consuming search leading to longer mean times to restoration (MTTR) in times of trouble.
ネットワーク図と青写真は、多くの場合、システムデバイスにどのようなIPアドレスが割り当てられているかを示しています。トラブルシューティングの時代には、図を検索して障害のポイントを見つける必要があるかもしれません（たとえば、2001年にトレーサーアウトが停止した場合：db8 :: 1では、そのアドレスの図を検索します）。これは、エンタープライズネットワークとマネージドサービスで使用される非常に頻繁に使用される手法です。繰り返しますが、テキスト表現のさまざまなフレーバーは、問題のある時期に時間のかかる時間（MTTR）までの平均時間（MTTR）につながる時間のかかる検索につながります。
With all the possible methods of text representation, each application must include a module, object, link, etc. to a function that will parse IPv6 addresses in a manner such that no matter how it is represented, they will mean the same address. Many system engineers who integrate complex computer systems for corporate customers will have difficulties finding that their favorite tool will not have this function, or will encounter difficulties such as having to rewrite their macros or scripts for their customers.
テキスト表現のすべての可能な方法がある場合、各アプリケーションには、モジュール、オブジェクト、リンクなどを含める必要があります。これにより、IPv6アドレスを解析する関数が含まれている必要があります。企業の顧客のために複雑なコンピューターシステムを統合する多くのシステムエンジニアは、お気に入りのツールがこの機能を持たないこと、または顧客のためにマクロやスクリプトを書き直さなければならないなどの困難に遭遇することを見つけるのに苦労します。
If an application were to output a log summary that represented the address in full (such as 2001:0db8:0000:0000:1111:2222:3333:4444), the output would be highly unreadable compared to the IPv4 output. The address would have to be parsed and reformed to make it useful for human reading. Sometimes logging for critical systems is done by mirroring the same traffic to two different systems. Care must be taken so that no matter what the log output is, the logs should be parsed so they are equivalent.
アプリケーションがアドレスを完全に表すログの要約を出力する場合（2001：0DB8：0000：0000：1111：2222：3333：4444など）、IPv4出力と比較して出力は非常に読み取れません。住所は、人間の読書に役立つように解析および改革する必要があります。重要なシステムのロギングは、同じトラフィックを2つの異なるシステムにミラーリングすることで行われる場合があります。ログ出力が何であれ、ログを解析して同等にするように注意する必要があります。
When a router or any other network appliance machine configuration is audited, there are many methods to compare the configuration information of a node. Sometimes auditing will be done by just comparing the changes made each day. In this case, if configuration was done such that 2001:db8::1 was changed to 2001:0db8:0000:0000: 0000:0000:0000:0001 just because the new engineer on the block felt it was better, a simple diff will show that a different address was configured. If this was done on a wide scale network, people will be focusing on 'why the extra zeros were put in' instead of doing any real auditing. Lots of tools are just plain diffs that do not take into account address representation rules.
ルーターまたはその他のネットワークアプライアンスマシンの構成が監査されている場合、ノードの構成情報を比較する多くの方法があります。毎日行われた変更を比較するだけで監査が行われる場合があります。この場合、2001：db8 :: 1が2001：0DB8：0000：0000：0000：0000：0000：0000：0001に変更されたように構成が行われた場合、ブロックの新しいエンジニアがより良いと感じたからです。別のアドレスが構成されたことを示します。これが大規模なネットワークで行われた場合、人々は実際の監査を行う代わりに「余分なゼロが入れる理由」に焦点を当てます。多くのツールは、アドレス表現ルールを考慮していない単なる差分です。
Node configurations will be matched against an information system that manages IP addresses. If output notation is different, there will need to be a script that is implemented to cover for this. The result of an SNMP GET operation, converted to text and compared to a textual address written by a human is highly unlikely to match on the first try.
ノード構成は、IPアドレスを管理する情報システムと一致します。出力表記が異なる場合、これをカバーするために実装されたスクリプトが必要です。SNMP Get操作の結果、テキストに変換され、人間によって書かれたテキストアドレスと比較された結果、最初の試みで一致する可能性は非常に低いです。
Some protocols require certain data fields to be verified. One example of this is X.509 certificates. If an IPv6 address field in a certificate was incorrectly verified by converting it to text and making a simple textual comparison to some other address, the certificate may be mistakenly shown as being invalid due to a difference in text representation methods.
一部のプロトコルでは、特定のデータフィールドを検証する必要があります。この1つの例は、X.509証明書です。証明書のIPv6アドレスフィールドがテキストに変換し、他のアドレスと簡単なテキスト比較を作成することにより誤って検証された場合、テキスト表現方法の違いにより証明書が無効であると誤って示される場合があります。
Sometimes, a system will take an address and modify it as a convenience. For example, a system may take an input of 2001:0db8:0::1 and make the output 2001:db8::1. If the zeros were input for a reason, the outcome may be somewhat unexpected.
時には、システムが住所を取得し、便利なものとして変更することがあります。たとえば、システムは2001：0DB8：0 :: 1の入力を取得し、2001：db8 :: 1を出力します。ゼロが理由で入力された場合、結果はいくぶん予期しないかもしれません。
When an operator sets an IPv6 address of a system as 2001:db8:0:0:1: 0:0:1, the system may take the address and show the configuration result as 2001:DB8::1:0:0:1. Someone familiar with IPv6 address representation will know that the right address is set, but not everyone may understand this.
オペレーターが2001：db8：0：0：0：0：0：1としてシステムのIPv6アドレスを設定すると、システムはアドレスを取得し、2001：db8 :: 1：0：0として構成結果を表示する場合があります。1。IPv6アドレスの表現に精通している人は、正しいアドレスが設定されていることを知っていますが、誰もがこれを理解できるわけではありません。
When a customer calls to inquire about a suspected outage, IPv6 address representation should be handled with care. Not all customers are engineers, nor do they have a similar skill level in IPv6 technology. The network operations center will have to take extra steps to humanly parse the address to avoid having to explain to the customers that 2001:db8:0:1::1 is the same as 2001:db8::1:0:0:0:1. This is one thing that will never happen in IPv4 because IPv4 addresses cannot be abbreviated.
顧客が停止の疑いについて問い合わせるように電話する場合、IPv6アドレス表現は注意して処理する必要があります。すべての顧客がエンジニアであるわけではなく、IPv6テクノロジーでも同様のスキルレベルを持っていません。ネットワークオペレーションセンターは、2001年：db8：0：1 :: 1が2001年と同じであることを顧客に説明する必要がないように、住所を人間的に解析するための追加の措置を講じる必要があります。：1。IPv4アドレスを省略できないため、これはIPv4では決して発生しないことの1つです。
Network abuse reports generally include the abusing IP address. This 'reporting' could take any shape or form of the flexible model. A team that handles network abuse must be able to tell the difference between a 2001:db8::1:0:1 and 2001:db8:1::0:1. Mistakes in the placement of the "::" will result in a critical situation. A system that handles these incidents should be able to handle any type of input and parse it in a correct manner. Also, incidents are reported over the phone. It is unnecessary to report if the letter is uppercase or lowercase. However, when a letter is spelled uppercase, people tend to specify that it is uppercase, which is unnecessary information.
ネットワークの悪用レポートには、一般に、IPアドレスの乱用が含まれます。この「報告」は、柔軟なモデルの形や形をとることができます。ネットワークの乱用を処理するチームは、2001年：db8 :: 1：0：1と2001：db8：1 :: 0：1の違いを伝えることができなければなりません。「::」の配置の間違いは、重大な状況につながります。これらのインシデントを処理するシステムは、あらゆる種類の入力を処理し、正しい方法で解析できる必要があります。また、電話でインシデントが報告されています。手紙が大文字または小文字であるかどうかを報告する必要はありません。ただし、文字が大文字と綴られている場合、人々はそれが大文字であることを指定する傾向があります。これは不必要な情報です。
When an engineer decides to change the platform of a running service, the same code may not work as expected due to the difference in IPv6 address text representation. Usually, a change in a platform (e.g., Unix to Windows, Cisco to Juniper) will result in a major change of code anyway, but flexibility in address representation will increase the work load.
エンジニアが実行中のサービスのプラットフォームを変更することを決定した場合、IPv6アドレステキスト表現の違いにより、同じコードが期待どおりに機能しない場合があります。通常、プラットフォームの変更（例：UnixからWindows、Cisco to Juniperなど）は、とにかくコードの大幅な変更をもたらしますが、アドレス表現の柔軟性は作業負荷が増加します。
A document that is edited by more than one author may become harder to read.
複数の著者によって編集されたドキュメントは、読みにくい場合があります。
Capital case D and 0 can be quite often misread. Capital B and 8 can also be misread.
キャピタルケースDと0は、しばしば誤解される可能性があります。キャピタルBと8も誤読できます。
A recommendation for a canonical text representation format of IPv6 addresses is presented in this section. The recommendation in this document is one that complies fully with [RFC4291], is implemented by various operating systems, and is human friendly. The recommendation in this section SHOULD be followed by systems when generating an address to be represented as text, but all implementations MUST accept and be able to handle any legitimate [RFC4291] format. It is advised that humans also follow these recommendations when spelling an address.
このセクションでは、IPv6アドレスの標準テキスト表現形式の推奨事項を示します。このドキュメントの推奨事項は、[RFC4291]に完全に準拠したものであり、さまざまなオペレーティングシステムによって実装され、人間に優しいものです。このセクションの推奨事項は、テキストとして表現するアドレスを生成するときにシステムが続く必要がありますが、すべての実装は、正当な[RFC4291]形式を受け入れ、処理できる必要があります。住所を綴るとき、人間もこれらの推奨事項に従うことをお勧めします。
Leading zeros MUST be suppressed. For example, 2001:0db8::0001 is not acceptable and must be represented as 2001:db8::1. A single 16- bit 0000 field MUST be represented as 0.
主要なゼロを抑制する必要があります。たとえば、2001：0DB8 :: 0001は受け入れられず、2001：DB8 :: 1として表す必要があります。単一の16-ビット0000フィールドは0として表す必要があります。
The use of the symbol "::" MUST be used to its maximum capability. For example, 2001:db8:0:0:0:0:2:1 must be shortened to 2001:db8::2:1. Likewise, 2001:db8::0:1 is not acceptable, because the symbol "::" could have been used to produce a shorter representation 2001:db8::1.
シンボルの使用 "::"は、その最大機能に使用する必要があります。たとえば、2001年：db8：0：0：0：0：0：2：1は2001年まで短縮する必要があります：db8 :: 2：1。同様に、2001年：db8 :: 0：1は受け入れられません。なぜなら、シンボル "::"は、2001：db8 :: 1の短い表現を生成するために使用できた可能性があるため。
The symbol "::" MUST NOT be used to shorten just one 16-bit 0 field. For example, the representation 2001:db8:0:1:1:1:1:1 is correct, but 2001:db8::1:1:1:1:1 is not correct.
シンボル "::"は、1つの16ビット0フィールドのみを短くするために使用してはなりません。たとえば、2001年の表現：db8：0：1：1：1：1：1は正しいですが、2001：db8 :: 1：1：1：1：1は正しくありません。
When there is an alternative choice in the placement of a "::", the longest run of consecutive 16-bit 0 fields MUST be shortened (i.e., the sequence with three consecutive zero fields is shortened in 2001: 0:0:1:0:0:0:1). When the length of the consecutive 16-bit 0 fields are equal (i.e., 2001:db8:0:0:1:0:0:1), the first sequence of zero bits MUST be shortened. For example, 2001:db8::1:0:0:1 is correct representation.
「::」の配置に別の選択肢がある場合、連続した16ビット0フィールドの最長の実行を短縮する必要があります（つまり、3つの連続したゼロフィールドを持つシーケンスが2001年に短縮されます：0：0：1：0：0：0：1）。連続した16ビット0フィールドの長さが等しい場合（つまり、2001：db8：0：0：0：0：0：1）、ゼロビットの最初のシーケンスを短縮する必要があります。たとえば、2001年：db8 :: 1：0：0：1は正しい表現です。
The characters "a", "b", "c", "d", "e", and "f" in an IPv6 address MUST be represented in lowercase.
IPv6アドレスの「A」、「B」、「C」、「D」、「E」、および「F」の文字は、小文字で表す必要があります。
Addresses such as IPv4-Mapped IPv6 addresses, ISATAP [RFC5214], and IPv4-translatable addresses [ADDR-FORMAT] have IPv4 addresses embedded in the low-order 32 bits of the address. These addresses have a special representation that may mix hexadecimal and dot decimal notations. The decimal notation may be used only for the last 32 bits of the address. For these addresses, mixed notation is RECOMMENDED if the following condition is met: the address can be distinguished as having IPv4 addresses embedded in the lower 32 bits solely from the address field through the use of a well-known prefix. Such prefixes are defined in [RFC4291] and [RFC2765] at the time of this writing. If it is known by some external method that a given prefix is used to embed IPv4, it MAY be represented as mixed notation. Tools that provide options to specify prefixes that are (or are not) to be represented as mixed notation may be useful.
IPv4-Mapped IPv6アドレス、ISATAP [RFC5214]、IPv4翻訳可能アドレス[ADDR-Format]などのアドレスには、アドレスの32ビットの低次にIPv4アドレスが埋め込まれています。これらのアドレスには、16進数とDOT 10進表記が混合される可能性のある特別な表現があります。小数表記は、アドレスの最後の32ビットでのみ使用できます。これらのアドレスの場合、次の条件が満たされている場合は、混合表記をお勧めします。アドレスは、有名な接頭辞を使用して、アドレスフィールドからのみ32ビットに埋め込まれたIPv4アドレスを持つことと区別できます。このようなプレフィックスは、この執筆時点で[RFC4291]および[RFC2765]で定義されています。特定のプレフィックスがIPv4を埋め込むために使用されていることが外部メソッドで知られている場合、混合表記として表される場合があります。混合表記として表現される（またはそうでない）プレフィックスを指定するオプションを提供するツールが役立つ場合があります。
There is a trade-off here where a recommendation to achieve an exact match in a search (no dot decimals whatsoever) and a recommendation to help the readability of an address (dot decimal whenever possible) does not result in the same solution. The above recommendation is aimed at fixing the representation as much as possible while leaving the opportunity for future well-known prefixes to be represented in a human-friendly manner as tools adjust to newly assigned prefixes.
ここでは、検索で正確な一致を達成するための推奨事項（DOT小数はまったくありません）と、住所の読みやすさ（可能な限りDOT小数）が同じソリューションにならないようにするための推奨事項があります。上記の推奨事項は、ツールが新しく割り当てられたプレフィックスに合わせて調整されるため、将来の有名な接頭辞が人間に優しい方法で表現される機会を残しながら、可能な限り表現を修正することを目的としています。
The text representation method noted in Section 4 should be applied for the leading hexadecimal part (i.e., ::ffff:192.0.2.1 instead of 0:0:0:0:0:ffff:192.0.2.1).
セクション4で記載されているテキスト表現方法は、0：0：0：0：0：FFFF：192.0.2.1ではなく、:: FFFF：192.0.2.1：192.0.2.1）の主要な16進部分に適用する必要があります。
There are many different ways to combine IPv6 addresses and port numbers that are represented in text. Examples are shown below.
テキストで表されるIPv6アドレスとポート番号を組み合わせるには、さまざまな方法があります。例を以下に示します。
o [2001:db8::1]:80
o 2001:db8::1:80
o 2001:db8::1.80
o 2001:db8::1 port 80
o 2001:db8::1p80
o 2001:db8::1#80
The situation is not much different in IPv4, but the most ambiguous case with IPv6 is the second bullet. This is due to the "::"usage in IPv6 addresses. This style is NOT RECOMMENDED because of its ambiguity. The [] style as expressed in [RFC3986] SHOULD be employed, and is the default unless otherwise specified. Other styles are acceptable when there is exactly one style for the given context and cross-platform portability does not become an issue. For URIs containing IPv6 address literals, [RFC3986] MUST be followed, as well as the rules defined in this document.
IPv4では状況はそれほど違いはありませんが、IPv6の最も曖昧なケースは2番目の弾丸です。これは、IPv6アドレスの「::」の使用によるものです。このスタイルは、その曖昧さのために推奨されません。[RFC3986]で表現されている[]スタイルは採用する必要があり、特に指定されていない限りデフォルトです。他のスタイルは、指定されたコンテキストに正確に1つのスタイルがある場合に受け入れられ、クロスプラットフォームのポータビリティが問題になりません。IPv6アドレスリテラルを含むURISの場合、[RFC3986]と、このドキュメントで定義されているルールに従う必要があります。
Problems with prefixes are the same as problems encountered with addresses. The text representation method of IPv6 prefixes should be no different from that of IPv6 addresses.
接頭辞の問題は、アドレスで発生する問題と同じです。IPv6プレフィックスのテキスト表現方法は、IPv6アドレスのテキスト表現方法と変わらないはずです。
This document notes some examples where IPv6 addresses are compared in text format. The example on Section 3.2.5 is one that may cause a security risk if used for access control. The common practice of comparing X.509 data is done in binary format.
このドキュメントには、IPv6アドレスがテキスト形式で比較される例をいくつか示しています。セクション3.2.5の例は、アクセス制御に使用された場合にセキュリティリスクを引き起こす可能性のある例です。X.509データを比較する一般的な慣行は、バイナリ形式で行われます。
The authors would like to thank Jan Zorz, Randy Bush, Yuichi Minami, and Toshimitsu Matsuura for their generous and helpful comments in kick starting this document. We also would like to thank Brian Carpenter, Akira Kato, Juergen Schoenwaelder, Antonio Querubin, Dave Thaler, Brian Haley, Suresh Krishnan, Jerry Huang, Roman Donchenko, Heikki Vatiainen, Dan Wing, and Doug Barton for their input. Also, a very special thanks to Ron Bonica, Fred Baker, Brian Haberman, Robert Hinden, Jari Arkko, and Kurt Lindqvist for their support in bringing this document to light in IETF working groups.
著者は、このドキュメントを開始したキックでの寛大で有益なコメントについて、Jan Zorz、Randy Bush、Randy Bush、Yuichi Yuichi Matsuuraに感謝したいと思います。また、ブライアン・カーペンター、アキラ・カト、ジュエルゲン・シェーンワールダー、アントニオ・クルービン、デイブ・ターラー、ブライアン・ヘイリー、スレシュ・クリシュナン、ジェリー・ファン、ローマン・ドンチェンコ、ヘイキ・ヴァティアイネン、ダン・ウィング、ダグ・バートンに感謝します。また、Ron Bonica、Fred Baker、Brian Haberman、Robert Hinden、Jari Arkko、Kurt Lindqvistに感謝します。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC2765] Nordmark, E., "Stateless IP/ICMP Translation Algorithm (SIIT)", RFC 2765, February 2000.
[RFC2765] Nordmark、E。、「Stateless IP/ICMP翻訳アルゴリズム（SIIT）」、RFC 2765、2000年2月。
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005.
[RFC3986] Berners-Lee、T.、Fielding、R。、およびL. Masinter、「Uniform Resource Identifier（URI）：Generic Syntax」、Std 66、RFC 3986、2005年1月。
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, February 2006.
[RFC4291] Hinden、R。およびS. Deering、「IPバージョン6アドレス指定アーキテクチャ」、RFC 4291、2006年2月。
[ADDR-FORMAT] Bao, C., "IPv6 Addressing of IPv4/IPv6 Translators", Work in Progress, July 2010.
[Addr-Format] Bao、C。、「IPv4/IPv6翻訳者のアドレス指定」、2010年7月の作業。
[RFC4038] Shin, M-K., Hong, Y-G., Hagino, J., Savola, P., and E. Castro, "Application Aspects of IPv6 Transition", RFC 4038, March 2005.
[RFC4038] Shin、M-K。、Hong、Y-G。、Hagino、J.、Savola、P。、およびE. Castro、「IPv6遷移のアプリケーションの側面」、RFC 4038、2005年3月。
[RFC5214] Templin, F., Gleeson, T., and D. Thaler, "Intra-Site Automatic Tunnel Addressing Protocol (ISATAP)", RFC 5214, March 2008.
[RFC5214] Templin、F.、Gleeson、T。、およびD. Thaler、「敷地内自動トンネルアドレス指定プロトコル（ISATAP）」、RFC 5214、2008年3月。
We recommend that developers use display routines that conform to these rules. For example, the usage of getnameinfo() with flags argument NI_NUMERICHOST in FreeBSD 7.0 will give a conforming output, except for the special addresses notes in Section 5. The function inet_ntop() of FreeBSD7.0 is a good C code reference, but should not be called directly. See [RFC4038] for details.
開発者は、これらのルールに準拠するディスプレイルーチンを使用することをお勧めします。たとえば、FreeBSD 7.0のFlags引数ni_numerichostを使用したgetnameInfo（）の使用法は、セクション5の特別なアドレスノートを除き、適合出力を提供します。直接呼ばれません。詳細については、[RFC4038]を参照してください。
Authors' Addresses
著者のアドレス
Seiichi Kawamura NEC BIGLOBE, Ltd. 14-22, Shibaura 4-chome Minatoku, Tokyo 108-8558 JAPAN
Seiichi Kawamura Nec Biglobe、Ltd。14-22、Shibaura 4-Chome Minatoku、Tokyo 108-8558 Japan
Phone: +81 3 3798 6085
EMail: kawamucho@mesh.ad.jp
Masanobu Kawashima NEC AccessTechnica, Ltd. 800, Shimomata Kakegawa-shi, Shizuoka 436-8501 JAPAN
Masanobu kawashima nec Accesstechnica、Ltd。800、Shimomata kakegawa-shi、Shizuoka 436-8501 Japan
Phone: +81 537 23 9655
EMail: kawashimam@necat.nec.co.jp