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.

How to do SR in an RFC 8200 compliant way

How To Do SR In An RFC 8200 Compliant Way

Introduction

Currently there is a debate going on in the IETF 6man and SPRING working groups, about whether to allow insertion of Extension Headers (EHs) within existing packets when performing Segment Routing (SR).

The following article is the contents of a private email that I sent in this discussion which describes a model of how to do SR in IPv6 that is compliant with the Internet Standard RFC for IPv6, RFC 8200.

Note that all of the text is mine, including the '>' quotation from RFC 8200.

How to do SR in an RFC 8200 compliant way

"On Sun, 15 Sep 2019 at 09:45, Mark Smith <markzzzsmith@gmail.com> wrote:
>

<snip>

> After that, from RFC 8200,
>
> "Extension headers (except for the Hop-by-Hop Options header) are not
>    processed, inserted, or deleted by any node along a packet's delivery
>    path, until the packet reaches the node (or each of the set of nodes,
>    in the case of multicast) identified in the Destination Address field
>    of the IPv6 header."
>
>

So, to make it clear, the way to do SR in an RFC 8200 complaint way is
to have a path across an SR domain constructed of a (likely
contiguous) sequence of X-in-IPv6 tunnels.

At each of the tunnel origins is the opportunity to "insert" or add
new supplemental information via an newly created, or copied and
modified EH.

At each of the tunnel end-points is the opportunity to process the
received EHs. They could be used to create or copy and modify the EHs
that are used for the next segment in the path.

In other words, "segments" are 1:1 with X-in-IPv6 tunnels. In an IPv6
network, "Tunnel Routing" would be a synonym for Segment Routing.

If "mid-segment", supplemental information needs to be added or
removed, then that means the existing segment/tunnel has ended, and a
new segment/tunnel needs to start.

Another way to validate RFC 8200 compliance is to imagine that the
segment/tunnel head end applied encryption to the payload (i.e.
payload packet) via IPsec. Could a device mid-way along the segment
add or remove information? No it couldn't, it wouldn't even be able to
recognise that the packet is a segment/tunnel packet, because that
information is hidden by the encryption.

If, in the presence of encryption, a segment/tunnel "midpoint" needs
to add or remove information, then that is solved by making the
"midpoint" a segment/tunnel end-point. The end-point would have the
decryption key, would know the packet is to be processed locally
because the end-point node has the same DA as in the packet, and would
know which decryption key to use because of the packet's Source
Address.

Yes, there is an overhead issue with X-in-IPv6 tunnelling, which is
fundamentally caused by IPv6 addresses being so large. They're large
because they need to be able to uniquely identify all IPv6 nodes in
literally all contexts i.e. the global Internet, and perhaps down the
track the entire Universe.

I doubt this literal global uniqueness of IPv6 addresses and therefore
literal globally unique SIDs is necessary in a limited domain model
and mechanism such as SR, which is why SR over MPLS or native SR over
IPv4 would be ways to avoid this X-over-IPv6 overhead.

However, as IPv6 is likely the future commodity (cheapest) protocol,
the overhead is the cost of gaining from IPv6 commodification. Nothing
is free, everything is a trade off.

There are ways to reduce this X-in-IPv6 overhead that both don't
compromise and would fit RFC 8200:

"Skinny IPv6 in IPv6 Tunnelling"
https://tools.ietf.org/html/draft-smith-skinny-ipv6-in-ipv6-tunnelling-00

"The RObust Header Compression (ROHC) Framework"
https://tools.ietf.org/html/rfc5795

(I don't know much about ROHC, however I think could be applied to the
inner X payload packet before the compressed packet is then
encapsulated in the new outer X-in-IPv6 tunnel header. Performance and
state would likely be an issue at high Gbps, which is why I wrote
"Skinny IPv6 in IPv6 Tunnelling".)

There may be other suitable compression methods.

Regards,
Mark."

RFCs and IDs

This page is serving as a placeholder for the IETF RFCs that I've reviewed and contributed to and the Internet Drafts I've authored or co-authored.

Working Group Detailed Reviewer (One of)

RFC7421 - Analysis of the 64-bit Boundary in IPv6 Addressing
RFC7217 - A Method for Generating Semantically Opaque Interface Identifiers with IPv6 Stateless Address Autoconfiguration (SLAAC)


Authors' Requested Reviewer

RFC8799 - Limited Domains and Internet Protocols

RFC8981 - Temporary Address Extensions for Stateless Address Autoconfiguration in IPv6


Acknowledged Reviewer and Contributor

