Hierarchical IPv 4 Framework Patrick Frejborg pfrejborggmail com

Hierarchical IPv 4 Framework Patrick Frejborg pfrejborg@gmail. com 18 Dec 2009

Why h. IPv 4 ? n Addressing RFC 4984 It is commonly recognized that today’s Internet routing and addressing system is facing serious scaling problems. The ever increasing user population, as well as multiple other factors including multi-homing, traffic engineering, and policy routing, have been driving the growth of the Default Free Zone (DFZ) routing table size at an increasing and potentially alarming rate. While it has been long recognized that the existing routing architecture may have serious scalability problems, effective solutions have yet to be identified, developed, and deployed.

Influence sources n n n The Locator/Identifier Separation Protocol research work at RRG MPLS solutions, mainly the shim header that made it possible to create new services on top of an IP backbone Anycast Rendezvous Point (RP) with Multicast Source Discovery Protocol (MSDP) PSTN hierarchical numbering scheme Active participants on the RRG mailing-list Multipath enabled transport protocols, SCTP and MTCP

Adding scalability by introducing hierarchy in the address space n Global Locator Block (GLB) ¨ n Area Locator (ALOC) ¨ n An IPv 4 address block that is globally unique. An IPv 4 address assigned to locate an ALOC realm in Internet. The ALOC is assigned by a RIR to a service provider or a multi-homed enterprise. The ALOC is globally unique because it is allocated from the GLB. Endpoint Locator (ELOC) ¨ An IPv 4 address assigned to locate an endpoint in an ALOC realm. The ELOC block is assigned by a RIR to a service provider or to an enterprise. The ELOC block is only unique in a geographical region or globally unique in a business area defined by the RIRs. The final policy of uniqueness shall be defined by the RIRs.

The h. IPv 4 header n n IPv 4 header still valid, new IP option added – idea similar as in MPTCP and RFC 1385 New IP option called locator header

Fundamental elements n ALOC realm ¨ n An area in the Internet with at least one attached Locator Swap Router (LSR), also an ALOC must be assigned to the ALOC realm. The RIB of an ALOC realm holds both local ELOC prefixes and global ALOC prefixes. An ALOC realm exchanges only ALOC prefixes with other ALOC realms. Locator Swap Router (LSR) ¨ A router or node which is capable to process the h. IPv 4 header; once the header is processed the LSR will forward the packet upon the IPv 4 destination address. The LSR must have the ALOC assigned as its locator.

LSR per packet tasks (the swap) n n n verify the received packet that it uses the locator header ID in the IP option field verify IP and transport header checksums replace the source address in the IPv 4 header with the ALOC value of the locator header replace the destination address in the IPv 4 header with the ELOC value of the locator header replace the ALOC value in the locator header with the destination IP address of the IPv 4 header replace the ELOC value in the locator header with the source IP address of the IPv 4 header set the S-field to 1 decrease TTL value with one calculate IP and transport protocol checksums forward the packet upon the destination IP address of the IPv 4 header No FIB nor cache required at the LSR

Life of a h. IPv 4 session

Client -> server www. foo. com? S: 10. 1. 1. 1 D: 10. 2. 2. 2 S: 10. 1. 1. 1 D: 172. 16. 0. 5 A-record: 10. 2. 2. 2 ALOC: 172. 16. 0. 5 A: 172. 16. 0. 3 E: 10. 2. 2. 2 S: 172. 16. 0. 3 D: 10. 2. 2. 2 A: 172. 16. 0. 5 E: 10. 1. 1. 1 S: 10. 1. 1. 1 D: 172. 16. 0. 5 A: 172. 16. 0. 3 E: 10. 2. 2. 2 IPv 4 API IPv 4 header Locator header

Client -> server, return path S: 10. 2. 2. 2 D: 10. 1. 1. 1 S: 10. 2. 2. 2 D: 172. 16. 0. 3 S: 172. 16. 0. 5 D: 10. 1. 1. 1 S: 10. 2. 2. 2 D: 172. 16. 0. 3 A: 172. 16. 0. 3 E: 10. 2. 2. 2 S: 172. 16. 0. 5 D: 10. 1. 1. 1 A: 172. 16. 0. 3 E: 10. 2. 2. 2 IPv 4 API IPv 4 header Locator header S: 10. 2. 2. 2 D: 10. 1. 1. 1 A: 172. 16. 0. 5 E: 10. 1. 1. 1

