(51) Int Cl.: H04L 29/12 ( )

Transcription

1 (19) TEPZZ 99 86B_T (11) EP B1 (12) EUROPEAN PATENT SPECIFICATION (4) Date of publication and mention of the grant of the patent: Bulletin /17 (21) Application number: (22) Date of filing: (1) Int Cl.: H04L 29/12 (06.01) (86) International application number: PCT/IB11/ (87) International publication number: WO 12/0167 ( Gazette 12/0) (4) IPv6 address generation to trigger a virtual leased line service IPv6-Adressenerzeugung zur Auslösung eines virtuellen Mietleitungsdienstes Génération d adresse IPv6 pour déclencher un service de ligne louée virtuelle EP B1 (84) Designated Contracting States: AL AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC MK MT NL NO PL PT RO RS SE SI SK SM TR () Priority: US (43) Date of publication of application: Bulletin 13/23 (73) Proprietor: ALCATEL LUCENT 9 Boulogne-Billancourt (FR) (72) Inventors: PIRBHAI, Shafiq Ottawa, Ontario K2T 0E3 (CA) HART, Neil Chelsea, Quebec J9B 2N7 (CA) (74) Representative: Wetzel, Emmanuelle et al Alcatel Lucent Intellectual Property & Corporate Standards Lorenzstrasse 7043 Stuttgart (DE) (6) References cited: WO-A1-/ US-A HIMANSHU SHAH(FORCE) ERIC ROSEN (CISCO) GILES HERON(BT) VACH KOMPELLA (ALCATEL-LUCENT): "ARP Mediation for IP Interworking of Layer 2 VPN; draft-ietf-l2vpn-arpmediation-14.txt", ARP MEDIATION FOR IP INTERWORKING OF LAYER 2 VPN; DRAFT-IETF- L2VPN-ARP-MEDIATION-14.TXT, INTERNET ENGINEERING TASK FORCE, IETF; STANDARDWORKINGDRAFT, INTERNET SOCIETY (ISOC) 4, RUE DES FALAISES CH- 1 GENEVA, SWITZERLAND, no. 14, 7 July (-07-07), pages 1-31, XP , [retrieved on ] HUANG AT&T LABS J: "IPv6CP Options for PPP Host Configuration; draft-huang-ipv6cp-options 00.txt", IPV6CP OPTIONS FOR PPP HOST CONFIGURATION; DRAFT-HUANG-IPV6CP- OPTIONS 03 INTERNET ENGINEERING TASK FORCE, IETF; STANDARDWORKINGDRAFT, INTERNET SOCIETY (ISOC) 4, RUE DES FALAISES CH- 1 GENEVA, SWITZERLAND, 3 February (-02-03), pages 1-, XP00663, [retrieved on ] VARADA S ET AL: "IP Version 6 over PPP; rfc072.txt", , 1 September 07 ( ), XP00144, ISSN: THOMSON BELLCORE T NARTEN IBM S: "IPv6 Stateless Address Autoconfiguration; rfc2462.txt", , 1 December 1998 ( ), XP , ISSN: Note: Within nine months of the publication of the mention of the grant of the European patent in the European Patent Bulletin, any person may give notice to the European Patent Office of opposition to that patent, in accordance with the Implementing Regulations. Notice of opposition shall not be deemed to have been filed until the opposition fee has been paid. (Art. 99(1) European Patent Convention). Printed by Jouve, 7001 PARIS (FR) (Cont. next page)

2 EP B1 CARPENTER UNIV OF AUCKLAND R ATKINSON EXTREME NETWORKS H FLINCK NOKIA SIEMENS NETWORKS B: Renumbering Still Needs Work; rfc887.txt RENUMBERING STILL NEEDS WORK; RFC887.TXT, INTERNET ENGINEERING TASK FORCE, IETF; STANDARD, INTERNET SOCIETY (ISOC) 4, RUE DES FALAISES CH- 1 GENEVA, SWITZERLAND 27 May, pages 1-3, XP HANGZHOU H3C TECHNOLOGIES CO. ET AL: H3C S900E Series Routing Switches Layer 2- WAN Configuration Guide, [Online] 21 October 13, pages 1-43, XP09242 Retrieved from the Internet: <URL: download.do? id=169690> [retrieved on ] JIE HU YUNQING CHEN HUILING ZHAO DONGFENG MAO CHINA TELECOM: PPPv6 Problem statement and requirements; draft-hupppext-ipv6cp-requirements-00.txt PPPV6 PROBLEM STATEMENT AND REQUIREMENTS; DRAFT-HU-PPPEXT-IPV6CP-REQUIREMENTS- 00.TXT, INTERNET ENGINEERING TASK FORCE, IETF; STANDARDWORKINGDRAFT, INTERNET SOCIETY (ISOC) 4, RUE DES FALAISES CH- 1 GENEVA, SWITZERLAND 18 October, pages 1-6, XP Remarks: The file contains technical information submitted after the application was filed and not included in this specification 2

