COX using RFC1918 addresses on their WAN

TWX

Had a fun one today. COX is using 10.0.0.0/8 addresses and 172.16.0.0/12 addresses on their WAN. This causes a headache for the end subscriber if one is blocking RFC1918 addresses on their WAN interface, as it may break DHCP.

They want to claim that they're free to use the private IP addresses since "their customers use 192.168.0.0/16", but as far as I'm concerned, if my WAN interface is an Internet-facing interface, there's no business having any private IP addresses on it. Also, I have just as much right to 10.0.0.0/8 and 172.16.0.0/12 as they do.

I'm really hoping that someone else's high-speed solution makes it to town soon.

jamthat

This is for a regular old residential connection? ...Are you sure??

TWX

Residential. I'm sure. I called them even, to confirm that there was not some bizarro attack or MITM or other malevolence.

instant000

For your reading pleasure:

RFC 6598 -IANA-Reserved IPv4 Prefix for Shared Address Space
https://tools.ietf.org/html/rfc6598

cisco.com - Carrier Grade Network Adress Translation
IP Addressing: NAT Configuration Guide, Cisco IOS XE Release 3S (ASR 1000) - Carrier Grade Network Address Translation [Support] - Cisco

Wikipedia - Carrier Grade NAT
https://en.wikipedia.org/wiki/Carrier-grade_NAT

Google Query - Carrier Grade NAT
https://www.google.com/search?q=carrier+grade+NAT

Hope this helps!

TWX

instant000 wrote: »

For your reading pleasure:

RFC 6598 -IANA-Reserved IPv4 Prefix for Shared Address Space
https://tools.ietf.org/html/rfc6598

cisco.com - Carrier Grade Network Adress Translation
IP Addressing: NAT Configuration Guide, Cisco IOS XE Release 3S (ASR 1000) - Carrier Grade Network Address Translation [Support] - Cisco

Wikipedia - Carrier Grade NAT
https://en.wikipedia.org/wiki/Carrier-grade_NAT

Google Query - Carrier Grade NAT
https://www.google.com/search?q=carrier+grade+NAT

Hope this helps!

Yeah, they don't appear to have followed these RFCs and guidelines either. Haven't seen any 100.64.0.0/10 addresses yet. Instead previously 10.36.96.1 answered my DHCP request, then after I restarted my router last night 172.19.73.156 answered my request. This afternoon as a I was doing some network practice exercises I saw a random stray route that I know I did not put in my router, to 172.19.73.156 via my WAN interface, and it wasn't statically set anywhere in the router config. Its admin distance is 254, which Cisco uses for DHCP-added routes.

I guess what pisses me off is the cavalier attitude I got on the phone when I called COX about this, and the, "we'll do what we please" attitude over on dslreports from the COX reps that responded to my public comment on this. I am so looking forward to other options coming into town.

alan2308

Wait, so are there actually ISP's that don't have that "we'll do as we please" attitude? I haven't had the pleasure of dealing with one yet.

TWX

I actually did, once. Probably fifteen years ago the local Macintosh User's Group's ISP was spun-off as its own business so that the tax-exempt Users Group could keep that status. At the time, one could get one's DSL line through the phone company, but get one's account and service through a third-party ISP. This ISP offered five static IP addresses with DNS forward and reverse resolve (basically a /29) for some paltry amount over the cost of a standard residential DSL account. I had services hosted at home while nearly everyone else was still on dialup.

Unfortunately when I moved DSL wasn't available in the new place, and by the time I lived in a DSL neighborhood again the local phone company wouldn't do the line-only type of service anymore. Bastards.

beatfreaker

Can you provide a snippet of your logs and a couple of mac addresses? Or better yet a packet capture? Just only need to see ARP/DHCP packets.


I believe you're seeing cable modem management traffic which is harmless but fun to disect. It may look like WAN traffic but its actually COX "LAN" traffic. Couple ways to tell are:


DHCP and ARP traffic addressed to broadcast
ARP traffic are the other modems in your neighborhod (this is why your activity light always flashes)
ARP reqs should be coming from the gateway address (there may be several but will end with .1)


You mentioned IPs 10.36.96.1 and 172.19.73.156 responding to requests. It sounds like these are your DHCP and TFTP servers. Most likely 10.36.96.1 is your CMTS and acting as relay for their DHCP servers. Think dhcp ip-helper. The diag page on your modem (192.168.100.1) should corroborate this.


I don't have cox service but this is typical of a DOCSIS network. I don't know their design in your area but its basically like this:


