[Cu-wireless] phase iii network: v4/v6 addressing & Internet connectivity

[David Young]

Here is my proposal for v4/v6 addressing and gateway selection on the
network that we are developing with the OSI funds.  Please feel free to
rip this proposal to shreds.

BTW, a lot of the following stems from an interesting discussion going
on right now on the IETF MANET list, and a suggestion by Perry Metzger
to look at 6to4.  Of course, I take full responsibility for any nonsense
I am about to write.

In this proposal, I assume that we will use Hazy Sighted Link State
(HSLS) routing. I assume that in the HSLS link-state updates (LSUs),
we will reserve extension fields.

With this proposal, I am trying to treat present problems, to anticipate
a future problems, and to serve our desires for the network's future.
Here are some present and future problems, and desires.

  1 We want to be able to provide every subscriber with at least
    one routable IP number, since that is what they will need to use
    the full spectrum of Internet apps, and also to run a server.

  2 Routable IPv4 numbers are in short supply. It is not clear
    whether CWNs can get hold of them, and it appears that they will
    cost a *lot*. IPv6 numbers, on the the other hand, are plentiful
    and essentially free.

  3 IPv6 is unquestionably the future of the Internet.People are already
    using v6 a little bit, both Mac OS X and Windows XP support it, and
    wherever IPv4 numbers are "running out"---in Asia, for example---there
    are already significant economic and government incentives to
    adopt v6.  It would be foolish to design without this in mind.

  4 IPv6 numbers can already be had very easily: if you have a single IPv4
    number, you can use "6to4" to get a /48 in IPv6
    space. That is 2**80 IPv6 addresses, which is enough to
    assign a number to each of your home appliances.  (Yes,
    it is *that* *many*.) For more info, see this tutorial,
    <http://www.onlamp.com/pub/a/onlamp/2001/06/01/ipv6_tutorial.html>.

  5 As long as we auto-assign IPv4 numbers, we have to count on address
    duplication. We have to detect duplication and correct it. IPv6
    auto-configuration will occasionally duplicate addresses, too.

  6 It seems inevitable that CWNs are going to be multihomed.  Maybe it
    will be for greater bandwidth or reliability. It might just happen
    by accident!  In any case, multihoming will complicate matters.

  7 I want for our nodes to be reached easily from the Internet, since
    that will help far more people to participate in network development,
    maintenance, and troubleshooting.  When our networks are NAT'd onto
    the Internet, it is awfully hard to provide a connection into each
    node from the Internet. 6to4 connectivity is an enormous help there.
    Granted, developers will need an IPv6-capable computer, but you're
    a geek, right? (The C-U Wireless development server is IPv6 capable,
    BTW.)

  8 Our routers fail in spectacular ways when you plug them into an
    Internet gateway that issues IP numbers out of 10/8.

My proposal is this. All routers route both IPv6 and IPv4. They use IPv6
transport for the routing protocol messages. At bootstrap time, each
router picks a globally-routable IPv6 number with the same arbitrary
prefix (f00d, say) for its wireless interface. Also at bootstrap time,
a router tries to get an IPv4 number on its ethernets, refusing any
IP in 10/8.  Depending the router receives a routable IPv4 number, a
private IPv4 number, or no v4 number on an ethernet, it sets different
link flags for that ethernet.  The flags are 6to4 and nat.

(Hopefully a routable prefix, such as f00d, will be reserved for
bootstrapping routing on ad hoc networks---there used to be an Internet
draft on that recommended that....)

If a DHCP server assigns a routable IPv4 number to a router's ethernet,
then that router sets both the "6to4" and "nat" properties for that
ethernet to the IP number that was assigned. If a DHCP server assigns
a private IPv4 number, then only the ethernet's "nat" property is set.

An link with either a "nat" or "6to4" property, I will call a "gateway
link," and the rooftop router that the link belongs to, "a gateway
router." Gateways advertising a link w/ "6to4" property are "6to4
gateways," and gateways w/ "nat" property are "nat gateways."

HSLS link-state updates will carry an interface's "nat" and "6to4"
properties. Routers wanting v6 connectivity will select the 6to4 gateway
with the best path metric, breaking ties by choosing the gateway whose
6to4 number is smallest (0.0.0.128 is smaller than 128.0.0.0).  When a
router selects a 6to4 gateway, its role changes to "gateway supplicant"
or simply "supplicant." A v6 supplicant asks its chosen 6to4 gateway for
a /61 network.  If any unused /61s remain in the gateway's 6to4 subnet,
the gateway answers the supplicant with one.  The supplicant assigns /64s
from the /61 to its interfaces. Then it creates a IPv6-in-IPv6 tunnel to
the 6to4 gateway, and points the default route through the tunnel. HSLS
will propagate routes to the supplicants interfaces. What you end up
with is IPv6 tunnel-encapsulated traffic between the supplicant and the
6to4 gateway, and unencapsulated traffic in the other direction.

Routers wanting v4 connectivity choose a nat gateway. They choose it by
the same criteria as a 6to4 gateway. A nat supplicant will not assign
different numbers to its ethernets than the 10/8 numbers already assigned.
It will tunnel to its gateway, but its gateway will send unencapsulated
packets back.

A router will select a new gateway with some hysteresis: it will not
choose a new gateway unless the gateway has a "much better" metric for a
"short time," or else a somewhat better metric for a long time. So that
sessions that go through an old gateway are not needlessly terminated,
a router will leave the tunnel to its old gateway open even after it has
chosen a new gateway, and in the case of a 6to4 gateway, a router will
leave the old IPv6 addresses on its interfaces. However, the default
route will be changed to point through the new tunnel (this should not
break existing sessions, since they will have host routes through the
old tunnel), and new IPv6 aliases will be assigned (also should not
break sessions, but I'm not as sure of it).

In the future, there will be v4 and v6 link properties which indicate
a gateway w/o NAT or 6to4. Ordinarily a gateway will speak OSPF or BGP
on these interfaces, however, we will still tunnel to the gateway.

I don't think we should ever let HSLS propagate a default route, but we
should use the tunnels. I think that gateway selection and migration is
probably going to get more complicated before it gets less complicated,
so I prefer to put that function in its own module, separate from HSLS,
until we give gateway selection a good shake-out.

I think that there will also be link properties ns and nsd, indicating
name service and dynamic name service---i.e., a server where routers can
register new name<->number associations, kind of like dyndns.org and such.

Ok, that's all I've thought of so far.  Let me have it! =)

Dave

-- 
David Young             OJC Technologies
dyoung at ojctech.com      Urbana, IL * (217) 278-3933