Re: [RAM] Ivip (was ViP ...)

Here is some more discussion of the similarities and differences
between Ivip-mobile and various types of Mobile-IP.

This is from an off-list exchange with a list member who does
not at present have time to be fully involved with the
discussion, and who gave me permission to post this to the list.
 He provides links to I-Ds concerning new developments in Mobile-IP.

At the end, I also speculate that something like LISP/Ivip will
either be required in order for IPv6 to be widely adopted (if no
PI space is made available for AS-end-users) or if it does
become widely adopted (after PI space is made available to
AS-end-users).  In either case, I speculate that LISP/Ivip or
similar with its global network of ITRs beaming packets to
whichever ETR or TTR (or some other term for the tunnel router
which has a 2-way tunnel to mobile devices) would make mobile IP
very much easier and probably make SHIM6 less important.

 - Robin     http://www.firstpr.com.au/ip/ivip/

RW> Ivip's notion of large numbers of public ITRs and TTRs (by
RW> paid-for access I guess) with the mobile host choosing
RW> which TTR to use at any time, does not seem to have a
RW> parallel in these pre-existing mobile systems, which
RW> assume a fixed home-agent router.
>
> <snip>
>
> That's not 100% correct: The Mobile IPv6 bootstrapping
> extensions (draft-ietf-mip6-bootstrapping-split-05.txt,
> draft-ietf-mip6-bootstrapping-integrated-dhc-04.txt) allow the
> mobile node to choose and change the home agent and obtain a
> corresponding home address dynamically. The home agent could
> be located in the mobile node's current access network (i.e.,
> a local home agent) or anywhere else (assuming the necessary
> trust relationships between Mobility Service Authorizer and
> Mobility Service Provider are in place; please see above draft
> for details).

Mobile IPv6 bootstrapping in split scenario
http://tools.ietf.org/html/draft-ietf-mip6-bootstrapping-split

  A Mobile IPv6 node requires a Home Agent address, a home
  address, and IPsec security associations with its Home Agent
  before it can start utilizing Mobile IPv6 service.  RFC 3775
  requires that some or all of these are statically configured.
  This document defines how a Mobile IPv6 node can bootstrap
  this information from non-topological information and security
  credentials preconfigured on the Mobile Node.  The solution
  defined in this document solves the Mobile IPv6 bootstrapping
  problem (RFC4640) when the Mobile Node's mobility service is
  authorized by a different service provider than basic network
  access, and is therefore generically applicable to any
  bootstrapping case.

MIP6-bootstrapping for the Integrated Scenario
http://tools.ietf.org/html/draft-ietf-mip6-bootstrapping-integrated-dhc

  Mobile IPv6 bootstrapping can be categorized into two primary
  scenarios, the split scenario and the integrated scenario.  In
  the split scenario, the mobile node's mobility service is
  authorized by a different service authorizer than the network
  access authorizer.  In the the integrated scenario, the mobile
  node's mobility service is authorized by the same service
  authorizer as the network access service authorizer.  This
  document defines a method for home agent information discovery
  for the integrated scenario.

> Furthermore, a mobile node may have multiple home addresses
> and may be registered with multiple home agents.
> draft-weniger-mobopts-mip6-cnlocpriv-02 describes a
> MIPv6-based scenario, where the mobile node bootstraps with
> home agents close to correspondent nodes. Such home agent
> would look even more similar to an ETR.

MIPv6 Correspondent Node-Targeted Location Privacy and Optimized
Routing
http://tools.ietf.org/html/draft-weniger-mobopts-mip6-cnlocpriv

  This draft discusses the problem of correspondent
  node-targeted location privacy in Mobile IPv6 and proposes a
  mechanism to achieve simultaneous optimized routing and strong
  correspondent node-targeted location privacy.  The mechanism
  utilizes the MIPv6 bootstrapping mechanisms and does neither
  require any new network entities nor changes to home agent or
  correspondent node implementations.

> Finally, a proxy entity in the network may send registration
> and act as tunnel endpoint on behalf of the mobile node. This
> is specified in the Proxy Mobile IPv6 draft
> (draft-ietf-netlmm-proxymip6-01.txt) and the network entity is
> called Mobile Access Gateway (MAG). The MAG would be similar
> to an ITR.
>
> With Proxy Mobile IPv6, the Mobile Node can be an unmodified
> IPv4 or IPv6 host (i.e., the host has no "second" address,
> since the care-of address is managed by the proxy entity).

