WO2000044132A2

WO2000044132A2 - Secure and efficient address resolution for client stations connected over wide area network links to ip networks such as the internet

Info

Publication number: WO2000044132A2
Application number: PCT/SE2000/000145
Authority: WO
Inventors: Stephen Langstaff; Stephen Reynolds
Original assignee: Telefonaktiebolaget Lm Ericsson (Publ)
Priority date: 1999-01-25
Filing date: 2000-01-25
Publication date: 2000-07-27
Also published as: GB2363043A; AU2469700A; GB0120317D0; WO2000044132A3

Abstract

In a wide area network (WAN) configured to act as a local area network (LAN) for enabling clients (e.g. PCs) to access the Internet, a dynamic host configuration protocol (DHCP) server makes address resolution protocol (ARP) table or cache entries in response to DHCP messages received from respective clients. The ARP entries include a client's logical interface, IP address, hardware address, and network connection identifier (e.g. virtual circuit (VC) identifier). Accordingly, the DHCP server need not broadcast ARP requests to obtain client addresses and/or may ignore incoming alleged or actual ARP replies, thereby reducing WAN traffic and rendering the network more secure.

Description

WO 00/44132 PCTtSEOO/00145

SECURE AND EFFICIENT ADDRESS RESOLUTION

FOR CLIENT STATIONS

CONNECTED OVER WIDE AREA NETWORK LINKS

TO IP NETWORKS SUCH AS THE INTERNET

This Application claims priority on U.S. Provisional Patent Application Number 60/116,977, filed January 25, 1999, the disclosure of which is hereby incorporated herein by reference.

Field of Invention

The present invention relates to the field of internet access, and in particular, to the provision of access to internet(s) over a network such as a wide area network (WAN) configured to act as a local area network (LAN).

Background and Summary of the Invention

The LAN was developed in response to the needs of computer users to communicate among themselves and to share computing resources such as printers, file servers, and electronic mail systems. A LAN may be defined as a network system that allows a number of independent stations (e.g. personal computers (PCs), servers, routers, other computers, etc.) to communicate with each other wil-hin a moderately sized geographic area over one or more communication channels.

Concurrent with the development of the LAN was the WAN. A primary distinguishing characteristic of a WAN over a LAN is its scope of geographic coverage. WANs may be used to interconnect LANs that are sufficiently distant from one another to be beyond the physical transmission limitations of a LAN. This is analogous to a telephone network where local telephone systems are interconnected by long distance carriers. An application of LAN/WAN technology is internet access, where WANs and/or LANs are used to access the internet from home, work, or the like. Such an application may be implemented over the public switched telephone network (PSTN) using di.al-up or Integrated Services Digital Network (ISDN) modems to access a Network Service Provider (NSP) who then provides access to the internet. Internet access, also known as Internet Protocol (IP) service, has traditionally been implemented using MOdulator/DEModulators (MODEMs) and serial ports of client computers. IP is part of the Transmission Control Protocol/Internet Protocol (TCP/IP) suite, and is used for data packet routing.

Within IP computer networks, stations are typically identified by network layer (see "network" layer in Fig. 2 OSI model) addresses such as IP addresses. These addresses provide a simple mechanism for identifying the source and destination of messages within the network. For example, an IP address may be a 32-bit (or more) binary number with a format of four or more bytes, divided into four or more 8-bit parts. Typically, each byte of an IP address (e.g. 140.179.220.200) is a number from 0 to 255, with one part of the address identifying the network and another part the station.

In addition, stations are identified at a lower level by hardware addresses such as Media Access Control (MAC) addresses; an example of such hardware addresses are Ethernet addresses. An exemplary MAC address may be 48 bits in length. One set of digits may identify the manufacturer or vendor of the station, and another set of digits may include an interface serial number or some other value administered by a vendor.

Given these different types of addresses for each station on a network, there exists a need to associate or map station network layer addresses (e.g. IP addresses) to hardware addresses (e.g. MAC addresses). Consider the example context of a bridged connection between router 3 and several Network Teπnination (NT) points 11 as shown in Figure 1. The known Address Resolution Protocol (ARP) may be used by router 3 for this mapping. To determine a hardware address for a particular network layer address on a single logical L.AN, an ARP request message is broadcast by a requester station (e.g. PC, file server, set-top box, or router) to all stations on the LAN in an attempt to learn the hardware address of the station with which the requester wants to communicate. The ARP request is received and processed by all stations on the LAN, although only the station that owns the requested address responds by sending an ARP reply message to the requester containing both the responder's network layer address and hardware address. The router 3 may associate in an ARP table the ARP reply including the network layer and hardware address with the WAN 5 connection over which the ARP response was received.

