Re: [RRG] Consensus? 4 points so we can make progress

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

I am replying to Brian and Ran, but also mention Lixia's request to
end discussion of whether we only need to develop an IPv6 solution.

Brian E Carpenter wrote:

>> This will no-doubt displease some folks, but here is a set of points
>> which I think we need to agree upon soon in order to make sufficient
>> progress to achieve a useful recommendation in March 2009.
>>
>> Without such agreement, or something similar, I think we would waste
>> time arguing about:
>>
>>    a - A solution which involves significant host changes - and
>>        therefore which could never be implemented in a reasonable
>>        time-frame.
> 
> We'd certainly waste time by arguing about it as an abstract principle.
> But there is evidence that new TCP/IP stacks can be rolled out in the
> major operating systems on a timescale of a few years, so I would be
> prepared to consider a solution that includes incremental roll-out
> to hosts. I think we agree that we're unlikely to invent a solution
> that solely depends on that, however. In any case I suggest it's
> already off the research table, since shim6 is already in the IETF
> process, so not worth discussing here.

I understand that over a period of years, there is scope for new
features in the major operating systems and that these can often be
integrated into running systems via the regular update mechanism.

However I feel certain that this falls far short of the complete,
rapid, painless, upgrade capability which would be required for the
great majority of end-user networks to be able to adopt a solution
which required host changes.

This is particularly the case with the various "embedded" devices,
and the old servers, old routers, which are surely a part of most
end-user networks.  There is more to networks than modern desktop
PCs, servers and routers.

There are printers, various special purpose devices including
hardware to do firewall functions, managed switches, NAS boxes, WiFi
devices, VoIP boxes, UPSes.  These are generally not amenable to OS
upgrades and there is no way of automating their reconfiguration if
their address needs to change.  While not all of these might need to
be accessible via the Internet, they may well be on addresses which
depend upon the public address range the network uses.

I think any solution which does not provide portable space for
anyone who wants/needs it will not be adopted widely enough to solve
the routing scaling problem.

It doesn't matter if we think portability is not a need - if a
significant number of end-users feel they want or need it, they will
fail to adopt solutions which do not provide it.

I guess we can't succeed in solving the routing scaling problem if
more than about 10% or so of end-users (including the largest
corporations and universities) do not find our solution attractive.

The proportion of end-user networks (from the largest corporations
to home-office users) who can't or don't want to fully upgrade their
OSes in all their devices and/or who need/want portability is vastly
more than 10%.


>>    b - Router based translation schemes which can't be practical for
>>        IPv4.  http://psg.com/lists/rrg/2008/msg01314.html
> 
> I think it's pretty clearly established that, due to the shortage
> of IPv4 prefixes, either map-and-encap or pure NAT is *required*
> for IPv4, iff we believe that the remaining scaling of IPv4 usage
> will actually exceed BGP4 scaling capability.

Does this mean you agree with my argument that router-based
translation (such as Six/One Router) cannot be a solution in IPv4
because it could only work with duplicate address ranges?

  http://psg.com/lists/rrg/2008/msg01314.html

The last part of your statement is preceded by an IF, as if we don;t
know whether we have consensus on it:

> iff we believe that the remaining scaling of IPv4 usage
> will actually exceed BGP4 scaling capability.

I believe this statement is true, since I think there is no chance
in the foreseeable future of mass migration to IPv6, and because I
am sure that there will be more and more end-user networks in IPv4,
as address space is utilized more intensively - with more and more
DFZ routes.  I think this is worth stating as something we might
achieve consensus on.

   We expect the continued use of IPv4 will result in further growth
   in the DFZ routing table and/or insufficient provision of
   multihoming, TE and portability (or ease of choosing another
   ISP) to end-user networks which require it.  So we must provide a
   direct solution to the IPv4 routing scalability problem.

