IPv6 over Nothing Internet Draft

The IETF aren't accepting Internet Draft submissions for the moment due to the upcoming IETF 125 meeting.

I have posted the new Internet Draft here for the time being.

Internet Engineering Task Force                                 M. Smith

Internet-Draft                                             12 March 2026

Intended status: Standards Track                                        

Expires: 13 September 2026

                           IPv6 Over Nothing

                 draft-smith-6man-ipv6-over-nothing-00

Abstract

   A perspective on the function of the network layer is that it

   abstracts away the differences between the various underlying link

   layer frame and addressing formats, unifying them into a common

   protocol data unit format and addressing scheme, namely the IPv4 or

   IPv6 protocols, and hiding those details from the upper transport

   layer protocols.  As IPv6 is expected to become the dominant network

   layer protocol, and Ethernet has become the dominant link-layer

   protocol, this memo proposes eliminating the overhead of the

   abstraction of Ethernet by IPv6 and using IPv6 directly as the link-

   layer protocol.

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 13 September 2026.

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 (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

Smith                   Expires 13 September 2026               [Page 1]



Internet-Draft              IPv6 Over Nothing                 March 2026

   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

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2

     1.1.  Requirements Language . . . . . . . . . . . . . . . . . .   3

   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3

   3.  Link Type . . . . . . . . . . . . . . . . . . . . . . . . . .   3

   4.  IPv6 Addressing . . . . . . . . . . . . . . . . . . . . . . .   4

   5.  IPv6 Link Error Detection . . . . . . . . . . . . . . . . . .   4

     5.1.  Inter-Router Link Error Detection . . . . . . . . . . . .   4

     5.2.  Host-Router and Router-Host Link Error Detection  . . . .   4

   6.  Maximum Transmission Unit . . . . . . . . . . . . . . . . . .   5

   7.  Neighbor Discovery  . . . . . . . . . . . . . . . . . . . . .   5

   8.  Router Discovery  . . . . . . . . . . . . . . . . . . . . . .   6

   9.  Carrying Other Link Layer and Network Layer Protocols . . . .   6

   10. IPv6 Over Almost Nothing  . . . . . . . . . . . . . . . . . .   6

   11. IANA Considerations . . . . . . . . . . . . . . . . . . . . .   7

   12. Security Considerations . . . . . . . . . . . . . . . . . . .   7

   13. References  . . . . . . . . . . . . . . . . . . . . . . . . .   7

     13.1.  Normative References . . . . . . . . . . . . . . . . . .   7

     13.2.  Informative References . . . . . . . . . . . . . . . . .   7

   Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .   7

   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .   7

1.  Introduction

   As observed in the Internet Protocol Suite overview in [RFC6272],

   "The Internet layer provides a uniform network abstraction network

   that hides the differences between various network technologies."

   More specifically, the Internet layer is abstracting away the

   different frame formats, processing and addressing formats of the

   various link-layers that are used to construct an IP based network.

   To layers above the network layer, there is a uniform packet format,

   uniform processing, and a uniform addressing scheme that idenfifies

   all packet sources and destinations.

   Ethernet [IEEE802.3] has become the most widely deployed phyiscal

   link-layer technology in IP networks, displacing other link-layer

   technologies such as ATM, SONET/SDH/PoS, Token Ring and Frame Relay.

   This is due to Ethernet becoming the most popular link-layer

   technology used to deploy wired Local Area Networks used to

   interconnect commodity desktop personal computers.  Ethernet became

   so commodified that it became both the cheapest way to interconnect

Smith                   Expires 13 September 2026               [Page 2]



Internet-Draft              IPv6 Over Nothing                 March 2026

   IP devices, including routers within IP networks, and also became the

   best link-layer technology to enhance with performance improvements,

   since the it provided the largest likely market for those

   improvements.

   A useful computer science principle is to optimise for the common

   case.  Since IPv6 is expected to become the common case IP protocol

   in use, Ethernet is the common case for interconnecting network

   devices, and the IP layer's purpose is to abstract away different

   link-layer's differences, there is an opportunity to optimise for the

   common case of IPv6 over Ethernet and use IPv6 directly as a link-

   layer protocol.  This would eliminate the need to abstract away

   Ethernet's link-layer frame and addressing properties, simplifying

   the network and increasing performance.  It would also elminate the

   need to also run a link-layer redudnancy protocol such as the

   Spanning Tree Protocol [STP].

   This memo describes how this can be achieved.

   Note that this is a serious proposal, despite it sounding like an

   April Fools memo.  Should it progress to being published as an RFC,

   it could be published as Standards Track RFC on April Fools for the

   amusement of the audience.

1.1.  Requirements Language

   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.

2.  Terminology

   IPv6 link - a link-layer link implementing this specification.

3.  Link Type

   When using IPv6 as a link-layer protocol, an IPv6 link is a point-to-

   point link, per [RFC4861]'s point-to-point link definition.  There is

   no such thing as a multi-access link connecting more than 2 nodes

   when using IPv6 as a link-layer.

   Also as per [RFC4861], these point-to-point links are multicast

   capable, by sending IPv6 multicasts to the far end of the point-to-

   point link, and optionally looping the multicast back to the sending

   host itself when necessary[Reference to IPv6 verson of RFC1112].

Smith                   Expires 13 September 2026               [Page 3]



Internet-Draft              IPv6 Over Nothing                 March 2026

   As all IPv6 links are point-to-point, this means that an IPv6 host is

   directly connected to a single upstream IPv6 router.  If a host

   requires network attachment redundancy, it will need to be connected

   to two different routers via two different point-to-point IPv6 links.

4.  IPv6 Addressing

   As per [RFC4291], all interfaces attached to IPv6 links are required

   to have at least one Link-Local unicast address.  These addresses are

   typically generated and configured via SLAAC [RFC4862][RFC8064].

   Link-local addresses are the analogue for traditional link-layer

   addresses such as Ethernet MAC addresses, as packets with link-local

   addresses are limited to a single link [RFC4007].

   An interface attached to an IPv6 link may and likely will gain other

   GUA [RFC4291] and/or ULA [RFC4193] addresses, and perhaps additional

   link-local addresses, via IPv6 address configuration methods such as

   SLAAC [RFC4862][RFC8064], DHCPv6 [RFC9915] or manual configuration.

5.  IPv6 Link Error Detection

5.1.  Inter-Router Link Error Detection

   To detect packet loss and corruption that causes packet loss,

   isolated to a single link between two routers, single hop IPv6

   Bidirectional Forwarding Detection is used [RFC5881].

5.2.  Host-Router and Router-Host Link Error Detection

   Transport layer protocols such as TCP [RFC793] and UDP [RFC768] use

   an end-to-end checksum to detect errors that have occurred while

   packets travel over the network between the transport layer end-

   points residing in the source and destination hosts.

   As inter-router IPv6 links are protected via BFD (see previous

   section), or link-layer checksums for other link-layer link types, if

   no inter-router links are suffering from errors, then it can be

   concluded a fault lies with either the link between a source host and

   its upstream router, or the final router and its downstream

   destination host.  Conventional ICMPv6 Echo Requests and Replies

   ("ping") can be used to determine which of these two links is faulty

   (or in fact if they both are).

   If necessary, BFD [RFC5881] could be used between the hosts and their

   routers to better check for link errors.

Smith                   Expires 13 September 2026               [Page 4]



Internet-Draft              IPv6 Over Nothing                 March 2026

6.  Maximum Transmission Unit

   The Maximum Transmission Unit for an IPv6 link is variable, up to the

   maximum payload size that can be carried in an IPv6 packet.  It can

   be different for each IPv6 link within a network (although not

   recommended), and different for each direction of a bidirectional

   link, as long as the packet receiver can receive packets as large as

   the packet sender can send (in other words, the Maximum Reception

   Unit (MRU) for a receiving node on a link is greater than or equal to

   the Maximum Transmission Unit (MTU) for a sending node on the link).

   The default Maximum Transmission Unit for an IPv6 link is 2^16-1 or

   65535 octets, the maximum value for the IPv6 Payload Length field

   [RFC8200].

   The maximum Maximum Transmission Unit for an IPv6 link is 2^32-1 or

   4294967295 octets, when using the Jumbo Payload IPv6 Hop-by-Hop

   option [RFC2675].

7.  Neighbor Discovery

   Although IPv6 links do not have actual link-layer addresses, and are

   point-to-point, [RFC4861] Neighbor Discovery still needs to be

   performed, as specified for point-to-point links in [RFC4861].  This

   is because Neighbor Discovery, in addition to normally resolving an

   IPv6 address into a link-layer address for link-layers with

   addresses, also discovers whether or not an IPv6 address exists at

   the far end of the IPv6 (point-to-point) link, and monitors the

   continued existence of IPv6 addresses via Neighbor Unreachability

   Discovery (NUD).

   Neighbor Discovery is not optional because it prevents the so-called

   "ping-pong" problem described in [RFC6164] on inter-router links.

   This problem exists because router IPv6 implementations weren't or

   aren't performing Neighbor Discovery on point-to-point links.

   Instead, they were assuming that any and all non-local addresses must

   exist at the far end of the point-to-point link.  In other words,

   they weren't testing for the existence of an IPv6 address via

   Neighbor Discovery at the far end of the link before sending packets

   to that IPv6 address.

   As IPv6 addresses are carried directly within the Neighbor Discovery

   protocol, the Source/Target Link-Layer Address [RFC4861] option is

   not required in either Neighbor Solicitations or Neighbor

   Advertisements.

Smith                   Expires 13 September 2026               [Page 5]



Internet-Draft              IPv6 Over Nothing                 March 2026

8.  Router Discovery

   As could be expected from the previous Neighbor Discovery section,

   [RFC4861] router discovery works as usual, with the exception that

   Router Soliciations and Router Advertisments do not contain Source/

   Target Link-layer Address options.

9.  Carrying Other Link Layer and Network Layer Protocols

   It may be useful or necessary to carry link layer or network layer

   protocols over an IPv6 link.  For example, it may be useful to use

   Link Layer Discovery Protocol [LLDP] between routers attached to an

   IPv6 link, or transport legacy IPv4 over IPv6 links.

   Carrying these protocols over IPv6 links can be achieved via various

   "tunnelling" over IPv6 methods such as [RFC2473].  For example, LLDP

   can be carried in Ethernet frames that are tunnelled over IPv6, with

   a suitable IPv6 unicast or multicast destination address.

   Note that as IPv6 supports multiple different multicast scopes that

   cover increasingly larger domains of the IPv6 network [IANA-IPv6-

   MCAST-SCOPES], it would be possible to carry protocols such as LLDP

   beyond a single link, unlike when they are carried in traditional

   link-layer protocols such as Ethernet.

10.  IPv6 Over Almost Nothing

   It is common for Ethernet interface drivers to fill in the

   Destination Address, Source Address and Ethernet Type fields of each

   frame before transmission.  Upon frame reception, an Ethernet Network

   Interface Card (NIC) uses a Destination Address matching mechanism

   within the NIC to determine if it should accept the frame and pass it

   onto the networking protocol stack.

   If an Ethernet NIC is put into "promiscuous" mode, it will accept

   frames with any Destination Address value, passing them onto the

   networking protocol stack.

   Over a point-to-point Ethernet link, once a NIC is in promiscuous

   mode, the Destination and Source Address fields of an Ethernet frame

   could be used to carry information other than Ethernet addresses.

   This would result in an additonal 12 octets per frame being

   available.

   Furthermore, again over a point-to-point Ethernet link, the 2 octet

   Ethernet type field could also be used to carry information other

   than Ethernet frame type information.

Smith                   Expires 13 September 2026               [Page 6]



Internet-Draft              IPv6 Over Nothing                 March 2026

   These initial 14 octets in the Ethernet frame could be used to carry

   the first 14 octets of the IPv6 packet, making this Ethernet link an

   "IPv6 over Almost Nothing" link, a variant of the IPv6 link described

   previously.

   Note that Ethernet's MTU limitations would still apply, although the

   MTU available would be 14 octets larger, and that the Ethernet Frame

   Check Sequence would still be present in the frames.

   It is important to ensure that the point-to-point link is a true

   physical link, or if not, there are no devices present within the

   link that will interpret the values of the Destination and Source

   Addresses and the Ethernet type field in these IPv6 over almost

   nothing frames.

11.  IANA Considerations

   This memo includes no request to IANA.

12.  Security Considerations

   This document should not affect the security of the Internet.

13.  References

13.1.  Normative References

   [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>.

   [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>.

13.2.  Informative References

Acknowledgements

   Your name here!

Author's Address

   Mark Smith

   PO BOX 521

   Heidelberg Victoria 3084

   Australia

Smith                   Expires 13 September 2026               [Page 7]



Internet-Draft              IPv6 Over Nothing                 March 2026

   Email: markzzzsmith@gmail.com

Smith                   Expires 13 September 2026               [Page 8]

Nearly IPv6 Only Dual Stack Hosts

I've written an Internet Draft on how to effectively disable IPv4 on dual stack hosts, while still satisifying their need for having an IPv4 address assigned via DHCPv4. It takes advantage of how IPv4 hosts use subnet masks, by using a 255.255.255.255 or /32 subnet mask.

The Internet Draft is available at Nearly IPv6 Only Dual Stack Hosts

The following is an bare bones example Kea DHCP DHCPv4 server configuration file that implements what is described in the Internet Draft.

//

// kea-dhcp4.conf.255sm.opt108.conf

//

// Bare bones example Kea DHCPv4 configuration implementing IETF

// Internet Draft:

//

// Nearly IPv6 Only Dual Stack Hosts

// draft-smith-v6ops-nearly-ipv6-only-dualstack-hosts

//

// https://datatracker.ietf.org/doc/draft-smith-v6ops-nearly-ipv6-only-dualstack-hosts/

// 

// To use:

// 1. Ensure the Kea DHCP server is installed, including the

//    'hooks' libraries. On Fedora 43, that means installing

//    both of the 'kea' and 'kea-hooks' packages.

// 2. As root, copy into /etc/kea and rename as kea-dhcp4.conf

//    (Or copy as kea-dhcp4.conf.255sm.opt108.conf into /etc/kea

//    and then symlink /etc/kea/kea-dhcp4.conf to point to

//    kea-dhcp4.conf.255sm.opt108.conf/)

// 3. Change the ownership of the file (kea-dhcp4.conf or symlinked

//    kea-dhcp4.conf.255sm.opt108.conf to root:kea via

//    'chown root:kea /etc/kea/<filename>'

// 4. Update the "interfaces" variable in "interfaces-config" to

//    suit which host interface is going to be used for the DHCPv4

//    server.

// 5. Update the "valid-lifetime" and possibly the "renew-timer",

//    and "rebind-timer" timers for the IPv4 address leases. The

//    current "valid-lifetime" is 600 seconds or 10 minutes for testing.

// 6. Replace the documentation 203.0.113.0/24 subnet in the config

//    with a suitable local subnet and prefix length on the 2 & 3

//    interface.

// 7. Change the pool range if necessary to suit the local subnet.

// 8. Update the "interface" variable in "subnet4" to the same

//    host interface name as in 2.

// 9. Update the "v6-only-preferred" "data" seconds value. It is

//    currently is 150 seconds for testing, which is 1/4th of the

//    10 minute "valid-lifetime", corresponding to the default

//    "renew-timer" timer value.

// 10. If necessary, update the host's firewall so it can receive

//    DHCPv4 requests from clients (destination UDP port 67).

// 11. Start kea-dhcpv4 using the local system method e.g.

//    'systemctl start kea-dhcp4' for a systemd based distribution.

//

{

"Dhcp4": {

    // Add names of your network interfaces to listen on.

    "interfaces-config": {

        // See section 8.2.4 for more details. You probably want to add just

        // interface name (e.g. "eth0" or specific IPv4 address on that

        // interface name (e.g. "eth0/203.0.113.1").

        "interfaces": [ "wlp1s0" ]

        // Kea DHCPv4 server by default listens using raw sockets. This ensures

        // all packets, including those sent by directly connected clients

        // that don't have IPv4 address yet, are received. However, if your

        // traffic is always relayed, it is often better to use regular

        // UDP sockets. If you want to do that, uncomment this line:

        // "dhcp-socket-type": "udp"

    },

    // Kea supports control channel, which is a way to receive management

    // commands while the server is running. This is a Unix domain socket that

    // receives commands formatted in JSON, e.g. config-set (which sets new

    // configuration), config-reload (which tells Kea to reload its

    // configuration from file), statistic-get (to retrieve statistics) and many

    // more. For detailed description, see Sections 8.8, 16 and 15.

    "control-socket": {

        "socket-type": "unix",

        "socket-name": "kea4-ctrl-socket"

    },

    // Use Memfile lease database backend to store leases in a CSV file.

    "lease-database": {

        // Memfile is the simplest and easiest backend to use. It's an in-memory

        // C++ database that stores its state in CSV file.

        "type": "memfile",

        "lfc-interval": 3600

    },

    // Setup reclamation of the expired leases and leases affinity.

    // Expired leases will be reclaimed every 10 seconds. Every 25

    // seconds reclaimed leases, which have expired more than 3600

    // seconds ago, will be removed. The limits for leases reclamation

    // are 100 leases or 250 ms for a single cycle. A warning message

    // will be logged if there are still expired leases in the

    // database after 5 consecutive reclamation cycles.

    // If both "flush-reclaimed-timer-wait-time" and "hold-reclaimed-time" are

    // not 0, when the client sends a release message the lease is expired

    // instead of being deleted from the lease storage.

    "expired-leases-processing": {

        "reclaim-timer-wait-time": 10,

        "flush-reclaimed-timer-wait-time": 25,

        "hold-reclaimed-time": 3600,

        "max-reclaim-leases": 100,

        "max-reclaim-time": 250,

        "unwarned-reclaim-cycles": 5

    },

    // Global timers specified here apply to all subnets, unless there are

    // subnet specific values defined in particular subnets.

    //"renew-timer": 900,

    //"rebind-timer": 1800,

    //"valid-lifetime": 3600,

    "valid-lifetime": 600, // seconds or 10 minutes for testing

    "hooks-libraries": [

{

// This hook overrides the DHCPv4 Option 1 Subnet Mask

// option value that is automatically set by Kea.

// Kea automatically derives the Subnet Mask option

// value from the 'subnet' prefix length (below), and

// does not currently allow it to be set via normal

// DHCPv4 option value setting in the global or

// "subnet4" "option-data" sections.

"library": "/usr/lib64/kea/hooks/libdhcp_flex_option.so",

"parameters": {

"options": [

{

"code": 1,

"supersede": "255.255.255.255"

}

]

}

}

    ],

    "subnet4": [

        {

            "id": 1,

            "subnet": "203.0.113.0/24",

            "pools": [ { "pool": "203.0.113.100 - 203.0.113.200" } ],

            "interface": "wlp1s0",

            "option-data": [

  {

"name": "v6-only-preferred",

"data": "150" // Seconds. Same as 600 second lease renew time

  }

            ],

        }

    ],

    "loggers": [

    {

        "name": "kea-dhcp4",

        "output-options": [

            {

                //"output": "kea-dhcp4.log"

                "output": "syslog"

            }

        ],

        // This specifies the severity of log messages to keep. Supported values

        // are: FATAL, ERROR, WARN, INFO, DEBUG

        "severity": "INFO",

        //"severity": "DEBUG",

        // If DEBUG level is specified, this value is used. 0 is least verbose,

        // 99 is most verbose. Be cautious, Kea can generate lots and lots

        // of logs if told to do so.

        "debuglevel": 0

    }

  ]

}

}

The Stateful DHCPv6 Myth. No, it doesn't record IPv6 addresses in use. Neither does DHCPv4.

A false sense of security is worse than no security at all; at least with no security you know you don't have any.

For many years, people have been complaining that Android is "broken" because it doesn't support stateful DHCPv6, meaning that it has a stateful DHCPv6 client that can acquire IPv6 addresses from a DHCPv6 server.

These complaints have mostly come from people running enterprise networks, who are used to running DHCPv4 to provide IPv4 addresses to hosts.

You can see many people making this complaint in this Google issue tracker ticket, lodged in 2012.

Support for DHCPv6 (RFC 3315)

There are also many articles and blog posts about it, such as the following, easily found through a Google (!) search:

There are business requirements, and compliance requirements, where you need to track what host had what IP at what time.

It’s 2020 And Android’s IPv6 Is Still Broken

 

The Big Myth

 

It's all a big myth. DHCPv4 and DHCPv6 do not "track what host had what IP at what time." Neither DHCPv4 or DHCPv6 never have, never will and never were designed to.

DHCPv4 normally only keeps a database of hosts running DHCPv4 clients that have requested and been supplied with IPv4 addresses (that is, an IPv4 address lease database). An attacker can easily bypass being recorded in the DHCPv4 database by not running a DHCPv4 client, and manually configuring an IPv4 address instead. Discovering what IPv4 address space exists on a link would be a simple as packet capturing some periodically broadcast ARP requests - and that is if IPv4 addressing isn't conveniently printed on a label on a device like a shared printer in a common area.

Stateful DHCPv6 normally only keeps a database of hosts running DHCPv6 clients that have requested and been supplied with IPv6 addresses (that is, an IPv6 client binding database). An attacker can easily bypass being recorded in the DHCPv6 database by not running a DHCPv6 client, and manually configuring an IPv6 address instead. Discovering what IPv6 address space exists on a link would be as simple as packet capturing some multicast IPv6 Router Advertisements or multicast Neighbor Discovery Neighbor Solicitations - or finding a printer with an IPv6 address label on it.

 

Additionally, DHCPv6 doesn't record IPv6 addresses that hosts generate using SLAAC (of course), nor does DHCPv6 record hosts' link-local addresses.

If the attacker's goal is to steal link bandwidth, by doing something like transferring files between two hosts on the link surreptitiously, the attacker doesn't even need to manually configure IPv6 addresses either. IPv6 interfaces are required to automatically configure a link-local address, to be used as a source address for things such as sending Neighbor Discovery messages and Router Solicitations.

 

Link-local addresses can be used for application traffic too, and are in fact preferred over IPv6 GUA or ULA addresses if available (see How to use IPv6 Link-Local Addresses in Applications for a summary of Link-Local address properties).

Terribly Inadequate

 

DHCPv4 and DHCPv6 are terribly inadequate for the security purposes of recording IPv4 or IPv6 addresses in use on the network.

Believing they are recording all IPv4 or IPv6 addresses in use on the network is false security.

 

Android is Not Broken

RFC 8504 (BCP 220) - IPv6 Node Requirements says the following about stateful DHCPv6 support (6.5):

   DHCPv6 [RFC3315] can be used to obtain and configure addresses.  In
   general, a network may provide for the configuration of addresses
   through SLAAC, DHCPv6, or both.  There will be a wide range of IPv6
   deployment models and differences in address assignment requirements,
   some of which may require DHCPv6 for stateful address assignment.
   Consequently, all hosts SHOULD implement address configuration via
   DHCPv6.

Stateful DHCPv6 is not a MUST implement. The Android IPv6 implementation complies with RFC 8504 / BCP 220.

Even if Android did implement stateful DHCPv6, it still wouldn't solve the problem that DHCPv6 doesn't record all IPv6 addresses in use.

IPv6 Addresses in Use

So if a network operator wants to have an accurate database of IPv6 addresses in use on a link and across the network, then they'll need a method that records:

• IPv6 addresses provided by Stateful DHCPv6
• IPv6 addresses generated by hosts using SLAAC.
  
• IPv6 addresses that have been manually configured
• IPv6 link-local autoconfigured addresses

I don't know of any specific methods or solutions that records IPv6 addresses that have been configured or generated using all of these addressing mechanisms. RFC 7039 - Source Address Validation Improvement (SAVI) Framework comes to mind, if an implementation also reports all of the source addresses it discovers.

The point of this article isn't to explore solutions - the reader can look into those.

The point is to call out the myth that Stateful DHCPv6 (and DHCPv4) record all IPv6 (or IPv4) addresses in use on a network, and that believing so is being lulled into a false sense of security, which is worse than no security at all.

Pinging all IPv6 nodes on a link

A series of blog articles on troubleshooting tips and tricks using IPv6 ping (ICMPv6 Echo Request/Echo Reply).

Note that I'm using Linux (specifically Fedora 31), however the ping command syntax for other operating systems should hopefully be quite similar.

Pinging all IPv6 nodes on a link

The first and most simple tip is to ping all IPv6 nodes on a link.

IPv6 only uses multicast addresses for all types of one to many communication. There is no IPv6 address that is designated as a "broadcast" address. This is unlike IPv4, where there are a number of types of broadcast addresses, such as the "limited broadcast" address of 255.255.255.255 [RFC1122].

However there is an "all-nodes" IPv6 multicast address, so we'll use that to ping all IPv6 nodes on the link. (A "broadcast" address is really just a specially named multicast address that happens to be a multicast group that includes all nodes. For example, notice how the "group" or multicast address bit is switched on in Ethernet link-layer broadcast addresses.)

The all-nodes IPv6 multicast address, for a link, is ff02::1. The ff designates an IPv6 multicast address. The following 0 is a flag nibble, with no flag bits set.

The following 2 is specifying a link multicast "scope". Unlike IPv4 multicast addresses, IPv6 multicast addresses have a scope. This scope value indicates the portion of the network over which the multicast packet is allowed to be forwarded. Once the packet reaches the boundary of the specified scope, the packet is to be discarded, regardless of if its Hop Count field is non-zero. Of course, if the Hop Count reaches zero before reaching the indicated multicast scope boundary, it is also discarded immediately. Here's the full list of IPv6 multicast scopes.

Finally, the ::1 is specifying the all-nodes multicast group.

One thing to notice about the ff02::1 address is that it is ambiguous. On an IPv6 node with multiple interfaces, such as a router or multi-homed host, there is nothing in the ff02::1 address to specify which interface to send the ICMPv6 Echo Requests out, or to expect to receive ICMPv6 Echo Responses when they come in. ff02::1 is valid and can be used on any of the interfaces and links attached to the multi-interface node.

So when we ping all IPv6 nodes on a link, we need to somehow also tell the IPv6 ping utility which interface to use.

Specifying Interfaces - Command Line Parameter

As we've seen, the all-nodes multicast address we want to use - ff02::1 - does not provide any information as to which interface to send and receive the ICMPv6 Echo Request and Reply packets on.

So how to do we specify an interface to use when using either link scope multicast addresses, or Link-Local unicast addresses?

The first and most obvious way would be to provide it as a parameter to the application we're using. 

For the ping utility, we provide it via the -I option.

[mark@opy ~]$ ping -w 1 -I enp3s2 ff02::1

ping: Warning: source address might be selected on device other than: enp3s2
PING ff02::1(ff02::1) from :: enp3s2: 56 data bytes
64 bytes from fe80::1d36:1fff:fefd:82be%enp3s2: icmp_seq=1 ttl=64 time=0.438 ms
64 bytes from fe80::f31c:ccff:fe26:a6d9%enp3s2: icmp_seq=1 ttl=64 time=0.589 ms (DUP!)
64 bytes from fe80::7e31:f5ff:fe1b:9fdb%enp3s2: icmp_seq=1 ttl=64 time=5.15 ms (DUP!)
64 bytes from fe80::f7f8:15ff:fe6f:be6e%enp3s2: icmp_seq=1 ttl=64 time=58.0 ms (DUP!)
64 bytes from fe80::877d:4ff:fe1a:b881%enp3s2: icmp_seq=1 ttl=64 time=62.3 ms (DUP!)
64 bytes from fe80::877d:4ff:fe1a:ad79%enp3s2: icmp_seq=1 ttl=64 time=62.8 ms (DUP!)

--- ff02::1 ping statistics ---
1 packets transmitted, 1 received, +5 duplicates, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 0.438/31.544/62.786/29.566 ms
[mark@opy ~]$

From this all-nodes multicast ping, we've received responses from a total of 6 IPv6 nodes. The responses have come from the nodes' Link-Local IPv6 addresses, starting with the fe80::/10 prefix.

To prevent ping continuing to endlessly send ICMPv6 Echo Requests until we interrupt it, we would normally specify a number of packets to send via the -c option. However, this also stops ping from accepting and displaying more than one ICMPv6 Echo Response when sending a multicast ICMPv6 Echo Request. Instead, we've used the -w parameter to specify that ping should terminate after 1 second, regardless of how many ICMPv6 Echo Requests or Echo Responses have been sent or received.

One other thing to notice is the (DUP!) output on the second and subsequent responses. These packets are identified as duplicates of the response because they have the same ICMP sequence value as the single ICMPv6 Echo Requests that was sent in the first place. They're occurring because the multicast ICMPv6 Echo Request results in multiple individual unicast responses. The number of duplicates is also reported in the statistics summary.

Specifying Interfaces - Zone ID

The other way we can provide the interface to use is as part of the IPv6 address parameter.

We can see an example of this in the ping output, where the addresses of the responding IPv6 nodes also has a %enp3s2 suffix e.g.:

64 bytes from fe80::1d36:1fff:fefd:82be%enp3s2: icmp_seq=1 ttl=64 time=0.438 ms

This way of specifying interfaces is formally described in [RFC4007], "IPv6 Scoped Address Architecture". Although they're commonly the operating system's name for an interface, they're actually specifying something more general - a "zone" or "scope zone".

The reason for having more general zones or scope zones is that as [RFC4007] mentions, an IPv6 node could have multiple different IPv6 interfaces connected to the same link. These interfaces are members of the same zone.

It should be possible to group multiple interfaces within a zone under the operating system; I don't currently know if that is possible under Linux or how to do so.

Using the %<zone_id> suffix, we can drop the -I ping command line parameter.

[mark@opy ~]$ ping -w 1 ff02::1%enp3s2
PING ff02::1%enp3s2(ff02::1%enp3s2) 56 data bytes
64 bytes from fe80::2392:6213:a15b:66ff%enp3s2: icmp_seq=1 ttl=64 time=0.106 ms
64 bytes from fe80::1d36:1fff:fefd:82be%enp3s2: icmp_seq=1 ttl=64 time=0.453 ms (DUP!)
64 bytes from fe80::f31c:ccff:fe26:a6d9%enp3s2: icmp_seq=1 ttl=64 time=0.606 ms (DUP!)
64 bytes from fe80::7e31:f5ff:fe1b:9fdb%enp3s2: icmp_seq=1 ttl=64 time=6.23 ms (DUP!)
64 bytes from fe80::f7f8:15ff:fe6f:be6e%enp3s2: icmp_seq=1 ttl=64 time=157 ms (DUP!)
64 bytes from fe80::877d:4ff:fe1a:ad79%enp3s2: icmp_seq=1 ttl=64 time=159 ms (DUP!)
64 bytes from fe80::877d:4ff:fe1a:b881%enp3s2: icmp_seq=1 ttl=64 time=161 ms (DUP!)
64 bytes from fe80::23d:e8ff:feec:958c%enp3s2: icmp_seq=1 ttl=64 time=179 ms (DUP!)

--- ff02::1%enp3s2 ping statistics ---
1 packets transmitted, 1 received, +7 duplicates, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 0.106/82.858/179.216/81.281 ms

[mark@opy ~]$

Link-Local Address Responses

From this all-nodes multicast ping we've received a total of 6 unique responses.

These responses have come from the IPv6 nodes' Link-Local unicast addresses. For example, here is the first response:

64 bytes from fe80::2392:6213:a15b:66ff%enp3s2: icmp_seq=1 ttl=64 time=0.106 ms

IPv6 unicast Link-Local addresses are required on all IPv6 enabled interfaces [RFC4291], "IP Version 6 Addressing Architecture". The reason for this is so that an IPv6 node always and automatically has an IPv6 unicast address that it can use to at least communicate with other nodes on its directly attached links. This includes communicating with other hosts' applications over the hosts' Link-Local addresses.

This simplifies design and implementation of protocols such as IPv6 Neighbor Discovery and OSPFv3. It also allows end-user applications on hosts to communicate on a link without requiring any other supporting IPv6 infrastructure on the link. There is no need for an IPv6 router or an DHCPv6 server on the link for attached IPv6 hosts to directly communicate.

Link-Local addresses start with a 10 bit prefix of fe80, followed by 54 zero bits, and then the 64 bit Interface Identifier (IID). In the above first response, 2392:6213:a15b:66ff is the 64 bit IID.

Looped Multicast

By default, multicast packets are looped back internally to the host that is sending them. This occurs for both IPv6 and IPv4 multicasts.

The reason for this default is that when sending multicast packets, there may also be a local multicast listening application running on the sending host itself, as well as somewhere on the network. This local application should also receive the multicast packets.

We can see this multicast local looping in our ping output:

[mark@opy ~]$ ping -w 1 ff02::1%enp3s2
PING ff02::1%enp3s2(ff02::1%enp3s2) 56 data bytes
64 bytes from fe80::2392:6213:a15b:66ff%enp3s2: icmp_seq=1 ttl=64 time=0.106 ms
64 bytes from fe80::1d36:1fff:fefd:82be%enp3s2: icmp_seq=1 ttl=64 time=0.453 ms (DUP!)

...

The first response and the fastest one (0.106 ms compared to 0.453 ms) is from the Link-Local address configured on the enp3s2 interface itself.

[mark@opy ~]$ ip addr show dev enp3s2 | grep fe80
    inet6 fe80::2392:6213:a15b:66ff/64 scope link noprefixroute 
[mark@opy ~]$

The ping utility provides a way to suppress local loopback of multicast, using the -L parameter. If we send an all-nodes multicast ping with this flag, then the responses are limited to remote nodes. We don't get a response from the sending interface's Link-Local address.

[mark@opy ~]$ ping -L -w 1 ff02::1%enp3s2
PING ff02::1%enp3s2(ff02::1%enp3s2) 56 data bytes
64 bytes from fe80::1d36:1fff:fefd:82be%enp3s2: icmp_seq=1 ttl=64 time=0.383 ms

64 bytes from fe80::f31c:ccff:fe26:a6d9%enp3s2: icmp_seq=1 ttl=64 time=0.467 ms (DUP!)

...

Pinging Link-Local Addresses

As you might guess, Link-Local unicast addresses by themselves also don't provide enough information to indicate which interface to use to reach them. As with our all-nodes multicast ping, we also need to supply either an interface as a ping command line parameter, or a zone ID with the address when pinging Link-Local addresses.

This time around we can use -c to limit the number of packets and responses ping sends and receives, since we're doing a unicast ping.

[mark@opy ~]$ ping -c 1 fe80::f31c:ccff:fe26:a6d9%enp3s2

PING fe80::f31c:ccff:fe26:a6d9%enp3s2(fe80::fad1:11ff:feb7:3704%enp3s2) 56 data bytes

64 bytes from fe80::f31c:ccff:fe26:a6d9%enp3s2: icmp_seq=1 ttl=64 time=0.395 ms

--- fe80::f31c:ccff:fe26:a6d9%enp3s2 ping statistics ---

1 packets transmitted, 1 received, 0% packet loss, time 0ms

rtt min/avg/max/mdev = 0.395/0.395/0.395/0.000 ms

[mark@opy ~]$

Pinging (all) other IPv6 Addresses?

In this article we've seen how to ping all IPv6 nodes on a link, using the all-nodes IPv6 multicast address of ff02::1. We've also seen how to specify which interface to use with the all-nodes IPv6 multicast address, as the address by itself cannot provide that information. We used either a ping command line parameter, or specified the interface via the %<zone_id> suffix.

We then learned about Link-Local unicast addresses, which are the addresses being used for the responses to the all-nodes multicast ICMPv6 Echo Requests.

We also saw how multicast packets are looped back into the sending node by default, and how to switch that off for the ping utility.

Finally, we pinged a single Link-Local address, using the %<zone_id> suffix, as Link-Local addresses by themselves also don't provide outgoing interface information.

So what about ping all other nodes and receiving their Global Unicast Addresses (GUAs) (i.e. their public Internet addresses) or their Unique Local Unicast Addresses (ULAs)? We'll cover that in the next blog article.