Google LLC

1600 Amphitheatre Parkway Mountain View California 94043 United States of America jonhui@google.com

INT 6man stub network stub router IPv6 Neighbor Discovery RA Flags Option This document defines a new flag, the SNAC Router flag, in the Router Advertisement message that can be used to distinguish configuration information sent by Stub Network Auto-Configuring (SNAC) routers from information sent by transit routers.

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. Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at .

Copyright Notice Copyright (c) 2026 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 () 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.

Table of Contents

• .  Introduction
• .  SNAC Router Flag
• .  IANA Considerations
• .  Operational Considerations
• .  Security Considerations
• .  References
  • .  Normative References
  • .  Informative References
• Author's Address

Introduction Per , networks can either be transit or stub networks. Transit networks are those capable of carrying data traffic that is neither locally originated nor locally destined. A Stub Network Auto-Configuring (SNAC) router is an autonomously configuring router that provides IP connectivity between one or more stub networks and one or more transit networks. A common example of a SNAC router is a device that attaches a 6LoWPAN-based network to a home network, automatically providing IPv6 forwarding between the two networks without explicit operator configuration. This document defines a new IPv6 Neighbor Discovery Router Advertisement (RA) flag, the SNAC Router flag, which SNAC routers use to identify RAs sent by other SNAC routers. Readers can refer to for an overview of a set of practices for automatically connecting IPv6 stub networks to transit networks.

SNAC Router Flag The SNAC Router flag is bit 6 in the RA Flags Extension Option . The SNAC Router flag bit with a value of '1' is reserved for use by SNAC routers. Receipt of an RA with that bit set to '1' indicates that the sending router is a SNAC router. Describing the exact triggers when a SNAC router sets this flag to '1' is out of scope for this document. An example of such considerations is documented in . Consistent with , devices that do not operate as SNAC routers will not set the SNAC Router flag bit to '1', and devices that do not understand the SNAC Router flag will silently ignore it. This means that setting the flag bit to '1' or '0' should not change the behavior of such devices in any way (other than that it is permissible to log and cache the value of the flag bit as part of normal router advertisement processing, where applicable).

IANA Considerations IANA has allocated a flag from the "IPv6 ND Router Advertisement Flags" registry in the "Internet Control Message Protocol version 6 (ICMPv6) Parameters" registry group as specified below:

RA Option Bit	Description	Reference
6	S - SNAC Router Flag	This Document

Operational Considerations In environments that implement RA-Guard in a way that filters RAs sent by SNAC routers, devices on the transit network will never receive an RA with the SNAC Router flag bit set to '1'.

Security Considerations How SNAC routers process RAs is dependent on the SNAC Router flag value. The security considerations of IPv6 Neighbor Discovery are documented in Section Security Considerations of . The addition of the SNAC Router flag does not change these considerations.

References Normative References This document specifies the Neighbor Discovery protocol for IP Version 6. IPv6 nodes on the same link use Neighbor Discovery to discover each other's presence, to determine each other's link-layer addresses, to find routers, and to maintain reachability information about the paths to active neighbors. [STANDARDS-TRACK] The IPv6 Neighbor Discovery's Router Advertisement message contains an 8-bit field reserved for single-bit flags. Several protocols have reserved flags in this field and others are preparing to reserve a sufficient number of flags to exhaust the field. This document defines an option to the Router Advertisement message that expands the number of flag bits available. [STANDARDS-TRACK] Informative References Apple Inc. Google LLC IoTconsultancy.nl This document specifies a set of practices for using IPv6 networking to automatically connect stub networks to adjacent infrastructure networks, even if they do not otherwise use IPv6. This is applicable in cases such as constrained (Internet of Things) networks where there is a need to provide functional parity of service discovery and reachability between devices on the stub network and devices on an adjacent infrastructure link (for example, a home network). Work in Progress This memo documents version 2 of the OSPF protocol. OSPF is a link- state routing protocol. [STANDARDS-TRACK] This document describes the assumptions, problem statement, and goals for transmitting IP over IEEE 802.15.4 networks. The set of goals enumerated in this document form an initial set only. This memo provides information for the Internet community. The IPv6 Router Advertisement Guard (RA-Guard) mechanism is commonly employed to mitigate attack vectors based on forged ICMPv6 Router Advertisement messages. Many existing IPv6 deployments rely on RA-Guard as the first line of defense against the aforementioned attack vectors. However, some implementations of RA-Guard have been found to be prone to circumvention by employing IPv6 Extension Headers. This document describes the evasion techniques that affect the aforementioned implementations and formally updates RFC 6105, such that the aforementioned RA-Guard evasion vectors are eliminated.

Author's Address Google LLC

1600 Amphitheatre Parkway Mountain View California 94043 United States of America jonhui@google.com