IPv6 day and tunnels

Owen DeLong owen at delong.com
Tue Jun 5 06:06:31 UTC 2012


On Jun 4, 2012, at 6:11 PM, Jeroen Massar wrote:

> On 2012-06-04 17:57, Owen DeLong wrote:
> [..]
>> If you're going to redesign the header, I'd be much more interested
>> in having 32 bits for the destination ASN so that IDR can ignore IP
>> prefixes altogether.
> 
> One can already do that: route your IPv6 over IPv4.... IPv4 has 32bit
> destination addresses remember? :)
> 
> It is also why it is fun if somebody uses a 32-bit ASN to route IPv4, as
> one is not making the problem smaller that way. ASNs are more used as
> identifiers to avoid routing loops than as actual routing parameters.
> 
> Greets,
> Jeroen

While this is true today (to some extent), it doesn't have to always be true.

If we provided a reliable scaleable mechanism to distribute and cache prefix->ASN mappings and could reliably populate a DEST-AS field in the packet header, stub networks would no longer need separate ASNs to multihome and IDR routing could be based solely on best path to the applicable DEST-AS and we wouldn't even need to carry prefixes beyond the local AS border.

While I don't think DNS is up to the task of reliable distribution and caching (though something somewhat similar to DNS could do the job rather well), DNS-style resource records could be used. For example, instead of using my own AS1734 as I do today, my multi-homed household could be placed in the database with pointers to my two upstream ASNs as follows:


2620:0:930::/48			AS		10	6939
						AS		10	8121
192.124.40.0/23			AS		10	6939
						AS		10	8121
192.159.10.0/24			AS		10	6939
						AS		10	8121

Or, if I wanted to do some traffic engineering, I could tweak the preferences to be non-equal values.

The router doing the DEST-AS insertion into the packet would grab the most preferred AS to which it has a valid feasible successor.

I believe that the number of transit autonomous systems on the planet is much smaller than the minimum number of prefixes to represent all multi-homed organizations with independent routing policies. As such, I believe this could produce much more scalable routing with relatively little additional overhead.

Owen





More information about the NANOG mailing list