| Author: | John.Marshall@riverwillow.com.au |
|---|---|
| Date: | 25-May-2004 |
| Revised: | 11-Jun-2004 |
This page describes what I have observed in the context of our own BigPond Broadband Cable connection. My observations are offered for the interest of others and are confined to the following context:
Related findings from subsequent experience are documented in a subsequent article, HFC Channels and IP Addressing.
As at 25 May 2004, Telstra BigPond Broadband Cable provide no information on the IP network behind their DOCSIS Cable Network deployment; and no help for subscribers with firewalls. I hope that the information provided on this page may obviate the need for at least some other BigPond Cable subscribers to have to figure this out from first principles - or to have to spend days getting nowhere with the BigPond Cable Helpdesk.
We are one of the many subscribers who have been sent one of the new Motorola SURFboard SB5100 DOCSIS Cable Modems to replace the superseded CDLP Cable Modems. Telstra BigPond Broadband provide instructions for the "straightforward process" of changing to the new modem. For subscribers with a single home PC and no firewall this process really is that simple, but if you have a firewall (and BigPond Broadband "strongly recommend" that their subscribers use firewalls) then you quickly discover that the network beyond the new modem is very different.
The basic problem is Lack of Information. With the advent of DOCSIS, we need to know that we need to talk to "private" IP addresses on the "Internet". BigPond Broadband did not/does not/will not tell us that the BigPond Broadband Cable DOCSIS network uses RFC1918 private IP addressing (even although this appears to be the usual means of deployment on any vendor's network). Subscribers who have their networks secured to prevent RFC1918 traffic leaving or entering their network will find that they are unable to obtain or renew DHCP leases from the BigPond DOCSIS network.
This block diagram may help make things clearer.
The DOCSIS architecture allows the Cable Network provider to manage all of the cable modems on its network. It uses a private network for that purpose. A Universal Broadband Router (UBR) at the Head End acts as the gateway for this network. In our case (Western Sydney), the address of our local UBR is private IP address 10.128.136.1.
When each DOCSIS cable modem boots, it acquires an IP address on the RF (cable) side via DHCP. The modem's cable-facing IP address is allocated via DHCP from the private 10.128.x.x network. The BOOTP information returned to the cable modem tells it the address of a TFTP server and the name of a configuration file to load. This means that BigPond Broadband control and manage the configuration of all of the cable modems on their network.
After the cable modem has booted, it will bridge DHCP traffic from the subscriber side of the modem through to the UBR. The UBR is configured as a DHCP relay. The UBR forwards the subscriber's DHCP request through to the BigPond Broadband DHCP server. The DHCP reply is relayed to the subscriber by the UBR, so the subscriber receives the initial DHCP configuration from the private 10.x.x.1 address.
The IP configuration information provided to the subscriber via DHCP includes the address of the BigPond Broadband DHCP server. In our case, the DHCP server is at private IP address 172.18.18.80. In order for the subscriber equipment to renew its DHCP lease, the subscriber equipment must route traffic to the DHCP server's private address via the cable modem.
If Telstra would publish this information, there would be no problem. We need to know the primary IP address of the UBR's RF interface because that is the address which is configured as the DHCP relay or "IP Helper". The way to discover the primary address of your local UBR will depend upon the type of equipment or firewall you have in service. It may mean logging dropped DHCP packets (Source = any UDP Port 67; Destination = 255.255.255.255 UDP Port 68); it may mean enabling a DHCP debugging trace; it may mean opening up the firewall to permit incoming BOOTP replies to 255.255.255.255. In our case, the UBR address is 10.128.136.1. My guess is that 10.128.0.0/16 would be a good starting point.
If your equipment/firewall dictates that you fall into the "trial and error" category, then you can discover the UBR's IP address after your equipment receives its initial IP address. As soon as your equipment has received its DHCP lease, start your BPA login client, wait for successful login, and then perform a traceroute to a favourite Internet address. The first hop shown on the traceroute (beyond your own network) will be the UBR. It will respond to the traceroute from its primary RF-facing IP address (e.g. 10.128.136.1).
Once you have discovered the UBR's primary IP address, you can lock down your equipment to permit incoming DHCP replies from that private IP address only. I know this sounds like I'm stating the obvious, but I stress this because you probably have a filter defined to BLOCK traffic from the 10.0.0.0/8 network. You will therefore need to explicitly permit traffic from the UBR (DHCP relay) and make sure that the rule takes precedence over the block rule. Since traffic from the DHCP relay address will only ever be inbound (in response to a broadcast request) there is no need to define a route to that address.
The IP address of the BigPond Broadband DHCP server is included in the IP configuration downloaded to your equipment. Use the appropriate incantation for your operating system to list IP configuration or DHCP lease information and you should find it. In our case, the BigPond Broadband DHCP server is at private IP address 172.18.18.80.
Unless you configure your equipment to talk to the DHCP server, you will not be able to renew your DHCP lease and your equipment will lose its IP address every few hours - and go through the DHCP discover process all over again.
If you are using filtering, you will need to permit traffic outbound to, and inbound from, UDP port 67 on the DHCP server's address. If you are using a firewall, then you will need to permit outbound traffic from UDP port 68 to UDP port 67 on the DHCP server - and make sure that there is a corresponding reflexive rule that opens the firewall to listen for the response. I know this sounds like I'm stating the obvious, but I stress this because you probably have a filter defined to BLOCK traffic to and from the 172.16.0.0/12 network. You will therefore need to explicitly permit traffic to and from the DHCP server and make sure that the rule takes precedence over the block rule.
Why? Don't I already have my default route pointing at the cable network? Yes, but you probably also have a route defined to swallow traffic directed to 172.16.0.0/12. If this is the case, then you will still not find the DHCP server (even if you have the correct filters or rules configured). You will need to define an explicit host route to the DHCP server (e.g. 172.18.18.80/32) via the cable network.
Perhaps I have just been looking in all the wrong places, but I have found it very difficult to find helpful material on this subject.
| 25-May-2004 | Original Document |
|---|---|
| 29-May-2004 | Added block diagram and provided link from this page |
| 11-Jun-2004 | Added Document Revision History. Added context notice at top of page |
