[ppml] IPv4 swamp, mh end-users & IP architectural solutions: LISP/APT/Ivip
rw at firstpr.com.au
Mon Aug 20 05:20:40 EDT 2007
Thanks for your detailed response.
I interpret the term "IPv4 swamp" more broadly than you do, I think.
Most of your message concerns a proposal for IPv6 multihoming
involving PI space which is not advertised. I hadn't heard of this
proposal before. If you are really confident it would be widely
accepted by end-users - and I agree with you on this:
> But I'd offer the opinion, that multi-homed non-ISPs are likely to
> outnumber multi-homed ISPs, by one or more orders of magnitude.
- then I suggest you write it up as in Internet draft and/or present
it to the RAM mailing list, where solutions to this multihoming
problem are badly wanted.
My initial critique of your proposal, which I only partially
understand, is that firstly it involves NAT - which will probably
make most people want to run the other way - and that secondly it
involves fussy DNS arrangements. As far as I can see, the proposal
doesn't provide for continuity of sessions on existing IP addresses
- which is part of what most people require in "multihoming". Also,
the requirement for special arrangements for some protocols, being
handled in the hosts, sounds all too messy.
If there were any serious prospect of end-users being happy to
multihome IPv6 by SHIM6 or any other system other than using BGP and
PI space as they do now with IPv4, then I can't imagine that ARIN,
AfriNIC or RIPE would have reversed the long-standing policy of
denying end-user networks PI space.
There are still people, with decades of experience, who hold out
hope that IPv6 multihoming can be achieved with SHIM6 of by some
other method which does not involve PI space. However I think it is
easy to prove this is unrealistic
Having got a bunch of hosts configured and running, with a network
set up with some addresses, the operator simply requires that the
network keep running without any fuss, when the link from one ISP
goes down and they decide to use a link to another ISP.
The very last thing the end-user network can tolerate is a sudden
change in addresses or the requirement that a bunch of hosts figure
something out, or that they be told to do things differently. Hosts
are extremely diverse, from massive servers, to old, obsolete
machines, to IPv6 lightswitches etc. - many of which have no
prospects for keeping their operating systems or application
programs up to date.
For end-users who, in their own judgement, need multihoming, the
requirement is simple: The solution must not involve fancy software
in correspondent hosts, special arrangements for certain protocols,
any changes at all for the hosts on the network etc. The network
needs to have a publicly reachable block of addresses and when one
link goes down the packets need to flow on the other link ASAP.
In short, they need their own PI space they can use with any ISP and
they need a way of quickly switching the "routing system" (including
any additional architectural elements such as are being discussed on
the RAM list) so the packets go via a different ISP.
I don't think it does any good trying to pretend that end-users will
be happy with anything less, or anything more complex and therefore
The two ways of achieving that we know about are the conventional PI
and BGP approach - which places unsustainable burdens on every DFZ
router - or some scheme such as LISP, eFIT-APT or Ivip etc. I think
these are all ugly, problematic, kludges - but at least they don't
burden all DFZ routers.
More information about the ARIN-PPML