Multi-homing and impact on DFZ

The new routing architecture 172. 16. 0. 5 /32 172. 16. 0. 1 /32 172. 16. 0. 4 /32 172. 16. 0. 5 /32 10. 1. 1. 0 /24 172. 16. 0. 5 /32 172. 16. 0. 1 /32 172. 16. 0. 4 /32 172. 16. 0. 5 /32 10. 2. 2. 0 /24 Advertizing whole RIB of the ALOC realm, generating 0. 0/0 towards DFZ Advertizing only ALOC prefixes

Multi-homing becomes multi-pathing S: 172. 16. 0. 3 D: 10. 2. 2. 2 S: 10. 1. 1. 1 D: 172. 16. 0. 4 A: 172. 16. 0. 3 E: 10. 2. 2. 2 A: 172. 16. 0. 4 E: 10. 1. 1. 1 S: 10. 1. 1. 1 D: 172. 16. 0. 4 A: 172. 16. 0. 3 E: 10. 2. 2. 2 New subflow Policy-based routing, Valiant load-balancing S: 10. 1. 1. 1 D: 172. 16. 0. 5 A: 172. 16. 0. 3 E: 10. 2. 2. 2 S: 172. 16. 0. 3 D: 10. 2. 2. 2 A: 172. 16. 0. 5 E: 10. 1. 1. 1 S: 10. 1. 1. 1 D: 10. 2. 2. 2 www. foo. com? IPv 4 API IPv 4 header Locator header A-record: 10. 2. 2. 2 ALOC: 172. 16. 0. 5 ALOC: 172. 16. 0. 4

Integrating h. IPv 4 with map-andencapsulate solutions

Fundamental elements n Three types of locator is needed Endpoint Locator, ELOC (regionally unique) ¨ Area Locator, ALOC (globally unique) ¨ Routing Locator, RLOC (globally unique) ¨ n n n DNS need to have two new records, for ALOC and RLOC but an endpoint have only one type of record (ALOC or RLOC) in DNS MPTCP is used to achieve new type of multi-homing at h. IPv 4 enabled sites, i. e. migrating from multi-homing to multi-pathing ITR/ETR should support MPTCP and the h. IPV 4 framework Outcome is that the Internet citizen can choose the upgrade path that is most convenient for him Note! Scenario not yet documented in draft-frejborg-hipv 4!

Legacy client -> h. IPv 4 server S: 10. 1. 1 D: 10. 2. 2. 2 S: 10. 1. 1. 1 D: 172. 16. 0. 5 A: 192. 168. 0. 1 E: 10. 2. 2. 2 S: 192. 168. 0. 1 D: 10. 2. 2. 2 S: 10. 1. 1. 1 D: 10. 2. 2. 2 Reply ALOC 172. 16. 0. 5 ALOC 172. 16. 0. 4 www. foo. com? A-record: 10. 2. 2. 2 A: 172. 16. 0. 5 E: 10. 1. 1. 1 S: 192. 168. 0. 1 D: 10. 2. 2. 2 Mapping Request Where is 10. 2. 2. 2? A: 172. 16. 0. 5 E: 10. 1. 1. 1 S: 10. 1. 1. 1 D: 10. 2. 2. 2 IPv 4 API IPv 4 header Locator header

