[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [RRG] Consensus? IPv4 scaling problem must be solved directly, not by relying on migration to IPv6
- To: "Robin Whittle" <email@example.com>
- Subject: Re: [RRG] Consensus? IPv4 scaling problem must be solved directly, not by relying on migration to IPv6
- From: "William Herrin" <firstname.lastname@example.org>
- Date: Mon, 26 May 2008 21:39:39 -0400
- Cc: "Routing Research Group" <email@example.com>
- Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=C6VAFwDFWXtGCB1Fi39SeM7KqSQhNSxwq7IzZbS9G7ycAuvO7tDJxhYIkXUJvIarhr/A7YDxzlVkqh+/oqfMHmjqSJLV7CZ34ydPSManZi+4usjPHiZEA74YGzzPX+KhEI2+q5IhVblABMZulKkSJznKOkzb/DXdbghWhytaR54=
- In-reply-to: <483934A7.firstname.lastname@example.org>
- References: <483934A7.email@example.com>
On Sun, May 25, 2008 at 5:43 AM, Robin Whittle <firstname.lastname@example.org> wrote:
> I think the map-encap schemes (LISP, APT, Ivip and TRRP) were all
> designed on the assumption that we must solve the routing scaling
> problem in IPv4 and the one which would develop if and when IPv6 is
> widely adopted.
Speaking for TRRP, this is correct and I consider the assumption valid.
> Here is why I think we can't just solve the future IPv6 problem and
> rely on the IPv4 problem being solved - or becoming no longer a
> concern - due to most end-users no longer needing IPv4 space.
#0: Don't count your chickens before they hatch. IPv6 may be the
future of the Internet, but that future has yet to arrive. The
possibility of an IIPv4 double-NAT world with lots of little bitty
islands of public IPv4 addresses for servers is still in the cards.
The nasty thing is this: Double-nat is *very* incrementally
deployable, so it could deploy ahead of IPv6 in order to relieve the
pressure and serve as a stopgap after the end of the IPv4 free pool.
But IPv4 exhaustion is the only thing driving IPv6 deployment. Relieve
that pressure and the expense of IPv6 deployment might well stop it
On Mon, May 26, 2008 at 12:16 AM, Tony Li <email@example.com> wrote:
> To date, no one has demonstrated a routing architecture that scales without
> aggregation, and aggregation is THE sore point.
TRRP? Though I suppose that's only been proposed, not demonstrated.
On Sun, May 25, 2008 at 6:51 AM, Eliot Lear <firstname.lastname@example.org> wrote:
>> IPv6 has been available in operating systems for at least 10 years,
>> but in terms of adoption, it has been a spectacular failure. This
> 1. There is no serious Plan B. Any plan that came to be today likely
> couldn't be fielded.
Double-NAT. We add the Class-E space to the existing RFC1918 space and
just like service providers now only offer static IPs to those who
request and pay extra for it, they'll start only giving public IPs to
those who request and pay extra for it. Thus the user's packet gets
natted twice: once at his "broadband router" and once again upstream
at his ISP.
Nobody WANTS to do this, but everybody CAN do it, and they can do it
with COTS systems available now. You may not like it (I sure don't)
but that's plan B and it's VERY SERIOUS.
On Mon, May 26, 2008 at 5:18 AM, Tony Li <email@example.com> wrote:
> If you believe [Ross Callon] then the issue is real and is strategic, not tactical.
> We have the opportunity to Do It Right, and we should.
Doing it Right with a capital R and doing it compatibly have ever been
mutually exclusive goals. If we can't find the consensus to pick one,
we should fork the task and let different groups pursue both in
parallel. Trying to compromise between the two rarely seems to end
William D. Herrin ................ firstname.lastname@example.org email@example.com
3005 Crane Dr. ...................... Web: <http://bill.herrin.us/>
Falls Church, VA 22042-3004
to unsubscribe send a message to firstname.lastname@example.org 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