Bad routes update

[Robert Rockell]

No PTLA SHOULD RECIEVE A ROUTE FROM OTHER PTLA'S MORE SPECIFIC THEN THE
FULL PTLA ROUTE. THERE IS NO CURRENT NEED FOR IT (other than maybe to do
hot-potato routing eventually, but this needs to be fixed, not worked
around.

Thanks
Rob Rockell
Sprintlink Internet Service Center
Operations Engineering
703-689-6322
1-800-724-3329, PIN 385-8833
Ines|e gnyne qh vagr bz s|e Ino ngg una {e hgr bpu plxyne?

On Tue, 20 Jul 1999, Craig Metz wrote:

->In message <Pine.GSO.3.96.990719221751.22806C-100000@iscone>, you write:
->>3FFE:F00:2::0/48		11261
->
->  This is not a bogus route per se. I told them to set it up this way. I have
->been recommending that non-pTLA multi-homed sites use a /48, which happens to
->mesh nicely with the way I've been managing tunnel address space at NRL.
->
->  I can see a very very strong case for making it /32 and setting a hard and
->fast rule that prefixes >/32 are not allowed into the cloud. I think that it
->would be a Very Very Good Thing if no backbone router ever had to look at
->beyond the first 32 bits of the address, as this would make life a Whole Lot
->Easier for hardware that is designed for the best-performance case being 32
->bit addresses (like, oh, say, most backbone routers).
->
->  Now, these other prefixes are bogon.
->
->  I'd like to add one I saw in my routing tables:
->
->  3FFE:F00:A:1133::0/64
->         *> 3FFE:F01:0:FFFF::5 FE80::C8E:50C2:7 Tunnel1 1225 1103 65502 5623 559 1717 1835 1849 109 3462 3263 49 i
->         *  3FFE:F01:0:FFFF::19 FE80::E0:1E8E:C2C1:18 Tunnel6 5609 1225 1275 1103 222 5623 559 1717 1835 1849 109 3462 3263 49 i
->  3FFE:F00:A:11E1::0/64
->         *> 3FFE:F01:0:FFFF::5 FE80::C8E:50C2:7 Tunnel1 1225 1103 65502 5623 559 1717 786 1849 109 3462 3263 49 ?
->         *  3FFE:F01:0:FFFF::19 FE80::E0:1E8E:C2C1:18 Tunnel6 5609 1225 1275 1103 222 5623 559 1717 786 1849 109 3462 3263 49 ?
->
->  NIST guys, please fix.
->
->>3FFE::0/16			2497 (prepended)
->
->  Sigh.
->
->>When Ipv6 goes live, unless business is more good-willed than it is now,
->>this is going to break things, and one pTLA may not have much motivation to
->>fix the problem (unless flames on the 6bone mailing lists really hurt).
->
->  What's basically going to have to happen soon is that we're going to have to
->turn on the basic BGP knobs. I'd like to see routing transit policy stuff in
->place on the 6Bone as well as reasonable path metrics and such, as it would
->stop much of the current tunnel routing insanity.
->
->  Perhaps the Cisco guys could elaborate, but I had the impression that only
->a very limited subset of the knobs are really built for IPv6. This might
->complicate things.
->
->									-Craig
->