3 1 EP B1 2 Description TECHNICAL FIELD [0001] Various exemplary embodiments disclosed herein relate generally to communications devices, specifically connectivity in a packet data network. BACKGROUND [0002] In modern communications systems, various local devices and local networks may be attached to each other through a packet data network, such as an Internet Protocol (IP) or Multiprotocol Label Switching (MPLS) network. In some instances, a pseudo-local area network (pseudo-lan) may be established between one or more devices through the packet data network with the use of various devices and techniques. One of the methods for creating such a pseudo-lan may be the use of one or more pseudowires within the packet data network to connect devices on the edge of the network. Through such emulation of a Layer 2 point-to-point (P2P) connectionoriented service, two devices connected through a packet-switching network may operate in a similar manner to, for example, devices sharing a common provider edge (PE) device. [0003] Configuration of a pseudo-lan regularly involves the management of devices connected within the pseudo-lan, including, for example, the resolution of addresses for the devices once the service is established. While the pseudo-lan may be able to support a variety of services, such as Asynchronous Transfer Mode (ATM), Frame Relay (FR), Ethernet, High-Level Data Link Control (HLDC), MPLS, IPv4 and IPv6 Internet Protocol, some form of address resolution between services of the same layer may be necessary. However, address resolution between devices using different services may not be possible in certain instances, such as during the initial setup through the pseudo-lan or when an intermediate service is not active. [0004] HIMANSHU SHAH (FORCE) ERIC ROSEN (CISCO) GILES HERON (BT) VACH KOMPELLA (AL- CATEL-LUCENT) : "ARP Mediation for IP Interworking of Layer 2 VPN; draft-ietf-i2vpn-arp-mediation-14.txt", ARP MEDIATION FOR IP INTERWORKING OF LAYER 2 VPN; DRAFT-IETF-L2VPN-ARP-MEDIATION- 14.TXT, INTERNET ENGINEERING TASK FORCE, IETF; STANDARDWORKINGDRAFT, INTERNET SO- CIETY (ISOC) 4, RUE DES FALAISES CH- 1 GE- NEVA, SWITZERLAND, no. 14, 7 July (-07-07), pages 1-31, XP , [retrieved on ] describes Address Resolution Procedure (ARP) mediation for IP Interworking of Layer 2 VPN. A Virtual Private Wire Service (VPWS) provides point-topoint connections between pairs of Customer Edge (CE) devices. Two Attachment Circuits each connecting a CE device with a Provider Edge, PE, device are bound to a pseudowire connecting the two PEs. In case of CE address discovery for CEs attached using PPP in connectin with IPv6CP, PPP negotiation takes place between the CE and its local PE. The PE performs proxy PPP negotiation and informs the attached CE of the link-local identifier of its local interface using the Interface-Identifier option (0x01). This local interface identifier is used by stateless address autoconfiguration [RFC 2462]. When a PE with a local AC of the type point-to-point link receives a Neighbor Solicitation from a far end PE over the pseudowire, after learning the IP address of the far-end CE, the PE may forward the Neigbor Solicitation to the local CE after replacing the source link-layer address with the link-layer address of the local AC or send an Inverse Neighbor Solicitation to the local CE specifying the farend CE s IP address and the link-layer address of the local AC. When a PE with a local AC of the type pointto-point link receives a Neighbor Advertisement over the pseudowire, it should learn the IPv6 addresses of the farend CE. If the AC supports Inverse Neighbor Discovery and the PE had already processed an Inverse Neighbor Solicitation from local CE, it should send an Inverse Neighbor Advertisement on the local AC using source IP address information received in Neighbor Discovery ADV and its own local AC link layer information. [000] HUANG AT&T LABS J: "IPv6CP Options for PPP Host Configuration; draft-huang-ipv6cp-options 00.txt", IPV6CP OPTIONS FOR PPP HOST CONFIU- RATION; DRAFT-HUANG-IPV6CP-OPTIONS 03 INTERNET ENGINEERING TASK FORCE, IETF; STANDARDWORKINGDRAFT, INTERNET SO- CIETY (ISOC) 4, RUE DES FALAISES CH- 1 GE- NEVA, SWITZERLAND, 3 February (-02-03), pages 1 -, XP00663, [retrieved on ] describes, that IPv6CP [RFC072] only defines the Interface-Identifier option, and therefore defines additional host IPv6CP Options for PPP Host Configuration. [0006] VARADA S ET AL: "IP Version 6 over PPP; rfc072.txt", , 1 September 07 ( ), XP00144, ISSN: describes that the Network Control Protocol, NCP, for establishing and configuring the IPv6 over PPP is referred to as the IPv6 Control Protocol, IPv6 CP, and that the Interface Identifier option is to be used for the address autoconfiguration at the local end of the link. THOMSON BELLCORE T NARTEN IBM S: "IPv6 Stateless Address Autoconfiguration; rfc2462.txt", , 1 December 1998 ( ), XP , ISSN: describes the creation of link-local addresses. A link-local address is formed by prepending the well-known linklocal prefix FE80 :: 0 of appropriate length to the interface identifier. [0007] CARPENTER UNIV OF AUCKLAND R ATKIN- SON EXTREME NETWORKS H FLINCK NOKIA SIE- MENS NETWORKS B: "Renumbering Still Needs Work; rfc887.txt", RENUMBERING STILL NEEDS WORK; RFC887.TXT, INTERNET ENGINEERING TASK FORCE, IETF; STANDARD, INTERNET SOCIETY (ISOC) 4, RUE DES FALAISES CH- 1 GENEVA, 3

4 3 EP B1 4 SWITERLAND, 27 May (-0-27), pages 1-3, XP , [retrieved on -0-27] describes renumbering for IPv4 and IPv6. For IPv6, the NCP is IP6CP [RFC072] and is used to configure an interface identifier for each end, after which link-local addresses may be created in the normal way. In practice, each side can propose its own identifier and renegotiation is only necessary when there is a collision, or when a provider wishes to force a subscriber to use a specific interface identifier. Once link-local addresses are assigned and IP6CP is complete, automatic assignment of global scope addresses is performed by the same methods as with multipoint links, i.e., either SLAAC or DHCPv6. Again, in a subscriber/provider environment, this allows renumbering per PPP session. [0008] In view of the foregoing, it would be desirable to have a communications system that enables address resolution between devices. In particular, it would be desirable to have a system capable of resolving addresses of applicable devices during initiation of a service through at least one pseudowire. SUMMARY [0009] In light of the present need for address resolution in a pseudo-local area network, a brief summary of various exemplary embodiments is presented. Some simplifications and omissions may be made in the following summary, which is intended to highlight and introduce some aspects of the various exemplary embodiments, but not to limit the scope of the invention. Detailed descriptions of a preferred exemplary embodiment adequate to allow those of ordinary skill in the art to make and use the inventive concepts will follow in the later sections. [00] The present invention provides a method according to claim 1 and a system according to claim 7. [0011] It should be apparent that, in this manner, various exemplary embodiments enable the management of addresses when establishing a service. Particularly, by generating and subsequently modifying an address for a far-end device, the system may enable consistent, reliable service that may react properly when a provider SAP does not have the far-end customer address stored. BRIEF DESCRIPTION OF THE DRAWINGS [0012] In order to better understand various exemplary embodiments, reference is made to the accompanying drawings wherein: FIG. 1 illustrates an exemplary embodiment of the pseudo-local area network (LAN) through a packet data network; FIG. 2 illustrates an exemplary datapath for a Pointto-Point Protocol (PPP) customer edge service access point (SAP); FIG. 3 illustrates an exemplary datapath for a Frame Relay (FR) customer edge SAP; and FIG. 4 illustrates an exemplary flowchart for determining an address for a far-end customer edge SAP through the packet data network. DETAILED DESCRIPTION [0013] Referring now to the drawings, in which like numerals refer to like components or steps, there are disclosed broad aspects of various exemplary embodiments. [0014] FIG. 1 illustrates an exemplary embodiment of the pseudo-local area network (LAN) through a packet data network. In various exemplary embodiments, communications system 0 includes a packet data network 1, customer edge (CE) service access providers (SAPs) , provider edge (PE) SAPs , pseudowire 1, and local connections Pseudowire 1 may be established through packet data network 1 to connect PE SAPs 121, 122, which may, in turn, establish a pseudo-local area network (pseudo- LAN), Internet Protocol LAN service (IPLS), virtual private wire service (VPWS), or virtual private network (VPN) that includes CE SAPs and PE SAPs 121, 122. In the illustrative embodiment, for example, communications system 0 may include a VPWS that includes the SAPs [00] In some embodiments, the communications network 0 may be a network incorporating hardware dedicated to a customer entity. In such embodiments, the devices in the communications network 0 may be configured such that the devices , in the communications network 0 occupy the same address space. This may include devices that connect directly to each other at the same site and may also include devices located at two different sites that communicate with each other through the packet data network 1. In some embodiments, the devices may be located behind the same security boundary, which may isolate devices within the boundary from outside devices, with some control of communications at the border between such devices. [0016] Packet data network 1 may be a packetswitched network operating in accordance with a packetbased protocol, such as Transmission Control Protocol/Internet Protocol (TCP/IP), Multiprotocol Label Switching (MPLS), Asynchronous Transfer Mode (ATM), Frame Relay (FR), Ethernet, Provider Backbone Transport (PBT), High-Level Data Link Control (HDLC), or any other suitable packet-based protocol that will be apparent to one of skill in the art. More specifically, data packet network 1 may communicate using Layer 2 or Layer 3 protocols, such as MPLS or IPv4 and IPv6 Internet protocol. [0017] Customer edge (CE) service access points (SAPs) may be devices or nodes in the communications network 0. CE SAPs may be network nodes or devices, such as routers or switches, that may be configured to transmit packets to other devices, 4

