METHOD AND APPARATUS FOR ACCOMMODATING DUPLICATE MAC ADDRESSES
Each access node is associated with one or more IP subnets with a preferred default subnet. Each subnet is instantiated as a unique virtual Ethernet broadcast domain. As client nodes register on the communication network, they will dynamically try to obtain an IP address for use on the communication network. As part of this process, the MAC address of the client node will be checked to ensure that it is not a duplicate of another MAC address associated with another client node that has already been assigned an IP address from the default subnet. When duplicate MAC addresses are detected, the device with the duplicate MAC address will be assigned an IP address from a different subnet so that more than one client device with the same MAC address are not associated with the same subnet.
Latest Rockstar Bidco, LP Patents:
- Web services interface
- COMMUNICATION METHODS AND APPARATUS FOR ONLINE GAMES
- Methods of establishing virtual circuits and of providing a virtual private network service through a shared network, and provider edge device for such network
- Communication methods and apparatus for online games
- MANAGEMENT OF QUEUES IN CONTACT CENTRES
This application is a continuation of co-pending U.S. patent application Ser. No. 12/429,210, filed on Apr. 24, 2009, entitled METHOD AND APPARATUS FOR ACCOMMODATING DUPLICATE MAC ADDRESSES, which is hereby incorporated herein by reference in its entirety.
TECHNICAL FIELDThe present invention relates to communication networks, and, more particularly, to a method and apparatus for accommodating duplicate MAC addresses on a communication network.
BACKGROUNDData communication networks may include various computers, servers, nodes, routers, switches, bridges, hubs, proxies, and other network devices coupled to and configured to pass data to one another. These devices will be referred to herein as “network elements.” Data is communicated through the data communication network by passing protocol data units, such as Internet Protocol packets, Ethernet Frames, data cells, segments, or other logical associations of bits/bytes of data, between the network elements by utilizing one or more communication links between the network elements. A particular protocol data unit may be handled by multiple network elements and cross multiple communication links as it travels between its source and its destination over the network.
The various network elements on the communication network communicate with each other using predefined sets of rules, referred to herein as protocols. Different protocols are used to govern different aspects of the communication, such as how signals should be formed for transmission between network elements, various aspects of what the protocol data units should look like, how protocol data units should be handled or routed through the network by the network elements, and how information such as routing information should be exchanged between the network elements.
Ethernet is a well known networking protocol that has been defined by the Institute of Electrical and Electronics Engineers (IEEE) as standards 802.1 and 802.3. Conventionally, Ethernet has been used to implement networks in enterprises such as businesses and campuses, and other technologies have been used to transport network traffic over longer distances. As the Ethernet standards have evolved over time, Ethernet has become more viable as a long distance transport technology as well.
The Ethernet standard has evolved to also allow for a second encapsulation process to take place as specified in IEEE 802.1ah. Specifically, an ingress network element to a service provider's network may encapsulate the original Ethernet frame with an outer MAC header including a destination address on the service provider's network (B-DA), a source address on the service provider's network (B-SA), a VLAN ID (B-VID) and a service instance tag (I-SID). The combination of the customer MAC addresses (C-SA and C-DA) and the I-SID are commonly referred to as the I-Tag.
The Ethernet Media Access Control (MAC) address forms part of the Ethernet header. In a given broadcast domain such as an Ethernet LAN, each MAC address is required to be unique and identifies a particular networking entity so that frames can be unambiguously forwarded to that particular entity.
The MAC addressing scheme is designed to enable the MAC addresses to be globally unique. Specifically, the IEEE specifies a numbering scheme in which universally administered addresses are assigned to particular devices by the manufacturer when the devices are created. In the IEEE numbering scheme, the first two bits are set aside for local/multicast frame indication, and the remainder of the first three octets of the MAC address are referred to as the Organizationally Unique Identifier (OUI), and identify the manufacturer. An OUI code-point is assigned by the IEEE to a manufacturer as needed. The last three bytes are assigned by the manufacturer to the devices as they are created and burned into the devices so that each device created by that manufacturer will have a unique MAC address.
In general, manufacturers have adhered to this numbering scheme to create devices that have globally unique permanent MAC addresses. However, unfortunately, not every manufacturer has adhered to this convention. Thus, devices with duplicate MAC addresses are starting to appear. This is problematic for normal bridging, which “learns” the forwarding path to a given MAC address by bridges that receive a frame each observing and storing the port of arrival for traffic from that MAC address, and hence if multiple identical addresses appear in a bridged domain, the frame forwarding for a given MAC address will always go to the most recent source of a frame with that MAC address as source.
Typically, duplicate MAC addresses is more a problem with low cost consumer appliances than it is with very expensive network routers, etc., that are deployed within a service provider's network. When such low cost appliances are networked via a broadband access network that preserves the Ethernet frame content, duplicate addresses can become a problem and interfere with the correct operation of the network. Accordingly, one way that has been proposed to handle the possibility of duplicate MAC addresses appearing on a broadcast domain is to perform MAC Network Address Translation (NAT) in the access node where the customer devices connect to the service provider's network. This process enables any duplicate MAC address to be translated to a carrier administered globally unique value so that duplicate addresses do not appear within the service provider's network.
Unfortunately, MAC NAT is not trivial. Particularly in IPv6, where the MAC address becomes part of the IP address, performing MAC NAT is complex. Additionally, keeping the MAC NAT functionality in the access node up to date, which includes the awareness of new protocols, may require significant maintenance and ongoing software development. Accordingly, it would be desirable to provide another way to accommodate duplicate MAC addresses in a communication network.
SUMMARYEach access node is associated with one or more IP subnets with a preferred default subnet. Each subnet is instantiated as a unique virtual Ethernet broadcast domain. As client nodes register on the communication network, they will dynamically try to obtain an IP address for use on the communication network. As part of this process, the MAC address of the client node will be checked to ensure that it is not a duplicate of another MAC address associated with another client node that has already been assigned an IP address from the default subnet. When duplicate MAC addresses are detected, the device with the duplicate MAC address will be assigned an IP address from a different subnet so that more than one client device with the same MAC address are not associated with the same subnet. In one embodiment, a DHCP server may implement the process of checking for duplicate MAC addresses. In an Ethernet context, different IP subnet prefixes may be mapped to different S-VID values so that the different subnets are implemented as different VLANs within the Ethernet network.
Aspects of the present invention are pointed out with particularity in the appended claims. The present invention is illustrated by way of example in the following drawings in which like references indicate similar elements. The following drawings disclose various embodiments of the present invention for purposes of illustration only and are not intended to limit the scope of the invention. For purposes of clarity, not every component may be labeled in every figure. In the figures:
MAC addresses are required to be unique within a subnet so that traffic transmitted within the subnet can unambiguously be transmitted to particular nodes. In one embodiment, as client nodes connect to the communication network, they will register to obtain an IP address for use on the communication network. As part of this process, the MAC address of the client node will be checked to ensure that it is not a duplicate of another MAC address associated with another client node that has already been assigned an IP address for a particular subnet. When duplicate MAC addresses are detected, the device with the duplicate MAC address will be assigned an IP address from a different subnet so that more than one client device with the same MAC address is not associated with the same subnet. In one embodiment, a centralized address server (typically a DHCP server) may implement the process of checking for duplicate MAC addresses. In an Ethernet context, different IP subnet prefixes may be mapped to different S-VID values (IEEE 802.1 ad) or I-SID values (IEEE 802.1ah) so that the different subnets are implemented as different VLANs within the Ethernet network.
Although an embodiment of the invention will be described with reference to an example where the duplicate MAC addresses appear on client nodes, the invention is not limited in this manner as duplicate MAC addresses may appear at other locations on the network. Thus, the techniques described herein may be extended to apply in other regions of the network as well.
In an access network it is common for an access provider to scale the solution by having multiple customers share a common S-VID and subnet prefix and employing bridging techniques for multiplexing/demultiplexing traffic between customers and the BRAS. This minimizes S-VID consumption and IP address fragmentation respectively. There is also a requirement that customers do not have layer 2 reachability of each other within the scope of an S-VID such that the BNG can be the primarily policy agent for connectivity. This requires access nodes and, potentially aggregation nodes to implement split horizon forwarding.
Although it is possible for “well behaved” clients to observe that they are not unique when they can see neighbor traffic, and possibly take corrective action, we need to consider that clients cannot see each other, and we need to assume the presence of potentially malicious clients. Hence a solution that does not require the cooperation of any network attached customer equipment is required.
If the network interconnecting the access nodes and the BRAS is an Ethernet network, traffic on the Ethernet network may be separated into separate VLANs by using different S-VIDs (for an Ethernet network implemented using 802.1ad) or different I-SIDs (for an Ethernet network implemented using 802.1ah). This means that the layer 3 subnets are virtualized at the Ethernet layer. Common practice is to tie this virtualization to specific facilities (e.g. an S-VID per individual access node) but this is not a requirement. The result is Hub-and-Spoke connectivity between the BRAS and the access nodes.
Each of the subnets will form a particular broadcast domain. Accordingly, it is important that each of the client devices 14 within a given subnet has a unique MAC address. In the example shown in
However, access node 1 has two client nodes that have the same MAC address. Specifically, in the example shown in
To enable traffic on different subnets to be broadcast within the Ethernet domain, a different S-VID or other VLAN identifier may be assigned to each subnet. The BRAS and access nodes may be programmed to associate prefixes from different subnets with these VLAN tags so that traffic addressed to a particular subnet is correctly tagged for transport on the Ethernet network.
In each of
Although implementation of duplicate MAC address checking may be conveniently performed in the DHCP server, the invention is not limited to an embodiment that implements this process in the DHCP server. For example, the access nodes may be provided with a range of S-VIDs and client devices may be assigned to a subnet (S-VID) before obtaining an IP address from the DHCP server. In this embodiment the access nodes may check for duplicate MAC addresses and assign client devices to different subnets as necessary to prevent two client devices with the same MAC address from being assigned to the same subnet. Alternatively numerous other centralized address administration systems exist (e.g. RADIUS based) that could similarly perform the required function.
In one embodiment, the DHCP server preferentially performs subnet assignment for a given request on the basis of both location, and whether the MAC address already exists on the default sub-network. Use of a DHCP server is advantageous since it is a central facility and can therefore coordinate subnets that span multiple access nodes. The DHCP server, in this embodiment, will have a default subnet associated with each access facility from which to assign IP addresses. This allows the DHCP server to assign IP addresses out of the subnet assigned to the access node or client port during the normal course of events, when the MAC address associated with the DHCP request is unique within the access node. The DHCP server will also assign IP addresses out of other subnets for duplicate MAC addresses to prevent more than one instance of a particular MAC address to be assigned to a given subnet.
The access node, in one embodiment, does not keep track of the MAC addresses or know that more than one of its attached client nodes has duplicate MAC addresses. The access node does implement a DHCP relay agent such that it will have opportunity to inspect/modify DHCP transactions as they flow between the client and the server. When the access node receives an offered IP address, the access node will infer the correct VLAN tagging (or IEEE 802.1ah I-SID tagging) to use for the subscriber client node based on the subnet prefix offered by the DHCP server.
When the DHCP server receives the DHCP request, it will determine the current subnet associated with the facility and perform a search to look for duplicate MAC address in the set of leases already existing for that subnet (104). Specifically, the DHCP server will look to determine if the MAC address of the client node is unique within a subnet assigned to the access node (106). If the MAC address is unique, the DHCP server will assign the device an IP address lease from pool of unused addresses for the subnet and update its tables accordingly (108). If the MAC address is not unique, the DHCP server will assign the facility to another subnet where that MAC address is unique and allocate an IP address lease to the client node from pool of unused addresses for that subnet.
The DHCP server has a default subnet associated with all facilities on each access node, so that the DHCP server will generally assign IP addresses out of the subnet for the access node when the client nodes attaching to the network do not have duplicate MAC addresses. An example DHCP server is shown in
As shown in
When the DHCP server receives a request from an access node, it will use the tables 74 to determine if the associated MAC address is unique for the current subnet associated with the facility. If the MAC address is unique, the DHCP server will allocate an address from the current subnet for the facility and send the IP address back to the client node. If the MAC address is not unique, the DHCP server will find a subnet where the MAC address is unique and allocate an address from the different subnet where the MAC address is unique. If there is not an available subnet, a means of communicating denial of service will be used. This could be a reserved address which instructed the access node to block the port. An example would be the IPv4 127./8 non-routable prefix.
To enable traffic associated with the MAC address to be mapped to the correct subnet, the access nodes and gateway BRAS are both pre-programmed with a table associating IP prefix with VLAN IDs. In an Ethernet network implemented using IEEE 802.1ad the VLAN IDs may be implemented using S-VIDs. Where the Ethernet network is implemented using IEEE 802.1ah, other VLAN IDs may be used as well, such as the I-SID. Thus, the particular VLAN ID may depend on the particular implementation of the Ethernet network being used to carry traffic between the BRAS and the access nodes.
Assuming the Ethernet network is implemented using IEEE 802.1ad, the DHCP relay function in the access node will read the prefix from the DHCP response and use this to infer the S-VID from the VLAN ID/prefix table. This S-VID will then be associated with the client port so that traffic received from the client can be correctly tagged for transmission on the network.
When downstream traffic received at the access node is tagged with the S-VID or I-SID, the access node can either broadcast the traffic on any port associated with that S-VID/I-SID, or the access node can perform a MAC lookup to determine which output port to use to forward the traffic to the correct client node. Since each client device is represented by a unique MAC within the subnet, tagging each subnet with a different VLAN ID (e.g. S-VID) enables the access node to perform a MAC lookup and unambiguously determine the correct output port, even where more than one client node with the same MAC address has attached to the same access node.
If an access node has not registered interest in the S-VID or I_SID associated with a facility, or does not have a-priori pre-provisioned connectivity, it may have to use registration techniques such as Generic Attribute Registration Protocol (GARP) or Multiple Registration Protocol (MRP) to add the access node to the subnet. MRP is specified in IEEE 802.1ak-2007. Other ways of registering interest in an S-VID may be implemented as well.
When all the leases associated with a given option 82 identified facility (e.g. customer facing port) expire, the subsequent assignment of IP addresses may revert back to the default subnet associated with the facility. This enables subnet fragmentation to be reduced by collecting MAC addresses back to the default subnet assigned to the option 82 facility where there is no longer a duplicate MAC address issue. The goal is not to make correcting duplicates permanent as the equipment deployed by the client may change over time.
If a duplicate MAC appears and requests a lease on a facility that already has a lease on the default subnet initiated by an earlier registration, the DHCP server is required to consider the set of MAC addresses associated with the facility when determining which subnet to assign, the set requiring uniqueness within the assigned subnet. In addition the DHCP server will issue a DHCP-FORCE-RENEW for the existing lease in order to force the current leaseholder to reapply, so that at the time that the new registration transactions are received, the current subnet associated with the facility can be reselected to be one where the set of MAC addresses associated with the facility will be unique.
Although it is desirable to avoid permanent binding of a facility with a duplicate MAC to a non-default subnet, the use of DHCP-FORCE-RENEW represents a service disruption to the leaseholder. The impact of this can be minimized by making the binding “sticky”, and associating a facility with a non-default subnet for a programmable period, reset each time duplication with a MAC on the default subnet is detected, after which the association is aged out.
The functions described above may be implemented as a set of program instructions that are stored in a computer readable memory and executed on one or more processors on the computer platform. However, it will be apparent to a skilled artisan that all logic described herein can be embodied using discrete components, integrated circuitry such as an Application Specific Integrated Circuit (ASIC), programmable logic used in conjunction with a programmable logic device such as a Field Programmable Gate Array (FPGA) or microprocessor, a state machine, or any other device including any combination thereof. Programmable logic can be fixed temporarily or permanently in a tangible medium such as a read-only memory chip, a computer memory, a disk, or other storage medium. All such embodiments are intended to fall within the scope of the present invention.
It should be understood that various changes and modifications of the embodiments shown in the drawings and described in the specification may be made within the spirit and scope of the present invention. Accordingly, it is intended that all matter contained in the above description and shown in the accompanying drawings be interpreted in an illustrative and not in a limiting sense. The invention is limited only as defined in the following claims and the equivalents thereto.
Claims
1. A method of allocating Internet Protocol (IP) addresses to client devices, the method comprising:
- receiving requests for IP addresses for a plurality of client devices, each client device being associated with a respective Media Access Control (MAC) address and with a respective facility having a respective default subnet; and
- allocating respective IP addresses to the client devices based, at least in part, on the respective MAC addresses of the client devices, the allocated IP addresses for some of the client devices being associated with the respective default subnets of the facilities with which the some of the client devices are associated, and the allocated IP addresses for others of the client devices being associated with subnets different from the respective default subnets of the facilities with which the others of the client devices are associated.
2. The method of claim 1, wherein client devices having a same MAC address are allocated respective IP addresses associated with different subnets.
3. The method of claim 2, wherein allocating the respective IP addresses comprises, when the client devices having the same MAC address are associated with a same facility, allocating to one of the client devices having the same MAC address an IP address associated with a default subnet of the same facility and allocating to each other client device having the same MAC address an IP address associated with a respective subnet different from the default subnet of the same facility.
4. The method of claim 1, wherein allocating the respective IP addresses comprises:
- for a client device for which an IP address has been requested, the client device being associated with a respective MAC address and a respective facility, determining whether another client device associated with a same MAC address and a same facility has currently been allocated an IP address associated with a default subnet of the same facility; and
- when another client device associated with the same MAC address and the same facility has currently been allocated an IP address associated with the default subnet of the same facility, allocating an IP address associated with a subnet other than the default subnet of the same facility to the client device for which the IP address has been requested.
5. The method of claim 4 wherein allocating the respective IP addresses comprises, when another client device associated with the same MAC address and the same facility has not currently been allocated an IP address associated with the default subnet of the same facility, allocating an IP address associated with the default subnet of the same facility to the client device for which an IP address has been requested.
6. The method of claim 1, wherein the requests for the IP addresses are received and the IP addresses are allocated by a centralized server.
7. The method of claim 6, wherein the centralized server is a dynamic host configuration protocol (DHCP) server.
8. The method of claim 1, wherein each facility is associated with a respective access node.
9. The method of claim 8, wherein the each facility connects to the respective access node via a respective physical or virtual port of the respective access node.
10. The method of claim 8, wherein each respective access node supports multiple facilities.
11. A network element for allocating Internet Protocol (IP) addresses to client devices, the network element comprising:
- at least one communication interface configured to receive requests for IP addresses for client devices, each client device being associated with a respective Media Access Control (MAC) address and with a respective facility having a respective default subnet; and
- at least one IP address allocation element configured to allocate respective IP addresses to the client devices, the allocated IP addresses for some of the client devices being associated with the respective default subnets of the facilities with which the some of the client devices are associated, and the allocated IP addresses for others of the client devices being associated with subnets different from the respective default subnets of the facilities with which the others of the client devices are associated.
12. The network element of claim 11, wherein the at least one IP address allocation element is configured to allocate to client devices having a same MAC address respective IP addresses associated with different subnets.
13. The network element of claim 12, wherein the at least one IP address allocation element is configured to allocate respective IP addresses by, when client devices having the same MAC address are associated with a same facility, allocating to one of the client devices having the same MAC address an IP address associated with a default subnet of the same facility and allocating to each other client device having the same MAC address an IP address associated with a respective subnet different from the default subnet of the same facility.
14. The network element of claim 11, wherein the at least one IP address allocation element is configured to allocate respective IP addresses by:
- for a client device for which an IP address has been requested, the client device being associated with a respective MAC address and a respective facility, determining whether another client device associated with a same MAC address and a same facility has currently been allocated an IP address associated with a default subnet of the same facility; and
- when another client device associated with the same MAC address and the same facility has currently been allocated an IP address associated with the default subnet of the same facility, allocating an IP address associated with a default subnet other than the default subnet of the same facility to the client device for which the IP address has been requested.
15. The network element of claim 14, wherein the at least one IP address allocation element is configured to allocate respective IP addresses by, when another client device associated with the same MAC address and the same facility has not currently been allocated an IP address associated with the default subnet of the same facility, allocating an IP address associated with the default subnet of the same facility to the client device for which an IP address has been requested.
16. The network element of claim 11, implemented in a centralized server.
17. The network element of claim 16, implemented in a dynamic host configuration protocol (DHCP) server.
18. The network element of claim 17, wherein the at least one IP address allocation element runs at least one DHCP process.
19. The network element of claim 17, comprising a table containing associations between facilities and subnets assigned to the facilities.
20. The network element of claim 17, comprising at least one table configured to associate MAC addresses with respective facilities and subnets.
Type: Application
Filed: Jul 12, 2012
Publication Date: Jan 10, 2013
Applicant: Rockstar Bidco, LP (New York, NY)
Inventors: David Allan (Ottawa), Nigel Bragg (Weston Colville)
Application Number: 13/547,326
International Classification: G06F 15/16 (20060101);