- Test - lists.nanog.org

RE: rfc1918 ignorant (fwd)
by Daniel Senie 24 Jul '03

24 Jul '03

At 02:11 PM 7/23/2003, Dave Temkin wrote: >---------- Forwarded message ---------- >Date: Wed, 23 Jul 2003 07:53:26 -1000 >From: DOUGS(a)oceanic.com >To: oberman(a)es.net >Cc: dave(a)ordinaryworld.com >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:oberman@es.net> 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:oberman@es.net> wrote on Wednesday, July 23, >2003 7:07 AM:] > >> Date: Wed, 23 Jul 2003 08:59:18 -0400 (EDT) > >> From: Dave Temkin <dave(a)ordinaryworld.com> > >> Sender: owner-nanog(a)merit.edu > >> > >> > >> 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.)

5 5

re: rfc1918 ignorant
by Dave Temkin 24 Jul '03

24 Jul '03

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 bvba www.openminds.be Tweebruggenstraat 16 - 9000 Gent - Belgium -- David Temkin

8 14

RE: rfc1918 ignorant
by McBurnett, Jim 24 Jul '03

24 Jul '03

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:haesu@towardex.com] Sent: Wednesday, July 23, 2003 12:53 PM To: Vinny Abello; nanog(a)merit.edu 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: haesu(a)towardex.com 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: > > 2 16 ms 9 ms 10 ms 10.110.168.1 > 3 15 ms 10 ms 11 ms 172.30.116.17 > 4 10 ms 13 ms 10 ms 172.30.116.50 > 5 14 ms 12 ms 26 ms 172.30.112.123 > 6 10 ms 14 ms 23 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 bvba www.openminds.be > >Tweebruggenstraat 16 - 9000 Gent - Belgium > > > Vinny Abello > Network Engineer > Server Management > vinny(a)tellurian.com > (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.

4 3

RE: rfc1918 ignorant
by McBurnett, Jim 24 Jul '03

24 Jul '03

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: up(a)3.am [mailto:up@3.am] Sent: Thursday, July 24, 2003 8:44 AM To: nanog(a)merit.edu 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:haesu@towardex.com] > Sent: Wednesday, July 23, 2003 12:53 PM > To: Vinny Abello; nanog(a)merit.edu > 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: haesu(a)towardex.com > 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: > > > > 2 16 ms 9 ms 10 ms 10.110.168.1 > > 3 15 ms 10 ms 11 ms 172.30.116.17 > > 4 10 ms 13 ms 10 ms 172.30.116.50 > > 5 14 ms 12 ms 26 ms 172.30.112.123 > > 6 10 ms 14 ms 23 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 bvba www.openminds.be > > >Tweebruggenstraat 16 - 9000 Gent - Belgium > > > > > > Vinny Abello > > Network Engineer > > Server Management > > vinny(a)tellurian.com > > (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 up(a)3.am http://3.am =========================================================================

1 0

RE: Cisco vulnerability and dangerous filtering techniques
by McBurnett, Jim 24 Jul '03

24 Jul '03

>Quick solution to this bug, as well as any future bug(s) .... replace all >routers with PCs running Zebra. That is good until Zebra get's a bug and then someone will say go to XYZ... Jim

4 3

Re: rfc1918 ignorant
by Stewart, William C (Bill), RTSLS 24 Jul '03

24 Jul '03

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.

1 0

root.rwhois.net broken
by nanog 23 Jul '03

23 Jul '03

Domain Name: RWHOIS.NET Registrar: NETWORK SOLUTIONS, INC. Whois Server: whois.networksolutions.com Referral URL: http://www.networksolutions.com Name Server: NS1.VERISIGNLABS.COM Name Server: NS2.VERISIGNLABS.COM Status: REGISTRAR-HOLD Updated Date: 15-jul-2003 Creation Date: 10-jul-1996 Expiration Date: 09-jul-2004 Registrar-hold? Nice. ETA for fix? $ host root.rwhois.net Host root.rwhois.net. not found: 3(NXDOMAIN) Can anyone from Network Solutions push this fix along? Or possibly let me know the IP of root.rwhois.net so we can look up things in the interim? bill

1 0

Cisco Vulnerability (updated?)
by Jason Frisvold 23 Jul '03

23 Jul '03

Apparently protocol 103 does not need to have a ttl of 0 or 1 when it hits the interface in order to cause the DoS ... Cisco has updated their advisory to reflect this (Version 1.9 now).. Just wanted to alert everyone... This makes the thought of some sort of virus causing this even more realistic.. no need to check ttl's, just fire away with protocol 103... Yikes... -- --------------------------- Jason H. Frisvold Backbone Engineering Supervisor Penteledata Engineering friz(a)corp.ptd.net RedHat Engineer - RHCE # 807302349405893 Cisco Certified - CCNA # CSCO10151622 MySQL Core Certified - ID# 205982910 --------------------------- "Imagination is more important than knowledge. Knowledge is limited. Imagination encircles the world." -- Albert Einstein [1879-1955]

1 0

Re: rfc1918 ignorant
by Kevin Oberman 23 Jul '03

23 Jul '03

> Date: Wed, 23 Jul 2003 14:06:09 -0400 (EDT) > From: Dave Temkin <dave(a)ordinaryworld.com> > > 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: oberman(a)es.net Phone: +1 510 486-8634

1 0

Re: rfc1918 ignorant
by Kevin Oberman 23 Jul '03

23 Jul '03

> Date: Wed, 23 Jul 2003 13:50:05 -0400 (EDT) > From: Dave Temkin <dave(a)ordinaryworld.com> > Sender: owner-nanog(a)merit.edu > > > 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: oberman(a)es.net Phone: +1 510 486-8634

4 4