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

From: [email-masked] (Noel Chiappa)
Date: Fri, 22 Jun 2007 09:41:52 -0400 (EDT)

> From: Brian E Carpenter <[email-masked]>

    >> 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.

    > I suggest we don't have that conversation. I could write a long rant in
    > response - but it seems much more constructive to talk about routing
    > and addressing here

Indeed...

    > shim6 is an orthogonal discussion, and I believe we should just let the
    > WG finish its job.

I basically agree; but he does have a point, that many (most?) of the users
are not happy with the broad direction of the SHIM6 solution... which is a
problem for all of us, because the technical reasons why we went that way are
significant.

A architectural-level discussion of why people are unhappy with SHIM6, and
how that relates to those inescapable technical drivers, might not be out of
place here...

	Noel

_______________________________________________
RAM mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ram

---

From: Robin Whittle <[email-masked]>
Date: Sat, 23 Jun 2007 22:04:44 +1000

I wasn't suggesting any change to SHIM6's development.  What I

>>> want to adopt IPv6 without PI address space.

seems to be factual.

Noel wrote:

> A architectural-level discussion of why people are unhappy
> with SHIM6, and how that relates to those inescapable
> technical drivers, might not be out of place here...

I agree.

I think a global system for LISP, Ivip or similar will be built.
 I think this system will provide good portability and hopefully
TE for ordinary hosts - IPv4 or IPv6 - without additions to the
protocol stack or changes to operating systems.  I think this
has to happen soon for IPv4, because the BGP system can't be
expected to keep up with the growth in the number of advertised
prefixes.  We have to find a way to provide portability,
multihoming, TE and ideally great mobility for millions of
end-users, without altering hosts.

SHIM6 would still work with any such LISP or Ivip system for
IPv6 - so it is "orthogonal" to any such system.  However the
things which SHIM6 would provide would already be largely or
entirely available via the LISP/Ivip system.

I understand that SHIM6 is basically a host-oriented system,
operating on a single IP address at a time, with the control
necessarily being exercised within the multihomed host itself.
I may be wrong - it is complex and I haven't properly read
draft-ietf-shim6-proto.

LISP/Ivip, as I envisage it working, can handle individual IP
addresses or arbitrary sets of addresses with equal ease, and
does not require any new software or for the host(s) whose
addresses are being managed to be in any way aware of it.
Nonetheless, a single host could manage its own LISP/Ivip
mapping, or some centralised system could perform this task for
it, for instance to choose the best ETR in a multihoming setting
when one link fails.

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

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 25 Jun 2007 16:21:26 +0200

>>>> want to adopt IPv6 without PI address space.

No. If shim6 was shipping code in the popular operating systems, we could
start the clock on that evaluation. Since it isn't, it's way too soon
to say anything.

>> technical drivers, might not be out of place here...

First of all, please identify those people. The ones who were
identified in last year's round of meetings with IAB members have been
heard from, and their main issue - lack of ISP control over multihoming
policy - has certainly been heard. As far as I understand the history
of these discussions, we're here to look for another solution that
has that property, which would certainly move the control point for
locator selection out from the host towards the border router
or beyond.

>  I think this system will provide good portability

I'm not sure exactly what you mean by portability.

> and hopefully
> TE for ordinary hosts - IPv4 or IPv6 - 

Hosts aren't interested in TE. That is an enterprise
network operator, or ISP interest.

> without additions to the
> protocol stack or changes to operating systems. 

You should know that one of the reasons we took a host based
approach in developing shim6 was because we saw no sign of
a proposal to solve the problem in the routing system. So, now
we have a near-ready host based solution. Why can't we just
let it become ready and see if it works? Why let shim6 be a
distraction here?

> I think this

So what? The approaches are orthogonal, as you say.
> operating on a single IP address at a time,

It operates on a locator set.

> with the control

Final choice is made in the shim. There's no reason the
policy that determines the choice shouldn't be
distributed site-wide - that's why RFC 3484 is relevant.
And there is a draft on a shim6 proxy, but that raises
some standard stateful-proxy issues.

> addresses or arbitrary sets of addresses with equal ease, 

I think NERD only scales if it handles prefixes, not /128s
or /32s.

> and

Yes, that might be a way for users to take control back from ISPs,
although I think shim6 will prove an easier way to do that.

      Brian

