| Internet-Draft | An IPV6_ANYCAST_LOCAL Socket Option | October 2026 |
| Smith | Expires 30 April 2027 | [Page] |
IPv6 nodes will deliver packets destined to an anycast address to one of their own local instances of the anycast address should they exist. There are cases where it could be useful for a node to ignore its own anycast address instances and to submit packets towards this anycast address to the network for delivery to another node holding the anycast address. This memo describes a Sockets API socket option to specify this behaviour.¶
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 30 April 2027.¶
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 (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.¶
An IPv6 node may hold an IPv6 anycast address [RFC4291][RFC7094], yet wish to ignore its own instance of this IPv6 anycast address, and send IPv6 packets to one of any of the same non-local IPv6 anycast addresses available over the network.¶
Currently, it is not possible for a node to ignore its own instance of an IPv6 anycast address. All packets sent to this IPv6 anycast address will be delivered locally to and within the node itself.¶
An example of a node that may wish to ignore its own IPv6 anycast address is an IPv6 router. As per [RFC4291] 2.6.1, a router is required to configure the Subnet-Router anycast address, an IPv6 address consisting of the IPv6 prefix and an IID portion of all zero bits (e.g., for the link-local prefix, the Subnet-Router anycast address is fe80::/64), for all prefixes on all of its IPv6 enabled interfaces.¶
This router is configured to establish an BGP session [RFC4271] with its neighbor using the fe80::/64 anycast address and a zone index [RFC4007] (typically an interface identifier) identifying the interface to reach its neighbor. Currently, this router would attempt to establish a BGP session with itself, rather than with its link BGP neighbor's fe80:: anycast address.¶
Multicast has a similar requirement, where a multicast listener may wish to send packets to other listeners within a group it is a member of, but not receive its own transmissions. In another situation, a multicast sender may wish to receive its own transmissions as well as have them delivered to other listeners in the same group on the network. The Basic Sockets API for IPv6 [RFC3493] facilitates both of these scenarios with via the IPV6_MULTICAST_LOOP socket option.¶
This memo specifies a similar IPV6_ANYCAST_LOCAL socket option for use with IPv6 sockets that are used to send packets to anycast IPv6 addresses.¶
Note that this memo is informational and is intended to solicit feedback from IETF members. The socket option will need to be standardised by The Open Group as part of the POSIX X.Y.Z standard.¶
If a unicast IPv6 packet is sent to an anycast address for which the IPv6 node holds one or more instances the anycast address, the packet will be delivered locally within the node upon transmission to one of the anycast address instances if this option is set to 1.¶
If this option is set to 0, the packet will not be delivered to any of the node's anycast address instances upon transmission. Based on the anycast address destination prefix and address, and possibly zone index, the node will find a suitable egress interface to send the packet towards a non-local anycast IPv6 address instance.¶
Many IPv6 implementations implement a virtual "loopback" interface, and assign the ::1/128 address to it [RFC4291]. A loopback interface should also have the required link-local address [RFC4291], within which it may have a link-local Subnet-Router anycast address if the loopback interface is a forwarding interface (perhaps because the node is acting as a router and all interfaces are enabled for forwarding). It may also be configured with other anycast addresses within the link-local or other prefixes on its interfaces.¶
An implementation choice for a loopback interface is to implement it as a link-layer virtual interface, and to have the function that sends IPv6 packets out the interface call the function that receives IPv6 packets on the loopback interface, literally looping the IPv6 packet back to the sending host via and within the loopback interface implementation.¶
Using the IPV6_ANYCAST_LOCAL socket option with a value of 0 when sending packets to an anycast address assigned to a loopback interface would still be valid. Upon transmisson of the packet out the loopback interface, the anycast address would be ignored as a destination address for the purposes of local delivery. However, after the packet has been looped back to the node by its loopback interface, the node would then receive and accept the packet with the anycast address.¶
Incorrectly setting the IPV6_ANYCAST_LOCAL flag could cause packets to leave a node when the intention is for the packet to be delivered to the node's local anycast address instance. This could expose these packets to interception and contents disclosure on the network. Packet payload encryption via IPsec [RFC6071] or similar would prevent this contents disclosure.¶
Review and comments were provided by YOUR NAME HERE!¶
This memo was prepared using the xml2rfc tool.¶