Legacy client -> h. IPv 4 server, return path S: 10. 2. 2. 2 D: 10. 1. 1. 1 S: 10. 2. 2. 2 D: 192. 168. 0. 1 A: 172. 16. 0. 5 E: 10. 1. 1. 1 S: 10. 1. 1 D: 10. 2. 2. 2 S: 10. 2. 2. 2 D: 192. 168. 0. 1 A: 172. 16. 0. 5 E: 10. 1. 1. 1 S: 10. 1. 1. 1 D: 172. 16. 0. 5 A: 192. 168. 0. 1 E: 10. 2. 2. 2 S: 10. 2. 2. 2 D: 192. 168. 0. 1 S: 10. 2. 2. 2 D: 10. 1. 1. 1 A: 172. 16. 0. 5 E: 10. 1. 1. 1 S: 192. 168. 0. 1 D: 10. 2. 2. 2 S: 10. 1. 1. 1 D: 10. 2. 2. 2 Reply ALOC 172. 16. 0. 5 ALOC 172. 16. 0. 4 www. foo. com? A-record: 10. 2. 2. 2 A: 172. 16. 0. 5 E: 10. 1. 1. 1 S: 192. 168. 0. 1 D: 10. 2. 2. 2 Mapping Request Where is 10. 2. 2. 2? A: 172. 16. 0. 5 E: 10. 1. 1. 1 S: 10. 1. 1. 1 D: 10. 2. 2. 2 IPv 4 API IPv 4 header Locator header S: 10. 2. 2. 2 D: 10. 1. 1. 1

Legacy client -> h. IPv 4 server, adding MPTCP subflow S: 192. 168. 0. 1 D: 10. 2. 2. 2 A: 172. 16. 0. 4 E: 10. 1. 1. 1 S: 10. 1. 1. 1 D: 172. 16. 0. 4 A: 192. 168. 0. 1 E: 10. 2. 2. 2 S: 10. 1. 1 D: 10. 2. 2. 2 S: 10. 1. 1. 1 D: 172. 16. 0. 5 A: 192. 168. 0. 1 E: 10. 2. 2. 2 S: 192. 168. 0. 1 D: 10. 2. 2. 2 S: 10. 1. 1. 1 D: 10. 2. 2. 2 Reply ALOC 172. 16. 0. 5 ALOC 172. 16. 0. 4 www. foo. com? A-record: 10. 2. 2. 2 A: 172. 16. 0. 5 E: 10. 1. 1. 1 S: 192. 168. 0. 1 D: 10. 2. 2. 2 A: 172. 16. 0. 4 E: 10. 1. 1. 1 S: 192. 168. 0. 1 D: 10. 2. 2. 2 Mapping Request Where is 10. 2. 2. 2? A: 172. 16. 0. 5 E: 10. 1. 1. 1 S: 10. 1. 1. 1 D: 10. 2. 2. 2 IPv 4 API IPv 4 header Locator header

h. IPv 4 client -> legacy server S: 10. 2. 2. 2 D: 10. 1. 1. 1 www. foo. com? A-record: 10. 1. 1. 1 RLOC: 192. 168. 0. 2 S: 10. 2. 2. 2 D: 192. 168. 0. 1 A: 172. 16. 0. 5 E: 10. 1. 1. 1 S: 10. 2. 2. 2 D: 10. 1. 1. 1 IPv 4 API IPv 4 header Locator header

h. IPv 4 client -> legacy server, return path S: 10. 1. 1. 1 D: 10. 2. 2. 2 S: 10. 1. 1. 1 D: 172. 16. 0. 5 A: 192. 168. 0. 1 E: 10. 2. 2. 2 S: 10. 2. 2. 2 D: 10. 1. 1. 1 S: 192. 168. 0. 1 D: 10. 2. 2. 2 A: 172. 16. 0. 5 E: 10. 1. 1. 1 A-record: 10. 1. 1. 1 RLOC: 192. 168. 0. 2 S: 10. 2. 2. 2 D: 192. 168. 0. 1 A: 172. 16. 0. 5 E: 10. 1. 1. 1 S: 10. 1. 1. 1 D: 10. 2. 2. 2 www. foo. com? S: 10. 2. 2. 2 D: 192. 168. 0. 1 A: 172. 16. 0. 5 E: 10. 1. 1. 1 S: 10. 2. 2. 2 D: 10. 1. 1. 1 S: 10. 1. 1. 1 D: 10. 2. 2. 2 S: 10. 2. 2. 2 D: 10. 1. 1. 1 IPv 4 API IPv 4 header Locator header

h. IPv 4 client -> legacy server, adding MPTCP subflow S: 10. 2. 2. 2 D: 192. 168. 0. 1 A: 172. 16. 0. 4 E: 10. 1. 1. 1 S: 10. 2. 2. 2 D: 10. 1. 1. 1 www. foo. com? A-record: 10. 1. 1. 1 RLOC: 192. 168. 0. 2 S: 10. 2. 2. 2 D: 192. 168. 0. 1 A: 172. 16. 0. 5 E: 10. 1. 1. 1 S: 10. 2. 2. 2 D: 10. 1. 1. 1 IPv 4 API IPv 4 header Locator header

