Network Working Group P. Francis INTERNET-DRAFT (formerly P. Tsuchiya) Bellcore June 1993 Pip Identifiers Status of this Memo This document is an Internet Draft. 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. Internet Drafts may be updated, replaced, or obsoleted by other documents at any time. It is not appropriate to use Internet Drafts as reference material or to cite them other than as a "working draft" or "work in progress." Please check the I-D abstract listing contained in each Internet Draft directory to learn the current status of this or any other Internet Draft. Abstract Pip is an internet protocol intended as the replacement for IP version 4. The Pip header defines source and destination ID fields whose primary function it is to identify the source and destination of a Pip packet. While Pip systems treat the IDs as flat for the purpose of identification, it is useful to have hierarchical structure in the ID for other purposes, such as for doing a reverse DNS lookup on the ID. This internet-draft defines the structure of Pip IDs. 1. Changes From Previous Version The previous version is dated January 1993. Following is a summary of changes from that version. Pip WG, Expires December 1, 1993 [Page 1] INTERNET-DRAFT Pip Identifiers June 1993 1. A code point was added for "local" IP address. This is an IP address that is not guaranteed to be globally unique. With this code-point, a system can assign itself an ID based on its IP address, but the ID will only be unique within the systems "IP- unique" domain. As long as all IP addresses are unique, the ID will also be unique. 2. A section describing Pip ID notation was added. 3. The ASN.1 style of assignment was removed. This results in the Pip ID hierarchy not being self describing. This is the result of a general notion that Pip IDs should largely be considered flat entities, and in particular that Pip systems should use an Ethernet number to derive their Pip IDs. Because the ASN.1 style of assignment was removed, all of the previous assignments are different. 2. Introduction Pip is an internet protocol intended as the replacement for IP ver- sion 4. The Pip header defines source and destination ID fields whose function, in the context of host processing of Pip headers, is to only identify the source and destination of a Pip packet. While Pip systems treat the IDs as flat for the purpose of identification, it is useful to have hierarchical structure in the ID for other pur- poses, such as for doing a reverse DNS lookup on the ID. This internet-draft defines the structure of Pip IDs. Pip IDs have the following characteristics: 1. With well-known exceptions, they are globally unique binary strings 8 octets in length. 2. While they are hierarchically structured for assignment pur- poses, the Pip layer does not treat them as hierarchical. Further, assignments are set aside for such addresses as IEEE 802, resulting in what is effectively a flat ID. 3. Each component of the hierarchy is contiguous, and each hierarchical component is positioned in the Pip ID adjacent to its parent and child components. Pip WG, Expires December 1, 1993 [Page 2] INTERNET-DRAFT Pip Identifiers June 1993 4. Each level of the hierarchy can fall on an arbitrary bit boun- dary. 5. Pip IDs may be used for group identification, but such a Pip ID is not self-describing as being a group Pip ID. 6. Certain Pip IDs are well-known and have local meaning, such as "all routers on the subnet" and "this host". Pip IDs are formed by a hierarchy of number authorities, each of which is responsible for assigning the next lower level of the hierarchy. Generally it is the intent that Pip IDs be treated as flat, and that the hierarchy is solely for the purposes of insuring uniqueness. In particular, it is not assumed that an inverse DNS lookup on the Pip ID works. To the extent that the hierarchy in a Pip ID is exploited for other purposes, it is recommended that the hierarchical structure of Pip IDs follow administrative hierarchy (versus, for instance, topologi- cal hierarchy). It is up to each number authority to determine how the next level is assigned. I should be noted that some people are of the opinion that Pip IDs (or, network layer IDs in general) should have organizational hierarchical content that might be used for accounting of various kinds, inverse DNS lookups, and perhaps other things. Bob Smart and John Curran in particular have put forth arguments to this effect, and were acknowledged in the first draft of this document, which embraced their philosophy. Since then, I have become concerned that this placed too many constraints on Pip IDs, in particular with regards to auto-configuration of hosts, and the need to change Pip IDs when a host changes organizations. However, the issues of organ- izationally meaningful Pip IDs versus flat Pip IDs is still an open one. This specification does not prohibit the creation of organiza- tionally meaningful Pip IDs, should that be found useful by various organizations or across the board. 3. Pip ID Notation This section describes a uniform method to write Pip IDs. This method should be used whenever Pip IDs are written or typed. In par- ticular, all software used to read or write Pip IDs should use this notation. Pip WG, Expires December 1, 1993 [Page 3] INTERNET-DRAFT Pip Identifiers June 1993 A Pip ID is written as a sequence of 8 2-digit hex numbers separated by dots. Leading 0's are written. 4. Assigned Top-level Pip ID Numbers The top-level assignment authority (as yet unspecified, but IANA, the Internet Assigned Numbers Authority, seems to be a logical candidate) is responsible for assigning prefixes (the most significant bits) of the Pip ID. By assigning a prefix, the top-level authority creates a block of addresses, the authority of which is handed to another organization. The following Pip ID assignments are defined: 4.1. CCITT E.164 A CCITT E.164 address can be used to create a globally unique Pip ID. Thus, anybody with an E.164 address can use it to form a globally unique Pip ID. All Pip IDs formed from E.164 address have the form: | 14-bit prefix |---50 bits---| |00000000 000000| E164Address | That is, 14 bits of value 0, followed by the E.164 address, converted to binary (note this is not BCD encoding, but strict binary). 50 bits is adequate to encode all E.164 addresses in binary. 4.2. IEEE 802 Address An IEEE 802 address can be used to create a globally unique Pip ID. Thus, anybody with an IEEE 802 address can use it to form a globally unique Pip ID. All IEEE 802 based Pip IDs have the format: (hex) 80.00.IEEE802address That is, the first 16 bits are (hex) 8000, followed by the 48 bit IEEE 802 Address. Thus, the valid range of IEEE 802 based Pip IDs is: Pip WG, Expires December 1, 1993 [Page 4] INTERNET-DRAFT Pip Identifiers June 1993 80.00.00.00.00.00.00.00 to 80.00.ff.ff.ff.ff.ff.ff. 4.2.1. Locally Unique ID If a host has no IEEE 802 address, it can create a locally unique (local to the subnet) Pip ID using the IEEE 802 prefix. To do this, the local subnet address is placed in the low order part of the Pip ID, and the remaining bits of the 48-bit space are filled in ran- domly. 4.3. Local IP Domain A Pip ID can be formed from an IP address. As long as IP addresses are globally unique, a Pip ID formed from an IP address is also glo- bally unique. All IP Address based Pip IDs have the format: (hex) 40.00.00.00.IPaddress That is, the first 32 bits are 40.00.00.00, followed by a 32-bit IP Address. Thus, the valid range of IP based Pip IDs is: 40.00.00.00.00.00.00.00 to 40.00.00.00.ff.ff.ff.ff. 4.4. Flat Well-Known IDs There are any number of uses for identifying systems of a certain type, rather than specific systems. For instance, an ID for "all routers on the LAN" is useful for router discovery. This specifica- tion defines the following well-known Pip IDs. These well-known Pip IDs consist of a single hierarchy level (the top-level), but are so large that only one level of hierarchy is possible. Any Router = ff.ff.ff.ff.ff.ff.ff.fe Any Host = ff.ff.ff.ff.ff.ff.ff.fd Any System = ff.ff.ff.ff.ff.ff.ff.fc The above three well-known Pip IDs serve for functions such as "all Pip WG, Expires December 1, 1993 [Page 5] INTERNET-DRAFT Pip Identifiers June 1993 routers on a subnet", for instance in configuration algorithms such as router discovery. Other well-known Pip IDs are expected to be defined in the future. 4.5. Country Codes While it is expected that most hosts will obtain their Pip ID from an IEEE802 address (either from their interface card from from their CPU), it may be necessary to obtains IDs from other sources. For this purpose, a 32-bit block of IDs have been assigned to each coun- try. The countries can further assign blocks to organizations if desired. It should be noted that Pip systems with an assignment from a country's block is in no way constrained to reside in that country. Pip IDs formed by country code have a prefix of: |------22 bit prefix-----|--10 bits---|----32 bits---| |11000000 00000000 000000| ISO 3166 | remainder | ISO 3166 is the ISO standard for country codes. All country codes are between 0 and 999 (decimal), so 10 bits are adequate. The coun- try codes are encoded in binary when in the Pip ID. It is recognized that, in the long run, 32 bits per country will not be adequate. When countries need more code space, it can be allo- cated at that time. It is likely that we will have a better idea of ID assignment needs at that time. Pip WG, Expires December 1, 1993 [Page 6]