Technique for automated MAC address cloning

- AT&T

In an arrangement where the device that is known to an ISP is communicating with the ISP through an interposed device that is not known to the ISP, the interposed device captures the known device's MAC address upon startup and clones the captured MAC address in all standard packets that it sends to the ISP.

Skip to: Description  ·  Claims  ·  References Cited  · Patent History  ·  Patent History
Description
RELATED APPLICATIONS

This Application is a continuation of application Ser. No. 12/011,751 filed in the USPTO on Jan. 29, 2008, now U.S. Pat. No. 7,787,455, which application is a continuation of U.S. application Ser. No. 11/033,930, filed Jan. 12, 2005, now U.S. Pat. No. 7,342,945, which claims priority of Provisional Ser. No. 60/631,633 filed Nov. 30, 2004.

BACKGROUND

This invention relates to communication over the Internet, and more particularly to establishing IP addresses for subscriber devices.

Internet Service Providers (ISPs) supply a public IP address upon request to a subscriber's IP device (e.g., PC NIC card). This request is most commonly made at startup of the IP device, when the device sends a Dynamic Host Configuration Protocol (DHCP) Broadcast Discover message, requesting IP Address offers from any DHCP server that is listening. In response to the DHCP Broadcast Discover message one or more DHCP Offer messages are received at the subscriber's IP device, the IP device chooses the offer of one of the responding servers, and sends a DHCP Request message to the chosen server. The chosen server sends back an Acknowledgement (ACK) message, and communication thereafter proceeds.

Cable companies that offer Internet access through cable modems bridge DHCP Discover messages that are received by a modem onto a Data Over Cable System Interface Specification (DOCSIS) channel, where the cable modem identifies itself to a cable modem termination system (CMTS) by providing its Media Access Control (MAC) address. The CMTS thus receives both the DHCP Discover message from an IP device that is connected to the cable modem and the cable modem's MAC address. When a subscriber's IP device, such as a PC, connects to the cable company's ISP server, the cable company can therefore establish a correspondence between the MAC address of the subscriber's cable modem and the MAC address of the subscriber's IP device. Thereafter, knowing the MAC address that is expected to be found in DHCP Discover messages coming from the subscriber's cable modem, a cable company can choose to decline providing an IP address in response to a DHCP Discover message with an unexpected MAC address. Declining to provide an IP address is a measure of security that prevents an interloper's IP device from obtaining service. Consequently, however, when a legitimate subscriber wants to change the IP device or add an interposed device, the subscriber needs to contact the ISP (e.g., by telephone), and have the ISP clear the existing MAC addresses association, so that a new association can be established.

The fact that anytime the subscriber wants to add a new IP end-device such as a new PC, a home-router, or some other device, the subscriber needs to contact the ISP represents a significant inconvenience. A solution is to mimic, or clone, the MAC address of the old device in the new end-device, but this also presents a hassle for the subscriber because currently available devices need to be manually configured to perform such cloning.

SUMMARY

An advance in the art is achieved in an arrangement where the device that is known to the ISP is communicating with the ISP through an interposed device that is not known to the ISP by having the interposed device automatically clone the known device's MAC address in its communications with the ISP. This is achieved by the interposed device capturing the MAC address of the known device at startup and employing the captured MAC address in all standard packets that are sent to the ISP.

BRIEF DESCRIPTION OF THE DRAWING

FIG. 1 presents a messages flow chart in accord with the principles disclosed herein;

FIG. 2 presents an alternate messages flow chart; and

FIG. 3 shows an arrangement of an interposed device that supports both a PC and an IP telephone.

DETAILED DESCRIPTION

Many ISPs track a user's MAC address as a crude security measure, but the idea of cloning a MAC address has made this security measure more of a hassle than an effective measure. Home Router manufacturers embraced the idea of cloning in order to keep their buyers from having to reset this MAC with the ISP. However, the subscriber has to locate and identify the MAC address of his or her PC, and use this information to manually set up cloning in the router. To a novice this setup can be challenging, and circumventing it would provide a much better customer experience.