For purposes of example only as to conventional ARP procedure, with reference to Fig. 3, assume that IP-based station A with an IP address 192.0.2.1 wants to send data over an Ethernet channel to another IP-based station B on the same network having IP address 192.0.2.2. Station A does not have station B's MAC address, and thus sends an ARP request essentially saying "I need the MAC address for 192.0.2.2." The ARP request is sent in a broadcast frame. Every Ethernet station on the network reads the ARP request and looks to see whether the request is for its own address. If so, they respond. If not, they ignore it. Thus, while other stations with different IP addresses ignore the request, only station B with IP address 192.0.2.2 responds by sending a reply packet containing station B's MAC address back to the requesting station A (e.g. a reply saying in effect that 192.0.2.2 has a MAC address of, e.g., 8:0:20:1:56:34 (Ethernet addresses may be 48 bits)). It is noted that after a predetermined period of time (e.g. 15 minutes), dynamically entered ARP table entries .are typically timed out and removed by a router, while static ARP entries need not be timed out.

Turning back to IP addresses, these have historically been assigned statically during network configuration. In such cases, stations are pre- configured to use a statically assigned IP address. However, in large or rapidly changing networks, static assignment of IP addresses is often inadequate due to the potential for misconfiguration. As a result, IP addresses within networks are increasingly assigned automatically using the Dynamic Host Configuration Protocol (DHCP) per Internet RFC 1541. hereby incorporated herein by reference. DHCP is an extension of the Bootstrap Protocol (BOOTP), allowing hosts on a TCP/IP network to dynamically obtain basic configuration information (e.g. IP address(es)). DHCP provides for dynamic automatic set-up of IP addresses for stations in a network. For example, after a client (a "client" herein may be a PC, set-top box, or the like at a subscriber location) station is turned on, it and a DHCP server may exchange DHCPDISCOVERY (client asking server for an IP address), DHCP OFFER (server offering client an address), DHCPREQUEST (client attempting to accept the offer), and DHCPACK (server leases IP address to client ) messages during the IP address allocation process. The DHCP server leases dynamic IP addresses to respective clients for finite periods of time which expire, after which such leases must be renewed.

In the context of the above-described addressing schemes, there is a need for efficient and fast internet access. In this regard, a relatively new data transmission technology known as Digital Subscriber Line (DSL) is capable of providing high speed data transmission rates over twisted pair copper lines of the PSTN. DSL is thus particularly attractive with regard to IP services such as WO 00/44132 PCTtSEOO/00145

internet access, as it instantly increases transmission rates by orders of magnitude over available conventional transmission rates, thereby allowing users faster and more efficient internet access. Furthermore, since twisted pair copper lines of the PSTN have long been used to provide telephone services, they are already in place. Examples of DSL include Asynchronous DSL (ASDL), high bit rate DSL, and rate adaptive DSL.

Unfortunately, with the substantial improvement in transmission rates provided by DSL technologies, serial ports of most PCs in use are not able to process the amount of data transmitted between DSL modems without causing a data overflow problem. Consequently, network technologies which can handle such high speeds, such as Ethernet and Asynchronous Transfer Mode (ATM), have been proposed for use at both central offices and client sites in order to connect clients and other computers to access nodes (e.g. at central offices). These transport protocols may reduce the number of interrupts generated thereby reducing the processing time taken to process received data. The development of such technologies has led to network configurations including many small "LAN segments" (one LAN segment per client site) connected over DSL WAN links to a central service provision node via NTs 11 acting as remote LAN bridges as shown in Figure 1. A "LAN segment" may be, for example, a portion of a LAN cable or link, disposed between the client and a corresponding NT.

In particular, the assignee of this invention offers DSL links using an ATM virtual circuit (VC) interface. The term VC is typically used to describe a logical connection between two stations in a network (e.g. packet switching, cell switching, or frame switching network). A VC is a connection between two stations in a network that acts as though it is a direct connection even though it may share a physical interface or link with other connections/links for some part of its path. Frame Relay VCs, ATM VCs, and X.25 VC connections are examples of VCs.

Referring to Figure 1, various allocations of client VCs to IP subnetworks may be made. Possibilities include a single LAN, separate LANs, and multiple LANs. In a single LAN scenario as shown in Figure 4, all VCs from client LANs are connected in a single IP subnetwork. Router 3 includes DHCP server 15 for dynamic assignment of IP addresses to client stations attached to the subnet. Router 3 also includes an IP address pool or table 17, for enabling IP addresses to be stored. All client LAN segments are considered by router 3 to be within the same LAN so that the WAN is effectively configured to act as a local area network (LAN).

One advantage of the Figure 4 single LAN approach is that only a single IP subnetwork and DHCP address pool 17 need be configured on router 3. This configuration reflects efficient IP address utilization because only one address pool is needed. Moreover, all client stations may use the same IP address for the services of router 3. Unfortunately, there are also disadvantages of the single LAN approach. For example, the above-described conventional ARP protocol requires broadcasting a message to all clients within a LAN. Thus, for the Figure 4 network, broadcast ARP traffic must be copied by router 3 and sent as a separate message on each VC within the IP subnetwork. Such broadcasting of largely redundant information may lead to a surge of traffic on the WAN, resulting in lost data due to traffic rate "policing" put into effect during such surges. Also, some DHCP messages, such as DHCP OFFER, may need to be broadcast by the server to all VCs which leads to increased traffic volumes on the WAN. Moreover, the router may have to spend CPU cycles doing message copying, which is also undesirable. WO 00/44132 PCTtSEOO/00145

