[要約] RFC 9164は、IPv4およびIPv6のアドレスとプレフィックスに対するCBORタグの定義を提供します。この文書の目的は、ネットワーク設定や通信プロトコルでの効率的なアドレス表現を可能にすることです。利用場面には、IoTデバイス、モバイルアプリケーション、クラウドサービスなど、データサイズやパース速度が重要な環境が含まれます。
Internet Engineering Task Force (IETF) M. Richardson
Request for Comments: 9164 Sandelman Software Works
Category: Standards Track C. Bormann
ISSN: 2070-1721 Universität Bremen TZI
December 2021
Concise Binary Object Representation (CBOR) Tags for IPv4 and IPv6 Addresses and Prefixes
IPv4およびIPv6アドレスおよび接頭辞のための簡潔なバイナリオブジェクト表現（CBOR）タグ
Abstract
概要
This specification defines two Concise Binary Object Representation (CBOR) tags for use with IPv6 and IPv4 addresses and prefixes.
この仕様は、IPv6およびIPv4アドレスとプレフィックスで使用するための2つの簡潔なバイナリオブジェクト表現（CBOR）タグを定義しています。
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 7841.
この文書はインターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表します。それはパブリックレビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による出版の承認を受けました。インターネット規格に関する詳細情報は、RFC 7841のセクション2で利用できます。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc9164.
この文書の現在のステータス、任意のエラータ、およびフィードバックを提供する方法は、https://www.rfc-editor.org/info/frfc9164で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2021 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（C）2021 IETFの信頼と文書著者として識別された人。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://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 Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.
この文書は、この文書の公開日に有効なIETF文書（https://trustee.ietf.org/License-Info）に関するBCP 78およびIETF信頼の法的規定の対象となります。この文書に関してあなたの権利と制限を説明するので、これらの文書をよくレビューしてください。この文書から抽出されたコードコンポーネントには、信託法定規定のセクション4。
Table of Contents
目次
1. Introduction
2. Terminology
3. Protocol
3.1. Three Forms
3.1.1. Addresses
3.1.2. Prefixes
3.1.3. Interface Definition
3.2. IPv6
3.3. IPv4
4. Tag Validity
4.1. Deterministic Encoding
4.2. Encoder Considerations for Prefixes
4.3. Decoder Considerations for Prefixes
4.3.1. Example Implementation
5. CDDL
6. Security Considerations
7. IANA Considerations
7.1. Tag 54 - IPv6
7.2. Tag 52 - IPv4
7.3. Tags 260 and 261
8. References
8.1. Normative References
8.2. Informative References
Acknowledgements
Authors' Addresses
[RFC8949] defines a number of CBOR tags for common items. Tags 260 and 261 were later defined in documents listed with IANA [IANA.cbor-tags]. These tags were intended to cover addresses (260) and prefixes (261). Tag 260 distinguishes between IPv6, IPv4, and MAC [RFC7042] addresses only through the length of the byte string, making it impossible, for example, to drop trailing zeros in the encoding of IP addresses. Tag 261 was not documented well enough for use.
[RFC8949]一般的な項目のためのCBORタグの数を定義します。タグ260と261は後でIANA [IANA.CBOR-TAGS]にリストされている文書に定義されています。これらのタグは、アドレス（260）とプレフィックス（261）をカバーすることを意図していました。タグ260は、IPv6、IPv4、およびMAC [RFC7042]を、バイト文字列の長さを介してのみ区別し、たとえば、IPアドレスの符号化で末尾のゼロを削除することを不可能にします。タグ261は使用のために十分に文書化されていない。
This specification defines tags 54 and 52 to explicitly indicate use of IPv6 or IPv4 by the tag number. These new tags are intended to be used in preference to tags 260 and 261. They provide formats for IPv6 and IPv4 addresses, prefixes, and addresses with prefixes, while explicitly indicating use of IPv6 or IPv4. The prefix format omits trailing zeroes in the address part. (Due to the complexity of testing, the value of omitting trailing zeros for the pure address format was considered nonessential, and support for that is not provided in this specification.) This specification does not deal with MAC addresses (Section 2 of [RFC7042]).
この仕様は、タグ番号によるIPv6またはIPv4の使用を明示的に示すようにタグ54および52を定義する。これらの新しいタグは、タグ260および261を好みに使用することを意図している。プレフィックス形式はアドレス部分の末尾のゼロを省略します。（テストの複雑さのため、純粋なアドレスフォーマットの末尾ゼロを省略するという値は、非エネルギーと見なされ、この仕様ではサポートされていません。）この仕様はMACアドレスを扱いません（[RFC7042]のセクション2）。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
この文書のキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", および "OPTIONAL" はBCP 14 [RFC2119] [RFC8174]で説明されているように、すべて大文字の場合にのみ解釈されます。
These tags can be applied to byte strings to represent a single address.
これらのタグは、単一のアドレスを表すためにバイト文字列に適用できます。
This form is called the "Address Format".
このフォームは「アドレス形式」と呼ばれます。
When applied to an array that starts with an unsigned integer, the tags represent a CIDR-style prefix of that length.
符号なし整数で始まるアレイに適用されると、タグはその長さのCIDRスタイルのプレフィックスを表します。
When the Address Format (i.e., without prefix) appears in a context where a prefix is expected, then it is to be assumed that all bits are relevant. That is, for IPv4, a /32 is implied, and for IPv6, a /128 is implied.
プレフィックスが予想されるコンテキストにアドレスフォーマット（すなわち）フォーマットが表示されると、すべてのビットが関連性があると仮定されます。すなわち、IPv4、A / 32が暗示され、IPv6の場合、A / 128が暗示される。
This form is called the "Prefix Format".
このフォームは「プレフィックス形式」と呼ばれます。
When applied to an array that starts with a byte string, which stands for an IP address, followed by an unsigned integer giving the bit length of a prefix built out of the first length bits of the address, the tags represent information that is commonly used to specify both the network prefix and the IP address of an interface.
IPアドレスを表すバイト文字列で始まるアレイに適用され、続いてアドレスの最初の長さのビットから構築されているプレフィックスのビット長を行う符号なし整数が続く場合、タグは一般的に使用されている情報を表します。ネットワークプレフィックスとインターフェイスのIPアドレスの両方を指定するには。
The length of the byte string is always 16 bytes (for IPv6) and 4 bytes (for IPv4).
バイト文字列の長さは常に16バイト（IPv6の場合）と4バイト（IPv4の場合）です。
This form is called the "Interface Format".
このフォームは「インタフェース形式」と呼ばれます。
Interface Format definitions support an optional third element to the array, which is to be used as the IPv6 link-local zone identifier from Section 6 of [RFC4007]; for symmetry, this is also provided for IPv4 as in [RFC4001] and [RFC6991]. The zone identifier may be an integer, in which case it is to be interpreted as the interface index. It may be a text string, in which case it is to be interpreted as an interface name.
インターフェイスフォーマット定義は、[RFC4007]のセクション6のIPv6リンクローカルゾーンIDとして使用される配列に対するオプションの3番目の要素をサポートしています。対称性については、[RFC4001]と[RFC6991]のようにIPv4にも提供されています。ゾーン識別子は整数であり得るので、その場合はインタフェースインデックスとして解釈されるべきである。テキスト文字列かもしれません。その場合、インターフェイス名として解釈されます。
As explained in [RFC4007], the zone identifiers are strictly local to the node. They are useful for communications within a node about connected addresses (for instance, where a link-local peer is discovered by one daemon and another daemon needs to be informed). They may also have utility in some management protocols.
[RFC4007]で説明したように、ゾーン識別子は厳密にノードに対してローカルです。それらは、接続されているアドレスに関するノード内の通信に便利です（たとえば、リンクローカルピアが1つのデーモンによって検出され、別のデーモンを知らせる必要がある場合）。また、管理プロトコルによってもユーティリティがある可能性があります。
In the cases where the Interface Format is being used to represent only an address with a zone identifier and no interface prefix information, the prefix length may be replaced with the CBOR "null" (0xF6).
ゾーン識別子を持つアドレスのみを表すためにインタフェースフォーマットが使用されている場合には、プレフィックス長はCBOR "NULL"（0xF6）に置き換えることができます。
IANA has allocated tag 54 for IPv6 uses. (This is the ASCII code for '6'.)
IANAはIPv6の使用のためにタグ54を割り当てました。（これは '6'のASCIIコードです。）
An IPv6 address is to be encoded as a sixteen-byte byte string (Section 3.1 of [RFC8949], major type 2), enclosed in tag number 54.
IPv6アドレスは、タグ番号54で囲まれた16バイトのバイト文字列としてエンコードされます（[RFC8949]のセクション3.1、メジャータイプ2）。
For example:
例えば：
54(h'20010db81234deedbeefcafefacefeed')
54（H'20010DB81234DEEDBEEFCAFEFECEEFED '）
An IPv6 prefix, such as 2001:db8:1234::/48, is to be encoded as a two-element array, with the length of the prefix first. See Section 4 for the detailed construction of the second element.
2001：DB8：1234 :: / 48などのIPv6プレフィックスは、プレフィックスの長さを最初に符号化します。2番目の要素の詳細な構成についてはセクション4を参照してください。
For example:
例えば：
54([48, h'20010db81234'])
54（[48、H'20010DB81234 ']）
An IPv6 address combined with a prefix length, such as one used for configuring an interface, is to be encoded as a two-element array, with the (full-length) IPv6 address first and the length of the associated network the prefix next; a third element can be added for the zone identifier.
インタフェースを構成するために使用されるもののようなプレフィックス長と組み合わされたIPv6アドレスは、2要素配列として、（全長）IPv6アドレスを最初に、関連するネットワークの長さにプレフィックスを次に符号化します。ゾーン識別子のために3番目の要素を追加することができます。
For example:
例えば：
54([h'20010db81234deedbeefcafefacefeed', 56])
54（[H'20010DB81234DeedBeeFcafeFaceFeed '、56]）
The address-with-prefix form can be reliably distinguished from the prefix form only in the sequence of the array elements.
address-with-prefix形式は、配列要素のシーケンス内のプレフィックス形式とのみ確実に区別できます。
An example of a link-local IPv6 address with a 64-bit prefix:
64ビットプレフィックスを持つリンクローカルIPv6アドレスの例：
54([h'fe8000000000020202fffffffe030303', 64, 'eth0'])
54（[h'fe800000000202FFFFFFFE030303 '、64、' eth0 ']）
with a numeric zone identifier:
数値区域識別子を使用すると、
54([h'fe8000000000020202fffffffe030303', 64, 42])
54（[H'FE80000000020202FFFFFFFE030303 '、64,42]）
An IPv6 link-local address without a prefix length:
プレフィックス長のないIPv6リンクローカルアドレス：
54([h'fe8000000000020202fffffffe030303', null, 42])
54（[H'FE80000000000202FFFFFFFE030303 '、NULL、42]）
Zone identifiers may be used with any kind of IP address, not just link-local addresses. In particular, they are valid for multicast addresses, and there may still be some significance for Globally Unique Addresses (GUAs).
ゾーン識別子は、リンクローカルアドレスだけでなく、あらゆる種類のIPアドレスで使用できます。特に、それらはマルチキャストアドレスに有効であり、グローバルに一意のアドレス（GUAS）にとっては何らかの意味がある可能性があります。
IANA has allocated tag 52 for IPv4 uses. (This is the ASCII code for '4'.)
IANAは、IPv4の用途にタグ52を割り当てました。（これは '4'のASCIIコードです。）
An IPv4 address is to be encoded as a four-byte byte string (Section 3.1 of [RFC8949], major type 2), enclosed in tag number 52.
IPv4アドレスは、タグ番号52で囲まれた4バイトのバイト文字列としてエンコードされます（[RFC8949]のセクション3.1、メジャータイプ2）。
For example:
例えば：
52(h'c0000201')
52（h'c0000201 '）
An IPv4 prefix, such as 192.0.2.0/24, is to be encoded as a two-element array, with the length of the prefix first. See Section 4 for the detailed construction of the second element.
192.0.2.0/24などのIPv4プレフィックスは、最初にプレフィックスの長さを持つ2要素配列としてエンコードされます。2番目の要素の詳細な構成についてはセクション4を参照してください。
For example:
例えば：
52([24, h'c00002'])
52（[24、H'C00002 ']）
An IPv4 address combined with a prefix length, such as being used for configuring an interface, is to be encoded as a two-element array, with the (full-length) IPv4 address first and the length of the associated network the prefix next; a third element can be added for the zone identifier.
インタフェースを構成するために使用されるなどのプレフィックス長と組み合わされたIPv4アドレスは、（フルレングス）IPv4アドレスが最初に（全長）IPv4アドレスと、関連するネットワークの長さに接頭辞を次に符号化することです。ゾーン識別子のために3番目の要素を追加することができます。
For example, 192.0.2.1/24 is to be encoded as a two-element array, with the length of the prefix (implied 192.0.2.0/24) last.
たとえば、192.0.2.1 / 24は2要素配列としてエンコードされ、プレフィックスの長さ（192.0.2.0/24）が最後に符号化されます。
52([h'c0000201', 24])
52（[H'C0000201 '、24]）
The address-with-prefix form can be reliably distinguished from the prefix form only in the sequence of the array elements.
address-with-prefix形式は、配列要素のシーケンス内のプレフィックス形式とのみ確実に区別できます。
This section discusses when tag 54 or tag 52 is valid (Section 5.3.2 of [RFC8949]). As with all CBOR tags, validity checking can be handled in a generic CBOR library or in the application. A generic CBOR library needs to document whether and how it handles validity checking.
このセクションでは、タグ54またはタグ52が有効な場合に説明します（[RFC8949]のセクション5.3.2）。すべてのCBORタグと同様に、有効性チェックは、一般的なCBOBOBORライブラリまたはアプリケーションで処理できます。一般的なCBOBLICライブラリは、有効性チェックを処理するかどうかを文書化する必要があります。
The rule ip-address-or-prefix in Figure 1 shows how to check the overall structure of these tags and their content, the ranges of integer values, and the lengths of byte strings. An instance of tag 52 or 54 is valid if it matches that rule and, for ipv6-prefix and ipv4-prefix, the considerations of Sections 4.2 and 4.3.
図1のルールのIP-address-またはPrefixは、これらのタグの全体的な構造体とそのコンテンツ、整数値の範囲、およびバイト文字列の長さを確認する方法を示しています。タグ52または54のインスタンスは、それがそのルールと一致し、IPv6プレフィックスとIPv4プレフィックスの場合、セクション4.2と4.3の考慮事項を有効です。
The tag validity rules, combined with the rules in Section 4.2.1 of [RFC8949], lead to deterministic encoding for tags 54 and 52 and require no further additional deterministic encoding considerations as per Section 4.2.2 of [RFC8949].
タグの有効性規則は、[RFC8949]のセクション4.2.1の規則と組み合わされて、タグ54および52の決定論的符号化を招き、[RFC8949]のセクション4.2.2と同様にさらに追加の決定論的符号化の考慮を必要としない。
For the byte strings used as the second element in the array representing a prefix:
接頭辞を表す配列内の2番目の要素として使用されるバイト文字列の場合
(1) An encoder MUST set any unused bytes and any unused bits in the final byte, if any, to zero. Unused bytes (or bits) are bytes (or bits) that are not covered by the prefix length given. So, for example, 2001:db8:1230::/44 MUST be encoded as:
(1) エンコーダは、未使用のバイトと未使用のビットがFinal Byteでゼロに設定する必要があります。未使用のバイト（またはビット）は、指定されたプレフィックス長によってカバーされていないバイト（またはビット）です。そのため、たとえば、2001：DB8：1230 :: / 44は次のようにエンコードされている必要があります。
54([44, h'20010db81230'])
54（[44、H'20010DB81230 ']）
even though variations like:
バリエーションのような変化が
54([44, h'20010db81233']) 54([44, h'20010db8123f']) 54([44, h'20010db8123012'])
54（[44、H'20010DB81233 ']）54（[44、H'20010DB8123F']）54（[44、H'20010DB8123012 ']）
start with the same 44 bits but are not valid.
同じ44ビットから始めますが、無効です。
(Analogous examples can be constructed for IPv4 prefixes.)
（IPv4プレフィックス用の類似の例を構築できます。）
(2) An encoder MUST then omit any right-aligned (trailing) sequence of bytes in which the bytes are all zeros.
(2) その後、エンコーダは、バイトがすべてゼロであるバイトの右寄せ（末尾）シーケンスを省く必要があります。
There is no relationship between the number of bytes omitted and the prefix length. For instance, the prefix 2001:db8::/64 is encoded as:
バイト数省略とプレフィックス長の関係はありません。たとえば、prefix 2001：DB8 :: / 64は次のようにエンコードされています。
54([64, h'20010db8'])
54（[64、H'20010DB8 ']）
A decoder MUST check that all unused bits encoded in the byte string ipv6-prefix-bytes/ipv4-prefix-bytes, i.e., the bits to the right of the prefix length, are zero.
デコーダは、バイト文字列IPv6プレフィックスバイト/ ipv4-プレフィックスバイト、すなわちプレフィックス長の右側のビットでエンコードされたすべての未使用ビットがゼロであることを確認する必要があります。
A decoder MUST also check that the byte string does not end in a zero byte.
デコーダはまた、バイト文字列がゼロバイトで終わらないことを確認する必要があります。
Since encoders are required to remove zero-valued trailing bytes, a decoder MUST handle cases where a prefix length specifies that more bits are relevant than are actually present in the byte string.
エンコーダはゼロ値の末尾バイトを削除するために必要なので、デコーダは、プレフィックス長が、実際にバイト文字列に存在するよりも多くのビットが関連性があることを指定するケースを処理する必要があります。
As an example, ::/128 is encoded as
54([128, h''])
54（[128、H '']）
A recommendation for prefix decoder implementations is to first create an array of 16 (or 4) zero bytes.
プレフィックスデコーダ実装の推奨事項は、まず16（または4）ゼロバイトの配列を作成することです。
Then, taking whichever is smaller between (a) the length of the included byte string and (b) the number of bytes covered by the prefix length rounded up to the next multiple of 8, fail if that number is greater than 16 (or 4) and then copy that many bytes from the byte string into the byte array.
その後、（a）含まれているバイト文字列の長さと（b）次の倍数までのプレフィックス長でカバーされているバイト数は、その数が16（または4以上にすると失敗します。）してから、そのようなバイト文字列からバイト配列にその数バイトをコピーします。
Finally, when looking at the number of unused bits in the last byte (if any) of the range covered by the prefix length, check that any unused bits in the byte string are zero:
最後に、プレフィックス長によってカバーされている範囲の最後のバイト（ある場合）の未使用ビット数を見ると、バイト文字列の未使用のビットがゼロであることを確認してください。
unused_bits = (8 - (prefix_length_in_bits % 8)) % 8;
if (length_in_bytes > 0 &&
(address_bytes[length_in_bytes - 1] & ~(0xFF << unused_bits))
!= 0)
fail();
For use with Concise Data Definition Language (CDDL) [RFC8610], the type names defined in Figure 1 are recommended:
簡潔なデータ定義言語（CDDL）[RFC8610]で使用するために、図1に定義されている型名をお勧めします。
ip-address-or-prefix = ipv6-address-or-prefix / ipv4-address-or-prefix
ip-address-or-prefix = IPv6-address-または-prefix / ipv4-address-または-prefix
ipv6-address-or-prefix = #6.54(ipv6-address /
ipv6-address-with-prefix /
ipv6-prefix)
ipv4-address-or-prefix = #6.52(ipv4-address /
ipv4-address-with-prefix /
ipv4-prefix)
ipv6-address = bytes .size 16 ipv4-address = bytes .size 4
IPv6-address =バイト.Size 16 IPv4-address = Bytes .Size 4
ipv6-address-with-prefix = [ipv6-address,
ipv6-prefix-length / null,
?ip-zone-identifier]
ipv4-address-with-prefix = [ipv4-address,
ipv4-prefix-length / null,
?ip-zone-identifier]
ipv6-prefix-length = 0..128 ipv4-prefix-length = 0..32
IPv6プレフィックス長= 0..128 IPv4プレフィックス= 0..32
ipv6-prefix = [ipv6-prefix-length, ipv6-prefix-bytes]
ipv4-prefix = [ipv4-prefix-length, ipv4-prefix-bytes]
ipv6-prefix-bytes = bytes .size (uint .le 16) ipv4-prefix-bytes = bytes .size (uint .le 4)
IPv6-prefix-bytes =バイト.Size（UINT .Le 16）IPv4-prefix-bytes = bytes .size（uint .le 4）
ip-zone-identifier = uint / text
Figure 1: CDDL Types for Tags 54 and 52
図1：タグ54と52のCDDLタイプ
This document provides a CBOR encoding for IPv4 and IPv6 address information. Any applications using these encodings will need to consider the security implications of this data in their specific context. For example, identifying which byte sequences in a protocol are addresses may allow an attacker or eavesdropper to better understand what parts of a packet to attack.
この文書は、IPv4およびIPv6アドレス情報のためのCBORエンコーディングを提供します。これらのエンコーディングを使用するアプリケーションは、特定のコンテキストでこのデータのセキュリティの影響を考慮する必要があります。例えば、プロトコル内のどのバイトシーケンスがアドレスであるかを識別することで、攻撃者または盗聴者が攻撃するパケットの一部をよりよく理解することができる。
Applications need to check the validity (Section 4) of a tag before acting on any of its contents. If the validity checking is not done in the generic CBOR decoder, it needs to be done in the application; in any case, it needs to be done before the tag is transformed into a platform-specific representation that could conceal validity errors.
アプリケーションは、その内容のいずれかに行動する前にタグの有効性（セクション4）を確認する必要があります。有効性チェックが一般的なCBOBOBORデコーダで行われていない場合は、アプリケーションで実行する必要があります。いずれにせよ、タグが有効性エラーを隠す可能性があるプラットフォーム固有の表現に変換される前に行われる必要があります。
The right-hand bits of the prefix, after the prefix length, are set to zero by this protocol. (Otherwise, a malicious party could use them to transmit covert data in a way that would not affect the primary use of this encoding. Such abuse is detected by tag validity checking and can also be detected by examination of the raw protocol bytes.)
プレフィックス長後のプレフィックスの右側のビットは、このプロトコルによってゼロに設定されます。（悪意のある当事者は、この符号化の主な使用に影響を与えないような方法で秘密データを送信するためにそれらを使用することができます。そのような虐待はタグの妥当性検査によって検出され、生プロトコルバイトの検査によっても検出されます。）
IANA has allocated two tags from the Specification Required [RFC8126] area of the "Concise Binary Object Representation (CBOR) Tags" registry [IANA.cbor-tags]:
IANAは、「簡潔なバイナリオブジェクト表現（CBOR）タグ」レジストリ[IANA.CBOR-TAGS]の仕様から2つのタグを割り当てました。
Data Item: byte string or array Semantics: IPv6, [prefixlen,IPv6], [IPv6,prefixpart]
データ項目：バイト文字列またはアレイセマンティクス：IPv6、[PrefixLen、IPv6]、[IPv6、PrefixPart]
Data Item: byte string or array Semantics: IPv4, [prefixlen,IPv4], [IPv4,prefixpart]
データ項目：バイト文字列またはアレイセマンティクス：IPv4、[PrefixLen、IPv4]、[IPv4、PrefixPart]
IANA has added the note "DEPRECATED in favor of 52 and 54 for IP addresses" to registrations 260 and 261.
IANAは、登録260および261に「IPアドレスのために52および54を支持する」というノートを追加しました。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.
[RFC2119] BRADNER、S、「RFCで使用するためのキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<https：//www.rfc-editor.org/info/RFC2119>。
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, <https://www.rfc-editor.org/info/rfc8126>.
[RFC8126]コットン、M.、Leiba、B.およびT.Narten、「RFCSのIANAに関する考察のためのガイドライン」、BCP 26、RFC 8126、DOI 10.17487 / RFC8126、2017年6月、<https：// www.rfc-editor.org / info / rfc8126>。
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8174] Leiba、B.、RFC 2119キーワードの「大文字の曖昧さ」、BCP 14、RFC 8174、DOI 10.17487 / RFC8174、2017年5月、<https：//www.rfc-editor.org/info/RFC8174>。
[RFC8610] Birkholz, H., Vigano, C., and C. Bormann, "Concise Data Definition Language (CDDL): A Notational Convention to Express Concise Binary Object Representation (CBOR) and JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610, June 2019, <https://www.rfc-editor.org/info/rfc8610>.
[RFC8610] Birkholz、H.、Vigano、C. Bormann、「簡潔なデータ定義言語（CDDL）：簡潔なバイナリオブジェクト表現（CBOR）とJSONデータ構造を表現する表記規則」、RFC 8610、DOI 10.17487/ RFC8610、2019年6月、<https://www.rfc-editor.org/info/rfc8610>。
[RFC8949] Bormann, C. and P. Hoffman, "Concise Binary Object Representation (CBOR)", STD 94, RFC 8949, DOI 10.17487/RFC8949, December 2020, <https://www.rfc-editor.org/info/rfc8949>.
[RFC8949] Bormann、C.およびP.HOFFMAN、「簡潔なバイナリオブジェクト表現（CBOR）」、STD 94、RFC 8949、DOI 10.17487 / RFC8949、2020年12月、<https：//www.rfc-editor.org/info/ RFC8949>。
[IANA.cbor-tags] IANA, "Concise Binary Object Representation (CBOR) Tags", <https://www.iana.org/assignments/cbor-tags>.
[IANA.CBOR-TAGS] IANA、「簡潔なバイナリオブジェクト表現（CBOR）タグ」、<https：//www.iana.org/assignments/cbor-tags>。
[RFC4001] Daniele, M., Haberman, B., Routhier, S., and J. Schoenwaelder, "Textual Conventions for Internet Network Addresses", RFC 4001, DOI 10.17487/RFC4001, February 2005, <https://www.rfc-editor.org/info/rfc4001>.
[RFC4001] Daniele、M.、Haberman、B.、Routhier、S.、およびJ.Schoenwaelder、「インターネットネットワークアドレスのためのテキスト規約」、RFC 4001、DOI 10.17487 / RFC4001、2005年2月、<https：// www。rfc-editor.org/info/rfc4001>。
[RFC4007] Deering, S., Haberman, B., Jinmei, T., Nordmark, E., and B. Zill, "IPv6 Scoped Address Architecture", RFC 4007, DOI 10.17487/RFC4007, March 2005, <https://www.rfc-editor.org/info/rfc4007>.
[RFC4007] Theering、S.、Haberman、B.、Jinmei、T.、Nordmark、E.、およびB.Zill、「IPv6スコープアドレスアーキテクチャ」、RFC 4007、DOI 10.17487 / RFC4007、2005年3月、<https：//www.rfc-editor.org/info/rfc4007>。
[RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", RFC 6991, DOI 10.17487/RFC6991, July 2013, <https://www.rfc-editor.org/info/rfc6991>.
[RFC6991] Schoenwaelder、J.、Ed。、「共通ヤンデータ型」、RFC 6991、DOI 10.17487 / RFC6991、2013年7月、<https：//www.rfc-editor.org/info/rfc6991>。
[RFC7042] Eastlake 3rd, D. and J. Abley, "IANA Considerations and IETF Protocol and Documentation Usage for IEEE 802 Parameters", BCP 141, RFC 7042, DOI 10.17487/RFC7042, October 2013, <https://www.rfc-editor.org/info/rfc7042>.
[RFC7042]イーストレイク3RD、D.およびJ.Ely、 "IANAの考慮事項およびIETFプロトコルおよびIEEE 802パラメータのためのドキュメンテーションの使用"、BCP 141、RFC 7042、DOI 10.17487 / RFC7042、2013年10月、<https：//www.rfc-editor.org/info/rfc7042>。
Acknowledgements
謝辞
Roman Danyliw, Donald Eastlake, Ben Kaduk, Barry Leiba, and Éric Vyncke reviewed the document and provided suggested text. Jürgen Schönwälder helped find the history of IPv4 zone identifiers.
Roman Danyliw、Donald Eastlake、Ben Kaduk、Barry Leiba、およびEric Vynckeはその文書を検討し、提案されたテキストを提供しました。JürgenSchönwälderがIPv4ゾーン識別子の履歴を見つけました。
Authors' Addresses
著者の住所
Michael Richardson Sandelman Software Works
Michael Richardson Sandelman Software Works.
Email: mcr+ietf@sandelman.ca
Carsten Bormann Universität Bremen TZI Germany
Carsten BormannUniversitätブレーメンTZIドイツ
Email: cabo@tzi.org