All the cable modems in your area/node end up end on the same phy interface on the CMTS (Cable Modem Termination System).
In a nutshell its just a giant router with interfaces that bridge the RF and IP network.
In DOCSIS world each interface is actually called a mac domain and is comprised of multiple upstream and downsteam RF channels that can be bonded.
Each mac domain group can serve anwhere from 1 to 500 modems upwards and a single CMTS may have 5-7000 modems.
Multiple IP subnets/pools are assigned to the CMTS for different services like voip, business, managing IP space, etc.
You'll see ARP requests from gw addresses from the above subnets which is just your CMTS as proxy.




Heres a dhcp packet capture on my WAN interface on Time Warner Cable. Just modem management stuff like requesting DHCP, TOD, TFTP and modem confguration file, all the things that happen before you get a public IP and online. This one is actually from my set top. It's one of TWCs newer DVR that leverages the cable modem for video control signaling. Really cool stuff in that world too. I'd be interested in talking about that too for anyone interested.




Packet:


beatfreaker@router:~$ sudo tcpdump -i eth1 -vvn port 67 or port 68 -c 1
23:52:38.041936 IP (tos 0x0, ttl 64, id 42467, offset 0, flags [none], proto UDP (17), length 389)
XXX.XXX.XXX.XXX.67 > 255.255.255.255.68: [udp sum ok] BOOTP/DHCP, Reply, length 361, hops 1, xid 0x101b5c4, Flags [Broadcast] (0x8000)
Your-IP 10.61.215.104
Server-IP 76.85.237.69
Gateway-IP XXX.XXX.XXX.XXX
Client-Ethernet-Address pp:pp:pp:pp:pp:pp
file "?BEWGlyCkeqRpjaYKPddo@Cj3XaIjf2WPN0Je3QN2zpbkcHp8StP12"
Vendor-rfc1048 Extensions
Magic Cookie 0x63825363
DHCP-Message Option 53, length 1: Offer
Server-ID Option 54, length 4: XXX.XXX.XXX.XXX
Lease-Time Option 51, length 4: 489223
Subnet-Mask Option 1, length 4: 255.255.224.0
Time-Zone Option 2, length 4: 0
Default-Gateway Option 3, length 4: 10.61.192.1
Time-Server Option 4, length 4: 76.85.237.69
Domain-Name-Server Option 6, length 8: 209.18.47.61,209.18.47.62
BF Option 67, length 54: "?BEWGlyCkeqRpjaYKPddo@Cj3XaIjf2WPN0Je3QN2zpbkcHp8StP12"
T177 Option 177, length 12: 17455920,774909488,774921472


Broken Down:


XXX.XXX.XXX.XXX = CMTS
Your-IP 10.61.215.104 = Cable modem mangement IP
Server-IP 76.85.237.69 = TFTP server
Client-Ethernet-Address pp:pp:pp:pp:pp:pp = Modem HFC MAC Address
file = encrypted modem configuration file
Default-Gateway Option 3, length 4: 10.61.192.1 = CMTS, also gw address for one of many assigned subnets
Domain-Name-Server Option 6, length 8: 209.18.47.61,209.18.47.62 = TWC Anycast DNS IPs




Heres a link for DOCSIS DHCP related options:
https://www.incognito.com/tips-and-tutorials/dhcp-options-in-plain-english/


RFC's & CableLab
RFC 2132: RFC 2132
RFC 3046: RFC 3046
RFC 3495: RFC 3495
RFC 3646: RFC 3646
RFC 4704: RFC 4704
CL-SP-CANN-DHCP-Reg-I08-111117: http://www.cablelabs.com/specifications/CL-SP-CANN-DHCP-Reg-I08-111117.pdf

beatfreaker

TWX - saw your response on dslreports.com which sheds some more light. Weird for sure but looks like fun to figure out. I don't have an account there so I'll post your reply here and hope we can troubleshoot this here instead.

said by TWX:because their configuration adds a route to my router:

172.19.0.0/32 is subnetted, 1 subnets
S 172.19.73.156 [254/0] via 68.###.###.### (public IP)


This breaks my use of 172.19.73.0/24 specifically, as my router cannot have two routes to two networks with the same address space.