Another disadvantage is that conventional ARP does not validate ARP reply messages received from different client VCs. A client VC is a VC over which the server may communicate with a client. As a result, it is easy for an attacking or faulty client to mount a "denial-of-service" attack/mistake on a network by sending out a stream of ARP messages containing bogus (or incorrect) information. Bogus information may be used to direct all traffic for a range of IP addresses to go down the attacker's (or faulty client's) VC instead of the valid client's VC. Vulnerability to such attacks/mistakes renders the network less secure than would otherwise be desirable.

The following message sequences are used to help illustrate how a system in accordance with Figure 4 operates, with the DHCP server allocating the client (e.g. PC or set-top box) an IP address and thereafter the server and client communicating with one another.

WO 00/44132 PCTtSEOO/00145

Client Server

DHCPDISCOVER (MAC broadcast, user's NC) - looking for server

Lookup IP

address lease and make

DHCPOFFER (possible MAC broadcast, all VCs) provisional lease allocation in

DHCP table.

DHCPREQUEST

Lookup

provisionally

DHCPACK (possible MAC broadcast, all VCs) allocated IP address lease and check if still available. IP address allocated to client.

At this point, it is up to the client what it does: e.g. client may validate the allocated address using an ARP to SELF.

ARP for CLIENT address (MAC broadcast, user's VC)

So client is now OK with the address. Suppose it wants to talk to the server now.

ARP for SERVER address (MAC broadcast, user's VC)

Server can fill in ARP table

ARP response from SERVER (MAC unicast, user's VC) entry using received info.

Client can now speak to server and vice versa.

Some time later the server may time out the ARP table entry.

If the server subsequently needs to contact the client . . .:

ARP request broadcast for CLIENT address (MAC broadcast, all VCs)

Server has to copy request to all VCs.

Server can fill

in ARP table entry using WO 00/44132 PCTtSEOO/00145

received info.

As can be seen in the aforesaid messaging sequences, server 15 broadcasts its DHCPOFFER and DHCPACK messages to all VCs (not just the one for the intended client station). Moreover, server 15 must copy and broadcast its ARP requests to all VCs to determine the desired client's hardware address. This is undesirable for the reasons discussed above.

Another approach is separate LANs, as shown in Fig. 5. Each VC from a client LAN is connected to a separate IP subnetwork 23-25. In this case, each of the client LAN segments is considered to be a separate LAN by router 3. This approach removes the broadcast problems of the Figure 4 system. Since there is only one VC in each IP subnetwork, only one copy of ARP request messages and DHCP messages need be sent by each server 27-29. On the other hand, multiple IP subnetworks 23-25 and DHCP address pools 31-33 need to be configured on the router. This results in poor IP address utilization and may lead to configuration problems and/or the need for additional hardware/software. Additionally, the servers must keep track of which IP addresses have been leased from each of the pools. Moreover, each client must use a different IP address for server services, depending on which IP subnetwork they are connected to.

The third approach is a hybrid of the single LAN (Fig. 4) and separate LANs (Fig. 5) approaches described above. Small clusters of LANs may be considered by a router as, and supported by, a single LAN. Accordingly, this scenario has a hybrid of the advantages and drawbacks of the other two approaches.

In view of the above, it will be apparent to the skilled artisan that there exist needs in the art for: (i) a method and/or system for reducing network traffic, (ii) a method and/or system for eliminating the need for a server to broadcast messages over multiple WAN or other network connections, (iii) a method and/or system for mapping (or associating) client addresses (e.g. IP addresses) to corresponding client connections (VCs) in response to network layer address request (e.g. DHCP) messages in order to reduce the need for broadcasting server messages; and/or (iv) a method and/or system for increasing security of any such network.

An object of this invention is to eliminate the need for the server to broadcast address request messages on an IP network.

In the provision of access to the internet (e.g. the term "internet" herein includes not only the global interconnected network but also more localized networks running the IP) over a network, it is an object of this invention for a server to map in memory a network address of a client to the network connection (e.g. VC) for that client (i.e. client addressxlient network connection) in response to a network layer address request message received by the server, so as to achieve the aforesaid object of reducing the need for the server to broadcast messages on the network.

Another object of this invention is to reduce the chance of a server sending messages to incorrect client(s).

Yet another object of this invention is for a server to temporarily lock in a mapping of a client address to a corresponding client connection when or after the mapping is stored. This reduces the likelihood of address: connection mappings being incorrectly modified, thereby achieving the object of reducing the chance of messages being sent to incorrect client(s) so as to achieve a more secure system. Another object of this invention is to satisfy or fulfill any or all of the above listed objects or needs.

In a server provided in a network for enabling internet access, this invention may include a method of mapping a client address to a client network connection. The server receives from the client a network layer address request message over a network connection. A channel identifier indicating the network connection over which the request was received may be at least partially included in the message or alternatively inferred by the server depending upon the channel or network connection that the message is received on. In response to the address request message, the server allocates a network layer address to the client and maps the network layer address to the network connection in a memory. The server thus need not subsequently broadcast address request messages over the network when it desires to communicate with that client.

In certain preferred embodiments of this invention, ARP entry timing is modified in a manner such that a DHCP server maps at least one client station address (e.g. IP address) to that client's network connection (e.g. VC) via an ARP table entry (e.g. including IP address, MAC address and VC ID) for the client when, or as a function of when, the server dynamically allocates a network layer address (e.g. IP address) to that client. This mapping is temporarily locked in for a period of time, and the server need not subsequently broadcast address request messages (e.g. ARP requests) across the network to obtain client addresses and/or connections. Due to the locking, messages received from attacking or faulty clients seeking to incorrectly change the address: connection mapping are ignored and/or not acted upon by the server.

Thus, certain embodiments of this invention satisfy one or more of the above-listed objects or needs by: reducing or even eliminating the need for the server to broadcast ARP requests thereby reducing WAN traffic; reducing the potential for an attacking or faulty client to falsify entries in the server's ARP table(s); reducing or eliminating the need for the server to broadcast certain DHCP messages; and/or rendering the network more secure.

BRIEF DESCRIPTION OF THE DRAWINGS

Figure 1 is a schematic diagram of a network configuration including a plurality of client LAN segments connected over DSL VC links to a router.

Figure 2 is a schematic diagram of the OSI layer model.

Figure 3 is a diagram illustrating a TCP packet on Ethernet including the use of ARP to obtain a station's hardware address.

Figure 4 is a schematic diagram of a first implementation of the Figure 1 network configuration where client internet access is provided over a WAN configured to act as a LAN.

Figure 5 is a schematic diagram of a second implementation of the Fig. 1 network configuration where multiple LANs are provided, as well as multiple servers and address pools in the router.

Figure 6(a) is a schematic diagram of a network configuration including a plurality of supported client LAN segments as well as a plurality of unsupported client LAN segments connected over DSL links to a router in accordance with an embodiment of this invention.

Figure 6(b) schematic diagram of a first implementation of the router of Fig. 6(a) according to an embodiment of this invention. Figure 7 is a flow chart illustrating steps taken by a server in mapping a {client address : network connection} in response to receiving a network layer address message from the client in accordance with an embodiment of this invention.

Figure 8 is a flow chart illustrating steps taken by the DHCP server/processor of Fig. 6 in allocating a network address (e.g. IP address) to a client and making an ARP table entry (including a mapping of a client network layer address to a network connection for that client) in accordance with an embodiment of this invention.

Figure 9 is a flow chart illustrating how the DHCP server/processor of

Fig. 6 ignores ARP response message it receives identifying supported clients, yet responds to ARP requests, in accordance with an embodiment of this invention.

DETAILED DESCRIPTION OF THE DRAWINGS

In the following description, for purposes of explanation and not limitation, specific details are set forth in order to provide an understanding of certain embodiments of the present invention. However, it will be apparent to those skilled in the art that the present invention may be practiced in other embodiments that depart from these specific details. In other instances, detailed descriptions of well-known devices, circuits, OSI models (see Fig. 2), protocols, and methods are omitted so as not to obscure the description of the present invention with unnecessary detail.

Figure 6(a) illustrates a network according to an embodiment of this invention for enabling client (e.g. PC 9) access to an internet over a WAN 40 configured to act as a LAN. Router 39 communicates with client LANs including respective client PCs (or set-top boxes) 9 over WAN or other network connections 42 (e.g. VCs), thereby enabling PCs 9 to access the internet. As shown in Figure 6(b) , router 39 includes at least one DHCP server including processor 41, at least one IP subnetwork 45 for enabling the router to communicate over a plurality of WAN connections (e.g. permanent or temporary VCs), and a memory 47 including at least one IP address pool 43 and ARP table 49 (described below). Input devices 51 and output devices 53 are in communication with the server system of the router, and represent a range of varying I/O devices such as disk drives, keyboards, modems, network adapters, printers, displays, and the like.

In an exemplary embodiment of this invention, router 39 may be an Ericsson AXI 510 Edge Router including DHCP server/processor 41 and memory 47. The AXI 510 may include an ATM OC-3c/STM-l interface for connection to the ADSL access network and/or WAN(s), and up to 18 built-in serial ports for Frame Relay WAN connectivity. Frame Relay involves a frame switched network based on point-to-point circuits from router 39 to a frame relay switch with packets being identified by router 39 as to their network connection with a virtual circuit ID. While the AXI-510 is utilized in a preferred exemplary embodiment, it will be recognized by those of skill in the art that other suitable routers may instead be used in other embodiments of this invention.

For a client 9 to communicate with other stations on a TCP/IP network, it needs certain information, including where it is itself (its own network or IP address) and where certain essential network resources are located. In this regard, DHCP server 41 may provide networked clients 9 with the required TCP/IP configuration information from a central location, thereby reducing the need for the clients to be set up individually. When a DHCP client (e.g. a PC or set-top box) 9 starts up, it broadcasts a DHCPDISCOVERY packet looking for DHCP server(s) 41. The source IP address for this may be 0.0.0.0, as the client has no IP address at this time. DHCP server 41 responds to this packet with a DHCPOFFER packet sent to the client, offering to configure the client. If the client accepts the offered configuration information (e.g. IP address) from server 41, the client sends a DHCPREQUEST packet to that server. DHCP server 41, in response to the request packet, then sends a DHCPACK packet to the client containing the final parameters (e.g. IP address) for the client to use, and the configuration information is allocated (leased) to the client for a period of time (e.g. seconds or minutes). Server 41 notes the IP address internally as in use via a table or cache entry and does not offer it to any other client(s) during the in-use period. Upon receiving the DHCPACK packet, the client TCP stack finishes configuring itself. For example, it is known that a client may validate its allocated IP address by sending out an ARP request identifying the IP address just allocated to it (i.e. ARP to SELF). If another station responds, then the client assumes that the allocated address is not valid since it is already in use on the network. Finally, the client may have to periodically renew its lease via the server in order to continue to use the configuration.

Referring to Figures 6-8, certain embodiments of this invention take advantage of the fact that, when a client 9 is turned on or started up, the first valid communication(s) from the client to DHCP server 41 is a DHCPDISCO VER or DHCPREQUEST for an IP address. Conventionally, this process is handled independently from the ARP protocol, thereby requiring the server to broadcast ARP requests after the DHCP messages have been exchanged when the server subsequently wishes to communicate with a particular client, resulting in much WAN traffic. However, in the case of certain embodiments of the present invention, the normal operation and/or timing of ARP protocol entries is modified. ARP table entries are stored by DHCP server 41 in ARP table 49 when the server allocates an IP address from pool 43 to a DHCP requesting client 9. A channel identifier indicative of the VC (or other network connection) that the DHCP message comes in on is determined by the receiving server (i.e. the server associates the VC with the message when it receives it). The DHCP message may be, for example, one of a DHCPDISCOVER or DHCPREQUEST. The DHCP message is passed up the protocol stack to DHCP server 41. When the DHCP server is ready to allocate an IP address to the client, it also has all of the information required to set up an ARP entry (i.e.. IP address, MAC address, and VC ID) in table 49 for the client. The IP address, VC ID and MAC address are thus stored simultaneously or in close time proximation with DHCP lease information in table 49, or at a time which is a function of when the table entry of DHCP lease information is made. The server thus maps the allocated IP address to the network connection (e.g. VC) in such a manner. The DHCP and modified ARP allocations may be made together as one entry in table 49, or as separate entries in separate tables in different embodiments of this invention.

There are a number of different ways in which the server may determine the network connection (e.g. VC) which an incoming DHCP message comes in or is received on. In certain embodiments, a channel identifier may be attached to the message indicative of the network connection. The server may use this channel identifier (either alone or in combination with additional physical information such as which port/board the message was received on) to identify the relevant network connection (e.g. VC), and store the same as the client's IP address is to be mapped thereto. In other embodiments of this invention, the server may use physical receiving port ID information as a channel identifier in WO 00/44132 PCTtSEOO/00145

17

order to identify the network connection on which a message is received. In any case, the server stores a channel identifier that is indicative of the network connection on which the DHCP message was received, and the same is mapped to the allocated network layer address for the client at issue.

IP address leases are held by the server for finite periods of time. When the DHCP server releases its hold on an IP address lease, it also removes the corresponding ARP table 49 entry for the client. Thus, ARP entries in table 49 are not subject to the conventional ARP timeout mechanism (they need not be deleted if not used for a given period of time). In accordance with certain embodiments of this invention, server entered ARP information for a client in table 49 is stored and/or deleted along with the client's allocated IP address. Thus, when a client turns off for the night, for example, the IP address lease may timeout and be revoked, and the ARP entry removed from table 49.

A conventional ARP entry is compared below to an ARP entry (table 49 entry) according to an embodiment of this invention:

Conventional ARP Entry:

{Logical Interface, Protocol (IP) Address, Hardware (MAC) Address}

ARP Entry according to an embodiment of this invention fTable 491:

{Logical Interface, Protocol (IP) Address, Hardware (MAC) Address, Network Connection ID (e.g. VC ID)}

As can be seen above, ARP table 49 of router 39 is extended according to certain embodiments of this invention so as to include the client' s network connection ID information (e.g. a WAN connection ID such as VC ID) therein. This is because the Logical Interface may not always be specific enough to correctly identify the VC or other WAN connection that a remote client is located on.

As shown in Figure 6(a), certain WAN connections (e.g. VCs_x-_z) support the modified ARP system described above wherein network layer addresses (e.g. IP addresses) may be mapped to WAN connection IDs in table 49 when the network layer addresses are allocated. However, other WAN connections of the network (e.g. VCsι-₂) may not support the modified ARP system. Thus, server 41 may also communicate with unsupported network connections and or clients 9b using standard ARP procedures and broadcasts. In other words, the inventive mapping described above need not apply to all WAN connections in the network. Thus, as shown in Figure 6(b), router 39 may include ARP table 49 that includes ARP entries for both supported clients 9a and unsupported clients 9b. For supported clients 9a, extended ARP entries are made in table 49 in response to received DHCP messages as discussed above thereby mapping client addresses (e.g. IP addresses) to respective client network connections (e.g. VCs), so that the server does not have to broadcast ARP requests if it subsequently wishes to communicate to a client. For unsupported clients 9b, ARP entries are also made in table 49; however for such unsupported clients these entries are made only after the server has broadcast an ARP request and received an ARP response from a client as to its address. For unsupported clients 9b, the entries in table 49 may have zeros input in the VC ID area according to certain embodiments of this invention. Thus, there need not be a change to the ARP table format in certain embodiments, but only a change in the πranner in which ARP entries are created in the router's table. In certain alternative embodiments of this invention, separate ARP tables may be provided in the router for supported versus unsupported client ARP entries, or alternatively all ARP entries WO 00/44132 PCTtSEOO/00145

19

(for supported and unsupported clients) may be made in the same table as shown in Fig. 6(b).

Thus, router 39 does not create and delete entries in ARP table 49 using the ARP procedures of RFC 826; instead, router 39 creates and deletes the modified ARP entries when DHCP server 41 assigns or removes a network address lease (e.g. lease of an IP address). This reduces WAN traffic, and additionally renders the network more secure (the likelihood is reduced of communications being intercepted by unintended PCs that have sent out stream(s) of ARP messages containing bogus information). As can be seen above, the term ARP herein is not limited to its conventional meaning, but instead means an address entry for a client which may or may not include a network connection identifier (e.g. VC ID) mapped to a network address such as an IP address.

Accordingly, server 41 need not (and preferably does not) broadcast ARP requests to resolve addresses for supported clients 9a, since all such clients with either dynamic DHCP leases and/or static DHCP addresses are known to the server. Traffic for unresolved addresses may be dropped. Moreover, unlike conventional ARP of RFC 826, if the address resolution module of server 41 does not find an associated pair of IP and MAC addresses in its ARP table 49 for a supported client, the server does not generate an ARP request in an attempt to resolve the same. Additionally, server 41 does not update its ARP table 49 entries when it receives alleged ARP replies from clients said to be supported (e.g. VCs_x._z), thereby reducing the likelihood that a client can falsify entries in the server's modified ARP table 49 in order to obtain information intended for others. However, the server's ARP mechanism may still be used to respond to ARP requests originating from clients that are sent to, and received by, server 41. Therefore, in the context of the single LAN scenario of Figure 4, the drawback of the ARP broadcasts is removed with regard to supported clients 9a, since the router no longer has to broadcast ARP requests to locate supported clients (e.g. VCs_x-_z). In addition, the drawback of the ARP information validation is removed for such clients 9a, since incoming ARP response information is ignored by the router.

In accordance with another aspect of this invention, incoming DHCP messages pertaining to current leases (e.g. DHCP IP address leases) received by server 41 may be validated by the server to ensure that the VC (or other network connection) they come in on is the same as for the originally mapped VC ID corresponding to the address at issue. Invalid requests (e.g., a lease release message from a different VC to the original lease) may be logged to the system administrator and not affect the valid lease.

IP addresses present in the server's ARP table 49 that are associated with static entries are not leased to clients of the DHCP server. This ensures that statically addressed nodes do not affect DHCP addressed nodes and vice versa.

Outgoing messages from server 41 to broadcast or multicast addresses are checked during output processing. Messages from the DHCP server are further interrogated to determine the target IP address. This IP address of a supporting client is used to perform a lookup in ARP table 49 to determine the network connection (e.g. VC) over which to send the message. This enables the server to send outgoing messages over proper connections. Messages from the DHCP server which do not contain a target IP address, (e.g., DHCP NACK messages), have the target WAN connection embedded in a formerly unused portion of the message which is extracted by the output processor when determining the target WAN connection. Other messages to broadcast or multicast addresses may be dropped by the output processor.

In Figures 6(a) and 6(b), VCs are shown as preferred network connections. Exemplary types of VCs, either permanent or temporary, which may be utilized in networks according to different embodiments of this invention include ATM VCs, Frame Relay VCs, and X.25 VCs. However, other types of WAN connections (and respective channel identifiers for identifying them) may instead be used in certain embodiments of this invention, including but not limited to dedicated HDLC links and media supporting the point-to-point protocol (PPP).

An exemplary and non-liirύting message sequence in accordance with an embodiment of this invention is set forth below (reference should also be made to the flow chart of Fig. 8 which tracks certain aspects of the below listed sequence):

Client Server

DHCPDISCOVER (MAC broadcast, user's VC) - looking for server

Lookup IP lease and

DHCPOFFER (possible MAC broadcast, user's VC) make provisional

allocation in DHCP table and ARP table.

DHCPREQUEST

Lookup

^ leases and

DHCPACK (possible MAC broadcast, user's VC) check if still available.

At this point, it is up to the client what it does, e.g. client may validate the allocated IP address using an ARP to SELF.

ARP for CLIENT address (MAC broadcast, user's VC)

ARP for SERVER address (MAC broadcast, user's VC)

^"> Send back

ARP response from SERVER (MAC unicast, user's VC) server MAC address

Client can now speak to server and vice versa. Now client will run out of DHCP lease at some time

DHCPREQUEST for current IP address

Lookup leases and check if still

DHCPACK (MAC broadcast, user's VC) available.

Suppose the client is turned off for the night Server times out lease and removes DHCP and ARP entries. Figure 7 is a flow chart illustrating steps taken in mapping a client network layer address to a network connection in accordance with an embodiment of this invention. In step 91, DHCP server 41 receives a network layer address message from a supported client 9a over a network connection, with at least a portion of a connection identifier attached thereto and/or implicit in the transport inferred by the server. In step 92, server 41 maps the network layer address (e.g. IP address) allocated to the client to the network connection (e.g. via the connection identifier) in ARP table 49. The server and client may then communicate with one another at 93, without the server having to broadcast ARP requests across the network. As shown in step 94, server 41 ignores messages that it receives seeking to modify entries in table 49 for supported clients, thereby rendering the system more secure. Following a predetermined period of time, the client's network layer address and network connection identifier are removed at 95. The client must ask for renewal to continue using the same.

Figure 8 is a flow chart illustrating a more detailed embodiment of this invention, including how server 41 receives a DHCP message from a supported client (e.g. PC 9a), and in response thereto allocates an IP address to the client and makes an ARP table 49 entry for that client mapping the two to one another. In step 61 , DHCP server 41 receives the DHCPDISCOVERY broadcast on a VC from a supported client 9. The logical channel number or identifier for identifying the VC is noted and stored by the server. In step 62, server 41 looks up an IP address lease and allocates an IP address for the client and makes an ARP entry for the client which includes the client's logical interface, IP address, hardware (e.g. MAC) address, and logical channel identifier (e.g. VC ID), thereby mapping the IP address to the VC ID. Thereafter, in step 63 the server sends a DHCPOFFER message to the client offering it the allocated IP address. In step 64, if the client decides to accept the IP address, it sends a DHCPREQUEST message to the server. In step 65, if the IP address lease is still available, server 41 sends a DHCPACK to the client leasing the client the address for a period of time. In step 66, the client may optionally validate the IP address received from the server (e.g. ARP to SELF as described above). In step 67, when the server times out the IP address, it removes both the DHCP and ARP entries for the supported client.

Figure 8 shows server 41 making its modified ARP entry at step 62 in response to a DHCPDISCOVERY message received from a supported client. However, it should be recognized that in other embodiments of this invention, the server may instead make its ARP table 49 entry with channel identifier in response to a DHCPREQUEST message received from the client; because the first message from a client to a server regarding DHCP may be a DHCPREQUEST, and a DHCPDISCOVER message may never be received from a supported client.

Figure 9 is a flow chart illustrating how server 41 ignores alleged ARP responses which it receives, yet still responds to ARP requests. In step 71, server 41 maps a network and or hardware address(es) to a network connection which an address request message was received on, for supported client #1. Server 41 may thereafter communicate with client #1 without having to broadcast an ARP request for that client because the ARP table 49 entry resolves .any potential address issues regarding that client. In step 73, server 41 receives an ARP reply message from attacking client #2 requesting that the server modify the table 49 entry for client #1 by replacing the stored WAN connection ID with client #2's WAN connection ID (client #2 is attempting to trick the server into sending it client #1 's messages). In step 75, server 41 ignores and/or does not respond to the message from client #2, as the table 49 entry is essentially "locked" and cannot be modified until a new network layer address is allocated to client #1. In certain embodiments, client #2 cannot modify entries in the ARP table of a "secure" IP subnet except via the DHCP server, regardless of whether a lease is allocated to client #1. Server 41 may ignore ARP replies allegedly from supported clients because the server need not broadcast any ARP requests to these clients — so ARP replies from them are unimportant). This renders the system more secure. Thus, as shown in step 77, server 41 may still communicate with client #1 despite client #2's attempt to modify the table 49 ARP entry. In the event that client #3 (supported or unsupported) wishes to send a message to server 41, then client #3 broadcasts an ARP request for the server across its LAN and WAN connections (e.g. VC) in step 79. In step 81, server 41 responds to ARP requests which it receives, using the single relevant VC of the client. After client #3 receives the ARP response from the server, it is able to communicate directly with the server.

It should be understood that the foregoing embodiments are merely exemplary and do not confine application of the present invention to any particular structure. For example, the invention may be relevant to any IP services provided to a client LAN over WAN links, where a client LAN may be differentiated from another by some form of connection ID (in this case a VC). It is also not limited to ATM over ADSL. While the invention has been described in connection with what is presently considered to be the most practical and preferred embodiment, it is to be understood that the invention is not to be limited to the disclosed embodiments, but to the contrary, is intended to cover various modifications and equivalent arrangements.

Claims

WE CLAIM:

1. In a server provided in a network for enabling internet access, a method of mapping a client address to a client network connection comprising the steps of:

receiving from a client a network layer address request message over a network connection; and

in response to the address request message, allocating a network layer address to the client and mapping the network layer address to the network connection in a memory.

2. The method of claim 1 , wherein said mapping step includes making an address resolution table entry for the client including a network layer address, a hardware address, and a channel identifier indicative of the network connection; and the method further comprising the step of routing a message over the network connection to the client using the address resolution table entry in a manner such that the server does not have to broadcast an address request message over the network.

3. The method of claim 2, wherein said step of receiving an address request message includes receiving a Dynamic Host Configuration Protocol (DHCP) message from the client over a virtual circuit (VC) wherein the channel identifier identifies the VC; and the DHCP message includes one of a DHCPDISCOVER and a DHCPREQUEST message.

4. The method of claim 3, further comprising the step of not modifying a client mapping entry in memory in response to receiving an address resolution protocol (ARP) reply message seeking to modify the client mapping entry.

5. The method of claim 4, further comprising the step of performing said mapping step without the server broadcasting an ARP request.

6. The method of claim 1, further comprising the step of removing the mapping at a point in time based upon when a lease of the network layer address is removed.

7. The method of claim 1, wherein said mapping step includes making an address resolution table entry including a logical interface, an IP address of the client, a media access control (MAC) address of the client, and a channel identifier identifying a virtual circuit (VC).

8. The method of claim 7, wherein the VC includes one of an ATM VC, a Frame Relay VC, and an X.25 VC.

9. The method of claim 1, further comprising the steps of:

a) the server receiving a request from the client for an internet protocol (IP) address;

b) in response to the message received in step a), the server offering the client an IP address;

c) the offer of step b) being accepted by the client; and d) the server dynamically allocating the IP address to the client.

10. The method of claim 9, wherein the server receives at least a portion of a channel identifier indicative of the network connection in the context of at least one of said steps a) and c).

11. In a server provided in a wide area network (WAN) configured to act as a local area network (LAN), a method of making an address resolution protocol (ARP) entry comprising the steps of:

receiving a Dynamic Host Configuration Protocol (DHCP) message over a WAN connection; and

making the ARP entry including a client's network layer address, hardware address, and a channel identifier indicative of the WAN connection in response to the DHCP message.

12. The method of claim 11, further comprising the steps of:

providing an edge router including the server and at least one address pool; and

wherein the DHCP message includes one of a DHCPDISCOVER and a DHCPREQUEST, and the WAN connection includes one of an ATM VC, a Frame Relay VC, an X.25 VC, a dedicated HDLC connection, and a media supporting point-to-point protocol (PPP).

13. In a network for enabling client internet access, a server comprising: a processor and a memory, said processor in communication with a plurality of clients via corresponding local area networks (LANs);

wherein said processor receives a network address request message requesting a network layer address from a first one of said clients over a network connection, said message including at least a hardware address of the first client; and

said server in response to said message making an address resolution table entry inclusive of said network address of the first client, said hardware address of the first client, and a network connection identifier indicative of the network connection over which the network address request message was received.

14. The network of claim 13, wherein said message includes one of a DHCPDISCOVERY and a DHCPREQUEST, said network connection is a virtual circuit (VC), and said network connection identifier includes a VC identifier.

15. The network of claim 14, wherein said table entry includes an internet protocol (IP) address, a media access control (MAC) address, and the VC identifier.

16. A router for use in a network, said router comprising:

a dynamic host configuration protocol (DHCP) server for dynamically allocating internet protocol (IP) addresses to clients; and wherein said DHCP server makes address resolution protocol (ARP) entries in response to receiving respective DHCP messages from clients including a client IP address, a client hardware address, and a channel identifier indicative of a network connection.

17. The router of claim 16, wherein said hardware address includes a MAC address, and said channel identifier includes a virtual circuit (VC) identifier.

18. A network configuration including a wide area network (WAN) configured to act as a local area network (LAN) for enabling clients to access a digital data network, the network configuration comprising:

a plurality of virtual circuits (VCs) in communication over digital subscriber line (DSL) links with a router, said router including a dynamic host configuration protocol (DHCP) server for communicating with a plurality of clients over respective ones of said VCs; and

wherein said DHCP server makes address resolution protocol (ARP) entries in response to DHCP messages received from clients, said ARP entries including a respective client's hardware address and VC identifier.