[arin-ppml] Portable address space vs. IPv6 auto-numbering

[Jason Schiller]

If Tony and Robin are taking a poll on the best way to make routing scale,
I'll agree with Paul and Lee.  If I have to choose between implementing
locator and ID separation in either IPv4 or IPv6, I think IPv6 makes the
most sense.  However I don't see any solutions for IPv4 that cannot also
be implemented in IPv6.

If there is a way to make IPv4 and IPv6 more scalable through redirection
such as locator/ID separation then we should be working on providing that
functionality for both protocols.

However, if the extra bits in IPv6, or the extra next-headers somehow give
us more flexibility and allow us to as Tony Li puts it "do something
better", that is less "architecturally unclean", then we should focus on
an architectural solution for IPv6, especially when we consider IPv4
depletion.

This is not to say as Robin suggests that by focusing on IPv6 we somehow
get the luxury of more time.

No matter whether we focus on solving the routing issue in IPv4, IPv6, or
both protocols, we have maybe two years until IPv4 depletion.  Once that
occurs demand for new address will only be fulfilled through IPv6.  It
would be nice if we had a solution for mult-homing, TE, and mobility at
that time so we do  not recreate the problems that IPv4 is currently
suffering from in IPv6, namely massive de-aggregation to solve the
problems of multi-home, TE, mobility, and provider independence.

The short time line may drive us to something which requires little
or no stack modifications and instead is more "architecturally unclean".

__Jason


==========================================================================
Jason Schiller                                               (703)886.6648
Senior Internet Network Engineer                         fax:(703)886.0512
Public IP Global Network Engineering                       schiller at uu.net
UUNET / Verizon                         jason.schiller at verizonbusiness.com

The good news about having an email address that is twice as long is that
it increases traffic on the Internet.

On Wed, 11 Jun 2008, Paul Vixie wrote:

> while i am not a member of RRG, if the question is drawn as clearly as
> that, my position would be, forget about IPv4.  the internet will have
> many more than 2^32 devices connected to it simultaneously within our
> lifetimes, and i think we should preserve the option of not using NAT in
> future generations.  therefore IPv4's growth has a glass ceiling formed
> by its address size, and
> any effort that's put into growing its routing table has a fixed return.

On Wed, 11 Jun 2008, Howard, W. Lee wrote:

> If Tony and Robin are taking a poll on the best way to make
> routing scale, I'll agree with Paul that I don't think IPv4
> can be made to scale, and so we shouldn't waste time trying.
> I can't argue on which of various solutions might work for
> IPv6; it's not part of my day job or volunteer work.

On Thu, 12 Jun 2008, Robin Whittle wrote:

>   If the RRG decides it doesn't need to fix the IPv4 routing
>   scaling problem, then it can concentrate its energies - and
>   the IETF's, if the IETF accepts the RRG's recommendation - on
>   the much less urgent IPv6 scaling problem.
>
>   IPv6 has many more technical possibilities for solving the
>   problem, primarily due to its longer address length and much
>   lower installed base.
>
>   If the RRG/IETF doesn't care about the IPv4 routing scaling
>   problem, then it probably has many years to solve the IPv6
>   problem, because I can't see how mass migration to IPv6 is
>   going to happen in the next decade.
>
>   However, this seems like a high-pressure, high-risk venture.
>
>   While one planet burns, the expeditionary force is supposed
>   to be preparing another, significantly incompatible, but
>   ultimately better planet.  I would rather a more relaxed
>   mission timetable:
>
>   I would rather fix the IPv4 problem ASAP and have more time
>   to prepare a lasting alternative, especially something with
>   greater ease of migration from IPv4, which means a much better
>   means of communicating with the IPv4 Internet than is currently
>   possible with IPv6.

On Thu, 12 Jun 2008, Paul Vixie wrote:

> i think we're going to see IPv6 routing table bloat earlier than RRG's
> work could possibly complete, and that that's the real race here, and
> that any time spent prolonging IPv4's doddering old age with double- and
> triple-NAT is a dangerous distraction.  the internet is not just the
> web, and we can't go on building new kinds of applications if everything
> has to be some kind of NAT or map-encap or ALG or proxy.  IPv4 is headed
> for end-of-life.  let's move on.

On Tue, 10 Jun 2008, Tony Li wrote:

> It's actually very unlikely that we will resort to a 
> tunneling/encapsulation mechanism.  They are too cumbersome,
> architecturally unclean, and fraught with MTU issues.  My hope is that
> we do something better.