Re: [apops] Fwd: Korea Telecom leaking >1000 prefixes to Internet

  • To: <apops at lists dot apnic dot net>
  • Subject: Re: [apops] Fwd: Korea Telecom leaking >1000 prefixes to Internet
  • From: "Phillip Grasso-Nguyen" <grasso at magna dot com dot au>
  • Date: Wed, 13 Dec 2000 09:34:35 +1100
  • Sender: owner-apops@lists.apnic.net
    • > announcing. If KT, for example, have a commercial
      > in-confidence reason for
      > announcing /30s etc to their peers, that is their private
      > issue, but then
      > they should take reasonable steps to ensure that the rest of
      > the world is
      > not drawn into their private affairs (the no-export community
      > could help
      > with this, for example). But any provider who has a need to
      > announce a /nn
      > to the Internet should be free to do so, as you say. And it
      > should not
      > matter what it is - that's the idea of CIDR... :-)
      
      This is only a suggestion, but I *think* that the larger providers should
      enforce RFC2519 for no-export functionally (to the smaller ISP's), and
      possibility the RADB *Could* be used as an alerting tool.
      
      I found that many providers knowingly announcing smaller blocks for
      preferred traffic direction, e.g. Satellite backchannel providers, /19 to
      Telstra, and two /20's to IHUG/NetConnect. Some Go beyond that and announce
      32x/24's. Not just that but other providers announce sub-CIDR for MED
      (effectively more control) however they should only be announcing with
      NO-EXPORT. (i'm guilty of doing this :-( ).
      
      If more people had RFC1998+ configured, these satellite ho's could control
      traffic direction without the need for announcing longer prefixes, however
      there are always some that DON'T want ANY traffic going via their cable
      paths. Obviously this lead's to it's own problems, but so is Global routing
      table.
      
      
      Regards
       Phillip.
      
      
      *             APOPS: Asia Pacific Operations Forum              *
      * To unsubscribe: send "unsubscribe" to apops-request at apnic dot net *