5 EP B1 6 such as other CE SAPs in the pseudo-lan or provider edge SAPs. CE SAPs may be capable of communications with other devices within and outside of the pseudo-lan, using multiple layers of the OSI reference model, such as, for example, Layer 3 communications using MPLS (L3 MPLS) or Layer 2 communications using Ethernet and Virtual Private LAN Service (VPLS). Each of the CE SAPs may include a similar address space. For example, CE SAPs may share common portion of an IPv6 prefix, such as "01:fc3:8a7::812e:e70:," with specific addresses within the address space. CE SAP 111 may have, for example,"7334/128" as the remaining portion of the IPv6 address, while CE SAP 112 may have "733/128" as its remaining portion. [0018] Provider edge (PE) SAP may be a node or device in the communications network 0, such as a router, switch, or similar hardware device located on the edge of the packet data network 1. PE SAPs may be configured to receive packets from the CE SAPs and transmit these packets to other devices through direct connections, such as , or through the packet data network 1 to other devices through intermediaries, such as other PE SAPs [0019] Pseudowire 1 may be an embodiment of a service that transmits a packet over a packet-switching network. Pseudowire 1 may be, for example, a pseudowire end-to-end (PWE3) that transports customer data packets over an MPLS network. In some embodiments, the pseudowire 1 may only transport packets between devices of the same type or using the same service. In other embodiments, the pseudowire 1 may also transport packets between devices of a different type or using a different service. This may occur, for example, when the packets payload consists solely of IP datagrams. [00] Local connections may be wired or wireless connections or attachment circuits that enable the transfer of packets from the CE SAPs to the PE SAPs , respectively. Local connections may be configured to support one or more services that support the transfer of packets between devices, such as, for example, TCP/IP, MPLS, ATM, FR, Ethernet, PBT, and HDLC. In the illustrative embodiment, the PE SAP 121 may include one or more services to connect to the CE SAPs 111, 113, 114. For example, the local connection between the CE SAP 111 and the PE SAP 121 may be a Frame Relay (FR) link. [0021] Having described the components of the communications network 0, a brief summary of the operation of the communications network 0 will be provided. It should be apparent that the following description is intended to provide an overview of the operation of the communications network and is therefore a simplification in some respects. The detailed operation of the communications network 0 will be described in further detail below in relation to, for example FIGS [0022] According to various exemplary embodiments, the PE SAP 121 may connect with the CE SAPs 111, , and 114. When connected, the PE SAP 121 may obtain the addresses of each CE SAP 111, 113,114. PE SAP 121 may obtain at least one address associated with the CE SAP 111, for example, upon receipt of an Inverse Neighbor Solicitation message originating from the CE SAP 111. The Inverse Neighbor Solicitation message may be a request for another device from which the CE SAP 111 does not already have an address, such as, for example CE SAP 112. [0023] The addresses of the CE SAPs 111, 113, 114 may include, for example, the IPv6 address, the data link connection identifier (DLCI), and/or the MAC address. Once obtained, the PE SAP 121 may store each of the obtained addresses. PE SAP 121 may, for example, store an obtained IPv6 address for the CE SAP 111 in an Address Resolution Protocol (ARP) Cache that may be included with the PE SAP 121. When the PE SAP 121 already has the address for CE SAP 112 stored, the PE SAP 121 may then include at least one of the stored addresses associated with the CE SAP 112 in an Inverse Neighbor Advertisement sent back to the CE SAP 111. PE SAP 121 may have already stored at least one address associated with CE SAP 112 as a result of receiving a Neighbor Solicitation message from the CE SAP 112. PE SAP 121 may have received the Neighbor Solicitation originating from CE SAP 112 when the pseudowire between the PE SAP 121 and the PE SAP 122 has been established in response to the establishment of a service. Such service establishment may include, for example, establishing a Virtual Leased Line (VLL) for the CE SAPs within the communications network 0. [0024] In some instances, however, the pseudowire may not already be established for the PE SAP 121 to receive Neighbor Solicitation messages. This may occur, for example, during the initialization of a service, which may be in response or associated with an Inverse Neighbor Solicitation message originating from the CE SAP 111. In such instances, the PE SAP 121 has no address for the target device CE SAP 112 stored and will not reply to the Inverse Neighbor Solicitation. As will be discussed in further detail below, the PE SAP 121 may, in such instances, generate an address for the target device using known values, such as its own MAC address, and may thereafter modify the target address to the "true" address acquired once the service is properly established. In such embodiments, the generated rule may enable a service to become established and may therefore allow a PE SAP 121, 122 to receive Neighbor Solicitation messages from far-end devices and thus enables the PE SAPs 121, 122 to store these values and return valid addresses upon further queries. [002] FIG. 2 illustrates an exemplary datapath for a Point-to-Point Protocol (PPP) customer edge service access point (SAP). PE SAP 1 and PE SAP 2 may be similar to the PEs SAP of the communications system 0 in FIG. 1. PE SAPs 1,2 may receive and transmit messages to and from other devices (not shown), such as Neighbor Solicitation messages 211 and

