ICMP weirdness
Robert Bonomi
bonomi at mail.r-bonomi.com
Mon Oct 18 21:36:35 UTC 2004
> From owner-nanog at merit.edu Mon Oct 18 16:01:42 2004
> Subject: Re: ICMP weirdness
> From: Jim Popovitch <jimpop at yahoo.com>
> To: "Stephen J. Wilcox" <steve at telecomplete.co.uk>
> Cc: nanog at merit.edu
> Date: Mon, 18 Oct 2004 17:01:39 -0400
>
>
> On Mon, 2004-10-18 at 15:54, Stephen J. Wilcox wrote:
> > why not that seems ok to me.. ?
> >
> > assuming you accept the 1918 assignment to your cable then its not unreasonable
> > that you can get to other end users on that network
>
> Across other non-private IP space? I am not all that familiar w/
> RFC1918, but I would think that this goes against it, or should I assume
> that Insight Broadband is part of Comcast?
It appears likely that that _is_ the case.
It is numbered in historical 'Class A' space that AT&T owns.
Comcast did buy up a bunch of AT&T's cable operations. Both the cable TV
_and_ the internet services.
By strict definitions, your home is a _separate_ network from Comcast's
internal network.
As such:
Per RFC 1918, _you_ should be doing egress filtering, to prohibit
RFC 1918 _destination_ addresses from exiting your network _to_ Comcast's
network, as well as egress filtering of RFC 1918 _source_ address packets
(with a few special-case exceptions), to be a 'good neighbor'. In self-
defense, you should be ingress filtering any RFC 1918 destination addresses,
and any RFC 1918 source addressed packets (except for the special-case
exectptions -- ICMP redirect, unreachable, TTL exceeded, etc.).
Similarly, Comcast should be at the 'gateway' to your network, be =egress=
filtering any packets with RFC 1918 destination addresses, as well as any
RFC 1918 source address packets (except for the aforementioned special-case
exceptions)
The should *also*, be _ingress_ filtering any RFC 1918 destination
addresses coming from your network, _and_ filtering out any RFC 1918
_source_ address packets (with the same few special-case execptions) from
your network.
RFC 1918 restricts use of the 'private' address-blocks to networks under
a _single_ administrative control. It is perfectly legitimate to use
different segments of that address-space in different locations *on*the*
*same*network*, even _with_ 'routable' addresses in between them. The
RFC 1918 rule is that the 'private' addresses must not escape _from_ the
network under the adminsistrative control of that party to a network that
is controlled by 'somebody else'.
That said, a *LOT* of the world doesn't use 'strict' definitions.
Unfortunately.
Comcast apparently considers the end-user machines as simply nodes _on_their_
_network_. And, as such, does route RFC 1918 addresses 'internally' between
different locales, where different portions of that address-space are used
_on_the_Comcast_network_.
>
> -Jim P.
>
> >
> > Steve
> >
> > On Mon, 18 Oct 2004, Jim Popovitch wrote:
> >
> > >
> > > >From Comcast Cable, at my home in Atlanta, I can ping 10.10.1.1....
> > > which is pong'ed from a private client network hanging somewhere off of
> > > Insight Broadband's network in the North Central part of the US. Why on
> > > god's green earth do network operators allow such nonsense as this?
> > >
> > > -Jim P.
> > >
> > > Traceroute -I 10.10.1.1 produces the following:
> > >
> > > traceroute to 10.10.1.1 (10.10.1.1), 30 hops max, 38 byte packets
> > > 1 10.238.10.1 (10.238.10.1) 29.089 ms 25.387 ms 28.574 ms
> > > 2 66.56.22.66 (66.56.22.66) 30.923 ms 31.305 ms 33.142 ms
> > > 3 66.56.22.70 (66.56.22.70) 35.945 ms 35.874 ms 36.832 ms
> > > 4 c-66-56-23-38.atl.client2.attbi.com (66.56.23.38) 34.740 ms 35.041
> > > ms 37.537 ms
> > > 5 12.118.184.41 (12.118.184.41) 41.967 ms 45.584 ms 43.997 ms
> > > 6 gbr2-p70.attga.ip.att.net (12.123.21.6) 44.988 ms 44.706 ms
> > > 43.033 ms
> > > 7 tbr2-p013602.attga.ip.att.net (12.122.12.37) 49.353 ms 44.010 ms
> > > 45.244 ms
> > > 8 12.122.10.138 (12.122.10.138) 62.244 ms 62.269 ms 62.148 ms
> > > 9 gbr1-p40.sl9mo.ip.att.net (12.122.11.114) 60.922 ms 67.005 ms
> > > 60.264 ms
> > > 10 gar1-p360.sl9mo.ip.att.net (12.123.24.209) 59.572 ms 64.013 ms
> > > 60.198 ms
> > > 11 12-220-0-69.client.insightBB.com (12.220.0.69) 77.000 ms 76.050
> > > ms 77.926 ms
> > > 12 12-220-7-198.client.insightBB.com (12.220.7.198) 95.437 ms 80.068
> > > ms 84.076 ms
> > > 13 10.10.1.1 (10.10.1.1) 93.612 ms 97.280 ms 192.994 ms
> > >
> > >
> > >
>
More information about the NANOG
mailing list