Re: [RAM] Re: RADIR Problem Statement: timeframe, portability, mobility, FIB etc.

Hi Brian,

Thanks for your response.

("End-user" in the following means end-users who need multihoming,
traffic engineering and what I try to describe, briefly, as
"portability" of the address range their network uses.)

You wrote:

>> I am sure that there is no prospect whatsoever of end-user's genuine
>> needs for multihoming - or for ease of using another ISP - being met
>> by some other mechanism than portability of their own address space.
> 
> "Portability" is a word I associate with cell-phone numbers. If you're
> referring exclusively to IPv4, and to the class of mechanism described
> in RFC 4116, then yes. But your argument does not apply a priori
> to a scenario where address space and prefixes are plentiful. That is
> why IPv6 was designed from the start on the assumption that sites
> would have multiple simultaneous prefixes and hosts would have multiple
> simultaneous addresses.

I don't think the end-user's need for "portable" address space is
related to the scarcity or otherwise of address space.

The end-user wants and needs to run their network without sudden
changes imposed by outside circumstances, such as the failure of a
multihoming link, or the business or technical failure of an ISP.
They also want and arguably need to be able to choose another ISP
for reasons of cost, performance etc. without having to do anything
disruptive or expensive to their network.

I think it is a good use of IPv6's vast address space to have
arrangements by which each host can have multiple IP addresses at
the same time.  Then SHIM6 or Six/One can use these to provide
multihoming.  SHIM6 does it without involving routers, but I think
it involves longer packets, with the extension header.  At least
this length is not added en-route and there are no problems with
Path MTU Discovery.  Six/One does it by involving routers, and I
think, without any extra headers - thanks to creative use of IPv6's
huge number of address bits.  However, I am not sure that Six/One's
rewriting destination addresses won't cause trouble for PMTUD.

Although there are better facilities in IPv6 for automated control
of router and host addresses, this doesn't solve the problem of
mobility - which ideally involves the host having one (or a stable
set of) address (or the mobile network one stable set of addresses)
no matter which provider network they connect to in a dynamic fashion.

For the major goal of multihoming, as far as I know, the only way
IPv6's "multiple addresses at once" approach can be used is SHIM6.

A decade after the guts of IPv6 was defined, SHIM6 is still not
finished.  This makes me think it is a difficult protocol to devise,
given its goals and constraints.

Even if SHIM6 was here today and universally implemented in all IPv6
stacks, it would not provide multihoming the way most end-user
networks want it.

My understanding of the needs of end-user network multihoming
requirements is that there must be a centralised, robust control
system.  Having to simultaneously control the multihoming behaviour
of hundreds or thousands of different hosts is not practical.

So the ten year long attempt at making IPv6 provide multihoming the
way most end-user networks want and need has not worked and will not
work.

If it had, or if anyone expected it to work sometime soon, then
there probably wouldn't have been the pressure to have IPv6 PI space
for end-users.  Likewise, if SHIM6 was expected to provide
multihoming which was acceptable to most end-users, I doubt whether
ARIN, AfriNIC and RIPE would have reversed long-standing policies
and decided to provide PI /48s to end-users.

The terms "portability" or "portable address space" are the
shortest, most accurate, terms for what I think end-users
(multihoming etc. end-users) need.

It is a delicate enough business getting all the software working on
one host, integrated with the external environment of nameservers
and all the other hosts which communicate with it.  It is also a
delicate business getting a whole network running, with all sorts of
different hosts, including some which don't have ongoing updates to
their operating systems and those which run applications which are
not completely up-to-date with recent RFCs.

There is no way an end-user with such a network can be sure their
network is going to keep running reliably if every host and router
needs to switch over to another address range.  IPv6 is intended to
facilitate this, but even when SHIM6 is finished and widely
implemented (2012?) it won't fulfil network multihoming needs
because this is a host-based, approach.

This seems to lead to portability as the only mechanism by which
end-users can get what they need for multihoming.  Portability is
also the only practical way of allowing painless switching to
another ISP.