However, Lixia asked to put a stop to the thread "We can't bet the
Internet on the imminent adoption of IPv6".  I wrote that thread
because of my impression that Tony, Ran and Iljitsch thought we
didn't necessarily need an IPv4 solution:

   http://psg.com/lists/rrg/2008/msg01326.html
   http://psg.com/lists/rrg/2008/msg01329.html
   http://psg.com/lists/rrg/2008/msg01344.html

Perhaps if the co-chairs declared we have consensus that we need an
IPv4 solution, that would do the trick.


> However, I would observe (even as a well-known NAT hater) that we
> have *already* broken the IPv4 transparency model by widespread use
> of NAT. So one can legitimately ask: does it really matter if we
> break IPv4 transparency even more by deploying much more NAT?

I think more use of NAT and perhaps double NAT is inevitable.

Whatever we think about the lost end-to-end transparency, I think
virtually all end-user networks would choose to stay with IPv4 NAT
rather than try to survive on IPv6 addresses with some ugly and/or
non-existent approaches to getting their hosts and applications
interworking with the IPv4 Internet.


> What I'm getting at is that it doesn't follow that we need the same
> solution for IPv4 as for IPv6. We could consider "doing it right"
> for IPv6 and struggling on with NAT for IPv4. (I can't believe I
> just wrote that ;-( )

I agree entirely.

I thought that the lack of urgency for IPv6 meant we could learn
something, as we inevitably will, from widespread map-encap
deployment in IPv4 before deciding what to do with IPv6.  However,
as you suggest, we could use the extra time to be more ambitious
with IPv6 - to design something much better than IPv4's (I assume)
pure map-encap solution.

Since the installed base of IPv6 would still probably be very low,
the more ambitious solution could include host changes - to the OS
and applications - without major problems.  Even in 2015, I think
IPv6 deployment will only be for specialised purposes, and will
remain a tiny fraction of a percent of IPv4 deployment.

It may be an elaborate enough alteration to warrant bumping the
version number up, while making it not too painfully different from
IPv6.


>>    c - The prospects for near-term (next 5 years or so) widespread
>>        adoption of IPv6 - because we haven't formed a clear
>>        consensus that we need to solve the IPv4 routing scaling
>>        problem directly, but think it could or should be solved by
>>        mass migration from IPv4 to IPv6.
> 
> I haven't used the word 'migration' for years in that context. The model
> is very clearly one of long-term *coexistence* of v4 and v6. So
> v6 deployment is definitely not an excuse for ignoring v4 scaling.

I agree.


>> Here is the rough list of points, all of which have been discussed
>> in greater detail in recent days:
>>
>> 1 - The scope of the RRG's work should focus on IP addresses and
>>     network based solutions - involving new router functions
>>     and/or new network elements.  The solution should not involve
>>     any changes to host stacks or applications, except perhaps
>>     to optimise performance which is degraded by the main solution.
> 
> I mainly agree with that. Some host based approaches (shim6 and sctp)
> are already in standards development. However, I think we should
> have ILNP on the radar screen.

Ran's Identifier Locator Network Protocol for IPv6 only:

   http://tools.ietf.org/html/draft-rja-ilnp-intro-00

I understand you favour no host changes for the IPv4 solution but
would contemplate them for the IPv6 solution.

SCTP is for both IPv4 and IPv6.  Does anyone have an idea of how
widely it is being used?  I guess it is still early days with
applications, since it will be a while before sufficient OSes
support it.


>>     Discussion of longer-term architectural solutions involving
>>     changing or underpinning existing host-level protocols -
>>     necessarily involving changes to host stacks and/or
>>     applications - should be directed to another forum.
>>
>> 2 - The solution must work for IPv4 and IPv6 and show promise
>>     for being adopted by the majority of end-user networks
>>     in the 3 years following deployment, such as in the 2012 to
>>     2015 time-frame.  While this adoption will be supported and
>>     encouraged by administrative and perhaps business arrangements,
>>     the primary reason for adoption will be the immediate benefits
>>     to the ISPs and end-user networks.
> 
> See above comment re different solutions for the two cases.

So perhaps you would favour the RRG adopting two parallel strands of
discussion:

  1 - For the more immediate, no host changes, IPv4 solution.

  2 - A more ambitious, longer-term, IPv6-only solution.

I think this would be a good approach, and that we should
concentrate on the IPv4 solution, whilst doing some useful
preliminary work on a reasonably compatible (with the IPv4 solution)
longer term solution for IPv6.

That sounds like a better idea than what I proposed above: excluding
longer-term discussion from the RRG.

Does IPv4 scalable routing solution deployment in 2012 to 2105 sound
about right?



>> (We don't have a good definition of "end-user networks", but I
>> suggest it should include all sizes - existing and new - including
>> single-host networks: from the largest universities and corporations
>> down to individuals on DSL lines and with cell-phones.)
>>
>> 3 - The solution must provide portable address space for
>>     end-user networks without impacting the scaling of the
>>     current BGP routing system.  (The map-encap schemes do this.)
> 
> I don't agree. The desire for "portable" prefixes is an artefact of
> IPv4 experience. Let me reformulate.
> 
>      The solution must allow the option of provider-independent
>      address space and the option of multiple provider-dependent
>      address spaces for end-user networks...
> 
> I don't think we should constrain the future in a way that IP does
> not do today.

I think we should constrain any solution for the foreseeable future
(the IPv4 solution) to require provision of portable space to all
end-user networks which want it, because:

1 - Many or most networks want/need it - and we must get the great
    majority of new end-user networks, and probably the majority
    of existing networks, to to adopt our solution in a few years in
    order to solve the IPv4 routing scaling problem.

2 - No-one has any proposal other than portability which works for
    most of today's networks, in which raw public IP addresses are
    found in config files all over the network, and which are
    also programmed into some embedded devices which will never
    be amenable to any automated update system.  (The security
    and robustness requirements of any centralised IP address
    alteration system are really daunting - my guess is it will
    never be achieved to the satisfaction of most end-user
    networks.)

Since there is not so much urgency finalising and deploying the IPv6
solution, and since a more elaborate solution for IPv6 could
contemplate host changes, and to have the new mechanisms built into
the OS, applications and embedded devices in the future, I would not
entirely oppose some automated renumbering as an alternative to
portability for IPv6.

However, if the IPv6 solution is going to involve map-encap, then
that provides perfectly portable space anyway, without the concerns
of the past.  So it may just be easier to accept portability as the
easiest way of reducing the pain of renumbering - by removing the
need for renumbering entirely.

The simplest and most robust approaches (in my opinion - map-encap)
to multihoming and mobility involve fast portability.  Slow
portability - a scalable form of PI space so there is no renumbering
when changing ISPs - comes naturally with the map-encap approaches
to multihoming and mobility.


>> 4 - As already agreed, the solution needs to support multihoming
>>     and traffic engineering in a scalable fashion.
> 
> Yes.

OK.

Randall Atkinson wrote:

> Earlier, Robin wrote:
> % Here is the rough list of points, all of which have been
> % discussed in greater detail in recent days:
>
> "Discussed...in recent days" is very substantially different
> from "Rough consensus is evident".

I didn't mean "rough consensus is evident".  I wrote I thought it
would be good if we did agree on these things.


> I would submit the discussion so far has mainly highlighted
> a LACK of rough consensus on a wide range of issues.

Indeed - but I am happy to agree with Brian on some things!


> (Obviously only the co-chairs are empowered to formally
> measure consensus.)

Yes.  I wasn't trying to say we had consensus on anything, except a
few days ago in which I wrote that I thought we all agreed that
since the RRG and the IETF etc. has only limited ability to persuade
end-users to do anything, that our solution needs to have immediate
benefits if it is to be widely enough adopted to solve the routing
scaling problem.

  - Robin

--
to unsubscribe send a message to rrg-request@psg.com with the
word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/rrg/> & ftp://psg.com/pub/lists/rrg