RFC4864 - Local Network Protection for IPv6
RFC4942 - IPv6 Transition/Coexistence Security Considerations
RFC5156 - Special-Use IPv6 Addresses
RFC5375 - IPv6 Unicast Address Assignment Considerations
RFC6036 - Emerging Service Provider Scenarios for IPv6 Deployment
RFC6085 - Address Mapping of IPv6 Multicast Packets on Ethernet
RFC6343 - Advisory Guidelines for 6to4 Deployment
RFC6436 - Rationale for Update to the IPv6 Flow Label Specification
RFC6437 - IPv6 Flow Label Specification
RFC6555 - Happy Eyeballs: Success with Dual-Stack Hosts
RFC6877 - 464XLAT: Combination of Stateful and Stateless Translation
RFC6883 - IPv6 Guidance for Internet Content Providers and Application Service Providers
RFC6911 - RADIUS Attributes for IPv6 Access Networks
RFC6964 - Operational Guidance for IPv6 Deployment in IPv4 Sites Using the Intra-Site Automatic Tunnel Addressing Protocol (ISATAP)
RFC6980 - Security Implications of IPv6 Fragmentation with IPv6 Neighbor Discovery
RFC7043 - Resource Records for EUI-48 and EUI-64 Addresses in the DNS
RFC7094 - Architectural Considerations of IP Anycast
RFC7278 - Extending an IPv6 /64 Prefix from a Third Generation Partnership Project (3GPP) Mobile Interface to a LAN Link
RFC7136 - Significance of IPv6 Interface Identifiers
RFC7503 - OSPFv3 Autoconfiguration
RFC7610 (BCP199) - DHCPv6-Shield: Protecting against Rogue DHCPv6 Servers
RFC7739 - Security Implications of Predictable Fragment Identification Values
RFC7721 - Security and Privacy Considerations for IPv6 Address Generation Mechanisms
RFC7772 (BCP202) - Reducing Energy Consumption of Router Advertisements
RFC7872 - Observations on the Dropping of Packets with IPv6 Extension Headers in the Real World
RFC7934 (BCP204) - Host Address Availability Recommendations
RFC8028 - First-Hop Router Selection by Hosts in a Multi-Prefix Network
RFC8064 - Recommendation on Stable IPv6 Interface Identifiers
RFC8106 - IPv6 Router Advertisement Options for DNS Configuration

RFC8883 - ICMPv6 Errors for Discarding Packets Due to Processing Limits

RFC8978 - Reaction of IPv6 Stateless Address Autoconfiguration (SLAAC) to Flash-Renumbering Events

RFC9096 - Improving the Reaction of Customer Edge Routers to IPv6 Renumbering Events

RFC9131 - Gratuitous Neighbor Discovery: Creating Neighbor Cache Entries on First-Hop Routers
RFC9268 - IPv6 Minimum Path MTU Hop-by-Hop Option

RFC9486 - IPv6 Options for In Situ Operations, Administration, and Maintenance (IOAM)

RFC9602 - Segment Routing over IPv6 (SRv6) Segment Identifiers in the IPv6 Addressing Architecture

RFC9631 - The IPv6 Compact Routing Header (CRH)

Authored Internet Drafts

draft-smith-v6ops-larger-ipv6-loopback-prefix - A Larger Loopback Prefix for IPv6
draft-smith-6man-mitigate-nd-cache-dos-slnd - Mitigating IPv6 Neighbor Discovery DoS Attack Using Stateless Neighbor Presence Discovery
draft-smith-mldv2-link-unicast - MLDv2 Procedures for Link-Layer Unicast Delivery of Multicast IPv6
draft-smith-v6ops-ce-dhcpv6-transparency - IPv6 CE Device DHCPv6 Option Transparency
draft-smith-v6ops-mitigate-rtr-dos-mld-slctd-node - Further Mitigating Router ND Cache Exhaustion DoS Attacks Using Solicited-Node Group Membership
draft-smith-enhance-vne-with-ipv6 - Enhancing Virtual Network Encapsulation with IPv6
draft-smith-6man-link-locals-off-link - Indicating Link-Local Unicast Destinations are Off-Link
draft-smith-ipv6-link-locals-apps - How to use IPv6 Link-Local Addresses in Applications
draft-smith-skinny-ipv6-in-ipv6-tunnelling - Skinny IPv6 in IPv6 Tunnelling
draft-smith-6man-form-func-anycast-addresses -
IPv6 Formal Anycast Addresses and Functional Anycast Addresses
draft-smith-6man-in-flight-eh-insertion-harmful - In-Flight IPv6 Extension Header Insertion Considered Harmful
draft-smith-v6ops-local-only-addressing - Default IPv6 Local Only Addressing for Non-Internet Devices draft-smith-6man-accurate-ra-router-lifetime - More Accurately Naming IPv6 RA Router Lifetime

draft-smith-6man-more-secure-rh - More Secure IPv6 Routing Header Processing

draft-smith-ietf-routers-vs-hosts - Routers Verses Hosts; Devices Verses Functions