---

From: Eliot Lear <[email-masked]>
Date: Mon, 25 Jun 2007 19:43:42 +0200

I agree.

---

From: Robin Whittle <[email-masked]>
Date: Tue, 26 Jun 2007 11:51:52 +1000

> start the clock on that evaluation. Since it isn't, it's way too soon

I think it is fair enough to say that if an AS-end-user or an
ISP has a prefix of IP addresses with a bunch of hosts on these
addresses (especially hosts belonging to another organisation)
and they want to multihome that prefix, then they would much
prefer to do the whole thing with a router and some robust,
global, system such as LISP, Ivip or whatever - rather than have
to configure a bunch of disparate host devices, operating
systems etc. to all respond to some centralised control system
so each SHIM6 system behaved as required.

There is the practical problem of either the ISP or the owner of
all the hosts (and there may be thousands of separate owners,
many of them not very technically adept) making sure they are
all configured correctly.  For instance after re-installing an
operating system, plugging in a new machine etc.  Testing the
SHIM6 system is properly controlled from the single point could
be tricky too.  This is all labour-intensive, full of
administrative hassles across organisational boundaries and
subject to technical error.

Then what if the central control point has to change?  All the
hundreds or thousands of hosts need to be reconfigured.

Customers who own the hosts don't want an ISP administrator
poking around their system, for security reasons.  So the ISP
has to give them explicit instructions on exactly how to
configure their machine - but there could be many operating
systems, different versions of the operating systems, many
different "appliance" devices and so many different ways an IPv6
host might need to be configured, from the users' point of view.
 This is roughly analogous to the ISP having to provide
bullet-proof instructions for people with limited technical
skills on how to configure several versions of Windows and Mac
operating systems to dial into their network.

>> Noel wrote:
>>
>> RW> A architectural-level discussion of why people are unhappy
>> RW> with SHIM6, and how that relates to those inescapable
>> RW> technical drivers, might not be out of place here...
>>
>> I agree.
> 

I agree that we are looking for such a solution.  The only ones
which seem to be available for IPv4, which make no demands such
as changing operating systems are LISP or some similar or
derivative system such as Ivip, which involves tunneling packets
and popping them out with their raw IP addresses in a local
environment where they are routed to their destination host.
The hosts at both ends of the communication are blissfully
unaware of how the packets have been handled in transit.  Each
host with an LISP/Ivip-mapped IP addresses only has that IP
address.

Since it seems that some form of LISP/Ivip/whatever is practical
and since no-one has a better solution to the problem of the BGP
routing table threatening to swamp the DFZ routers in the
uncomfortably near future, I think it is reasonable to believe
that something like LISP/Ivip will be built around the end of
the decade.  However I think we would need to make faster
progress than in the last 6 months to achieve this.

The quotes below are from me.

> I'm not sure exactly what you mean by portability.

A primary goal of Ivip - and I assume LISP - is to allow someone
who has an IP address, or a prefix of addresses, to use those
addresses for their host(s) which are either located at "any
ISP", or which are housed in their office, factory etc. and link
to the Net via a link through "any ISP".  "Any ISP" is an ISP
which has an ETR and local routing support for whichever
LISP/Ivip-mapped addresses the customer is using at the time.

The ITRs are a global system which tunnel the packets to
whichever IP address the owner of these hosts chooses - because
the owner of these hosts has some arrangement with the LISP/Ivip
system by which they control that part of the database which
controls how the ITRs tunnel incoming packets whose destination
address is one of their IP addresses.

I think different people in this discussion have different
models of administration of IP addresses, different goals etc.
for how LISP or whatever would be used.  A primary goal I have
is to enable a LISP/Ivip system to provide effectively portable
IP addresses or prefixes to millions or in principle a billion
or two end-users.

