Re: rfc1918 ignorant (fwd)
On Wed, 23 Jul 2003, Haesu wrote: Well, if uBR showing RFC1918 address out on the traceroute is an issue, why not just reverse the way its configured? Put RFC1918 as secondary, and put the routable addr as primary. Either way, it should work w/o issues, right? Hmm this could affect routing protocols which use the primary address.. I know quite a few people who purposely put a non-routable IP (whether it be 1918 or RIR-registered block) as primary on their interface, and use routable IP as secondary. Their reason for doing this is to somewhat hide their router's real interface IP from showing up in traceroute.. Well, it wouldn't completely 'hide' it, but to a certain level of degree, it probably does... Right but this one benefit doesnt make right the wrongs! I guess one thing you could do (if you really wanted to implement hacks) is to use the rfc1918 space on your routers and then nat them to a global ip at your borders.. achieves all your goals anyhow (not that i'd recommend it ;)
RE: rfc1918 ignorant
Interesting. Did any of you note last month or so that Sprint US came out with a notice that they are no longer going to router /30 ptp subnets unless the customer specifically asks for it? Could that be why 10.x.y.z is showing up here? Sprint??? you out there? -Original Message- From: Haesu [mailto:[EMAIL PROTECTED] Sent: Wednesday, July 23, 2003 12:53 PM To: Vinny Abello; [EMAIL PROTECTED] Subject: Re: rfc1918 ignorant Heh, check this out. traceroute to 219.168.64.121 (219.168.64.121), 64 hops max, 44 byte packets 1 216.93.161.1 (216.93.161.1) 0.532 ms 0.518 ms 0.405 ms 2 66.7.159.33 (66.7.159.33) 0.796 ms 0.667 ms 0.543 ms 3 gigabitethernet8-0-513.ipcolo1.SanFrancisco1.Level3.net (63.211.150.225) 0.541 ms 0.478 ms 0.834 ms 4 gigabitethernet4-1.core1.SanFrancisco1.Level3.net (209.244.14.197) 0.547 ms 0.486 ms 0.530 ms 5 so-4-0-0.mp2.SanFrancisco1.Level3.net (209.247.10.233) 0.741 ms 0.729 ms 0.731 ms 6 so-2-0-0.mp2.SanJose1.Level3.net (64.159.0.218) 1.677 ms 1.510 ms 1.549 ms 7 unknown.Level3.net (64.159.2.102) 1.864 ms 1.851 ms 1.875 ms 8 sl-bb20-sj.sprintlink.net (209.245.146.142) 3.110 ms 3.831 ms 3.321 ms 9 sl-bb22-sj-14-0.sprintlink.net (144.232.3.165) 7.127 ms 3.290 ms 3.331 ms 10 sl-bb20-tok-13-1.sprintlink.net (144.232.20.188) 113.739 ms 113.731 ms 113.874 ms 11 sl-gw10-tok-15-0.sprintlink.net (203.222.36.42) 114.400 ms 114.051 ms 114.067 ms 12 sla-bbtech-2-0.sprintlink.net (203.222.37.106) 114.207 ms 114.295 ms 114.340 ms 13 10.9.17.10 (10.9.17.10) 101.595 ms 101.580 ms 101.771 ms 14 10.0.13.2 (10.0.13.2) 119.025 ms 118.765 ms 118.833 ms 15 10.4.10.2 (10.4.10.2) 134.809 ms 134.536 ms 134.668 ms 16 10.3.10.130 (10.3.10.130) 134.526 ms 135.004 ms 135.701 ms 17 10.10.0.25 (10.10.0.25) 135.291 ms 134.899 ms 135.293 ms 18 10.10.0.3 (10.10.0.3) 122.515 ms 122.210 ms 121.779 ms 19 10.10.0.11 (10.10.0.11) 135.643 ms 135.144 ms 135.438 ms 20 10.10.3.4 (10.10.3.4) 121.721 ms 121.872 ms 122.603 ms 21 10.10.3.36 (10.10.3.36) 135.069 ms 134.956 ms 135.330 ms 22 10.10.3.107 (10.10.3.107) 121.906 ms 122.708 ms 122.076 ms 23 YahooBB219168064121.bbtec.net (219.168.64.121) 147.137 ms 146.039 ms 147.453 ms -hc -- Sincerely, Haesu C. TowardEX Technologies, Inc. WWW: http://www.towardex.com E-mail: [EMAIL PROTECTED] Cell: (978) 394-2867 On Wed, Jul 23, 2003 at 09:07:51AM -0400, Vinny Abello wrote: Heh... Check out Comcast. A large part of their network uses rfc1918: 216 ms 9 ms10 ms 10.110.168.1 315 ms10 ms11 ms 172.30.116.17 410 ms13 ms10 ms 172.30.116.50 514 ms12 ms26 ms 172.30.112.123 610 ms14 ms23 ms 172.30.110.105 At 08:48 AM 7/23/2003, you wrote: Is there a site to report networks/isps that still leak rfc1918 space? By leaking I not only mean don't filter, but actually _use_ in their network? If someone is keeping a list, feel free to add ServerBeach.com. All traceroutes to servers housed there, pass by 10.10.10.3. traceroute to www.serverbeach.com ... 20. 64-132-228-70.gen.twtelecom.net 21. 10.10.10.3 22. 66.139.72.12 Kind Regards, Frank Louwers -- Openminds bvbawww.openminds.be Tweebruggenstraat 16 - 9000 Gent - Belgium Vinny Abello Network Engineer Server Management [EMAIL PROTECTED] (973)300-9211 x 125 (973)940-6125 (Direct) PGP Key Fingerprint: 3BC5 9A48 FC78 03D3 82E0 E935 5325 FBCB 0100 977A Tellurian Networks - The Ultimate Internet Connection http://www.tellurian.com (888)TELLURIAN There are 10 kinds of people in the world. Those who understand binary and those that don't.
RE: rfc1918 ignorant
According to the notice they send me on 7/1, this isn't supposed to take effect until Aug 17th or 18th for existing customers, and they didn't mention an option to specifically request that they not do this. However, there was a link: http://www.sprint.net/faq/serialip.html That explains that you can keep using your ptp IP if you request it, but in either case, they will no longer route their end of the IP. On Thu, 24 Jul 2003, McBurnett, Jim wrote: Interesting. Did any of you note last month or so that Sprint US came out with a notice that they are no longer going to router /30 ptp subnets unless the customer specifically asks for it? Could that be why 10.x.y.z is showing up here? Sprint??? you out there? -Original Message- From: Haesu [mailto:[EMAIL PROTECTED] Sent: Wednesday, July 23, 2003 12:53 PM To: Vinny Abello; [EMAIL PROTECTED] Subject: Re: rfc1918 ignorant Heh, check this out. traceroute to 219.168.64.121 (219.168.64.121), 64 hops max, 44 byte packets 1 216.93.161.1 (216.93.161.1) 0.532 ms 0.518 ms 0.405 ms 2 66.7.159.33 (66.7.159.33) 0.796 ms 0.667 ms 0.543 ms 3 gigabitethernet8-0-513.ipcolo1.SanFrancisco1.Level3.net (63.211.150.225) 0.541 ms 0.478 ms 0.834 ms 4 gigabitethernet4-1.core1.SanFrancisco1.Level3.net (209.244.14.197) 0.547 ms 0.486 ms 0.530 ms 5 so-4-0-0.mp2.SanFrancisco1.Level3.net (209.247.10.233) 0.741 ms 0.729 ms 0.731 ms 6 so-2-0-0.mp2.SanJose1.Level3.net (64.159.0.218) 1.677 ms 1.510 ms 1.549 ms 7 unknown.Level3.net (64.159.2.102) 1.864 ms 1.851 ms 1.875 ms 8 sl-bb20-sj.sprintlink.net (209.245.146.142) 3.110 ms 3.831 ms 3.321 ms 9 sl-bb22-sj-14-0.sprintlink.net (144.232.3.165) 7.127 ms 3.290 ms 3.331 ms 10 sl-bb20-tok-13-1.sprintlink.net (144.232.20.188) 113.739 ms 113.731 ms 113.874 ms 11 sl-gw10-tok-15-0.sprintlink.net (203.222.36.42) 114.400 ms 114.051 ms 114.067 ms 12 sla-bbtech-2-0.sprintlink.net (203.222.37.106) 114.207 ms 114.295 ms 114.340 ms 13 10.9.17.10 (10.9.17.10) 101.595 ms 101.580 ms 101.771 ms 14 10.0.13.2 (10.0.13.2) 119.025 ms 118.765 ms 118.833 ms 15 10.4.10.2 (10.4.10.2) 134.809 ms 134.536 ms 134.668 ms 16 10.3.10.130 (10.3.10.130) 134.526 ms 135.004 ms 135.701 ms 17 10.10.0.25 (10.10.0.25) 135.291 ms 134.899 ms 135.293 ms 18 10.10.0.3 (10.10.0.3) 122.515 ms 122.210 ms 121.779 ms 19 10.10.0.11 (10.10.0.11) 135.643 ms 135.144 ms 135.438 ms 20 10.10.3.4 (10.10.3.4) 121.721 ms 121.872 ms 122.603 ms 21 10.10.3.36 (10.10.3.36) 135.069 ms 134.956 ms 135.330 ms 22 10.10.3.107 (10.10.3.107) 121.906 ms 122.708 ms 122.076 ms 23 YahooBB219168064121.bbtec.net (219.168.64.121) 147.137 ms 146.039 ms 147.453 ms -hc -- Sincerely, Haesu C. TowardEX Technologies, Inc. WWW: http://www.towardex.com E-mail: [EMAIL PROTECTED] Cell: (978) 394-2867 On Wed, Jul 23, 2003 at 09:07:51AM -0400, Vinny Abello wrote: Heh... Check out Comcast. A large part of their network uses rfc1918: 216 ms 9 ms10 ms 10.110.168.1 315 ms10 ms11 ms 172.30.116.17 410 ms13 ms10 ms 172.30.116.50 514 ms12 ms26 ms 172.30.112.123 610 ms14 ms23 ms 172.30.110.105 At 08:48 AM 7/23/2003, you wrote: Is there a site to report networks/isps that still leak rfc1918 space? By leaking I not only mean don't filter, but actually _use_ in their network? If someone is keeping a list, feel free to add ServerBeach.com. All traceroutes to servers housed there, pass by 10.10.10.3. traceroute to www.serverbeach.com ... 20. 64-132-228-70.gen.twtelecom.net 21. 10.10.10.3 22. 66.139.72.12 Kind Regards, Frank Louwers -- Openminds bvbawww.openminds.be Tweebruggenstraat 16 - 9000 Gent - Belgium Vinny Abello Network Engineer Server Management [EMAIL PROTECTED] (973)300-9211 x 125 (973)940-6125 (Direct) PGP Key Fingerprint: 3BC5 9A48 FC78 03D3 82E0 E935 5325 FBCB 0100 977A Tellurian Networks - The Ultimate Internet Connection http://www.tellurian.com (888)TELLURIAN There are 10 kinds of people in the world. Those who understand binary and those that don't. James Smallacombe PlantageNet, Inc. CEO and Janitor [EMAIL PROTECTED] http://3.am =
Re: source filtering (Re: rfc1918 ignorant)
On Wed, 23 Jul 2003, Jared Mauch wrote: I think you'll see more and more networks slowly over time move closer to bcp38. Is there anywhere that this is recorded? It would be interesting to see what the actual state of play on implementation of BCP38 was. I believe that ATT is the only tier-1 provider that is in full compliance with this. We've asked other tier-1's about BCP38 and were completely underwhelmed by the response. If you believe in the BCPs then I guess you just have to vote with your feet and try to use transit providers which comply with them. We've been trying to get transit from ATT in London for a while now, but they're obviously spending all their efforts on blocking RFC1918 traffic rather than talking to prospective customers. :-S Rich
RE: rfc1918 ignorant
I have a friend who is in SprintLink as a customer and he has VPN routers that this would take down... He called and they will route it.. Also, I got an offlist reply from a network services tech, and he said they would route if a customer requests it. J -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Thursday, July 24, 2003 8:44 AM To: [EMAIL PROTECTED] Subject: RE: rfc1918 ignorant According to the notice they send me on 7/1, this isn't supposed to take effect until Aug 17th or 18th for existing customers, and they didn't mention an option to specifically request that they not do this. However, there was a link: http://www.sprint.net/faq/serialip.html That explains that you can keep using your ptp IP if you request it, but in either case, they will no longer route their end of the IP. On Thu, 24 Jul 2003, McBurnett, Jim wrote: Interesting. Did any of you note last month or so that Sprint US came out with a notice that they are no longer going to router /30 ptp subnets unless the customer specifically asks for it? Could that be why 10.x.y.z is showing up here? Sprint??? you out there? -Original Message- From: Haesu [mailto:[EMAIL PROTECTED] Sent: Wednesday, July 23, 2003 12:53 PM To: Vinny Abello; [EMAIL PROTECTED] Subject: Re: rfc1918 ignorant Heh, check this out. traceroute to 219.168.64.121 (219.168.64.121), 64 hops max, 44 byte packets 1 216.93.161.1 (216.93.161.1) 0.532 ms 0.518 ms 0.405 ms 2 66.7.159.33 (66.7.159.33) 0.796 ms 0.667 ms 0.543 ms 3 gigabitethernet8-0-513.ipcolo1.SanFrancisco1.Level3.net (63.211.150.225) 0.541 ms 0.478 ms 0.834 ms 4 gigabitethernet4-1.core1.SanFrancisco1.Level3.net (209.244.14.197) 0.547 ms 0.486 ms 0.530 ms 5 so-4-0-0.mp2.SanFrancisco1.Level3.net (209.247.10.233) 0.741 ms 0.729 ms 0.731 ms 6 so-2-0-0.mp2.SanJose1.Level3.net (64.159.0.218) 1.677 ms 1.510 ms 1.549 ms 7 unknown.Level3.net (64.159.2.102) 1.864 ms 1.851 ms 1.875 ms 8 sl-bb20-sj.sprintlink.net (209.245.146.142) 3.110 ms 3.831 ms 3.321 ms 9 sl-bb22-sj-14-0.sprintlink.net (144.232.3.165) 7.127 ms 3.290 ms 3.331 ms 10 sl-bb20-tok-13-1.sprintlink.net (144.232.20.188) 113.739 ms 113.731 ms 113.874 ms 11 sl-gw10-tok-15-0.sprintlink.net (203.222.36.42) 114.400 ms 114.051 ms 114.067 ms 12 sla-bbtech-2-0.sprintlink.net (203.222.37.106) 114.207 ms 114.295 ms 114.340 ms 13 10.9.17.10 (10.9.17.10) 101.595 ms 101.580 ms 101.771 ms 14 10.0.13.2 (10.0.13.2) 119.025 ms 118.765 ms 118.833 ms 15 10.4.10.2 (10.4.10.2) 134.809 ms 134.536 ms 134.668 ms 16 10.3.10.130 (10.3.10.130) 134.526 ms 135.004 ms 135.701 ms 17 10.10.0.25 (10.10.0.25) 135.291 ms 134.899 ms 135.293 ms 18 10.10.0.3 (10.10.0.3) 122.515 ms 122.210 ms 121.779 ms 19 10.10.0.11 (10.10.0.11) 135.643 ms 135.144 ms 135.438 ms 20 10.10.3.4 (10.10.3.4) 121.721 ms 121.872 ms 122.603 ms 21 10.10.3.36 (10.10.3.36) 135.069 ms 134.956 ms 135.330 ms 22 10.10.3.107 (10.10.3.107) 121.906 ms 122.708 ms 122.076 ms 23 YahooBB219168064121.bbtec.net (219.168.64.121) 147.137 ms 146.039 ms 147.453 ms -hc -- Sincerely, Haesu C. TowardEX Technologies, Inc. WWW: http://www.towardex.com E-mail: [EMAIL PROTECTED] Cell: (978) 394-2867 On Wed, Jul 23, 2003 at 09:07:51AM -0400, Vinny Abello wrote: Heh... Check out Comcast. A large part of their network uses rfc1918: 216 ms 9 ms10 ms 10.110.168.1 315 ms10 ms11 ms 172.30.116.17 410 ms13 ms10 ms 172.30.116.50 514 ms12 ms26 ms 172.30.112.123 610 ms14 ms23 ms 172.30.110.105 At 08:48 AM 7/23/2003, you wrote: Is there a site to report networks/isps that still leak rfc1918 space? By leaking I not only mean don't filter, but actually _use_ in their network? If someone is keeping a list, feel free to add ServerBeach.com. All traceroutes to servers housed there, pass by 10.10.10.3. traceroute to www.serverbeach.com ... 20. 64-132-228-70.gen.twtelecom.net 21. 10.10.10.3 22. 66.139.72.12 Kind Regards, Frank Louwers -- Openminds bvbawww.openminds.be Tweebruggenstraat 16 - 9000 Gent - Belgium Vinny Abello Network Engineer Server Management [EMAIL PROTECTED] (973)300-9211 x 125 (973)940-6125 (Direct) PGP Key Fingerprint: 3BC5 9A48 FC78 03D3 82E0 E935 5325 FBCB 0100 977A Tellurian Networks - The Ultimate Internet Connection http://www.tellurian.com (888)TELLURIAN There are 10 kinds of people in the world. Those who understand binary and those that don't. James Smallacombe PlantageNet, Inc. CEO and Janitor [EMAIL PROTECTED] http://3.am =
Re: rfc1918 ignorant
By the way, doesn´t this break PMTU if the far end device has tunnels or such which have lower MTU than on the p2p link? (because the packets would be dropped by loose RPF external to sprintlink) Pete - Original Message - From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, July 24, 2003 3:44 PM Subject: RE: rfc1918 ignorant According to the notice they send me on 7/1, this isn't supposed to take effect until Aug 17th or 18th for existing customers, and they didn't mention an option to specifically request that they not do this. However, there was a link: http://www.sprint.net/faq/serialip.html That explains that you can keep using your ptp IP if you request it, but in either case, they will no longer route their end of the IP. On Thu, 24 Jul 2003, McBurnett, Jim wrote: Interesting. Did any of you note last month or so that Sprint US came out with a notice that they are no longer going to router /30 ptp subnets unless the customer specifically asks for it? Could that be why 10.x.y.z is showing up here? Sprint??? you out there? -Original Message- From: Haesu [mailto:[EMAIL PROTECTED] Sent: Wednesday, July 23, 2003 12:53 PM To: Vinny Abello; [EMAIL PROTECTED] Subject: Re: rfc1918 ignorant Heh, check this out. traceroute to 219.168.64.121 (219.168.64.121), 64 hops max, 44 byte packets 1 216.93.161.1 (216.93.161.1) 0.532 ms 0.518 ms 0.405 ms 2 66.7.159.33 (66.7.159.33) 0.796 ms 0.667 ms 0.543 ms 3 gigabitethernet8-0-513.ipcolo1.SanFrancisco1.Level3.net (63.211.150.225) 0.541 ms 0.478 ms 0.834 ms 4 gigabitethernet4-1.core1.SanFrancisco1.Level3.net (209.244.14.197) 0.547 ms 0.486 ms 0.530 ms 5 so-4-0-0.mp2.SanFrancisco1.Level3.net (209.247.10.233) 0.741 ms 0.729 ms 0.731 ms 6 so-2-0-0.mp2.SanJose1.Level3.net (64.159.0.218) 1.677 ms 1.510 ms 1.549 ms 7 unknown.Level3.net (64.159.2.102) 1.864 ms 1.851 ms 1.875 ms 8 sl-bb20-sj.sprintlink.net (209.245.146.142) 3.110 ms 3.831 ms 3.321 ms 9 sl-bb22-sj-14-0.sprintlink.net (144.232.3.165) 7.127 ms 3.290 ms 3.331 ms 10 sl-bb20-tok-13-1.sprintlink.net (144.232.20.188) 113.739 ms 113.731 ms 113.874 ms 11 sl-gw10-tok-15-0.sprintlink.net (203.222.36.42) 114.400 ms 114.051 ms 114.067 ms 12 sla-bbtech-2-0.sprintlink.net (203.222.37.106) 114.207 ms 114.295 ms 114.340 ms 13 10.9.17.10 (10.9.17.10) 101.595 ms 101.580 ms 101.771 ms 14 10.0.13.2 (10.0.13.2) 119.025 ms 118.765 ms 118.833 ms 15 10.4.10.2 (10.4.10.2) 134.809 ms 134.536 ms 134.668 ms 16 10.3.10.130 (10.3.10.130) 134.526 ms 135.004 ms 135.701 ms 17 10.10.0.25 (10.10.0.25) 135.291 ms 134.899 ms 135.293 ms 18 10.10.0.3 (10.10.0.3) 122.515 ms 122.210 ms 121.779 ms 19 10.10.0.11 (10.10.0.11) 135.643 ms 135.144 ms 135.438 ms 20 10.10.3.4 (10.10.3.4) 121.721 ms 121.872 ms 122.603 ms 21 10.10.3.36 (10.10.3.36) 135.069 ms 134.956 ms 135.330 ms 22 10.10.3.107 (10.10.3.107) 121.906 ms 122.708 ms 122.076 ms 23 YahooBB219168064121.bbtec.net (219.168.64.121) 147.137 ms 146.039 ms 147.453 ms -hc -- Sincerely, Haesu C. TowardEX Technologies, Inc. WWW: http://www.towardex.com E-mail: [EMAIL PROTECTED] Cell: (978) 394-2867 On Wed, Jul 23, 2003 at 09:07:51AM -0400, Vinny Abello wrote: Heh... Check out Comcast. A large part of their network uses rfc1918: 216 ms 9 ms10 ms 10.110.168.1 315 ms10 ms11 ms 172.30.116.17 410 ms13 ms10 ms 172.30.116.50 514 ms12 ms26 ms 172.30.112.123 610 ms14 ms23 ms 172.30.110.105 At 08:48 AM 7/23/2003, you wrote: Is there a site to report networks/isps that still leak rfc1918 space? By leaking I not only mean don't filter, but actually _use_ in their network? If someone is keeping a list, feel free to add ServerBeach.com. All traceroutes to servers housed there, pass by 10.10.10.3. traceroute to www.serverbeach.com ... 20. 64-132-228-70.gen.twtelecom.net 21. 10.10.10.3 22. 66.139.72.12 Kind Regards, Frank Louwers -- Openminds bvbawww.openminds.be Tweebruggenstraat 16 - 9000 Gent - Belgium Vinny Abello Network Engineer Server Management [EMAIL PROTECTED] (973)300-9211 x 125 (973)940-6125 (Direct) PGP Key Fingerprint: 3BC5 9A48 FC78 03D3 82E0 E935 5325 FBCB 0100 977A Tellurian Networks - The Ultimate Internet Connection http://www.tellurian.com (888)TELLURIAN There are 10 kinds of people in the world. Those who understand binary and those that don't. James Smallacombe PlantageNet, Inc. CEO and Janitor [EMAIL PROTECTED] http://3.am =
Re: rfc1918 ignorant (fwd)
Hmm this could affect routing protocols which use the primary address.. I haven't tried doing that with igp protocols.. But with BGP, it works does manage to bind itself to the working address. (Or if you are sourcing update to loopback, that would be fine too) Right but this one benefit doesnt make right the wrongs! I guess one thing you could do (if you really wanted to implement hacks) is to use the rfc1918 space on your routers and then nat them to a global ip at your borders.. achieves all your goals anyhow (not that i'd recommend it ;) The thing is... some people want to hide the IP of the interface that faces their transit on the border router, as most /30 demarcation subnet is assigned from the transit. And since they would run either bgp or static route between the transit and their border router, it shouldn't break routing.. -hc -- Sincerely, Haesu C. TowardEX Technologies, Inc. WWW: http://www.towardex.com E-mail: [EMAIL PROTECTED] Cell: (978) 394-2867
Re: rfc1918 ignorant
Interesting. Did any of you note last month or so that Sprint US came out with a notice that they are no longer going to router /30 ptp subnets unless the customer specifically asks for it? Could that be why 10.x.y.z is showing up here? No. :) 12 sla-bbtech-2-0.sprintlink.net (203.222.37.106) 114.207 ms 114.295 ms 114.340 ms In this example, bbtech (the one shown in example traceroute below) uses 1918 as transit space on their network. Looks cute though with so many 1918 hops (heh, not that i recommend it!) -hc -- Sincerely, Haesu C. TowardEX Technologies, Inc. WWW: http://www.towardex.com E-mail: [EMAIL PROTECTED] Cell: (978) 394-2867 Sprint??? you out there? -Original Message- From: Haesu [mailto:[EMAIL PROTECTED] Sent: Wednesday, July 23, 2003 12:53 PM To: Vinny Abello; [EMAIL PROTECTED] Subject: Re: rfc1918 ignorant Heh, check this out. traceroute to 219.168.64.121 (219.168.64.121), 64 hops max, 44 byte packets 1 216.93.161.1 (216.93.161.1) 0.532 ms 0.518 ms 0.405 ms 2 66.7.159.33 (66.7.159.33) 0.796 ms 0.667 ms 0.543 ms 3 gigabitethernet8-0-513.ipcolo1.SanFrancisco1.Level3.net (63.211.150.225) 0.541 ms 0.478 ms 0.834 ms 4 gigabitethernet4-1.core1.SanFrancisco1.Level3.net (209.244.14.197) 0.547 ms 0.486 ms 0.530 ms 5 so-4-0-0.mp2.SanFrancisco1.Level3.net (209.247.10.233) 0.741 ms 0.729 ms 0.731 ms 6 so-2-0-0.mp2.SanJose1.Level3.net (64.159.0.218) 1.677 ms 1.510 ms 1.549 ms 7 unknown.Level3.net (64.159.2.102) 1.864 ms 1.851 ms 1.875 ms 8 sl-bb20-sj.sprintlink.net (209.245.146.142) 3.110 ms 3.831 ms 3.321 ms 9 sl-bb22-sj-14-0.sprintlink.net (144.232.3.165) 7.127 ms 3.290 ms 3.331 ms 10 sl-bb20-tok-13-1.sprintlink.net (144.232.20.188) 113.739 ms 113.731 ms 113.874 ms 11 sl-gw10-tok-15-0.sprintlink.net (203.222.36.42) 114.400 ms 114.051 ms 114.067 ms 12 sla-bbtech-2-0.sprintlink.net (203.222.37.106) 114.207 ms 114.295 ms 114.340 ms 13 10.9.17.10 (10.9.17.10) 101.595 ms 101.580 ms 101.771 ms 14 10.0.13.2 (10.0.13.2) 119.025 ms 118.765 ms 118.833 ms 15 10.4.10.2 (10.4.10.2) 134.809 ms 134.536 ms 134.668 ms 16 10.3.10.130 (10.3.10.130) 134.526 ms 135.004 ms 135.701 ms 17 10.10.0.25 (10.10.0.25) 135.291 ms 134.899 ms 135.293 ms 18 10.10.0.3 (10.10.0.3) 122.515 ms 122.210 ms 121.779 ms 19 10.10.0.11 (10.10.0.11) 135.643 ms 135.144 ms 135.438 ms 20 10.10.3.4 (10.10.3.4) 121.721 ms 121.872 ms 122.603 ms 21 10.10.3.36 (10.10.3.36) 135.069 ms 134.956 ms 135.330 ms 22 10.10.3.107 (10.10.3.107) 121.906 ms 122.708 ms 122.076 ms 23 YahooBB219168064121.bbtec.net (219.168.64.121) 147.137 ms 146.039 ms 147.453 ms -hc -- Sincerely, Haesu C. TowardEX Technologies, Inc. WWW: http://www.towardex.com E-mail: [EMAIL PROTECTED] Cell: (978) 394-2867 On Wed, Jul 23, 2003 at 09:07:51AM -0400, Vinny Abello wrote: Heh... Check out Comcast. A large part of their network uses rfc1918: 216 ms 9 ms10 ms 10.110.168.1 315 ms10 ms11 ms 172.30.116.17 410 ms13 ms10 ms 172.30.116.50 514 ms12 ms26 ms 172.30.112.123 610 ms14 ms23 ms 172.30.110.105 At 08:48 AM 7/23/2003, you wrote: Is there a site to report networks/isps that still leak rfc1918 space? By leaking I not only mean don't filter, but actually _use_ in their network? If someone is keeping a list, feel free to add ServerBeach.com. All traceroutes to servers housed there, pass by 10.10.10.3. traceroute to www.serverbeach.com ... 20. 64-132-228-70.gen.twtelecom.net 21. 10.10.10.3 22. 66.139.72.12 Kind Regards, Frank Louwers -- Openminds bvbawww.openminds.be Tweebruggenstraat 16 - 9000 Gent - Belgium Vinny Abello Network Engineer Server Management [EMAIL PROTECTED] (973)300-9211 x 125 (973)940-6125 (Direct) PGP Key Fingerprint: 3BC5 9A48 FC78 03D3 82E0 E935 5325 FBCB 0100 977A Tellurian Networks - The Ultimate Internet Connection http://www.tellurian.com (888)TELLURIAN There are 10 kinds of people in the world. Those who understand binary and those that don't.
Re: source filtering (Re: rfc1918 ignorant)
On Thu, Jul 24, 2003 at 01:44:33PM +0100, [EMAIL PROTECTED] wrote: On Wed, 23 Jul 2003, Jared Mauch wrote: I think you'll see more and more networks slowly over time move closer to bcp38. Is there anywhere that this is recorded? It would be interesting to see what the actual state of play on implementation of BCP38 was. I can speak about the networks that I operate with regards to this: AS2914 performs source filtering on a significant number of our customers. This coverage is not 100%, and sometimes is only the 'loose' rpf check, but there are a significant number of customers that have the strict rpf check that was enabled some time ago without any problems (we watched counters for drops, and looked at the packets that were dropped to determine if there was some asymetrical routing going on). It was shocking how many t1 customers that had a /28 or similar routed to them were spoofing address space outside of the continent. I am personally trying to insure that our IPv6 infrastructure begins with filtering in place instead of adding it on later as an afterthought. I believe that ATT is the only tier-1 provider that is in full compliance with this. We've asked other tier-1's about BCP38 and were completely underwhelmed by the response. If you believe in the BCPs then I guess you just have to vote with your feet and try to use transit providers which comply with them. Well, i'm sure that some providers face the challenges that some of the older router hardware can't do linerate filtering for unicast-rpf. It's sometimes dificult to get this stuff out of the network as managment wants to extend the lifetime of working hardware as long as possible to reduce capital expendetures. network security vs budgets.. /sigh. - jared -- Jared Mauch | pgp key available via finger from [EMAIL PROTECTED] clue++; | http://puck.nether.net/~jared/ My statements are only mine.
RE: rfc1918 ignorant (fwd)
Unfortunately, the vast majority of Cable modems use the private (CM or Docsis) MAC address for management and present the primary (CPE) MAC address to attached equipment. E.G.- a cable provider has two DHCP scopes configured- a.b.c.d (RFC 1918) and w.x.y.z (Public Space). In Cisco land at least, the CMTS is configured with cable-helper which relays the CM MAC address to the DHCP server from the primary address of the Cable Interface and the CPE MAC Address is relayed from the secondary address of the Cable Interface. The CM interface is used for management of the system and such- a key example is to transfer the DOCSIS configuration file which does things such as setting rate limits, QoS parameters and lots of other parameters dreamt up by cable-labs. The utility of this design is something I will choose to avoid commenting on at this time. --D -- -- Darren Bolding -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Haesu Sent: Wednesday, July 23, 2003 5:10 PM To: [EMAIL PROTECTED] Subject: Re: rfc1918 ignorant (fwd) Well, if uBR showing RFC1918 address out on the traceroute is an issue, why not just reverse the way its configured? Put RFC1918 as secondary, and put the routable addr as primary. Either way, it should work w/o issues, right? I know quite a few people who purposely put a non-routable IP (whether it be 1918 or RIR-registered block) as primary on their interface, and use routable IP as secondary. Their reason for doing this is to somewhat hide their router's real interface IP from showing up in traceroute.. Well, it wouldn't completely 'hide' it, but to a certain level of degree, it probably does... -hc -- Sincerely, Haesu C. TowardEX Technologies, Inc. WWW: http://www.towardex.com E-mail: [EMAIL PROTECTED] Cell: (978) 394-2867 On Wed, Jul 23, 2003 at 07:21:25PM -0400, Jeff Wasilko wrote: On Wed, Jul 23, 2003 at 06:03:13PM -0400, Daniel Senie wrote: At 02:11 PM 7/23/2003, Dave Temkin wrote: 2003 7:07 AM:] Comcast and many others seem to blithely ignore this for convenience sake. (It's not like they need a huge amount of space to give private addresses to these links.) ARIN required cable operators to use RFC 1918 space for the management agents of the bridge cable modems that have been rolled out to the millions of residential cable modem customers. Doing so obviously requires a 1918 address on the cable router, but Cisco's implementation requires that address to be the primary interface address. There is also a publicly routable secondary which in fact is the gateway address to the customer, but isn't the address returned in a traceroute. Cisco has by far the lead in market share of the first gen Docsis cable modem router market so any trace to a cable modem customer is going to show this. When MediaOne (remember them?) deployed the cable modems here (LanCity stuff, originally), traceroutes did NOT show the 10/8 address from the router at the head end. ATT bought MediaOne, and now we've got Comcast. The service quality has stayed low, and the price has jumped quite a bit, and somewhere along the line a change happened and the 10/8 address of the router did start showing up. Now it's possible the router in the head end got changed and that was the cause. I really don't know. That's exactly what happened. The Lancity equipment were bridges, so you never saw them in traceroutes. The head-end bridges were aggregated into switches which were connected to routers. The Cisco uBR is a router, so you see the cable interface (which is typically rfc1918 space) showing up in traceroutes from the CPE out. Note that you don't see it on traceroutes towards the CPE since you see the 'internet facing' interface on the uBR. -j
re: rfc1918 ignorant
I agree... The only problem is if you filter all inbound RFC 1918 and inadvertently block ICMP messages from their routers on rfc1918 space. That could potentially cause issues with network connectivity related to MTU, etc... At 08:59 AM 7/23/2003, Dave Temkin wrote: Is this really an issue? So long as they're not advertising the space I see no issue with routing traffic through a 10. network as transit. If you have no reason to reach their router directly (and after Cisco's last exploit, I'd think no one would want anyone to reach their router directly :-) ), what's the harm done? RFC1918 merely states that it shouldn't be routed on the global internet, not that it can't be used for transit space. --- Is there a site to report networks/isps that still leak rfc1918 space? By leaking I not only mean don't filter, but actually _use_ in their network? If someone is keeping a list, feel free to add ServerBeach.com. All traceroutes to servers housed there, pass by 10.10.10.3. traceroute to www.serverbeach.com ... 20. 64-132-228-70.gen.twtelecom.net 21. 10.10.10.3 22. 66.139.72.12 Kind Regards, Frank Louwers -- Openminds bvbawww.openminds.be Tweebruggenstraat 16 - 9000 Gent - Belgium -- David Temkin Vinny Abello Network Engineer Server Management [EMAIL PROTECTED] (973)300-9211 x 125 (973)940-6125 (Direct) PGP Key Fingerprint: 3BC5 9A48 FC78 03D3 82E0 E935 5325 FBCB 0100 977A Tellurian Networks - The Ultimate Internet Connection http://www.tellurian.com (888)TELLURIAN There are 10 kinds of people in the world. Those who understand binary and those that don't.
re: rfc1918 ignorant
On Wed, 23 Jul 2003, Dave Temkin wrote: Is this really an issue? So long as they're not advertising the space I see no issue with routing traffic through a 10. network as transit. If you have no reason to reach their router directly (and after Cisco's last exploit, I'd think no one would want anyone to reach their router directly :-) ), what's the harm done? If Frank's seeing the IP in his traceroute then the network concerned isn't properly filtering traffic leaving their borders as per BCP38: http://www.faqs.org/rfcs/bcp/bcp38.html Rich
RE: rfc1918 ignorant
Good point on the PMTU, you're correct and I wasn't thinking about that (though generally that would have come from the inside router, unless one of those routers was where the MTU limitation was). Engineered *correctly *I don't see an issue. I never implied that people should remove filters for 1918, that's silly. On Wed, 23 Jul 2003, Ben Buxton wrote: Uhhh...PMTU-d can break as routers will send back icmp cant-frag packets from those link addresses and rpf, filtering, etc will bring tcp connections to a standstill. Don't filter rfc1918? umm good luck convincing the rest of the net to eliminiate their filters. The basic premise of building public networks is that you have to work around other peoples policies. If it's corporate nets, then sure you can control it all, but not here. Though the PMTU-d point is arguable (what are your internal links doing with crummy MTU, for example). BB Is this really an issue? So long as they're not advertising the space I see no issue with routing traffic through a 10. network as transit. If you have no reason to reach their router directly (and after Cisco's last exploit, I'd think no one would want anyone to reach their router directly :-) ), what's the harm done? RFC1918 merely states that it shouldn't be routed on the global internet, not that it can't be used for transit space. --- Is there a site to report networks/isps that still leak rfc1918 space? By leaking I not only mean don't filter, but actually _use_ in their network? If someone is keeping a list, feel free to add ServerBeach.com. All traceroutes to servers housed there, pass by 10.10.10.3. traceroute to www.serverbeach.com ... 20. 64-132-228-70.gen.twtelecom.net 21. 10.10.10.3 22. 66.139.72.12 Kind Regards, Frank Louwers -- Openminds bvbawww.openminds.be Tweebruggenstraat 16 - 9000 Gent - Belgium -- David Temkin
source filtering (Re: rfc1918 ignorant)
On Wed, Jul 23, 2003 at 02:10:17PM +0100, [EMAIL PROTECTED] wrote: On Wed, 23 Jul 2003, Dave Temkin wrote: Is this really an issue? So long as they're not advertising the space I see no issue with routing traffic through a 10. network as transit. If you have no reason to reach their router directly (and after Cisco's last exploit, I'd think no one would want anyone to reach their router directly :-) ), what's the harm done? If Frank's seeing the IP in his traceroute then the network concerned isn't properly filtering traffic leaving their borders as per BCP38: http://www.faqs.org/rfcs/bcp/bcp38.html I think you'll see more and more networks slowly over time move closer to bcp38. I believe that ATT is the only tier-1 provider that is in full compliance with this. I'm sure some of the smaller providers are as well. I've been looking at the unicast-rpf loose drops at our edges of our network the past month off and on and am still surprised at the bitrate of packets that can not be returned to their sources. I think it's a simple thing to do that will insure that you are not carrying all this extra junk traffic on your network. Another perspective here: A number of people refuse to answer calls that show up on their phones as out of area or private. Why would you answer or trust IP packets from hosts that are not in the routing table. While there is no PKI or similar to check if the packets are authenticated/signed for most of the network traffic, this does seem like a simple thing to do. Don't trust packets if you can't possibly figure out where they are coming from. - Jared -- Jared Mauch | pgp key available via finger from [EMAIL PROTECTED] clue++; | http://puck.nether.net/~jared/ My statements are only mine.
Re: rfc1918 ignorant
Date: Wed, 23 Jul 2003 08:59:18 -0400 (EDT) From: Dave Temkin [EMAIL PROTECTED] Sender: [EMAIL PROTECTED] Is this really an issue? So long as they're not advertising the space I see no issue with routing traffic through a 10. network as transit. If you have no reason to reach their router directly (and after Cisco's last exploit, I'd think no one would want anyone to reach their router directly :-) ), what's the harm done? RFC1918 merely states that it shouldn't be routed on the global internet, not that it can't be used for transit space. That's not what is in my copy of 1918. In order to use private address space, an enterprise needs to determine which hosts do not need to have network layer connectivity outside the enterprise in the foreseeable future and thus could be classified as private. Such hosts will use the private address space defined above. Private hosts can communicate with all other hosts inside the enterprise, both public and private. However, they cannot have IP connectivity to any host outside of the enterprise. While not having external (outside of the enterprise) IP connectivity private hosts can still have access to external services via mediating gateways (e.g., application layer gateways). As I read this, packets with a source address in 19298 space should NEVER appear outside the enterprise. Comcast and many others seem to blithely ignore this for convenience sake. (It's not like they need a huge amount of space to give private addresses to these links.) -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: [EMAIL PROTECTED] Phone: +1 510 486-8634
RE: rfc1918 ignorant
Ahhh...but this all comes down to how one defines enterprise and it's network scope. IANALBPSB (I am not a lawyer but probably shoud be) Daryl PGP Key: http://www.introspect.net/pgp [...] That's not what is in my copy of 1918. In order to use private address space, an enterprise needs to determine which hosts do not need to have network layer connectivity outside the enterprise in the foreseeable future and thus could be classified as private. Such hosts will use [...]
Re: rfc1918 ignorant
Heh, check this out. traceroute to 219.168.64.121 (219.168.64.121), 64 hops max, 44 byte packets 1 216.93.161.1 (216.93.161.1) 0.532 ms 0.518 ms 0.405 ms 2 66.7.159.33 (66.7.159.33) 0.796 ms 0.667 ms 0.543 ms 3 gigabitethernet8-0-513.ipcolo1.SanFrancisco1.Level3.net (63.211.150.225) 0.541 ms 0.478 ms 0.834 ms 4 gigabitethernet4-1.core1.SanFrancisco1.Level3.net (209.244.14.197) 0.547 ms 0.486 ms 0.530 ms 5 so-4-0-0.mp2.SanFrancisco1.Level3.net (209.247.10.233) 0.741 ms 0.729 ms 0.731 ms 6 so-2-0-0.mp2.SanJose1.Level3.net (64.159.0.218) 1.677 ms 1.510 ms 1.549 ms 7 unknown.Level3.net (64.159.2.102) 1.864 ms 1.851 ms 1.875 ms 8 sl-bb20-sj.sprintlink.net (209.245.146.142) 3.110 ms 3.831 ms 3.321 ms 9 sl-bb22-sj-14-0.sprintlink.net (144.232.3.165) 7.127 ms 3.290 ms 3.331 ms 10 sl-bb20-tok-13-1.sprintlink.net (144.232.20.188) 113.739 ms 113.731 ms 113.874 ms 11 sl-gw10-tok-15-0.sprintlink.net (203.222.36.42) 114.400 ms 114.051 ms 114.067 ms 12 sla-bbtech-2-0.sprintlink.net (203.222.37.106) 114.207 ms 114.295 ms 114.340 ms 13 10.9.17.10 (10.9.17.10) 101.595 ms 101.580 ms 101.771 ms 14 10.0.13.2 (10.0.13.2) 119.025 ms 118.765 ms 118.833 ms 15 10.4.10.2 (10.4.10.2) 134.809 ms 134.536 ms 134.668 ms 16 10.3.10.130 (10.3.10.130) 134.526 ms 135.004 ms 135.701 ms 17 10.10.0.25 (10.10.0.25) 135.291 ms 134.899 ms 135.293 ms 18 10.10.0.3 (10.10.0.3) 122.515 ms 122.210 ms 121.779 ms 19 10.10.0.11 (10.10.0.11) 135.643 ms 135.144 ms 135.438 ms 20 10.10.3.4 (10.10.3.4) 121.721 ms 121.872 ms 122.603 ms 21 10.10.3.36 (10.10.3.36) 135.069 ms 134.956 ms 135.330 ms 22 10.10.3.107 (10.10.3.107) 121.906 ms 122.708 ms 122.076 ms 23 YahooBB219168064121.bbtec.net (219.168.64.121) 147.137 ms 146.039 ms 147.453 ms -hc -- Sincerely, Haesu C. TowardEX Technologies, Inc. WWW: http://www.towardex.com E-mail: [EMAIL PROTECTED] Cell: (978) 394-2867 On Wed, Jul 23, 2003 at 09:07:51AM -0400, Vinny Abello wrote: Heh... Check out Comcast. A large part of their network uses rfc1918: 216 ms 9 ms10 ms 10.110.168.1 315 ms10 ms11 ms 172.30.116.17 410 ms13 ms10 ms 172.30.116.50 514 ms12 ms26 ms 172.30.112.123 610 ms14 ms23 ms 172.30.110.105 At 08:48 AM 7/23/2003, you wrote: Is there a site to report networks/isps that still leak rfc1918 space? By leaking I not only mean don't filter, but actually _use_ in their network? If someone is keeping a list, feel free to add ServerBeach.com. All traceroutes to servers housed there, pass by 10.10.10.3. traceroute to www.serverbeach.com ... 20. 64-132-228-70.gen.twtelecom.net 21. 10.10.10.3 22. 66.139.72.12 Kind Regards, Frank Louwers -- Openminds bvbawww.openminds.be Tweebruggenstraat 16 - 9000 Gent - Belgium Vinny Abello Network Engineer Server Management [EMAIL PROTECTED] (973)300-9211 x 125 (973)940-6125 (Direct) PGP Key Fingerprint: 3BC5 9A48 FC78 03D3 82E0 E935 5325 FBCB 0100 977A Tellurian Networks - The Ultimate Internet Connection http://www.tellurian.com (888)TELLURIAN There are 10 kinds of people in the world. Those who understand binary and those that don't.
RE: rfc1918 ignorant
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of [EMAIL PROTECTED] Sent: Wednesday, July 23, 2003 6:10 AM To: Dave Temkin Cc: [EMAIL PROTECTED] Subject: re: rfc1918 ignorant On Wed, 23 Jul 2003, Dave Temkin wrote: Is this really an issue? So long as they're not advertising the space I see no issue with routing traffic through a 10. network as transit. If you have no reason to reach their router directly (and after Cisco's last exploit, I'd think no one would want anyone to reach their router directly :-) ), what's the harm done? If Frank's seeing the IP in his traceroute then the network concerned isn't properly filtering traffic leaving their borders as per BCP38: http://www.faqs.org/rfcs/bcp/bcp38.html They're not complying with RFC1918 either: In order to use private address space, an enterprise needs to determine which hosts do not need to have network layer connectivity outside the enterprise in the foreseeable future and thus could be classified as private. Such hosts will use the private address space defined above. Private hosts can communicate with all other hosts inside the enterprise, both public and private. However, they cannot have IP connectivity to any host outside of the enterprise. While not having external (outside of the enterprise) IP connectivity private hosts can still have access to external services via mediating gateways (e.g., application layer gateways). All other hosts will be public and will use globally unique address space assigned by an Internet Registry. Public hosts can communicate with other hosts inside the enterprise both public and private and can have IP connectivity to public hosts outside the enterprise. Public hosts do not have connectivity to private hosts of other enterprises. and Because private addresses have no global meaning, routing information about private networks shall not be propagated on inter-enterprise links, and packets with private source or destination addresses should not be forwarded across such links. Routers in networks not using private address space, especially those of Internet service providers, are expected to be configured to reject (filter out) routing information about private networks. If such a router receives such information the rejection shall not be treated as a routing protocol error. Indirect references to such addresses should be contained within the enterprise. Prominent examples of such references are DNS Resource Records and other information referring to internal private addresses. In particular, Internet service providers should take measures to prevent such leakage. It's pretty clear that devices with network layer connectivity outside the etnerprise are not private and thus can't be numbered inside private IP space. DS
RE: rfc1918 ignorant
Except you're making assumptions as to how that router is used. If it's being used for purely transit then your third paragraph doesn't apply at all. The traffic is not originating or terminating there, it is merely passing through. -- David Temkin On Wed, 23 Jul 2003, David Schwartz wrote: -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of [EMAIL PROTECTED] Sent: Wednesday, July 23, 2003 6:10 AM To: Dave Temkin Cc: [EMAIL PROTECTED] Subject: re: rfc1918 ignorant On Wed, 23 Jul 2003, Dave Temkin wrote: Is this really an issue? So long as they're not advertising the space I see no issue with routing traffic through a 10. network as transit. If you have no reason to reach their router directly (and after Cisco's last exploit, I'd think no one would want anyone to reach their router directly :-) ), what's the harm done? If Frank's seeing the IP in his traceroute then the network concerned isn't properly filtering traffic leaving their borders as per BCP38: http://www.faqs.org/rfcs/bcp/bcp38.html They're not complying with RFC1918 either: In order to use private address space, an enterprise needs to determine which hosts do not need to have network layer connectivity outside the enterprise in the foreseeable future and thus could be classified as private. Such hosts will use the private address space defined above. Private hosts can communicate with all other hosts inside the enterprise, both public and private. However, they cannot have IP connectivity to any host outside of the enterprise. While not having external (outside of the enterprise) IP connectivity private hosts can still have access to external services via mediating gateways (e.g., application layer gateways). All other hosts will be public and will use globally unique address space assigned by an Internet Registry. Public hosts can communicate with other hosts inside the enterprise both public and private and can have IP connectivity to public hosts outside the enterprise. Public hosts do not have connectivity to private hosts of other enterprises. and Because private addresses have no global meaning, routing information about private networks shall not be propagated on inter-enterprise links, and packets with private source or destination addresses should not be forwarded across such links. Routers in networks not using private address space, especially those of Internet service providers, are expected to be configured to reject (filter out) routing information about private networks. If such a router receives such information the rejection shall not be treated as a routing protocol error. Indirect references to such addresses should be contained within the enterprise. Prominent examples of such references are DNS Resource Records and other information referring to internal private addresses. In particular, Internet service providers should take measures to prevent such leakage. It's pretty clear that devices with network layer connectivity outside the etnerprise are not private and thus can't be numbered inside private IP space. DS
Re: rfc1918 ignorant
On 23.07 10:07, Kevin Oberman wrote: In order to use private address space, an enterprise needs to determine which hosts do not need to have network layer connectivity outside the enterprise in the foreseeable future and thus could be classified as private. Such hosts will use the private address space defined above. Private hosts can communicate with all other hosts inside the enterprise, both public and private. However, they cannot have IP connectivity to any host outside of the enterprise. While not having external (outside of the enterprise) IP connectivity private hosts can still have access to external services via mediating gateways (e.g., application layer gateways). As I read this, packets with a source address in 19298 space should NEVER appear outside the enterprise. Comcast and many others seem to blithely ignore this for convenience sake. (It's not like they need a huge amount of space to give private addresses to these links.) You read this correctly. We also wrote: It is strongly recommended that routers which connect enterprises to external networks are set up with appropriate packet and routing filters at both ends of the link in order to prevent packet and routing information leakage. An enterprise should also filter any private networks from inbound routing information in order to protect itself from ambiguous routing situations which can occur if routes to the private address space point outside the enterprise. I consider this quite explicit. I also consider this still very valid. Imho the PMTU argument is moot. This should not be an issue at all other than on the edges these days. Should it nonetheless be an issue it can be done in the boundary routers which have interfaces numbered public address space. I do not know all the details here, so if I am wrong in detail, please tell me. Daniel
Re: rfc1918 ignorant
On Wednesday, July 23, 2003, at 11:40 AM, Dave Temkin wrote: Except you're making assumptions as to how that router is used. If it's being used for purely transit then your third paragraph doesn't apply at all. The traffic is not originating or terminating there, it is merely passing through. When the router needs to send an ICMP packet back to the source it becomes an originator. --lyndon
Re: rfc1918 ignorant
On Wed, 23 Jul 2003 13:40:03 EDT, Dave Temkin said: If it's being used for purely transit then your third paragraph doesn't apply at all. The traffic is not originating or terminating there, it is merely passing through. If it shows up on a traceroute, it originated an ICMP packet. 10 * * * 11 * * * 12 * * * would be proper behavior if it was *purely* transit-only. pgp0.pgp Description: PGP signature
Re: rfc1918 ignorant
Needs is a tough call. Plenty of networks block ICMP at the border and could very well be using 1918 addressing in between and you'd have no idea. -- David Temkin On Wed, 23 Jul 2003, Lyndon Nerenberg wrote: On Wednesday, July 23, 2003, at 11:40 AM, Dave Temkin wrote: Except you're making assumptions as to how that router is used. If it's being used for purely transit then your third paragraph doesn't apply at all. The traffic is not originating or terminating there, it is merely passing through. When the router needs to send an ICMP packet back to the source it becomes an originator. --lyndon
Re: rfc1918 ignorant
Date: Wed, 23 Jul 2003 13:40:03 -0400 (EDT) From: Dave Temkin [EMAIL PROTECTED] Sender: [EMAIL PROTECTED] Except you're making assumptions as to how that router is used. If it's being used for purely transit then your third paragraph doesn't apply at all. The traffic is not originating or terminating there, it is merely passing through. And what are the ICMP packets doing on the net? They seem to be originating from 1918 space. Nothing in the RFC says that ICMP does not count. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: [EMAIL PROTECTED] Phone: +1 510 486-8634
Re: rfc1918 ignorant
On Wednesday, July 23, 2003, at 11:50 AM, Dave Temkin wrote: Needs is a tough call. Plenty of networks block ICMP at the border and could very well be using 1918 addressing in between and you'd have no idea. True enough, but my view of networks that blindly block all ICMP is about the same as those that misuse 1918 addresses. And if they're blocking ICMP specifically to hide their misuse of 1918, well ... There are direct costs associated with dealing with networks that are configured as described above. If you can't see inside to diagnose problems, you can't call horsepucky when their support people start feeding you a line. The cost of downtime and local support staff quickly adds up. I've cancelled contracts in the past for this very reason. --lyndon
Re: rfc1918 ignorant
Date: Wed, 23 Jul 2003 13:50:05 -0400 (EDT) From: Dave Temkin [EMAIL PROTECTED] Sender: [EMAIL PROTECTED] Needs is a tough call. Plenty of networks block ICMP at the border and could very well be using 1918 addressing in between and you'd have no idea. And the network is broken. People persist in blocking ICMP and then complain when things don't work right. Even if you explain why blocking ICMP is breaking something, they say ICMP is evil and we have to block it. OK. they are broken and when things don't work, they need to tell their customers that they are choosing to run a network that does not work correctly. (Not that I expect anyone to do this.) I don't see anything tough about this call. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: [EMAIL PROTECTED] Phone: +1 510 486-8634
Re: rfc1918 ignorant
Unless of course I block ICMP for the purposes of denying traceroute but still allow DF/etc. Then it's not broken as you say. -- David Temkin On Wed, 23 Jul 2003, Kevin Oberman wrote: Date: Wed, 23 Jul 2003 13:50:05 -0400 (EDT) From: Dave Temkin [EMAIL PROTECTED] Sender: [EMAIL PROTECTED] Needs is a tough call. Plenty of networks block ICMP at the border and could very well be using 1918 addressing in between and you'd have no idea. And the network is broken. People persist in blocking ICMP and then complain when things don't work right. Even if you explain why blocking ICMP is breaking something, they say ICMP is evil and we have to block it. OK. they are broken and when things don't work, they need to tell their customers that they are choosing to run a network that does not work correctly. (Not that I expect anyone to do this.) I don't see anything tough about this call.
RE: rfc1918 ignorant (fwd)
-- Forwarded message -- Date: Wed, 23 Jul 2003 07:53:26 -1000 From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: RE: rfc1918 ignorant There's a common misconception reflected here that I wanted to correct. I don't have nanog-post, so I apologize if its not appropriate to reply directly. You may repost my comments if you'd like. [Kevin Oberman mailto:[EMAIL PROTECTED] wrote on Wednesday, July 23, 2003 7:07 AM:] Comcast and many others seem to blithely ignore this for convenience sake. (It's not like they need a huge amount of space to give private addresses to these links.) ARIN required cable operators to use RFC 1918 space for the management agents of the bridge cable modems that have been rolled out to the millions of residential cable modem customers. Doing so obviously requires a 1918 address on the cable router, but Cisco's implementation requires that address to be the primary interface address. There is also a publicly routable secondary which in fact is the gateway address to the customer, but isn't the address returned in a traceroute. Cisco has by far the lead in market share of the first gen Docsis cable modem router market so any trace to a cable modem customer is going to show this. In fact, Comcast and others _do_ need a huge amount of private IP space because of this. We didn't blithely ignore the RFC, but didn't have a choice in implementation. Perhaps Cisco will improve their implementation for the next round of CMTS development... Filtering of RFC 1918 space by cable ISPs is of course another topic. -Doug- [Kevin Oberman mailto:[EMAIL PROTECTED] wrote on Wednesday, July 23, 2003 7:07 AM:] Date: Wed, 23 Jul 2003 08:59:18 -0400 (EDT) From: Dave Temkin [EMAIL PROTECTED] Sender: [EMAIL PROTECTED] Is this really an issue? So long as they're not advertising the space I see no issue with routing traffic through a 10. network as transit. If you have no reason to reach their router directly (and after Cisco's last exploit, I'd think no one would want anyone to reach their router directly :-) ), what's the harm done? RFC1918 merely states that it shouldn't be routed on the global internet, not that it can't be used for transit space. That's not what is in my copy of 1918. In order to use private address space, an enterprise needs to determine which hosts do not need to have network layer connectivity outside the enterprise in the foreseeable future and thus could be classified as private. Such hosts will use the private address space defined above. Private hosts can communicate with all other hosts inside the enterprise, both public and private. However, they cannot have IP connectivity to any host outside of the enterprise. While not having external (outside of the enterprise) IP connectivity private hosts can still have access to external services via mediating gateways (e.g., application layer gateways). As I read this, packets with a source address in 19298 space should NEVER appear outside the enterprise. Comcast and many others seem to blithely ignore this for convenience sake. (It's not like they need a huge amount of space to give private addresses to these links.)
Re: rfc1918 ignorant (fwd)
So this, as many other discussions in the past, ends with the conclusion that ARIN did their share of breaking RFC´s and the Internet ? Pete - Original Message - From: Dave Temkin [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, July 23, 2003 9:11 PM Subject: RE: rfc1918 ignorant (fwd) -- Forwarded message -- Date: Wed, 23 Jul 2003 07:53:26 -1000 From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: RE: rfc1918 ignorant There's a common misconception reflected here that I wanted to correct. I don't have nanog-post, so I apologize if its not appropriate to reply directly. You may repost my comments if you'd like. [Kevin Oberman mailto:[EMAIL PROTECTED] wrote on Wednesday, July 23, 2003 7:07 AM:] Comcast and many others seem to blithely ignore this for convenience sake. (It's not like they need a huge amount of space to give private addresses to these links.) ARIN required cable operators to use RFC 1918 space for the management agents of the bridge cable modems that have been rolled out to the millions of residential cable modem customers. Doing so obviously requires a 1918 address on the cable router, but Cisco's implementation requires that address to be the primary interface address. There is also a publicly routable secondary which in fact is the gateway address to the customer, but isn't the address returned in a traceroute. Cisco has by far the lead in market share of the first gen Docsis cable modem router market so any trace to a cable modem customer is going to show this. In fact, Comcast and others _do_ need a huge amount of private IP space because of this. We didn't blithely ignore the RFC, but didn't have a choice in implementation. Perhaps Cisco will improve their implementation for the next round of CMTS development... Filtering of RFC 1918 space by cable ISPs is of course another topic. -Doug- [Kevin Oberman mailto:[EMAIL PROTECTED] wrote on Wednesday, July 23, 2003 7:07 AM:] Date: Wed, 23 Jul 2003 08:59:18 -0400 (EDT) From: Dave Temkin [EMAIL PROTECTED] Sender: [EMAIL PROTECTED] Is this really an issue? So long as they're not advertising the space I see no issue with routing traffic through a 10. network as transit. If you have no reason to reach their router directly (and after Cisco's last exploit, I'd think no one would want anyone to reach their router directly :-) ), what's the harm done? RFC1918 merely states that it shouldn't be routed on the global internet, not that it can't be used for transit space. That's not what is in my copy of 1918. In order to use private address space, an enterprise needs to determine which hosts do not need to have network layer connectivity outside the enterprise in the foreseeable future and thus could be classified as private. Such hosts will use the private address space defined above. Private hosts can communicate with all other hosts inside the enterprise, both public and private. However, they cannot have IP connectivity to any host outside of the enterprise. While not having external (outside of the enterprise) IP connectivity private hosts can still have access to external services via mediating gateways (e.g., application layer gateways). As I read this, packets with a source address in 19298 space should NEVER appear outside the enterprise. Comcast and many others seem to blithely ignore this for convenience sake. (It's not like they need a huge amount of space to give private addresses to these links.)
Re: rfc1918 ignorant
Unless of course I block ICMP for the purposes of denying traceroute but still allow DF/etc. Then it's not broken as you say. Sure, but people blocking all ICMP haven´t usually heard that there are different types and codes in ICMP. It´s surprising how many large www sites do not work if your MTU is less than 1500. Even if you do PMTU. (because the packets vanish somewhere before or at the server). Pete -- David Temkin On Wed, 23 Jul 2003, Kevin Oberman wrote: Date: Wed, 23 Jul 2003 13:50:05 -0400 (EDT) From: Dave Temkin [EMAIL PROTECTED] Sender: [EMAIL PROTECTED] Needs is a tough call. Plenty of networks block ICMP at the border and could very well be using 1918 addressing in between and you'd have no idea. And the network is broken. People persist in blocking ICMP and then complain when things don't work right. Even if you explain why blocking ICMP is breaking something, they say ICMP is evil and we have to block it. OK. they are broken and when things don't work, they need to tell their customers that they are choosing to run a network that does not work correctly. (Not that I expect anyone to do this.) I don't see anything tough about this call.
RE: rfc1918 ignorant (fwd)
ARIN required cable operators to use RFC 1918 space for the management agents of the bridge cable modems that have been rolled out to the millions of residential cable modem customers. this would be really amazing, as it would have required a time machine. the cable build was before arin existed. randy
Re: rfc1918 ignorant
On Wed, Jul 23, 2003 at 01:49:37PM -0400, [EMAIL PROTECTED] wrote: On Wed, 23 Jul 2003 13:40:03 EDT, Dave Temkin said: If it's being used for purely transit then your third paragraph doesn't apply at all. The traffic is not originating or terminating there, it is merely passing through. If it shows up on a traceroute, it originated an ICMP packet. 10 * * * 11 * * * 12 * * * would be proper behavior if it was *purely* transit-only. Perhaps it should send back the icmp packet from a loopback interface that has a publically routed ip on it. that would allow p-mtu to work as well as you'd get the packet saying frag-needed and you can still get a general idea of what route the packets are taking (although not the specific interface). it would allow people involved to look at their lsp routes or forwarding tables to determine where the fault is without revelaing information they would rather not about their infrastructure. ip icmp response-interface loopback0 junipers already do this if you traceroute directly to them (ie: they're the last hop in the traceroute) and send back the packet from their lo interface if you have 'default-address-selection' configured. (i think that's the keyword) - Jared -- Jared Mauch | pgp key available via finger from [EMAIL PROTECTED] clue++; | http://puck.nether.net/~jared/ My statements are only mine.
Re: rfc1918 ignorant
When the RFC's are broken, then what do you do? RFC's are to be followed if one can operate one's network under those constraints. Often times, RFC's don't take into account real world considerations. For instance: The rule that there should be only one root server network does not provide a solution to the problem of a corrupt monopoly gaining control over that one root server network (as is the case now). - Original Message - From: Petri Helenius [EMAIL PROTECTED] To: Dave Temkin [EMAIL PROTECTED]; Kevin Oberman [EMAIL PROTECTED] Cc: Lyndon Nerenberg [EMAIL PROTECTED]; David Schwartz [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Wednesday, July 23, 2003 13:19 Subject: Re: rfc1918 ignorant Unless of course I block ICMP for the purposes of denying traceroute but still allow DF/etc. Then it's not broken as you say. Sure, but people blocking all ICMP haven´t usually heard that there are different types and codes in ICMP. It´s surprising how many large www sites do not work if your MTU is less than 1500. Even if you do PMTU. (because the packets vanish somewhere before or at the server). Pete -- David Temkin On Wed, 23 Jul 2003, Kevin Oberman wrote: Date: Wed, 23 Jul 2003 13:50:05 -0400 (EDT) From: Dave Temkin [EMAIL PROTECTED] Sender: [EMAIL PROTECTED] Needs is a tough call. Plenty of networks block ICMP at the border and could very well be using 1918 addressing in between and you'd have no idea. And the network is broken. People persist in blocking ICMP and then complain when things don't work right. Even if you explain why blocking ICMP is breaking something, they say ICMP is evil and we have to block it. OK. they are broken and when things don't work, they need to tell their customers that they are choosing to run a network that does not work correctly. (Not that I expect anyone to do this.) I don't see anything tough about this call.
Re: rfc1918 ignorant
When the RFC's are broken, then what do you do? If negotiations fail, you revolt and overthrow the corrupt governing body. If applicable, add overseas occupation forces :) RFC's are to be followed if one can operate one's network under those constraints. Often times, RFC's don't take into account real world considerations. Unfortunately putting the non-rfc-compliant out of business would require distributing clue to the buyers, which has been tried and usually fails. For instance: The rule that there should be only one root server network does not provide a solution to the problem of a corrupt monopoly gaining control over that one root server network (as is the case now). You sure have filed drafts how this should be corrected, specially those which do not specify two roots, yours and theirs? Pete
Re: rfc1918 ignorant
Date: Wed, 23 Jul 2003 14:06:09 -0400 (EDT) From: Dave Temkin [EMAIL PROTECTED] Unless of course I block ICMP for the purposes of denying traceroute but still allow DF/etc. Then it's not broken as you say. And where do the ICMPs come from if the DF bit results in a failure? Surely not an RFC1918 address. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: [EMAIL PROTECTED] Phone: +1 510 486-8634
Re: rfc1918 ignorant
Is this really an issue? So long as they're not advertising the space I see no issue with routing traffic through a 10. network as transit. If you have no reason to reach their router directly (and after Cisco's last exploit, I'd think no one would want anyone to reach their router directly :-) ), what's the harm done? RFC1918 merely states that it shouldn't be routed on the global internet, not that it can't be used for transit space. RFC1918: Because private addresses have no global meaning, routing information about private networks shall not be propagated on inter-enterprise links, and packets with private source or destination addresses should not be forwarded across such links. Routers in networks not - using private address space, especially those of Internet service providers, are expected to be configured to reject (filter out) routing information about private networks. If such a router receives such information the rejection shall not be treated as a routing protocol error. By virtue of using RFC1918 addresses on packet-passing interfaces (those which generate ICMP error messages) it is a violation of RFC1918. One could, in turn, disable those messages, or filter them, but as others point out, that breaks such things as PMTU-D. Also, those who think their RFC1918-numbered device is not directly reachable solely due to being RFC1918 numbered, are deluded.
Re: rfc1918 ignorant
Needs is a tough call. Plenty of networks block ICMP at the border and could very well be using 1918 addressing in between and you'd have no idea. -- David Temkin Wholesale blocking of ICMP is another sign of incompetence. Either way a network using RFC1918 inappropriately, filtering all icmp, or both is a clueless network.
RE: rfc1918 ignorant (fwd)
At 02:11 PM 7/23/2003, Dave Temkin wrote: -- Forwarded message -- Date: Wed, 23 Jul 2003 07:53:26 -1000 From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: RE: rfc1918 ignorant There's a common misconception reflected here that I wanted to correct. I don't have nanog-post, so I apologize if its not appropriate to reply directly. You may repost my comments if you'd like. [Kevin Oberman mailto:[EMAIL PROTECTED] wrote on Wednesday, July 23, 2003 7:07 AM:] Comcast and many others seem to blithely ignore this for convenience sake. (It's not like they need a huge amount of space to give private addresses to these links.) ARIN required cable operators to use RFC 1918 space for the management agents of the bridge cable modems that have been rolled out to the millions of residential cable modem customers. Doing so obviously requires a 1918 address on the cable router, but Cisco's implementation requires that address to be the primary interface address. There is also a publicly routable secondary which in fact is the gateway address to the customer, but isn't the address returned in a traceroute. Cisco has by far the lead in market share of the first gen Docsis cable modem router market so any trace to a cable modem customer is going to show this. When MediaOne (remember them?) deployed the cable modems here (LanCity stuff, originally), traceroutes did NOT show the 10/8 address from the router at the head end. ATT bought MediaOne, and now we've got Comcast. The service quality has stayed low, and the price has jumped quite a bit, and somewhere along the line a change happened and the 10/8 address of the router did start showing up. Now it's possible the router in the head end got changed and that was the cause. I really don't know. In fact, Comcast and others _do_ need a huge amount of private IP space because of this. We didn't blithely ignore the RFC, but didn't have a choice in implementation. Perhaps Cisco will improve their implementation for the next round of CMTS development... Perhaps Comcast and others should INSIST that Cisco fix their bug, rather than just wish for a fix. Cable companies are buying lots of gear from them. Why not use that purchasing muscle to get this issue resolved? Or are the cable companies really interested in selling Internet service, or an online service like AOL? At some point, if you're going to sell Internet Service, it'd be nice if Internet standards and requirements are met. Filtering of RFC 1918 space by cable ISPs is of course another topic. -Doug- [Kevin Oberman mailto:[EMAIL PROTECTED] wrote on Wednesday, July 23, 2003 7:07 AM:] Date: Wed, 23 Jul 2003 08:59:18 -0400 (EDT) From: Dave Temkin [EMAIL PROTECTED] Sender: [EMAIL PROTECTED] Is this really an issue? So long as they're not advertising the space I see no issue with routing traffic through a 10. network as transit. If you have no reason to reach their router directly (and after Cisco's last exploit, I'd think no one would want anyone to reach their router directly :-) ), what's the harm done? RFC1918 merely states that it shouldn't be routed on the global internet, not that it can't be used for transit space. That's not what is in my copy of 1918. In order to use private address space, an enterprise needs to determine which hosts do not need to have network layer connectivity outside the enterprise in the foreseeable future and thus could be classified as private. Such hosts will use the private address space defined above. Private hosts can communicate with all other hosts inside the enterprise, both public and private. However, they cannot have IP connectivity to any host outside of the enterprise. While not having external (outside of the enterprise) IP connectivity private hosts can still have access to external services via mediating gateways (e.g., application layer gateways). As I read this, packets with a source address in 19298 space should NEVER appear outside the enterprise. Comcast and many others seem to blithely ignore this for convenience sake. (It's not like they need a huge amount of space to give private addresses to these links.)
Re: rfc1918 ignorant (fwd)
On Wed, Jul 23, 2003 at 06:03:13PM -0400, Daniel Senie wrote: At 02:11 PM 7/23/2003, Dave Temkin wrote: 2003 7:07 AM:] Comcast and many others seem to blithely ignore this for convenience sake. (It's not like they need a huge amount of space to give private addresses to these links.) ARIN required cable operators to use RFC 1918 space for the management agents of the bridge cable modems that have been rolled out to the millions of residential cable modem customers. Doing so obviously requires a 1918 address on the cable router, but Cisco's implementation requires that address to be the primary interface address. There is also a publicly routable secondary which in fact is the gateway address to the customer, but isn't the address returned in a traceroute. Cisco has by far the lead in market share of the first gen Docsis cable modem router market so any trace to a cable modem customer is going to show this. When MediaOne (remember them?) deployed the cable modems here (LanCity stuff, originally), traceroutes did NOT show the 10/8 address from the router at the head end. ATT bought MediaOne, and now we've got Comcast. The service quality has stayed low, and the price has jumped quite a bit, and somewhere along the line a change happened and the 10/8 address of the router did start showing up. Now it's possible the router in the head end got changed and that was the cause. I really don't know. That's exactly what happened. The Lancity equipment were bridges, so you never saw them in traceroutes. The head-end bridges were aggregated into switches which were connected to routers. The Cisco uBR is a router, so you see the cable interface (which is typically rfc1918 space) showing up in traceroutes from the CPE out. Note that you don't see it on traceroutes towards the CPE since you see the 'internet facing' interface on the uBR. -j
Re: rfc1918 ignorant (fwd)
Well, if uBR showing RFC1918 address out on the traceroute is an issue, why not just reverse the way its configured? Put RFC1918 as secondary, and put the routable addr as primary. Either way, it should work w/o issues, right? I know quite a few people who purposely put a non-routable IP (whether it be 1918 or RIR-registered block) as primary on their interface, and use routable IP as secondary. Their reason for doing this is to somewhat hide their router's real interface IP from showing up in traceroute.. Well, it wouldn't completely 'hide' it, but to a certain level of degree, it probably does... -hc -- Sincerely, Haesu C. TowardEX Technologies, Inc. WWW: http://www.towardex.com E-mail: [EMAIL PROTECTED] Cell: (978) 394-2867 On Wed, Jul 23, 2003 at 07:21:25PM -0400, Jeff Wasilko wrote: On Wed, Jul 23, 2003 at 06:03:13PM -0400, Daniel Senie wrote: At 02:11 PM 7/23/2003, Dave Temkin wrote: 2003 7:07 AM:] Comcast and many others seem to blithely ignore this for convenience sake. (It's not like they need a huge amount of space to give private addresses to these links.) ARIN required cable operators to use RFC 1918 space for the management agents of the bridge cable modems that have been rolled out to the millions of residential cable modem customers. Doing so obviously requires a 1918 address on the cable router, but Cisco's implementation requires that address to be the primary interface address. There is also a publicly routable secondary which in fact is the gateway address to the customer, but isn't the address returned in a traceroute. Cisco has by far the lead in market share of the first gen Docsis cable modem router market so any trace to a cable modem customer is going to show this. When MediaOne (remember them?) deployed the cable modems here (LanCity stuff, originally), traceroutes did NOT show the 10/8 address from the router at the head end. ATT bought MediaOne, and now we've got Comcast. The service quality has stayed low, and the price has jumped quite a bit, and somewhere along the line a change happened and the 10/8 address of the router did start showing up. Now it's possible the router in the head end got changed and that was the cause. I really don't know. That's exactly what happened. The Lancity equipment were bridges, so you never saw them in traceroutes. The head-end bridges were aggregated into switches which were connected to routers. The Cisco uBR is a router, so you see the cable interface (which is typically rfc1918 space) showing up in traceroutes from the CPE out. Note that you don't see it on traceroutes towards the CPE since you see the 'internet facing' interface on the uBR. -j
Re: rfc1918 ignorant
RFC1918 is a wonderful document. It probably added 10-15 years to the lifespan of the IPv4 address space, made IP addressing much simpler for internal applications, and it's prevented a large number of problems like people randomly making up addresses for boxes they know that they'll never need to connect to the outside. But it's not perfect, and it makes a couple of assumptions that aren't correct, which lead to the kind of edge cases driving this discussion. 1 - RFC1918 refers to hosts having IP addresses. They don't. Hosts have interfaces, and interfaces have IP addresses. In some cases, hosts have multiple interfaces with different communication needs - firewalls and routers being prominent examples. (You could argue that the definition of host excludes routers, but one of the problems here is that routers not only have routing parts, they have host parts, e.g. the configuration and control and monitoring functions that may deny public access for security and anti-DOS reasons.) And some software isn't all that bright about picking which interface address to use for its responses. 2 - RFC1918 assumes that communication is bidirectional, and that communication needs are bidirectional. They're not always, particularly at the network layer as opposed to the transport layer. Sometimes you need to send but don't want to receive, and sometimes you want to accept packets from machines that you don't want to send packets to. Routers often need to send ICMP packets about ___ failed to destinations that they don't need to accept packets from, such as traceroute and PMTU discovery responses - the source doesn't always need to be a routable address, though you could use a registered address and null-route any incoming packets to it if you wanted to help traceroute a bit. As a customer of an ISP, it's nice to be able to look at a traceroute and ask the help desk people why my packets from San Jose to San Francisco are going by way of Orlando, and to complain that the traceroute shows that orlando.routers.example.net is 250ms from San Jose, but I've also found that orlando.routers.example.net isn't always in Orlando, and that traceroute response times aren't always what they seem, and maybe that the 250ms doesn't mean either that Example.Net has a really slow route to Orlando or that the Orlando router is in Singapore; it may just be that they're using a Vendor X router which isn't good at pings when the CPU is busy (that's especially a problem for little DSL routers.) It's probably critical for connections between ISPs to have registered addresses that are used for traceroute responses, but I'm not convinced that routers internal to an ISP need to have globally unique addresses, as long as the ISP's operations folks can tell what interfaces are on what machines. Using RFC1918 space does mean that traceroutes either need to report numerical addresses or use the ISP's DNS server to resolve them, which isn't always practical, but that's not a big limitation. PathMTU Discovery is less of a perceived problem that traceroute, since usually anything that's broken will be broken on an edge router or tunnelling device of some sort rather than a core router, and core routers tend to all have the same values, but that still shouldn't force you to use registered address space.