Proxy Mobile IPv6
http://tools.ietf.org/html/draft-ietf-netlmm-proxymip6

  Host based IPv6 mobility is specified in Mobile IPv6 base
  specification [RFC3775].  In that model, the mobile node is
  responsible for doing the signalling to its home agent to
  enable session continuity as it moves between subnets.  The
  design principle in the case of host-based mobility relies on
  the mobile node being in control of the mobility management.
  Network based mobility allows IP session continuity for a
  mobile node without its involvement in mobility management.
  This specification describes a protocol solution for network
  based mobility management that relies on Mobile IPv6
  signalling and reuse of home agent functionality.  A proxy
  mobility agent in the network which manages the mobility for a
  mobile node is the reason for referring to this protocol as
  Proxy Mobile IPv6.

  It is possible to support mobility for IPv6 nodes by extending
  Mobile IPv6 [RFC-3775] signaling and reusing the home agent
  via a proxy mobility agent in the network.  This approach to
  supporting mobility does not require the mobile node to be
  involved in the signalling required for mobility management.
  The proxy mobility agent in the network performs the signalling
  and does the mobility management on behalf of the mobile node.

This is a fresh I-D, April 2007, and "Proxy Mobile IPv6" is
still a fairly novel term, with Google only finding 63 pages
mentioning it.  Previous Proxy Mobile IPv6 I-Ds are:

http://tools.ietf.org/html/draft-sgundave-mip6-proxymip6
http://tools.ietf.org/html/draft-devarapalli-netlmm-pmipv6-mipv6

Diag. 1

> So a possible MIPv6-based scenario could be the following:
>
>  MN1---(MAG1)---\
>       /          \
>  MN2-/            \
>                   (HA1)----CN
>                   /
>  MN3-------------/
>
>        (MAG2)     (HA2)
>
> MN3 would be Mobile IPv6 mobile node and MN1,MN2 would be
> Proxy Mobile IPv6 nodes. Tunnelling would happen between MAG1
> and HA1 and between MN3 and HA1. This looks quite similar to
> your ivip, no?

There are some similarities.  I will try to point out the
differences too.

Ivip-basic is just LISP (or rather some simple aspects of LISP,
without multiple encapsulation or messages going along with
packets regarding LISP-mapping of the source address) with the
ITRs automatically catching the raw packets from the
"correspondent nodes" (to use mobile IP terminology for an
ordinary host which is not part of the new system), no matter
where they originate from, because the Ivip-mapped address space
is part of one of many "master-subnets" which are advertised in
BGP.

With Ivip, if the raw packet, which is addressed to the
Ivip-mapped address, is not caught and tunnelled by the ITR
function of an internal or border router, it will soon be
forwarded to ITR outside the edge network.  There is a 1-way
tunnel from that ITR, and from many other ITRs handling packets
from other correspondent nodes, with all these tunnels
converging on an ETR, which terminates the tunnel and forwards
the raw packet to the destination host.

In general I think the similarities between this and mobile IP
are not very significant, however - I have only a cursory
understanding of Mobile-IP, and what you wrote in your second
email, which I have included in the quotes above, regarding
proxy Mobile IPv6 is something I had never heard of, which does
have some connection.

Firstly, the system doesn't require any special software on the
Correspondent Nodes (CN) or the host whose address is Ivip-mapped.

I understand no special software is required in Mobile-IPv6 for:

