Internet Engineering Task Force (IETF) P. Thubert
Request for Comments: 9927
Updates: 8928 A. Rashid
Category: Standards Track Politecnico di Bari
ISSN: 2070-1721 February 2026
This document updates "Address-Protected Neighbor Discovery for Low-Power and Lossy Networks" (RFC 8928) by changing the position of the C-flag in the Extended Address Registration Option (EARO) and registering it with IANA.
この文書は、拡張アドレス登録オプション (EARO) の C フラグの位置を変更し、IANA に登録することにより、「低電力および損失の多いネットワークのためのアドレス保護された近隣探索」(RFC 8928) を更新します。
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.
このドキュメントは Internet Engineering Task Force (IETF) の成果物です。これは IETF コミュニティのコンセンサスを表しています。この文書は公開レビューを受け、Internet Engineering Steering Group (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/rfc9927.
この文書の現在のステータス、正誤表、およびそれに対するフィードバックの提供方法に関する情報は、https://www.rfc-editor.org/info/rfc9927 で入手できます。
Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright (c) 2026 IETF Trust および文書の著者として特定された人物。無断転載を禁じます。
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) の対象となります。これらの文書には、この文書に関するお客様の権利と制限が記載されているため、注意深くお読みください。このドキュメントから抽出されたコード コンポーネントには、トラスト法的規定のセクション 4.e に記載されている改訂 BSD ライセンス テキストが含まれている必要があり、改訂 BSD ライセンスに記載されているように保証なしで提供されます。
1. Introduction
2. Terminology
2.1. Requirements Language
2.2. Related Documents
2.3. Acronyms
3. Updating RFC 8928
4. Security Considerations
5. Operational Considerations
6. IANA Considerations
6.1. Bit Position of the C-flag
7. References
7.1. Normative References
7.2. Informative References
Authors' Addresses
The Address-Protected Neighbor Discovery for Low-Power and Lossy Networks (AP-ND) [RFC8928] defined the C-flag in EARO. It is used to indicate that the Registration Ownership Verifier (ROVR) field contains a Crypto-ID and that the 6LoWPAN Node (6LN) may be challenged for ownership of the registered address. Initially, [RFC8928] defined the C-flag in the EARO in bit position 3; later, [RFC9685] defined the P-Field in bits 2 and 3 of the EARO flags field with proper IANA registration, causing an overlap with Figure 1 of [RFC8928], which depicts the location of the C-flag.
低電力および損失の多いネットワークのためのアドレス保護された近隣探索 (AP-ND) [RFC8928] は、EARO の C フラグを定義しました。これは、登録所有権検証者 (ROVR) フィールドに暗号 ID が含まれていること、および 6LoWPAN ノード (6LN) が登録アドレスの所有権を要求される可能性があることを示すために使用されます。当初、[RFC8928] は EARO のビット位置 3 に C フラグを定義しました。その後、[RFC9685] は適切な IANA 登録を使用して EARO フラグ フィールドのビット 2 および 3 に P フィールドを定義しました。これにより、C フラグの位置を示す [RFC8928] の図 1 との重複が生じました。
This specification updates [RFC8928] by repositioning the C-flag as bit 1 of the EARO flags field, thereby preventing conflicts.
この仕様は、C フラグを EARO フラグ フィールドのビット 1 として再配置することにより [RFC8928] を更新し、それによって競合を防止します。
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] で説明されているように解釈されます。
This document uses terms and concepts that are discussed in IPv6 Neighbor Discovery (ND) [RFC4861], [RFC4862], as well as 6LoWPAN-ND [RFC6775], [RFC8505], [RFC8928], [RFC8929], [RFC9685], and [RFC9926].
この文書では、IPv6 近隣探索 (ND) [RFC4861]、[RFC4862]、および 6LoWPAN-ND [RFC6775]、[RFC8505]、[RFC8928]、[RFC8929]、[RFC9685]、および [RFC9926] で説明されている用語と概念を使用します。
This document uses the following abbreviations:
このドキュメントでは次の略語を使用します。
6LN:
6LN:
6LoWPAN Node
6LoWPANノード
EARO:
アーロ:
Extended Address Registration Option
拡張アドレス登録オプション
ND:
ND:
Neighbor Discovery
隣人発見
RATInd:
RATInd:
Registered Address Type Indicator
登録アドレスタイプインジケーター
ROVR:
ROVR:
Registration Ownership Verifier
登録所有権検証者
[RFC8928] incorrectly refers to the Extended Address Registration Option (EARO) as the Enhanced Address Registration Option. This specification corrects this terminology throughout the document.
[RFC8928] は、拡張アドレス登録オプション (EARO) を誤って拡張アドレス登録オプションと呼んでいます。この仕様では、ドキュメント全体でこの用語を修正します。
In [RFC8928], the C-flag is specified in the EARO flags field at bit position 3 (as depicted in Figure 1 of [RFC8928]); however, [RFC8928] fails to register its position with IANA. Later, [RFC9685] defined the P-Field in bits 2 and 3 of the EARO flags field and obtained proper IANA registration, but this introduced an overlap with the representation in [RFC8928]. To resolve the conflict, this specification updates [RFC8928] by repositioning the C-flag to bit 1 of the EARO flags field, ensuring there are no overlapping definitions.
[RFC8928] では、C フラグは EARO フラグ フィールドのビット位置 3 で指定されます ([RFC8928] の図 1 に示されているように)。しかし、[RFC8928] はその立場を IANA に登録できません。その後、[RFC9685] は EARO フラグ フィールドのビット 2 および 3 で P フィールドを定義し、適切な IANA 登録を取得しましたが、これにより [RFC8928] の表現との重複が生じました。この矛盾を解決するために、この仕様では、C フラグを EARO フラグ フィールドのビット 1 に再配置することで [RFC8928] を更新し、重複する定義がないことを保証します。
Figure 1 replaces Figure 1 in [RFC8928] in the case of an EARO used in an NS message.
NS メッセージで使用される EARO の場合、図 1 は [RFC8928] の図 1 を置き換えます。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |F|Prefix Length| Opaque |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|r|C| P | I |R|T| TID | Registration Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
... Registration Ownership Verifier (ROVR) ...
| (64, 128, 192, or 256 bits) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: Extended Address Registration Option (EARO) Format for Use in NS Messages
図 1: NS メッセージで使用する拡張アドレス登録オプション (EARO) 形式
Figure 2 replaces Figure 1 in [RFC8928] in the case of an EARO used in an NA message. The difference between the two formats is in the usage of bits 16 to 23.
NA メッセージで使用される EARO の場合、図 2 は [RFC8928] の図 1 を置き換えます。2 つの形式の違いは、ビット 16 ～ 23 の使用法にあります。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | r | Status | Opaque |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|r|C| P | I |R|T| TID | Registration Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
... Registration Ownership Verifier (ROVR) ...
| (64, 128, 192, or 256 bits) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: Extended Address Registration Option (EARO) Format for Use in NA Messages
図 2: NA メッセージで使用する拡張アドレス登録オプション (EARO) 形式
Option fields of interest for this specification:
この仕様に関係するオプション フィールド:
Type:
タイプ：
33
33
Length:
長さ：
Defined in [RFC8505]
[RFC8505]で定義
F:
F:
Defined in [RFC9926]
[RFC9926]で定義
Prefix Length
プレフィックスの長さ
Defined in [RFC9926]
[RFC9926]で定義
Status:
状態：
6-bit unsigned integer. This field is used in NA(EARO) response messages only to indicate the status of a registration. This field is defined in [RFC8505] and resized by [RFC9010]. The values for the Status field are available in [IANA.ICMP.ARO.STAT]. This field MUST be set to 0 in NS(EARO) messages unless the registration is for a prefix, in which case the F-flag is set and the prefix length is provided.
6 ビットの符号なし整数。このフィールドは、登録のステータスを示すためにのみ NA(EARO) 応答メッセージで使用されます。このフィールドは [RFC8505] で定義され、[RFC9010] によってサイズ変更されます。Status フィールドの値は [IANA.ICMP.ARO.STAT] で入手できます。NS(EARO) メッセージでは、登録がプレフィックス用でない限り、このフィールドを 0 に設定しなければなりません (MUST)。この場合、F フラグが設定され、プレフィックス長が提供されます。
Opaque:
不透明:
Defined in [RFC8505]
[RFC8505]で定義
r (reserved):
r (予約済み):
1-bit reserved field in NS(EARO) and NA(EARO) as depicted in Figure 1 and Figure 2. 2-bit reserved field (most significant bits of Status filed) in NA(EARO) as depicted in Figure 2. All reserved field MUST be set to zero by the sender and MUST be ignored by the receiver.
図 1 と図 2 に示すように、NS(EARO) および NA(EARO) の 1 ビットの予約フィールド。図 2 に示す、NA(EARO) の 2 ビットの予約フィールド (ステータス フィールドの最上位ビット)。すべての予約フィールドは送信者によってゼロに設定されなければならず、受信者によって無視されなければなりません。
C:
C:
1-bit flag, moved from its position in Figure 1 of [RFC8928]. It is set to indicate that the ROVR field contains a Crypto-ID and that the 6LN MAY be challenged for ownership.
[RFC8928] の図 1 の位置から移動された 1 ビットのフラグ。これは、ROVR フィールドに Crypto-ID が含まれていること、および 6LN が所有権を求められてもよいことを示すように設定されます。
P:
P:
2-bit field for Registered Address Type Indicator (RATInd). Indicates whether the registered address is unicast, multicast, anycast, or derived from the registered unicast prefix. Used to transport the RATInd in different protocols. The values for the RATInd field are available in [IANA.ICMP.ARO.P-FIELD].
登録アドレス タイプ インジケーター (RATInd) の 2 ビット フィールド。登録されたアドレスがユニキャスト、マルチキャスト、エニーキャストであるか、または登録されたユニキャスト プレフィックスから派生したものであるかを示します。異なるプロトコルで RATInd を転送するために使用されます。RATInd フィールドの値は [IANA.ICMP.ARO.P-FIELD] で入手できます。
I:
I:
Defined in [RFC8505]
[RFC8505]で定義
R:
R:
Defined in [RFC8505]
[RFC8505]で定義
T:
T:
Defined in [RFC8505]
[RFC8505]で定義
TID (Transaction ID):
TID (トランザクション ID):
Defined in [RFC8505]
[RFC8505]で定義
Registration Lifetime:
登録の有効期間:
Defined in [RFC8505]
[RFC8505]で定義
Registration Ownership Verifier (ROVR):
登録所有権検証者 (ROVR):
Defined in [RFC8505]. Variable-length field used to verify who "owns" a registered IPv6 address. When the C-flag is set, this field contains a Crypto-ID [RFC8928].
[RFC8505]で定義されています。登録された IPv6 アドレスの「所有者」を確認するために使用される可変長フィールド。C フラグが設定されている場合、このフィールドには Crypto-ID [RFC8928] が含まれます。
This specification does not introduce any new security considerations beyond those already discussed in [RFC8928] and [RFC8505].
この仕様は、[RFC8928] および [RFC8505] で既に説明されているものを超える新しいセキュリティ考慮事項を導入しません。
The updates introduced in this document are not backward compatible. However, given that there are no known implementations or deployments of [RFC8928], this document does not require any transition plan.
このドキュメントで紹介されている更新プログラムには下位互換性がありません。ただし、[RFC8928] の既知の実装または展開がないことを考慮すると、この文書では移行計画は必要ありません。
IANA has updated the "Address Registration Option Flags" [IANA.ICMP.ARO.FLG] registry in the "Internet Control Message Protocol version 6 (ICMPv6) Parameters" registry group as specified in Table 1 so this document is referenced in addition to [RFC8928] for bit number 1:
IANA は、「インターネット コントロール メッセージ プロトコル バージョン 6 (ICMPv6) パラメーター」レジストリ グループ内の「アドレス登録オプション フラグ」[IANA.ICMP.ARO.FLG] レジストリを表 1 に指定されているように更新したため、ビット番号 1 については [RFC8928] に加えてこの文書も参照されます。
+============+=============+========================+
| Bit Number | Description | Reference |
+============+=============+========================+
| 1 | C-Flag | RFC 9927 and [RFC8928] |
+------------+-------------+------------------------+
Table 1: Bit Position of the C-flag
表 1: C フラグのビット位置
[IANA.ICMP.ARO.FLG]
IANA, "Address Registration Option Flags",
<https://www.iana.org/assignments/icmpv6-parameters>.
[IANA.ICMP.ARO.P-FIELD]
IANA, "P-Field Values",
<https://www.iana.org/assignments/icmpv6-parameters>.
[IANA.ICMP.ARO.STAT]
IANA, "Address Registration Option Status Values",
<https://www.iana.org/assignments/icmpv6-parameters>.
[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>.
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
"Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
DOI 10.17487/RFC4861, September 2007,
<https://www.rfc-editor.org/info/rfc4861>.
[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
Address Autoconfiguration", RFC 4862,
DOI 10.17487/RFC4862, September 2007,
<https://www.rfc-editor.org/info/rfc4862>.
[RFC6775] Shelby, Z., Ed., Chakrabarti, S., Nordmark, E., and C.
Bormann, "Neighbor Discovery Optimization for IPv6 over
Low-Power Wireless Personal Area Networks (6LoWPANs)",
RFC 6775, DOI 10.17487/RFC6775, November 2012,
<https://www.rfc-editor.org/info/rfc6775>.
[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>.
[RFC8505] Thubert, P., Ed., Nordmark, E., Chakrabarti, S., and C.
Perkins, "Registration Extensions for IPv6 over Low-Power
Wireless Personal Area Network (6LoWPAN) Neighbor
Discovery", RFC 8505, DOI 10.17487/RFC8505, November 2018,
<https://www.rfc-editor.org/info/rfc8505>.
[RFC8928] Thubert, P., Ed., Sarikaya, B., Sethi, M., and R. Struik,
"Address-Protected Neighbor Discovery for Low-Power and
Lossy Networks", RFC 8928, DOI 10.17487/RFC8928, November
2020, <https://www.rfc-editor.org/info/rfc8928>.
[RFC9010] Thubert, P., Ed. and M. Richardson, "Routing for RPL
(Routing Protocol for Low-Power and Lossy Networks)
Leaves", RFC 9010, DOI 10.17487/RFC9010, April 2021,
<https://www.rfc-editor.org/info/rfc9010>.
[RFC9685] Thubert, P., Ed., "Listener Subscription for IPv6 Neighbor
Discovery Multicast and Anycast Addresses", RFC 9685,
DOI 10.17487/RFC9685, November 2024,
<https://www.rfc-editor.org/info/rfc9685>.
[RFC9926] Thubert, P., Ed., "Prefix Registration for IPv6 Neighbor
Discovery", RFC 9926, DOI 10.17487/RFC9926, February 2026,
<https://www.rfc-editor.org/info/rfc9926>.
[RFC8929] Thubert, P., Ed., Perkins, C.E., and E. Levy-Abegnoli,
"IPv6 Backbone Router", RFC 8929, DOI 10.17487/RFC8929,
November 2020, <https://www.rfc-editor.org/info/rfc8929>.
Pascal Thubert
06330 Roquefort-les-Pins
France
Email: pascal.thubert@gmail.com
Adnan Rashid
Politecnico di Bari
Via Edoardo Orabona 4
70126 Bari
Italy
Email: adnan.rashid@poliba.it