The new routing architecture 172. 16. 0. 3 /32 172. 16. 0. 4 /32 172. 16. 0. 5 /32 10. 1. 1. 0 /24 192. 168. 0. 0 /21 192. 168. 8. 0 /21 192. 168. 16. 0 /21 172. 16. 0. 3 /32 172. 16. 0. 4 /32 172. 16. 0. 5 /32 10. 2. 2. 0 /24 192. 168. 0. 0 /21 192. 168. 8. 0 /21 192. 168. 16. 0 /21 Advertizing whole RIB of the ALOC realm, generating 0. 0/0 towards DFZ Advertizing only ALOC prefixes

Multicast

Multicast considerations n n n Source address (S) for a group (G) is no longer visible outside the local ALOC realm (only GLB prefixes are seen), therefore Reverse Path Forwarding (RPF) is only valid within the local ALOC realm In order to enable RPF globally for a (S, G), the multicast enabled LSR (m. LSR) must at the source ALOC realm replace the source address with the local ALOC identifier LSR in the source ALOC realm shall act as an Anycast RP with MSDP capabilities The m. LSR will decide which multicast groups are announced to other ALOC realms The receiver will locate the source via MSDP, the shared tree can be established to the m. LSR Source Specific Multicast schema will need an extension, ALOC options shall be added to SSM

Multicast forwarding S: 10. 1. 1. 1 G: 225. 5 S: 10. 1. 1. 1 D: 225. 5 S: 172. 16. 0. 3 D: 225. 5 A: 172. 16. 0. 3 E: 10. 1. 1. 1 IPv 4 API IPv 4 header Locator header A: 172. 16. 0. 3 l E: 10. 1. 1. 1 S: 172. 16. 0. 3 D: 225. 5 A: 172. 16. 0. 3 E: 10. 1. 1. 1

RTCP receiver reports S: 10. 1. 1. 1 D: 225. 5 S: 10. 1. 1. 1 G: 225. 5 S: 10. 2. 2. 2 D: 172. 16. 0. 3 S: 172. 16. 0. 5 D: 10. 1. 1. 1 A: 172. 16. 0. 3 E: 10. 2. 2. 2 IPv 4 API IPv 4 header Locator header S: 172. 16. 0. 5 D: 10. 1. 1. 1 A: 172. 16. 0. 3 E: 10. 2. 2. 2 A: 172. 16. 0. 5 E: 10. 1. 1. 1 S: 10. 2. 2. 2 D: 172. 16. 0. 3 A: 172. 16. 0. 5 E: 10. 1. 1. 1

Mobility

Mobility considerations n Site mobility: a site wishes to changes its attachment point to the Internet without changing its IP address block ¨ n Endpoint mobility: an endpoint moves relatively rapidly between different networks, changing its IP layer network attachment point ¨ n The change of attachment point is possible when PI addresses are allocated to the site. Only ALOC prefix(es) needs to be changed at the endpoints. SCTP or MPTCP is providing “session mobility” on the transport layer Mobile site: mobile vehicles that are crossing RIR boundaries and the vehicle (e. g. aircraft, train, ferry etc) carries a local network. ¨ Depending upon forthcoming RIR policies, NAT might be needed, see following slides

Mobile site: client -> server behind NAT S: 10. 2. 2. 2 D: 192. 168. 1. 1 S: 10. 2. 2. 2 D: 10. 1. 1. 1 S: 10. 2. 2. 2 D: 172. 16. 0. 3 PLR: 111 A: 172. 16. 0. 5 E: 10. 1. 1. 1 S: 10. 2. 2. 2 D: 192. 168. 1. 1 S: 172. 16. 0. 5 D: 10. 1. 1. 1 PLR: 111 A: 172. 16. 0. 3 E: 10. 2. 2. 2 S: 10. 2. 2. 2 D: 172. 16. 0. 3 PLR: 111 A: 172. 16. 0. 5 E: 10. 1. 1. 1 www. foo. com? A-record: 10. 1. 1. 1 ALOC: 172. 16. 0. 3 PLR: 111 A-record: 10. 3. 3. 3 ALOC: 172. 16. 0. 1 PLR: 111 IPv 4 API IPv 4 header Locator header

