[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: v6 multihoming and route filters



I urge everyone to seriously consider that silence is not a good answer.  This internet community needs, wants and is asking for direction.  Whatever comes out of this discussion, verbalizing a plan (be it with flaws or not) is better than no plan at all.  Silence has been a large part of this issue for some time now (with various internet conference venues) and all this has done is create confusion and finger pointing and thus total feeling of lost and confused routing for developing V6 networks.  

Also, correct me if I'm wrong...but I didn't think the global routing table should be seeing the "metropolitan aggregation" setup.  So /48 filter shouldn't interfere with that kind of setup.

Marla Azinger
Frontier Communications

-----Original Message-----
From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org]On
Behalf Of Christian Huitema
Sent: Tuesday, July 04, 2006 6:13 PM
To: Iljitsch van Beijnum; Marc Blanchet
Cc: v6ops@ops.ietf.org
Subject: RE: v6 multihoming and route filters


> What would be the purpose of filtering at /48?
> 
> That allows for 2^45 = 351 trillion prefixes in the routing table,
> which I suspect won't work too well on current routers. And it only
> takes a handful of /32s deaggregated into /48s to inflate the IPv6
> global routing table to a size larger than the current IPv4 routing
> table.

But then, filtering at /32 allows for 2^30 = 1 billion prefixes, which I
suspect also won't work too well on current routers. Setting filtering
constraints at /32 is not sufficient to ensure small tables.

Setting narrow filtering constraints is also counter-productive, as it
encourage a rush on the short prefixes. An organization that could have
done just fine with a /48 or maybe a /40 will request a /32 just in
case, so that organization can eventually multi-home. 

In the end, the size of the routing table will equal the number of
entities that want multi-homing hard enough. Playing around with prefix
sizes will not change that, and will probably generate undesirable
counter effects.

Besides, there are networks in which advertizing /48 or even /64 in BGP
makes perfect sense. Take for example the "metropolitan aggregation" in
which all users in an area get numbered from the same long prefix. The
local ISP will have to exchange the short prefixes with each other. The
will use BGP. Do we want to have a rule cast in stone that prevents
them?

We should really think twice before asking the IETF to publish a
position on this subject. Silence may well be the right approach.

-- Christian Huitema