6 7 EP B1 8 Neighbor Advertisement messages 212, 213. In order to transfer packets between attachment circuits of different types, such as the local connections \that may be using a different service, the PE SAPs 1, 2 may perform ARP mediation, which may resolve Layer 2 addresses when different resolution protocols are used in the attachment circuits. [0026] When a service is active, a CE, such as CE SAP 112 in the communications system 0 in FIG. 1, may send a Neighbor Solicitation message 211 to the PE SAP 2 in order to perform address discovery. In some embodiments, no addresses for the constituent devices in the communications system are preconfigured, so the devices may perform address discovery at various stages in order to acquire the addresses (including the IPv6 address, link local address, and/or MAC address) of other devices in the communications system 0. Upon receipt of the Neighbor Solicitation message 211, the PE SAP 2 may extract a MAC address and IP address (e.g., IPv6 address) of the source of the message, and may store the values of these addresses in memory, such as an Address Resolution Protocol (ARP) cache included with the PE SAP 2. [0027] PE SAP 2 may then send the Neighbor Solicitation message through the pseudowire 1 to the PE SAP 1, which may also extract and store the addresses of the source device in its memory. In some embodiments, the PE SAP 1 may use IPv6 Control Protocol (IPv6CP) negotiation 21 to bring up the PPP local connection 133 with the CE SAP 113. This may trigger the PE SAP 1 to generate a Neighbor Advertisement 212 message and forward the Neighbor Advertisement message 212 through the pseudowire to the PE SAP 2. [0028] When generating the Neighbor Advertisement message 212, the PE 1 may copy a number of values from the Neighbor Solicitation message 211. For example, the PE SAP 1 may copy the link local address of the CE SAP 113 that was learned through the IPv6CP negotiation to use as the source address in the Neighbor Advertisement message 212. PE SAP 1 may also add a Layer 2 address in the Neighbor Advertisement message (in the illustrative embodiment, a PPP Layer 2 address) and may copy the source IP address of the Neighbor Solicitation message as the destination IP address of the Neighbor Advertisement message. Once the Neighbor Advertisement message 212 is created, the PE SAP 1 may send the Neighbor Advertisement message 212 through the pseudowire to the PE SAP 2. In some embodiments, the PE SAP 1 may also bounce the IPv6CP SAP (in the illustrative example, CE SAP 113), using the IP address of the source CE SAP (e.g., CE SAP 112) to set a new link local address for the CE SAP 113. [0029] Upon receipt of the Neighbor Advertisement message 212, the PE SAP 2 may replace the Layer 2 address of the Neighbor Advertisement message 212 with its own MAC address. In some embodiments, the PE SAP 2 may also extract the addresses of the source CE SAP 213 that triggered the generation of the Neighbor Advertisement message 212 and store the address values in its memory. After replacing this value, the PE SAP 2 may then forward the modified Neighbor Advertisement message 213 to the CE SAP 112. [00] In some embodiments, the PE SAP 1 and/or the PE SAP 2 may not reply to the Neighbor Solicitation message 211. This may occur, for example, when the service is not active, as the PE SAPs 1, 2 would drop such messages. In such instances, the PE SAPs 1, 2 may not acquire and store the addresses of farend CE SAPs, as it would not receive either Neighbor Solicitation or Neighbor Advertisement messages due to the pseudowire not being established. This action may occur in some embodiments, as it is desirable to refrain from establishing the pseudowire before the IPv6CP negotiation has completed. Allowing Neighbor Solicitation and Neighbor Advertisement messages to pass through the service before the IPv6CP negotiation would also cause all user data to pass through the service, which may be avoided in preferred embodiments. Thus, in the preferred embodiment, during an IPv6CP negotiation with an attached CE SAP, such as the CE SAP 213, the needed far-end link local address for the proper negotiation is not known by the PE SAP 1. [0031] In some embodiments, the PE SAP 1 may therefore use its own MAC address to generate a temporary link local address in order to perform a proper IPv6CP negotiation 22 with the CE SAP 213. As the IPv6CP negotiation 22 may trigger the service to become active, the PE SAP 1 may subsequently receive Neighbor Solicitation and Advertisement messages over the now-established pseudowire. PE SAP may then extract the actual link local address of the farend CE SAP 112. Once the actual link local address of the far-end CE SAP 112 is known, the PE SAP 1 may then use the actual link local address in an IPv6CP renegotiation 21 with the CE SAP 113. [0032] When generating the temporary link local address from its MAC address, the PE SAP 1 may need to add values due to the differing lengths of the MAC address and the IPv6 address, for example. For example, the PE SAP 1 may insert two octets, such as 0xFF and 0xFE in the middle of the MAC address. This insertion may be between the company id and the vendor-supplied id of the MAC address, which should be known to a person of skill in the art. [0033] FIG. 3 illustrates an exemplary datapath for a Frame Relay (FR) customer edge SAP. The datapath for the communications system 0 is similar to the datapath for communications system 0 in FIG. 2, except that the PE SAP 1 responds to an Inverse Neighbor Solicitation message 3 instead of PE SAP 1 initiating the IPv6CP negotiation, as the PE SAP 1 in Frame Relay does not initiate the address discovery process. [0034] In the illustrative embodiment, the PE SAP 1 receives the Neighbor Solicitation message 311 over the 6

