As specified in RFC1918 (ftp://ds.internic.net/rfc/rfc1918.txt) the netblocks 10.0.0.0/16, 172.16.0.0/12 and 192.168.0.0/16 have been allocated for "Private Internets". Consequently, these netblocks should not be routed over the Internet. As shown below, they are currently advertised from AS6848 and these advertisements are carried to us (AS6453) through various AS's of the SprintLink system.
sh ip bgp reg _6846$ BGP table version is 9335417, local router ID is 207.45.201.5 Status codes: s suppressed, d damped, h history, * valid, > best, i - internal Origin codes: i - IGP, e - EGP, ? - incomplete
Network Next Hop Metric LocPrf Weight Path *> 10.0.0.0 144.228.164.57 0 90 0 1794 1239 1790 6846 ? *> 172.16.0.0/12 144.228.164.57 0 90 0 1794 1239 1790 6846 ? *> 192.168.0.0/16 144.228.164.57 0 90 0 1794 1239 1790 6846 ? [...] AS6846 responsibles should take immediate action to remove these announcements. SprintLink, as any conscientious operator, should take action to filter out these announcements from any of its peers. Regards. __ Pierre Thibaudeau | e-mail: <prt@Teleglobe.CA> TELEGLOBE CANADA | 1000, rue de La Gauchetiere ouest | Tel: +1-514-868-7257 Montreal, QC H3B 4X5 | Canada | fax: +1-514-868-8446
My standard in & out route filters are attached. Everyone should use something like this. --asp@partan.com (Andrew Partan) ! This list is used to block bogon routes to/from peers. ! Deny martian routes no access-list 180 ! 0/anything access-list 180 deny ip host 0.0.0.0 any ! 127/8 & longer access-list 180 deny ip 127.0.0.0 0.255.255.255 255.0.0.0 0.255.255.255 ! The private use nets access-list 180 deny ip 10.0.0.0 0.255.255.255 255.0.0.0 0.255.255.255 access-list 180 deny ip 172.16.0.0 0.15.255.255 255.240.0.0 0.15.255.255 access-list 180 deny ip 192.168.0.0 0.0.255.255 255.255.0.0 0.0.255.255 ! Test net access-list 180 deny ip 192.0.2.0 0.0.0.255 255.255.255.0 0.0.0.255 ! 1st and last classical B and C nets (guard nets). access-list 180 deny ip 128.0.0.0 0.0.255.255 255.255.0.0 0.0.255.255 access-list 180 deny ip 191.255.0.0 0.0.255.255 255.255.0.0 0.0.255.255 access-list 180 deny ip 192.0.0.0 0.0.0.255 255.255.255.0 0.0.0.255 access-list 180 deny ip 223.255.255.0 0.0.0.255 255.255.255.0 0.0.0.255 ! All multicast routes - the router now does this itself, but it didn't ! at one point..... access-list 180 deny ip 224.0.0.0 31.255.255.255 224.0.0.0 31.255.255.255 ! Block all routes with a mask longer than /24, access-list 180 deny ip any 255.255.255.128 0.0.0.127 access-list 180 permit ip any any
My standard in & out route filters are attached. Everyone should use something like this. --asp@partan.com (Andrew Partan)
! Deny martian routes ! 1st and last classical B and C nets (guard nets). access-list 180 deny ip 128.0.0.0 0.0.255.255 255.255.0.0 0.0.255.255 access-list 180 deny ip 191.255.0.0 0.0.255.255 255.255.0.0 0.0.255.255 access-list 180 deny ip 192.0.0.0 0.0.0.255 255.255.255.0 0.0.0.255 access-list 180 deny ip 223.255.255.0 0.0.0.255 255.255.255.0 0.0.0.255
In a classless environment, these prefixes are legitimate. Correct behaviour is now known for these subnets and so I wonder why you still have them in your standard list. -- --bill
! Deny martian routes ! 1st and last classical B and C nets (guard nets). access-list 180 deny ip 128.0.0.0 0.0.255.255 255.255.0.0 0.0.255.255 access-list 180 deny ip 191.255.0.0 0.0.255.255 255.255.0.0 0.0.255.255 access-list 180 deny ip 192.0.0.0 0.0.0.255 255.255.255.0 0.0.0.255 access-list 180 deny ip 223.255.255.0 0.0.0.255 255.255.255.0 0.0.0.255
In a classless environment, these prefixes are legitimate. Correct behaviour is now known for these subnets and so I wonder why you still have them in your standard list.
They sure look reserved to me: note% whois RESERVED IANA (RESERVED-1) RESERVED 0.0.0.0 IANA (RESERVED-3) RESERVED 128.0.0.0 IANA (RESERVED-4) RESERVED 191.255.0.0 IANA (RESERVED-5) RESERVED 223.255.255.0 IANA (RESERVED-7) Reserved 64.0.0.0 - 95.0.0.0 IANA (RESERVED-8) Reserved 96.0.0.0 - 126.0.0.0 Actually it looks like I should add the top 1/2 of the old A space as well. It also looks like someone did something really silly with 192.0.0/24: note% whois 192.0.0 IANA (NET-ROOT-NS-LAB) c/o Information Sciences Institute 4676 Admiralty Way, Suite 1001 Marina del Rey, CA 90292-6695 Netname: ROOT-NS-LAB Netnumber: 192.0.0.0 Coordinator: Manning, Bill (WM110) bmanning@ISI.EDU 310-322-8102 Domain System inverse mapping provided by: ORB.ISI.EDU 128.9.160.66 NS.ISI.EDU 128.9.128.127 Record last updated on 01-Jul-96. This idea looks really dumb, and since my >/24 filter blocks these in any case, I see no reason to listen to silly people to unblock this /24. Poking a bit further at this, it looks like 192.0/16 is all reserved as well: Netname: RESERVED-192 Netblock: 192.0.0.0 - 192.0.255.0 Humm, more bogons to add to my filter? --asp@partan.com (Andrew Partan)
Andrew Partan <asp@partan.com> writes: * They sure look reserved to me: * note% whois RESERVED * IANA (RESERVED-1) RESERVED 0.0. * 0.0 * IANA (RESERVED-3) RESERVED 128.0. * 0.0 * IANA (RESERVED-4) RESERVED 191.255. * 0.0 * IANA (RESERVED-5) RESERVED 223.255.25 * 5.0 * IANA (RESERVED-7) Reserved 64.0.0.0 - 95.0. * 0.0 * IANA (RESERVED-8) Reserved 96.0.0.0 - 126.0. * 0.0 * * Actually it looks like I should add the top 1/2 of the old A space as well. * This would be good as I report each week in my report possible bogus routes but no one seems to care to filter (or fix this). Today it says: *** Bogus 69.1.0.0/16 from AS1849 *** Bogus 69.2.0.0/16 from AS1849 *** Bogus 90.0.0.0 from AS4747 *** Bogus 103.40.99.0/24 from AS3249 --Tony
Sorry, but while I was looking to this list, I just reminded interesting issue. Why IANA did not reserved 223.255.0.0/16 or something simular; by other words, I'd like to have short (256, 512, 1024) private address space in the END of total address space for the normal IP (excluding D class etc). For example. I have a lot of CISCO routers with OSPF protocol. Thnis crazy IOS use highest loopback interface address as router-ID address; I use loopbacks to install load balancing etc. and I can't prevent loopbacks from being equal on the different routers. That's why I hardly need some IP addresses for 'Loopback 98' interface to use it as router-ID; and this have to be higher than any user's addresses. I use 233.255.254.0/24 for this purposes, but it's not reserved address. This is one, simple, example why it's nessesary to reserve some short address space in the begin and in the end of total addresses. On Tue, 11 Feb 1997, Tony Bates wrote:
Andrew Partan <asp@partan.com> writes:
* They sure look reserved to me: * note% whois RESERVED * IANA (RESERVED-1) RESERVED 0.0. * 0.0 * IANA (RESERVED-3) RESERVED 128.0. * 0.0 * IANA (RESERVED-4) RESERVED 191.255. * 0.0 * IANA (RESERVED-5) RESERVED 223.255.25 * 5.0 * IANA (RESERVED-7) Reserved 64.0.0.0 - 95.0. * 0.0 * IANA (RESERVED-8) Reserved 96.0.0.0 - 126.0. * 0.0 * * Actually it looks like I should add the top 1/2 of the old A space as well. * This would be good as I report each week in my report possible bogus routes but no one seems to care to filter (or fix this). Today it says:
*** Bogus 69.1.0.0/16 from AS1849 *** Bogus 69.2.0.0/16 from AS1849 *** Bogus 90.0.0.0 from AS4747 *** Bogus 103.40.99.0/24 from AS3249
--Tony
Aleksei Roudnev, Network Operations Center, Relcom, Moscow (+7 095) 194-19-95 (Network Operations Center Hot Line),(+7 095) 239-10-10, N 13729 (pager) (+7 095) 196-72-12 (Support), (+7 095) 194-33-28 (Fax)
-----BEGIN PGP SIGNED MESSAGE----- On Tue, 11 Feb 1997 22:04:19 +0300 (MSK), alex@relcom.eu.net writes:
Sorry, but while I was looking to this list, I just reminded interesting issue. Why IANA did not reserved 223.255.0.0/16 or something simular; by other words, I'd like to have short (256, 512, 1024) private address space in the END of total address space for the normal IP (excluding D class etc).
For example. I have a lot of CISCO routers with OSPF protocol. Thnis crazy IOS use highest loopback interface address as router-ID address; I use loopbacks to install load balancing etc. and I can't prevent loopbacks from being equal on the different routers. That's why I hardly need some IP addresses for 'Loopback 98' interface to use it as router-ID; and this have to be higher than any user's addresses. I use 233.255.254.0/24 for this purposes, but it's not reserved address.
This is one, simple, example why it's nessesary to reserve some short address space in the begin and in the end of total addresses.
No, that's an example of a poorly designed protocol implementation. One ought to be able to specify an arbitrary router id for OSPF (heh - even Bay routers can do that :) rather that relying on such an odd algorithm. I was so surprised by this that I just had to go look it up: <http://www.cisco.com/univercd/data/doc/software/11_2/cnp1/5ciprout.htm#REF38888> The equivalent Bay reference: <http://support.baynetworks.com/Library/tpubs/content/114065A/J_55.HTM#HEADING55-6> [A copy of the headers and the PGP signature follow.] Date: Tue, 11 Feb 1997 14:23:20 -0600 From: "Jeffrey C. Ollie" <jeff@ollie.clive.ia.us> In-reply-to: Your message of "Tue, 11 Feb 1997 22:04:19 +0300." <Pine.SUN.3.91.970211213356.1420T-100000@virgin> Subject: Re: [NANOG] RFC1918 conformance To: nanog@merit.edu -----BEGIN PGP SIGNATURE----- Version: 2.6.2 Comment: AnySign 1.4 - A Python tool for PGP signing e-mail and news. iQCVAwUBMwDVPZwkOQz8sbZFAQEXugP/csBBgGpX2pDm14HDL3RJAmzQIbqgQ+Tu cxTNolAGpgUIXTx1zJEUqfIREZ9CnTe2BBdbD1BNpn8Ns/m9iY7yKtbNzHWOS2yR dGkwhRrnXefjh3KPt/iGFVfwndpzYEzjZIpIUAfslfujY03bPXQe0YgTRt68q34S 13cWSHT1C3I= =wM5u -----END PGP SIGNATURE----- -- Jeffrey C. Ollie | Should Work Now (TM) Python Hacker, Mac Lover |
For example. I have a lot of CISCO routers with OSPF protocol. Thnis crazy IOS use highest loopback interface address as router-ID address; I use loopbacks to install load balancing etc. and I can't prevent loopbacks from being equal on the different routers. That's why I hardly need some IP addresses for 'Loopback 98' interface to use it as router-ID; and this have to be higher than any user's addresses. I use 233.255.254.0/24 for this purposes, but it's not reserved address.
This is one, simple, example why it's nessesary to reserve some short address space in the begin and in the end of total addresses.
No, that's an example of a poorly designed protocol implementation. One ought to be able to specify an arbitrary router id for OSPF (heh - even Bay routers can do that :) rather that relying on such an odd algorithm. I was so surprised by this that I just had to go look it up: I know _it's example of poorly designet software_. But I'd like to note it's not only example when it's usefull to have some addresses _greater than any other_ for private usage.
<http://www.cisco.com/univercd/data/doc/software/11_2/cnp1/5ciprout.htm#REF38888>
The equivalent Bay reference:
<http://support.baynetworks.com/Library/tpubs/content/114065A/J_55.HTM#HEADING55-6>
Yes, I was more surprised when they (cisco) did not implement something like _ip ospf router-id A.B.C.D_ into new IOS 11.2. We have 3 or 4 routing troubles due to this IOS property (and it always looked as _hidden bug_ because it is si,ular to the delayed bomb - it explodes 1 week below some mistake was made in the config files -:)).
Gated allows you to specify the ospf router id. AS others have mentioned so does Bay. Out of curiousity, is anyone running anything other than Cisco, Bay or something with GateD (which includes IBM 6611, Netstat Gigarouter and a few others which escape recall at the moment) for routing in the Internet (not private nets; I know that Mitsubishi Electric Corp of America uses IBM 6611 and some 2210, all with backlevel software). Dana On Wed, 12 Feb 1997, Alex P. Rudnev wrote:
Date: Wed, 12 Feb 1997 13:58:30 +0300 (MSK) From: "Alex P. Rudnev" <alex@Relcom.EU.net> To: "Jeffrey C. Ollie" <jeff@ollie.clive.ia.us> Cc: nanog@merit.edu Subject: Re: [NANOG] RFC1918 conformance
For example. I have a lot of CISCO routers with OSPF protocol. Thnis crazy IOS use highest loopback interface address as router-ID address; I use loopbacks to install load balancing etc. and I can't prevent loopbacks from being equal on the different routers. That's why I hardly need some IP addresses for 'Loopback 98' interface to use it as router-ID; and this have to be higher than any user's addresses. I use 233.255.254.0/24 for this purposes, but it's not reserved address.
This is one, simple, example why it's nessesary to reserve some short address space in the begin and in the end of total addresses.
No, that's an example of a poorly designed protocol implementation. One ought to be able to specify an arbitrary router id for OSPF (heh - even Bay routers can do that :) rather that relying on such an odd algorithm. I was so surprised by this that I just had to go look it up: I know _it's example of poorly designet software_. But I'd like to note it's not only example when it's usefull to have some addresses _greater than any other_ for private usage.
<http://www.cisco.com/univercd/data/doc/software/11_2/cnp1/5ciprout.htm#REF38888>
The equivalent Bay reference:
<http://support.baynetworks.com/Library/tpubs/content/114065A/J_55.HTM#HEADING55-6>
Yes, I was more surprised when they (cisco) did not implement something like _ip ospf router-id A.B.C.D_ into new IOS 11.2. We have 3 or 4 routing troubles due to this IOS property (and it always looked as _hidden bug_ because it is si,ular to the delayed bomb - it explodes 1 week below some mistake was made in the config files -:)).
Gated allows you to specify the ospf router id. AS others have mentioned so does Bay. Out of curiousity, is anyone running anything other than I know it well (really we have few gated-based routers there). Let me to
On Wed, 12 Feb 1997, Dana Hudes wrote: point my mind - it may be usefull to have short reserved address space in the beginning (net 1.0.0.0) and the end (223.255.0.0/16 or simular) address space. CISCO's router-id was used as amazing example _why it mey be usefull_.
Cisco, Bay or something with GateD (which includes IBM 6611, Netstat Gigarouter and a few others which escape recall at the moment) for routing in the Internet (not private nets; I know that Mitsubishi Electric Corp of America uses IBM 6611 and some 2210, all with backlevel software).
Dana
On Wed, 12 Feb 1997, Alex P. Rudnev wrote:
Date: Wed, 12 Feb 1997 13:58:30 +0300 (MSK) From: "Alex P. Rudnev" <alex@Relcom.EU.net> To: "Jeffrey C. Ollie" <jeff@ollie.clive.ia.us> Cc: nanog@merit.edu Subject: Re: [NANOG] RFC1918 conformance
For example. I have a lot of CISCO routers with OSPF protocol. Thnis crazy IOS use highest loopback interface address as router-ID address; I use loopbacks to install load balancing etc. and I can't prevent loopbacks from being equal on the different routers. That's why I hardly need some IP addresses for 'Loopback 98' interface to use it as router-ID; and this have to be higher than any user's addresses. I use 233.255.254.0/24 for this purposes, but it's not reserved address.
This is one, simple, example why it's nessesary to reserve some short address space in the begin and in the end of total addresses.
No, that's an example of a poorly designed protocol implementation. One ought to be able to specify an arbitrary router id for OSPF (heh - even Bay routers can do that :) rather that relying on such an odd algorithm. I was so surprised by this that I just had to go look it up: I know _it's example of poorly designet software_. But I'd like to note it's not only example when it's usefull to have some addresses _greater than any other_ for private usage.
<http://www.cisco.com/univercd/data/doc/software/11_2/cnp1/5ciprout.htm#REF38888>
The equivalent Bay reference:
<http://support.baynetworks.com/Library/tpubs/content/114065A/J_55.HTM#HEADING55-6>
Yes, I was more surprised when they (cisco) did not implement something like _ip ospf router-id A.B.C.D_ into new IOS 11.2. We have 3 or 4 routing troubles due to this IOS property (and it always looked as _hidden bug_ because it is si,ular to the delayed bomb - it explodes 1 week below some mistake was made in the config files -:)).
Aleksei Roudnev, Network Operations Center, Relcom, Moscow (+7 095) 194-19-95 (Network Operations Center Hot Line),(+7 095) 239-10-10, N 13729 (pager) (+7 095) 196-72-12 (Support), (+7 095) 194-33-28 (Fax)
-----BEGIN PGP SIGNED MESSAGE----- On Thu, 13 Feb 1997 13:47:24 +0300 (MSK), alex@relcom.eu.net writes:
On Wed, 12 Feb 1997, Dana Hudes wrote:
Gated allows you to specify the ospf router id. AS others have mentioned so does Bay. Out of curiousity, is anyone running anything other than
I know it well (really we have few gated-based routers there). Let me to point my mind - it may be usefull to have short reserved address space in the beginning (net 1.0.0.0) and the end (223.255.0.0/16 or simular) address space. CISCO's router-id was used as amazing example _why it mey be usefull_.
I don't think that Internet engineering decisions should be based solely on the basis of Cisco's bad decsisions regarding their OSPF implementation. You claim that there are other reasons why reserving 1.0.0.0/8 and 223.255.0.0/16 are a good idea. Can you share some of these reasons? I'm not totally against reserving these networks, but I do require more convincing. [A copy of the headers and the PGP signature follow.] Date: Thu, 13 Feb 1997 08:01:01 -0600 From: "Jeffrey C. Ollie" <jeff@ollie.clive.ia.us> In-reply-to: Your message of "Thu, 13 Feb 1997 13:47:24 +0300." <Pine.SUN.3.91.970213134530.11961d-100000@virgin> Subject: Re: RFC1918 conformance To: nanog@merit.edu -----BEGIN PGP SIGNATURE----- Version: 2.6.2 Comment: AnySign 1.4 - A Python tool for PGP signing e-mail and news. iQCVAwUBMwMeopwkOQz8sbZFAQE4gQP+N/jvy38bdxJlsqmiRhbfT9Nga6y5R57G opT5uzRpTa2B17ikDzYUEZgmjtXKcFTj6jCNXmcNoh3Be9g5SDFqZHvaiXUrvVwG Lcorm1iSN/x2HwXfkjKBxP7b2bAvjbCJinpIQp1cWU4BJymemwX+Bjwn7zMTtkl2 4b6oeADxi+A= =nUMC -----END PGP SIGNATURE----- -- Jeffrey C. Ollie | Should Work Now (TM) Python Hacker, Mac Lover |
Right now it checks for: >= 64/8 && <= 127/8 > 211/8 RFC1918 set of prefixes --Tony Andrew Partan <asp@partan.com> writes: * > This would be good as I report each week in my report possible bogus * > routes but no one seems to care to filter (or fix this). Today it says: * * Which routes to you consider to be bogons? * --asp@partan.com (Andrew Partan)
Hi, Pierre. These are the changes I have made in our sl-dc-10 router:
router bgp 1790 neighbor 144.228.120.130 remote-as 6846 neighbor 144.228.120.130 version 4 neighbor 144.228.120.130 distribute-list 50 in neighbor 144.228.120.130 distribute-list 111 out neighbor 144.228.120.130 route-map transit-in in neighbor 144.228.120.130 route-map transit-out out neighbor 144.228.120.130 filter-list 53 in
access-list 50 deny 10.0.0.0 0.255.255.255 access-list 50 deny 172.16.0.0 0.15.255.255 access-list 50 deny 192.168.0.0 0.0.255.255
clear ip bgp 144.228.120.130 soft out
Please let us know if there are any problems with this new configuration. Thank you. Ray, Sprintlink On Mon, 10 Feb 1997, Pierre Thibaudeau wrote:
As specified in RFC1918 (ftp://ds.internic.net/rfc/rfc1918.txt) the netblocks 10.0.0.0/16, 172.16.0.0/12 and 192.168.0.0/16 have been allocated for "Private Internets". Consequently, these netblocks should not be routed over the Internet.
As shown below, they are currently advertised from AS6848 and these advertisements are carried to us (AS6453) through various AS's of the SprintLink system.
sh ip bgp reg _6846$ BGP table version is 9335417, local router ID is 207.45.201.5 Status codes: s suppressed, d damped, h history, * valid, > best, i - internal Origin codes: i - IGP, e - EGP, ? - incomplete
Network Next Hop Metric LocPrf Weight Path *> 10.0.0.0 144.228.164.57 0 90 0 1794 1239 1790 6846 ? *> 172.16.0.0/12 144.228.164.57 0 90 0 1794 1239 1790 6846 ? *> 192.168.0.0/16 144.228.164.57 0 90 0 1794 1239 1790 6846 ? [...]
AS6846 responsibles should take immediate action to remove these announcements. SprintLink, as any conscientious operator, should take action to filter out these announcements from any of its peers.
Regards. __
Pierre Thibaudeau | e-mail: <prt@Teleglobe.CA> TELEGLOBE CANADA | 1000, rue de La Gauchetiere ouest | Tel: +1-514-868-7257 Montreal, QC H3B 4X5 | Canada | fax: +1-514-868-8446
Sorry, I forgot to include in the last email:
access-list 50 permit any
And I did a "clear ip bgp 144.228.120.130" without the "soft out". Thanks. Ray, Sprintlink On Mon, 10 Feb 1997 bgp4-adm@sprint.net wrote:
Hi, Pierre.
These are the changes I have made in our sl-dc-10 router:
router bgp 1790 neighbor 144.228.120.130 remote-as 6846 neighbor 144.228.120.130 version 4 neighbor 144.228.120.130 distribute-list 50 in neighbor 144.228.120.130 distribute-list 111 out neighbor 144.228.120.130 route-map transit-in in neighbor 144.228.120.130 route-map transit-out out neighbor 144.228.120.130 filter-list 53 in
access-list 50 deny 10.0.0.0 0.255.255.255 access-list 50 deny 172.16.0.0 0.15.255.255 access-list 50 deny 192.168.0.0 0.0.255.255
clear ip bgp 144.228.120.130 soft out
Please let us know if there are any problems with this new configuration. Thank you.
Ray, Sprintlink
On Mon, 10 Feb 1997, Pierre Thibaudeau wrote:
As specified in RFC1918 (ftp://ds.internic.net/rfc/rfc1918.txt) the netblocks 10.0.0.0/16, 172.16.0.0/12 and 192.168.0.0/16 have been allocated for "Private Internets". Consequently, these netblocks should not be routed over the Internet.
As shown below, they are currently advertised from AS6848 and these advertisements are carried to us (AS6453) through various AS's of the SprintLink system.
sh ip bgp reg _6846$ BGP table version is 9335417, local router ID is 207.45.201.5 Status codes: s suppressed, d damped, h history, * valid, > best, i - internal Origin codes: i - IGP, e - EGP, ? - incomplete
Network Next Hop Metric LocPrf Weight Path *> 10.0.0.0 144.228.164.57 0 90 0 1794 1239 1790 6846 ? *> 172.16.0.0/12 144.228.164.57 0 90 0 1794 1239 1790 6846 ? *> 192.168.0.0/16 144.228.164.57 0 90 0 1794 1239 1790 6846 ? [...]
AS6846 responsibles should take immediate action to remove these announcements. SprintLink, as any conscientious operator, should take action to filter out these announcements from any of its peers.
Regards. __
Pierre Thibaudeau | e-mail: <prt@Teleglobe.CA> TELEGLOBE CANADA | 1000, rue de La Gauchetiere ouest | Tel: +1-514-868-7257 Montreal, QC H3B 4X5 | Canada | fax: +1-514-868-8446
participants (8)
-
Alex P. Rudnev -
Andrew Partan -
bgp4-adm＠sprint.net -
bmanning＠ISI.EDU -
Dana Hudes -
Jeffrey C. Ollie -
Pierre Thibaudeau -
Tony Bates