About RIPE | Contact  | Search | Sitemap    
Homepage RIPE  
RIPE Community Mail Archives
search  
     
RIPE Navigation Ends
About RIPE Maillists
Maillists Archive
Global Lists
Non Active Lists
RIPE NCC Navigation Ends
Next Section

Re: [address-policy-wg] IPv6 access to K-root

  • To: "Iljitsch van Beijnum" <
    >, "Daniel Roesen" <
    >
  • From: Jørgen Hovland <
    >
  • Date: Wed, 2 Mar 2005 11:53:24 -0000
  • Organization: Joergen Hovland ENK

----- Original Message ----- From: "Iljitsch van Beijnum" iljitsch@localhost


On 2-mrt-05, at 11:45, Daniel Roesen wrote:

What do you do against intradomain routing problems? Loops? DDoS
congestion?
Read my book, it's all in there.

Hi
I think it would be much better if you explained it instead. Some of us (just a few though) may not have read that book.


With proper BGP multihoming you (as end site) can just
withdraw your announcement via this problematic uplink. Doesn't
help you with more-specific pseudomultihoming and people filtering
the more-specific.
I appreciate that having your own prefix in the global table makes lots of stuff easier, but what if everyone wants this? It just doesn't scale.
You seem to be too worried about the vendor implementations rather than the BGP specification which scales greatly and way beyond todays and tomorrows size of the global routing table. It doesn't affect us as the customer before no bgp vendor in the world can deliver a working BGP implementation. I am quite confident that this will never happen. As a matter of fact, I am willing to bet all my obsolete Cisco equipment on it.



As for the DoS issue, your transit ISPs can create blackhole communities so you can have them blackhole the traffic for individual /32s (if desired) when those are under attack by announcing even more specific more specifics with this community on them.


It would be interesting if this could be implemented in BGP5 as a standard so you can announce more specific prefixes that is not to be routed instead of just announcing the ones that is supposed to be routed.


Jørgen Hovland ENK



 

Next Section
     About RIPE | Site Map | LIR Portal | About the RIPE NCC | Contact | Copyright Statement
RIPE.NET Homepage LIR Portal RIPE Community