Network Working Group Patrick Frejborg Internet Draft May 28, 2009 Intended status: Experimental Expires: November 2009 Hierarchical IPv4 Framework draft-frejborg-hipv4-02.txt Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html This Internet-Draft will expire on November 28, 2009. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Frejborg Internet-Draft Hierarchical IPv4 Framework May 2009 Abstract This draft describes a framework how the current IPv4 address structure can be extended towards a similar hierarchical numbering structure as used in the Public Switched Telephone Network and bring a new level of hierarchy to the routing architecture of Internet. The hierarchical IPv4 framework is backwards compatible with the current IPv4 framework; it will also discuss a method to decouple the location and identifier functions, future applications can make use of the separation. The framework requires extensions to the existing Domain Name System architecture, the existing IPv4 stack of the end systems (hosts) and to routers in the Internet. The framework can be implemented incrementally to the hosts, databases, and routers. Table of Contents 1. Requirements Notation.........................................3 2. Introduction..................................................4 3. An overview of the hIPv4 framework............................5 4. Mandatory extensions to current architectures (unicast)......11 5. The header of a hIPv4 datagram...............................12 6. Life of a hIPv4 connection...................................12 7. Overlapping Source and Destination ELOC prefixes/ports.......15 8. Traceroute considerations....................................16 9. Multicast considerations.....................................16 10. Traffic engineering considerations..........................17 11. Large encapsulated datagrams................................17 12. Mobility considerations.....................................18 13. Affected Applications and Implications......................19 14. The Future Role of the LSR..................................20 15. Transition considerations...................................21 16. Security Considerations.....................................24 17. IANA Considerations.........................................24 18. Conclusion..................................................24 19. References..................................................24 19.1. References.............................................24 19.2. Informative References.................................25 20. Acknowledgements............................................25 Appendix A. Future IPv4 address allocation and routing policies.26 Frejborg Expires November 28, 2009 [Page 2] Internet-Draft Hierarchical IPv4 Framework May 2009 1. Requirements Notation The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. Frejborg Expires November 28, 2009 [Page 3] Internet-Draft Hierarchical IPv4 Framework May 2009 2. Introduction The hierarchical IPv4 (hIPv4) framework has been developed to address the issues discussed in the [IAB report] from the Routing and Addressing Workshop that was held by the Internet Architecture Board (IAB) on October 18-19, 2006, in Amsterdam, Netherlands. The current addressing (IPv4) and the future addressing (IPv6) schemes of Internet are single dimensional by their nature. This limitation, i.e. the single level addressing scheme, has created some roadblocks for further growth of Internet. If we compare Internet's current addressing schemes to other global addressing or location schemes we can notice that the other schemes use several levels in their structures. E.g. the postal system uses street address, city and country to locate a destination. Also to locate a geographical site we are using longitude and latitude in the cartography system. The other global network, the Public Switched Telephone Network (PSTN), have been build upon a three level numbering scheme that have enabled a hierarchical signaling architecture. By expanding the current IPv4 addressing scheme from a single level to a two level addressing structure most of the issues discussed in the IAB report can be solved. A convenient way to understand the two level addressing scheme of the hIPv4 framework is to compare it to the PSTN numbering scheme (E.164) which uses country codes, national destination codes and subscriber numbers. The Area Locator (ALOC) prefix in the hIPv4 addressing scheme can be considered similar as to the country code in PSTN, i.e. the ALOC prefix locates an area in Internet, the area is called an ALOC realm. The Endpoint Locator (ELOC) prefixes in hIPv4 can be compared to the subscriber numbers in PSTN, i.e. the ELOC is locally unique at the attached ALOC realm - the ELOC can also be attached simultaneously to several ALOCs realms (multi-homing). By inserting the ALOC and ELOC elements as a shim header (similar as in [MPLS] and [RBridge] architectures) between the IPv4 and the transport protocol headers, a hIPv4 header is created. But from the network point of view, the hIPv4 header "looks like" an IPv4 header and thus the current forwarding plane do not need to be upgraded though some minor changes are needed in the control plane (i.e. ICMP extensions). Another important influence source are the report and presentations from the [Dagstuhl] workshop that declared "a future Internet architecture must hence decouple the functions of IP addresses as names, locators, and forwarding directives in order to facilitate the growth and new network-topological dynamisms of the Internet". Frejborg Expires November 28, 2009 [Page 4] Internet-Draft Hierarchical IPv4 Framework May 2009 Thus, an identifier element needs to be added to the hIPv4 framework to provide a path for future applications to be able to remove the current dependency of the underlying network layer addressing scheme (local and remote IP address tuples). Host Identify Protocol [HIP] is proposing a new namespace that will decouple the locator and identifier realms from each other. In this document we will focus only on locators but discuss where and why HIP could fit in the hIPv4 framework. Some of the design goals of this proposal include: 1. The hierarchical IPv4 framework must be backwards compatible with the current IPv4 framework. 2. Minimize introduction of totally new protocols or signaling architectures, instead use well-proven protocols and insert extension to protocols where needed. 3. Create a hierarchical IPv4 addressing structure which enables a more localized allocation of IPv4 address blocks and therefore the routing table size in the "default-free zone" (DFZ) will be reduced. 4. Remove the single IPv4 address space constraint; reuse IPv4 address blocks by a hierarchy. 5. Improve site mobility, i.e. a site wishes to changes its attachment point to Internet without changing its IPv4 address block. 6. Make use of the current forwarding plane (IPv4); introduce a new forwarding plane for only a few routers in an Autonomous System or group of Autonomous Systems. 7. Reduce the amount of Network Address Translation (NAT) need for IPv4-to-IPv4 traffic. 8. Provide a smooth transition path to the hierarchical IPv4 framework. 3. An overview of the hIPv4 framework In this section we will discuss the roles of the new elements, introduced by the hIPv4 framework, and their dependencies. As mentioned in the introduction section the role of an Area LOCator (ALOC) prefix is similar as to a country code in PSTN. I.e. the ALOC Frejborg Expires November 28, 2009 [Page 5] Internet-Draft Hierarchical IPv4 Framework May 2009 prefix provides a location functionality of an area within an Autonomous System (AS), or an area spanning over a group of AS, in Internet. An AS can have several ALOC prefixes assigned, e.g. due to traffic engineering requirements. The ALOC prefix will be used for routing and forwarding purposes in Internet, thus the ALOC prefix must be globally unique and is allocated from an IPv4 address block. This globally unique IPv4 address block is called the Global Locator Block (GLB). When an area within an AS (or a group of AS) are assigned an ALOC prefix the area has the potential to become an ALOC realm. In order to establish an ALOC realm more elements, further than the ALOC prefix, are needed. One or multiple Locator Swap Routers (LSR) must be attached to the ALOC realm. A LSR element is a node capable of swapping the values of the IPv4 header and the new shim header, called the locator header. The swap mechanism of the headers is described in detail in section 6, step 4. Today's routers do not support the LSR functionality. Therefore the new functionality will most likely be developed on an external device attached to a router belonging to the ALOC realm. The external LSR might be a computer with two interface attached to a router, the first interface configured with the prefix of the ALOC and the second interface with any IPv4 prefix. The LSR do not make us of dynamic routing protocols, neither a forwarding information base (FIB) is needed - the LSR is producing a service, i.e. swapping headers. The swap mechanism is applied on per datagram basis and the information needed to carry out the swap is included in the header of the hIPv4 datagram. Thus a computer with enough computing and I/O resources is sufficient to take the role as a LSR. Later on, the LSR functionality might be integrated into the forwarding plane of a router. One LSR can not handle all the incoming traffic designated for an ALOC realm; it would also create a potential single point of failure in the network. Therefore, several LSRs shall be installed in the ALOC realm and the LSRs shall use the ALOC prefix as their locator and the routers are announcing the ALOC prefix as an Anycast address within the local ALOC realm. Also, the ALOC prefix is advertised throughout the DFZ by BGP mechanisms. The placement of the LSRs in the network will influence on the ingress traffic to the ALOC realm, the LSR is providing "nearest routing" functionality. Since the forwarding paradigm of multicast datagrams is quite different from forwarding unicast datagrams the multicast functionality will have an impact on the LSR. Also, the multicast LSR (mLSR) functionality is not available on today's routers, an external device is needed, and later on the functionality might be integrated to the routers. The mLSR shall take the role of an Anycast RP with MSDP and PIM capabilities, but to forward datagrams a FIB is not Frejborg Expires November 28, 2009 [Page 6] Internet-Draft Hierarchical IPv4 Framework May 2009 required. As with the LSR, the multicast hIPv4 datagrams are carrying all needed information in their headers in order to apply the swap, for details see section 9. The ALOC realm is not yet fully constructed, we can now locate the ALOC realm in Internet but to locate the hosts attached to the ALOC realm a new element is needed, i.e. the Endpoint Locator (ELOC). As mentioned in the introduction section the ELOC prefixes can be considered similar as to the subscriber numbers in PSTN. Actually, the ELOC is not a new element; the ELOC is a redefinition of the current IPv4 address configured at a host. The redefinition is applied because when the hIPv4 framework is fully implemented the global uniqueness of the IPv4 addresses are no longer valid and a more regional address allocation policy of IPv4 addresses can be deployed as discussed in Appendix A. The ELOC prefix will only be used for routing and forwarding purposes inside the local and remote ALOC domain, the ELOC prefix is not used in the intermediate ALOC domains. When a client is establishing a connection to a server residing outside the local ALOC realm the destination IP address field in the IPv4 header of an outgoing datagram is no longer the remote ELOC prefix - instead the remote ALOC prefix is installed in the destination IP address field of the IPv4 header. Because the destination IP address is an ALOC prefix, the intermediate ALOC realms do not need to carry the ELOC prefixes of other ALOC realms in their RIB - it is sufficient for the intermediate ALOC realms to carry only the ALOC prefixes. Outcome is that the RIB and FIB tables at each ALOC realm will be reduced when the hIPV4 framework is fully implemented. The ALOC prefixes are still globally unique and must be installed in the DFZ - thus the service provider can't control the growth of the ALOC prefixes but she/he can control the amount of local ELOC prefixes in her/his local ALOC realm. When the hIPv4 datagram arrives at the remote ALOC realm it will be forwarded to the nearest LSR, since the destination IPv4 address is the remote ALOC prefix. When the LSR has swapped the hIPv4 header, the destination IP address field in the IPv4 header is the remote ELOC, thus the hIPv4 datagram will be forwarded to the final destination at the remote ALOC realm. A host using an ELOC prefix can be attached simultaneously to two different ALOC realms without the requirement to deploy a classical multi-homing solution, for details see section 12. Next, how can we locate the remote ELOC (host) and remote ALOC realm in Internet, also how to assemble the header of the hIPv4 datagram? Another matter is that the addressing structure is no longer single dimensional; instead a second level has been added on top of the old one. It is obvious that the Domain Name System needs to support a new Frejborg Expires November 28, 2009 [Page 7] Internet-Draft Hierarchical IPv4 Framework May 2009 record type so that the ALOC information can be distributed to the hosts. To construct the header of the hIPv4 datagram either the host or an intermediate node (e.g. a proxy) should be used. A proxy solution is complicated, the proxy needs to listen to DNS messages and a cache solution does have scalability issues. A better solution is to extend the current IPv4 stack at the hosts so that the ALOC and ELOC elements are incorporated at the host's stack, backwards compatibility must be preserved. Most of the application will not be aware of the extensions - other applications, such as Mobile IP, SIP, IPsec AH and so on (see section 13) will suffer and can not be used outside their ALOC realm when the hIPv4 framework is fully implemented - unless the applications are upgraded. The reason is that these applications are depending upon the underlying network addressing structure to e.g. identify an endpoint. Since these applications needs to be modified when a new addressing scheme is deployed we should investigate what advantages we can gain by introducing identifier functionality to the hIPv4 framework. Thus, the Host Identifier Protocol [HIP] is briefly discussed in this document. The introduction of HIP solves the "identical connection situation", discussed in section 7. HIP will also enhance mobility and multi-homing solutions, see section 12. Frejborg Expires November 28, 2009 [Page 8] Internet-Draft Hierarchical IPv4 Framework May 2009 Definitions of terms Regional Internet Registry (RIR): Is an organization overseeing the allocation and registration of Internet number resources within a particular region of the world. Resources include IP addresses (both IPv4 and IPv6) and autonomous system numbers. Locator: A locator is a name for a point of attachment within the topology at a given layer. Objects that change their point of attachment(s) will need to change their associated locator(s). In the hIPv4 framework two types of locators have been defined, Area Locator (ALOC) and Endpoint Locator (ELOC). Global Locator Block (GLB): An IPv4 address block that is globally unique. Area Locator (ALOC): An IPv4 address assigned to locate an ALOC realm in Internet. The ALOC is assigned by a RIR to a service provider or a multi-homed enterprise. The ALOC is globally unique because it is allocated from the GLB. Endpoint Locator (ELOC): An IPv4 address assigned to locate a host in an ALOC realm. The ELOC block is assigned by a RIR to a service provider or to an enterprise. The ELOC block is only unique in a geographical region or globally unique in a business area defined by the RIRs. The final policy of uniqueness shall be defined by the RIRs. ALOC realm: An area in the Internet with at least one attached Locator Swap Router (LSR), also an ALOC must be assigned to the ALOC realm. The RIB of an ALOC realm holds both local ELOC prefixes and global ALOC prefixes. An ALOC realm exchanges only ALOC prefixes with other ALOC realms. Frejborg Expires November 28, 2009 [Page 9] Internet-Draft Hierarchical IPv4 Framework May 2009 Locator Swap Router (LSR): A router or host which is capable to process the hIPv4 header; once the header is processed the LSR will forward the datagram upon the IPv4 destination address. The LSR must have the ALOC assigned as its locator. Locator header: An 8 byte field consisting of ALOC and ELOC values hIPv4 header: A locator header is inserted between the IPv4 header and the header of the transport protocol, the new header combination is called a hIPv4 header. Identifier: An identifier is the name of an object at a given layer; identifiers have no topological sensitivity, and do not have to change, even if the object changes its point(s) of attachment within the network topology. Provider Independent Address Space (PI-addresses): An IPv4 address block which is assigned by a Regional Internet Registries directly to an end-user organization Provider Aggregatable Address Space (PA-addresses): an IPv4 address block assigned by a Regional Internet Registry to an Internet Service Provider which can be aggregated into a single route advertisement Frejborg Expires November 28, 2009 [Page 10] Internet-Draft Hierarchical IPv4 Framework May 2009 4. Mandatory extensions to current architectures (unicast) To implement the hierarchical IPv4 framework some basic rules are needed: 1. The DNS architecture must support a new extension, i.e. an A type Resource Record should be able to carry an ALOC prefix. 2. The hIPv4 capable host shall have information about the local ALOC value; the local ALOC value can be configured manually or provided via a new DHCP option. 3. A globally unique IPv4 address block shall be reserved; this block is called the Global Locator Block (GLB). A service provider can have one or several ALOC prefixes allocated from the GLB. A multi- homed enterprise might allocate an ALOC prefix from the GLB. 4. ALOC prefixes are announced via current BGP protocol to adjacent service providers and multi-homed enterprises, the ALOC prefixes are installed in the RIB of the DFZ. When the hIPV4 framework is fully implemented only ALOC prefixes are announced between the service providers and multi-homed enterprises. 5. A hIPv4 capable ALOC realm must have one or several LSRs attached to its realm. The ALOC prefix is configured as an Anycast IP address on the LSR. The Anycast IP address is installed to appropriate routing protocols in order to be distributed to the DFZ. 6. The IPv4 socket API at end hosts must be extended to support local and remote ALOC prefixes. The modified IPv4 socket API must be backwards compatible with the current IPv4 socket API. The outgoing hIPv4 datagram must be assembled by the hIPv4 stack with the local IP address from the socket as the source IP address and the remote ALOC prefix as the destination IP address in the IPv4 header. The local ALOC prefix is inserted in the ALOC field of the locator header. The remote IP address from the socket API is inserted in the ELOC field of the locator header. Frejborg Expires November 28, 2009 [Page 11] Internet-Draft Hierarchical IPv4 Framework May 2009 5. The header of a hIPv4 datagram 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Version| IHL |Type of Service| Total Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Identification |Flags| Fragment Offset | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Time to Live | Protocol | Header Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Destination Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Options | Padding | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Area Locator | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Endpoint Locator | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Area Locator: 32 bits An IPv4 address, the ALOC is assigned by a RIR to a service provider or a multi-homed enterprise with an Autonomous System (AS) number. The ALOC is globally unique because it is allocated from the GLB. Endpoint Locator: 32 bits An IPv4 address, the ELOC block is assigned by a RIR to a service provider or to an enterprise. The ELOC block is only unique in a geographical region or globally unique in a business area defined by the RIRs. The final policy of uniqueness shall be defined by the RIRs. 6. Life of a hIPv4 connection This section provides an example of a hIPv4 connection between two IPv4 hosts; a client and a server residing in different ALOC realms. When the hIPv4 stack is assembling the datagram for transport the hIPv4 stack shall decide if a legacy IPv4 or hIPv4 header is used upon the ALOC information received by a DNS reply. If the client's (local) ALOC value equals the server's (remote) ALOC value there is Frejborg Expires November 28, 2009 [Page 12] Internet-Draft Hierarchical IPv4 Framework May 2009 no need to use the hIPv4 header, because both the client and server reside in the local ALOC realm. The datagram is routed upon the IPv4 header since the datagram will not exit the local ALOC realm. When the local ALOC prefix doesn't match the remote ALOC prefix a hIPv4 header must be assembled because the datagram needs to be routed to a remote ALOC realm. In the current IPv4 framework, both TCP and UDP protocols calculate their header checksum values with the help of a pseudoheader. The pseudoheader calculation includes value from the IP header, i.e. source IP address, destination IP address and value of the protocol field. By this mechanism more reliability is achieved. To preserve current reliability level the hIPv4 stack shall also include the locator header when calculation of the TCP and UDP pseudoheader is applied. Therefore, a mechanism to identify when to include the values of the locator header in the pseudoheader calculation is needed. TCP and UDP pseudoheader checksum calculation shall be extended to include the locator header. Because routers and hosts are still using the IPv4 framework the devices must detect when a hIPv4 header is used. IPv4 uses protocol values for TCP, UDP, ICMP, GRE, IP-in-IP and so on. It is recommended that new values are reserved for the current IPv4 protocols in the hIPv4 framework. The new protocol values will act as an indicator of the usage of the hIPV4 header. The IPv4 socket API will not be aware of the new protocol values; it is the hIPv4 stack at the client that changes the protocol value when a remote ALOC realm connection is established. When the datagram has reached the server the hIPv4 stack changes the protocol value to the appropriate IPv4 value for the socket API. Therefore the application is not aware of new protocol values. How a hIPV4 connection is established follows: 1. The client queries the DNS server; the hIPv4 stack notice that the local and remote ALOC doesn't match and therefore must use the hIPv4 header for the connection. The hIPv4 stack of the client must assemble the datagram in the following way: a. change the protocol value to match appropriate hIPv4 value b. local IP address from API -> source IP address field c. remote IP address from API -> ELOC field d. local ALOC prefix -> ALOC field Frejborg Expires November 28, 2009 [Page 13] Internet-Draft Hierarchical IPv4 Framework May 2009 e. remote ALOC prefix-> destination IP address 2. Apply checksum calculations, include locator header values for the pseudoheader calculation, when completed the datagram is transmitted. 3. The hIPv4 datagram is routed throughout Internet upon the destination IP address of the IPv4 header. 4. The hIPv4 datagram will reach the closest LSR of the remote ALOC realm. When the LSR notice that the datagram matches the given local ALOC value the LSR must: a. verify IP and TCP/UDP checksums, include locator header values for the pseudoheader calculation b. replace the source address in the IPv4 header with the ALOC value of the locator header c. replace the destination address in the IPv4 header with the ELOC value of the locator header d. replace the ALOC value in the locator header with the destination IP address of the IPv4 header e. replace the ELOC value in the locator header with the source IP address of the IPv4 header f. decrease TTL with one g. calculate IP and TCP/UDP checksums, include locator header values for the pseudoheader calculation h. forward the datagram upon the destination IP address of the IPv4 header 5. The swapped hIPv4 packet is now routed inside the remote ALOC realm upon the new destination IP address of the IPv4 header to the final destination. 6. The server receives the hIPv4 datagram, the hIPv4 stack must verify IP and TCP/UDP checksums, include locator header values for the pseudoheader calculation 7. The hIPv4 stack of the server must present to the extended IPv4 socket API the following: Frejborg Expires November 28, 2009 [Page 14] Internet-Draft Hierarchical IPv4 Framework May 2009 a. change the protocol value to match appropriate IPv4 value b. source IP address -> remote ALOC c. destination IP address -> local IP address d. ALOC -> local ALOC e. ELOC -> remote IP address 8. The server's application will respond to the client and the returning datagram will take almost the same steps, which are steps 1 to 6, as when the client started the session. In step 1 the server doesn't need to do a DNS lookup since all information is provided by the datagram. 7. Overlapping Source and Destination ELOC prefixes/ports Because an ELOC prefix is only significant within the local ALOC realm there is a slight possibility that a connection between two hosts residing in separate ALOC realms might use the same source and destination ELOC prefixes. But the connection is still unique because the two processes communicating over the transport protocol form a logical connection which is uniquely identifiable by the five tuples involved, i.e. by the combination of . The connection might no longer be unique when two clients with the same source ELOC prefix residing in two separate ALOC realms are accessing a server locate in a third ALOC realm. In this scenario a possibility exists that the clients will use the same local port value. This situation will cause an "identical connection situation" for the application layer. To overcome this scenario the hIPv4 stack must accept only one unique connection with the help of the ALOC information. If there is an "identical connection situation" - i.e. both clients uses the same values in the five tuples - the hIPv4 stack shall allow only the first established connection to continue, the following connections must be prohibited and the clients are informed by ICMP notification about the "identical connection situation". With the introduction of HIP, which is inserted between the network and transport layer, the "identical connection situation" can be avoided because the application can either identify the remote endpoint via the globally unique Host Identifier or the Local Scope Identifier. Frejborg Expires November 28, 2009 [Page 15] Internet-Draft Hierarchical IPv4 Framework May 2009 8. Traceroute considerations As long as the traceroute is executed inside the local ALOC realm normal IPv4 traceroute mechanism can be used. As soon as the traceroute exits the local ALOC realm the locator header shall be used in the notifications. Therefore extension to ICMP protocol shall be implemented, the extensions shall be compatible with [RFC4884]. 9. Multicast considerations Since source and destination IPv4 prefixes are only installed in the RIB of the local ALOC realm there is a constraint with Reverse Path Forwarding (RPF) which is used to ensure loop-free forwarding of multicast packets. The source IP address of a multicast group (S,G) is used against the RFP check. The source IP address can no longer be used as a RFP checkpoint outside the local ALOC realm. To enable RPF globally for a (S,G), the multicast enabled LSR (mLSR) must at the source ALOC realm replace the source IP address with the local ALOC prefix for inter-ALOC multicast streams. This can be achieved if the local LSR act also as an Anycast Rendezvous Point with Multicast Source Discovery Protocol (MSDP) and Protocol Independent Multicast capabilities; with these functionalities the LSR becomes a multicast enabled LSR (mLSR). The sender register at the mLSR and a source tree is established between the sender and the mLSR. When an inter-ALOC realm receiver subscribes to the multicast group the mLSR have to swap the IPv4 multicast datagram in the following way: a. verify IP and UDP checksums, include locator header values for the pseudoheader calculation b. source IP address -> local ALOC c. destination IP address : no changes d. ALOC : no changes e. ELOC : no changes f. decrease TTL with one g. calculate IP and UDP checksums, include locator header values for the pseudoheader calculation h. forward the datagram to the shared multicast tree Frejborg Expires November 28, 2009 [Page 16] Internet-Draft Hierarchical IPv4 Framework May 2009 In order for the mLSR to function as described above the sender must assemble the multicast hIPv4 datagram in the following way: a. change the protocol value to match appropriate hIPv4 value b. local IP address from API -> source IP address (S) -> ELOC c. remote IP address from API -> destination IP address (G) d. local ALOC -> ALOC e. remote ALOC : not applicable The downstream routers from the mLSR to the receiver will use the source IP address (which value is the source ALOC prefix after the mLSR) in the IPv4 header for RPF verification. In order for the receiver to create RTCP receiver reports all information is provided in the hIPv4 header of the datagram. Because Source Specific Multicast (SSM) and IGMPv3 uses IP addresses in the payload both protocols needs to be modified to support the hierarchical IPv4 framework. 10. Traffic engineering considerations When hIPv4 framework is fully implemented ingress load balancing to an ALOC realm can be influenced by the placement of LSRs at the realm; a LSR provides "nearest routing" scheme. Also, if RIR policies allows, a service provider can have several ALOC assigned, hence traffic engineering and filtering can be done with the help of ALOC prefixes. E.g. sensitive traffic can be aggregated under one ALOC prefix which is not fully distributed into the DFZ of Internet. If needed an ALOC Traffic Engineering solution between ALOC realms might be developed, i.e. create explicit paths that can be engineered via specific ALOC prefixes. Further studies are needed; first it should be evaluated if there is demand for such a solution. 11. Large encapsulated datagrams Adding the locator header to an IPv4 datagram in order to create a hIPv4 datagram will increase the size of it but since the datagram is assembled at the host it will not add complications of current Path MTU Discovery (PMTUD) mechanism in the network. The intermediate network between two hosts will not see any difference in the size of datagram; IPv4 and hIPv4 datagram sizes are the same from the network point of view. Frejborg Expires November 28, 2009 [Page 17] Internet-Draft Hierarchical IPv4 Framework May 2009 12. Mobility considerations This section will consider two types of mobility solutions, site mobility and host mobility. Site mobility definition: a site wishes to changes its attachment point to the Internet without changing its IP address block Today multi-homing is the most common solution for enterprises that wishes to achieve site mobility. Multi-homing is one of the key findings behind the growth of the DFZ RIB, see the [IAB report], section 2.1 and 3.1.2. The hIPv4 framework can provide a solution for enterprises to have site mobility without the requirement of implementing a classical multi-homed solution. This new multi-homed solution utilizing PI addresses is depended upon the forthcoming IPv4 address allocation policy which is discussed in Appendix A. If the geographical region based IPv4 address block allocation is deployed the enterprise can be concurrently attached to two different Internet service providers (ISP) without the need to implement AS border routing. The ISPs provide their globally unique ALOC prefixes for the enterprise and the IPv4 address block of the enterprise is geographically unique, a PI IPv4 address block. The enterprise can change on per host basis the local ALOC prefix, i.e. from the previous ISP's ALOC prefix to the new ISP's ALOC prefix. Connections initiated at the enterprise needs to be routed to the correct ISP, i.e. the border router of the enterprise needs to apply policy based routing upon the ALOC prefix in the locator header. For connections initiated from the Internet the DNS record for a host needs to be updated, also the local ALOC prefix on the host needs be changed to achieve a symmetric path. Since the border router is enforcing policy based routing upon the ALOC prefix of the locator header the server can apply basic session load balancing over the two ISPs based upon from which ISP the connection has been initiated, i.e. if the server have two valid DNS records with two different ALOC prefixes. The updating rate of DNS records is considered slow but recent studies have shown that this is no longer the case, updates at rates as high as once per second can be achieved, see [DynamicDNS]. Conclusion is that a single-homed enterprise can achieve smooth transition from one ISP to another by only changing the ALOC prefix on the hosts and at DNS records - the local IP addressing (ELOC) scheme remains intact. Also a single-homed enterprise can become multi-homed without implementing AS border routing or to have an own ALOC prefix assigned. If a better session load balancing scheme is required the application should be migrated to a modern transport protocol, i.e. [SCTP], or migrated to make us of HIP which is providing support for Frejborg Expires November 28, 2009 [Page 18] Internet-Draft Hierarchical IPv4 Framework May 2009 multi-homing; both SCTP and HIP might require changes at the application level. Host mobility definition: a host moves relatively rapidly between different networks, changing its IP layer network attachment point Mobile IP [MIP] is used today for IPv4 hosts in order to provide mobility. Mobile IP is an overlay protocol; it is also an application that uses IP addresses in its payload. It is obvious that hIPv4 extensions need to be added to the MIP framework. Because hIPv4 framework requires changes to the current IPv4 stack it should be investigate if HIP can be integrated to the hIPv4 stack. The use of HIP is decoupling the application from the IP addressing scheme of the underlying network layer and thus it will be easier to design applications that are more optimized for host mobility. 13. Affected Applications and Implications There are several applications that are inserting IPv4 address information in the payload of a datagram. Some applications uses the IPv4 address information to create new connections or for identification purposes. This section is trying to list the applications that need to be enhanced; however, this is by no means a comprehensive list. The applications can be divided in four main categories: o Applications based on raw sockets, a raw socket is receiving datagrams containing the complete header in comparison to the other sockets that only receives the payload. o Applications needed to enable the hIPv4 framework, i.e. DNS and DHCP databases which must be extended to support ALOC prefixes. o Applications that insert IPv4 addresses to the payload and uses the IPv4 address for setting up new connections or for some kind of identification. The application belonging to this category can not set up connections to other ALOC domains until extensions have been incorporated. Within the local ALOC domain there are no restrictions since the current IPv4 scheme is still valid. The following applications have been identified: o SIP; IPv4 addresses are inserted in the SDP, Contact and Via header Frejborg Expires November 28, 2009 [Page 19] Internet-Draft Hierarchical IPv4 Framework May 2009 o Mobile IP; the mobile node uses several IPv4 addresses during the registration process o IPsec AH; designed to detect alterations at the IPv4 packet header o RSVP; RSVP messages are sent hop-by-hop between RSVP-capable routers to construct an explicit path o ICMP; notifications needs to be able to incorporate ALOC information and assemble the hIPv4 header in order to be routed back to the source o Source Specific Multicast; the receiver must specify the source address of the sender o IGMPv3; a source-list is included in the IGMP reports o Applications related to security, such as firewalls, must be enhanced to support ALOC prefixes and the new protocol parameters o Applications that will function with FQDN but many uses an IPv4 addresses instead, such as ping, traceroute, telnet and so on. The CLI syntax needs to be upgraded to support ALOC and ELOC information via the extended socket API. 14. The Future Role of the LSR The LSR was added to the framework in order to provide a smooth transition from the current IPv4 framework to the hierarchical IPv4 framework, i.e. a major forklift of the current forwarding plane is avoided by the introduction of the LSR element. In the future, the LSR can be left as such in the network, if preferred, or the LSR functionality can be expanded towards the edge when routers are upgraded due to their natural lifecycle process. Once an upgrade of a router is required because of e.g. increased demand for bandwidth, the modified forwarding plane might support concurrently IPv4 and hIPv4 forwarding - and the LSR functionality can be pushed towards the edge (the ultimate goal is to have LSR functionality integrated in the hosts). This is accomplished by adding extension to the current routing protocols, both IGP and BGP. When a LSR receives a hIPv4 datagram where the destination IPv4 address matches the local ALOC prefix the LSR shall - contrary to the tasks defined in section 6, step 4 - lookup the ELOC field in the locator header and compare this value against the FIB. If the next-hop entry is LSR capable the datagram shall be forwarded upon the ELOC value. If the next-hop is a Frejborg Expires November 28, 2009 [Page 20] Internet-Draft Hierarchical IPv4 Framework May 2009 legacy IPv4 router the LSR must apply the tasks defined in section 6, step 4 and once completed forward the datagram upon the new IPv4 destination address. Once the routers from the first ingress LSR to the final destination host is upgraded to support hIPv4 forwarding there exist no longer a need to implement LSR functionality in the network of the remote ALOC realm, the datagram is forwarded as such to the host's extended stack. The hIPv4 stack must check that the ELOC value matches its local IPv4 address, because the destination IPv4 address matched the local ALOC prefix. Then the hIPv4 stack of the destination must present to the extended IPv4 socket API the following: a. change the protocol value to match appropriate IPv4 value b. source IP address -> no change c. destination IP address -> not applicable d. ALOC -> remote ALOC e. ELOC -> destination IP address Multicast LSR (mLSR) functionality remains in the network; it is an extension to the Anycast RP with MSDP element. For connections inside the ALOC domain legacy IPv4 forwarding plane is kept in place. 15. Transition considerations The hIPv4 framework is not introducing any new protocols that would be mandatory to carry out the transition from IPv4 to hIPv4; instead extensions are added to existing protocols. The introduction of an identifier require a new protocol, i.e. HIP, which is currently in experimental status - the lack of the new identifier protocol will not create a roadblock to carry out the transition to hIPv4. Note, experimental deployments of HIP are available today and hIPv4 is only a theoretical study. The hIPv4 framework requires extensions to the current IPv4 stack, databases and to some applications that use IP addresses in the payload but the current forwarding plane in Internet remains intact apart from that a new forwarding element (the LSR) is required to create an ALOC realm. Extensions to the IPv4 stack, databases, applications that uses IP addresses in the payload and routers can be deployed in parallel with the current IPv4 framework. Even genuine hIPv4 connections can be established between hosts though the current single dimensional Internet structure is still present. When will the Frejborg Expires November 28, 2009 [Page 21] Internet-Draft Hierarchical IPv4 Framework May 2009 single dimensional routing architecture then be upgraded to a two level architecture? The author thinks there are two possible tipping points: o When the RIB of DFZ is getting close to the capabilities of current forwarding plane - who will pay for the upgrade? Or will the service provider only accept ALOC prefixes from other service providers and avoid capital expenses? o When the depletion of IPv4 addresses is causing enough problems for enterprises The biggest risk why hIPv4 framework will not succeed is the short timeframe before the expected depletion of the IPv4 address space occurs. Also, will enterprise give up their global allocation of the current IPv4 address block they have gained? Another risk is, will the enterprises and residences carry out an upgrade of their hosts and security nodes? The media has announced several times the meltdown of Internet and the depletion of IPv4 addresses - but the potential chaos has been postponed several times and the general public has lost their interest in these announcements. Perhaps other approaches could be worthwhile to study, instead try to find other valuable arguments that the general public could be interested in, such as: o Not all hosts needs to be upgraded, only those hosts that are directly attached to the Internet. These kinds of hosts are portable laptops, smart mobile phones, proxies, and DMZ/frontend servers. But the most critical servers, the backend servers where enterprises keep their most critical business applications do not need to be upgraded; the backend servers should not be reached at all from Internet - only from the Intranet - and this functionality can be achieved with the hIPv4 framework, since it is backwards compatible with the current IPv4 stack. o Mobility, it is estimated that the demand for applications that performs well over the wireless access network will increase. Introduction of HIP opens up a new possibility to create new solutions and applications that are optimized for mobility. HIP requires an upgrade of the hosts' stack; if possible the hIPv4 stack should also contain HIP features. Applications designed for mobility could bring competitive benefits for the enterprises. Frejborg Expires November 28, 2009 [Page 22] Internet-Draft Hierarchical IPv4 Framework May 2009 o The intermediate nodes in the network do not need to be upgraded, the current forwarding plane can still be used and the hIPv4 datagram is capable to traverse most of the current NAT implementations. The benefit is that the current network equipment can be preserved at the service providers, enterprises and residences. That means that the carbon footprint is a lot lower compared to other solutions. Many enterprises do have green programs and many residential users are concerned with the global warming issue. o The migration from IPv4 to IPv6 will increase the RIB and FIB throughout DFZ, will it require a new upgrade of the forwarding plane as discussed in the IAB report is unclear. Most likely an upgrade is needed, the outcome of deploying IPv4 and IPv6 concurrently is that the routers need to have larger memories for the RIB and FIB - every globally unique prefix is installed in the routers that are participating in the DFZ. Since the enterprise is reserving one or several RIB/FIB entries on every router in the DFZ it means that the enterprise is increasing the power consumption of Internet, thus increasing the carbon footprint. And many enterprises are committed to green programs - if hIPv4 gets deployed, the power consumption of Internet will not grow as much as compared in an IPv4 to IPv6 transition scenario. o Another issue, if the migration from IPv4 to IPv6 occurs, is that the routers in the DFZ most likely need to be upgraded to more expensive routers - as discussed in the IAB report. In the wealthy part of the world, where a large penetration of Internet users is already present, the service provider can pass along more easily the costs of the upgrade to their subscribers - with a "wealthy/high penetration" ratio the cost will not grow that much that the subscribers would abandon Internet. But in the less wealthy part of the world, where there is usually a lower penetration of subscribers, the cost of the upgrade cannot that easily be covered - a "less wealthy/low penetration" ratio could have a dramatic increase on the cost that needs to be passed along to the subscribers. And thus fewer subscribers could afford to get connected to the Internet. For the global enterprises and the enterprises in the less wealthy part of the world, this scenario could mean less potential customers and there could be situations when the nomads of the enterprises can't get connected to Internet. This is also not fair; every human being should have a fair chance to be able to enjoy the Internet experience - and the wealthy part of the world should take this right into consideration. Many enterprises are committed to Corporate Social Responsibility programs. Frejborg Expires November 28, 2009 [Page 23] Internet-Draft Hierarchical IPv4 Framework May 2009 16. Security Considerations Hijacking of a single ELOC prefix by longest match from another ALOC realm is no longer possible since the prefixes are separated by a locator, the ALOC. To apply a hijack of a certain prefix the whole ALOC realm must be routed via a bogus ALOC realm. Studies should be carried out with the Secure Inter-Domain Routing (SIDR) workgroup if the ALOC prefixes can be protected from hijacking. 17. IANA Considerations TBD 18. Conclusion This document provides a high level overview of the hierarchical IPv4 framework which could be build in parallel with the current single dimensional Internet by implementing extensions at several architectures. Implementation of the hIPv4 framework will not require a major service window break in the Internet, neither at the internal networks of enterprises. Basically, the hIPv4 framework is an evolution of the current IPv4 framework. For connections inside an ALOC realm the IPv4 framework can be used in the future and for inter-ALOC realm connections the hIPv4 framework is needed. Though there is a long journey ahead and many things that need to be sorted out the hierarchical IPv4 framework looks promising. The transition can be attractive for the enterprises since the hIPv4 framework doesn't create a catch-22 situation, it introduces functionalities (related to site mobility) that could better serve their business models, it slows down the expected growth of Internet's carbon footprint and it is inline with the Corporate Social Responsibility programs that many enterprises have implemented. 19. References 19.1. References [IAB report] Meyer, D., Zhang, L., Fall, K., "Report from the IAB Workshop on Routing and Addressing", RFC 4948, September 2007 Frejborg Expires November 28, 2009 [Page 24] Internet-Draft Hierarchical IPv4 Framework May 2009 [MPLS] Rosen, E., Tappan, D., Fedorkow, G., Rekther, Y., Farinacci, D., Li, T., Conta, A., "MPLS Label Stack Encoding", RFC 3032, January 2001 [RFC4884] Bonica, R., Gan, D., Tappan, D., Pignataro, C. "Extended ICMP to support Multi-Part Messages", RFC 4884, April 2007 [RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G.J., Lear, E. "Address Allocation for Private Internets", RFC 1918, February 1996 [HIP] Moskowitz, R., Nikander, P. "Host Identity Protocol (HIP) Architecture", RFC 4423, May 2006 [SCTP] Stewart, R. "Stream Control Transmission Protocol", RFC 4960, September 2007 [MIP] Perkins, C. "IP Mobility Support for IPv4", RFC 3344, August 2002 19.2. Informative References [RBridge] Perlman, R., "RBridges, Transparent Routing", Infocomm, 2004 [DynamicDNS] Pappas, A., Hailes, S., Giaffreda, R., "Mobile Host Location Tracking through DNS", University College London and BTexact Technologies, 2002 [Dagstuhl] Arkko, J., Braun, M.B., Brim, S., Eggert, L., Vogt, C., Zhang, L. "Perspectives Workshop: Naming and Addressing in a Future Internet", Dagstuhl, 2009 20. Acknowledgements The author would like to acknowledge Aki Anttila and Antti Jarvenpaa for giving helpful feedback. Frejborg Expires November 28, 2009 [Page 25] Internet-Draft Hierarchical IPv4 Framework May 2009 Appendix A. Future IPv4 address allocation and routing policies This section is not part of the draft, it is used to discuss and study how the hIPv4 framework could influence on the IPv4 address allocation and routing policies to ensure that the new framework will enable some re-usage of IPv4 address blocks. It is the Regional Internet Registries (RIRs) that shall define the final policies. When the hIPv4 framework is fully implemented every ALOC realm can have a full IPv4 address space - except the GLB - to allocate ELOC prefix blocks from. There are some implications though. In order for an enterprise to achieve site mobility, i.e. to change service provider without changing its IP addressing scheme, the enterprise should implement an Autonomous System (AS) solution with ALOC prefix at the attachment point to the service provider. Larger enterprises do have the resources to implement AS border routing; most of the large enterprises have already implemented multi-homing solutions. The small and midsize enterprises (SME) may not have the resources to implement AS border routing, or the implementation introduces unnecessary costs for the SME. Also if every SME needs to have an ALOC prefix it will have an impact on the RIB at the DFZ, the RIB will be populated with a huge amount of ALOC prefixes. It is clear that a compromise is needed. A SME is usually single- homed and the SME should be able to reserve a PI address block from the RIR without the need to be forced to create an ALOC realm, i.e. implement a LSR solution and AS border routing. The PI address block is no longer globally unique, the SME can only reserve the PI address block for the country or countries where it is active or has it attachment point to Internet. The attachment point rarely changes to another country; therefore it is sufficient that the PI address block is locally unique. When the SME is replacing its Internet service provider the SME do not have to change its ELOC addressing scheme - only the local ALOC prefix at the hosts are changed. The internal traffic at an SME does not use the ALOC prefix, the internal routing is applied by the IPv4 header and thus the internal routing and addressing architectures are preserved. Mergers and acquisitions of SME can cause IP address conflicts, because the PI address block is hereafter only locally unique. If a SME in country A overtakes a SME in country B there is a slight chance that both SME can have overlapping IPv4 addresses. An idea to address this scenario is to categorize the SME upon their business areas. It is highly unlikely that a SME in, e.g. agriculture business area will ever acquire a SME in the medical business area, or vice versa. When a SME applies for a PI address block the RIR could verify to which business area the SME operates in and do a global check in Frejborg Expires November 28, 2009 [Page 26] Internet-Draft Hierarchical IPv4 Framework May 2009 order to give the SME a globally unique IP address block from that business area. Large enterprises also merge, but since the large enterprises are usually multi-homed the merger of networks can be rapidly carried out with the help of ALOC realm routing. During a merger usually the infrastructure of a company is slowly incorporated to the other company's infrastructure, this integration usually requires redesign of the network architecture and therefore in most cases the ALOC realm routing can be removed. Finally, residential users will receive only PA addresses. When a residential user changes a service provider the residential user has to replace the IP addresses. A PA IP address block is no longer globally unique, every Internet service provider can use the PA address blocks at their ALOC realms. The hIPv4 framework will provide re-usage of IPv4 address blocks, the globally unique reservation of IPv4 address block shall be replaced by a geographical region and/or business area specific allocation. The biggest challenge is when merger and acquisitions are carried out, there is a possibility that overlapping of IP addresses could still happen but the hIPv4 framework reduces this problem to a minimum compared what is seen today during mergers with the usage of private IP addresses [RFC1918]. Authors' Addresses Patrick Frejborg Email: pfrejborg@gmail.com Frejborg Expires November 28, 2009 [Page 27]