7 9 EP B1 pseudowire 1 originating from the CE SAP 112. Meanwhile, the CE SAP 111 independently sends an Inverse Neighbor Solicitation message 3 to the PE SAP 1. The Inverse Neighbor Solicitation message 3 may contain the address of the CE SAP 111, including, for example, its IPv6 address, and its data link connection identifier (DLCI). Upon receipt of the Inverse Neighbor Solicitation message 3, the PE SAP 1 may store the IPv6 address for the CE SAP 111. [003] When the PE SAP 1 has a previously stored address for the source of the Neighbor Solicitation message 311, the PE SAP 1 may reply to the Inverse Neighbor Solicitation message 3 with an Inverse Neighbor Advertisement message 316. The Inverse Neighbor Advertisement message 316 may contain the IP address of the source of the Neighbor Solicitation message 311 and the local DLCI of the CE SAP 111. [0036] In some embodiments, when the PE SAP 1 does not have the address of the source of the Neighbor Solicitation message 311 previously stored, it may not reply to the Inverse Neighbor Solicitation message 311. This may occur, for example, when the PE SAP 1 has not received a Neighbor Solicitation message 311 due to, for example, the service not yet being established or active. In some embodiments, the PE SAP 1 may generate an Inverse Neighbor Advertisement message 317 using a temporary IP address generated from its own MAC address in lieu of the IP address of the source of the Neighbor Solicitation message 311. In such instances, the PE SAP 1 may, upon receipt of the Neighbor Solicitation message 311, replace the temporary IP address in its storage and generate a subsequent Inverse Neighbor Advertisement message 316 with the actual IP source address. [0037] FIG. 4 illustrates an exemplary flowchart for determining an address for a far-end customer edge SAP through the packet data network. PE SAP 1 may perform method 0, for example, when initiating an IPv6CP negotiation 22 with a CE SAP 113 over a PPP attachment circuit 133 or generating an Inverse Neighbor Advertisement message 317 through an FR attachment circuit 131 with acesap111. [0038] Method 0 begins at step 1 and continues to step 3, where the PE SAP 1 determines whether the service is active. When the service is active, the PE SAP 1 may receive and process Neighbor Solicitation messages 211 and may therefore acquire and store the actual local link address of the far-end CE SAP 112 upon receipt of the Neighbor Solicitation message 211. In such instances, the PE SAP 1 may proceed to step 9; otherwise, the PE SAP 1 in step 3 determines that the service is not active and proceeds to step. [0039] In step, the PE SAP 1 may generate a substitute link local address for the far-end CE SAP 112. In some embodiments, the PE SAP 1 may generate the substitute link local address from its own MAC address, adding octets to the middle of the MAC address to convert the value from a MAC address value to an IPv6 address value. In other embodiments, not forming part of the present invention, the PE SAP 1 may generate the substitute link local address from other values, such as, for example, an unallocated IPv6 address in the address space of the pseudo-lan. In some embodiments, the PE SAP 1 may store the value of the substitute link local address in its memory, which may be, for example, and ARP cache. [00] PE SAP 1 may then proceed to step 7, where the PE SAP 1 initiates an IPv6CP negotiation with the local CE SAP 113 over an attachment circuit 113 using the generated substitute address. In other embodiments, not forming part of the present invention, the PE SAP 1 may conduct similar ARP mediation techniques using the generated temporary address. Other ARP mediation techniques may include, for example, as known from the prior art, generating an Inverse Neighbor Advertisement message 317 using the substitute address. [0041] After step 7, the IPv6CP negotiation may cause an IPv6CP session to be up, which may cause the service to become active. The service, once active, may also trigger the pseudowire to be established in some embodiments. In some embodiments, the active service allows the PE SAP 1 in step 9 to receive and process Neighbor Solicitation or Advertisement messages from the far-end CE SAP 112. [0042] Upon receipt of the Neighbor Solicitation message 211 or Neighbor Advertisement message 212 in step 9, the PE SAP 1 may in step 411 determine whether the PE SAP 1 stored a substitute link local address for the CE SAP 112 that initiated the Neighbor Solicitation message 211 or Neighbor Advertisement message 212. When the substitute link local address is stored in the PE SAP 1, the PE SAP 1 in step 413 may replace the substitute link local address with the actual link local address extracted from the Neighbor Solicitation message 211 or the Neighbor Advertisement message 212. [0043] In step 4, the PE SAP 1 may initiate an IPv6CP negotiation with the local CE SAP 113 over the local attachment circuit 113 using the actual link local address. The IPv6CP negotiation may be similar to that step 7. In other embodiments not forming part of the present invention, PE SAP 1 may perform other ARP mediations in a similar manner to the ARP mediations known from the prior art described in relation to step 7, with the PE SAP 1 using the actual link local address. After the IPv6CP negotiation or renegotiation, the PE SAP 1 may end the process 0 at step 417. [0044] The illustrative embodiments therefore disclose a system and related method of bringing up an IPv6CP session between a pseudowire SAP and a CE SAP when the service is not active. By generating a substitute link local address for IPv6CP negotiation, the service enables proper ARP mediation even before the receipt of Neighbor Solicitation or Neighbor Advertisement messages, which may require a service to be active before a pseudowire SAP receives and/or extracts relevant information 7

