<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [

<!ENTITY RFC3493 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3493.xml">

<!ENTITY RFC4271 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4271.xml">

<!ENTITY RFC4291 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4291.xml">

<!ENTITY RFC4007 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4007.xml">

<!ENTITY RFC6071 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6071.xml">

<!ENTITY RFC7094 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7094.xml">

]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc strict="yes" ?>
<?rfc toc="yes"?>
<?rfc tocdepth="4"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes" ?>
<?rfc compact="yes" ?>
<?rfc subcompact="no" ?>
<rfc updates="3493" category="info" docName="draft-smith-6man-anycast-local-sock-opt-01" ipr="trust200902">

  <front>

    <title>An IPV6_ANYCAST_LOCAL Socket Option</title>

    <author fullname="Mark Smith" initials="M.R." surname="Smith">

      <address>
        <postal>
          <street>PO BOX 521</street>

          <city>HEIDELBERG</city>

          <region>VIC</region>

          <code>3084</code>

          <country>AU</country>
        </postal>

        <email>markzzzsmith@gmail.com</email>

      </address>
    </author>

    <date year="2026" />

    <area>General</area>

    <workgroup>Internet Engineering Task Force</workgroup>

    <keyword>ipv6</keyword>
    <keyword>anycast</keyword>
    <keyword>socket</keyword>
    <keyword>loop</keyword>
    <keyword>api</keyword>


    <abstract>
	    <t>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.</t>
    </abstract>
  </front>

  <middle>
    <section anchor="Intro" title="Introduction">
	    <t>An IPv6 node may hold an IPv6 anycast address <xref target="RFC4291" /><xref target="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.</t>
	<t>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.</t>
	<t>An example of a node that may wish to ignore its own IPv6 anycast address is an IPv6 router. As per <xref target="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.</t>
	<t>This router is configured to establish an BGP session <xref target="RFC4271" /> with its neighbor using the fe80::/64 anycast address and a zone index <xref target="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.</t>
	<t>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  <xref target="RFC3493" /> facilitates both of these scenarios with via the IPV6_MULTICAST_LOOP socket option.</t>
	<t>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.</t>
	<t>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.</t>
    </section>

    <section title="IPV6_ANYCAST_LOCAL Socket Option">

	    <t>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.</t>
	    <t>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.</t>

    </section>

    <section title="Loopback Interface(s)">

	    <t>Many IPv6 implementations implement a virtual "loopback" interface, and assign the ::1/128 address to it <xref target="RFC4291" />. A loopback interface should also have the required link-local address <xref target="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.</t>
	    <t>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.</t>
	    <t>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.</t>

    </section>

    <section anchor="Security" title="Security Considerations">

	    <t>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 <xref target="RFC6071" /> or similar would prevent this contents disclosure.</t>

    </section>

    <section anchor="acknowledgements" title="Acknowledgements">

	<t>Review and comments were provided by YOUR NAME HERE!</t>

	<t>This memo was prepared using the xml2rfc tool.</t>

    </section>

  </middle>

  <back>

    <references title="Normative References">


    </references>

    <references title="Informative References">

      &RFC3493;

      &RFC4271;

      &RFC4291;

      &RFC4007;

      &RFC6071;

      &RFC7094;

    </references>

  </back>
</rfc>