This portability between ISP's ETRs - between any ETR in any
edge network - is a prerequisite for multihoming.  LISP or Ivip
enables multihoming by having the customer site have two links
to two ISPs where the ETRs of both ISPs are ready to accept
encapsulated packets and to decapsulate them, and where the
local routing system is ready to forward the packets to the link
to the customer site.  (The ISP's network also needs to accept
outgoing packets and enable those which match BGP advertised
prefixes out to the Net, probably via an ITR so outgoing packets
to LISP/Ivip-mapped addresses don't depend on public-access ITRs
outside the ISP's edge network.)

Then by one means or another, the LISP/Ivip ITRs all over the
world tunnel the packets to one or the other ETR - whatever is
needed to keep the customer site connected when one link or one
ISP goes down.

> network operator, or ISP interest.

It is probably not much of a concern for an end-user with a
single IP address, but the end users of LISP/Ivip would include
a non AS-end-user with one or more LISP/Ivip-mapped addresses
and two or more links to ISPs.  That end-user may find there is
wildly varying incoming traffic for the various LISP/Ivip-mapped
addresses.  Say they want to keep both links from saturating,
they might start off with half of their mapped addresses getting
their packets through the ETR of ISP-A and the other half from
the ETR of ISP-B.  Then when one of their LISP/Ivip mapped
addresses has a very high rate of incoming traffic, they can
keep that on one ETR (say ISP-A's) and change the database to
map the others which used that ETR to use the other ETR of
ISP-B.  This leaves only the busy IP address's traffic on the
link from ISP-A.

With fine-grained, to individual IP address, control like this,
I think there is considerable scope for TE - at least in terms
of incoming load balancing across multiple links, ISPs, ETRs
etc. - simply by switching the database to cause the ITRs to
tunnel packets to a different ETR.  This is without any of the
TE specific constructs of "Weight" or "Priority" in:

  http://tools.ietf.org/html/rfc4271#section-9.1.2

I think these are very powerful constructs, but that they would
impose a huge burden on ITRs and cause the database to be more
complex.

I suspect that some or many people tend to think of LISP
generally dealing with whole prefixes.  I have always thought of
LISP and now Ivip dealing both with prefixes and with individual
IP addresses.

I believe we would have no crisis in routing or addressing - and
still have heaps of IPv4 space free - if the global routing
system could (and was always able to) easily point any IP
address to any edge network.  If the global routing system could
change this reliably and nearly instantly, without any great
cost, that would make full Mobile-IP easy to achieve.  Then, IP
address space could always have been assigned in smaller chunks
and used very efficiently.

We definitely can't do this with the global routing system.  The
propagation of changes is too slow, to unreliable and too
costly.  The RIBs can't handle 3.75 billion separate routes (for
each IP address in the unicast space to 223.255.255.255) and the
FIBs aren't up to this either.

My aim with Ivip is to keep the BPG system approximately where
it is now, to have tens of thousands of ETRs (dumb, cheap and
not needing any coordination) in most ISPs and to have a
globally coordinated, robust, database and ITR system which can
map individual IP addresses - ultimately one or two billion of
them - so packets sent to these addresses are tunneled to any
ETR in the world.

There is a burden on the database, the communications system
(push and pull) and on the ITRs for every change in the mapping.
 So I don't suggest an end-user should be able to flip their
mapping every few minutes without incurring some kind of fee to
help pay for the burden they place on the system.  However, all
such changes are a lot less expensive, faster and vastly more
fine-grained (single IP addresses rather then 256) than is
possible with changing the advertisement of a BGP-prefix.

I see a successful LISP or Ivip system as absolutely necessary
to contain the growth in the global BGP routing table - and that
 it would grow to cover a large proportion of the address space,
using it extremely efficiently, and so enabling a much greater
utilisation of IPv4 address space than is currently the case.

Once this happens, LISP/Ivip-mapped addresses will be much more
portable and generally useful than IPv6 addresses, assuming the
current ban on PI IPv6 space for AS-end-users remains.  As long
as that restriction remains, and as long as there is no
LISP/Ivip system, I believe not many ordinary end-users will
take up IPv6.  (I think China will adopt it because the
government wants each citizen on an individual IP address, where
they can be made responsible for the communications - the
surveillance system is deeply frustrated by NAT.  Also, I expect
IPv6 to be adopted by 3G mobile operators, to support Mobile
Multimedia Subsystem.)

However, if something like LISP/Ivip was created for IPv6, then
lots of end-users, including those who have no ASN and don't
want to fuss with BGP etc. might start adopting IPv6.

I haven't thought much about Ivip for IPv6, but I think it would
be nuts to have ITR' FIB having to look at all 128 bits of
address to determine the IP address the packet needs to be
tunneled to.  Even looking at the most significant 64 bits is a
major cost, but that may be the best granularity to use: map
whole /64 prefixes.

> let it become ready and see if it works? Why let shim6 be a

I believe that SHIM6 won't work for people who want and/or need
portability and multihoming control without having to fuss with
the operating system configuration of all the affected hosts.

So I don't think that we should expect SHIM6 alone to solve the
problem of encouraging widespread adoption of IPv6 without PI
space for AS-end-users.  The only solution I can imagine working
is something like LISP or Ivip.  Widespread adoption of IPv6
with people doing portability and multihoming with their own PI
space being advertised in BGP will quickly bring the IPv6 BGP
system to the same router-swamping state we are facing with IPv4.

  - Robin

---

From: "william(at)elan.net" <[email-masked]>
Date: Mon, 25 Jun 2007 20:19:09 -0700 (PDT)

I also think that current SHIM6 will only get to be used in way
similar to NAT where vendor would provide company a router box
which like NAT router sits in between local network and internet
and can modify ip addresses. Such box would itself add SHIM6
layer data and just like current NAT boxes are also usually
DNS servers on local net, it would do similarly.

So in effect even if shim6 & v6 designers did not want it, the
results would be continuation of NAT in v6 world even when we do
have enough addresses. Its not really entirely bad because those
NAT boxes also typically work as firewalls for small companies.

What could be useful though is if core routers also understand such
shim6 or a like scheme and so can look at the packet header and
seeing multiple possible destination addresses route address using
best appropriate address based on its own BGP table, i.e. its non-ASN
routing where instead of ASN the end-poing indicates directly
multiple ip blocks that could be used for routing and each one
of those is then checked in router table to find ASN and then
router decides which ASN is best to route to further.

But host-host only multi-homing route that shim6 wants will likely not
lead to serious adaption although as an option its good to have.
However if we know the above it may well be better to go with slightly
different or modified shim6 design that does take into account use
in both host-host and endrouter multihoming models.

-- 
William Leibzon
Elan Networks
[email-masked]

---

From: Olivier Bonaventure <[email-masked]>
Date: Tue, 26 Jun 2007 09:17:04 +0200

William,
> NAT boxes also typically work as firewalls for small companies.

I agree that enterprise networks will probably want better control on 
the IPv6 addresses chosen by their shim6 hosts. However, providing this 
kind of control does not necessarily require the utilization of NAT. A 
good amount of control can be obtained by placing inside the enterprise 
network a "controller" that the shim6 hosts would contact when they need 
to open shim6 flows. The controller could for example order the source 
and destination IPv6 addresses available to the host to select the most 
appropriate pair for the traffic engineering objectives of the enterprise.

This approach was proposed several years ago, before the creation of the 
shim6 wg, and could be easily added to shim6, see e.g.
http://inl.info.ucl.ac.be/publications/naros-approach-ipv6-multihoming-traffic
or
http://inl.info.ucl.ac.be/publications/unleashing-traffic-engineering-ipv6-multihomed-sites

> router decides which ASN is best to route to further.

I don't think that core routers should have to interpret the shim6 
headers and change the addresses

Olivier

-- 
http://inl.info.ucl.ac.be , Universite catholique de Louvain, Belgium

---

From: Eliot Lear <[email-masked]>
Date: Tue, 26 Jun 2007 09:43:25 +0200

Robin,

I don't think that SHIM6 is the be-all / end -all solution, but...
> so each SHIM6 system behaved as required.

This is the whole point of prefix delegation.  The host announces 
non-ULA non-local scope addresses and away you go.  I do think there is 
a chicken & egg problem with SHIM6, and that's too bad, and that makes 
this whole argument academic.

Eliot

---

From: "william(at)elan.net" <[email-masked]>
Date: Tue, 26 Jun 2007 02:24:50 -0700 (PDT)

On Tue, 26 Jun 2007, Olivier Bonaventure wrote:

> I agree that enterprise networks will probably want better control on the 
> IPv6 addresses chosen by their shim6 hosts. However, providing this kind
> of  control does not necessarily require the utilization of NAT.

I should have said "NAT-like" as I do not mean NAT in the way we have it
today but rather I mean router device that does ip address translation
and which modifies source and/or destination ip address of the packets
that path though it (and in case of shim6 that would also mean adding
shim6 layer).

> A good amount of control can be obtained by placing inside the 
> enterprise network a "controller" that the shim6 hosts would contact 
> when they need to open shim6 flows. The controller could for example 
> order the source and destination IPv6  addresses available to the host 
> to select the most appropriate pair for the traffic engineering 
> objectives of the enterprise.

It could. But lets imagine a choice between such "controller" device
which only works with shim6 layer hosts and a device which you just
plugin between your router and switch and which does not require
anything specific from hosts (other then support of ip6) and allows
to keep existing infrastructure as is but makes entire network
suddenly shim6-aware and multi-homed. What do you think IT manager
would choose?

And BTW, in case you wonder IT manager would not care at all if such
device properly fits in the "internet architecture" model, all he/she
wants is a device that will "just work"!

> headers and change the addresses

While core router vendors and large network operators are slightly
more aware of what internet architecture model should look like, in
the end such "feature" would not be difficult to add and somebody
will try it and then marketing will take it on them to point it one
of the reasons why you should buy such and such product (i.e. our
device can route better and makes your network more efficient, etc etc).
The question however is really more of should architecture be such as
to really consider this an "add on" and take advantage of it to create
a more functional (but optional) component that helps overall design
rather then just leave it to equipment vendors to figure how to do
on their own, likely in not entire compatible way.

-- 
William Leibzon
Elan Networks
[email-masked]

---

From: Jari Arkko <[email-masked]>
Date: Tue, 26 Jun 2007 11:27:24 +0300

Robin,

> so each SHIM6 system behaved as required.

The preferences depend largely on what you as the user
or network owner have an ability to change. What Shim6
gives you is a model where you as the host owner can use
multiple addresses even if your organization can not do
it for you (no PI, no central devices, etc). Or when you
want to be connected to multiple ISPs with different
interfaces on your laptop, and the ISPs do not
co-operate to give you a single address/prefix.
Advantages: no need to change the network side
Disadvantages: need to change the hosts.

LISP and other solutions on the other hand focus more
on the situation where the ISP or the organization is
in charge, and being able to provide a multihoming
service without any host requirements.
Advantages: no need to change the hosts.
Disadvantages: need to provide something new in
the network.

> A primary goal I have

I'm interested in this, but it is an ambitious goal, much
more ambitious than merely getting site-based multihoming
to work properly and without creating too large global
routing tables. Its not clear to me that we want to have
a future network where there's a central, coordinated
database of what the current locator of each host is. One
issue with this is that the dynamics requirements are so
demanding in the extreme cases (voip handovers) that
it seems end-to-end signaling seems preferrable.

> space for AS-end-users. 

It is very clear that Shim6 is not a solution that solves the problems
we discuss on this list. It solves some problems, but I believe there
is consensus that we need other solutions. So lets cut this argument
short...

Jari

---

From: Olivier Bonaventure <[email-masked]>
Date: Tue, 26 Jun 2007 11:59:31 +0200

William,

> suddenly shim6-aware and multi-homed. What do you think IT manager

This "controller" would of course be a piece of software that could be 
installed on any device already present in the network. We do no 
necessarily need a new device in the network.

Then, the key question becomes when shim6 will be implemented on popular 
operating systems. We have a Linux implementation that already supports 
a large fraction of the shim6 drafts, 
http://inl.info.ucl.ac.be/software/linshim6
but I don't know the status of other OSes

As Brian noted a few days ago, we will only be able to judge when shim6 
gets implemented on popular OSes.

Olivier

---

From: Christian Vogt <[email-masked]>
Date: Wed, 27 Jun 2007 00:41:26 +0300

> So what? The approaches are orthogonal, as you say.

Shim6 and LISP/Ivip can be combined to allow a multi-interfaced Shim6
host to spread a connection across different access networks, while each
access network may use LISP/Ivip internally for multi-homing with
multiple providers.

Other than this, I don't see an orthogonality between Shim6 and LISP/Ivip.

> although I think shim6 will prove an easier way to do that.

Brian, I'm not sure what you mean by "taking control back from ISPs".
But in any case, once a multi-homed access network to which a host
attaches performs address mapping (through LISP or Ivip), the host can
no longer choose between different providers (or ETRs) of that access
network.  All the host sees is provider-independent addresses.

- Christian

---

From: Christian Vogt <[email-masked]>
Date: Wed, 27 Jun 2007 01:01:25 +0300

Robin,

I wonder why you are so concerned about configuring Shim6.  Assuming two
communicating hosts both support it, Shim6 should actually work without
much configuration -- or even a centralized control system.

However, the more intractable problem with Shim6 that I would think of
is the requirement for support on both sides of a connection.  This may
become a chicken-and-egg problem, although it might, e.g., help to add
Shim6 support to the requirements in the IPv6 Host Requirements RFC.

Ciao,
- Christian

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 27 Jun 2007 11:32:51 +0200

> http://inl.info.ucl.ac.be/publications/unleashing-traffic-engineering-ipv6-multihomed-sites 

Exactly. Shim6 will self-deploy without any of that stuff, or any kind of
central control, and such things could be added on larger sites if wanted.
However, it isn't clear that there will be a gap between small (SOHO
and SMB) sites where raw shim6 will self-deploy and need no management,
and large sites that will end up using a PI prefix for practical and economic
reasons. If there is such a gap, it will need something like a shim6 proxy
and/or naros I guess. But raw shim6 would take care of a very large class
of small sites.