The present disclosure relates to an arrangement where a subscriber's PC (or other IP device) has already been configured to work with the ISP, and where the subscriber interposes a new device between the subscriber's PC and the cable modem. Home Routers (HR), Media Terminal Adapters, and Telephone Adapters are examples of such interposed devices, each possessing its own MAC address.

Although interposed devices have their own MAC addresses, to meet the objective of this invention an interposed device needs to automatically assume the MAC address of the PC that is already known to the ISP's server whenever the interposed device communicates with the ISP server.

In accordance with the illustrative approach depicted in FIG. 1, when the user's IP device is powered on at step 10, the TCP/IP interface of the IP device sends out a DHCP Discover message to acquire an IP address. It is a request to receive an IP address by selecting from one or more DHCP Offer messages that might arrive from listening DHCP servers. In step 11 the interposed device captures the DHCP Discover message and extracts therefrom the MAC address. In step 12 the interposed device creates its own DHCP Discover message, places the MAC address that was extracted from the DHCP Discover message sent by the IP device instead of its own MAC address, and in step 13 forwards the modified DHCP Discover message to the ISP. In step 14 the ISP sends to the interposed device a DHCP Offer message containing a public IP address and a DNS address, in step 15 the interposed device sends a DHCP Request message to the ISP, which effectively confirms its acceptance of the offered IP address, and in step 16 the ISP sends an ACK message, confirming the IP address that will be used. Thereafter, according to step 20 communication proceeds between the interposed device and the ISP, with the continued use of the cloned MAC address. The continued use of the cloned MAC address prevents an ISP from raising an alarm should it choose—in the course of the communication session—to check the MAC address of the device with which it is communicating.

Following step 16, or concurrently therewith, at step 17 the interposed device sends a DHCP Offer message to the subscriber's IP device, offering to the IP device a private IP address, and at steps 18-19 the interposed device and the IP device complete the IP acquisition protocol vis-à-vis the private IP address in the conventional manner described above.

FIG. 2 shows a slightly different approach. Specifically, as soon as the interposed device receives the initial DHCP Discover message in step 21, in step 22 it immediately offers the subscriber's IP device a private IP address, but with no DNS listed. The offer contains a very short lease time; for example, 10 sec. In step 23 the IP device follows up with the DHCP Request (since this is the only offer it received), and the interposed device completes the transaction with a DHCP ACK message in step 24.

The interposed device then turns to its task of establishing a connection to the ISP, extracts the MAC address of the IP device in step 11, creates its own DHCP Discover message with its MAC address replaced with the extracted MAC address of the IP device in step 12, and presents its created DHCP Discover message (with the cloned MAC address) to the ISP in step 13.

In the illustrative signal flow chart of FIG. 2, the lease time for the private IP address provided to the IP device expires shortly after the interposed device sends its created DHCP Discover message to the ISP. When the lease time thus expires, in step 25 the IP device sends a DHCP Request Renew message to the interposed device, asking to renew the lease. Since the interposed device has not yet received an IP address from the ISP, the interposed device sends a DHCP ACK message to the IP device in step 26, renewing the lease for another short interval.

Eventually, the communication between the interposed device and the ISP (steps 14, 15, and 16) completes, and the interposed device is in possession of a public IP address and DNS address. Thereafter, when the IP address lease of the IP device expires again and the IP device sends a DHCP Request Renew message in step 27, the interposed device responds in step 28 with a DHCP NACK message that denies use by the IP device of the previously provided private IP address. Having received a negative acknowledgement message, the subscriber's IP device sends a new DHCP Discover message in step 29, in response to which in step 30 the interposed device sends a DHCP Offer message that is complete with DNS address(es), and the same or a different private IP address. The IP device then sends a DHCP Request message in step 31, and the interposed device responds with a DHCP ACK message in step 32.

