RE: [RRG] Moving forward... IPv4 now, IPv6 less urgent and perhapsmoreambitious

["Templin, Fred L" <Fred.L.Templin@boeing.com>]

>-----Original Message-----
>From: Robin Whittle [mailto:rw@firstpr.com.au] 
>Sent: Wednesday, June 11, 2008 5:58 PM
>To: Routing Research Group
>Cc: Templin, Fred L
>Subject: Re: [RRG] Moving forward... IPv4 now, IPv6 less 
>urgent and perhapsmoreambitious
>
>Hi Fred,
>
>You wrote:
>
>> Sorry for the delay, but I had to dig pretty deep to find this:
>>
>>> Fred Templin disagreed with your text, wanting IPv4 and IPv6
>>> solutions.
>>
>> I don't disagree with what Tony said, however, there is quite
>> a bit left to consider in what he _didn't_ say.
>
>I apologise for misrepresenting your position.

That's all right; my original wording was probably ambiguous.

>> Tony didn't
>> say, for example, that we can expect the existing global IPv4
>> deployment to be decommissioned in the coming N years (for any
>> value of N). He also did not say that IPv4 will have no roll
>> to play in the IPv6 routing scaling solution.
>
>My understanding of the text Tony proposed was that it would be
>acceptable for the RRG solution to be developed for IPv6 only.  I
>understand this as meaning that the RRG would be doing its job if it
>allowed the the IPv4 routing scaling problem (increased DFZ router
>costs, instability, lack of multihoming for large numbers of
>end-user networks etc.) to continue to grow until a significant
>proportion of end-users adopted IPv6-only services.
>
>Since I can't see how large numbers of end-users will have IPv6-only
>services in the next decade, and because I assume that the IPv4
>routing scaling problem will accelerate and become an excessive (and
>I think avoidable) burden on all Internet users, I proposed an
>alternative.  This would commit the RRG to recommending a solution o
>the IPv4 problem for development and deployment ASAP, and doing our
>best to facilitate a solution to the IPv6 problem in sufficient time
>that no serious problem develops.  This is a much longer time frame
>with more technical flexibility for a solution, and perhaps no need
>by 2009-03 to make a precise recommendation on the IPv6 solution.

My understanding is that ordinary end-users today cannot offer
*any* services, since they typically sit behind a NAT with only
a private-use IPv4 address. That means that they can call out to
any IPv4 server on the net, but no one can call in to them. The
best solution for this IMHO is IPv6, since IPv6 gives the end
user a globally routable address. That means that any remote
peer that usess IPv6 can access services on the (IPv6-capable)
end user device, which is value-added beyond what can be done
in an IPv4-only world. Note that we are talking dual-stack here;
we are not asking for IPv4-only nodes to convert to IPv6-only   

>> In my perfect world, we would roll out the big iron to
>> flat-route the global IPv4 address space, while at the same
>> time we map-and-encaps the dickens out of IPv6.
>
>So your ideal is no architectural enhancement for IPv4.  Every DFZ
>router would be replaced every few years by some even more humongous
>thing from Cisco or Juniper with tens and later hundreds of gigs of
>RAM, and multiple CPUs somehow working to keep the BGP process
>working cohesively, despite having a dozen or so peers to chat to
>about several million prefixes.

IMHO, the ultimate level of aspiration would be flat-routing
the entire IPv4 global address space down to /32 granularity.
Maybe that means that we need to bring back your SRAM proposal
from last year. Maybe that means that we need to replace BGP.
Maybe it means some combination of things. 

>I think that would be indistinguishable from letting the IPv4
>routing scalability problem fester, and having all Internet users
>pay for these fabulously muscled routers, betting that by some
>means, (such as an imaginary chicken laying a real egg which grows
>into a real chicken), enough end-users will be happy with an
>IPv6-only service that the IPv4 debacle will come to an end in some
>acceptable way.

Again, in my perfect world, IPv4 never goes away. Instead, it
remains as the subnetwork layer routing and addressing protocol
when the global interdomain routing core is virtualized as a
subnetwork for IPv6.

>I thought the aim of the RRG work was to prevent such massively
>expensive technical mistakes.
>
>> The existing
>> IPv4 services would then remain highly available while new
>> services are rolled out using IPv6 and w/o thrashing the
>> routing system. IPv6/IPv4 map-and-encaps would support
>> this, but IPv6/SEAL/IPv4 map-and-encaps would be much
>> better (and also much better than IPv6/IPv6).
>
>Are you suggesting that IPv4 be used as the backbone for
>encapsulated IPv6 packets?  Wouldn't any self-respecting ISP
>providing IPv6-only services already have native links to the IPv6 DFZ?

As above, my vision is that the interdomain routing core stays
at IPv4 and the enterprise/site networks at the edges move to
IPv6. I know from visiting your webpages that you are not much
for the big bang theory, but consider the interdomain routing
core as the (black) center of an ever-expanding (red) universe.
(There may also be black-holes within the red networks, but
that is topic for a different discussion.) So, if we can engineer
our way through the finite scaling properties of IPv4 we can
map-and-encaps our way through the infinite scaling properties
of IPv6.

Thanks - Fred
fred.l.templin@boeing.com

>
> - 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