[6bone] 2001:478:: as /48

[Pim van Pelt]

On Sun, Jul 21, 2002 at 09:16:40AM -0700, Bill Manning wrote:
| 
| 
| this prefix has/is being carved up into /48 and /64 subnets for
| use at exchange points and other infrastructure support services.
| 
| Do not expect to see it aggregated. 
In the RIPE region, there were lengthy and quite heated discussions on
how an IXP is to request address space.

The superblock 2001:7f8::/32 was created and also carved into /48s for
use on peering points. It was specifically forbidden to run support
services (such as looking glasses, websites, mailservers, etc) in this
address space and it was noted that these /48s need not be globally
routable.

John points out that not having a route for the /48 will break things
like traceroute. This would then be due to reversed path filtering,
which can be (and should be) disabled.

Others point out that not having a route for the /48 will break things
like path MTU discovery. This is also not true, except for those
who do have RPF on the router originating the too large frame.

Actually, I used to believe also that not having a route for the peering
mesh breaks the pMTU, but people with a lot more brains than I assure
me that there is nothing broken at the IXP unless the participating
operators break their routers (eg by enabling RPF). To my knowledge,
there is no router today which does RPF for IPv6, but I could be
mistaken.

Regarding Johns statement with regard to accepting broken space from
somebody who is well known and respected, I am in total disagreement.
I will be filtering according to RFC and in the case one exists, the BCP
documents which are approved by my local community in the RIPE area.
Accepting /48s from some /32 from ARIN does not belong to this set of
policies, and I really don't see why any LIR, be they an IXP or no,
should be able to change these policies on their own.

As said previously, I have no real problem with parties who chose to
deliberately leak a /48 into the global tables. Such has been done by
the RIPE NCC (who have space from SURFnet, the nren) and possibly will
be done by the AMS-IX (the dutch high volume peering point) in the
future. This is because the current policies do not allow for these
parties to obtain an aggregate for themselves.

It is clear that if one is to accept the /48 from AMSIX or RIPENCC that
they could have a better path to them. People who do not wish to carry
the /48 in their tables, will still have a less specific route to the
SURFnet aggregate.

So in short: somebody should be aggregating 2001:478::/32 so that I (and
most probably several other European operators) will have a path to the
aggregate and be able to reach the /48s in a proper, RFC obeying manner.

-- 
---------- - -    - - -+- - -    - - ----------
Pim van Pelt                 Email: pim@ipng.nl
http://www.ipng.nl/             IPv6 Deployment
-----------------------------------------------