who gets a /32 [Re: IPV6 renumbering painless?]

Jeroen Massar jeroen at unfix.org
Fri Nov 19 11:46:24 UTC 2004


On Fri, 2004-11-19 at 12:15 +0100, Iljitsch van Beijnum wrote:
> On 18-nov-04, at 18:02, Jeroen Massar wrote:
> 
> > Larger enterprises probably consist of 200 'sites' already, eg seperate
> > offices, locations etc. Thus they can, after becoming a LIR and getting
> > an ASN, which most of the time they already have, easily get a /32.
> 
> Jeroen, this is nonsense and you know it.

It is not nonsense as long as 'multi6' doesn't have a solution to the
problem, but as politics go above getting solutions...

<SNIP>

> Now I hate to be the bearer of bad news, but having unaggregatable 
> globally routable address space just doesn't scale and there are no 
> routing tricks that can make it scale, whatever you put in the IP 
> version bits, so learn to love renumbering. And again, IPv6+NAT makes 
> no sense as NAT works much better with IPv4 and with NAT you don't 
> really need the larger address space.

Absolutely. Which is why one will always here from me:
"Want to NAT? Then stay at IPv4"

> > Actually, I would even go so far that the really large corps should be
> > able to get a /32 from every RIR when they globally have offices, this
> > could allow them to keep the traffic at least on the same continent, 
> > not
> > having to send it to another place of the world themselves.
> 
> If you want to introduce geography into routing, do it right. The above 
> "solution" is the worst of several worlds.

Not my idea at all, several big ISP's already do this.
Check http://www.sixxs.net/tools/grh/tla/all/ and look which
organizations have multiple RIR allocations ;)
Just for the reason you mentioned above: they are actually separate
organizations under one big umbrella. But they did fill the policy thus
got their allocation.

Greets,
 Jeroen

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 240 bytes
Desc: This is a digitally signed message part
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20041119/eeebfcde/attachment.sig>


More information about the NANOG mailing list