RFC-1918's on a PUBLIC network? why!!

[kronic_bsd]

I was checking my pf for blocks and keep seeing this over and over.....

Aug 14 14:09:13.153714 rule 17/0(match): block in on ep2: 10.177.112.1.67 > 255.255.255.255.68: xid:0x87b779e flags:0x8000 Y:10.177.65.226 S:12.242.18.9 G:10.177.112.1 ether 0:b:6:a1:6a:d8 [|bootp] [tos 0x7 (EC)]


after some help to find out which rule was blocking the above, pfctl -s rules , i found that the following was the rule responsible.


@17 block in log quick on ep2 inet from 10.0.0.0/8 to any


I have setup PF firewalls for 3 friends on the Comcast Network as i am, they all live in different cities so they are on different networks but i am seeing the same as above on their firewalls as well,,,except as i mentioned they are all on different networks so their SRC- are 10.177 .111.116 etc.

The firewalls are doing what they are suppose to do, block inbound rfc-1918 ...correct?

I wonder why Comcast would use RFC-1918 addressess on their PUBLIC network, this is not common pratice is it. I figure most people would drop rfc-1918 on their inet interface too, am i correct?

anyways i just wonder why they use such "Private" addressess for DHCP traffic on a "PUBLIC" network. Anyone else seeing this on their Comcast connection?

Have a Great Day

[Jason Ackley]

Post by kronic_bsd
I wonder why Comcast would use RFC-1918 addressess on their PUBLIC
network, this is not common pratice is it. I figure most people would
drop rfc-1918 on their inet interface too, am i correct?

What makes that part public versus private? These are just cable-modems
renewing their DHCP leases.

Post by kronic_bsd
anyways i just wonder why they use such "Private" addressess for DHCP
traffic on a "PUBLIC" network. Anyone else seeing this on their Comcast
connection?

Most providers do this.

The cable modems have no need to have routable IPs on them. They only
need to be reachable from the back-end systems for the cable provider
so that they can do monitoring/stats/config etc.

I don't even think you could get IP space from your registry
(ARIN/RIPE/APNIC) if you assigned 2 IPs per customer (one for their CM,
one for the PC).


In short, don't worry about it. Create a rule that drops quick RFC1918 to
bcast (or any) on DHCP and don't log. Then you can keep your previous
rule running with a little less noise..



cheers,
--
jason

[Anthony Schlemmer]

There's so much broadcast noise on cable that I use the following rule
to keep these packets from flooding my pf log.

#--------------------------------------------------------------------------
# Silently drop broadcasts (cable modem noise)
#
block in quick on $ext_if inet from any to { 255.255.255.255 }

Tony

Post by Jason Ackley

Post by kronic_bsd
I wonder why Comcast would use RFC-1918 addressess on their PUBLIC
network, this is not common pratice is it. I figure most people
would drop rfc-1918 on their inet interface too, am i correct?

What makes that part public versus private? These are just
cable-modems renewing their DHCP leases.

Post by kronic_bsd
anyways i just wonder why they use such "Private" addressess for
DHCP traffic on a "PUBLIC" network. Anyone else seeing this on
their Comcast connection?

Most providers do this.
The cable modems have no need to have routable IPs on them. They
only need to be reachable from the back-end systems for the cable
provider so that they can do monitoring/stats/config etc.
I don't even think you could get IP space from your registry
(ARIN/RIPE/APNIC) if you assigned 2 IPs per customer (one for their
CM, one for the PC).
In short, don't worry about it. Create a rule that drops quick
RFC1918 to bcast (or any) on DHCP and don't log. Then you can keep
your previous rule running with a little less noise..
cheers,
--
jason

[Dylan Smith]

Post by kronic_bsd
I wonder why Comcast would use RFC-1918 addressess on their PUBLIC network,
this is not common pratice is it.

RoadRunner have some routers with a 10.x.x.x address. When I lived in Houston,
an outbound traceroute would show a 10.x.x.x address on about the 3rd hop.

[Brian A. Seklecki]

I saw this crap back when I had Comcast here in northern VA. I quickly
kicked their service to the curb.

Who ever though broadband could be so bad?

Anyway, I have a friend in Georgia who uses "Charter" and sees the same
traffic, so it's probably the same cable platform.

Actually a lot of Cable ISPs assign a cable "modem" (remember, it's
actually a bridge, not a modem!) a 10.0/8 address as a management
address feature. Mostly so it can auto-update firmware at boot and/or
go into diagnostic mode if it can't reach the ISP net. You *know* it's
bad when your bridge needs a management interface...

