radical solutions

[smd@ebone.net (Sean Doran)]

This is hard for me to write nicely.

I am not making proposals here, I am offering my point of view, and 
some bits of free advice.  This is entirely predicated on the 
avoidance of the known failure of current inter-domain routing
technology to scale to anywhere near 10**7 prefixes while 
simultaneously remaining dynamic enough to see topology changes
reacted to across most of the Internet within minutes.  
Well before we reached today's 10**5 v4 prefixes, the introduction
of flap-dampening was needed to constrain dynamicism.   

If a decision is made to do something radical in v6-routing that is
not being done today in v4-routing, it will delay the deployment of
v6 as a native backbone frame type.

I have doubts that v6 is robust to delays; in particular, the existing
v6 topology is frail, and the growth of v6 VPublicNs and well-known
translation systems (6to4 with wk-unicast addresses or wk-anycast)
is generating a tangled network map that will be difficult to
untangle without an effective multihoming scheme that AT LEAST
accomplishes a transition of any-size site from one prefix to another prefix.

There are only two known technologies which can accomplish this today;
the first is renumbering, whether it's done by hand or through some form
of automation, while the second is the dreaded NAT, of which GSE's treatment
of "routing goop" bytes is a highly-constrained example.

Either way -- again, this is just my opinion, based on my experience -- the 
first n bits are going to need changing eventually, for all existing v6 
systems, whatever their nature. 

In the renumbering case, the host knows its address is changing,
and what it is changing to.   This includes the cases of simply
adding an address, or removing one of two-or-more existing addresses.

In the NAT case, the host does not know its address is changing, it
does not know what it is changing to, and it does not know what
else is happening in the header and/or body, depending on what type
of NAT (or ALG) is being performed.   Perhaps midcom can enlighten
the host, but this is not-yet-existing technology.

In the GSE case, the host knows its address is subject to change,
but it does not know, and must not care, what it is changing to.
It knows that there is pretty much nothing happening in the header
outside the modification of 8 source and 8 destination address bytes.
Any protocol which can live with arbitrary modifications to the top
8 bytes of any v6 header address, will not need an ALG or enlightenment
from a midcom box.   However, GSE is not-yet-existing technology.

My opinion is that without significant effort into handling
renumbering in the host and (more complicated) in routers, 
the only current solution to topology-change is to mutate 
packets on the fly.  That means NAT.  It is inevitable, simply
because wholesale magic renumbering of a large tree of devices
does not yet exist, and it is easier to be lazy and drop in 
a NAT than it is to renumber a large set of routers and hosts
with only limited automatic support.

However, GSE can be seen as a compromise that could constrain
present-day NATs to a very limited interference with an in-flight
v6 packet.   OTOH, market forces alone may arrive at that; after
all there is nearly no need for address-compression in IPv6,
and it's that aspect of NAT in v4 that is the hardest to deal with.

I am still no fan of v6, so it is no skin off my nose whether you
agree or disagree, whether it's because of multi-address-per-host
possibilities or belief in the standard's 8192-limit to the global 
routing space, or just because I'm someone who says things you don't like. 

	Sean.