rt#sh dhcp lease
Temp IP addr: 68.###.###.### for peer on Interface: GigabitEthernet0/0.2
Temp sub net mask: 255.255.255.0
DHCP Lease server: 172.19.73.156, state: 7 Renewing
DHCP transaction id: FD5
Lease: 86400 secs, Renewal: 43200 secs, Rebind: 75600 secs
Temp default-gateway addr: 68.###.###.###
Next timer fires after: 04:31:40
Retry count: 1 Client-ID: ####
Client-ID hex ****: ####
####
Hostname: ####
rt#sh dhcp server
DHCP server: ANY (255.255.255.255)
Leases: 2
Offers: 1 Requests: 2 Acks : 1 Naks: 0
Declines: 0 Releases: 0 Query: 0 Bad: 0
Forcerenews: 0 Failures: 0
DNS0: 68.105.28.11, DNS1: 68.105.29.11
TIME0 : 172.19.73.156 TIME1 : 172.19.73.157
Subnet: 255.255.255.0


My connection to COX is my connection to the public Internet. COX is breaking RFC by also putting RFC1918 addresses on this portion of the public Internet that are routable like this. It doesn't matter that they block these networks from their connections to higher tier ISPs, they should not be using them on their own public network either, as these addresses are mine or anyone else's to use as much as they are theirs to use.

TWX

beatfreaker wrote: »

TWX - saw your response on dslreports.com which sheds some more light. Weird for sure but looks like fun to figure out. I don't have an account there so I'll post your reply here and hope we can troubleshoot this here instead.

Yeah, what I don't get is with 100.64.0.0/10 set aside for carrier-grade NAT, there's really no need for them to use 10.0.0.0/8 or 172.16.0.0/12. Isn't over four million addresses enough to accomplish their goals?

networker050184

Technically that isn't their WAN it's on, it's their internal network which you are a customer of of.

TWX

networker050184 wrote: »

Technically that isn't their WAN it's on, it's their internal network which you are a customer of of.

Now you're just arguing semantics.

Flat-out, anyone may use any RFC1918 address on their own network so long as they do not impact other networks. RFC1918 addresses are not allowed to route outside of one's private network. That's why they are private addresses. I have literally as much right to use all of 10.0.0.0/8, all of 172.16.0.0.12, and 192.168.0.0/16 as they do, and they are not supposed to do anything that breaks my use of those networks.

If they are using them on their internal network, good design should not leak that to their customers. They claim that the customers always use 192.168.0.0/16. Well, they're wrong.

networker050184

Yes that's the point, that is their own network they are using them on. Just because you are their customer it doesn't mean that isn't their network anymore.

beatfreaker

Perhaps I spoke too soon. Cox manages their network much different from TWCs so any idea I might had is no longer valid. It's also super coincidental that your network 172.19.73.0/24 also just happens to overlap with the range where Cox probably places their cm provisioning network. Some googling also returned 172.19.73.55 as a DHCP server so Im guess they have lots of provisioning servers in this range.


I had no problem filtering inbound and outbound RFC 1918 with TWC as their DHCP and TFTP servers are on public IPs.




Your situation is still pretty interesting because it sounds like your router is actually completing DOCSIS/DHCP from their management network meant for modems. The short lease and single static route (prob for TFTP) is usally what modems do during initial registration. You should debug DHCP and look for options like tftp,config,tod, etc and let us know. That's pretty funny. Not for you though, sorry. Any reason why you don't want to relocate?

beatfreaker

TWX wrote: »

Yeah, what I don't get is with 100.64.0.0/10 set aside for carrier-grade NAT, there's really no need for them to use 10.0.0.0/8 or 172.16.0.0/12. Isn't over four million addresses enough to accomplish their goals?

No thanks to CGN. Seems like a solution looking for a problem. In term of addresses 4 million is actually not that much at all, especially for MSOs like Comcast who has like 22 million customers. On the flip side, one could also argue why would we so many private IPs that would waste? Realistically though we should really be pushing forward with IPv6.

pevangel

Every ISP I've worked with has used RFC1918 in their network in some fashion. I'm curious what RFC do you think they're breaking. The we do what we want attitude is pretty understandable. They're not going to change how they do things because of one residential customer having issues. What exactly did you expect them to do?

TWX

I expect them, as my Internet Service Provider, to not route RFC1918 addresses to me. I do not care if they route them internally among their own network, but I should never see them. RFC1918 addresses in their private network should not cross the public network that I connect to, just as my private network should not leak any RFC1918 addresses on to the public network that I am connected to.

The network that I connect to when I connect to COX is "The Internet". I'm not paying to have a connection to COX, I'm paying for a connection to the Internet.

pevangel

You keep saying "should". Based on what? You keep mentioning that they are breaking RFC. Which one?

They are not going to completely change how they do things because of one residential customer. Specially when the customer can just change to the 192.168/16 block to solve their problem.