8 11 EP B1 12 from them. [004] It should be apparent from the foregoing description that various exemplary embodiments of the invention may be implemented in hardware and/or firmware. Furthermore, various exemplary embodiments may be implemented as instructions stored on a machine-readable storage medium, which may be read and executed by at least one processor to perform the operations described in detail herein. A machine-readable storage medium may include any mechanism for storing information in a form readable by a machine, such as a personal or laptop computer, a server, or other computing device. Thus, a machine-readable storage medium may include read-only memory (ROM), random-access memory (RAM), magnetic disk storage media, optical storage media, flash-memory devices, and similar storage media. [0046] It should be appreciated by those skilled in the art that any block diagrams herein represent conceptual views of illustrative circuitry embodying the principals of the invention. Similarly, it will be appreciated that any flow charts, flow diagrams, state transition diagrams, pseudo code, and the like represent various processes which may be substantially represented in machine readable media and so executed by a computer or processor, whether or not such computer or processor is explicitly shown. [0047] Although the various exemplary embodiments have been described in detail with particular reference to certain exemplary aspects thereof, it should be understood that the invention is capable of other embodiments and its details are capable of modifications in various obvious respects. As is readily apparent to those skilled in the art, variations and modifications can be affected while remaining within the scope of the invention. Accordingly, the foregoing disclosure, description, and figures are for illustrative purposes only and do not in any way limit the invention, which is defined only by the claims. Claims 1. A method of a provider service access point, SAP, (121, 1, 1) determining an address of a customer SAP, the method comprising: determining that a virtual leased line, VLL, service (1) connecting a second customer SAP (112) and the first customer SAP (111, 113, 114) is not active; using its media access control, MAC, address to create a substitute IPv6 link local address, wherein the substitute IPv6 link local address acts as the IPv6 link local address for the second customer SAP (112); establishing an IPv6CP session (22) with the first customer SAP (111, 113, 114) using the substitute IPv6 link local address; receiving a Neighbor Solicitation packet (211, 311) or Neighbor Advertisement packet (212, 312) over the VLL service (1), wherein the established IPv6CP session (22) triggered the VLL service (1) to become active; extracting, from the Neighbor Solicitation packet (211, 311) or Neighbor Advertisement packet, a true IPv6 link local address for the second customer SAP (112); characterized in that the method further comprising: renegotiating the IPv6CP session (21), wherein the true IPv6 link local address replaces the substitute IPv6 link local address. 2. The method of claim 1, wherein the Neighbor Advertisement (213, 313) or Neighbor Solicitation (211, 311) packet traverses from the first (111, 113, 114) or second (112) customer SAPs through an attachment circuit (131, 133, 134, 132) before said receiving. 3. The method of claim 2, wherein the VLL service (1) uses the attachment circuit (131, 133, 134, 132) to connect to the first (111, 113, 114) or second (112) customer SAP. 4. The method of claim 2, wherein the attachment circuit (131, 133, 134, 132) is a link using a protocol selected from the group consisting of Frame Relay, FR, Point-to-Point Protocol, PPP, Ethernet, and High-Level Data Link Control, HLDC, and the packet data network (1) is an MPLS network.. The method of claim 1, further comprising: reestablishing the VLL service (1), wherein the VLL service uses the renegotiated IPv6CP session (21, 22) to connect the provider (121, 1, 1) and first customer SAPs (111, 113, 114). 6. The method of claim 1, further comprising: storing the substitute IPv6 link local address after the using step; and replacing the substitute IPv6 link local address with the true IPv6 link local address after the extracting step. 7. A system of determining an address of a customer service access point, SAP, the system comprising: a first customer SAP (112) connected to a packet data network (1) that includes a true IPv6 link local address; 8

9 13 EP B1 14 a second customer SAP (111, 113, 114) that is adapted to solicit the true IPv6 link local address when a virtual leased line, VLL, service (1) between the first (112) and second (111, 113, 114) customer SAPs is not active; and a provider SAP (121, 1, 1) connected to the second customer SAP (111, 113, 114) and the packet data network (1) that is adapted to: determine when the VLL service (1) connecting a first (112) and second (111, 113, 114) customer SAP is not active; use its media access control, MAC, address to create a substitute IPv6 link local address, wherein the substitute IPv6 link local address acts as the IPv6 link local address for the first customer SAP (112); establish an IPv6CP session (22) with the second customer SAP (111, 113, 114) using the substitute IPv6 link local address; receive a Neighbor Solicitation packet (211, 311) or Neighbor Advertisement (212, 312) packet over the VLL service (1), wherein the established IPv6CP session (22) triggered the VLL service (1) to become active; extract, from the Neighbor Solicitation packet (211, 311) or Neighbor Advertisement packet (212, 312), a true IPv6 address for the first customer SAP (112); characterized in that the provider SAP (121, 1, 1) is further adapted to: reestablish the IPv6CP session (21), wherein the true IPv6 link local address replaces the substitute IPv6 link local address. 8. The system of claim 7, wherein the second customer SAP (111, 113, 114) and the provider SAP (121, 1, 1) are connected through an attachment circuit (131, 132, 133, 134), and further wherein the Neighbor Advertisement (213, 313) or Neighbor Solicitation (211, 311) packet traverses from the first customer SAP (112) through the attachment circuit (131, 132, 133, 134) before being received by the provider SAP (121, 1, 1). 9. The system of claim 8, wherein the VLL service (1) uses the attachment circuit (131, 132, 133, 134) to connect to the first customer SAP (112).. The system of claim 8, wherein the attachment circuit (131, 132, 133, 134) is a link using a protocol selected from the group consisting of Frame Relay, FR, Point-to-Point Protocol, PPP, Ethernet, and High- Level Data Link Control, HLDC, and the packet data network (1) is an MPLS network Patentansprüche 1. Verfahren eines Dienstanbieter-Dienstzugangspunktes, SAP, (121, 1, 1) zur Ermittlung einer Adresse eines Kunden-SAP, wobei das Verfahren umfasst: Ermitteln, dass ein virtueller Mietleitungs- bzw. VLL-Dienst (1), der einen zweiten Kunden- SAP (112) mit dem ersten Kunden-SAP (111, 113, 114) verbindet, nicht aktiv ist, Verwenden seiner Medienzugriffssteuerungsbzw. MAC-Adresse, um eine verbindungslokale IPv6-Ersatzadresse zu erzeugen, wobei die verbindungslokale IPv6-Ersatzadresse als die verbindungslokale IPv6-Adresse für den zweiten Kunden-SAP (112) agiert; Aufbauen einer IPv6CP-Sitzung (22) mit dem ersten Kunden-SAP (111, 113, 114) unter Verwendung der verbindungslokalen IPv6-Ersatzadresse; Empfangen eines Neighbor-Solicitation-Pakets (211, 311) oder eines Neighbor-Advertisement- Pakets (212, 312) über den VLL-Dienst (1), wobei die aufgebaute IPv6CP-Sitzung (22) die Aktivierung des VLL-Dienstes (1) auslöst; Extrahieren, aus dem Neighbor-Solicitation-Paket (211, 311) oder dem Neighbor-Advertisement-Paket (212, 312), einer wahren verbindungslokalen IPv6-Adresse für den zweiten Kunden-SAP (112); dadurch gekennzeichnet, dass das Verfahren weiterhin umfasst: Neuaushandeln der IPv6CP-Sitzung (21) wobei die wahre verbindungslokale IPv6- Adresse die verbindungslokale IPv6-Ersatzadresse ersetzt. 2. Verfahren nach Anspruch 1, wobei das Neighbor- Advertisement-Paket (213, 313) oder das Neighbor- Solicitation-Paket (211, 311) von dem ersten (111, 113, 114) oder dem zweiten (112) Kunden-SAP vor dem besagten Empfang eine Anbindungsschaltung (131, 133, 134, 132) durchquert. 3. Verfahren nach Anspruch 2, wobei der VLL-Dienst (1) die Anbindungsschaltung (131, 133, 134, 132) für die Verbindung mit dem ersten (111, 113, 114) oder dem zweiten (112) Kunden-SAP verwendet. 4. Verfahren nach Anspruch 2, wobei die Anbindungsschaltung (131, 133, 134, 132) ein Link ist, welcher ein aus der Gruppe bestehend aus Frame Relay, FR, Punkt-zu-Punkt-Protokoll, PPP, Ethernet und High-Level Data Link Control, HLDC, gewähltes Protokoll verwendet, und das Paketdatennetzwerk (1) ein MPLS-Netzwerk ist. 9

