[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Post-Exhaustion-phase "punishment" for early adopters



On Tue, Feb 8, 2011 at 6:54 PM, David Barak <thegameiam at yahoo.com> wrote:
>
>
>>From: R. Benjamin Kessler <Ben.Kessler at zenetra.com>
>
>>>From: George Herbert [mailto:george.herbert at gmail.com]
>
>>>"Let's just grab 2/8, it's not routed on the Internet..."
>
>>+1
>
>>I was consulting for a financial services firm in the late '90s that was
>>acquired by a large east-coast bank; the bank's brilliant scheme >was to
>>renumber all new acquisitions *out* of RFC1918 space and into (at the time)
>>bogon space.
>>
>
>>If I recall, some of the arguments were "they were too big to fit into RFC1918
>>space" and by having all of their divisions in non->RFC1918 space it would make
>>it easier for them to acquire new companies who used RFC1918 space internally.
>
>>I wonder what they're doing now...
>
> <fireproof underwear = on>
>
> If we make the assumption that the hosts which were numbered in the space
> formerly known as bogon are typical enterprise hosts, it wouldn't be surprising
> if they were just?fine: they probably don't *want* to have end-to-end
> connectivity, and are perfectly happy with the proxy-everything approach.
>
> If you're going to NAT everything anyway, then the damage done by having 2/8 on
> both sides of the NAT isn't any worse than having 10/8 on both sides of the
> NAT.? If it turns out that they start running across the hosts in 2/8 as
> customers, those can get NATted into some third block, with probably a lot less
> effort and confusion than trying to sort out the chunks of overlapping 10/8s.

If you could really proxy everything, you'd be able to use 10/8
everywhere and never hit problems, even if two private peers overlap
in usage within 10/8.

I can assure you that the "proxy everything" statement breaks down
with every enterprise-to-enterprise interconnection project I've run
into.  There are some protocols that are just not meant to do that.


-- 
-george william herbert
george.herbert at gmail.com