Mobile site: client -> server behind NAT, return path S: 192. 168. 1. 1 D: 10. 2. 2. 2 S: 10. 2. 2. 2 D: 192. 168. 1. 1 S: 10. 1. 1. 1 D: 172. 16. 0. 5 PLR: 111 A: 172. 16. 0. 3 E: 10. 2. 2. 2 S: 10. 1. 1. 1 D: 172. 16. 0. 5 S: 172. 16. 0. 3 D: 10. 2. 2. 2 PLR: 111 A: 172. 16. 0. 5 E: 10. 1. 1. 1 PLR: 111 A: 172. 16. 0. 3 E: 10. 2. 2. 2 S: 192. 168. 1. 1 D: 10. 2. 2. 2 S: 10. 2. 2. 2 D: 172. 16. 0. 3 S: 10. 2. 2. 2 D: 192. 168. 1. 1 PLR: 111 A: 172. 16. 0. 5 E: 10. 1. 1. 1 S: 10. 1. 1. 1 D: 10. 2. 2. 2 S: 10. 2. 2. 2 D: 10. 1. 1. 1 S: 172. 16. 0. 5 D: 10. 1. 1. 1 PLR: 111 A: 172. 16. 0. 3 E: 10. 2. 2. 2 S: 10. 2. 2. 2 D: 172. 16. 0. 3 PLR: 111 A: 172. 16. 0. 5 E: 10. 1. 1. 1 www. foo. com? A-record: 10. 1. 1. 1 ALOC: 172. 16. 0. 3 PLR: 111 A-record: 10. 3. 3. 3 ALOC: 172. 16. 0. 1 PLR: 111 IPv 4 API IPv 4 header Locator header

Mobile site: client -> server behind NAT, adding subflow S: 10. 3. 3. 3 D: 172. 16. 0. 5 S: 192. 168. 1. 1 D: 10. 2. 2. 2 PLR: 111 A: 172. 16. 0. 1 E: 10. 2. 2. 2 S: 10. 1. 1. 1 D: 10. 2. 2. 2 A: 172. 16. 0. 1 E: 10. 2. 2. 2 PLR: 111 A: 172. 16. 0. 5 E: 10. 3. 3. 3 S: 192. 168. 1. 1 D: 10. 2. 2. 2 S: 10. 1. 1. 1 D: 172. 16. 0. 5 PLR: 111 A: 172. 16. 0. 3 E: 10. 2. 2. 2 S: 172. 16. 0. 3 D: 10. 2. 2. 2 PLR: 111 A: 172. 16. 0. 5 E: 10. 1. 1. 1 www. foo. com? A-record: 10. 1. 1. 1 ALOC: 172. 16. 0. 3 PLR: 111 A-record: 10. 3. 3. 3 ALOC: 172. 16. 0. 1 PLR: 111 IPv 4 API IPv 4 header Locator header

Mobile site: client -> server behind NAT, roaming completed S: 10. 3. 3. 3 D: 172. 16. 0. 5 S: 192. 168. 1. 1 D: 10. 2. 2. 2 PLR: 111 A: 172. 16. 0. 1 E: 10. 2. 2. 2 S: 10. 1. 1. 1 D: 10. 2. 2. 2 A: 172. 16. 0. 1 E: 10. 2. 2. 2 PLR: 111 A: 172. 16. 0. 5 E: 10. 3. 3. 3 S: 192. 168. 1. 1 D: 10. 2. 2. 2 www. foo. com? A-record: 10. 1. 1. 1 ALOC: 172. 16. 0. 3 PLR: 111 A-record: 10. 3. 3. 3 ALOC: 172. 16. 0. 1 PLR: 111 IPv 4 API IPv 4 header Locator header

