Let's Focus on Moving Forward Re: V6 still not supported Re: 20220326125.AYC

Fri Apr 1 23:45:54 UTC 2022

Owen DeLong via NANOG writes:

> Just because there is a small code snippet you found that prevents casting 240/4 as unicast on an interface doesn’t mean that removing that code will magically make 240/4 usable in the entire stack.
> 
> [...]
> 
> The code you found may just be a safety valve to prevent the user from doing something stupid that will have undefined consequences down the line if executed. What you appear to have found is, quite likely, the equivalent of a buffer bounds check on input. Removing the check doesn’t inherently make the buffer infinite.

We've found remarkably few other places in Unix userspace that made
assumptions that would forbid the use of 240/4.  When we do find such
a thing, we propose a patch for that too.

Obviously, this can't prove that there is no application left that
treats 240/4 specially somehow.  Here is one!

# Refuse reserved peer addresses in userspace.

import socket
import sys

s = socket.socket()
s.bind(("0.0.0.0", int(sys.argv[1])))
s.listen()
conn, addr = s.accept()
if socket.inet_aton(addr[0])[0] >= 240:
    conn.close()
    raise ValueError("Reserved peer address {}".format(addr[0]))
conn.send(b"Hello, world!\n")
conn.close()

As long as people are running that application, their systems won't
be fully compatible with use of 240/4.

However, I haven't seen documentation that specifically encourages
network developers to do this kind of check for themselves (instead,
it's usually left to the OS).  I would be surprised if it were common
in userspace anywhere.

The way we will find out about these issues (and to some extent the way
we have been finding out about them already) is by running networks
that use these addresses with already-patched OSes, and seeing what
works or doesn't work.  I've noted in several talks that you can easily
try this for yourself if you run a wifi network that gives out internal
addresses in 240/4 and NATs them.  You can actually use this for
day-to-day work -- if you're not on Windows -- and gain more experience
and data about any possible problems.

There _are_ somewhat more often special cases in dynamic routing,
(to a lesser extent) autoconfiguration tools, and dedicated routers.
However, those we've seen and fixed have also represented tiny code
changes within those tools.

> It’s also important to note that there are at least a dozen IPv4 stacks in common use with differing code implementations and underlying assumptions baked into the code in various places.

Yes, for example I found a printer that was unhappy with 240/4.
Although I'm confident that the software changes needed are also
tiny, it may be difficult to get the vendor to issue them officially.

It's too bad that we couldn't officially agree back in 2008 to ask
the printer vendor, or its embedded OS developer, to make those
changes then.  If it gets to be 2036 and we've had 14 more years of
printers being manufactured with this behavior, that will be
unfortunate, too.