Re: OK, shim6, if we must [Re: [RAM] Ivip (was ViP ...)]

[Robin Whittle <rw at firstpr.com.au>]

There are a number of recent messages which I would like to
respond to, but for now I will just reply to two things
mentioned by Christian Vogt:

> Right.  But maybe is good to clarify that LISP/Ivip can be used only for
> site multi-homing, whereas Shim6 can also be used for host multi-homing.

It has never been my vision that LISP (or Ivip, which is not
yet two weeks old) is only capable of, or should only be
used for, controlling the tunneling of packets to ETRs in
large groups, meaning subnets or prefixes like those
typically handled by BPG.  So I have never thought they "can
be used only for site multi-homing".

Also, I think my view of how addresses wind up in the
LISP/Ivip system is rather different from what the LISP
proponents and maybe others have in mind.  I have written
about this in the long messages listed at:
http://www.firstpr.com.au/ip/ivip/ , especially:
http://www1.ietf.org/mail-archive/web/ram/current/msg01561.html

The database and ITRs are a massive piece of infrastructure
and if we ensure they are able to handle millions to hundreds
of millions of different mappings, including for individual
IPv4 addresses, then we will gain benefits far beyond
multihoming and TE at site-granularity.

Firstly, we can slice and dice and move the physical
destination of one or more billions of IPv4 addresses with
arbitrary finesse in the dimensions of both time and
address-space.  This will never be possible with the global
BGP system.  I don't suggest that the granularity for an
IPv6 Ivip system be all the way to a /128.  To a /64 sounds
more realistic.

This enables the most important goal I see: the more
efficient use of IPv4 address space - without further
burdening the BGP system.  This address space can be assigned
without a care about route aggregation or the binary
boundaries of conventional prefixes.  This means it can be
dealt out in small chunks, like one or a few or a hundred or
whatever IP addresses as people need them, not the overblown
traditional PI allocation of 256, 512, 1024, . . . 16,384 . .
. IP addresses which are "big enough for expansion over the
next few years" - expansion which often never happens.

The second immensely valuable benefit is that this ITR
infrastructure can beam packets around the Net to ETRs which
are actually what I call Translating Tunnel Routers - which
have two-way tunnels to nearby truly mobile devices.  That
would completely transform mobile IP, by enabling the mobile
nodes to pick the nearest TTRs, wherever they are (inside or
outside edge networks).  Path lengths would be close to
optimal, no matter where the mobile node and corresponding
nodes are.   The mobile nodes don't require any special
handling by the edge network, and they can be behind NAT too.

There are serious questions of scaling here, in terms of the
number of address divisions the ITRs and the database handles
and the frequency of updates.  There probably needs to be an
extra charge for updates, or updates above a certain rate.

Maybe there could be two or more Ivip systems, covering
different ranges of addresses.  One could have low fees and
generally do updates at a rate suitable for multihoming.
Another could be optimised for more rapid changes in mapping.
I am not convinced two or more systems would be good, but
I don't rule it out.

Anyone could roll out such a system today, as a revenue
generating business, as long as their RIR approved of their
address space being used for this novel purpose.  There
would need to be either a bunch of standardised ETRs in
edge networks, with local routing support for the
Ivip-mapped addresses, or the operators would need TTRs all
around the Net, so their customers could put their hosts on
an IP address in any nearby edge network and install a
little piece of tunnel software to tunnel incoming and
outgoing packets to the TTRs.


Any global ITR and database system, whether it is LISP or
Ivip or whatever, will be a truly heroic, bold,
architectural enhancement for the Internet.

We might as well do a proper job of it.


> And with respect to site multi-homing, LISP/Ivip takes precedence over
> Shim6 in that a site doing multi-homing with LISP/Ivip would effectively
> prevent hosts from managing site multi-homing with Shim6.

SHIM6 couldn't work normally with /128 specific Ivip,
because the HBA address generation would need to be done by
the host and the Ivip system's mapping made to match each
such address, for each ISP.  However, if the host had a
whole /64 via Ivip, or two such /64s via different ISPs,
then it could do SHIM6 multihoming fine.  I am not sure what
purpose would be served, because Ivip could provide a whole
/64 multihomed via two ISPs anyway.  This would require ETRs
in each ISP and support for the /64 in the ISP's routing
system, including to allow packets out with source addresses
in this range.

SHIM6 doesn't require anything from networks.  All it needs
is appropriate software in all the hosts, and two IP
addresses from two links to two ISPs, and it can do
multihoming.  SHIM6 is only going to be for IPv6, and only
widely used some years after it is finalised, when sufficient
operating systems and devices (3G cellphones etc.) support it
properly.  I doubt if anyone would want to multihome with
SHIM6 if even a small fraction of the hosts they are trying
to communicate with couldn't follow their host to its second
IP address.

SHIM6 can't provide the global portability (or mobility) of
IP addresses or whole prefixes of addresses which LISP/Ivip
can provide.  But SHIM6 is free, autonomous and self-
contained - and doesn't require thousands of souped-up
routers, a huge, fast, distributed yet in some way
centralised database and all the money, administration and
tortuous policy debates that will entail!

 - Robin


_______________________________________________
RAM mailing list
RAM at iab.org
https://www1.ietf.org/mailman/listinfo/ram