The interposed device can be viewed to have an upstream side that is connected to the ISP through a modem, and a downstream side that is connected to a subscriber's IP device with a MAC address that is known to the ISP. On the upstream side the interposed device behaves like a client relative to the ISP. On the downstream side the interposed device behaves like a server relative to the subscriber's IP device, and any other device that is connected to the interposed device on the downstream side thereof, such as illustrated for example in FIG. 3 where a PC and a telephone are connected to the downstream side of the interposed device. For sake of simplicity, it is assumed that the telephone shown in FIG. 3 is an IP device. Of course, the shown telephone can be a conventional POTS telephone if the circuitry that is necessary for converting it to an IP device is included within the interposed device.

It is noted that the above-disclosed approach requires the PC with the MAC address that is known to the ISP to send a DHCP Discover message to the interposed device before any other of the IP devices that are connected to the downstream side of the interposed device. When this is done, other devices can send their own DHCP Discover message, obtain their own private IP address from the interposed device and communicate in a conventional manner. It is noted, however, that the communication with the ISP, as far as the ISP is concerned, is with the PC that is known to the ISP because, as shown in step 20 of both FIG. 1 and FIG. 2, subsequent communication from the interposed device to the ISP is with packets that employ the cloned MAC address.

The above discloses two illustrative approaches for automatically cloning the MAC address of a device that is known to an ISP, but it should be realized that other approaches can be implemented without departing from the spirit and scope of this invention. To illustrate, the private IP address that is provided to the PC (sans a DNS address) is shown in FIG. 2 to be provided immediately upon receipt DHCP Discover message 21, but it could just as validly be provided sometime later, such as after the MAC address is extracted.

Claims

1. A method, comprising:

obtaining, by an interposed internet protocol device, a media access control address from a user internet protocol device, wherein the media access control address is obtained by receiving a first dynamic host configuration protocol discover message that includes the media access control address from the user internet protocol device, wherein the obtaining further comprises extracting the media access control address from the first dynamic host configuration protocol discover message that is received;
receiving, by the interposed internet protocol device, a first dynamic host configuration protocol request message from the user internet protocol device;
sending, by the interposed internet protocol device, a first dynamic host configuration protocol acknowledgement message to the user internet protocol device;
sending, by the interposed internet protocol device to an internet service provider, a second dynamic host configuration protocol discover message that includes a media access control address from a second user internet protocol device that is different from the media access control address that is extracted from the first dynamic host configuration protocol discover message and is different from a media access control address of the interposed internet protocol device, wherein the media access control address from the second user internet protocol device has previously been extracted by the interposed internet protocol device from a third dynamic host configuration protocol discover message from the second user internet protocol device;
receiving, by the interposed internet protocol device from the internet service provider, a first dynamic host configuration protocol offer message based on the media access control address from the second user internet protocol device, the first dynamic host configuration offer message including a public internet protocol address and a domain name system address;
sending, by the interposed internet protocol device, an interim dynamic host configuration protocol offer message that includes a private internet protocol address, a lease time and a blank domain name service address;
receiving, by the interposed internet protocol device, an interim dynamic host configuration protocol request message from the user internet protocol device in response to the interim dynamic host configuration protocol offer message;
sending, by the interposed internet protocol device, a first interim dynamic host configuration protocol acknowledgement message to the user internet protocol device;
providing, by the interposed internet protocol device, a second dynamic host configuration protocol offer message to the user internet protocol device, wherein the interposed internet protocol device connects to the internet service provider via a cable modem;
sending, by the interposed internet protocol device to the internet service provider, a second dynamic host configuration protocol request message that confirms an acceptance of the public internet protocol address; and
receiving, by the interposed internet protocol device from the internet service provider, a second dynamic host configuration protocol acknowledgement message,
wherein the second dynamic host configuration protocol acknowledgement message that is received from the internet service provider confirms that the internet protocol address will be used by the internet service provider.

2. The method of claim 1, wherein the second dynamic host configuration protocol offer message contains a private internet protocol address and the domain name system address.

3. The method of claim 1 where the interposed internet protocol device is a router.

