Internet-Draft SNAC Router RA Flag April 2026
Hui Expires 10 October 2026 [Page]
Workgroup:
Internet Engineering Task Force
Published:
Intended Status:
Standards Track
Expires:
Author:
J. Hui
Google LLC

SNAC Router Flag in ICMPv6 Router Advertisement Messages

Abstract

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 SNAC routers from information sent by transit routers.

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."

This Internet-Draft will expire on 10 October 2026.

Table of Contents

1. Introduction

Per Section 2.1 of [RFC2328], networks can either be transmit 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 SNAC router example is a device that attaches a 6LoWPAN-based network [RFC4919] to a home network, automatically providing IPv6 forwarding between the two networks without explicit operator configuration. This document defines a new IPv6 ND Router Advertisement (RA) flag, the "SNAC router" flag, which SNAC routers use to identify RAs sent by other SNAC routers.

Readers can refer to [I-D.ietf-snac-simple] for an overview of a set of practices for automatically connecting IPv6 stub networks to transmit networks.

2. Terminology

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.

3. SNAC Router Flag

The "SNAC Router" flag is bit TBD in the RA Flags Extension Option [RFC5175].

The SNAC router flag bit with value '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 are documented in [I-D.ietf-snac-simple].

Consistent with Section 4.2 of [RFC4861], devices that do not operate as SNAC routers will not set the SNAC router flag bit to '1', and routers 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).

4. IANA Considerations

IANA is requested to allocate a flag from the "Internet Control Message Protocol version 6 (ICMPv6) Parameters", "IPv6 ND Router Advertisement flags" registry [IANA-RA-FLAGS] as specified below:

Table 1
RA Option Bit Description Reference
TBD S - SNAC Router Flag This Document

5. Operational Considerations

In environments that implement RA-Guard [RFC7113] 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'.

6. Security Considerations

How SNAC routers process RAs is dependent on the SNAC router flag value.

The security considerations of IPv6 ND are documented in the "Security Considerations" section of [RFC4861]. The addition of the SNAC router flag does not change these considerations.

7. Normative References

[RFC2119]
Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, , <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, , <https://www.rfc-editor.org/info/rfc4861>.
[RFC5175]
Haberman, B., Ed. and R. Hinden, "IPv6 Router Advertisement Flags Option", RFC 5175, DOI 10.17487/RFC5175, , <https://www.rfc-editor.org/info/rfc5175>.
[RFC8174]
Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, , <https://www.rfc-editor.org/info/rfc8174>.

8. Informative References

[I-D.ietf-snac-simple]
Lemon, T. and J. Hui, "Automatically Connecting Stub Networks to Unmanaged Infrastructure", Work in Progress, Internet-Draft, draft-ietf-snac-simple-08, , <https://datatracker.ietf.org/doc/html/draft-ietf-snac-simple-08>.
[IANA-RA-FLAGS]
IANA, "IPv6 ND Router Advertisement flags", <https://www.iana.org/assignments/icmpv6-parameters/icmpv6-parameters.xhtml#icmpv6-parameters-11>.
[RFC2328]
Moy, J., "OSPF Version 2", STD 54, RFC 2328, DOI 10.17487/RFC2328, , <https://www.rfc-editor.org/info/rfc2328>.
[RFC4919]
Kushalnagar, N., Montenegro, G., and C. Schumacher, "IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs): Overview, Assumptions, Problem Statement, and Goals", RFC 4919, DOI 10.17487/RFC4919, , <https://www.rfc-editor.org/info/rfc4919>.
[RFC7113]
Gont, F., "Implementation Advice for IPv6 Router Advertisement Guard (RA-Guard)", RFC 7113, DOI 10.17487/RFC7113, , <https://www.rfc-editor.org/info/rfc7113>.

Author's Address

Jonathan Hui
Google LLC
1600 Amphitheatre Parkway
Mountain View, California 940432
United States of America