v6 peering at PAIX/Palo Alto

Jeroen Massar jeroen at unfix.org
Tue Aug 29 17:11:28 CEST 2006

Joe Abley wrote:
> Switch and Data recently started distributing addresses assigned out of 
> 2001:540:d::/48 for use in v6 peering on their Bay Area fabric (exposed 
> at 529 Bryant/Palo Alto, 200 Paul/San Francisco, etc), replacing the 
> 6bone prefix that had been in use there for a long time.
> Trouble is S&D didn't specify a prefix length when they told people 
> their addresses. I know some people who have assumed a /64. S&D 
> themselves insist that the correct prefix length is a /48.
> Seems to me that if I was S&D, I'd be carving one /64 out of that /48 
> for each exchange point fabric I operated. Perhaps they have other 
> plans, though (or aspirations to attract more than 2^64 peers to their 
> Bay Area fabric :-)
> So anyway, just interested -- how many people here assumed that the 
> prefix length was /64?

They put a /48 on a single ethernet? How many routers do these guys want 
to connect? :) I guess somebody should explain them what a "prefix" is 
and what the "/48" portion of it means....

On this same subject are IX's that request /48's for every single switch 
they seem to have, even though at different sites, but run by the same 
operator. Eg 2001:7fa:9::/48 - 2001:7fa:f::/48. I wonder how big those 
IX's are that they need a separate /48 for every site. Then again they 
have enough room for expansion then ;) But it is quite wasteful. The 
only real argument could be that now they can split off any of them 
without having to renumber.

> What operational damage might result from a mixture of routers 
> configured with their PAIX address variously in a /48 or a /64? Will it 
> make any practical difference to anything?

Only thing is that Router Advertisements don't work with anything else 
than /64's. For the rest if everybody uses a /48, it should be fine, 
just a bit wasteful of address space though. As there is no concept of 
broadcast, that can't give any problems. The subnet anycast address is 
at the lower :: thus that should not give any issues either. They should 
though be using a single /64 on the interface just to be sure that is 
can work.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 311 bytes
Desc: OpenPGP digital signature
Url : http://lists.cluenet.de/pipermail/ipv6-ops/attachments/20060829/7e450863/signature.bin

More information about the ipv6-ops mailing list