> headers and change the addresses

I agree. Shim6 was designed on a couple of basic assumptions, after all:

1. It must have no negative impact on routing table size, i.e. it
works in a world where all prefixes are PA and is of no value or
interest to large networks that have a PI prefix.

2. If a site has N ISPs, it will have N PA prefixes (where N=2 in
the vast majority of cases).

There's a good chance that shim6 for SOHOs and SMBs, plus PI
with LISP for larger enterprises, will cover everything and keep the
IPv6 DFZ at a very tolerable size.

      Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 27 Jun 2007 11:39:36 +0200

Robin,

> hundreds or thousands of hosts need to be reconfigured.

That is a strong argument for making the central mechanism
self-deploying (whether it's done via DHCP, a routing
protocol, or however). Since we already have to spread
RFC 3484 policy from a central point in large enterprises,
spreading shim6 policy is really not a new problem.

But as I noted just now, I hope this can be avoided. Shim6
was really designed for the ten million small multihomed
sites, not for the ten thousand big ones.

...
> problem of encouraging widespread adoption of IPv6 without PI

We agree on that. I've always expected the big users to
have PI prefixes by one method or another.

     Brian

---

From: Christian Vogt <[email-masked]>
Date: Wed, 27 Jun 2007 13:16:31 +0300

> Maybe that is a bit strong. But it's clear that if a site has several
> providers, and a single PI prefix, there are some tricky issues in the
> site controlling which ISP carries which traffic. 