Portability, if it can be done fast enough, is clearly the best
approach to mobility too - from the end-user's point of view.

> ...
>> It would be marvellous if mathematicians found more than 4 billion
>> combinations of 32 bits . . . but since we all agree there is no
>> possibility of this occurring, there is no point in an IPv4 addressing
>> problem statement being written as if it was a possibility.
> 
> Yes, but that isn't the problem statement being written.

My point was that no-one mentions more than 4 billion IPv4 addresses
because everyone agrees it is not a possibility.

Thomas Narten and perhaps you seem to think that it is possible for
multihoming and free choice of ISP to be achieved without what I
call "portability".  I believe this is not a possibility.

My guess is that you hold on to the idea of it being possible
because if it were possible, you would be able to retain the
traditional and current Internet architecture without causing
unsustainable growth in the global BGP routing table.

I think you need to show why it is a possibility.  It doesn't matter
how convenient it would be for the rest of the Internet if it were
possible.  What counts is whether it is what end-users want and need
in order to run their networks reliably and without excessive costs
or other complications.

I think you need to show why end-users could find your
yet-to-be-developed solutions - which involve changing the addresses
of their networks - robust, fully applicable to their actual
networks and of sufficiently low cost that they would be about as
happy with this as with what they currently want: "portability" -
meaning their networks keep the same address space.

> ...
>>> (And no, I'm not about to argue that getting automatic/painless
>>> renumbering is about to happen. But let any proposed solution in
>>> that direction be evaluated  on its merits please!).
>>
>> I am evaluating "automatic/painless renumbering" it on its merits -
>> its merits amount to zero.
> 
> That's just polemic.

Yes, but at least it was brief!

What are its merits?

"Automatic/painless renumbering" (user networks adopting new
addresses) would have enormous merits for the Internet's routing
system because no further change is needed to the current routing
architecture.

But that doesn't matter unless you can show why this would be as
good as true portability for the people who need to run their
networks 24 hours a day without disruption or further complications.

What is the time-frame within which the techniques you hope for will
be developed and fully deployed?

If the discussion is about IPv4, then you can't rely on host changes
- because there is too much old stuff out there which can't and
won't be upgraded.  With IPv6, because it is so little used at
present, you can probably require host changes, but I think you need
to show how and why everyone would make these changes in the
timeframe you are proposing.

All such host changes need to support full backwards compatibility
with non-upgraded hosts for as long as any non-upgraded hosts remain
in use, perhaps until some far-off date where you nominate that
those hosts will no longer be able to communicate fully.

>> So let's not pretend that perhaps, by some new technique no-one has
>> stumbled upon in all these years, there might be a technical
>> approach which would make network operators happy to have their
>> entire network suddenly renumbered the moment one multihoming link
>> goes down,
> 
> I'm not aware that anyone has ever suggested such a thing.

SHIM6, when it is finished, should enable multihoming without this
sudden change of addresses, because each host will already have a
set of addresses from the PA space of each of the two or more ISPs
through which the end-user network is multihomed.  But this is IPv6
only, requires new host software in every host in the multihomed
network and in all correspondent hosts.  It doesn't exist yet and it
is not a router-centric approach, which I understand is what most
end-user networks want and need, rather than having to fuss over
every host.

Apart from this host-based, IPv6-specific, future possibility, as
long as you want end-user networks not to have "portable" address
space, then I think you are implying that when one link goes down,
the network must switch to using the address space which is
available on another link.

LISP/eFIT-APT/Ivip are intended to provide address space which is
genuinely portable between any ISP with an ETR.  Ivip is intended to
do this so fast that it will support mobility, with generally
optimal path lengths from all correspondent hosts, without upgrades
to those correspondent hosts, and for both IPv4 and IPv6.