10 EP B1 16. Verfahren nach Anspruch 1, weiterhin umfassend: Wiederherstellen des VLL-Dienstes (1), wobei der VLL-Dienst die neu ausgehandelte IPv6CP Sitzung (21, 22) für die Verbindung des Dienstanbieters (121, 1, 1) mit ersten Kunden-SAPs (111, 113, 114) verwendet. Ermitteln, wenn der VLL-Dienst (1), welcher einen ersten (112) und einen zweiten (111, 113, 114) Kunden-SAP verbindet, nicht aktiv ist; Verwenden seiner Medienzugriffssteuerungs- bzw. MAC-Adresse, um eine verbindungslokale IPv6-Ersatzadresse zu erzeugen, wobei die verbindungslokale IPv6-Ersatzadresse als die verbindungslokale IPv6-Adresse für den ersten Kunden-SAP (112) agiert; Aufbauen einer IPv6CP-Sitzung (22) mit dem zweiten Kunden-SAP (111, 113, 114) unter Verwendung der verbindungslokalen IPv6-Ersatzadresse; Empfangen eines Neighbor-Solicitation- Pakets (211, 311) oder eines Neighbor-Advertisement-Pakets (212, 312) über den VLL-Dienst (1), wobei die aufgebaute IPv6CP-Sitzung (22) die Aktivierung des VLL-Dienstes (1) auslöst; Extrahieren, aus dem Neighbor-Solicitation-Paket (211, 311) oder dem Neighbor- Advertisement-Paket (212, 312), einer wahren verbindungslokalen IPv6-Adresse für den ersten Kunden-SAP (112); dadurch gekennzeichnet, dass der Dienstanbieter- SAP (121, 1, 1) weiterhin für Folgendes ausgelegt ist: 6. Verfahren nach Anspruch 1, weiterhin umfassend: Speichern der verbindungslokalen IPv6-Ersatzadresse nach dem Schritt des Verwendens; und Ersetzen der verbindungslokalen IPv6-Ersatzadresse durch die wahre verbindungslokale IPv6- Adresse nach dem Schritt des Extrahierens. 7. System zur Ermittlung einer Adresse eines Kunden- Dienstzugangspunktes, SAP, wobei das System umfasst: Einen ersten Kunden-SAP (112), der an ein Paketdatennetzwerk (1), welches eine wahre verbindungslokale IPv6-Adresse umfasst, angeschlossen ist; einen zweiten Kunden-SAP (111, 113, 114), welcher dazu ausgelegt ist, die wahre verbindungslokale IPv6-Adresse anzufordern, wenn ein virtueller Mietleitungs- bzw. VLL-Dienst (1) zwischen dem ersten (112) und dem zweiten (111, 113, 114) Kunden-SAP nicht aktiv ist; und einen Dienstanbieter-SAP (121, 1, 1), welcher an den zweiten Kunden-SAP (111, 113, 114) und an das Paketdatennetzwerk (1) angeschlossen und für Folgendes ausgelegt ist: Wiederherstellen der IPv6CP-Sitzung (21) wobei die wahre verbindungslokale IPv6-Adresse die verbindungslokale IPv6-Ersatzadresse ersetzt. 8. System nach Anspruch 7, wobei der zweite Kunden- SAP (111, 113, 114) und der Dienstanbieter-SAP (121, 1, 1) über eine Anbindungsschaltung (131, 132, 133, 134) verbunden sind, und wobei weiterhin das Neighbor-Advertisement-Paket (213, 313) oder das Neighbor-Solicitation-Paket (211, 311) von dem ersten Kunden-SAP (112) vor dem Empfang an dem Dienstanbieter-SAP (121, 1, 1) eine Anbindungsschaltung (131, 133, 134, 132) durchquert. 9. System nach Anspruch 8, wobei der VLL-Dienst (1) die Anbindungsschaltung (131, 133, 134, 132) für die Verbindung mit dem ersten Kunden-SAP (112) Kunden-SAP verwendet.. System nach Anspruch 8, wobei die Anbindungsschaltung (131, 132, 133, 134) ein Link ist, welcher ein aus der Gruppe bestehend aus Frame Relay, FR, Punkt-zu-Punkt-Protokoll, PPP, Ethernet und High-Level Data Link Control, HLDC, gewähltes Protokoll verwendet, und das Paketdatennetzwerk (1) ein MPLS-Netzwerk ist. Revendications 1. Procédé d un point d accès au service, SAP, d un fournisseur (121, 1, 1) déterminant une adresse d un SAP d un client, le procédé comprenant les étapes suivantes : déterminer qu un service de ligne louée virtuelle, VLL, (1) reliant un deuxième SAP d un client (112) et le premier SAP d un client (111, 113, 114) n est pas actif ; utiliser son adresse de contrôle d accès au support, MAC, pour créer une adresse locale de liaison IPv6 de remplacement, dans lequel l adresse locale de liaison IPv6 de remplacement agit comme adresse locale de liaison IPv6 pour le deuxième SAP d un client (112) ; établir une session IPv6CP (22) avec le premier SAP d un client (111, 113, 114) en utilisant l adresse locale de liaison IPv6 de

