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