Re: [RRG] Moving forward... IPv4 now, IPv6 less urgent and perhaps more ambitious

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

I understand the current draft text is:

> Our recommendation should be applicable to IPv6.  It may or may not also
> apply to IPv4, but at the very least must provide a path forward for IPv6.

I oppose this because it would allow the RRG not to recommend a
solution for IPv4.

I agree with a lot of what Scott, Dino and Christian wrote.

There is currently only one routing scaling problem - in the IPv4
Internet.  There's no hurry about solving the IPv6 routing scaling
problem because it will only occur if and when IPv6 is widely adopted.

AFAIK we are not required to assume that IPv6 adoption (without IPv4
addresses, meaning mass migration from IPv4) will occur soon enough
that the IPv4 routing scaling problem does not need to be solved.
RAWS concentrated on the IPv4 scaling problem.

The world in general uses IPv4.  Enthusiasm for IPv6 is limited and
is much more prevalent in the IETF than amongst most users or
providers.  (IOW, since its development in the mid-1990s, IPv6 has
not come close to meeting the needs of significant numbers of users
or ISPs.  There is no evidence that the looming IPv4 address
shortage has changed this.)  We should consider that such confidence
about IPv6 is likely to involve unrealistic expectations of imminent
dual-stack and IPv6-only adoption.

If the RRG only recommends an IPv6 solution, almost no-one will take
us seriously or care what our recommendation is.  Almost no-one will
devote serious effort to solving a problem which does not yet exist
and will not arise for 10 years or so.  This is especially so while
the IPv4 problem needs to be solved ASAP and will get significantly
worse as space is sliced and diced more finely after 2010.

I would support text such as:

  We should recommend a solution to the IPv4 routing scaling problem
  which has the best possible chance of being widely adopted in the
  time-frame 2012 to 2015.

  In order for the solution to be widely enough adopted, it must
  involve minimal costs and disruption and provide significant
  immediate and lasting benefits to the new and existing end-users
  and providers who adopt it.  This rules out changes to host stacks
  or applications except perhaps to cope better with any small
  performance limitations imposed by the solution itself.

  We should also recommend a solution to the IPv6 routing scaling
  problem, although with a potentially longer time-frame for
  development and deployment.  Our recommendation for IPv6 may
  be more tentative or suggest multiple avenues which should be
  researched further before a final decision is made.

  The IPv6 situation differs in several important respects
  from the IPv4 situation, including:

    1 - Greater possibility of host stack and application changes
        due to lower installed base.  So perhaps the solution
        could involve fundamental changes and/or additions to the
        IPv6 protocols.

    2 - Likewise, greater possibility of changes to routers, the
        DNS system and other items of network infrastructure etc.
        (Maybe BGP for IPv6, but I think we all agree BGP can't
        improved enough to solve the routing scaling problem on
        its own.)

    3 - The longer address being used potentially for very different
        address management policies and in specific ways for the
        new protocols.  (eg. SHIM6, Six One, Six One Router.)

    4 - Less urgency about development and deployment.

    5 - Therefore, the possibility of choosing and developing
        the IPv6 solution after the IPv4 solution has been
        developed and perhaps partially deployed.

    6 - Therefore the possibility that the solution may also
        be desired or required to explicitly support additional
        goals, such as mobility, QoS across the global Internet,
        better security etc.  (This includes the improvement of
        IPv6 over IPv4 for the explicit purpose of encouraging
        faster IPv6 adoption and so facilitating a more
        rapid changeover by most users from IPv4 and dual stack
        to IPv6 only.)

  Consequently, our recommended IPv6 solution may differ
  significantly in detail and perhaps in principle from the IPv4
  solution.

  However, any difference in principle between the two solutions -
  especially in terms of the types of new network functions (ITRs,
  ETRs etc.) and where they are located - should be minimised
  and justified fully by the advantages which such differences
  enable.

  Likewise, any extensions to the IPv6 protocols which would affect
  applications (such as changes which make it harder to convert IPv4
  applications to IPv6) would need to be fully justified by
  important benefits.


I think that map-encap is the best solution for both IPv4 and IPv6.
 Ivip for IPv4 and IPv6 should be identical in principle and in most
details.

However, I can't rule out that there may be some fancier, better and
more ambitious approaches to solving the IPv6 routing scaling
problem.  This includes fundamentally different approaches,
especially if we contemplate changing the IPv6 protocols.

 - 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