None the less, other ISPs, like DSL.net, who actually provides my T-1,
use 172.16.0.0/16 for the WAN side of my line. They do it to conserve
having to allocate thousands of /30s for WAN links. It sucks because a
reverse traceroute always gets dropped at that next-to-last hop. What's
more, my point-to-point T1 uses Frame-Relay instead of HDLC/SDLC?!

At some point it's not worth asking questions.

If ISPs are going to use 1918 space for WAN links, they ought to setup a
many-to-one NAT for the space so that you don't always have to manually
specify the source address when your router wants to send outbound
traffic (SNMP anyone?!).

-lava

[Jason Ackley]

(going OT now)

Post by Brian A. Seklecki
address feature. Mostly so it can auto-update firmware at boot and/or
go into diagnostic mode if it can't reach the ISP net. You *know* it's
bad when your bridge needs a management interface...

Uhhh. What is a better alternative? Deploying millions of devices without
a management interface and require a truckroll for a change?

And don't suggest that management protocol be built into the protocol
between the CM and CMTS, that would toss out all industry standards
and require proprietary solutions (e.g. fancy snmp proxy agents, or
things like Motorola does with the Canopy wireless gear).

Post by Brian A. Seklecki
None the less, other ISPs, like DSL.net, who actually provides my T-1,
use 172.16.0.0/16 for the WAN side of my line. They do it to conserve

It is a /12.

Post by Brian A. Seklecki
having to allocate thousands of /30s for WAN links. It sucks because a
reverse traceroute always gets dropped at that next-to-last hop. What's

That is a bad decision on their part. They can justify a /30 for WAN
links to ARIN/other, as long as the overall subnetting makes sense..

Post by Brian A. Seklecki
more, my point-to-point T1 uses Frame-Relay instead of HDLC/SDLC?!

Is there a particular problem you have with frame vs. other protocol? If
it still performs the same(assuming that your CIR is not 0), what does it
matter to you?

This is usually done as frame-relay since providers can use DSL/bridged
ATM and frame-relay on the same platforms and use FRF.5 and FRF.8 for
connectivity, all transparently on the same box..

Post by Brian A. Seklecki
If ISPs are going to use 1918 space for WAN links, they ought to setup a
many-to-one NAT for the space so that you don't always have to manually

How would you accomplish this at an ISP with hundreds of ingress/egress
points and paths within the network? Would you expect the translation to
be pseudo-static so that 'border-r4.sfo' always comes out a certain IP to
all destinations or would you expect this to change based on the routing
(and hence the egress point from the AS) ?

The solution is proper configuration and subnet design, not NAT
hacks..

Post by Brian A. Seklecki
specify the source address when your router wants to send outbound
traffic (SNMP anyone?!).

Well, alot of the RFCs dictate that things be sourced from the interface
that recv'ed the offensive traffic (e.g. ICMP generation). So you cannot
have a single 'global' IP for the router to always use for outbound
traffic.

Most vendors provide a method to set the source IP for the services that
run locally or need to send data (netflow,syslog,ntpd,snmp,tftp,etc on
cisco).



cheers,
--
jason

[Brian A. Seklecki]

Post by Jason Ackley
(going OT now)

Post by Brian A. Seklecki
address feature. Mostly so it can auto-update firmware at boot and/or
go into diagnostic mode if it can't reach the ISP net. You *know* it's
bad when your bridge needs a management interface...

Uhhh. What is a better alternative? Deploying millions of devices without
a management interface and require a truckroll for a change?

I've just never seen a DSL bridge that required a management IP address.

More to the point, if the device truly is a bridge, it's CAM table
should have static entries to prevent DHCP/BOOTP broadcast traffic from
flooding to all ports.

Post by Jason Ackley
It is a /12.

Right.

Post by Jason Ackley

Post by Brian A. Seklecki
having to allocate thousands of /30s for WAN links. It sucks because a
reverse traceroute always gets dropped at that next-to-last hop. What's

That is a bad decision on their part. They can justify a /30 for WAN
links to ARIN/other, as long as the overall subnetting makes sense..

Post by Brian A. Seklecki
more, my point-to-point T1 uses Frame-Relay instead of HDLC/SDLC?!

Is there a particular problem you have with frame vs. other protocol? If
it still performs the same(assuming that your CIR is not 0), what does it
matter to you?

