Shim6 vs PI addressing

Owen DeLong owen at
Thu Mar 2 21:31:35 UTC 2006

--On March 2, 2006 9:37:12 AM -0500 Jared Mauch <jared at>

> On Wed, Mar 01, 2006 at 03:01:22PM -0800, Owen DeLong wrote:
>> > 	I think you're missing that some people do odd
>> > things with their IPs as well, like have one ASN and 35
>> > different sites where they connect to their upstream
>> > all with the same ASN.  This means that their 35 offices/sites
>> > will each need a /32, not one per the entire asn in the table.
>> > 
>> People who are doing that have not read the definition of the
>> term ASN and there is no reason that the community or public
>> policy should concern itself with supporting such violations
>> of the RFCs.  An AS is a collection of prefixes with a consistent
>> and common routing policy.  By definition, an AS must be a
>> contiguous collection of prefixes or it is not properly a
>> single AS.  Using the same ASN to represent multiple AS is
>> a clear violation.
>> It doesn't fit the RFC definition of AS.  Therefore, there is no
>> reason to support such usage on a continuing basis.  You violate
>> the RFC's you takes your chances.
> 	I guess all those root servers that use the same asn
> but connect to different networks (anycast) should get shut down
> quickly.
No... In the case of anycast, there is a consistent routing policy
for the address.  There are services that don't work because
of that routing policy, but, that's a decision of the service
provider in question.  However, they are using the equivalent
of one /32 per entire ASN, not one per site.

If they are advertising different prefixes from different sites
in an inconsistent manner using the same ASN, that is broken.
That's not what anycast does.

> 	This is a part of networking life today in the v4 space,
> and without any current changes, it will (is) the same in v6
> routing as there is nothing different except a few more bits 32 => 128.
Anycast is part of networking life today.  What you described initially
is _NOT_ how anycast works.


If it wasn't crypto-signed, it probably didn't come from me.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 186 bytes
Desc: not available
URL: <>

More information about the NANOG mailing list