Yes, but that's exactly the kind of freedom that access network (or
site) operators want because it facilitates engineering of traffic
coming in and getting out the access network.

[...]

> Yes indeed - LISP/Ivip are natural partners with PI; shim6 is a
> natural partner with PA. But they don't damage each other, as
> far as I can see.

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.
 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.

Best,
- Christian

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 27 Jun 2007 14:04:49 +0200

...

Maybe that is a bit strong. But it's clear that if a site has several
providers, and a single PI prefix, there are some tricky issues in the
site controlling which ISP carries which traffic. If the site has
a PA prefix per ISP, which is the natural state in IPv6, the site
can use address selection policy to control which ISP gets which
packet.

     Brian

---

From: Robin Whittle <[email-masked]>
Date: Wed, 27 Jun 2007 22:27:02 +1000

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

> 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.

> 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

---

From: Gert Doering <[email-masked]>
Date: Sat, 30 Jun 2007 12:14:43 +0200

Hi,

On Tue, Jun 26, 2007 at 11:51:52AM +1000, Robin Whittle wrote:
> current ban on PI IPv6 space for AS-end-users remains.  

As far as I know, there is no such "ban" - ARIN has been giving out IPv6 PI 
blocks since october last year...

(The other regions are working on it, and it's likely that IPv6 PI for
"AS-end-users" will show up there as well)

Gert Doering
        -- RIPE APWG chair
-- 
Total number of prefixes smaller than registry allocations:  113403

SpaceNet AG                        Vorstand: Sebastian v. Bomhard
Joseph-Dollinger-Bogen 14          Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen                   HRB: 136055 (AG Muenchen)
Tel: +49 (89) 32356-444            USt-IdNr.: DE813185279