11 17 EP B1 18 remplacement ; recevoir un paquet de sollicitation de voisinage (211, 311) ou un paquet d annonce de voisinage (212, 312) sur le service VLL (1), dans lequel la session IPv6CP établie (22) a déclenché le service VLL (1) pour qu il devienne actif ; extraire, à partir du paquet de sollicitation de voisinage (211, 311) ou du paquet d annonce de voisinage (212, 312), une adresse locale de liaison IPv6 réelle pour le deuxième SAP d un client (112) ; caractérisé en ce que le procédé comprend en outre l étape suivante : renégocier la session IPv6CP (21), dans lequel l adresse locale de liaison IPv6 réelle remplace l adresse locale de liaison IPv6 de remplacement. 2. Procédé selon la revendication 1, dans lequel le paquet d annonce de voisinage (213, 313) ou de sollicitation de voisinage (211, 311) traverse, à partir des premiers (111, 113, 114) ou du deuxième (112) SAP d un client, un circuit annexe (131, 133, 134, 132) avant ladite réception. 3. Procédé selon la revendication 2, dans lequel le service VLL (1) utilise le circuit annexe (131, 133, 134, 132) pour se connecter au premier (111, 113, 114) ou au deuxième (112) SAP d un client. 4. Procédé selon la revendication 2, dans lequel le circuit annexe (131, 133, 134, 132) est une liaison utilisant un protocole sélectionné dans le groupe constitué du relais de trames, FR, du protocole point à point, PPP, d Ethernet et de la commande de liaison de données de haut niveau, HLDC, le réseau de données en paquets (1) étant un réseau MPLS.. Procédé selon la revendication 1, comprenant en outre l étape suivante : rétablir le service VLL (1), dans lequel le service VLL utilise la session IPv6CP renégociée (21, 22) pour connecter le fournisseur (121, 1, 1) et les premiers SAP d un client (111, 113, 114). 6. Procédé selon la revendication 1, comprenant en outre les étapes suivantes : stocker l adresse locale de liaison IPv6 de remplacement après l étape d utilisation ; et remplacer l adresse locale de liaison IPv6 de remplacement par l adresse locale de liaison IPv6 réelle après l étape d extraction. 7. Système de détermination d une adresse d un point d accès au service, SAP, d un client le système comprenant : un premier SAP d un client (112) connecté à un réseau de données en paquets (1) qui comprend une adresse locale de liaison IPv6 réelle ; un deuxième SAP d un client (111, 113, 114) qui est adapté pour solliciter l adresse locale de liaison IPv6 réelle lorsqu un service de ligne louée virtuelle, VLL, (1) entre le premier (112) et les deuxièmes (111, 113, 114) SAP d un client n est pas actif ; et un SAP d un fournisseur (121, 1, 1) connecté au deuxième SAP d un client (111, 113, 114) et le réseau de données en paquets (1) qui est adapté pour : déterminer le moment où le service VLL (1) connectant un premier (112) et un deuxième (111, 113, 114) SAP d un client n est pas actif ; utiliser son adresse de contrôle d accès au support, MAC, pour créer une adresse locale de liaison IPv6 de remplacement, dans lequel l adresse locale de liaison IPv6 de remplacement agit comme adresse locale de liaison IPv6 pour le premier SAP d un client (112) ; établir une session IPv6CP (22) avec le deuxième SAP d un client (111, 113, 114) en utilisant l adresse locale de liaison IPv6 de remplacement ; recevoir un paquet de sollicitation de voisinage (211, 311) ou un paquet d annonce de voisinage (212, 312) sur le service VLL (1), dans lequel la session IPv6CP établie (22) a déclenché le service VLL (1) pour qu il devienne actif ; extraire, à partir du paquet de sollicitation de voisinage (211, 311) ou du paquet d annonce de voisinage (212, 312), une adresse IPv6 réelle pour le premier SAP d un client (112) ; caractérisé en ce que le SAP d un fournisseur (121, 1, 1) est en outre adapté pour : rétablir la session IPv6CP (21), dans lequel l adresse locale de liaison IPv6 réelle remplace l adresse locale de liaison IPv6 de remplacement. 8. Système selon la revendication 7, dans lequel le deuxième SAP d un client (111, 113, 114) et le SAP d un fournisseur (121, 1, 1) sont connectés par l intermédiaire d un circuit annexe (131, 132, 133, 134), et en outre dans lequel le paquet d annonce de voisinage (213, 313) ou de sollicitation de voisinage (211, 311) traverse, à partir du premier SAP d un client (112), le circuit annexe (131, 132, 133, 11

12 19 EP B1 134) avant d être reçu par le SAP d un fournisseur (121, 1, 1). 9. Système selon la revendication 8, dans lequel le service VLL (1) utilise le circuit annexe (131, 132, 133, 134) pour se connecter au premier SAP d un client (112).. Système selon la revendication 8, dans lequel le circuit annexe (131, 132, 133, 134) est une liaison utilisant un protocole sélectionné dans le groupe constitué du relais de trames, FR, du protocole point à point, PPP, d Ethernet et de la commande de liaison de données de haut niveau, HLDC, le réseau de données en paquets (1) étant un réseau MPLS

13 EP B1 13

14 EP B1 14

15 EP B1

16 EP B1 16

17 EP B1 REFERENCES CITED IN THE DESCRIPTION This list of references cited by the applicant is for the reader s convenience only. It does not form part of the European patent document. Even though great care has been taken in compiling the references, errors or omissions cannot be excluded and the EPO disclaims all liability in this regard. Non-patent literature cited in the description ARP Mediation for IP Interworking of Layer 2 VPN; draft-ietf-i2vpn-arp-mediation-14.txt. HIMANSHU SHAH ; ERIC ROSEN ; GILES HERON ; VACH KOMPELLA. ARP MEDIATION FOR IP INTER- WORKING OF LAYER 2 VPN; DRAFT-IETF-L2VPN-ARP-MEDIATION-14.TXT, INTERNET ENGINEERING TASK FORCE, IETF; STANDARDWORKINGDRAFT. INTERNET SOCIE- TY, 07 July, 1-31 [0004] HUANG AT ; T LABS J. IPv6CP Options for PPP Host Configuration; draft-huang-ipv6cp-options 00.txt. IPV6CP OPTIONS FOR PPP HOST CONFIU- RATION; DRAFT-HUANG-IPV6CP-OPTIONS 03 INTERNET ENGINEERING TASK FORCE, IETF; STANDARDWORKINGDRAFT, IN- TERNET SOCIETY (ISOC) 4, RUE DES FALAISES CH- 1 GENEVA, SWITZERLAND, 03 February, 1- [000] VARADA S et al. IP Version 6 over PPP; rfc072.txt, 01 September 07, ISSN [0006] THOMSON BELLCORE T NARTEN IBM S. IPv6 Stateless Address Autoconfiguration; rfc2462.txt. IPv6 Stateless Address Autoconfiguration; rfc2462.txt, 01 December 1998, ISSN [0006] Renumbering Still Needs Work; rfc887.txt. RENUM- BERING STILL NEEDS WORK; RFC887.TXT, IN- TERNET ENGINEERING TASK FORCE, IETF; STANDARD. INTERNET SOCIETY, 27 May, 1-3 [0007] 17