RFC 1621
Pip Near-term Architecture
Pip Near-term Architecture 🎀
Okay bestie, let's dive into RFC 1621 🦋 It's called Pip Near-term Architecture and it's Informational, so it's sharing info, not setting a standard. P. Francis from NTT wrote it, and it came out in May 1994. The header doesn't list any RFCs it obsoletes or updates, so it's just doing its own thing ✨
Status of this Memo ✨
This memo is here to give the Internet community information 🌈 It does not specify an Internet standard of any kind. And distribution is unlimited, so share it with everyone 💖
Preamble 💜
Back in 1992 and 1993, the Pip internet protocol (made at Belclore) was one of the candidate replacments for IP 🧚 In mid 1993, Pip got merged with another candidate, the Simple Internet Protocol (SIP), and together they became SIPP (SIP Plus). Pip's big ideas survived, especially keeping identifier separate from address and using the source route mechanism for rich routing. But lots of other Pip ideas didn't make the cut 🙈 This RFC and the companion RFC "Pip Header Processing" are here to record Pip's ideas, the good ones and the bad ones too 🫶
This document references a bunch of Pip draft memos that were at different stages of being finished. The basic ideas from those memos show up here, but many details got lost along the way. If you're super interested, you can request those internet drafts directly from P. Francis at francis@cactus.ntt.jp 💌
The rest of this document is copied word for word from the Pip draft memo with the same title, the one that existed when the Pip project ended. So if any text says Pip is meant to replace IP, just ignore it 🙃
Abstract 🌸
Pip is an internet protocol meant to replace IP version 4 🔥 It's general purpose and designed to evolve to all forseeable internet protocol requirements. This spec describes the routing and addressing architecture for near-term Pip deployment. We say "near-term" because Pip was built with evolution in mind, so other architectures are expected later. This document doesn't reference those future architectures though 🦋
Table of Contents 🧚
1. Pip Architecture Overview ................................... 4
1.1 Pip Architecture Characteristics ........................... 4
1.2 Components of the Pip Architecture ......................... 5
2. A Simple Example ............................................ 6
3. Pip Overview ................................................ 7
4. Pip Addressing .............................................. 9
4.1 Hierarchical Pip Addressing ................................ 9
4.1.1 Assignment of (Hierarchical) Pip Addresses ............... 12
4.1.2 Host Addressing .......................................... 14
4.2 CBT Style Multicast Addresses .............................. 15
4.3 Class D Style Multicast Addresses .......................... 16
4.4 Anycast Addressing ......................................... 16
5. Pip IDs ..................................................... 17
6. Use of DNS .................................................. 18
6.1 Information Held by DNS .................................... 19
6.2 Authoritative Queries in DNS ............................... 20
7. Type-of-Service (TOS) (or lack thereof) ..................... 21
8. Routing on (Hierarchical) Pip Addresses ..................... 22
8.1 Exiting a Private Domain ................................... 23
8.2 Intra-domain Networking .................................... 24
9. Pip Header Server ........................................... 25
9.1 Forming Pip Headers ........................................ 25
9.2 Pip Header Protocol (PHP) .................................. 27
9.3 Application Interface ...................................... 27
10. Routing Algorithms in Pip .................................. 28
10.1 Routing Information Filtering ............................. 29
11. Transition ................................................. 30
11.1 Justification for Pip Transition Scheme ................... 31
11.2 Architecture for Pip Transition Scheme .................... 31
11.3 Translation between Pip and IP packets .................... 33
11.4 Translating between PCMP and ICMP ......................... 34
11.5 Translating between IP and Pip Routing Information ........ 34
11.6 Old TCP and Application Binaries in Pip Hosts ............. 34
11.7 Translating between Pip Capable and non-Pip Capable DNS
Servers ................................................... 35
12. Pip Address and ID Auto-configuration ...................... 37
12.1 Pip Address Prefix Administration ......................... 37
12.2 Host Autoconfiguration .................................... 38
12.2.1 Host Initial Pip ID Creation ............................ 38
12.2.2 Host Pip Address Assignment ............................. 39
12.2.3 Pip ID and Domain Name Assignment ....................... 39
13. Pip Control Message Protocol (PCMP) ........................ 40
14. Host Mobility .............................................. 42
14.1 PCMP Mobile Host message .................................. 43
14.2 Spoofing Pip IDs .......................................... 44
15. Public Data Network (PDN) Address Discovery ................ 44
15.1 Notes on Carrying PDN Addresses in NSAPs .................. 46
16. Evolution with Pip ......................................... 46
16.1 Handling Directive (HD) and Routing Context (RC) Evolution. 49
16.1.1 Options Evolution ....................................... 50
References ..................................................... 51
Security Considerations ........................................ 51
Author's Address ............................................... 51Introduction 🌷
Pip is an internet protocol meant to replace IP version 4 💖 It's general purpose and designed to handle all forseeable internet protocol requirements. This spec describes the routing and addressing architecture for near-term Pip deployment. Near-term is the key phrase here, because Pip is built with evolution in mind, so other architectures are expected in the future. This document doesn't reference those future architectures, except to talk about Pip evolution in general 🧠
This document gives you the big picture of how Pip works. It's mainly a framework for understanding the whole set of documents that make up Pip, so think of it as your map 🗺️
1. Pip Architecture Overview ✨
The Pip near-term architecture is an incremental step up from IP. Just like IP, near-term Pip is datagram-based. Pip runs under TCP and UDP. DNS is used the same way it's used now, to distribute name to Pip Address (and ID) mappings. Routing in the near-term Pip architecture is hop-by-hop, though it's possible for a host to create a domain-level source route (for policy reasons) 🛣️
Pip Addresses have more hierarchy than IP. That improves scaling on one hand, but it also brings extra addressing complexities, like multiple addresses, on the other 🙃 Pip makes the most of hierarchical addresses by making them provider-based, then using them to make policy routing choices (here, provider selection). Pip also has mechanisms for automatically assigning provider prefixes to hosts and routers in domains. This is the main difference between the near-term Pip architecture and the IP architecture 🔥 (In the remainder of this paper, unless otherwise stated, "Pip architecture" means the near-term Pip architecture described here.)
2. Pip Architecture Characteristics 💅
The proposed architecture for near-term Pip has the following characteristics:
- Provider-rooted hierarchical addresses. 🌳
- Automatic domain-wide address prefix assignment.
- Automatic host address and ID assignment.
- Exit provider selection.
- Multiple defaults routing (default routing, but to multiple exit points).
- Equivalent of IP Class D style addressing for multicast.
- CBT style multicast.
- "Anycast" addressing (route to one of a group, usually the nearest).
- Providers support forwarding on policy routes (but initially will not provide the support for sources to calculate policy routes).
- Mobile hosts. 📱
- Support for routing across large Public Data Networks (PDN). 🌐
- Inter-operation with IP hosts (but only within an IP-address domain where IP addresses are unique). In particular, an IP address can be explicitly carried in a Pip header.
- Operation with existing transport and application binaries (though if the application contains IP context, like FTP, it may only work within a domain where IP addresses are unique).
- Mechanisms for evolving Pip beyond the near-term architecture. 🦋
1.2 Components of the Pip Architecture 🧩
The Pip Architecture is made up of the following five systems:
- Host (source and sink of Pip packets)
- Router (forwards Pip packets)
- DNS
- Pip/IP Translator
- Pip Header Server (formats Pip headers)
The first three systems already exist in the IP architecture, so they don't need explaining here 🙌 The fourth one, the Pip/IP Translator, is required solely for inter-operating with current IP systems. All Pip routers are also Pip/IP translators.
The fifth system, the Pip Header Server, is brand new ✨ Its job is to format Pip headers on behalf of the source host (though at first, hosts will be able to do this themselves). This use of the Pip Header Server will increase as policy routing gets more sophisticated, moving beyond what the near-term Pip Architecture can do 💜
To handle future evolution, a Pip Header Server can "spoon-feed" Pip headers to old hosts that haven't been updated to understand new uses of Pip. That way, the probability that the internet can evolve without changing all hosts goes up 🌈
2. A Simple Example ✨
okay so a typical Pip "exchange" goes like this 💖 an application starts talking to another host, and that host is identified by a domain name. The application sends a request for one or more Pip Headers to the Pip Header Server, and that request contains the domain name of the destination host 🦋. The Pip Header Server then generates a DNS request and gets back a Pip ID, multiple Pip Addresses, and possibly other info like a mobile host server or a PDN address 🌸. Now it has all of that, plus info about the source host (its Pip Addresses, for instance), plus optionally policy info, plus optionally topology info. ✨ It formats an ordered list of valid Pip headers and hands them to the host.
ngl this next bit is so relatable 🥹 if the Pip Header Server lives on the same box as the host (which will be super common at first 🧚), the host acts kinda like a regular IP host. A DNS request comes from the host, and the host forms a Pip header based on the answer it gets back from DNS.
The source host then starts sending Pip packets to the destination host 🚀. If the destination is an IP host, the Pip packet gets translated into an IP packet along the way. But if the destination is a Pip host (the slay scenario 👑), it uses the destination Pip ID alone to figure out whether the packet is meant for it. The destination host then generates a return Pip header, either based on info in the Pip header it received, or by using the Pip ID of the source host to query the Pip Header Server/DNS itself. The second option has more overhead, but it lets the destination make a more informed decision about how to send packets back to the originating host 💅.
If either host is mobile and moves somewhere new, getting a new Pip Address, it tells the other host its new address directly 📱. Since hosts are identified by Pip ID and not by Pip Address, this doesn't make the transport level fail (no cap, that's the whole point 🙌). But if both hosts are mobile and get new Pip Addresses at the same time, so they can't exchange packets at all 💀, they can query each other's mobile host servers, which they learned about from DNS.
Keeping track of host mobility is completely confined to hosts.
Routers never get involved in tracking mobile hosts. Never. 🙅 (They are still involved in host discovery and automatic host address assignment, though 🫶.)
3. Pip Overview 🎀
here's a quick overview of the Pip protocol 🌈. The reader is encouraged to read [2] for a complete description, so go read that too, bestie 📚.
The Pip header is split into three parts 🧩:
Initial Part
Transit Part
Options PartThe Initial Part has these fields:
Version Number
Options Offset, OP Contents, Options Present (OP)
Packet SubID
Protocol
Dest ID
Source ID
Payload Length
Host Version
Payload Offset
Hop CountAll of the fields in the Initial Part are fixed length. The Initial Part is 8 32-bit words long 💜.
Version Number places Pip as a subsequent version of IP. The Options Offset, OP Contents, and Options Present (OP) fields tell how to process the options. The Options Offset tells where the options are. The OP tells which of up to 8 options are in the Options Part, so the Pip system can efficiently ignore options that don't pertain to it. OP Contents is like a version number for the OP field, and it allows for different sets of the (up to 8) options.
Packet SubID is used to relate a received PCMP message to a previously sent Pip packet. This matters because routers in Pip can tag packets, so the packet returned to a host in a PCMP message may not be the same as the packet that was sent 🕵️. Payload Length and Protocol take the place of IP's Total Length and Protocol fields, respectively. Dest ID identifies the destination host and isn't used for routing, except where the final router on a LAN uses ARP to find the physical address of the host identified by the Dest ID. Source ID identifies the source of the packet. Host Version tells what control algorithms the host has implemented, so routers can respond to hosts appropriately. It's an evolution mechanism 🦋. Hop Count is similar to IP's Time-to-Live.
The Transit Part has these fields:
Transit Part Offset
HD Contents
Handling Directive (HD)
Active FTIF
RC Contents
Routing Context (RC)
FTIF Chain (FTIF = Forwarding Table Index Field)Except for the FTIF Chain, which can have a variable number of 16-bit FTIF fields, the fields in the Transit Part are fixed length and are three 32-bit words long 🧱.
Transit Part Offset gives the length of the Transit Part. This is used to figure out where the subsequent Transit Part is located (when Transit Part encapsulation is happening) 🎁.
The Handling Directive (HD) is a set of subfields, and each one indicates a specific handling action that must be executed on the packet. Handling directives have no influence on routing. HD Contents indicates which subfields are in the Handling Directive, which lets the definition of that set evolve over time 🌱. Example handling directives are queueing priority, congestion experienced bit, drop priority, and so on.
The remaining fields make up the Routing Directive, and this is where the routing decision gets made 🗺️. The basic algorithm is that the router uses the Routing Context to choose one of multiple forwarding tables. The Active FTIF says which FTIFs to retrieve, and that's used as an index into the forwarding table. That lookup either tells the router to look at the next FTIF, or returns the forwarding information.
Examples of Routing Context uses are distinguishing address families (multicast vs. unicast), indicating which level of the hierarchy a packet is being routed at, and indicating a Type of Service. In the near-term architecture, the FTIF Chain carries source and destination hierarchical unicast addresses, policy route fragments, multicast addresses (all-of-group), and anycast (one-of-group) addresses. Like OP Contents and HD Contents, RC Contents indicates which subfields are in the Routing Context. This allows the definition of the Routing Context to evolve over time 🌷.
The Options Part contains the options. They're preceded by an array of 8 fields that gives the offset of each of up to 8 options, so a particular option can be found without a serial search through the list of options 🔍.
4. Pip Addressing 💌
Addressing is the core of any internet architecture (main character energy, no cap 👑). Pip Addresses are carried in the Routing Directive (RD) of the Pip header, except for the Pip ID, which in certain circumstances functions as part of the Pip Address. Pip Addresses are used only for routing packets. They don't identify the source and destination of a Pip packet, though. The Pip ID does that 🪪. Here we describe and justify the Pip Addressing types.
There are four Pip Address types [11] 🔢. The hierarchical Pip Address (referred to simply as the Pip Address) is used for scalable unicast, and for the unicast part of a CBT-style multicast and anycast. The multicast part of a CBT-style multicast is the second Pip Address type. The third type is class-D style multicast. The fourth type is the so-called "anycast" address, which causes the packet to be forwarded to one of a class of destinations (such as the nearest DNS server) 🎯.
Bits 0 and 1 of the RC, defined by an RC Contents value of 1 (that is, for the near-term Pip architecture), indicate which of four address families the FTIFs and Dest ID apply to. The values are:
Value Address Family
----- --------------
00 Hierarchical Unicast Pip Address
01 Class D Style Multicast Address
10 CBT Style Multicast Address
11 Anycast Pip AddressThe remaining bits are defined differently for different address families, and those are defined in the following sections 🌈.
4.1. Hierarchical Pip Addressing
okay so the whole point of a hierarchical address is to scale routing info way better 📈✨, and Pip also sneakily uses the "path" info hiding inside these addresses to make provider selection (policy routing) decisions 💅 main character routing energy fr
The Pip Header encodes addresses as a series of separate numbers, one number for each level of hierarchy 🧁. Traditional packet encodings are more "one field, whole address, good luck" 🙈 because they cram the entire address into one field. Because of Pip's encoding, you don't need a format for a Pip Address the way you do with traditional addresses. (For instance, the SIP address is formatted so the first so-many bits are the country/metro code, the next so-many bits are the site/subscriber, and so on 🌍.) Pip's encoding also totally eliminates the "cornering in" effect, which is running out of space in one part of the hierarchy even though there's plenty of room in another 😩. No "field sizing" decisions need to be made at all with Pip Addresses 🎀. This makes address assignment easier and more flexible than with traditional addresses 💖.
Pip Addresses are carried in DNS as a series of numbers, usually with each number representing a layer of the hierarchy [1]. But optionally, the initial number(s) can represent a "route fragment" (the tail end of a policy route, which is a source route whose elements are providers) 🦋. Route fragments would be used, for instance, when the destination network's directly attached (local access) provider is only giving access to other (long distance) providers, but the important provider-selection policy decision is about the long distance providers 🌈.
The RC for (hierarchical) Pip Addresses is defined as:
bits meaning
---- -------
0,1 Pip Address (= 00)
2,3 level
4,5 metalevel
6 exit routing typeThe level and metalevel subfields are used to indicate what level of the hierarchy the packet is currently at (see section 8) 🔍. The exit routing type subfield is used to indicate whether host-driven (hosts decide exit provider) or router-driven (routers decide exit provider) exit routing is in effect (see section 8.1) 🚦.
Each FTIF in the FTIF Chain is 16 bits in length 🧩. The low-order part of each FTIF in a (hierarchical unicast) Pip Address indicates the relationship of that FTIF with the next FTIF. There are three relators: Vertical, Horizontal, and Extension 🎭. The Vertical and Horizontal relators indicate if the subsequent FTIF is hierarchically above or below (Vertical) or hierarchically unrelated (Horizontal). The Extension relator is used to encode FTIF values longer than 16 bits 📏.
FTIF values 0 - 31 are reserved for special purposes 🚫. That means they cannot be assigned to normal hierarchical elements. FTIF value 1 is defined as a flag to indicate a switch from the unicast phase of packet forwarding to the anycast phase of packet forwarding 🚩.
Note that Pip Addresses do not need to be seen by protocol layers above Pip (though layers above Pip can provide a Pip Address if they want to 💁♀️). Transport and above use the Pip ID to identify the source and destination of a Pip packet 🎯. The Pip layer is able to map the Pip IDs (and other information received from the layer above, such as QOS) into Pip Addresses 🪄.
The Pip ID can serve as the lowest level of a Pip Address. While this "bends the principal" of separating Pip Addressing from Pip Identification, it greatly simplifies dynamic host address assignment 🙌. The Pip ID also serves as a multicast ID 📡. Unless otherwise stated, the term "Pip Address" refers to just the part in the Routing Directive (that is, it excludes the Pip ID) 🫶.
Pip Addresses are provider-rooted (as opposed to geographical) 🏢. That is, the top level of a Pip Address indicates a network service provider, even when the service provided is not Pip 👑. (A justification of using provider-rooted rather than geographical addresses is given in [12] 📚.)
So the basic form of a Pip address is:
providerPart,subscriberPartwhere both the providerPart and the subscriberPart can have multiple layers of hierarchy inside them 🪆.
A subscriber may be attached to multiple providers 🌐. In this case, a host can end up with multiple Pip Addresses because it has multiple providerParts:
providerPart1,subscriberPart
providerPart2,subscriberPart
providerPart3,subscriberPartThis applies to the case where the subscriber network spans many different provider areas, like a global corporate network 🏬. In this case, some hosts in the global corporate network will have certain providerParts, and other hosts will have others 🤹. The subscriberPart should be assigned so that routing can successfully take place without a providerPart in the destination Pip Address of the Pip Routing Directive (see section 8.2) 🗺️.
Note that, while there are three providerParts shown, there is only one subscriberPart 👀. Internal subscriber numbering should be independent of the providerPart. Honestly, with the Pip architecture, it's possible to address internal packets without including any of the providerPart of the address 🤯.
Top-level Pip numbers can be assigned to subscriber networks as well as to providers 💼:
privatePart,subscriberPartIn this case, though, the top-level number (privatePart) would not be advertised globally 🤫. The purpose of this kind of assignment is to give a private network "ownership" of a globally unique Pip Address space 🔐. Note that the privatePart is assigned as an extended FTIF (that is, from numbers greater than 2^15) 🔢. Because the privatePart is not advertised globally, and because internal packets do not need the prefix above the subscriberPart, the privatePart actually never appears in a Pip packet header 🫥.
Pip Addresses can be prepended with a route fragment. That is, one or more Pip numbers that are all at the top of the hierarchy 🪜:
longDistanceProvider.localAccessProvider.subscriber
(top-level) (top-level) (next level)This is useful, for instance, when the subscriber's directly attached provider is a "local access" provider and is not advertised globally 🛰️. In this case, the "long distance" provider is prepended to the address, even though the local access provider number is enough to provide global uniqueness 🌍✨.
Note that no coordination is required between the long distance and local access providers to form this address 🤝. The subscriber, with a prefix assigned to it by the local access provider, can autonomously form and use this address 🦸♀️. It is only necessary that the long distance provider know how to route to the local access provider 🧭.
4.1.1. Assignment of (Hierarchical) Pip Addresses
Administratively, Pip Addresses are assigned as follows [3] 📋. There is a root Pip Address assignment authority. Likely choices for this are IANA or ISOC 🏛️. The root authority assigns top-level Pip Address numbers. (A "Pip Address number" is the number at a single level of the Pip Address hierarchy. A Pip Address prefix is a series of contiguous Pip Address numbers, starting at the top level but not including the entire Pip Address. So the top-level prefix is the same thing as the top-level number 🤓.)
Though by and large, and most importantly, top-level assignments are made to providers, each country is given an assignment, each existing address space (such as E.164, X.121, IP, etc.) is given an assignment, and private networks can be given assignments too 🌏. So existing addresses can be grandfathered in 🎀. Even if the top-level Pip address number is an administrative rather than topological assignment, the routing algorithm still advertises providers at the top (provider) level of routing. That is, routing will advertise enough levels of hierarchy that providers know how to route to each other 🗣️.
There must be some means of validating top-level number requests from providers (basically, those numbers less than 2^15) 🛂. That is, top-level assignments must be made only to true providers. While designing the best way to do this is outside the scope of this document, it seems off hand that a reasonable approach is to charge for the top-level prefixes 💸. The charge should be enough to discourage non-serious requests for prefixes, but not so much that it becomes an inhibitor to entry in the market 🚪. The charge might include a yearly "rent", and top-level prefixes could be reclaimed when they are no longer used by the provider 🏠. Any profit made from this activity could be used to support the overall role of number assignment 💰. Since roughly 32,000 top-level assignments can be made before having to increase the FTIF size in the Pip header from 16 bits to 32 bits, it is envisioned that top-level prefixes will not be viewed as a scarce resource 🌟.
After a provider obtains a top-level prefix, it becomes an assignment authority with respect to that particular prefix 👸. The provider has complete control over assignments at the next level down (the level below the top-level). The provider may either assign top-level minus one prefixes to subscribers, or, preferably, use that level to provide hierarchy within the provider's network (for instance, in the case where the provider has so many subscribers that keeping routing information on all of them creates a scaling problem) 🧱. It is envisioned that the subscriber will have complete control over number assignments made at levels below that of the prefix assigned to it by the provider 🫧.
Assigning top-level prefixes directly to providers leaves the number of top-level assignments open-ended, which results in the possibility of scaling problems at the top level 😬. While it is expected that the number of providers will remain relatively small (say, less than 10000 globally), this can't be guaranteed 🎲. If there are more providers than top-level routing can handle, it is likely that many of these providers will be "local access" providers, meaning providers whose role is to give a subscriber access to multiple "long-distance" providers 🚇. In this case, the local access providers need not appear at the top level of routing, which mitigates the scaling problem at that level 🧘♀️.
In the worst case, if there are too many top-level "long-distance" providers for top-level routing to handle, a layer of hierarchy above the top level can be created 🆙. This layer should probably conform to some policy criteria (as opposed to geographical criteria). For instance, backbones with similar access restrictions or type-of-service can be hierarchically clustered 🧃. Clustering according to policy criteria rather than geographical criteria allows the choice of address to remain an effective policy routing mechanism 🎯. Of course, adding a layer of hierarchy to the top requires that all systems, over time, obtain a new providerPart prefix 🔄. Since Pip has automatic prefix assignment, and since DNS hides addresses from users, this is not a debilitating problem 💅✨.
4.1.2 Host Addressing ✨
okay so hosts can have multiple Pip Addresses 🦋 and that's literally the point. Pip Addresses are topologically significant, so a host has several of them because it exists in several places topologically. like, it can be reached through multiple providers, or it has multiple physical interfaces. and the address you use to reach the host totally influences the path you take to get there 🗺️
locally, Pip Addressing is giving IP Addressing vibes 💅. Pip prefixes get assigned to subnetworks, and "subnetwork" here is meant in the OSI sense. so it's a network running at a lower layer than Pip, like a LAN 🏠. because of that, you don't have to advertise individual hosts in routing updates. routers only need to advertise and store routes to subnetworks. iconic efficiency 😤
unlike IP though 🙈, a single subnetwork can have multiple prefixes. (technically IP can do this too, but a host might not realize it can reach another host on the same subnetwork using a different prefix without going through a router. that's a whole vibe check ngl.)
there are two styles of local Pip Addressing. in one, the Pip Address denotes the host. in the other, the Pip Address denotes only the destination subnetwork. that second style is called ID-tailed Pip Addressing 🎀. with ID-tailed addresses, the Pip ID is what the last router uses to forward the packet to the host. it's expected that ID-tailed addressing will be the most common, because it greatly eases address administration. major bestie energy 🫶
aside: the Pip Routing Directive (the RD) can also route a Pip packet inside a host. like, it can point a packet at a device in the host or even a certain memory location. using the RD this way is NOT part of this near-term Pip architecture, but it could be done locally without affecting any other Pip systems 🤫
when a router gets a Pip packet and figures out it's for a host on one of its attached subnetworks (by examining the appropriate FTIF), it looks at the destination Pip ID, which sits in a fixed position, and forwards based on that. if it doesn't know the subnetwork address of the host, it ARPs, using the Pip ID as the "address" in the ARP query 🧠
4.2 CBT Style Multicast Addresses 🌸
when bits 1 and 0 of the RC (as defined by RC Contents = 1) are set to 10, the FTIF and Dest ID indicate CBT (Core Based Tree) style multicast. the rest of the bits work like this:
bits meaning
---- -------
0,1 CBT Multicast (= 10)
2,3 level
4,5 metalevel
6 exit routing type
7 on-tree bit
8,9 scopingokay so with CBT (Core-based Tree) multicast, there's a single multicast tree connecting the members (recipients) of the group 🌳. this is different from Class-D style multicast, where there's a tree per source. the tree comes out of one "core" router. to send to the group, a packet gets routed to the core using unicast routing. once it reaches a router on the tree, it gets multicast using a group ID 💫
so the FTIF Chain for CBT multicast holds the (Unicast) Hierarchical Pip Address of the core router, and the Dest ID field holds the group ID 🎯
a Pip CBT packet has two phases of forwarding: a unicast phase and a multicast phase 🔥. the on-tree bit in the RC tells you which phase the packet is in. while it's in the unicast phase, on-tree is set to 0 and the packet gets forwarded similarly to Pip Addresses. the scoping bits get ignored during this phase 🙅♀️
once the packet reaches the multicast tree, it switches to multicast routing. it does this by changing on-tree to 1 and using the Dest ID group address for forwarding. during this phase, bits 2-6 get ignored 🦋
4.3 Class D Style Multicast Addresses 💜
when bits 1 and 0 of the RC (as defined by RC Contents = 1) are set to 01, the FTIF and Dest ID indicate Class D style multicast. the rest of the RC is defined like this:
bits meaning
---- -------
0,1 Class D Style Multicast (= 01)
2-5 Scopingby "class D" style multicast, we mean multicast using the algorithms developed for Class D addresses in IP (class D addresses aren't used per se, just the algorithms). this style uses both source and destination info to route the packet: the source host address and the destination multicast group 👀
for Pip, the FTIF Chain holds the source Pip Address, with the most significant hierarchy level first. why the source Pip Address and not the Source ID? because using the source Pip Address lets multicast routing take advantage of the hierarchical source address, same as IP does 🧩. the Dest ID field holds the multicast group, and the RC indicates Class-D style multicast. all routers must first look at the FTIF Chain and Dest ID field to route the packet on the tree 🌲
bits 2 through 5 of the RC are the scoping bits 🎀
4.4 Anycast Addressing 🧚
when bits 1 and 0 of the RC (as defined by RC Contents = 1) are set to 11, the FTIF and Dest ID indicate anycast addressing. the rest of the RC is defined like this:
bits meaning
---- -------
0,1 Anycast Address (= 11)
2,3 level
4,5 metalevel
6 exit routing type
7 anycast active
8,9 scopingwith anycast routing, the packet is unicast, but it goes to the nearest one of a group of destinations 📍. Pip uses this type of routing for autoconfiguration. other stuff, like discovery protocols, may also use anycast routing 🔍
like CBT, Pip anycast has two phases: a unicast phase and an anycast phase 💖. the unicast phase gets the packet into a certain vicinity. the anycast phase forwards the packet to the nearest of a group of destinations in that vicinity.
so the RC has both unicast and anycast info in it ✨. during the unicast phase, the anycast active bit is set to 0, and the packet is forwarded according to the rules of Pip Addressing. the scoping bits are ignored here.
the switch from unicast to anycast gets triggered by the presence of an FTIF of value 1 in the FTIF Chain. when that FTIF is reached, the anycast active bit is set to 1, the scoping bits take effect, and bits 2 through 6 get ignored. in the anycast phase, forwarding is based on the Dest ID field 🌈
5. Pip IDs 🆔
the Pip ID is 64-bits in length [4] 💅
the basic role of the Pip ID is to identify the source and destination host of a Pip Packet. (the other role of the Pip ID is helping a router find the destination host on the destination subnetwork 🗺️)
that said, it's possible for the Pip ID to end up identifying something in addition to the host. for instance, it could identify a user or a process 👑. for this to work, though, the Pip ID has to be bound to the host, so that as far as the Pip layer is concerned, the ID belongs to the host. any additional use of the Pip ID is outside the scope of this Pip architecture 🙅♀️
the Pip ID is treated as flat. when a host receives a Pip packet, it compares the destination Pip ID in the Pip header with its own. if there's a complete match, the packet has reached the right destination and gets sent up to the higher layer protocol ✅. if there's not a complete match, the packet is discarded and a PCMP Invalid Address packet gets sent back to the originator of the packet [7] 😭
open issue alert 🚨: it's kinda unsettled whether Pip IDs should contain significant organizational hierarchy info. that info could be used for inverse DNS lookups and for associating a Pip packet with an organization. (ngl, using the Pip ID alone for this is super easy to spoof. cross-checking it with the Pip Address prefix makes spoofing harder, as hard as it is with IP, but still easy. Section 14.2 discusses methods for making spoofing harder still, without requiring encryption 🔐)
relying on organizational info in the Pip header generally complicates ID assignment 🫠. it makes host autoconfiguration harder, because hosts then have to get an assignment from some database somewhere, instead of creating one locally from an IEEE 802 address, for instance. it also means a host has to get a new assignment if it changes organizations. it's not clear what this would mean for a mobile host moving through different organizations 🚗
because of all this, the use of flat Pip IDs is currently favored 💜
blocks of Pip ID numbers have been reserved for existing numbering spaces, like IP, IEEE 802, and E.164 📚. Pip ID numbers have also been assigned for special purposes, like "any host", "any router", "all hosts on a subnetwork", "all routers on a subnetwork", and so on 🌸. finally, 32-bit blocks of Pip ID numbers have been reserved for each country, according to ISO 3166 country code assignments 🌍
6. Use of DNS 🌈
the Pip near-term architecture uses DNS in roughly the same style it's currently used in 🧁. specifically, the Pip architecture keeps the two fundamental DNS characteristics: 1) information stored in DNS doesn't change often, and 2) the information returned by DNS is independent of who requested it 💖
while the fundamental use of DNS stays roughly the same, Pip's use of DNS differs from IP's use by degrees. first, Pip relies on DNS to hold more types of information than IP does [1] 🤓. second, Pip Addresses in DNS are expected to change more often than IP addresses, because Pip Address prefixes (the providerPart) get reassigned 🔄. to still allow aggressive caching of DNS records even with addressing changing more quickly, Pip has a mechanism for telling hosts when an address is no longer assigned 🚨. this triggers an authoritative query, which overrides DNS caches. the mechanism consists of PCMP Packet Not Delivered messages that explicitly indicate the Pip Address is invalid 💀
so what's next: we first talk about the info contained in DNS, and then we talk about authoritative queries 🫶
6.1. Information Held by DNS 💖
okay bestie, let's talk about what DNS is actually holding for Pip 🧚 there are six things in there:
- The Pip ID.
- Multiple Pip Addresses
- The destination's mobile host address servers.
- The Public Data Network (PDN) addresses through which the destination can be reached.
- The Pip/IP Translators through which the destination (if the destination is IP-only) can be reached.
- Information about the providers represented by the destination's Pip addresses. This information includes provider name, the type of provider network (such as SMDS, ATM, or SIP), and access restrictions on the provider's network.
the Pip ID and Addresses are the core basics 🎀 they're the basic units of information required for carriage of a Pip packet, so no cap, you need them to send anything at all 💅
the mobile host address server is the one that tells you where to send queries for the current address of a mobile Pip host 🦋 lowkey though, the mobile host usually tells you its current address itself, so a mobile host server query is not usually required 🙈
the PDN address is how the entry router of a PDN learns the PDN address of the next hop router 🌈 the entry router grabs it from an option in the Pip packet. if there are multiple PDNs tied to a given Pip Address, there can be multiple PDN addresses carried in that option. also, the option isn't sent on every packet, and only the PDN entry router needs to look at it 👑
the Pip/IP translator info is what tells you how to turn an IP address into a Pip Address, so the packet can get carried across the Pip infrastructure 🫶 if the originating host is IP, then the first IP/Pip translator the IP packet reaches must query DNS for this info. it's giving teamwork ✨
the info about the destination's providers helps the "source" (either the source host or a Pip Header Server near the source host) build a good Pip header when it picks a Pip Address [14] 💜 choosing one of multiple Pip Addresses is basically a policy routing choice, which is very main character energy 😭
more detailed descriptions of how the DNS info gets used are in the relevant sections, so keep scrolling 🍓
6.2. Authoritative Queries in DNS 🌸
okay so Pip treats addresses as way more dynamic than IP does 🦋 one example is how Pip Address prefixes change when a subscriber network attaches to a new provider. Pip also stores more stuff in DNS, and any of it can change for different reasons. so the info in DNS is more dynamic with Pip than with IP, periodt 💅
now, because Pip leans on DNS harder, there's a danger of increasing the load on DNS 😬 this would be extra true if you made DNS more dynamic by shortening the cache holding time through a lower DNS Time-to-Live (TTL). to counteract that, Pip gives explicit network layer (Pip layer) feedback on whether the address info is correct 🛡️ this lets Pip hosts selectively override cached DNS info by making an authoritative query. the whole point is that we actually hope to increase the cache holding time of DNS, which improves DNS' scaling characteristics overall 🧠✨
the network layer feedback comes as a type of PCMP Packet Not Delivered (PDN) message that says the address used is known to be out-of-date 🙅♀️ routers can be configured with this info, or it can come through the routing algorithm. when an address is decommissioned, the routing algorithm can say that's why it became unreachable, as opposed to being "temporarily" unreachable because of equipment failure 🔧
Pip hosts think about destination addresses as being in one of four states 🎀
- Unknown, but assumed to be valid.
- Reachable (and therefore valid).
- Unreachable and known to be invalid.
- Unreachable, but weakly assumed to be valid.
the first state exists before a host has tried talking to another host 🌷 in this state, the host queries DNS as normal (so no authoritative query, bestie).
the second state happens once a host has successfully communicated with another host ✅ once you're in this state, you can stay in it for an arbitrarily long time, even after the DNS TTL has expired. while you're here, there's no need to query DNS 💖
a host enters the third state after a failed attempt at communicating with another host, where the PCMP PND message explicitly says the address is known to be invalid 💀 in this case, the host makes an authoritative query to DNS whether or not the TTL has expired. this is the bit that lets DNS info be cached for ages while addresses can still get reassigned often. iconic design honestly 👑
a host enters the fourth state after a failed attempt at communicating with another host, but where the address isn't explicitly known to be invalid 🌧️ here the host weakly assumes the destination's address is still valid, so it can requery DNS with a normal (non-authoritative) query 🫶
7. Type-of-Service (TOS) (or lack thereof) 💅
okay, one year ago it probably would've been fine to define a handful (4 or 5) of priority levels to drive a simple priority FIFO queue 🕰️ but with real-time services showing up on the Internet, that's no longer enough 😭 real-time traffic can't be handled on the same footing as non-real-time traffic. specifically, real-time traffic must be subject to access control, so that excess real-time traffic doesn't swamp a link and hurt other real-time and non-real-time traffic alike 🚫
since there's no consensus solution for managing real-time and non-real-time traffic on the internet yet, this version of the Pip near-term architecture doesn't specify any classes of service (or related queueing mechanisms) 🌈 it's expected that Pip will define classes of service (mainly for use in the Handling Directive) once solutions become available. stay tuned, bestie ✨
8. Routing on (Hierarchical) Pip Addresses 🦋
okay so Pip forwarding in a single router is done based on one or a small number of FTIFs 🧚 what that means for hierarchical Pip Addresses is that a Pip router can forward a packet by examining only part of the Pip Address, often just a single level 🎯
encoding each level of the Pip Address separately is a big deal for a few reasons. it makes handling addresses easier, like address assignment or managing multiple addresses 💜 it also makes lookups faster, because the entire address doesn't have to be examined to forward a packet (which is what traditional hierarchical address encoding requires). the cost is extra complexity in keeping track of the active hierarchical level in the Pip header 😅
since Pip Addresses let numbers get reused at each level of the hierarchy, a Pip router needs to know which level it's acting at when it retrieves an FTIF 🌸 part of how this works is a hierarchy level indicator in the Routing Context (RC) field. RC level is numbered from the top of the hierarchy down, so the top is RC level = 0, the next level down is RC level = 1, and so on 🔢
the RC level alone isn't enough to track the right level in every case 🙈 different parts of the hierarchy can have different numbers of levels, and elements of the hierarchy (like a domain or an area) can exist in multiple parts of the hierarchy. so one hierarchy element can be, say, level 3 under one parent and level 2 under another 🌀
to sort out this ambiguity, the topological hierarchy gets superimposed with another set of levels, called metalevels [11] 🌈 a metalevel boundary exists wherever a hierarchy element has multiple parents with different numbers of levels, or might reasonably have multiple parents with different numbers of levels in the future.
so a metalevel boundary exists between a subscriber network and its provider 🫶 (heads up: in general, the metalevel represents a significant administrative boundary between two levels of the topological hierarchy. it's because of that administrative boundary that the child is likely to have multiple parents.) lower metalevels may exist, but usually they won't 💖
so the RC contains a level and a metalevel indicator 🎀 the level says how many levels are from the top of the next higher metalevel. the top of the global hierarchy is metalevel 0, level 0. the next level down (like the one that provides a level of hierarchy within a provider) is metalevel 0, level 1. the first level of hierarchy under a provider is metalevel 1, level 0, and so on 👑
to figure out the RC level and RC metalevel in a transmitted Pip packet, a host (or Pip Header Server) must know where the metalevels are in its own Pip Addresses 🧠
the host compares its source Pip Address with the destination Pip Address 👀 the highest Pip Address component that's different between the two addresses decides the level and metalevel. (no levels higher than this one need to be encoded in the Routing Directive 💅)
neighbor routers are configured to know whether there's a level or metalevel boundary between them, so they can modify the RC level and RC metalevel in a transmitted packet appropriately 🦋
8.1. Exiting a Private Domain 🚪
okay so the near-term Pip Architecture gives you two methods of exit routing 💫 that's routing inter-domain Pip packets from a source host to a network service provider of a private domain [12,15]. in the first method, called transit-driven exit routing, the source host leaves the choice of provider to the routers 🧭 in the second method, called host-driven exit routing, the source host explicitly picks the provider 🎯 either way, it's possible to stop internal routers from having to carry external routing info. the exit routing bit of the RC tells you which type is in effect 🔖
with host-driven exit routing, the host can pick a provider the destination can't be reached through 😬 when that happens, the host gets the appropriate PCMP Packet Not Delivered message, and it may either fall back on transit-driven exit routing or choose a different provider 🌷
when using transit-driven exit routing, there are two modes 🌈 the first, called destination-oriented, is used when the routers inside a domain have external routing info and the host only has one provider prefix. the second, called provider-oriented, is used when the routers inside a domain don't have any external routing info, or when the host has multiple provider prefixes 💜 (with IP, this case is called default routing. with IP though, default routing doesn't allow an intelligent choice of multiple exit points 🙄)
with provider-oriented exit routing, the host arbitrarily picks a source Pip Address (and therefore, a provider) 🎲 (note that if the Pip Header Server is tracking inter-domain routing, then it chooses the appropriate provider ✨). if the host picks the wrong provider, the border router will redirect the host to the correct provider with a PCMP Provider Redirect message 🫶
8.2. Intra-domain Networking ✨
Okay bestie, with intra-domain networking (where both source and destination are in the private network) there are two scenarios we need to think about 🧚. In the first, the destination address shares a providerPart with the source address, so the destination is known to be intra-domain before a packet is even sent 💅. In the second, the destination address does not share a providerPart with the source address, so the source host doesn't know the destination is reachable intra-domain 🙈. Ngl the first case is the most common, because the private top-level number assignment acts as the common prefix even though it isn't advertised globally (see section 4.1) 💜.
In the first case, the Pip Addresses in the Routing Directive need not contain the providerPart. Instead, it only contains the address part below the metalevel boundary 🦋. (A Pip Address in an FTIF Chain always starts at a metalevel boundary.)
For example, if the source Pip Address is 1.2.3,4.5.6 and the destination Pip Address is 1.2.3,4.7.8, then only 4.7.8 needs to be included for the destination address in the Routing Directive. (The comma "," in the address indicates the metalevel boundary between providerPart and subscriberPart.) The metalevel and level are set accordingly 🌸.
In the second case, it's desirable to use the Pip Header Server to determine whether the destination is intra-domain or inter-domain. The Pip Header Server can do this by monitoring intra-domain routing. (This is done by having the Pip Header Server run the intra-domain routing algorithm, but not advertise any destinations.) So the Pip Header Server can figure out whether the providerPart can be eliminated from the address, like we just covered, or whether it can't and has to follow the rules of exit routing from the previous section 🔥.
If the Pip Header Server does not monitor intra-domain routing, however, then the following happens. With host-driven exit routing, the packet gets routed to the stated provider, and an external path is used to reach an internal destination 😭. (The moral here is to not use host-driven exit routing unless the Pip Header Server is privy to routing information, both internal and external. 💀)
With transit-driven exit routing, the packet sent by the host will eventually reach a router that knows the destination is intra-domain. That router forwards the packet toward the destination, and at the same time sends a PCMP Reformat Transit Part message to the host. This message tells the host how much of the Pip Address is needed to route the packet 🌈.
9. Pip Header Server 🦋
Okay so two new components of the Pip Architecture are the Pip/IP Translator and the Pip Header Server 💅. The Pip/IP Translator is only used for the transition from IP to Pip, and otherwise wouldn't be necessary. The Pip Header Server, though, is a brand new architectural component 🌸.
The purpose of the Pip Header Server is to form a Pip Header. It's useful to form the Pip header in a separate box because 1) in the future (as policy routing matures, for instance), a ton of information may be needed to form the Pip header, too much to distribute to all hosts, and 2) it won't be possible to evolve all hosts at the same time, so a separate box that can spoon-feed Pip headers to old hosts is necessary 🍓. (It is impossible to guarantee that no modification of Pip hosts is necessary for any potential evolution, but being able to form the header in a server and hand it to an outdated host is a large step in the right direction 🫶.)
(Note that policy routing architectures commonly if not universally require the use of some kind of "route server" for calculating policy routes. The Pip Header Server is, among other things, just this server. Thus, the Pip Header Server does not so much result from the fact that Pip itself is more complex than IP or other "IPv7" proposals. Rather, the Pip Header Server reflects the fact that the Pip Architecture has more functionality than the ROAD architectures supported by the simpler proposals. 👑)
We note that for the near-term architecture, hosts themselves will by-and-large have the capability of forming Pip headers. The exception to this will be the case where the Pip Header Server wishes to monitor inter-domain routing to enhance provider selection. Thus, the Pip Header Server role will be largely limited to evolution (see section 16) ✨.
9.1. Forming Pip Headers
Forming a Pip header is more complex than forming an IP header, because there are way more choices to make 🎀. At a minimum, one of multiple Pip Addresses (both source and destination) must be chosen [14]. In the near future, it will also be necessary to choose a TOS 💜.
After DNS information about the destination has been received, the following information is available to the Pip header formation function 🦋:
- From DNS: The destination's providers (either directly connected or nearby enough to justify making a policy decision about), and the names, types, and access restrictions of those providers.
- From the source host: The application type (and thus, the desired service), and the user access restriction classes.
- From local configuration: The source's providers, and the names, types, and access restrictions of those providers.
- Optionally from inter-domain routing: The routes chosen by inter-domain to all top level providers. (Note that inter-domain routing in the Pip near-term architecture is path-vector. Because of this, the Pip Header Server does not obtain enough information from inter-domain routing to form a policy route. When the technology to do this matures, it can be installed into Pip Header Servers.)
The inter-domain routing information is optional. If it is used, then probably a Pip Header Server is necessary, to limit this information to a small number of systems.
There may also be arbitrary policy information available to the Pip header formation function. This architecture does not specify any such information 🙃.
The Pip header formation function then goes through a process of forming an ordered list of source/destination Pip Addresses to use. The ordering is based on knowledge of the application service requirements, the service provided by the source providers, guesses or learned information about the service provided by the destination providers or by source/destination provider pairs, and the cost of using source providers to reach destination providers. It is assumed that the sophistication of forming the ordered list will grow as experience is gained with internet commercialization and real-time services 📈.
The Pip Header formation function then returns the ordered pairs of source and destination addresses to the source host in the PHP response message, along with an indication of what kind of exit routing to use with each pair. Any additional information, such as PDN Address, is also returned. With this information, the source host can now establish communications and properly respond to PCMP messages. Based on information received from PCMP messages, particularly PCMP Packet Not Delivered messages but also Mobile Host messages, the host is able to choose appropriately from the ordered list 🌟.
Note that if Pip evolves to the point where the Transit Part of the Pip header is no longer compatible with the current Transit Part, and the querying host has not been updated to understand the new Transit Part, then the PHP response message contains a bit map of the Transit Part. The host puts this bit map into the Transit Part of the transmitted Pip header even though it does not understand the semantics of the Transit Part. The Host Version field indicates to the Pip Header Server what kinds of transit parts the host can understand 🧚.
9.2. Pip Header Protocol (PHP)
The Pip Header Protocol (PHP) is a simple query/response protocol used to exchange information between the Pip host and the Pip Header Server [6]. In the query, the Pip host includes (among other things) the domain name of the destination it wishes to send Pip packets to. (So the PHP query basically stands in for the DNS query 💖.)
The PHP query also contains 1) User Access Restriction Classes, 2) Application Types, and 3) host version. The host version tells the Pip Header Server what features are installed in the host. Thus, the Pip Header Server is able to determine if the host can format its own Pip header based on DNS information, or whether the Pip Header Server needs to do it on behalf of the host. In the future, the PHP query will also contain desired TOS (possibly in lieu of Application Type). (Note that this information could come from the application. Thus, the application interface to PHP (the equivalent of gethostbyname()) must pass this information.) 🫶
9.3. Application Interface
In order for a Pip host to generate the information required in the PHP query, there must be a way for the application to convey the information to the PHP software. The host architecture for doing this is as follows 🎀.
A local "Pip Header Client" (the source host analog to the Pip Header Server) is called by the application (instead of the current gethostbyname()). The application provides the Pip Header Client with either the destination host domain name or the destination host Pip ID, plus other pertinent information such as user access restriction class and TOS. If the Pip Header Client doesn't have the information cached locally, it queries the Pip Header Server and receives an answer. (Remember that the Pip Header Server can be co-resident with the host 💜.)
Once the Pip Header Client has determined what the Pip header(s) are, it assigns a local handle to the headers, returns the handle to the application, and configures the Pip packet processing engine with the handle and related Pip Headers. The application then issues packets to the Pip layer (via intervening layers such as transport) using the local handle 🦋.
10. Routing Algorithms in Pip ✨
okay so this section is all about the routing algorithm for (hierarchical) Pip Addresses 🗺️💖
The architecture for running routing algorithms in Pip mirrors the clean split of routing contexts in the Pip header 🧩 so routing is nicely modularized, and honestly it's giving organized energy.
Inside a Hierarchical Pip Address there are multiple hierarchical levels. Wherever two routers connect, or two levels interface (either inside one router or between routers), two decisions have to be made: 1) what information gets exchanged (meaning what part of one side's routing table gets passed along to the other side), and 2) what routing algorithm gets used to exchange that information? The first decision is covered in section 10.1 below (Routing Information Filtering). The second one is what we're talking about here 🦋
Conceptually, and pretty much in practice too, the routing algorithms at each level are cleanly partitioned. It's kind of like the split between "egp" and "igp" level routing in IP, except in Pip it happens at every level of the hierarchy ✨
At the top level of the Pip Address hierarchy, a path-vector routing algorithm is used. Path-vector is a better fit up top than link-state because path-vector doesn't need the top-level entities (providers) to agree on metrics in order to stay loop-free. (Agreement between the providers would probably lead to better paths, but the Pip Architecture doesn't assume that agreement exists 🤷♀️)
The top-level path-vector algorithm is based on IDRP, but it's been upgraded to handle Pip addresses and Pip quirks like the Routing Context 💅 Below the top level, it's a local decision which routing algorithm technology to run. The path-vector algorithm is generalized so it can run at multiple levels of the Pip Address hierarchy too. So a lower-level domain can pick the path-vector algorithm, or run something else, like a link-state algorithm. The modified version of IDRP is called MLPV [10], for Multi-Level Path-Vector (pronounced "milpiv") 🎀
Normally, information gets exchanged between two separate routing algorithms because they both live in the same router. For instance, a border router is likely to swap routing info with provider routers, and still run the routing algorithm of the internal routers. If the two algorithms use different routing technologies (like link-state versus distance-vector), then internal conversion translates the information from one algorithm's form into the other's 🔁
In some cases, though, two routing algorithms that exchange information live in different routers and have to swap info over a link. If those two algorithms are different technologies, they need a common way to exchange routing info. Strictly speaking this is a local matter, but MLPV can also act as the interface between two disparate routing algorithms. So all routers should be able to run MLPV, if for no other reason than to exchange information with other, maybe proprietary, routing protocols 🌸
MLPV is built to be extendible when it comes to the types of routes it calculates. It uses the Pip Object parameter identification number space to identify what type of route is being advertised and calculated [9]. So if you want to add new route types (like new types of service), you only need to configure the routers to accept the new route type, define metrics for that type, and set criteria for preferring one route of that type over another. Iconic, right? 👑
10.1. Routing Information Filtering
Okay, the whole point of hierarchical routing is that information from one part of the hierarchy can get reduced when it's passed to another part. Usually reduction (in the form of aggregation) happens when information moves from the bottom of the hierarchy up. Pip is different though: it uses tunneling and exit routing so that, if you want, information from the top can be reduced on its way down 🧚
When two routers become neighbors, they can figure out which hierarchical levels they share by comparing their Pip Addresses. For example, if two neighbor routers have Pip Addresses 1.2.3,4 and 1.2.8,9.14 respectively, then they share levels 0 and 1, and they differ at the levels below that. (0 is the highest level, 1 is the next highest, and so on.) As a general rule, these two routers exchange level 0, level 1, and level 2 routing information, but not level 3 or lower. In other words, both routers know how to route to everything at the top level (level 0), how to route to all level 1 things with "1" as the level 0 prefix, and how to route to all level 2 things with "1.2" as the level 1 prefix 💖
Without any other instructions, two routers will by default exchange information about all levels, from the top down to the first level where their Pip Addresses differ. In practice, though, that default exchange is about as likely to be followed as not 🙈 For example, say 1.2.3,4 is a provider router and 1.2.8,9.14 is a subscriber router. (Note that 1.2.8 is the prefix the provider gave the subscriber, which is why the metalevel boundary shows up as the comma.) Also say the subscriber network is using destination-oriented transit-driven exit routing (see section 8.1). And finally, say router 1.2.8,9.14 is the subscriber's only entry point into provider 1 (other routers provide entry points to other providers).
In this setup, 1.2.8,9.14 doesn't need to know about level 2 or level 1 areas in the provider (so it doesn't need 1.2.4..., 1.2.5..., or 1.3..., 1.4..., and so on). That means 1.2.8,9.14 should be configured to tell 1.2.3,4 that it doesn't need level 1 or 2 information 🎀
Here's another one: same provider 1.2.3,4, same subscriber 1.2.8,9.14, but now the subscriber network is using host-driven exit routing. In this case the subscriber doesn't even need level 0 information, because all exit routing is pointed at the provider of choice, and level 0 info doesn't change that choice 🫶
11. Transition
The transition scheme for Pip has two major parts: 1) translation, and 2) encapsulation. Translation is required to map the Pip Address into the IP address and back again. Encapsulation is how one Pip router (or host) exchanges packets with another Pip router (or host) by tunneling through intermediate IP routers 🦋
Basically, the Pip transition scheme is a set of techniques that lets existing IP "stuff" and Pip coexist, but only within the limits of IP address depletion (not the limits of IP scaling problems, though 👀). What I mean is that an IP-only host can only exchange packets with other hosts in a domain where IP numbers are unique. At first that domain includes all IP hosts, but eventually it'll only include hosts inside a private domain. The IP "stuff" that can stick around includes 1) whole IP domains, 2) individual IP hosts, 3) IP-oriented TCPs, and 4) IP-oriented applications 💅
11.1. Justification for Pip Transition Scheme
Real talk: any transition to a bigger address requires translation. It can't be avoided 😭 When deciding on a translation scheme, the major choices come down to these:
- Will we require a contiguous infrastructure made of the new protocol, or will we allow tunneling through whatever remains of the existing IP infrastructure at any point in time?
- Will we allow global connectivity between IP machines after IP addresses are no longer globally unique, or not? (In other words, will we use a NAT scheme or not? [15])
About question number 1: it's desirable to move to a contiguous Pip (or SIP or whatever) infrastructure as fast as possible, especially for better scaling. But it's fantasy to think the whole infrastructure will cut over to Pip quickly 🙃 Also, during the testing stages of Pip, it's highly desirable to be able to install Pip in any box anywhere and, by tunneling through IP, create a virtual Pip internet 🧪 So the only reasonable answer to question number 1 is to allow tunneling ✨
About question number 2: it's highly desirable to avoid using a NAT scheme. A NAT (Network Address Translation) scheme is one where any two IP hosts can communicate even though their IP addresses aren't globally unique. It works by dynamically mapping non-unique IP addresses into unique ones so they can cross the infrastructure. NAT schemes come with problems: they add complexity to maintain the mappings, and they have to translate IP addresses that live inside application data structures (like the PORT command in FTP) 😩
That said, it's conceivable the new protocol won't be far enough along when IP addresses stop being unique, and so a NAT scheme becomes necessary. It's possible to use a NAT scheme at any point in the future without making it part of the intended transition scheme now. So we can plan for a NATless transition now without preventing the potential use of NAT if it becomes necessary 🌈
11.2. Architecture for Pip Transition Scheme
okay so the architecture for Pip transition is basically a Pip infrastructure surrounded by IP-only "systems" 🧚 those can be whole IP domains, individual IP hosts, an old TCP sitting inside an otherwise Pip host, or an old application running on top of a Pip-smart TCP. the old stuff is giving main character energy 💅
the Pip infrastructure starts out getting its internal connectivity by tunneling through IP 🦋 so any Pip box can be installed literally anywhere and become part of the infrastructure just by being configured over a "virtual" IP. it's desirable that Pip boxes be directly connected to other Pip boxes, but super early on that's the exception, not the rule 🙈
two neighbor Pip systems tunneling through IP just treat IP as a "link layer" protocol 🫶 so they encapsulate Pip over IP the same way they'd encapsulate Pip over any other link layer protocol. the hop-count field of Pip is not copied into the Time-to-Live field of IP, so don't expect that to happen 🙅♀️ there's no automatic configuration of neighbor Pip systems over IP either. manual configuration (and careful "virtual topology" engineering) is required, sorry bestie 😭
also, ICMP messages from an IP router inside a tunnel don't get translated into a PCMP message and sent on. they get sinked at the translating router at the head of the tunnel. the info learned from those ICMP messages can still be used to figure out that the far end of the tunnel is unreachable, and that may then result in a PCMP message on later packets 👀
in the rest of this section, we don't distinguish between a virtual Pip infrastructure on IP and a pure Pip infrastructure ✨
given the model of a Pip infrastructure surrounded by IP, there are 5 possible packet paths 🌈
IP - IPIP - Pip - IPIP - PipPip - IPPip - Pip
okay the first three paths all start with packets from IP-only hosts. so for an IP host to talk to any other host (IP or not), the other host must be addressable within the context of the IP host's 32-bit IP address 🎀 right now this "IP-unique" domain includes all IP hosts. once IP addresses stop being unique, the IP-unique domain will only include a subset of all hosts. at a minimum, that subset has to include the hosts in the IP host's private domain. but it also makes sense to put all the "public" hosts in there too, basically anonymous ftp servers and mail gateways 🍓 in other words, a portion of the IP address space should be set aside to stay globally unique, even though other parts of the address space are being reused. big brain move, honestly 🧠✨
11.3. Translation between Pip and IP packets
okay paths 2 and 4 both involve translating from Pip to IP, and this part is lowkey straightforward 💖 all the info needed to make the IP addresses is already in the Pip header. Pip IDs have an encoding that lets them contain an IP address (again, one that's unique within an IP-unique domain). so whenever a packet path involves an IP host on either end, both hosts must have IP addresses. translating from Pip to IP is basically just pulling the IP addresses out of the Pip IDs and forming an IP header 🦋
going the other way, from an IP header to a Pip header, is way harder 😩 the 32-bit IP address has to be "translated" into a 64-bit Pip ID and a Pip Address, and there's no algorithm for doing that. a table mapping IP addresses (or, rather, network numbers) to Pip IDs and Pip Addresses is required. since that table could potentially need to map every IP address, we chose dynamic discovery and caching to maintain it 🧚 and we also chose DNS as the way to discover the mappings. no notes 💅
so DNS contains records that map an IP address to a Pip ID and Pip Address. if the host behind the DNS record is a Pip host (packet path 3), then the Pip ID and Pip Address are the host's own. if the host behind the DNS record is an IP-only host (packet paths 2 and 4), then the Pip Address is the one belonging to the Pip/IP translating gateway that gets you to that IP host 🌸 so an IP-only domain must at least be able to return Pip information in its DNS records, or the parent DNS domain has to be able to do it on the child's behalf. it's giving teamwork 🫶
for paths 2 and 3 (IP-Pip-IP and IP-Pip), the initial translating gateway (IP to Pip) is the one that makes the DNS query. it holds onto the IP packet while it waits for the answer. the query is an inverse address (in-addr) using the destination IP address. the translating gateway can cache the record for an arbitrarily long period, because if the mapping ever goes bad, a PCMP Invalid Address message flushes that cache entry 💜
path 4 (Pip-IP) is different though 👀 the Pip Address of the translating gateway gets handed straight back to the source host, piggybacked onto the DNS record that's normally returned anyway. so this scheme only adds a small incremental cost on top of the normal DNS query. slay, efficiency 😌✨
11.4. Translating between PCMP and ICMP
ngl this one's short and sweet 🍬 the only ICMP/PCMP messages that get translated are the Destination Unreachable, Echo, and PTMU Exceeded messages. the portion of the offending IP/Pip header that's attached to the ICMP/PCMP message does not get translated 🙈
11.5. Translating between IP and Pip Routing Information
okay so it is not necessary to pass IP routing information into the Pip infrastructure 🧚 the mapping of IP address to Pip Address in DNS lets Pip find the right gateway to IP using only Pip addresses. no extra routing drama needed 💅
BUT it is impossible to pass Pip routing information into IP routers, since IP routers cannot understand Pip addresses 😭 which means IP domains must use default routing to reach IP/Pip translators. they just kinda send everything to the door and let the translator handle it 🚪🦋
11.6. Old TCP and Application Binaries in Pip Hosts
real talk, a Pip host can be expected to have an old TCP sitting above it for a long time to come 💀 and a new (Pip-smart) TCP can be expected to have old application binaries running over it for a long time too. so we have to have some way of ensuring that the TCP checksum is correctly calculated whenever one or both ends are running Pip and one or both ends have an old TCP binary 🎀 on top of that, we need to let applications talk to TCP using only a 32-bit "address", even though those 32 bits get locally translated into Pip Addresses and IDs. complicated, but we're literally handling it 🌈
as said above, whenever a Pip host is talking to an IP-only host, the Pip host has a 32-bit IP address. that address is embedded in the Pip ID so you can tell it's an IP address just by looking at the Pip ID itself 🔍
the TCP pseudo-header is calculated using the Payload Length and Protocol fields, plus some or all of the Source and Dest Pip IDs. when both the Source and Dest Pip IDs are IP-based, only the 32-bit IP address gets included in the pseudo-header checksum calculation. otherwise the full 64 bits are used 💖 (fun fact: using the full Payload Length and Protocol fields doesn't break when old TCP binaries are in use, because those values have to fit inside the 16-bit and 8-bit limits for TCP to work correctly anyway 🙌)
why only 32 bits of the Pip ID when both ends use an IP address? because an old TCP only uses 32 bits of some number to form the pseudo-header. if all 64 bits of the Pip ID were used, there would be cases where no 32-bit number could make sure the correct checksum gets calculated in every case. so yeah, it's a whole puzzle 🧩
now, when an old TCP sits on top of Pip, "Pip" (actually, a Pip daemon) has to create a 32-bit number that can do two jobs: 1) let the Pip layer correctly match a packet from the TCP layer with the right Pip header, and 2) make the TCP layer calculate the right checksum 🦋 (this number gets created when the application starts a DNS query. a Pip daemon steps in on that request, works out a 32-bit number the application/TCP can use, and tells the Pip layer about the mapping between that 32-bit number and the full Pip header.)
when the destination host is an IP-only host, this 32-bit number is nothing more than the IP address itself 🫶 when the destination host is a Pip host, the 32-bit number is something Pip generates to "fool" the old TCP into calculating the right checksum 🤭 this number can normally be the same as the lower 32 bits of the Pip ID. BUT, if two or more active TCP connections go to different hosts whose Pip IDs share the same lower 32 bits, then things get spicy 🌶️ in that case the Pip layer has to generate a different 32-bit number for each connection, in such a way that the sum of the two 16-bit components of those 32-bit numbers matches the sum of the two 16-bit components of the lower 32 bits of the Pip IDs. math bestie, do your thing 🧮💅
last one 😭 if an old application wants to open a socket using an IP address that was handed to it (by the user or hard-coded), instead of a domain name, then we have to assume that this IP address is valid within the IP-unique domain. to form a Pip ID out of that 32-bit number, the host appends the high-order 24 bits of its own Pip ID, plus the IP-address-identifier-byte value, to the 32-bit IP address 🌟
11.7 Translating between Pip Capable and non-Pip Capable DNS Servers ✨
okay so, besides transitioning the "Pip-layer" packets, we also have to move DNS from non-Pip capable to Pip capable 🌸 During the transition, some name servers in DNS will only understand IP queries, and others will understand both Pip and IP queries. That means there must be a way for Pip resolvers to figure out whether a name server is Pip capable, and vice versa 💅 Also, if a name server provides recursive service, it must be able to turn Pip requests into IP requests. (Pip-capable means a name server understands Pip and the existing IP queries. It does not necessarily mean the name server uses the Pip protocol to talk to others 🙈)
New resource records were defined to hold Pip identifiers and addresses, plus other info [1] 🎀 These resource records must be queried with a new opcode in the DNS query packet header. Existing resource records can be queried with either the old or the new header format. Name servers that aren't Pip-capable will reply with a format error to queries using the new opcode 💀 So a resolver can work out on its own whether a name server is Pip-capable by sending it a Pip query and checking the response 🦋 It only needs to do this once, the first time it queries a server, and the result can be cached along with that name server's address ✨
Using a new opcode for Pip queries also helps name servers figure out whether a resolver is Pip-capable 🧚 (Honestly, you can't always tell from the type of query, since a lot of queries are shared between IP and Pip.) This matters when a server responds with address info that wasn't explicitly asked for. A big example is a referral to another name server: if the request came from a Pip resolver, the name server addresses come back as Pip identifier/address resource records. Otherwise, they come back as IP A resource records 👑
Pip-capable servers that provide recursive service must translate Pip requests into IP requests when they query an IP name server 🔥 For most queries, this just means changing the opcode value in the query header to say it's an IP query instead of a Pip one. (Most queries look exactly the same in IP and Pip, so this is pretty easy 💖) Other queries, especially the query for Pip identifier/address info, must be translated into their IP counterpart, which is an IP A query 🫶 When an answer comes back from an IP name server, a Pip name server must translate the query header and question section back to the original, then format the answer properly. Again, for most queries this is a trivial operation, but any response containing IP addresses, whether from an explicit query or as additional info, must be formatted so it looks like a valid Pip response 🌈
Pip-capable name servers that provide recursive name service should also translate IP address requests into Pip identifier/address requests when they query a Pip-capable name server 🍓 (A host's IP address can be deduced from its Pip identifier, so this works 🦋) This lets a Pip-capable name server cache all the relevant addressing info about a Pip host from the very first address query about that host ✨
Caching only partial info is a big no-no 🙅♀️ The name server uses the current DNS caching strategy, so on a future Pip request it would only return the cached info. Then IP, not Pip, would be used to talk to the destination host 😭
12. Pip Address and ID Auto-configuration 🎀
One goal of Pip is to make networks as easy to administer as possible, especially when it comes to hosts 💜 Some parts of the Pip architecture make admin way easier. For example, the ID field gives you a network layer "anchor" to hang address changes on 🌸
This section covers three autoconfiguration topics: 1) domain-wide Pip Address prefix assignment, 2) host Pip Address assignment, and 3) host Pip ID assignment 🧚
12.1 Pip Address Prefix Administration
The whole idea behind provider-rooted hierarchical addresses is that assigning and re-assigning a domain-wide address prefix is straightforward 🦋 This section walks through how that works.
Pip Address prefix administration limits the manual prefix configuration to DNS and border routers ✨ That's the least manual config possible, since both border routers and DNS have to be configured with prefix info for other reasons anyway. DNS needs prefix info so it can answer address queries. DNS files are set up so the prefix is administered in only one place, which means you don't have to change every host record to create a new prefix 💅 Border routers need prefix info so they can advertise exit routes internally 👑
Here's the big one: no internal (non-border) routers or hosts ever need to be manually configured with any externally derived addressing info 🙌 That said, all internal routers that are expected to fall under a common provider-prefix must be configured with a "group ID" taken from the Pip ID space. (This group ID isn't a multicast ID per se. It's really just an identifier that lets prefix updates be aimed at a specific set of routers 🎯)
Each border router is configured with the following info:
- The type of exit routing for the domain. This tells the border router whether it needs to advertise external routes internally.
- The address prefix of the providers the border is directly connected to. This prefix info includes any metalevel boundaries above the subscriber/provider metalevel boundary (called simply the subscriber metalevel).
- Other info about the provider (provider name, type, user access restriction classes).
- A list of common-provider-prefix group IDs that should receive the auto-configuration info. (By default, only systems that share a group ID with the border router receive the info.)
This info gets injected into the intra-domain routing algorithm 🌊 It's automatically spread to all the routers in the group ID list. So by default, the info stays nicely contained within the border router's "area" 🫧
When a non-border router gets this info, it does two things: 1) it records the route to the providers in its forwarding table, and 2) it advertises the info to hosts through the router discovery protocol [8] 💖 That way, hosts learn their complete address, and they also learn how to do exit routing and how to pick source addresses 🎀
12.2 Host Autoconfiguration
There are three phases of host autoconfiguration 🌈
- The host locally creates a flat unique Pip ID (probably globally unique, but at least unique on the attached subnet).
- The host learns its Pip Addresses.
- The host optionally gets a hierarchical, organizationally meaningful Pip ID and a domain name from a Pip ID/domain name assignment service. This service updates DNS.
Item three is optional 🫶 If there aren't any Pip ID and domain name assignment services installed, then the host must get its domain name and, if necessary, its Pip ID from static configuration 🙃 Each of the three phases is described below ✨
12.2.1 Host Initial Pip ID Creation
When a host boots, it can form an ID using only local info 🧚 If the host has an IEEE 802 number, either from an IEEE 802 interface or from an internal identifier, then it can create a globally unique Pip ID from the IEEE 802 Pip ID type [4] 🔥 If it doesn't have one, the host can create an ID from the IEEE 802 space using its subnet (link layer) address. That latter ID is only guaranteed to be locally unique 🌸
12.2.2 Host Pip Address Assignment
Unless a host doesn't want to use ID-tailed Pip Addresses (see section 4.1.2), assigning a host's Pip Address is trivial 💅 (The near-term Pip Architecture doesn't specify a way for a host to get a non-ID-tailed Pip Address.) When a host attaches to a subnet, it learns the Pip Addresses of the attached routers through router discovery 🦋
The host just adopts those Pip Addresses as its own 🎀 The Pip Address gets a packet to the host's subnet, and the host's Pip ID is used to route across the subnet ✨ When the routers advertise new addresses (say, because of a new provider), the host adopts those new addresses too 👑
12.2.3 Pip ID and Domain Name Assignment
Once the host has its Pip Addresses and an at-least-locally-unique Pip ID, it can exchange packets with an ID/Domain Name (ID/DN) assignment service 🫶 If the host locally created a globally unique Pip ID (using an IEEE 802 number), and the organization it belongs to doesn't use organizationally structured Pip IDs (which should normally be the case), then it only needs to get a domain name 🌈 The ID/DN assignment service can be reached at a well-known anycast address [4] 💖 So the host can start exchanging packets with the ID/DN assignment service without any extra configuration 🧚
If there's no ID/DN assignment service available, then the host must get its organizational ID or DNS name in a non-automatic way 🙃 If the ID/DN assignment service is down, the host must temporarily make do with just a Pip ID and Address 😭 The host can periodically try to reach the ID/DN assignment service again 🍓
The ID/DN assignment service must coordinate with DNS 🔥 When it creates a new ID or domain name to assign to a new host, it must know which IDs and domain names are available for assignment. It must also update DNS with the new info 💅
The design of this service is left for further study. 🌸
13. Pip Control Message Protocol (PCMP) 🎀
okay so the Pip version of ICMP is PCMP [7] 💖 The near-term Pip architecture defines these PCMP messages:
- Local Redirect
- Packet Not Delivered
- Echo
- Parameter Problem
- Router Discovery
- PMTU Exceeded
- Provider Redirect
- Reformat Transit Part
- Unknown Parameter
- Host Mobility
- Exit PDN Address
The Local Redirect, Echo, and Parameter Problem messages work almost exactly like their ICMP counterparts ✨
Packet Not Delivered is the one doing ICMP's Destination Unreachable job 🙈 but it's way more general. First, it tells you the hierarchy level where something is unreachable, instead of saying "host, subnet, or network unreachable" like IP does. Second, it indicates when an address is known to be invalid, which lets DNS be used more intelligently (see section 6.2) 🧠
Router Discovery works like ICMP's, with one twist: a host derives its Pip Address from it 🌸
PMTU Exceeded works like ICMP's too, except the Pip header size of the offending Packet is also included 📏 This lets the source host transport figure out how much smaller the packet PMTU should be than the advertised subnet PMTU. ngl this part is lowkey clever. If an occasional option, like the PDN Address option, gets attached to one of many packets and makes that packet bigger than the PMTU, then you don't have to change the MTU coming from transport. That packet can just be fragmented by the host's Pip forwarding engine instead 🧩 (Pip specifies fragmentation/reassembly for hosts but not for routers. The fragmentation information is in a Pip Option.)
Provider Redirect, Invalid Address, Reformat Transit Part, Unknown Parameter, Host Mobility, and Exit PDN Address are the NEW ones 🆕 (well, new as in "not in ICMP," not new as in "brand new to the universe" 😭 okay, moving on)
Provider Redirect tells the source host about a preferable exit provider to use when provider-rooted, transit-driven exit routing is in use (see section 8.1) 🚪
Invalid Address tells the source host that none of the IDs of the destination host match the Pip packet. Its whole purpose is to allow for authoritative DNS requests (see section 6.2) 📇
Reformat Transit Part has both near-term and evolution functions, so it's giving multitasking 💅 Near-term, it tells the source whether it has too few or too many layers of address in the Routing Directive (see section 8.2). Long-term, it's able to arbitrarily modify the transit part transmitted by the host, as encoded by a bit string 🔮
Unknown Parameter tells the source host that the router doesn't understand a parameter in the Handling Directive, the Routing Context, or the Transit Options. Its purpose is to assist evolution (see section 16.1) 🌈
Host Mobility is sent by a host to inform another host (for instance, the host's Mobile Address Server) that it has a new address (see section 14) 🦋 Its main use is host mobility, but it can manage any address change, such as one caused by a new prefix assignment.
Exit PDN Address manages the function where the source host tells the PDN entry router about the PDN Address of the exit PDN system (see section 15) 🧚
When a router needs to send a PCMP message, it sends it to the source Pip Address. If the Pip header is in a tunnel, then the PCMP message goes to the router that is the source of the tunnel. Depending on the situation, this can trigger another PCMP message from the tunnel source to the true source. For example, if the tunnel source finds that the tunnel destination can't be reached, it may send a Packet Not Delivered to the source host 🫶
14. Host Mobility 🦋
Depending on how security conscious a host is, and what security mechanisms it has available, mobility can come from Pip "for free" 🎁 If a host is willing to accept a packet just by looking at the source and destination Pip ID, and if it simply records the source Pip Address on any packet it receives as the right return address for that source Pip ID, then mobility comes automatically.
Here's how that goes. When a mobile host gets a new Pip Address, it just puts that address into the next packet it sends. When the other host receives it, it records the new Pip Address and starts sending return packets to that address. The catch is that this kind of operation makes it super easy to spoof the (internet level) identity of a host 😬 Without any other security mechanisms, any host can write any Pip ID into a packet. (Cross-checking a source Pip ID against the source Pip Address at least makes spoofing of this sort as hard as it is with IP. This is discussed below.)
The simple host mobility mechanism above does not work when the source and destination hosts obtain new Pip Addresses at the same time and the old Pip Addresses stop working, because neither one can send its new address information directly to the other 💔 Also, if a host wants to be more secure about authenticating the source Pip ID of a packet, the mechanism above isn't good enough either. So below, we describe the complete host mobility mechanism 🧩
Pip uses the Mobile Host Server and the PCMP Host Mobility message to manage host mobility;
The Mobile Host Server is a non-mobile host (or a router acting as a host) that keeps track of the active address of a mobile host 📍 The Pip ID and Address of the Mobile Host Server are configured into the mobile host, and into DNS. When a host X gets information from DNS about a host Y, the Pip ID and Address of host Y's Mobile Host Server is among that information. (Also included is host Y's "permanent" address, if host Y has one. If host Y is so mobile that it doesn't have a permanent address, then DNS returns no permanent address. Note that DNS is not intended to keep track of a mobile host's active address 🙅♀️)
Given the destination host's (Y) permanent ID and Address, and the Mobile Host Server's permanent IDs and Addresses, the source host (X) proceeds like this. X tries to establish communications with Y using one of the permanent addresses. If that fails (or if at any time X cannot contact Y), X sends a PCMP Mobile Host message to the Mobile Host Server asking for Y's active address 📨 (Note that X can tell it can't contact Y from receiving a PCMP Destination Unreachable or a PCMP Invalid Address message.)
The Mobile Host Server responds to X with Y's active Pip Addresses. (Of course, Y must tell its Mobile Host Server(s) its active Pip Addresses when it knows them. This is also done using the PCMP Mobile Host message. Y also tells any hosts it is actively communicating with, using either a regular Pip packet or a PCMP Mobile Host message. So usually X doesn't need to contact the Mobile Host Server to track Y's active address 🙌)
If the address X already tried is among those returned by Y, then the source host has the option of either 1) continuing to try the same Pip Address, 2) trying another of Y's Pip Addresses, 3) waiting and querying the Mobile Host Server again, or 4) giving up 🤷♀️
If the Mobile Host Server indicates that Y has new active Pip Addresses, then X chooses among them the same way it chooses among multiple permanent Pip Addresses, and then tries to contact Y 📞
14.1. PCMP Mobile Host message 📬
There are two types of PCMP Mobile Host messages: the query and the response. The query consists of the Pip ID of the host whose active Pip Address information is being requested.
The response consists of a Pip ID, a sequence number, a set of Pip Addresses, and a signature field. The set of Pip Addresses includes all currently usable addresses of the host indicated by the Pip ID. So the PCMP Mobile Host message can be used both to announce a newly obtained address and to show that a previous address is no longer active (by that address being absent from the set) ✨
The sequence number shows which information is the most recent. It's needed for the case where an older PCMP Mobile Host response arrives after a newer one 🕰️
The signature field is a value derived from encrypting the sequence number and the set of Pip Addresses. For now, the encryption algorithms used, how to obtain keys, and so on are for further study 🔐
14.2. Spoofing Pip IDs 🕵️♀️
This section talks about host mechanisms for decreasing the probability of Pip ID spoofing. The mechanisms in this version of the near-term Pip architecture are no more secure than DNS itself 😭 It is hoped that mechanisms and the corresponding infrastructure needed for better internetwork layer security can be installed with whatever new IP protocol is chosen 🙏
After a host makes a DNS query, it knows:
- The destination host's Pip ID,
- The destination host's permanent Pip Addresses, and
- The destination host's Mobile Host Server's Pip ID and Addresses.
The DNS query can be a normal one (based on domain name) or an inverse query (based on Pip ID or Pip Address). The latter is more likely to succeed, since the Pip ID may be flat and therefore not suitable for an inverse lookup 🔍 The inverse query is done when the host did not start the packet exchange, and so doesn't know the domain name of the remote (initiating) host.
If the destination host is not mobile, then the source host can check the source Pip Address, compare it with those received from DNS, and reject the packet if it doesn't match. This gives spoof protection equal to that of IP 🛡️
If the destination host is mobile and gets new Pip Addresses, then the source host can check the validity of the new Pip Address by sending a PCMP Mobile Host query to the Mobile Host Server it learned about from DNS. The set of Pip Addresses learned from the Mobile Address Server is then used for later validation 💜
15. Public Data Network (PDN) Address Discovery ✨
okay bestie, so here's the drama 🎭. When Pip (or honestly any internet protocol 💅) runs over a PDN, the PDN entry Pip System has to figure out the PDN Address of the right PDN exit Pip System. In small broadcast LANs, ARP handles this because broadcasting is relatively cheap 🙌. But on a PDN there are SO many attached systems, and broadcast is either not available or not cheap if it is 😭, so ARP is basically a no-go.
For the case where the destination host's domain is attached to a PDN, it's giving elegance 🦋. The domain's exit PDN Address info gets distributed in DNS, and then the source host conveys the exit PDN Address to the PDN entry router inside a Pip option. Iconic, honestly.
The DNS of the destination host's domain holds the PDN Addresses for that domain 🌸. When DNS returns a record for the destination host, the record links zero or more PDN Addresses to each Pip Address. A single PDN can have more than one PDN Address, and a single Pip Address can be tied to more than one PDN. That second case happens when more than one hierarchical component of the Pip Address each represents a separate PDN. Realistically, though, it's expected that in almost all cases there will be only one PDN (or none) associated with any Pip Address 🫶.
Quick aside, because this part is lowkey genius: the returned DNS record ties the PDN Addresses to a single Pip Address, but the PDN Address usually applies to a whole bunch of Pip Addresses, one for every host in the domain 🧚. The DNS files are structured to show this grouping, the same way a single Pip Address prefix in DNS covers many hosts. So you do NOT have to type separate PDN Addresses in for every individual host entry. Way less config work, periodt 🎀.
When the source host sends the first packet to a given destination host, it attaches the PDN Addresses, one per PDN, to the packet in an option 💌. Because of how options are processed in Pip packets, no router other than the entry PDN router needs to look at that option 👀. When the entry router gets the packet, it works out that it's the entry router based on the result of the FTIF Chain lookup.
Next, it pulls the PDN Address out of the option and caches it locally 📦. That cache entry can be retrieved later using either the destination Pip ID or the destination Pip Address as the cache index.
Then the entry router sends the source host a PCMP Exit PDN Address message to say it has cached the info ✨. If there are multiple exit PDN Addresses, the source host can tell the entry PDN router about all of them at this point. The entry PDN router can either pick one of them to set up a connection, or stash them away so it can recover if the existing connection breaks. Very prepared, very slay 💅.
Finally, the entry PDN router delivers the Pip packet to the PDN Address indicated, maybe by setting up a connection first 🚀.
Now, what if a PDN entry router gets a Pip packet and doesn't know the exit PDN Address (and has no other way to figure it out, like shortcut routing)? No panic 😤. It sends a PCMP Exit PDN Address query message to the originating host. This can happen if, say, routing changes and sends packets to a new PDN entry router 🔄. When the source host gets that query, it transmits the PDN Addresses to the entry PDN router. Problem solved, bestie 🫶.
15.1. Notes on Carrying PDN Addresses in NSAPs 🧁
Okay so this subsection is the receipts 🧾. Carrying PDN Addresses in the option or in the PCP Exit PDN Address message solves two big problems that come with doing the same thing using PDN Address-based NSAPs. Let's go 👑.
Problem one: there is no existing agreement, standards or otherwise, that a PDN Address inside an NSAP means the identified host is reachable behind that PDN Address 🙈. So when an entry PDN router gets an NSAP like that, it can't know for sure, without explicit configuration info, whether that PDN Address can actually be used at the lower layer. Fixing this needs a standards body agreement, maybe by setting aside extra AFIs to mean "PDN Address with topological significance" 📜.
Problem two is the more serious one 💀, and it's that a PDN Address in an NSAP doesn't necessarily scale well. The E.164 address is the perfect example of this. E.164 addresses get used in lots of different network technologies, like the telephone network, BISDN, SMDS, Frame Relay, and other ATM setups 🌍. When a router gets a packet with an E.164-based NSAP, the E.164 address sits in the most significant part of the NSAP address, which is where the highest level routing info lives 🗺️. So without a potentially huge amount of routing table info, the router has no idea which network to send the packet to. Unless E.164 addresses are handed out in blocks according to provider network, it just won't scale well 😩.
There's also a related problem: how does an entry PDN router know whether a PDN address is meant for the PDN it's attached to or for some other PDN? With Pip, there's a one-to-one relationship between a Pip Address prefix and a PDN, so it's always known 💖. With NSAPs, that's not clear without those potentially large routing tables we just talked about 🥲.
16. Evolution with Pip 🦋
Let's talk about the glow-up 🌈. The fact that we call this architecture "near-term" basically means we expect it to evolve into other architectures. So it's super important to have a plan for getting there ✨. The Pip near-term architecture includes explicit mechanisms to support that evolution, so it's not just vibes.
The whole key to evolution is being able to evolve any system at any time without wrecking the old functionality 🛠️. Depending on what the new functionality is, it might be immediately useful to any system that installs it, or it might not become useful until a big chunk of systems, or even a majority, have installed it. None-the-less, it's necessary to be able to install it piece-wise 🧩.
The Pip protocol itself supports evolution through the following mechanisms [2]:
- Tunneling. This lets more up-to-date routers tunnel less up-to-date routers, which allows incremental router evolution 🚇. (Of course, because of encapsulation, tunneling is always an evolution option, and tunneling through IP is indeed used in the Pip transition. But Pip's tunneling encoding is efficient because it doesn't duplicate header information 💜.)
The only use for Pip tunneling in the Pip near-term architecture is routing packets through the internal routers of a transit domain when those internal routers have no external routing information 🧭. It's assumed that enhancements to the Pip Architecture that need tunneling will have their own way of indicating when forming a tunnel is necessary.
- Host independence from routing information. Since a host can receive packets without understanding the routing content of the packet, routers can evolve without necessarily requiring hosts to evolve at the same pace 🏃♀️.
To let hosts send Pip packets without understanding the routing information (in the Transit Part), the Pip Header Server is able to "spoon-feed" the host the Pip header 🥄.
If the Pip Header Server determines the host is able to form its own Pip header (which will usually be the case with the near-term Pip architecture), the Pip Header is essentially a null function 🙃. It accepts a query from the host, passes it on to DNS, and returns the DNS information to the host.
If the Pip Header Server determines the host is not able to form its own Pip header, then the Pip Header Server forms one on the host's behalf 🎁. In one mode of operation, the Pip Header Server gives the host the values of some or all Transit Part fields, and the host constructs the Transit Part. This allows for evolution within the framework of the current Transit Part 🏗️. In another mode, the Pip Header Server gives the host the Transit Part as a simple bit field. This allows for evolution outside the framework of the current Transit Part 🚀.
On top of the Pip Header Server being able to spoon-feed the host a Transit Part, routers can also spoon-feed hosts a Transit Part in case the original Transit Part needs to be modified, using the PCMP Reformat Transit Part message 🔁.
- Separation of handling from routing. This allows one aspect to evolve independently of the other 🫧.
- Flexible Handling Directive, Routing Context, and Options definition. This allows new handling, routing, and option types to be added, and defunct ones to be removed, over time (see section 16.1 below) 🗑️✨.
- Fast and general options processing. Options processing in Pip is fast, both because not every router needs to look at every option, and because once a router decides it needs to look at an option, it can find it quickly (no serial search required) ⚡. So the oft-heard argument that a new option can't be used because it'll slow down processing in all routers? Goes away 🙅♀️.
Pip Options can be thought of as an extension of the Handling Directive (HD). The HD gets used when the handling type is common and can be encoded in a small space, and the option gets used otherwise 🧠. It's possible that a future option will influence routing, and then the Option would be an extension of the RD as well. The RD, however, is rich enough that this is unlikely 💅.
- Generalized Routing Directive. Because the Routing Directive is so general, it's more likely we can evolve routing and addressing semantics without having to redefine the Pip header or the forwarding machinery 🧃.
- Host version number. This number tells what Pip functions a host has, such as which PCMP messages it can handle, so routers can respond appropriately to a Pip packet received from a remote host 📱. This supports the capability for routers to evolve ahead of hosts. (All Pip hosts will at least be able to handle all Pip near-term architecture functions 🫶.)
The Host version number is also used by the Pip Header Server to determine the extent to which it needs to format a header on behalf of the host 🔍.
- Generalized Route Types. The IDRP/MLPV routing algorithm is generic with regards to the types of routes it can calculate 🗺️. So adding new route types is just a matter of configuring routers to accept the new route type, defining metrics for it, and defining criteria for selecting one route of the new type over another 🎯.
Note that none of these evolution features of Pip significantly slow down Pip header processing, especially compared to other internet protocols 🏆. Honestly, that's the most iconic thing in this whole section 👑🔥.
16.1 Handling Directive (HD) and Routing Context (RC) Evolution 💅
Okay bestie, the HD and RC are literally central to how a Pip packet gets handled and routed, so how they evolve deserves a proper chat 💖
Both the HD and the RC fields hold multiple parameters. 🧚 For the RC, the router treats the whole field as a single number. It basically ignores the fact that the RC is made of multiple parameters, and that's what makes fast forwarding of Pip packets possible ⚡. These HD and RC parameters can be arranged in any fashion. They can be any length, as long as they fit in the HD and RC fields themselves, and they can start and end on arbitrary bit boundaries 🦋.
Attached to the HD and RC are "Contents" fields, which say what parameters are in each field and where they live 🗺️. The Contents fields are basically version numbers, with one twist: a higher "version" number does not automatically supersede a lower one 🙈. Typical parameters are things like address family, TOS value, queueing priority, and so on 🌈.
The Contents field is a single number, and its value tells you which parameter set you're looking at 🔢. The mapping from a Contents value to a parameter set is configured manually 🛠️.
Here's how new HD or RC parameter sets (or the erasing of old ones) get made 🎀. First, some organization defines the new parameter set. That might involve defining a brand-new parameter, and if it does, the new parameter gets described as a Pip Object. A Pip Object is basically a number space that uniquely identifies a new parameter type, plus a character string that describes it [9] ✨.
So the new parameter set is written up as a list of Pip Objects, along with the bit locations in the HD or RC that each Pip Object occupies 📋. The organization then submits the set for an official Contents field value. (That submission goes to the standards body that has authority over Pip, which is currently the IAB 🏛️.) If the new parameter set gets approved, it's given a Contents value, and that value is published in a well known place, which is an RFC 📜. Iconic, right? 👑
Network administrators are totally free to install or not install the new parameter set on their hosts and routers 🫶. For a new RC parameter set, installing it doesn't necessarily need any new software 🙌. That's because any Pip routing protocol, such as IDRP/MLPV, can find routes according to the new parameter set once the routers are configured appropriately 🧭.
A new HD parameter set is a different story though. New software is necessary, because something has to actually execute the new handling 🔧.
For new HD and RC parameter sets, systems that don't understand the new parameter set can still be configured to run one of several default actions on it 🎛️. These default actions give you some control over how new functions roll out into Pip systems, which is lowkey genius 🧠. The default actions are:
- Ignore the unknown parameter,
- Set unknown parameter to all 0's,
- Set unknown parameter to all 1's,
- Silently discard packet,
- Discard packet with
PCMP Parameter Unknown.
Action 1 is for when it doesn't much matter whether earlier systems on a path acted on the parameter or not 🤷♀️. Actions 2 and 3 are for when systems need to know whether a previous system didn't understand the parameter 🔍. Actions 4 and 5 are for when something bad happens if not every system understands the new parameter 😭.
16.1.1 Options Evolution 🌸
The evolution of Options is very similar to what we just covered for the HD and RC 🥰. Attached to the Options is an Options Present field, which uses a single word to indicate which of up to 8 options are present in the Options Part 💜. There's also a Contents field associated with the Options Present field, and it indicates which subset of all possible options the Options Present field refers to ✨. Contents field values are assigned in the same way as the HD and RC Contents fields 🎀.
The same 5 default actions used for the HD and RC also apply to the Options 💅🔥.
References 📚
- [1] Thomson, F., "Use of DNS with Pip", Work in Progress.
- [2] Francis, P., "Pip Header Processing", Work in Progress.
- [3] Pip Address Assignment Specification, Work in Progress.
- [4] Francis, P., "Pip Identifiers", Work in Progress.
- [5] Pip Assigned Numbers, Work in Progress.
- [6] Pip Header Protocol, Work in Progress.
- [7] Francis, G., "PCMP: Pip Control Message Protocol", Work in Progress.
- [8] Pip Router Discovery Protocol, Work in Progress.
- [9] Pip Objects Specification, Work in Progress.
- [10] Rajagopolan, and P. Francis, "The Multi-Level Path Vector Routing Scheme", Work in Progress.
- [11] Francis, P., "Pip Address Conventions", Work in Progress.
- [12] Francis, P., "On the Assignment of Provider Rooted Addresses", Work in Progress.
- [13] Ballardie, Francis, P., and J. Crowcroft, "Core Based Trees (CBT), An Architecture for Scalable Inter-Domain Multicast Routing", Work in Progress.
- [14] Franics, P., "Pip Host Operation", Work in Progress.
- [15] Egevang, K., and P. Francis, "The IP Network Address Translator (NAT)", RFC 1631, Cray Communications, NTT, May 1994.
Notes on the References 🦋
As of the publication of this RFC, a version of [12], titled "Comparison of Geographic and Provider-rooted Internet Addressing," was submitted to ISOC INET 94 in Prague 🇨🇿. Reference [13] was published at ACM SIGCOMM 93 in San Francisco under the title "An Architecture for Scalable Inter-Domain Multicast Routing" 🌉.
Security Considerations 🔒
Security issues are not discussed in this memo. 😭 Literally none. Go in with your eyes open 👀.
Heads up, bestie: this memo doesn't cover security at all, so don't assume anything about it that isn't written here 🚨.
Author's Address 🎀
Paul Francis
NTT Software Lab
3-9-11 Midori-cho Musashino-shi
Tokyo 180 Japan
Phone: +81-422-59-3843
Fax +81-422-59-3765
EMail: francis@cactus.ntt.jp📦 where this page comes from
- ietf: rfc1621 1994-05
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms