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

[Pim van Pelt]

Hi Bill,

To start off, I now see your point and have no further problems with the
de-aggregated /48s. See in-line comments for some more thoughts. The
only important issue left, in my oppinion, is if your /48 allocated IXPs
will be offering services from within these non-aggregated chunks..

On Mon, Jul 22, 2002 at 05:19:55AM -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.
| 
| 	whom announces 2001:7f8::/32 ?
| 	someone with a path to each and every exchange that gets
| 	a /48 ?   and whom enforces the "no services" clause?
Nobody announces or aggregates it. It is a placeholder for IXPs. It is
much like the network we are talking about now, in all respects.

| % 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.
| 
| 	Modulo the exceptions you mention below ... :)
| 	EP.NET, LLC. is not an LIR. (thats a RIPE convention)
| 	Filtering is the responsibility of each ISP, according
| 	to their own policies. Nothing I do should affect how
| 	you set your own fitlering policies.
Indeed. If one choses not to accept the /48s, then there simply will be
no route to those IXP networks. However, if I wanted to be able to reach
the /48s, I would be forced to change my filtering policies.

So in fact, depending on the given fact that these IXP /48s will be
running services in their deaggregated network space, this will surely
lead to either unreachable services, or changed (global) filtering
policy guidelines.
 
| % 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.
| 
| That is precisely what I'm asking -NOT- be done. There is no transit
| facility that will get you to all the exchanges numbered out of this
| range.  e.g.
| 
| 	2001:478:200::/48	MAE-West
| 	2001:478:1199::/48	MAE-Frankfurt
| 	2001:478:39::/48	IX-SauPaulo
| 	2001:478:1202::/48	CNIX-Beijing
These, and all other more specifics in the 2001:478::/32 network, will
be unreachable from my site(s). I do hope people are not planning to run
public services such as looking glass or websites/whois servers in these
networks ?

If so, those will not be reachable either for my customers, unless I can
be somehow persuaded that IXPs are more special than other pigs.

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