Mobile site: client behind NAT -> server S: 192. 168. 1. 1 D: 10. 2. 2. 2 S: 10. 1. 1. 1 D: 10. 2. 2. 2 S: 192. 168. 1. 1 D: 172. 16. 0. 5 A: 0. 0 E: 10. 2. 2. 2 A: 172. 16. 0. 3 E: 10. 2. 2. 2 S: 10. 1. 1. 1 D: 172. 16. 0. 5 A: 172. 16. 0. 3 E: 10. 2. 2. 2 www. foo. com? A-record: 10. 2. 2. 2 ALOC: 172. 16. 0. 5 IPv 4 API IPv 4 header Locator header S: 10. 1. 1. 1 D: 172. 16. 0. 5 A: 172. 16. 0. 3 E: 10. 2. 2. 2 A: 172. 16. 0. 5 E: 10. 1. 1. 1

Mobile site: client behind NAT -> server, adding subflow S: 192. 168. 1. 1 D: 10. 2. 2. 2 S: 10. 3. 3. 3 D: 172. 16. 0. 5 A: 172. 16. 0. 1 E: 10. 2. 2. 2 S: 192. 168. 1. 1 D: 172. 16. 0. 5 A: 0. 0 E: 10. 2. 2. 2 A: 172. 16. 0. 3 E: 10. 2. 2. 2 A-record: 10. 2. 2. 2 ALOC: 172. 16. 0. 5 IPv 4 API IPv 4 header Locator header S: 10. 3. 3. 3 D: 10. 2. 2. 2 A: 172. 16. 0. 5 E: 10. 3. 3. 3 S: 10. 1. 1. 1 D: 10. 2. 2. 2 S: 10. 1. 1. 1 D: 172. 16. 0. 5 A: 172. 16. 0. 3 E: 10. 2. 2. 2 S: 10. 1. 1. 1 D: 172. 16. 0. 5 www. foo. com? S: 172. 16. 0. 1 D: 10. 2. 2. 2 A: 172. 16. 0. 3 E: 10. 2. 2. 2 A: 172. 16. 0. 5 E: 10. 1. 1. 1

Mobile site: client behind NAT -> server, roaming completed S: 192. 168. 1. 1 D: 10. 2. 2. 2 S: 10. 3. 3. 3 D: 172. 16. 0. 5 A: 172. 16. 0. 1 E: 10. 2. 2. 2 S: 172. 16. 0. 1 D: 10. 2. 2. 2 A: 172. 16. 0. 5 E: 10. 3. 3. 3 S: 192. 168. 1. 1 D: 172. 16. 0. 5 A: 0. 0 E: 10. 2. 2. 2 www. foo. com? A-record: 10. 2. 2. 2 ALOC: 172. 16. 0. 5 IPv 4 API IPv 4 header Locator header S: 10. 3. 3. 3 D: 10. 2. 2. 2

Traffic Engineering

Traffic Engineering considerations n n Load balancing is influenced by the placement of LSRs within a ALOC realm; LSR provides a “nearest routing” scheme A service provider might have several ALOC assigned; traffic engineering and filtering can be done upon ALOC addresses If needed an ALOC identifier based Traffic Engineering solution might be developed. Establish explicit routing paths upon ALOC prefixes, that is create explicit paths that can be engineered via specific ALOC realms. Valiant Load-Balancing can be added, more studies is required around this technology

Summary

Cost and issues n n n Upgrade of the stack at an endpoint or the endpoint should make use of an ITR/XTR In a multi-homing solution the border routers should be able to apply policy based routing upon the ALOC value in the locator header New policies must be set by the RIRs Short timeframe before the expected depletion of the IPv 4 address space occurs Will enterprises give up their global allocation of the current IPv 4 address block they have gained? Co-ordination with MPTCP is highly desirable

Carrots for everyone n Enterprises ¨ ¨ ¨ n No need to learn a totally new protocol Minimize porting of applications to a new protocol, IPv 4 socket API is extended Achieve site mobility MPTCP and SCTP supports endpoint mobility Remove IPv 4 address constraints Internet Service Providers No need to learn new routing protocols ¨ Remove IPv 4 address constraints ¨ Hierarchical routing architecture, smaller RIB for each ALOC realm ¨ Internal prefix flaps are not seen in other ALOC realms, only GLB state changes are reflected globally – “update churn” is reduced ¨