Subject: (ngtrans) RE: Shipworm-05 comments #1: size of prefix

From: "Christian Huitema" <[email-masked]>
Date: Mon, 25 Mar 2002 08:57:04 -0800

Pekka's comments address many points of the Teredo specification. I
would rather discuss them one by one rather than attempt an omnibus
reply. The first point is the size of the Teredo prefix:

> - I'm not sure how you're supposed to use the new variable length
prefix.
> If plen > 16, this would kill stateless autoconfig at least.
> 
> - It wasn't clear to me, at least from the above, how Shipworm is
> positioned: is it meant for a stand-alone node (like "6to4 host that
is
> also a 6to4 router"), or can it also be used for a subnet router?  If
not,
> this would decrease the usability somewhat.  Also see above about
> stateless autoconfig for subnet router case.

As Pekka mentions, we really have to choices: either allocate a /16 for
Teredo, or allocate any prefix length we see fit. If we allocate a /16,
then the Teredo prefix is a /64: 16 bits for the prefix, 32 bits for the
IP address, 16 bits for the port number. We can then use the /64 for the
auto-configuration of a subnet. If we allocate any length longer than
/16, then the address allocation rules prevent us from using the
resulting /n for auto-configuring a subnet; in that case, the prefix can
only be used by a single node. The choice between the two options should
be guided by the usage scenarios, which we are committed to write
according to the new NGTRANS marching orders.

There are three possible scenarios in which we can use Teredo: single
node, home gateway, and multiple nodes behind a NAT. The single node
scenario is easy to explain and manage: a node wants to participate in
an IPv6 only application; it tries to obtain an IPv6 address through the
regular means; if it cannot get a native address, an ISATAP address, or
a 6to4 address, and if it is not explicitly configured to use a tunnel,
then it uses Teredo to obtain at least one node address. In this single
node scenario, the prefix is not constrained to be a /64.

The home gateway scenario occurs when a home router wants to provide
IPv6 services to the nodes on the home network. The normal way to
achieve this is to obtain an IPv6 prefix natively, or to construct a
prefix using 6to4. If everything else fails, the router could envisage
using Teredo to obtain a prefix. In this scenario, the prefix must be a
/64.

The multiple nodes scenario occurs when several nodes located on the
same link (behind the same NAT) resort to using Teredo. One possibility
would be to elect one of the nodes to serve as the local Teredo router,
but the resulting configuration is very brittle. Election procedures are
inherently stateful and have well known failure modes; even if we do the
election right, the service on any given node depends on the continuous
operation of the selected "router". Another way to solve the scenario is
to let each node obtain a prefix independently, and then arrange for
some form of "shortcut routing" between the hosts located on the same
link; the 05 draft uses a local multicast advertisement to achieve this
shortcut routing. In this scenario, the prefix is not constrained to be
a /64.

From this rough scenario analysis, we conclude that using a global
Teredo prefix larger than a /16 will result in giving up the "home
router" scenario, while still maintaining the other two scenarios. This
scenario is mostly useful when there is a NAT "in the middle of the
network" - obviously, if the NAT is the home router itself, it is more
effective to use 6to4 than Teredo. If we do not support the home router
scenario using Teredo, the alternatives will be to use another
technology in the home router, for example configured tunnels over UDP,
or to let the nodes located behind the home router configure their own
Teredo addresses.

The main advantage of using prefixes larger than /16 is the ease of
deployment. A /16 is a scarce resource. The recent history shows that
the IANA will not allocate a /16 until the draft is finalized, i.e. is
accepted by the IESG; in any case, the IANA will allocate at most one
/16 prefix for Teredo. On the contrary, larger prefixes can be allocated
out of pre-existing allocations. For example, a service provider or an
organization can allocate a /64 out of their existing address space, and
maintain a local system of servers and relays.

That being said, there is still merit in having a global Teredo prefix,
by opposition to many local prefixes. An obvious advantage to a global
prefix, whatever its length, is that this prefix can be pre-programmed
in nodes, without having to resort to explicit configuration. Another
advantage is that we can maximize "prefix recognition", and thus use of
shortcut routing.

-- Christian Huitema