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