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.
Greets,
Jeroen
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 311 bytes
Desc: OpenPGP digital signature
URL: <https://lists.cluenet.de/pipermail/ipv6-ops/attachments/20060829/7e450863/attachment.sig>
More information about the ipv6-ops
mailing list