This specification defines two Concise Binary Object Representation (CBOR) tags for use with IPv6 and IPv4 addresses and prefixes.
この仕様書は、IPv6およびIPv4アドレスおよびプレフィックスに使用するための2つの簡潔なバイナリオブジェクト表現(CBOR)タグを定義します。
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/rfc9164で入手できます。
Copyright (c) 2021 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright (c) 2021 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 (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.
この文書は、BCP 78およびIETFドキュメントに関するIETFトラストの法的規定（https://trustee.ietf.org/license-info）にしたがう必要があります。これらの文書をよく確認し、この文書に関するあなたの権利と制限を説明しています。この文書から抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
[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よりも優先して使用することを意図しています。 IPv6およびIPv4アドレス、プレフィックス、およびプレフィックス付きアドレスのフォーマットを提供し、IPv6またはIPv4の使用を明示的に示します。 プレフィックスのフォーマットでは、アドレス部分の末尾のゼロを省略します。 (純粋なアドレスフォーマットで末尾のゼロを省略することの価値は、テストの複雑さのため、非本質的と考えられ、この仕様書ではサポートされていません。) この仕様書ではMACアドレス([RFC7042]のSection 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）」、「推奨されません（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の場合は/32が暗示され、IPv6の場合は/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アドレスを表し、その後にアドレスの最初のlengthビットから構築されたプレフィックスのビット長を示す符号なし整数が続きます。これらのタグは、インタフェースのネットワークプレフィックスとIPアドレスの両方を指定するために一般的に使用される情報を表します。
The length of the byte string is always 16 bytes (for IPv6) and 4 bytes (for IPv4).
バイト文字列の長さは、常にIPv6の場合は16バイト、IPv4の場合は4バイトです。
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.
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を割り当てています。 (これはASCIIコードの「6」です。)
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アドレスは、16バイトのバイト文字列([RFC8949]のSection 3.1, メジャータイプ2)としてエンコードされ、タグ番号54で囲まれます。
For example:
例:
54(h'20010db81234deedbeefcafefacefeed')
54(h'20010db81234deedbeefcafefacefeed')
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要素の配列としてエンコードされます。 2番目の要素の詳細な構造については、Section 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:
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.
アドレスとプレフィックスを含む形式は、配列要素のシーケンスのみでプレフィックス形式と確実に区別できます。
An example of a link-local IPv6 address with a 64-bit prefix:
64ビットのプレフィックスを持つリンクローカルIPv6アドレスの例:
54([h'fe8000000000020202fffffffe030303', 64, 'eth0'])
54([h'fe8000000000020202fffffffe030303', 64, 'eth0'])
with a numeric zone identifier:
数値のゾーン識別子を持つ場合:
54([h'fe8000000000020202fffffffe030303', 64, 42])
54([h'fe8000000000020202fffffffe030303', 64, 42])
An IPv6 link-local address without a prefix length:
プレフィックス長を持たないIPv6リンクローカルアドレス:
54([h'fe8000000000020202fffffffe030303', null, 42])
54([h'fe8000000000020202fffffffe030303', 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アドレスで使用できます。 特に、マルチキャストアドレスに対しても有効であり、グローバルユニークアドレス(GUA)に対してもいくらかの意義がある可能性があります。
IANA has allocated tag 52 for IPv4 uses. (This is the ASCII code for '4'.)
IANAは、IPv4の使用に対してタグ52を割り当てています。 (これはASCIIコードの「4」です。)
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アドレスは、4バイトのバイト文字列([RFC8949]のSection 3.1, メジャータイプ2)としてエンコードされ、タグ番号52で囲まれます。
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番目の要素の詳細な構造については、Section 4を参照してください。
For example:
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アドレスは、2要素の配列としてエンコードされます。 最初に(完全な長さの)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.
アドレスとプレフィックスを含む形式は、配列要素のシーケンスのみでプレフィックス形式と確実に区別できます。
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]のSection 5.3.2) すべてのCBORタグと同様に、妥当性チェックは一般的なCBORライブラリまたはアプリケーションで処理できます。 一般的なCBORライブラリは、妥当性チェックをどのように処理するかを文書化する必要があります。
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.
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]のSection 4.2.1のルールと組み合わせて、タグ54および52の決定論的エンコーディングを導き、[RFC8949]のSection 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) エンコーダーは、使用されていないバイトと最後のバイトの使用されていないビットをゼロに設定しなければなりません（MUST）。
使用されていないバイト(またはビット)とは、指定されたプレフィックス長でカバーされていないバイト(またはビット)のことです。
例えば、2001:db8:1230::/44は、次のようにエンコードしなければなりません（MUST）:
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) エンコーダーは、バイトがすべてゼロである右揃え(末尾)のバイト列を省略しなければなりません（MUST）。
There is no relationship between the number of bytes omitted and the prefix length. For instance, the prefix 2001:db8::/64 is encoded as:
省略されたバイト数とプレフィックス長の間には関係がありません。 例えば、プレフィックス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-prefix-bytes/ipv4-prefix-bytesのバイト文字列にエンコードされたすべての未使用ビット(つまり、プレフィックス長の右側のビット)がゼロであることを確認しなければなりません（MUST）。
A decoder MUST also check that the byte string does not end in a zero byte.
デコーダーは、バイト文字列が末尾にゼロバイトを持たないことを確認しなければなりません（MUST）。
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.
エンコーダーは、ゼロ値の末尾バイトを削除する必要があるため、デコーダーは、バイト文字列に実際に存在するビットよりも多くのビットが関連するプレフィックス長を指定する場合を処理しなければなりません（MUST）。
As an example, ::/128 is encoded as
例えば、::/128は次のようにエンコードされます:
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)次の8の倍数に切り上げたプレフィックス長でカバーされるバイト数のうち、小さい方を取り、その数が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:
最後に、プレフィックス長でカバーされる範囲の最後のバイト(ある場合)の未使用ビット数を調べるときは、バイト文字列の未使用ビットがすべてゼロであることを確認しなければなりません（MUST）。
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();
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();
ip-address-or-prefix = ipv6-address-or-prefix /
ipv4-address-or-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-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-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)
ip-zone-identifier = uint / text
ip-address-or-prefix = ipv6-address-or-prefix /
ipv4-address-or-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-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-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)
ip-zone-identifier = uint / text
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.
アプリケーションは、タグの内容を処理する前に、タグの妥当性(Section 4)を確認する必要があります。 汎用CBORデコーダーで妥当性チェックが行われていない場合は、アプリケーションで行う必要があります。 いずれにせよ、タグがプラットフォーム固有の表現に変換される前に、妥当性エラーを隠す可能性があるため、妥当性チェックを行う必要があります。
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は、「Concise Binary Object Representation (CBOR) Tags」レジストリ[IANA.cbor-tags]の「Specification Required」エリアから2つのタグを割り当てました。[RFC8126]:
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に代わって非推奨」という注釈を追加しました。
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、Éric Vynckeが文書をレビューし、テキストの提案を行いました。 Jürgen SchönwälderはIPv4ゾーン識別子の履歴を見つけるのに役立ちました。