All these schemes have significant problems to do with tunneling
overhead, breaking Path MTU Discovery etc.  But unlike SHIM6 they
give the end-user what they want and need.  (I think Six/One can do
multihoming with passive, not specifically controlled, hosts running
 suitable software - with the control being exercised at the
network's CE router.  So this may well provide the network-centric
control of multihoming which end-user's need.  Six/One's techniques
can't be applied to IPv4.)

With the possible exception of using Six/One for IPv6 only
multihoming, I don't think you can give the end-user what they want
and need as long as you can't give them "portable" address space.

>> or that could provably make some automated renumbering
>> system work flawlessly on a huge variety of networks in existence
>> today, for which there is no clear enough definition to even start
>> designing such an automated system.
> 
> There was certainly some thought about that in the early days of
> IPv6 design, but it's clearly impossible, which is why RFC 4192
> was written.

Sections 3 and 4 consider some fundamental problems in implementing
this, such as with dedicated devices (VoIP phones) which are not
amenable to being upgraded to adopt the new addresses.  There are
also problems with securely automating DDNS and reverse mapping.

Six/One would need to be implemented in all a network's devices,
including phones and light switches, for it to be successful.

> ...
>> The reason it is not being pushed very heavily is because the only
>> people who want it are not the end-users, but those who want to keep
>> end-users using PA space for the convenience of not having to design
>> and run the Internet in a way which genuinely supports end-user needs.
> 
> This also verges on the polemic. To be clear, we've spent >10 years
> with the certain knowledge that the only way to avoid a BGP4 meltdown
> is to aggregate prefixes, and the only way to aggregate prefixes is to
> us PA space whenever possible (and I mean that strictly, i.e. not
> merely whenever convenient or preferred).

But this "certain knowledge" is no longer true.

LISP/eFIT-APT/Ivip all provide portable address - applicable for
most of the purposes PI space is currently used for - without
directly involving or burdening the BGP routing system.  (LISP etc.
mapped space can't be used for running ITRs, ETRs or any server
which is part of the LISP/eFIT-APT/Ivip infrastructure.)

They are all a kludge, with various degrees of ugliness and various
amounts of new benefits, particularly in terms of the speed by which
end users can control the behaviour of the global network of ITRs.

If you and others had been successful in meeting the needs of
end-users (who need multihoming, TE and "portability" = ease of
switching to another ISP) by the use of PA space, then there
wouldn't be unsustainable growth in the global BGP routing table.

You haven't been successful.

The task was - and remains - impossible.

End-users with current network technology can only run their
networks reliably with stable addresses - and you can't provide that
with PI space. (Except that in the future SHIM6 or Six/One will be
able to provide multihoming for IPv6 within limits such as those
described above.)

That is why we now have a crisis in routing and addressing for which
the only potentially practical solution seems to be a kludge like
LISP, eFIT-APT or Ivip.

If RADIR wants to position its Problem Statement into the indefinite
future, to provide a new architecture to which everyone will happily
migrate within some time-frame - say 2020 or 2025 - with new host
and router requirements which support robust, easy, renumbering of
networks, then that would be great.   That would be worth working
for, rather than all this tunneling stuff and being stuck forever in
the constraints of IPv4.  In the meantime, I think there needs to be
another Problem Statement and potential solutions to get us through
to 2020 or 2025.

> Multi6 took that as a basic assumption and Shim6 (and I suppose Six/One)
> takes that as a basic assumption. This wasn't an assumption adopted for
> convenience; it was an assumption adopted to avoid meltdown. People thought
> that would be even less convenient.

The idea of this global ITR network and tunneling overhead is pretty
 horrible, I think.  The thought of the the BGP system progressively
failing due to stability, RIB or FIB limits being breached by the
number and length of advertised prefixes is much worse.

I think I fully understand the motivation for this assumption.
Unfortunately, by staying within the constraints of this assumption,
it has not been possible to meet the needs of end-users with
substantial multihomed networks (or those who want freedom of choice
between ISPs).  Nothing has changed.  Apart from SHIM6 or Six/One
there is no reason to think anything will change in the future.  It
was a noble effort.  But it didn't work and I think it is best to
recognise that it won't work in the future either - not through lack
of effort, but because the task is impossible.

> That's also why it would be pretty short sighted to hand out more than a
> few tens of thousands PI prefixes, of course, unless we have a viable
> solution in the LISP/iVIP/eFIT class ready to deploy. 

Thanks for moving Ivip up the pecking order!

> If this current
> effort leads to such a solution, net convenience will increase. But the
> problem statement cannot assume that such a solution can be found.

This makes me think that you see the RADIR Problem Statement as
applying to a longer time-frame.

I think there are two timeframes.  Something like:

Short timeframe:

  Start                   2010
  Wide adoption           2015

  Last until at least     2025

  Apply to IPv4 without requiring host changes?   Yes

  Apply similar principles to IPv6 maybe with
  host changes?                                   Yes

  Must solve:       Million or more MH end-user networks
                    without further significant growth
                    in number or churn of BGP advertised
                    prefixes.

  Should solve or   Portability so end-user networks can
  at least not      freely choose ISP without any impact
  prevent solution  on their network.
  to:
                    Mobility with generally optimal path
                    lengths and fast (a few seconds, ideally)
                    user control of mapping to whichever
                    router is best for the mobile-node.

                    Increased utilisation of IPv4 address
                    space.

                    Migration to IPv6 or whatever new
                    architecture is optimal in the future.

Long timeframe:

  Start                   2020
  Wide adoption           2025

  Last until at least     2035

  Apply to IPv4 without requiring host changes?   No - may not
                                                  support IPv4 at
                                                  all, except by
                                                  some tunneling and
                                                  software hack for
                                                  IPv4 applications.

  Apply similar principles to IPv6 maybe with
  host changes?                                   Everything is up
                                                  for grabs, so IPv6
                                                  might be extended
                                                  or replaced.

  Must solve:       Million or more MH end-user networks
                    without further significant growth
                    in number or churn of BGP advertised
                    prefixes.

  Ideally solve:    Portability so end-user networks can
                    freely choose ISP without any impact
                    on their network.

                    Mobility for billions of devices -
                    probably each with the functional
                    equivalent of an IPv6 /64 with generally
                    optimal path lengths and fast (a few seconds,
                    ideally) user control of mapping to whichever
                    router is best for the mobile-node.

                    Get rid of kludgey LISP/eFIT-APT/Ivip
                    tunnels and ITR stuff.

>>>>  - Do folk agree with the problem statement as written, or are we
>>>>    missing something fairly fundamental?
>>> Yes. I think it's correct to keep it down to the bare bones.
> 
> I still think that. Short problem statements get read. Long
> ones don't.

If additions to the Internet architecture are designed by people who
won't read more than a few pages, then I think the outcome is likely
to be a mess.

The current draft's Section 6, which is what really matters,
contains 90 words, not counting the final paragraph which is a
qualification about what the section doesn't fully consider.

The text I proposed in:

  http://www1.ietf.org/mail-archive/web/ram/current/msg01773.html

contains 515 words, not counting the stuff in brackets.  That is not
exactly long - about 1.6 pages

My suggested text is for a short timeframe.

I think it would be helpful if the RADIR statement specified the
timeframe.  I think it should be clear to the reader whether the
intended solution is meant to support existing IPv4 hosts and
networks, or whether it is meant to provide a new architecture in
the longer term future to which all those users would ultimately
migrate.

I am proceeding on the basis that some people will devote the time
to understanding the problem in all its facets - including how some
solutions might support further benefits (eg. mobility) while other
solutions make such benefits harder to achieve.

Perhaps the solution properties should also include that each new
architectural element should be, to the greatest extent possible, a
building block which can be used with other building blocks, rather
than a monolithic system which contains fixed ways of dealing with
particular problems.

>> and I responded to your critique:
>>
>>   http://www1.ietf.org/mail-archive/web/ram/current/msg01779.html
>>
>> but I haven't seen your response to this.
> 
> You won't. I will be mostly silent for the next month while
> moving jobs and land masses.

OK - that is a huge move.  Good luck with it.

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

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