You mean FRASI (Frame Relay to ATM Service Inter-working)? Frame relay
DLCI <-> ATM PVC mapping? That thought had crossed my mind.

One would think that an ISP big enough to use that solution wouldn't
mind the extra ARIN work for IP space.

Post by Jason Ackley
How would you accomplish this at an ISP with hundreds of ingress/egress
points and paths within the network? Would you expect the translation to
be pseudo-static so that 'border-r4.sfo' always comes out a certain IP to
all destinations or would you expect this to change based on the routing
(and hence the egress point from the AS) ?
The solution is proper configuration and subnet design, not NAT
hacks..

....

Post by Jason Ackley

Post by Brian A. Seklecki
specify the source address when your router wants to send outbound
traffic (SNMP anyone?!).

Well, alot of the RFCs dictate that things be sourced from the interface
that recv'ed the offensive traffic (e.g. ICMP generation). So you cannot
have a single 'global' IP for the router to always use for outbound
traffic.

On IOS it's easy to source traps from an interface. I'm fortunate
enough to have an OpenBSD router using a Sangoma Wanpipe.

[Dom De Vitto]

My ISP, erm, the one I help run, has 66.5 class Bs, but still uses
RFC1918 for stuff that should never be internet addressable - CMs
for instance, and it means that uBRs and DHCP servers can have (more)
common configs between regions.

Either way, there is no such thing as "private" addresses, RPC1918
just indicates that these addresses shouldn't be passed between ISPs.

Dom
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Dom De Vitto Tel. [phone]
http://www.devitto.com mailto:***@devitto.com
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -


-----Original Message-----
From: owner-***@openbsd.org [mailto:owner-***@openbsd.org] On Behalf
Of Jason Ackley
Sent: Sunday, August 17, 2003 4:12 AM
To: Brian A. Seklecki
Cc: kronic_bsd; ***@openbsd.org
Subject: Re: RFC-1918's on a PUBLIC network? why!!


(going OT now)

Post by Brian A. Seklecki
address feature. Mostly so it can auto-update firmware at boot and/or
go into diagnostic mode if it can't reach the ISP net. You *know*
it's bad when your bridge needs a management interface...

Uhhh. What is a better alternative? Deploying millions of devices
without a management interface and require a truckroll for a change?

And don't suggest that management protocol be built into the protocol
between the CM and CMTS, that would toss out all industry standards and
require proprietary solutions (e.g. fancy snmp proxy agents, or things
like Motorola does with the Canopy wireless gear).

Post by Brian A. Seklecki
None the less, other ISPs, like DSL.net, who actually provides my T-1,
use 172.16.0.0/16 for the WAN side of my line. They do it to conserve

It is a /12.

Post by Brian A. Seklecki
having to allocate thousands of /30s for WAN links. It sucks because
a reverse traceroute always gets dropped at that next-to-last hop.
What's

That is a bad decision on their part. They can justify a /30 for WAN
links to ARIN/other, as long as the overall subnetting makes sense..

Post by Brian A. Seklecki
more, my point-to-point T1 uses Frame-Relay instead of HDLC/SDLC?!

Is there a particular problem you have with frame vs. other protocol?
If it still performs the same(assuming that your CIR is not 0), what
does it matter to you?

This is usually done as frame-relay since providers can use DSL/bridged
ATM and frame-relay on the same platforms and use FRF.5 and FRF.8 for
connectivity, all transparently on the same box..

Post by Brian A. Seklecki
If ISPs are going to use 1918 space for WAN links, they ought to setup
a many-to-one NAT for the space so that you don't always have to
manually

How would you accomplish this at an ISP with hundreds of ingress/egress
points and paths within the network? Would you expect the translation
to be pseudo-static so that 'border-r4.sfo' always comes out a certain
IP to all destinations or would you expect this to change based on the
routing (and hence the egress point from the AS) ?

The solution is proper configuration and subnet design, not NAT
hacks..

Post by Brian A. Seklecki
specify the source address when your router wants to send outbound
traffic (SNMP anyone?!).

Well, alot of the RFCs dictate that things be sourced from the interface
that recv'ed the offensive traffic (e.g. ICMP generation). So you cannot
have a single 'global' IP for the router to always use for outbound
traffic.

Most vendors provide a method to set the source IP for the services that
run locally or need to send data (netflow,syslog,ntpd,snmp,tftp,etc on
cisco).



cheers,
--
jason