legacy /8

Sat Apr 3 06:47:36 UTC 2010

On 4/2/2010 19:13, George Bonser wrote:
>
>   
>> -----Original Message-----
>> From: Jim Burwell [mailto:jimb at jsbc.cc]
>> Sent: Friday, April 02, 2010 6:00 PM
>> To: nanog at nanog.org
>> Subject: Re: legacy /8
>>     
>
>   
>> So, jump through hoops to kludge up IPv4 so it continues to provide
>> address space for new allocations through multiple levels of NAT (or
>> whatever), and buy a bit more time, or jump through the hoops required
>> to deploy IPv6 and eliminate the exhaustion problem?  And also, if the
>> IPv4 space is horse-traded among RIRs and customers as you allude to
>> above, IPv6 will look even more attactive as the price and
>>     
> preciousness
>   
>> of IPv4 addresses increases.
>>     
> No problem,  everyone tunnels v4 in v4 and the "outer" ip address is
> your 32-bit ASN and you get an entire /0 of "legacy" ip space inside
> your ASN.  Just need to get rid of BGP and go to some sort of label
> switching with the border routers having an ASN to upstream label table
> and there ya go. Oh, and probably create an AA RR in DNS that is in
> ASN:x.x.x.x format.  Increase the MTU a little and whammo!  There ya go!
> Done.
>
> :)
>
>   
So essentially add 32-bits to the IPv4 address, used as a ASN, and use
legacy V4 on the "backbone" which tunnels everything, so the entire
intra-ASN internet has to go through v4-in-v4 tunnels.  A few "little"
changes to DNS, and voila!  And of course, there's no "devils in the
details" we have to worry about.  Heck.    Just quote that last post up
and submit it as an RFC to replace the IPv6 RFCs!  :-)

Seriously though, would that really be easier to implement, or be better
than IPv6 as this point?  I'd think the IETF would probably have
considered solutions like that, but IPv6 is what we got.  So best learn
to love it.  :P

-Jim

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5570 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20100402/e63e2a24/attachment.bin>