4. The method of claim 1, where the interposed internet protocol device is a media terminal adapter.

5. The method of claim 1, where the interposed internet protocol device is a telephone adapter.

6. The method of claim 1, further comprising, when the lease time expires prior to the interposed internet protocol device receiving the second dynamic host configuration protocol acknowledgement message:

sending a second interim dynamic host configuration protocol acknowledgement message to the user internet protocol device that provides for a renewed lease time.

7. The method of claim 1, further comprising, when the lease time expires after the interposed internet protocol device receives the second dynamic host configuration protocol acknowledgement message:

sending a dynamic host configuration protocol negative acknowledgment message to the user internet protocol device that denies use of the private internet protocol address that was previously included in the interim dynamic host configuration protocol offer message;
receiving a responsive dynamic host configuration protocol discover message from the user internet protocol device;
sending a final dynamic host configuration protocol offer message to the user internet protocol device;
receiving a responsive dynamic host configuration protocol request message; and
sending a final dynamic host configuration protocol acknowledgement message to the user internet protocol device.

8. The method of claim 1, further comprising:

receiving from the user internet protocol device a dynamic host configuration protocol request-to-renew message when the lease time expires.
Referenced Cited
U.S. Patent Documents
6223222 April 24, 2001 Fijolek et al.
6577642 June 10, 2003 Fijolek et al.
6657991 December 2, 2003 Akgun et al.
6847704 January 25, 2005 Cherchali et al.
7068597 June 27, 2006 Fijolek et al.
7139818 November 21, 2006 Kinnear et al.
7143137 November 28, 2006 Maufer et al.
7263559 August 28, 2007 Yao et al.
7342925 March 11, 2008 Cherchali et al.
7508816 March 24, 2009 Everson et al.
7787455 August 31, 2010 Cherchali et al.
20020006137 January 17, 2002 Rabenko et al.
20020062485 May 23, 2002 Okano et al.
20020141389 October 3, 2002 Fangman et al.
20030133450 July 17, 2003 Baum
20030147395 August 7, 2003 Gutknecht et al.
20030147404 August 7, 2003 Mazo
20030172170 September 11, 2003 Johnson et al.
20030212773 November 13, 2003 Sullivan
20030212781 November 13, 2003 Kaneda et al.
20030233452 December 18, 2003 Maufer et al.
20040073600 April 15, 2004 Elo
20040177133 September 9, 2004 Harrison et al.
20040205211 October 14, 2004 Takeda et al.
20040219948 November 4, 2004 Jones et al.
20040230970 November 18, 2004 Janzen
20040249927 December 9, 2004 Pezutti
20040267949 December 30, 2004 Rover et al.
20050044273 February 24, 2005 Bouchat et al.
20050047355 March 3, 2005 Wood et al.
20050083908 April 21, 2005 Holder
20050149204 July 7, 2005 Manchester et al.
20050149626 July 7, 2005 Manchester et al.
20050198040 September 8, 2005 Cohen et al.
20050198233 September 8, 2005 Manchester et al.
20050201391 September 15, 2005 Ma et al.
20050243837 November 3, 2005 Boyd et al.
20060168280 July 27, 2006 Alexis
Foreign Patent Documents
1119139 May 1999 EP
WO 0171983 September 2001 WO
Patent History
Patent number: 9124474
Type: Grant
Filed: Jul 9, 2010
Date of Patent: Sep 1, 2015
Patent Publication Number: 20100274917
Assignee: AT&T Intellectual Property II, L.P. (Atlanta, GA)
Inventors: Ali Cherchali (Jackson, NJ), Marius J. Gudelis, Jr. (Holmdel, NJ), William G. Lester (Cranford, NJ), Robert J. McLaughlin (Allentown, NJ)
Primary Examiner: Alpus H Hsu
Assistant Examiner: Hooman Houshmand
Application Number: 12/833,296
Classifications
Current U.S. Class: Computer-to-computer Session/connection Establishing (709/227)
International Classification: H04L 29/12 (20060101);