[ppml] v6 multihoming and route filters
Iljitsch van Beijnum
iljitsch at muada.com
Fri Jun 30 20:06:19 EDT 2006
Marla,
On 28-jun-2006, at 21:32, Azinger, Marla wrote:
> I currently have customers asking for this ability and none of them
> wish to wait for solutions that may not be fully developed for a
> couple more years. Also, my customers don't want to get PI space
> (even under the new V6 PI policy), so this means I need to give
> them a /48 and set up multihoming. However, as all policy and
> practices sit right now, everyone filters on a /32.
I see there is a long discussion on ppml that I hadn't noticed before
about this subject. Scott Leibrand made some good points on both the
usefulness and the limitations of multihoming using PA space. It's
too bad that some others are pushing for PI. PI ALWAYS needs a place
in the global routing table, while with shooting holes in PA, the
more specific only needs to be visible in part of the network. As
long as that part is big enough to provide reasonable multihoming
benefits, this works out well of all parties involved.
Unlike PI, PA multihoming is compatible with what we're trying to do
in shim6, which may or may not be an advantage, but it can't hurt.
(If anyone has questions about shim6, email me off-list.)
Thinking in practical terms, I don't see an "allow all /48s" policy
adopted by most network operators any time soon, as it commits them
to something that may not give them trouble now, but has the
potential to do so in the future. An alternative would be to come up
with a BGP community to tag /48s that are used in multihoming so that
it's possible to selectively allow those while still rejecting /48s
that are deaggregated by accident. It will probably still take some
time to get this adopted, but ISPs are smart enough to realize that
more multihoming is more business for everyone, so I expect that
something like this will be accepted unless there are problems that
make this solution unattractive. I would be happy to co-author a
document outlining this.
More information about the ARIN-PPML
mailing list