1 - A CN using ordinary Mobile-IPv6 communication to the home
    address of the Mobile Node (MN), where the home-agent
    router uses Tunnel Mode.  (Special software in the CN is
    required to use the more efficient alternative - route
    optimisation: direct communication with the MN at its
    care-of address.

2 - A MN using Proxy Mobile-IPv6.  I haven't read how it is
    done, but I understand that the MN has only its own IP
    address and it (and probably other MNs) are in a
    direct network connection with the proxy somehow does all
    the mobile-specific work for the one or more MNs it serves.

Secondly, LISP/Ivip is intended to be applicable for both IPv4
and IPv6 - although I have only been discussing IPv4 use of Ivip
so far.

Thirdly, except for Proxy Mobile IPv6, all mobile-IP systems
involve the mobile host having one or more physical IP addresses
(each is a "care-of" address) where it connects to the Net, and
having one stable IP address by which correspondent nodes send
it packets.  The simplest arrangement is Mobile-IPv6 in tunnel
mode where the mobile host always responds as if it has the
address it has on its home network, perhaps on an office LAN,
for instance.  This means the mobile host always has some fancy
software which implements all this, sending and receiving
packets to and from a tunnel, working from one or more physical
"care-of" IP addresses (each from a different wireless network
etc.) but allowing some or all of the operating system and
applications to work as if they had the mobile-host's home IP
address.

Ivip-basic and LISP do not involve the receiving host having any
IP address but its own.  I haven't stated this clearly before.

(By "receiving host" I mean the host whose IP address is
portable between ISPs, effectively mobile and able to be
multihomed by selecting different ETRs via links which use
different edge networks.  This "receiving host" can use this
same IP address when it is located in any ISP who supports it
with an ETR and correct internal routing configuration,
including letting the mobile host's packets go out to the Net,
as long as the ITRs all tunnel packets addresses to this IP
address to the correct ETR.)

In LISP/Ivip, the receiving host has no tunnel establishment or
end-point features.

In Ivip and I think in general LISP there is no 2-way tunnel.
Only 1-way tunnelling from potentially multiple ITRs to the one
ETR at any one time.  (I find the LISP I-D to cover so many
potential configurations that it is hard to understand clearly.)

I think this makes LISP or Ivip-basic very different from
Mobile-IP, except in some ways Proxy Mobile IPv6.

A MN with Proxy Mobile IPv6 is something like a "receiving host"
(sorry about this interchangeable "node" / "host" stuff) whose
IP address has been mapped by Ivip and is in an edge network,
perhaps with other receiving hosts and there is a single router
which performs its ETR and default gateway functions.

In both cases the MN / receiving host has only one IP address
and has no special software.  In both cases, the overall system
of Proxy Mobile IPv6 - or Ivip-basic and the local network's
ability to handle outgoing packets from the ETR/default gateway
- enable the MN / receiving host to be anywhere, but still
retain its one IP address.

With Proxy Mobile IPv6 router is called a "Mobile Access
Gateway" and I would redraw your diagram like this:

Diag. 2

  MN1---(MAG1)====
       /          =
  MN2-/            =
                   (HA1)----CN
                   =
  MN3==============

        (MAG2)     (HA2)

> MN3 would be Mobile IPv6 mobile node and MN1,MN2 would be
> Proxy Mobile IPv6 nodes. Tunnelling would happen between MAG1
> and HA1 and between MN3 and HA1. This looks quite similar to
> your ivip, no?

Where ----- means ordinary two way raw packets and ==== means
a 2-way tunnel between the Home Agent router and either the
Mobile Node (MN3) or the (MAG1) which I understand behaves like
one or more Mobile Nodes as far as the Home Agent is concerned.

I think it is challenging to understand all the variations of
mobile IP.  I find SHIM6 really hard to understand, though I
have not tried reading the whole of what I think is the most
up-to-date documents:

  RFC4177 and draft-ietf-shim6-proto.

I would like to fully understand all this.

Ivip-mobile is an extension to Ivip-basic.  The same principles
could be used with LISP (2.00+) With both LISP and Ivip-basic,
there is a large number of ITRs which 1-way tunnel packets
addressed to a particular IP address or subnet, wherever the
central system directs them to.  The tunnelled packets for any
given LISP/Ivip-mapped IP address are are all directed to a
particular BGP-mapped IP address, which is the ETR.

Ivip-mobile is simply:

1 - A mobile host (or some other system looking after its
    interests) being able to tell the database to have the
    ITRs tunnel the packets to any ETR, where the ETR is
    actually a TTR which has a two-way tunnel to the
    mobile host, previously established by the mobile host.

    As with Mobile IP's Home Agent, the TTR is the exit
    point for the mobile host's outgoing packets.  (The
    TTR may also perform an ITR function on those outgoing
    packets if they are addressed to an Ivip-mapped address,
    or simply tunnel the packets to a second mobile host it
    has a tunnel to, if the destination of the packets is
    the second mobile host's Ivip-mapped IP address.)

2 - The ability of the mobile host to build tunnels to
    multiple TTRs and by some means have the ITRs direct
    packets to one or another of the TTRs.

In your diagram:

>  MN1---(MAG1)---\
>       /          \
>  MN2-/            \
>                   (HA1)----CN
>                   /
>  MN3-------------/
>
>        (MAG2)     (HA2)

the hosts/nodes whose IP address is handled by the mobility
system are on the left, where in my diagrams in previous
messages they were on the right.

Here is your diagram rewritten to match Ivip-basic:

Diag. 3

                             /---CN1
                            /
 RN1---(ETR1)~~(TR)~~~~~(ITR1)---CN2
      -          ~
 RN2--            ~
                   (ITR2)--------CN3
                   ~
 RN3--(ETR2)~~~~~~~

      (ETR3)           (ITR3)
       ....             ....
      (ETRn)           (ITRn)

      TR is an ordinary transit router.

      ITR1 might also be a border or transit router.

      ITR2 is also transit router.

----  Raw packets flowing right-to-left.

~~~~  1-way tunnelled (IP-in-IP) packets flowing
      generally right-to-left, except for the
      tunnel (ETR1)>(TR)>(ITR2)>(ETR2) which involves
      a little left-to-right in this diagram.  In
      this case, ITR2 is acting like an ordinary
      transit router for those encapsulated packets.

      The ETR functions are performed in internal or
      border routers.  Many other routers are not
      shown.

      If we add another ---- link from RN2 to ETR2 then
      RN2 will be multihomed.

RN1, RN2 and RN3 each have a single IP address, which is within
one of the "master-subnets" which all the ITRs advertise.  They
have no other IP address.

Raw packets addressed to RN1, RN2 or RN3 from CN1, CN2 or CN3
are all forwarded to the nearest ITR.  This ITR function may be
performed in a router inside their edge edge network, in a
border router, in a transit router or in a specialised ITR which
has a stub connection to a transit router.

Diag. 4
                   (ITR4)
                    ~  |
                    ~  |
   RN4---<-(ETR4)~~~(TR)--<--CN4

Here a packet addressed to an Ivip-mapped IP address travels
from CN4 to a transit router.  The transit router sends it to
the ITR4 which is the closest of potentially tens of thousands
of ITRs which advertise the complete set of "master-subnets" of
addresses which are handled by the Ivip system.

The ITR4 has only one connection - to the transit router.  It
encapsulates the packets in IP-in-IP headers addressed to
whichever ETR the original packet's address is mapped to,
according to the central database which the ETR has an
up-to-date copy of, or which it queries and maintains a partial
cache of.

The transit router then forwards it through various other
routers not shown to wherever in the world the ETR is.  The ETR
strips off the header and sends the raw packet on a local
network to the Receiving Node.

The ETR can be a relatively dumb, unmanaged, router which is not
at all part of the database-ITR system.  It simply decapsulates
the packet and the local routing system of the edge network must
be configured to forward the packet to the RNn.

The ETR function is always implemented in an internal or border
router.  It is never in the "core" - meaning implemented in a
transit router.  This is because the decapsulated packets have
the final IP address and need to be handled by a suitably
configured local routing system to get them to the RN.  Without
this special routing, they would be forwarded to the border
router, since they are part of one of the "master-subnets" which
all the ITRs advertise.  (With LISP, the mapped address is not
part of any BGP advertised prefix, but the local network still
needs to route the decapsulated packets to the RN, and allow
packets from the RN to be forwarded out of the border router and
then be forwarded by the normal BGP system.)

(It is also possible for the CN to perform the ITR function and
encapsulate its own outgoing packets, but that will make a mess
if it is behind a NAT.)

It is also possible for the RN to perform its own ETR functions.
In that case, it needs a second physical, local, IP address in
order that it can behave like its own ETR.  In mobile-IP that IP
address would be called a "care-of" address, which was reachable
via an ordinary BGP-advertised prefix.  In some ways, this would
resemble mobile-IP, because the RN itself is  taking part in
tunnelling.  However, for LISP or Ivip-basic, there is no 2-way
tunnel, and the edge network needs to be able to get the packets
sent by the RN out through the border router, for each RN to be
able to send packets back to the CN.  To the extent that this
resembles mobile-IP, the ITRs would be like the home-agent,
except that there are thousands of them, all potentially sending
packets to the RN, as if it was an ETR.  But the resemblance
with Mobile IP is slight, since the RN needs support from the
edge network to get its outgoing packets forwarded, which means
the edge network needs to know about and approve of its
LISP/Ivip-mapped IP address.

That is why I called it a Receiving Node - because LISP (as I
understand it) or Ivip-basic is a strictly one-way system.
Right-to-left in the above diagram.

It is up to the edge network and the normal BGP network to
support the carriage of packets from the RNs to the CNs.  If one
of the CNs also had a LISP/Ivip-mapped address, this would
involve ITRs and ETRs in the reverse direction,   But these
would generally be different ITRs, close to or within the edge
network depicted at the left of the diagram, and would certainly
be different ETRs than those depicted above, assuming the RNs
and the CNs were in different edge networks.

The diagram above does not depict packet flows left-to-right,
because they flow by ordinary BGP methods.

Now I will convert Diag. 3 to depict multiple Mobile
Nodes, using an Ivip-mobile extension: the ETRs are now TTRs
with a 2-way tunnel to the MN.

Diag. 5

                             /---CN1
                            /
 MN1===(TTR1)~~(TR)~~~~~(ITR1)---CN2
      =          ~
 MN2==            ~
                   (ITR2)--------CN3
                   ~
 MN3==(TTR2)~~~~~~~

      (TTR3)           (ITR3)
       ....             ....
      (TTRn)           (ITRn)

----  Raw packets flowing right-to-left.

~~~~  1-way tunnelled (IP-in-IP) packets as
      described in the previous diagram.

====  2-way tunnelled packets.

The TTR (ETR) functions could be located in transit routers,
border routers or internal routers.  With Ivip-basic, the ETR
function can't be in a transit router - it must be inside or at
the border router of an edge network.

A TTR function in a transit router can be tunnelled to by any
MN, no matter where it is, including behind a NAT.  Ideally,
each MN would pick a TTR nearby, perhaps in its own edge
network.  In that case, the TTR somewhat resembles a MAG of
Proxy Mobile IPv6.  However, with this idea of Ivip-mobile, the
TTRs always communicate with their MNs via two-way tunnels.

The main idea is that the TTRs can be outside edge networks, but
the MN will be able to find one far from whatever edge
network(s) it is currently connecting to the Net with.  This
way, the MN can make two tunnels, via two separate radio links
of two separate edge networks, to two TTRs which may be in those
 edge networks, at their border routers or outside the borders,
but not far away.  Then, it has true multihomed mobility, and it
(or some other central monitoring system) can direct the ITR
system to send its packets to whichever of the TTRs works best
at that moment.

If there was a link from MN2 to TTR2, then MN2 would be
multihomed.  It would have two "care-of" addresses, one from
each of the edge networks it is connected to. (I assume two edge
networks, such as two wireless networks, but it could still have
two tunnels to two TTRs from one "care-of" address in one edge
network.)

The only three changes from Diag. 3 to Diag. 5 are:

1 - I haven't shown the ordinary ETRs used for Ivip-basic -
    but they still exist.  By the way, the Ivip database
    and its ITRs don't need to know, or care, whether they are
    tunnelling packets to an ordinary ETR or to a TTR.  This
    part of the diagram - the ITR side - hasn't changed in Diag
    5 because it *is* "Ivip-basic".

2 - The MRs establish 2-way tunnels with their chosen TTRs.

3 - Packets flowing left to right from the MNs to the CNs
    first flow in the 2-way tunnel to a TTR.  Then the TTR
    uses the ordinary BGP routing system to get them to the
    CN destination.

We could make TTR2 into an ETR2 and have a link from MN2 to
 ETR2.

Diag. 6

                             /---CN1
                            /
 MN1===(TTR1)~~(TR)~~~~~(ITR1)---CN2
      =          ~
     =            ~
  MN2~             ~
      ~            (ITR2)--------CN3
       ~           ~
 MN3--(ETR2)~~~~~~~

Then MN3's link to the Net would be an ordinary 1-way LISP/Ivip
arrangement, via ETR2.

MN2 would have an edge-network-supplied "care-of" address, from
which it would establish a 2-way tunnel to TTR-1.  If the ITRs
tunnelled packets with MN2's Ivip-mapped address to TTR-1, MN2's
connection to the Net would be Ivip-basic to TTR1 and then
Ivip-mobile to itself.  TTR1 would probably receive its outgoing
packets and forward them via ordinary BPG.  Alternatively, since
MN2 is in an edge network with an ETR (ETR2), and has chosen to
use this as an optional link to the Net, presumably this edge
network has also allowed packets sent from MN2's
LISP-Ivip-mapped address to be forwarded to the border router
and handled by the normal BGP system.  In that case, MN2's
outgoing packets might flow via that edge network's routers,
which are not shown in the diagram.

If the ITRs tunnelled packet's addressed to MN2's packets to
TTR-1, its connection to the Net would be ordinary Ivip-basic
via ETR2.

There are some similarities between the Ivip-mobile link, and
mobile-IP.  However, it might be best to think of Ivip-basic and
its extension Ivip-mobile being like:

1 - The MN establishes one or more 2-way tunnel-mode links
    to TTRs, each of which is somewhat like a home-agent.
    However, the MN can choose between a bunch of these
    TTRs.  Some may be in the edge network, or be its
    border routers.  Some may be in the core.  TTRs are
    ideally all over the world.  They could be run by
    multiple companies with paid-for, authenticated, access.
    These one or more systems of TTRs, like the ETRs, do not
    need to have any relationship with the LISP/Ivip system
    (the database and the ITRs it controls).

2 - The MN's portable address has nothing to do with the
    addresses or physical/topological addresses of the TTRs.

3 - All packets sent by any number of correspondent nodes
    to the MN's Ivip-mapped (portable = mobile) address are
    funnelled by BGP anycast into any of the thousands or
    hundreds of thousands of ITRs all over the Net.

    (ITRs may be inside CN's edge networks, at the border or
    in the core.  Also, the CN can perform the ITR function if
    it is not behind NAT.)

4 - A central database controls which ETR or TTR receives
    the tunnelled packets which were addressed to the CN's
    Ivip-mapped (portable = mobile) address.

5 - There is no need for any special software in the CN or
    any changes in their edge networks. (LISP requires ITRs
    in CN's edge networks.)

6 - Total path lengths will be optimal or close to optimal
    assuming there are well-placed ITRs and the MN chooses
    a nearby TTR.  So there's no need for triangle routing,
    route optimisation, establishing trust between the
    CN and the MN etc. as is needed to optimise the path
    length taken by packets with mobile-IPv6.

7 - The TTR or ETR functions don't need to be coordinated
    by the Ivip system itself.  The Ivip system is the ITRs
    and the database which controls their behavior.

Because the explosion of the BGP routing table size is
threatening to cause excessive costs for everyone (and more
revenues for router manufacturers) to the tune of billions of
dollars, someone like me on the RAM or RRG list who is trying to
avert this can easily invoke a global network of ITRs and a
central database to control them.

If anyone had suggested such a thing be built just for the
benefit of mobile-IP users, the proposal would have been ignored.

Because we are desperate, this global network of ITRs seems like
the best (probably the only) way of averting either massive
router replacement and bloat, or major malfunction in the
Internet.  (I assume that it is impossible to institute a change
in Internet protocols, and therefore all routers, host operating
systems and probably application software.)

Ivip is just like LISP (or at least the more straightforward
aspects of LISP 2.00+ which I understand), except the ITRs can
be in the core, to serve end-users of networks who don't yet
have their own ITRs. This makes Ivip incrementally deployable,
while I believe LISP is not.

A fully functioning LISP or Ivip system is like a magic mirror
system, somewhat like the banks of steerable solar mirrors:

  http://www.nrel.gov/data/pix/Jpegs/00036.jpg

except that each IP address can be mapped to a different ETR,
and the mapping can be changed rapidly without upsetting the BPG
system at all.

This enables ordinary hosts to have their packets sent to
whichever MAG or Home-Agent a mobile-IP host desires.

The principles of LISP or Ivip apply equally to IPv4 and IPv6,
although there would probably be some significant differences in
implementation.  Since no-one thinks BGP can be replaced or
vastly improved, something like LISP or Ivip is needed in the
next few years.

Either LISP or Ivip makes it so much more simple and efficient
to do mobile-IP.

If IPv6 ever becomes widely adopted, perhaps something like LISP
or Ivip needs to be implemented for IPv6 too.  This could happen
if RIRs start handing out PI address space to AS-end-users.

Alternatively, if RIRs stick to current policy and don't hand
out PI space, someone will need to create a LISP or Ivip system
before ordinary networks (other than researchers, 3G mobile
networks and the Chinese government) adopt IPv6 widely.

Either way, I think IPv6 will have something like LISP or Ivip.
 This involves some special routers and a central control
system, but no direct involvement with host software and no
extra burden on most of the DFZ routers.

I guess this would make SHIM6 largely redundant.

SHIM6 is clearly not the portability and multihoming system most
end-users want, so on its own, it has not been enough to make
people want to adopt IPv6 without PI address space.

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