idnits 2.17.1 draft-herbert-intarea-ams-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 688: '... Hello message MUST be sent by each ...' RFC 2119 keyword, line 735: '.... The connection MUST be terminated an...' RFC 2119 keyword, line 739: '...is an error and the connection MUST be...' RFC 2119 keyword, line 740: '...nd error message SHOULD be logged. Bot...' RFC 2119 keyword, line 744: '...o the connection MUST be terminated an...' (27 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (February 21, 2019) is 1891 days in the past. Is this intentional? Checking references for intended status: Full Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC5246' is mentioned on line 2267, but not defined ** Obsolete undefined reference: RFC 5246 (Obsoleted by RFC 8446) == Unused Reference: 'RFC8200' is defined on line 2285, but no explicit reference was found in the text == Unused Reference: 'RFC2663' is defined on line 2332, but no explicit reference was found in the text ** Downref: Normative reference to an Draft Standard RFC: RFC 4291 -- Obsolete informational reference (is this intentional?): RFC 6830 (Obsoleted by RFC 9300, RFC 9301) -- Obsolete informational reference (is this intentional?): RFC 4941 (Obsoleted by RFC 8981) == Outdated reference: A later version (-09) exists of draft-ietf-intarea-gue-06 == Outdated reference: A later version (-16) exists of draft-ietf-nvo3-geneve-08 == Outdated reference: A later version (-07) exists of draft-herbert-fast-03 Summary: 3 errors (**), 0 flaws (~~), 7 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT T. Herbert 3 Intended Status: Standard Quantonium 4 Expires: August 2019 V. Siwach 5 Independent consultant 7 February 21, 2019 9 Address Mapping System 10 draft-herbert-intarea-ams-01 12 Abstract 14 This document describes the Address Mapping System that is a generic, 15 extensible, and scalable system for mapping network addresses to 16 other network addresses. The Address Mapping System is intended to be 17 used in conjunction with overlay techniques which facilitate 18 transmission of packets across overlay networks. Information returned 19 by the Address Mapping System can include the particular network 20 overlay method to use, as well as instructions related to using the 21 method. The Address Mapping System has a number of potential use 22 cases including identifier-locator protocols, network virtualization, 23 and promotion of privacy. 25 Status of this Memo 27 This Internet-Draft is submitted to IETF in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF), its areas, and its working groups. Note that 32 other groups may also distribute working documents as 33 Internet-Drafts. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 The list of current Internet-Drafts can be accessed at 41 http://www.ietf.org/1id-abstracts.html 43 The list of Internet-Draft Shadow Directories can be accessed at 44 http://www.ietf.org/shadow.html 46 Copyright and License Notice 47 Copyright (c) 2019 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (http://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 63 1.1 Use cases . . . . . . . . . . . . . . . . . . . . . . . . . 5 64 1.2 Requirements . . . . . . . . . . . . . . . . . . . . . . . . 7 65 1.3 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 8 66 2 Architecture . . . . . . . . . . . . . . . . . . . . . . . . . 11 67 2.1 Reference topology . . . . . . . . . . . . . . . . . . . . . 11 68 2.2 Functional components . . . . . . . . . . . . . . . . . . . 11 69 2.3 AMS router (AMS-R) . . . . . . . . . . . . . . . . . . . . . 11 70 2.3.1 Serving mapping information . . . . . . . . . . . . . . 12 71 2.3.2 Overlay forwarding . . . . . . . . . . . . . . . . . . . 12 72 2.3.3 AMS router operation . . . . . . . . . . . . . . . . . . 12 73 2.4 AMS forwarder (AMS-F) . . . . . . . . . . . . . . . . . . . 13 74 2.4.1 Overlay termination . . . . . . . . . . . . . . . . . . 13 75 2.4.2 Overlay forwarding . . . . . . . . . . . . . . . . . . . 13 76 3 Address Mapping Router Protocol (AMRP) . . . . . . . . . . . . 14 77 3.1 Key/value database . . . . . . . . . . . . . . . . . . . . . 14 78 3.2 BGP . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 79 3.3 GTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 80 4 Address Mapping Forwarder Protocol (AMFP) . . . . . . . . . . . 15 81 4.1 Common header format . . . . . . . . . . . . . . . . . . . . 15 82 4.2 Hello messages . . . . . . . . . . . . . . . . . . . . . . . 16 83 4.3 Version negotiation . . . . . . . . . . . . . . . . . . . . 16 84 5 AMFP Version 0 . . . . . . . . . . . . . . . . . . . . . . . . 17 85 5.1 Message types . . . . . . . . . . . . . . . . . . . . . . . 17 86 5.2 Parameters message . . . . . . . . . . . . . . . . . . . . . 17 87 5.2.1 Supported identifier types . . . . . . . . . . . . . . . 19 88 5.2.2 Supported locator types . . . . . . . . . . . . . . . . 19 89 5.2.3 Supported overlay methods . . . . . . . . . . . . . . . 20 90 5.2.4 Default overlay method . . . . . . . . . . . . . . . . . 20 91 5.2.5 Default timeout . . . . . . . . . . . . . . . . . . . . 21 92 5.2.6 Default priority . . . . . . . . . . . . . . . . . . . . 21 93 5.2.7 Default weight . . . . . . . . . . . . . . . . . . . . . 22 94 5.2.8 Default instructions . . . . . . . . . . . . . . . . . . 23 95 5.3 Map Request message . . . . . . . . . . . . . . . . . . . . 23 96 5.4 Map Information message . . . . . . . . . . . . . . . . . . 24 97 5.5 Compressed Map Information message . . . . . . . . . . . . . 27 98 5.6 Locator Unreachable message . . . . . . . . . . . . . . . . 28 99 5.7 Identifier and locator types . . . . . . . . . . . . . . . . 29 100 5.8 Cache Occupancy message . . . . . . . . . . . . . . . . . . 29 101 5.9 Operation . . . . . . . . . . . . . . . . . . . . . . . . . 30 102 5.9.1 Populating an mapping cache . . . . . . . . . . . . . . 31 103 5.9.2 Redirects . . . . . . . . . . . . . . . . . . . . . . . 31 104 5.9.2.1 Proactive push with redirect . . . . . . . . . . . . 31 105 5.9.2.2 Redirect rate limiting . . . . . . . . . . . . . . . 31 106 5.9.3 Map request/reply . . . . . . . . . . . . . . . . . . . 32 107 5.9.4 Push mappings . . . . . . . . . . . . . . . . . . . . . 32 108 5.9.5 Cache maintenance . . . . . . . . . . . . . . . . . . . 32 109 5.9.5.1 Timeouts . . . . . . . . . . . . . . . . . . . . . . 33 110 5.9.5.2 Cache refresh . . . . . . . . . . . . . . . . . . . 33 111 5.9.6 AMS forwarder processing . . . . . . . . . . . . . . . . 33 112 5.9.7 Locator unreachable handling . . . . . . . . . . . . . . 34 113 5.9.8 Control connections . . . . . . . . . . . . . . . . . . 34 114 5.9.9 Protocol errors . . . . . . . . . . . . . . . . . . . . 35 115 6 Stateless mapping optimization using FAST . . . . . . . . . . . 35 116 6.1 Firewall and Service Tickets encoding . . . . . . . . . . . 35 117 6.2 Address mapping encoding . . . . . . . . . . . . . . . . . . 36 118 6.3 Reference topology . . . . . . . . . . . . . . . . . . . . . 36 119 6.4 Operation . . . . . . . . . . . . . . . . . . . . . . . . . 37 120 6.4.1 Ticket requests . . . . . . . . . . . . . . . . . . . . 37 121 6.4.2 Qualified locators . . . . . . . . . . . . . . . . . . . 38 122 6.4.2.1 Fully qualified locators . . . . . . . . . . . . . . 38 123 6.4.2.2 Unqualified locators . . . . . . . . . . . . . . . . 38 124 6.4.3 AMS forwarder processing and FAST . . . . . . . . . . . 38 125 6.4.4 Transit to the peer . . . . . . . . . . . . . . . . . . 38 126 6.4.5 Ingress into the origin network . . . . . . . . . . . . 39 127 6.4.6 Overlay termination . . . . . . . . . . . . . . . . . . 39 128 6.4.7 Fallback . . . . . . . . . . . . . . . . . . . . . . . . 39 129 6.4.8 Mobile events . . . . . . . . . . . . . . . . . . . . . 40 130 6.4.9 Expired tickets . . . . . . . . . . . . . . . . . . . . 40 131 7 Privacy in Internet addresses . . . . . . . . . . . . . . . . . 41 132 7.1 Criteria for privacy in addressing . . . . . . . . . . . . . 41 133 7.2 Achieving strong privacy . . . . . . . . . . . . . . . . . . 42 134 7.3 Scaling network state . . . . . . . . . . . . . . . . . . . 42 135 7.3.1 Hidden aggregation . . . . . . . . . . . . . . . . . . . 42 136 7.3.2 Address format . . . . . . . . . . . . . . . . . . . . . 43 137 7.3.3 Practicality of hidden aggregation methods . . . . . . . 44 138 7.4 Scaling bulk address assignment . . . . . . . . . . . . . . 44 139 8 Address Mapping System in 5G networks . . . . . . . . . . . . . 45 140 8.1 Architecture . . . . . . . . . . . . . . . . . . . . . . . . 45 141 8.2 Protocol layering . . . . . . . . . . . . . . . . . . . . . 46 142 8.3 Control plane between AMS and the network . . . . . . . . . 47 143 8.4 AMS and network slices . . . . . . . . . . . . . . . . . . . 47 144 8.5 AMS in 4G networks . . . . . . . . . . . . . . . . . . . . . 48 145 8.6 Overlay forwarding methods in 5G networks . . . . . . . . . 49 146 9 Security Considerations . . . . . . . . . . . . . . . . . . . . 49 147 10 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 50 148 11 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 50 149 12 References . . . . . . . . . . . . . . . . . . . . . . . . . . 50 150 12.1 Normative References . . . . . . . . . . . . . . . . . . . 50 151 12.2 Informative References . . . . . . . . . . . . . . . . . . 50 152 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 52 154 1 Introduction 156 This document describes the Address Mapping System (AMS). AMS is a 157 system that maps network addresses to other network addresses. The 158 canonical use case is to map "identifiers" to "locators" (applying 159 identifier-locator split terminology). Identifiers are logical 160 addresses that identify a node, and locators are addresses that 161 indicate the current location of a node. Identifiers are mapped to 162 locators at points in the data path to facilitate device mobility or 163 or network virtualization. 165 The address mapping system may be queried on a per packet basis in 166 the data path. For instance, an encapsulating tunnel ingress node for 167 virtualization would perform a lookup on each destination virtual 168 address to discover the address of the physical node to which a 169 packet should be forwarded. It follows that access to the mapping 170 system is expected to be tightly coupled with nodes that query the 171 system to perform packet forwarding. 173 The mapping system contains a database or table of all the address 174 mappings for a mapping domain. The database may be distributed across 175 some number of nodes, sharded for scalability, and caches may be used 176 to optimize communications. The mappings in a mapping system may be 177 very dynamic, for instance end user devices in a mobile network may 178 change location within the network at a high rate (e.g. a mobile 179 device in a fast moving automobile may frequently connect to 180 different cells). Protocols are defined to synchronize mapping 181 information across devices that participate in the address mapping 182 system. 184 1.1 Use cases 186 This section describes some of the use cases of the address mapping 187 system. 189 o Network virtualization 191 Container virtualization and Virtual Machines are popular 192 techniques for malleable and efficient use of compute resources 193 in datacenters. A key function in network virtualization is to 194 map virtual addresses to physical addresses. The physical 195 address represents the location of a virtual node. An overlay 196 technique, such as an encapsulation protocol like VXLAN 197 [RFC7348], GUE [GUE], Geneve [GENEVE], or GTP [GTP], is used to 198 forward a packet to its virtual destination based on the 199 physical address associated with a virtual address. The address 200 mapping system provides the necessary mapping information and 201 allows for mobility in container or VM migration. 203 o Identifier/locator protocols 205 Identifier/locator protocols generalize the addressing model of 206 network virtualization. These include a group of protocols and 207 proposals that are being discussed in IETF which resolve the 208 currently strong correlation in IP addresses between 209 identification of a communication end point and the topological 210 location in the network. Identifier/locator protocols include 211 LISP [RFC6830], ILNP [RFC6740], and ILA [ILA]. These demand 212 mechanisms for rapid lookup and notification of the correlation 213 between identifiers of hosts and where they are located. The 214 address mapping system provides this. 216 o Network function virtualization 218 Network function virtualization [NFV] deployed in distributed 219 data centers, or the cloud, requires addressing of dedicated 220 network function instances that fulfils stringent performance 221 requirements. This is achieved by an efficient mapping of 222 network function (NF) logical name to an instance which the 223 address mapping system facilitates. 225 o Address resolution 227 Address resolution refers to the general concept of resolving a 228 higher layer address into a lower layer address. For instance, 229 in Ethernet, a network (IP) address is resolved to a link layer 230 (MAC) address via IPv4 ARP (Address Resolution Protocol) or IPv6 231 NDP (Neighbor Discovering Protocol). The address mapping system 232 provides an alternative system for address resolution. 234 o Privacy in Internet addressing 236 IP addressing is a privacy concern when addresses embed 237 information that can be used to infer the geographic location, 238 identity, or correlations in unrelated communications of a user. 239 Discussions on this topic and countermeasures have been scope of 240 numerous activities at IETF ([RFC4941], [RFC6462], [RFC7721], 241 [ADDRPRIV], [IDLOCPRIV]). An address mapping system can be used 242 as a basis for a solution as described in section 7. 244 o Mobile networks 246 Mobile networks, where the temporary location of a moving device 247 is typically changing more or less rapidly, require resolution 248 of the address of the current point of attachment (radio base 249 station) per device identifier. During an active session the 250 serving base station may change (handover) and the traffic is 251 rerouted to and from the new point of attachment's address. 252 Whereas cellular networks so far have applied mainly proprietary 253 procedures and 3GPP protocols [3GPP15] to mobility, forthcoming 254 5G architectures allow multiple heterogeneous access 255 technologies and may employ IP-based mechanisms. The address 256 mapping system could provide the mapping between a client 257 address and its current point of attachment. Use of AMS in a 5G 258 service based architecture is described in section 8. 260 1.2 Requirements 262 Requirements for the Internet Addressing Mapping system are: 264 o Allow use of different overlay protocols 266 The mapping system should be agnostic to the protocol used to 267 implement an underlying network overlay. An overlay could be 268 implemented using an encapsulation protocol, such as GTP, GUE, 269 LISP, VXLAN, etc., or using an identifier/locator address split 270 protocol such as ILA or ILNP. A network may simultaneously use 271 different overlay protocols per its needs. Mapping information 272 provided by the address mapping system indicates the overlay 273 technique and overlay technique specific instructions to use 274 when sending to a destination. 276 o Secure access to mapping system 278 An address mapping system may contain sensitive information, 279 particularly in the case that locators would reveal location or 280 identity of specific users. Access to the mapping system must be 281 tightly controlled. Law enforcement considerations may require 282 maintaining a history of mappings to provide under legal order. 284 o Mapping caches (anchorless mobility) 286 Mapping caches may be implemented at the network edge to perform 287 overlay forwarding and avoid triangular routing through 288 centralized anchor points. A cache may be implemented as a 289 working set cache or could be pre-populated with mappings for 290 common destinations. The purpose of the cache is to optimize for 291 critical communications, however the use of caches should not be 292 required for viable communications. 294 o Scalability 296 Address mapping systems should be able to scale to at least a 297 billion mappings in a single mapping system domain. This 298 accounts for a large number of devices, where each device may 299 have some number of associated mappings. It follows that a large 300 deployment will likely need a number of sharded mapping servers, 301 each of which may be replicated for reliability. 303 o Resiliency against Denial of Service attack 305 An address mapping system must be resistant to Denial of Service 306 attacks. For instance, if a mapping cache is used then a 307 resource exhaustion attack on a mapping cache must not result in 308 loss of service to users. 310 o User privacy 312 An address mapping system must facilitate user privacy. As 313 mentioned above, the mapping system must be secured to prevent 314 leakage of sensitive personal information. The mapping system 315 can also foster privacy in addressing by supporting untrackable, 316 per-flow IP addresses. 318 o Seamless handover 320 When a mobile device switches from one point of attachment to 321 another (handover), existing communications should continue 322 without packet loss or substantial delay. The mapping system 323 must be dynamic to handle handover events with bounded latency. 325 o Roaming 327 Devices may roam from one administrative domain to another. The 328 mapping systems in the home domain and remote domain may 329 coordinate to persist existing communications using addresses 330 that are local to the home domain. 332 o Stateless mapping mode 334 An address mapping system may provide a communication mode where 335 the mapping information is carried in packets themselves. When a 336 packet that contains such information enters a network, the 337 information can be decoded to determine the identifier to 338 locator mapping. This obviates the need for lookup in the 339 mapping system for each packet. 341 1.3 Terminology 343 Address Mapping System (AMS) 344 A system for mapping addresses to other addresses. 346 Address mapping system domain 347 An administrative domain in which an address mapping system is 348 run. The address mappings and related addresses are considered 349 to be in a domain. An address mapping system domain implements 350 a security policy to prevent unauthorized viewing or 351 manipulation of mapping information. 353 Mapping database/mapping table 354 A logical or real database that contains all of the address 355 mappings for an address mapping system domain. 357 Mapping address 358 A network address that is an object in the address mapping 359 system table. Mapping addresses are typically IPv4 or IPv6 360 addresses, but can generically be any type of fixed length 361 network addresses. 363 Identifier 364 A mapping address that identifies an end node in network 365 communication. In AMS, "identifier" generically refers to the 366 key in an address mapping system database. 368 Locator 369 A mapping address that refers to the location of a node. In 370 AMS, "locator" generically refers to the addresses that a key 371 maps to in the mapping system database. 373 Mapping entry 374 A single entry in a mapping system database. A mapping entry 375 is composed of the key address (the identifier), one or more 376 locators that the key maps to, and optional ancillary 377 information. 379 Mapping query 380 A lookup in the address mapping system database. A key address 381 (identifier) is provided and the corresponding map entry 382 (containing locators) is returned if the key is matched. 384 Overlay forwarding 385 The processing performed to implement a network overlay that 386 forwards packets to the location for their destination address 387 based on a mapping entry in the address mapping system. 389 Overlay method/overlay protocol 390 A method or protocol that implements overlay forwarding. 391 Overlay methods include encapsulation and address 392 transformation. 394 Overlay instructions 395 A set of instructions that are specific to an overlay method 396 Instructions can describe how the method is used and optional 397 protocol extensions or security parameters to use with the 398 overlay method. 400 Overlay termination 401 The processing done at the terminal endpoint of an overlay 402 protocol used in overlay forwarding. 404 AMS router (AMS-R) 405 A node that contains all or a shard of the addressing mapping 406 system database. An AMS-R node serves mapping system 407 information to AMS forwarding nodes. An AMS router will often 408 act as a packet router that performs overlay forwarding for 409 addresses that it manages in the mapping system. 411 AMS forwarders (AMS-F) 412 A node that performs overlay forwarding and/or overlay 413 termination. An AMS forwarder contains a mapping cache to 414 facilitate overlay forwarding. End hosts may participate in 415 the address mapping system as a specialized type of a 416 forwarder. 418 Addressing Mapping Routing Protocol (AMRP) 419 A protocol used amongst AMS routers to synchronize the address 420 mapping system database. 422 Addressing Mapping Forwarder Protocol (AMFP) 423 A control protocol run between AMS routers and AMS forwarders 424 that is used to manage mapping caches in AMS forwarders. 426 Firewall and Service Tickets (FAST) 427 A protocol in which packets carry "tickets" in extension 428 headers. Tickets provide arbitrary information about how a 429 network processes packets. 431 Hidden aggregation 432 A method to encode aggregation in network addresses where the 433 aggregation is visible to trusted devices within a network, 434 but is transparent to external observers of the addresses. 436 2 Architecture 438 This section describes the architecture of the Address Mapping 439 System. 441 2.1 Reference topology 443 The diagram below provides a generic reference topology for AMS. 445 +------------+ ___________ +------------+ 446 | AMS-R | ( Shared ) | AMS-R | 447 | AMS router +-------( Database )-------+ AMS router | 448 +------+-----+ (___________) +------+-----+ 449 | | 450 +-------+--+----------+ +----------+--+-------+ 451 | | | | | | 452 +---+---+ +---+---+ +---+---+ +---+---+ +---+---+ +-------+ 453 | AMS-F | | AMS-F | | AMS-F | | AMS-F | | AMS-F | | AMS-F | 454 | | | | | Server| | | | | | Server| 455 +-------+ +-------+ +-------+ +-------+ +-------+ +-------+ 456 | | | | 457 End hosts End hosts End hosts End hosts 459 2.2 Functional components 461 There are two fundamental types of nodes in the AMS architecture: 463 AMS-R: AMS routers 465 AMS-F: AMS forwarders 467 2.3 AMS router (AMS-R) 469 AMS routers are deployed within the network infrastructure and 470 collectively contain the address mapping database for an address 471 mapping system domain. The database may be sharded across some number 472 of routers for scalability. AMS routers that maintain the database or 473 a shard may be replicated for scalability and availability. AMS 474 routers share and synchronize mapping information amongst themselves 475 using an Address Mapping Routing Protocol (AMRP, see section 3). 477 AMS routers have three primary functions: 479 o Serving mapping information 481 o Overlay forwarding 483 o Sending redirects 485 2.3.1 Serving mapping information 487 AMS routers serve mapping information to AMS forwarders via the 488 Address Mapping Forwarder Protocol (AMFP, see section 4). Mapping 489 information is provided by a request/reply protocol, a push 490 mechanism, or mapping redirects. 492 2.3.2 Overlay forwarding 494 An AMS router may perform overlay forwarding for the destination 495 addresses it serves in the address mapping system database. Network 496 routing is configured so that packets with identifier addresses 497 served by an AMS-R will be routed to that AMS-R. 499 AMS routers are considered authoritative for the portion of the 500 mapping database that they serve. For instance, if a packet with an 501 identifier address is routed to an AMS-R then, either a mapping is 502 found and the packet is forwarded via overlay forwarding, or the 503 packet is dropped. In this sense, AMS routers can be thought of as 504 anchor points when they are forwarding packets (using 3GPP 505 terminology). 507 An AMS router can send mapping redirects to AMS forwarders in order 508 to inform them of a direct path they can take to a destination. A 509 redirect is sent to the upstream AMS forwarder of the source which 510 can be determined by a mapping query the source address. When an AMS 511 forwarder receives a redirect, it can create a mapping cache entry 512 and apply overlay forwarding on subsequent packets to directly send 513 to the destination instead routing packets through a AMS router. 515 2.3.3 AMS router operation 517 The operation of a forwarding AMS router is: 519 1) Packet are routed to the AMS-R 521 2) For each received packet, a lookup on the destination address 522 is performed in the mapping system database 524 3) If a matching mapping entry is found in the address mapping 525 system database: 527 o The packet is forwarded over a network overlay per the 528 returned locator and ancillary information 530 o Optionally, a mapping redirect is sent to an AMS forwarder 531 that is in that path from the source of the packet 533 4) Else, the packet is dropped 535 2.4 AMS forwarder (AMS-F) 537 As indicated in the reference topology, forwarding nodes may deployed 538 near the point of device attachment (e.g. base station, eNodeB) of 539 user devices (e.g. UEs). 541 End hosts may act as AMS forwarders. These could be servers that 542 provide overlay forwarding and termination on behalf of VMs or 543 containers for virtualization. Since the source of packets is local 544 on a host that is an AMS forwarder, there may be some datapath 545 optimizations that can be applied. 547 AMS forwarders may have two functions: 549 o Overlay termination which is restoring packets with original 550 identifier addresses 552 o Optional overlay forwarding to destinations based on a mapping 553 cache 555 2.4.1 Overlay termination 557 AMS forwarders perform overlay termination. In other words, they are 558 typically the target node of a locator. Overlay termination is the 559 process of removing or undoing the overlay processing that was 560 previously done. If the overlay method is encapsulation, the overlay 561 termination processing is to decapsulate the packet. If the overlay 562 method is address transformation, such as in ILA, the overlay 563 termination processing is to transform addresses back to their 564 original values before overlay processing. Once the overlay 565 processing is undone, an AMS forwarder forwards the resultant packet 566 to its final destination. 568 2.4.2 Overlay forwarding 570 An AMS forwarder may perform overlay forwarding to send packets 571 directly to the destination using a cache of address mappings. The 572 mapping cache of an AMS forwarder may be managed as a working set 573 cache. As a cache there must be methods to populate, evict, and 574 timeout entries. A cache is considered an optimization, so the system 575 should be functional without it being used (e.g. if the cache has no 576 entries). 578 The operation of overlay forwarding in an AMS forwarder is: 580 1) Receive packets from downstream nodes 581 2) Lookup up packet's destination address in the mapping cache 583 3) If a match is found in the mapping cache then forward the 584 packet over a network overlay per the returned locator and 585 instructions 587 4) Else, forward the unmodified packet in the network per normal 588 routing 590 5) An AMS router may send a mapping redirect in response to a 591 packet that had been forwarded by the AMS forwarder. In 592 response, the forwarder may create a mapping cache entry based 593 on the contents of the redirect and use the entry to send 594 directly to a destination for subsequent packets. 596 3 Address Mapping Router Protocol (AMRP) 598 AMS routers must synchronize the contents of the address mapping 599 system database. When a change occurs to an address mapping, for 600 instance a mobile device has moved to a new location, the AMS routers 601 managing the shard that contains the identifier must be synchronized 602 in as little convergence time as possible. 604 There are a number of options to use or have been used to implement 605 an AMS mapping router protocol. This document highlights some 606 alternatives, but does not prescribe a particular protocol. 608 3.1 Key/value database 610 A key/value database, such as a NoSQL database like Redis, can 611 implement an address mapping routing protocol. The idea of the 612 database is that each mapping shard is a distributed database 613 instance with some number of replicas. When a write is done in the 614 database, the change is propagated throughout all of the replicas for 615 the shard using the standard database replication mechanisms. Mapping 616 information is written to the database using a common database API 617 that can require authenticated write permissions. Each AMS router can 618 read the database for the associated shard to perform its function. 620 3.2 BGP 622 BGP can be used to propagate mapping information amongst AMS routers 623 as simple routes. [BGPOLAY] describes a scalable method for using BGP 624 in overlay networks. [BGPILA] describes a method to distribute 625 identifier to locator information using Multiprotocol Extensions for 626 BGP-4. 628 3.3 GTP 629 GPRS tunneling protocol (GTP) is the primary protocol for control and 630 user plane in 4G and has been adopted in 5G service based 631 architecture where control and user plane is separated. GTP tunnels 632 are data plane encapsulation programmed for subscribers as point to 633 point segments between the network elements from enodeB to SGW 634 (Serving Gateway) to PGW (Packet Gateway) in 4G and gnodeB (5G base 635 station) to UPF (User Plane Function) in 5G. 637 AMS scheme allows to migrate the GTP Anchors like PGW and UPF to open 638 the network distributed application for mobility. 640 4 Address Mapping Forwarder Protocol (AMFP) 642 The Address Mapping Forwarder Protocol (AMFP) is a control plane 643 protocol that provides address to address mappings. Clients of the 644 AMFP include AMS forwarders with mapping caches, so AMFP includes 645 primitives for mapping cache management. 647 AMFP is primarily used between AMS forwarders and AMS routers. The 648 purpose of the protocol is to populate and maintain the mapping cache 649 in AMS forwarders. 651 AMFP defines mapping redirects, a request/response protocol, and a 652 push mechanism to populate the mapping cache. AMFP runs over TCP to 653 leverage reliability, statefulness implied by established 654 connections, ordering, and security in the form of TLS. Secure 655 redirects are facilitated by the use of TCP. 657 AMFP messages are sent over the TCP stream and must be delineated by 658 a receiver. Different versions of AMS are allowed and the version 659 used for communication is negotiated by Hello messages. 661 4.1 Common header format 663 All AMFP messages begin with a two octet common header: 665 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 666 | Type | Length | 667 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 669 The contents of the common header are: 671 o Type: Indicates the type of message. A type 0 message is a Hello 672 message. Types greater than zero are interpreted per the 673 negotiated version. 675 o Length: Length of the message in 32-bit words not including the 676 first four bytes of the message. All AMFP messages are multiples 677 of four bytes in length and the message length includes the two 678 bytes for the common header. The length field is computed as 679 (message_length / 4) - 1, so the minimum message size is four and 680 the maximum size is 16,384 bytes. 682 Following the two octet common header is variable length data that is 683 specific to the negotiated version and type the message. 685 4.2 Hello messages 687 Hello messages indicate the versions of AMFP that a node supports. A 688 Hello message MUST be sent by each side as the first message in the 689 connection. 691 The format of an AMFP Hello message is: 693 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 694 | 0 | 1 |R| Rsvd | 695 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 696 | Versions | 697 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 699 The contents of the Hello message are: 701 o Type = 0. This is indicates the type is a Hello message. 703 o Length = 1. Indicates eight byte length. 705 o Router bit: Indicates the sender is an AMS router. If the sender 706 is an AMS forwarder this bit is cleared. 708 o Rsvd: Reserved bits. Must be set to zero on transmit. 710 o Versions: A bit map of supported versions. Bit 0 refers to 711 version 0, bit 1 refers to version 1, etc. If a bit is set then 712 the corresponding version is supported by a node. 714 Version numbers are from 0 to 31. Version 0-15 will defined by IANA, 715 and versions 16 to 31 are user defined. This document describes 716 version 0 of AMFP. 718 4.3 Version negotiation 720 The first message sent by each side of an AMFP connection is a Hello 721 message. Hello messages indicate the set of AMFP versions that a node 722 supports. 724 When a host receives an AMFP Hello message, it determines which 725 version is negotiated. The negotiated version is the maximum version 726 number supported by both sides. For instance, if a node advertises 727 that versions 0,1,3, and 4 are supported and receives a peer Hello 728 message with versions 1 and 2 indicated as being supported; then the 729 negotiated version is 1 since that is the greatest version supported 730 by both sides. The peer host will also determine that 1 is the 731 negotiated version. 733 If there is no common version supported between peers, that is their 734 sets of supported versions are disjoint, then version negotiation 735 fails. The connection MUST be terminated and error message SHOULD be 736 logged. 738 If both sides set the router bit or both clear the router bit in a 739 Hello message, then this is an error and the connection MUST be 740 terminated and error message SHOULD be logged. Both sides cannot have 741 the same role in an AMFP session. 743 If the first message received on a connection is not a Hello message, 744 then that is an error so the connection MUST be terminated and an 745 error MAY be logged. If a second Hello message is received on a 746 connection, then that is also considered an error so the connection 747 MUST be terminated and an error MAY be logged. 749 5 AMFP Version 0 751 This section describes the message types and operation of version 0 752 of AMFP. 754 5.1 Message types 756 The message types in version 0 of AMFP are: 758 o Parameters (Type = 1) 760 o Map request (Type = 2) 762 o Map information (Type = 3) 764 o Compressed map information (Type = 4) 766 o Locator unreachable (Type = 5) 768 o Cache occupancy (Type = 6) 770 5.2 Parameters message 772 A Parameters message contains AMFP related parameters. The parameters 773 are encodes in TLVs. A Parameters message MUST be sent by each side 774 as the first message after the AMFP version negotiation is completed. 776 The format of an AMFP Parameters message is: 778 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 779 | 1 | Length | Rsvd | 780 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 781 | | 782 ~ TLVs ~ 783 | | 784 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 786 The contents of the Parameters message are: 788 o Type = 1. This is indicates a Parameters message. 790 o Length: Set to the length of the TLVs divided by four. 792 o Rsvd: Reserved bits. Must be set to zero when sending. 794 o TLVs: A list of TLVs that describe capabilities or requested 795 options. 797 The format of a TLV is: 799 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 800 | Type | Length | | 801 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 802 | | 803 ~ Data ~ 804 | | 805 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 807 Fields are: 809 o Type: Type of the TLV. 811 o Length: Length of the TLV 32-bit units not include the first four 812 bytes of the TLV. The minimum length of a TLV is four bytes and 813 the maximum length is 1024 bytes. 815 The table below lists the Parameters TLVs defined in this document. 816 The "Length" column indicates any length requirements on TLVs, and 817 the "Sender" column indicates whether the TLV can be sent by the 818 router, forwarder, or both sides. 820 Type Length Sender Meaning 821 --------------------------------------------------------------------- 822 0 RESERVED 823 1 4 Either side Supported identifier types 824 2 4 Either side Supported locator types 825 3 variable Either side Supported overlay methods 826 4 4 Router Default overlay method 827 5 8 Router Default timeout 828 6 4 Router Default priority 829 7 4 Router Default weight 830 8 variable Router Default instructions 831 9-127 UNASSIGNED (assignable by IANA) 832 128-255 User defined 834 5.2.1 Supported identifier types 836 This TLV provides the identifier types that a node supports. The TLV 837 can be sent by either an AMS-R or an AMS-F. The format of the TLV is: 839 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 840 | 1 | 0 | IDTypes | 841 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 843 Fields are: 845 o Type = 1 847 o Length: Set to 0 to indicate four bytes length. 849 o IDTypes: A bitmap that indicates supported identifier types. The 850 position in the bitmap corresponds to the defined values for 851 identifier type. Identifier types are defined below. 853 If the supported identifier types TLV is not received then a node 854 assumes that supported identifier types by a peer is unknown. 856 5.2.2 Supported locator types 858 This TLV provides the locator types that a node supports. The TLV can 859 be sent by either and AMS-R or an AMS-F. The format of the TLV is: 861 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 862 | 2 | 0 | LocTypes | 863 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 865 Fields are: 867 o Type = 2 868 o Length: Set to 0 to indicate four bytes length. 870 o LocTypes: A bitmap that indicates supported locator types. The 871 position in the bitmap corresponds to the defined values for 872 locator types. Locator types are defined below. 874 If the supported locator types TLV is not received then a node 875 assumes that supported locator types by a peer is unknown. 877 5.2.3 Supported overlay methods 879 This TLV provides the overlay methods that a node supports. The TLV 880 can be sent by either an AMS-R or an AMS-F. The format of the TLV is: 882 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 883 | 3 | Length | Rsvd | 884 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 885 | | 886 ~ Overlay methods ~ 887 | | 888 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 890 Fields are: 892 o Type = 3 894 o Length: Set to length of the overlay methods bitmap divided by 895 four. The overlay methods bitmap is padded with zeroes if 896 necessary to align message length to four bytes. 898 o Overlay methods: A variable length bit map that indicates 899 overlay methods. The position in the bitmap corresponds to the 900 defined values for the various overlay methods. Overlay methods 901 are defined in section 10. 903 If the supported overlay methods TLV is not received then a node 904 assumes that supported overlay methods in a peer is unknown. 906 5.2.4 Default overlay method 908 This TLV provides the default overlay method in reported mapping 909 information when the method is not explicitly provided in a mapping 910 information message. The format of the TLV is: 912 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 913 | 4 | 0 | OvMethod | Rsvd | 914 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 916 Fields are: 918 o Type = 4 920 o Length = 0, indicating four bytes length 922 o OvMethod: Indicates the default overlay method to be used when 923 sending to a locator. 925 o Rsvd: Reserved bits. Must be set to zero when sending. 927 Only AMS routers send this TLV. If the TLV is received by an AMS 928 router it is considered an error. 930 The default overlay method SHOULD be negotiated. If it's not 931 negotiated then the default method is undefined. 933 5.2.5 Default timeout 935 This TLV provides the default timeout for reported mapping 936 information when the timeout is not explicitly provided in a mapping 937 information message. 939 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 940 | 5 | 1 | Rsvd | 941 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 942 | Timeout | 943 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 945 Fields are: 947 o Type = 5 949 o Length = 1, indicating eight bytes length 951 o Rsvd: Reserved bits. Must be set to zero when sending. 953 o Timeout: The default time to live for the identifier information 954 in seconds. 956 Only AMS routers send this TLV. If the TLV is received by an AMS 957 router it is considered an error. 959 If the default timeout is not negotiated then the assumed default is 960 300 seconds (five minutes). 962 5.2.6 Default priority 963 This TLV provides the default overlay priority in reported mapping 964 information when the priority is not explicitly provided in a mapping 965 information message. The format of the TLV is: 967 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 968 | 6 | 0 | Priority | Rsvd | 969 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 971 Fields are: 973 o Type = 6 975 o Length = 0, indicating four bytes length 977 o Priority: Default relative priority of a locator. Locators with 978 higher priority values have preference to be used. Locators that 979 have the same priority may be used for load balancing. 981 o Rsvd: Reserved bits. Must be set to zero when sending. 983 Only AMS routers send this TLV. If the TLV is received by a router it 984 is considered an error. 986 If the default priority is not negotiated then the assumed default 987 value is zero. 989 5.2.7 Default weight 991 This TLV provides the default weight in reported mapping information 992 when the weight is not explicitly provided in a mapping information 993 message. The format of the TLV is: 995 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 996 | 7 | 0 | Weight | Rsvd | 997 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 999 Fields are: 1001 o Type = 7 1003 o Length = 0, indicating four bytes length 1005 o Weight: Relative weight assigned to each locator. In the case 1006 that locators have the same priority the weights are used to 1007 control how traffic is distributed. A weight of zero indicates no 1008 weight and the mapping is not used unless all locators for the 1009 same priority have a weight of zero. 1011 o Rsvd: Reserved bits. Must be set to zero when sending. 1013 Only AMS routers send this TLV. If the TLV is received by a router it 1014 is considered an error. 1016 If the default weight is not negotiated then the assumed default 1017 value is zero. 1019 5.2.8 Default instructions 1021 This TLV provides the default overlay specific instructions in 1022 reported mapping information when instructions are not explicitly 1023 provided in a mapping information message. The format of the TLV is: 1025 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1026 | 8 | Length | OvMethod | Rsvd | 1027 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1028 | | 1029 ~ Instructions ~ 1030 | | 1031 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1033 Fields are: 1035 o Type = 8 1037 o Length: Set to length of instructions divided by four. 1039 o OvMethod: Indicates the overlay method associated with the 1040 instructions. 1042 o Rsvd: Reserved bits. Must be set to zero when sending. 1044 o Instructions: Data with format and semantics that are specific to 1045 an overlay method and describe options for the method and how the 1046 overlay method is used. 1048 Only AMS routers send this TLV. If the TLV is received by a router it 1049 is considered an error. The TLV may sent multiple times for different 1050 overlay methods. 1052 If default instructions are not negotiated then the assumed default 1053 value is no instructions. 1055 5.3 Map Request message 1057 A Map Request message is sent by an AMS forwarder to an AMS router to 1058 request mapping information for a list of identifiers. The format of 1059 a Map Request message is: 1061 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1062 | 2 | Length |IDType | Rsvd | 1063 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\ 1064 | | | 1065 ~ Identifier ~ ent 1066 | | | 1067 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+/ 1069 The contents of the Map Request message are: 1071 o Type = 2. This is indicates a Map Request message 1073 o Length: Message length is set to size of an identifier times the 1074 number of identifiers in the list. The Length field is computed 1075 as (identifier_size * number_of_identifiers) / 4. 1077 o Rsvd: Reserved bits. Must be set to zero when sending. 1079 o IDType: Identifier type. Specifies the identifier type. This also 1080 implies the length of each identifier in the request list. 1081 Identifier types are defined below. 1083 o Identifier: An identifier of type indicated by IDType. The size 1084 of an identifier is specified by the type. 1086 The Identifier field is repeated for each identifier in the list. The 1087 number of identifiers being requested is (message_length - 4) / 1088 (identifier_size). 1090 This message MUST only be sent by an AMS forwarder. If an AMS 1091 forwarder receives a Map Request message it is considered an error. 1093 5.4 Map Information message 1095 A Map Information message is sent by an AMS router to provide mapping 1096 information. In addition to providing locators for an identifier, the 1097 message also contains the overlay method to use and related 1098 instructions for sending to an identifier. 1100 A Map Information message is composed of a four byte header followed 1101 by a set of identifier records. Each identifier record describes 1102 mapping information for one identifier. An identifier record is 1103 composed of a four byte header, an identifier, and a set of locator 1104 entries. Each locator entry provides the information about one 1105 locator used to reach the identifier. A locator entry is composed of 1106 a four byte header that includes the overlay method to use, the 1107 locator, and optional instructions specific to the overlay method for 1108 the locator. 1110 The identifier record is repeated for each mapping being reported and 1111 the locator entry is repeated for each locator being reported for an 1112 identifier. Both records and entries are variable length. The total 1113 number of identifiers being reported is determined by parsing the 1114 message. 1116 The format of a Map Information message is: 1118 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1119 | 3 | Length | Reason| Rsvd | 1120 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ <-+ 1121 |IDType | Record timeout | Num locator | \ 1122 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1123 | | | 1124 ~ Identifier ~ | 1125 | | r 1126 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\ e 1127 |LocType| Ilen | OvMethod | Weight | Prio | Rsvd | | c 1128 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | o 1129 | | e r 1130 ~ Locator ~ n d 1131 | | t | 1132 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ r | 1133 | | y | 1134 ~ Instructions ~ | | 1135 | |/ | 1136 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<--+ 1138 The contents of the Map Information message header are: 1140 o Type = 3. This indicates a Map Information message 1142 o Length: Set to the sum of lengths of all the identifier records 1143 in the message divided by four. The length of an identifier 1144 record is four bytes plus the sum of all the lengths of locator 1145 entries in the record. The length of a locator entry is four plus 1146 the size of a locator plus the length of the instruction field. 1148 o Reason: Specifies the reason that the message was sent. Reasons 1149 are: 1151 o 0: Map reply to a map request 1153 o 1: Redirect 1154 o 2: Push map information 1156 o Rsvd: Reserved bits. Must be set to zero when sending. 1158 The contents of an identifier record are: 1160 o IDType: Identifier type. Specifies the identifier type. This also 1161 implies the length of each identifier in the list. Identifier 1162 types are defined below. 1164 o Record timeout: The time to live for the identifier information 1165 in seconds. A value of zero indicates the default value is used. 1167 o Num locator: Number of locators (entries) being reported for an 1168 identifier. 1170 o Identifier: An identifier of type specified in IDType. 1172 The contents of a locator entry are: 1174 o LocType: Locator type. Specifies the locator type. This also 1175 implies the length of each locator in the list. Locator types are 1176 defined below. 1178 o Ilen: Length in 32-bit words of optional instructions in the 1179 entry (length of the instructions field). Instructions are 1180 overlay method specific and can describe options or how the 1181 overlay is used. The instructions length is from zero to sixty 1182 bytes. 1184 o OvMethod: The overlay method to use for sending to the identifier 1185 using the given locator. This is an indication of the 1186 encapsulation method (e.g. GUE, GTP, LISP, etc.) or address 1187 transformation method (e.g. ILA). Specific values are listed in 1188 section 10. 1190 o Weight: Relative weights assigned to each locator. In the case 1191 that locators have the same priority the weights are used to 1192 control how traffic is distributed. A weight of zero indicates no 1193 weight and the mapping is not used unless all locators for the 1194 same priority have a weight of zero. 1196 o Prio: Relative priority of a locator. Locators with higher 1197 priority values have preference to be used. Locators that have 1198 the same priority may be used for load balancing. 1200 o Rsvd: Reserved bits. Must be set to zero when sending 1201 o Locator: A locator of type specified in LocType. 1203 o Instructions: Optional data with format and semantics that are 1204 specific to an overlay method and can describe options for the 1205 method and how the overlay method is used. Ilen indicates the 1206 length of the field. 1208 This message MUST only be sent by an AMS router. If an AMS router 1209 receives a Map Information message it is considered an error. 1211 5.5 Compressed Map Information message 1213 The Compressed Map Information message may be sent as an efficient 1214 alternative to the Map Information message. The Compressed Map 1215 Information can be used when all these conditions are met: 1217 o There is only locator provided for each identifier 1219 o The identifier type and locator type are common for all the 1220 mappings reported in the message 1222 o The priority, weight, overlay method, record timeout, and overlay 1223 instructions are the default values negotiated for the AMFP 1224 session 1226 A Compressed Map Information message is composed of a four byte 1227 header followed by a list of identifier/locator pairs. 1229 The identifier/locator pairs are repeated for each mapping being 1230 reported. The total number of identifiers being reported can computed 1231 as (message_length - 4) / (identifier_size + locator_size). 1233 The format of the Compressed Map Information message header is: 1235 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1236 | 4 | Length | Reason|IDType |LocType| Rsvd | 1237 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ 1238 | | | 1239 ~ Identifier ~ e 1240 | | n 1241 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ t 1242 | | | 1243 ~ Locator | | 1244 | |/ 1245 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1246 The contents of the Compressed Map Information message header are: 1248 o Type = 4. This indicates a Compressed Map Information message 1250 o Length: Set to the sum of lengths of the identifier/locator pairs 1251 in the message divided by four 1253 o Reason: Specifies the reason that the message was sent. Reasons 1254 are: 1256 o 0: Map reply to a map request 1258 o 1: Redirect 1260 o 2: Push map information 1262 o IDType: Identifier type. Specifies the identifier type. This also 1263 implies the length of each identifier in the list. Identifier 1264 types are defined below. 1266 o LocType: Locator type. Specifies the locator type. This also 1267 implies the length of each locator in the list. Locator types are 1268 defined below. 1270 o Rsvd: Reserved bits. Must be set to zero when sending 1272 o Identifier: An identifier of type specified in IdType. 1274 o Locator: A locator of type specified in LocType. 1276 This message MUST only be sent by an AMS router. If an AMS router 1277 receives a Compressed Map Information message it is considered an 1278 error. 1280 5.6 Locator Unreachable message 1282 A locator Unreachable message is sent by AMS routers to AMS 1283 forwarders in the event that a locator or locators are known to no 1284 longer be reachable. The format of a Locator Unreachable message is: 1286 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1287 | 5 | Length | Rsvd |LocType| Rsvd | 1288 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\ 1289 | | | 1290 ~ Locator ~ ent 1291 | | | 1292 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+/ 1293 The fields of the locator unreachable message are: 1295 o Type = 5. This indicates a Locator Unreachable message. 1297 o Length: Set to the size of the locator times the number of 1298 locators in the list divided by four. 1300 o LocType: Specifies the locator type. This also implies the length 1301 of each locator in the list. Locator types are defined below. 1303 o Rsvd: Reserved bits. Must be set to zero when sending. 1305 o Locator: A locator of type indicated by LocType. The size of a 1306 locator is specified by the type. 1308 The Locator field is repeated for each locator in the list. The 1309 number of locators being reported is (message_length - 4) / 1310 (locator_size). 1312 This message MUST only be sent by an AMS router. If an AMS router 1313 receives a Locator Unreachable message it is considered an error. 1315 5.7 Identifier and locator types 1317 Identifier and locator values used in IDType and LocType fields of 1318 AMCP messages are: 1320 o 0: Null value, 0 bit value. This indicates that absence of 1321 locator or identifier information. 1323 o 1: IPv6 address, 128 bit value 1325 o 2: IPv4 address, 32 bit value 1327 o 3: 32 bit index 1329 o 4: 64 bit index 1331 o 5: ILA value. A 64 bit value that represent a canonical ILA 1332 identifier when used in an IDType field and a canonical ILA 1333 locator when used in a LocType field. 1335 Note that the types for index values are used to index into tables 1336 for locators or identifiers. 1338 5.8 Cache Occupancy message 1340 This message provides the mapping cache size and occupancy of an AMS 1341 forwarder. This serves as a hint that a router can use when pushing 1342 cache entries. The format of a Cache Occupancy message is: 1344 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1345 | 6 | 4 | Pressure | 1346 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1347 | Number entries in use | 1348 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1349 | Maximum entries | 1350 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1351 | Number bytes in use | 1352 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1353 | Maximum bytes | 1354 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1356 Fields are: 1358 o Type = 6. This indicates a Cache Occupancy message. 1360 o Length = 4, indicating twenty bytes length 1362 o Pressure: Indicates relative pressure the cache is under. The 1363 higher the number, the greater the pressure. 1365 o Number entries in use: Approximate number of cache entries in the 1366 forwarder cache. 1368 o Maximum entries: Approximate maximum number of cache entries in 1369 the forwarder cache. Zero indicates no reported information. 1371 o Number bytes in use: Approximate number of bytes used in the 1372 forwarder cache. 1374 o Maximum bytes: Approximate maximum number of bytes in the 1375 forwarder cache. Zero indicates no reported information. 1377 If the cache size is not reported by a forwarder, then a router may 1378 assume local default values configured for the domain. Note that the 1379 protocol allows the forwarder to report cache occupancy and limits in 1380 several ways. Routers MAY use this information to modify the rate of 1381 pushing mapping entries or sending redirects. 1383 This message is only sent by AMS forwarders. If an AMS forwarder 1384 receives a Cache Occupancy message then it is considered an error. 1386 5.9 Operation 1388 This section describes the operation of AMFP. 1390 5.9.1 Populating an mapping cache 1392 AMS forwarders can maintain a cache of identifier to locator 1393 mappings. There are three means for populating this cache: 1395 o Redirects 1397 o Mapping request/reply 1399 o Pushed mappings 1401 Redirects are RECOMMNDED as the primary means of dynamically 1402 obtaining mapping information. Request/reply and push mappings may be 1403 used in limited circumstances, however generally these techniques 1404 don't scale and are susceptible to DOS attack. 1406 AMS forwarders (and AMS routers as well) are work conserving, they do 1407 not hold packets that are pending mapping resolution. If a node does 1408 not have a mapping for a destination in its cache then the packet is 1409 forwarded into the network; the packet should be processed by an AMS 1410 router and sent to the proper destination node. 1412 5.9.2 Redirects 1414 An AMS router can send redirects in conjunction with forwarding 1415 packets. Redirects are Mapping Information or Compressed Mapping 1416 Information messages sent to AMS forwarders in order to inform them 1417 of a direct AMS path. A redirect is sent to the upstream AMS 1418 forwarder of the source which is determined by a lookup in the 1419 mapping system on the source address of the packet being forwarded. 1420 The found locator is used to infer the address of the AMS forwarder. 1421 Note that this technique assumes a symmetric path towards the source. 1423 5.9.2.1 Proactive push with redirect 1425 In addition to sending an AMFP redirect to the AMS forwarder, an AMS 1426 router MAY send an AMFP push to the AMS forwarder associated with the 1427 destination to inform it of the identifier to locator mapping for the 1428 source address in a packet. This is an optimization to push the 1429 mapping entry that can be used in the reverse direction of 1430 communications. In order to do this, the AMS router performs a 1431 mapping lookup on the source address (which should already be done to 1432 perform the redirect). An AMFP push message is then sent to the 1433 forwarding node or host based on its locator. 1435 5.9.2.2 Redirect rate limiting 1437 An AMS router SHOULD rate limit the number of redirects it sends to a 1438 forwarder for each redirected address. The rate limit SHOULD be 1439 configurable. The default rate limit SHOULD be to send no more than 1440 one redirect to a forwarder per second per redirected identifier. If 1441 a mapping change is detected the the rate limiting SHOULD be reset so 1442 that redirects for a new mapping can be sent immediately. 1444 5.9.3 Map request/reply 1446 An AMS forwarder may send a Map Request message to obtain mapping 1447 information for a locator. If the receiving AMS router has the 1448 mapping information, it responds with a Map Information or Compressed 1449 Map Information message. If the router does not have a mapping entry 1450 for the requested identifier, it MAY reply with a locator type of 1451 Null. 1453 Map requests are NOT RECOMMENDED as the primary means to dynamically 1454 populate entries in a mapping cache. The problem with this technique 1455 is that an AMS forwarder may generate a map request for each new 1456 destination that it gets from a downstream end host. A downstream end 1457 host could launch a Denial of Service (DOS) attack whereby it sends 1458 packets with random destination addresses that require a mapping 1459 lookup. In the worst case scenario, the forwarder would send a map 1460 request for every packet received. Rate limiting the sending of map 1461 requests does not mitigate the problem since that would prevent the 1462 cache from getting mappings for legitimate destinations. 1464 5.9.4 Push mappings 1466 An AMS router may push mappings to an AMS forwarder without being 1467 requested to do so. This mechanism could be used to pre-populate a 1468 mapping cache. Pre-populating the cache might be done if the network 1469 has a very small number of identifiers or there are a set of 1470 identifiers that are likely to be used for forwarding in most AMS 1471 forwarders (identifiers for common services in the network for 1472 instance). When an AMS router detects a changed mapping, the locator 1473 changes for instance, a new mapping can be pushed to the AMS 1474 forwarders. 1476 The push model is NOT RECOMMENDED as a primary means to populate a 1477 mapping cache since it does not scale. Conceivably, one could 1478 implement a pub/sub model and track of all AMS mappings and to which 1479 nodes the mapping information was provided. When a mapping changes, 1480 mapping information could be sent to those nodes that expressed 1481 interest. Such a scheme will not scale in deployments that have many 1482 mappings. 1484 5.9.5 Cache maintenance 1485 This section describes maintenance of a mapping cache. 1487 5.9.5.1 Timeouts 1489 A node SHOULD apply the timeout for a mapping entry that was 1490 indicated in a Map Information message or as negotiated default. If 1491 the timeout fires then the mapping entry is removed. Subsequent 1492 packets may cause an AMS router to send a redirect so that the 1493 mapping entry gets repopulated in the cache. 1495 The RECOMMENDED default timeout for identifiers is five minutes. If a 1496 node sends a map request to refresh a mapping, the RECOMMENDED 1497 default is to send the request ten seconds before the the mapping 1498 expires. 1500 5.9.5.2 Cache refresh 1502 In order to avoid cycling a mapping entry with a redirect after a 1503 mapping that times out, a node MAY try to refresh the mapping before 1504 timeout. This should only be done if the cache entry has been used to 1505 forward a packet during the timeout interval. 1507 A cache refresh is performed by sending a Map Request for an 1508 identifier before its cache entry expires. If a Map Information 1509 message is received for the identifier, then the timeout can be reset 1510 and there are no other side effects. 1512 5.9.6 AMS forwarder processing 1514 If an AMS forwarder receives to its local address (i.e. a locator 1515 address) a packet that has undergone overlay forwarding, it will 1516 perform overlay termination. It will check its local mapping database 1517 to determine if the identifier revealed in the packet after overlay 1518 termination is local. If the identifier is local, the forwarder will 1519 forward the packet on to its destination which is either a downstream 1520 node that the forwarder has a route to, or a local VM or container in 1521 the case that the forwarder is an end host. 1523 If the identifier is not local then the AMS forwarder forwards the 1524 packet back into the network after overlay termination. This may 1525 happen if an end node has moved to be attached to a different AMS 1526 forwarder and the new locator has not yet been propagated to all AMS 1527 nodes. The packet should traverse an AMS router which can send a 1528 mapping redirect back the source's AMS forwarder as described above. 1529 To avoid infinite loop in this process, the forwarder must decrement 1530 the TTL in the packet being forwarded. 1532 When a node migrates its point of attachment from one forwarder to 1533 another, the local mapping on the old node is removed so that any 1534 packets that are received and destined to the migrated identifier are 1535 re-injected without using an overlay method. A "negative" mapping 1536 with timeout may also be set ensure that the node is able to infer 1537 the destination address is a proper identifier for the mapping domain 1538 (e.g. would be needed with foreign identifiers). 1540 5.9.7 Locator unreachable handling 1542 When connectivity to a locator is loss, the address mapping system 1543 should detect this. A Locator Unreachable message MAY be sent by AMS 1544 routers to AMS forwarders to inform them that a locator is no longer 1545 reachable. Each forwarder SHOULD remove any cache entries using that 1546 locator and MAY send a map request for the affected identifiers. 1548 5.9.8 Control connections 1550 AMS forwarders must create AMFP connections to all the AMS routers 1551 that might provide routing information. In a simple network there may 1552 be just one router to connect to. In a more complex network with AMS 1553 routers for a sharded and replicated mapping system database there 1554 may be many. A list of AMS routers to connect to is provided to each 1555 AMS forwarder. This list could be provided by configuration, a shared 1556 database, or an external protocol to AMFP. 1558 Conceivably, the number of AMS routers in a network that might report 1559 mapping information could be quite large (into the thousands). If 1560 managing a large number of connections in AMS forwarders is 1561 problematic, AMS router proxies could be used to consolidate 1562 connections as illustrated below: 1564 +-------+ +-------+ +-------+ +-------+ +-------+ 1565 | AMS-R | | AMS-R | | AMS-R | | AMS-R | | AMS-R | 1566 +---+---+ +---+---+ +---+---+ +---+---+ +---+---+ 1567 | | | | | 1568 | +-+------------+-------------+-+ | 1569 +----------+ AMFP +----------+ 1570 | PROXY | 1571 +----------+ +----------+ 1572 | +-+------------+-------------+-+ | 1573 | | | | | 1574 +---+---+ +---+---+ +---+---+ +---+---+ +-------+ 1575 | AMS-F | | AMS-F | | AMS-H | | AMS-F | | AMS-F | 1576 +---+---+ +---+---+ +---+---+ +---+---+ +---+---+ 1578 In the above diagram a single AMS router proxy serves five AMS 1579 routers and five AMS forwarders. The proxy creates one connection to 1580 each AMS router and each AMS forwarder creates one connection to the 1581 proxy. 1583 5.9.9 Protocol errors 1585 If a protocol error is encountered in processing AMFP messages then a 1586 node MUST terminate the connection. It SHOULD log an error and MAY 1587 attempt to restart the connection. There are no error messages 1588 defined in AMFP. 1590 Protocol errors include mismatch of length for the message type or a 1591 Parameters TLV, unknown message type or Parameters TLV type, reserved 1592 bits not set to zero, unknown identifier type or locator type, 1593 unknown reason, unknown overlay method or instructions, loss of 1594 message synchronization in a TCP stream, or a message or parameters 1595 TLV was received that is inappropriate for the AMFP role. Note that 1596 if the end of a message does not end on field or record or message 1597 boundary this also considered a protocol error. 1599 6 Stateless mapping optimization using FAST 1601 An alternative to requiring a mapping lookup on each packet is to 1602 encode the mapping information in packets themselves. This can be 1603 achieved by encoding mapping information in Firewall and Service 1604 Tickets [FAST]. The basic concept is that mapping information is 1605 encoded in FAST tickets which are attached in packets at end hosts 1606 and interpreted by the network. Tickets are associated with flows and 1607 are set in all the packets for the flow. Ticket reflection ensures 1608 that packets sent in the return path of a flow include a ticket. 1610 6.1 Firewall and Service Tickets encoding 1612 FAST tickets are encoded in Hop-by-Hop options. The format of a FAST 1613 ticket in a Hop-by-Hop option is: 1615 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1616 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1617 | Option Type | Opt Data Len | Prop | Rsvd | Type | 1618 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1619 | | 1620 ~ Ticket ~ 1621 | | 1622 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1624 [FAST] suggests a simple and efficient encoding of a Service Profile 1625 Index: 1627 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1628 | Option Type | Opt Data Len | Prop | Rsvd | Type | 1629 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1630 | Expiration time | 1631 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1632 | Service Profile Index | 1633 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1635 This format can be amended to include address mapping encoding. 1637 6.2 Address mapping encoding 1639 A locator address can be directly encoded in a ticket. Different 1640 address types can be used. A ticket with expiration time, service 1641 profile and locator address may have format: 1643 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1644 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1645 | Option Type | Opt Data Len | Prop |LocType| Type | 1646 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1647 | Expiration time | 1648 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1649 | Service Profile Index | 1650 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1651 | | 1652 ~ Locator ~ 1653 | | 1654 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1656 Pertinent fields are: 1658 o LocType: Specifies the locator type. This also implies the 1659 length the locator in the list. Locator types are defined above. 1661 o Service Profile Index: Can encode the overlay method and a 1662 limited set of instructions for overlay forwarding. 1664 o Locator: A locator of type indicated by LocType. The size of a 1665 locator is specified by the type. 1667 A network may have a comparatively small number of locators. For 1668 instance, a mobile provider might associate each eNodeB with a 1669 locator and there may only be a few thousand of these. In this case, 1670 the border routers might maintain a table of locator addresses that 1671 can simply be indexed by number in a small range. Similarly, the 1672 backend server in the layer 4 load balancing case might also be 1673 indicated by an index into a table of backend servers. 1675 6.3 Reference topology 1676 As show in the reference topology below, FAST routers and AMS 1677 forwarders are involved in the stateless mapping datapath. AMS 1678 routers are not directly involved in the data path, however they 1679 serve the mapping information to be encoded into FAST tickets. 1681 FAST routers interpret tickets and perform overlay forwarding. AMS 1682 forwarders terminate overlay forwarding. Note that an AMS forwarder 1683 and FAST router would be co-located so that a node processes FAST 1684 tickets and does AMS forwarding base on that. 1686 Internet 1687 | 1688 +-----------+---------+ 1689 | FAST | AMS-F | 1690 | router | | 1691 +-----------+---------+ 1692 | 1693 +-----------+---------+ _____|_____ +------------+---------+ 1694 | FAST | AMS-F | ( ) | FAST | AMS-F | 1695 | router | +----( Network )----+ router | | 1696 +-----------+---------+ (___________) +------------+---------+ 1697 | 1698 +----------+----------+ 1699 | | | 1700 +---+---+ +---+---+ +---+---+ 1701 | AMS-F | | AMS-F | | AMS-F | 1702 +-------+ +-------+ +-------+ 1703 | | 1704 End hosts End hosts 1706 6.4 Operation 1708 This section describes the operation of encoding mapping entries in 1709 FAST tickets. 1711 6.4.1 Ticket requests 1713 Applications request FAST tickets from a ticket agent in the network 1714 local to the application. The ticket agent can return a ticket for 1715 the application to use in its data packets. The ticket includes 1716 information that is parsed by elements in the issuing network. The 1717 ticket information may include routing information. For example, if 1718 the application is on a mobile device, the network may provide a 1719 ticket that has a locator indicating the current location of the 1720 device. 1722 [FAST] describes the process of an application requesting tickets and 1723 setting them in packets. An application will not normally need to 1724 make any special requests for routing information and the use of 1725 routing information is expected to be transparent to the application. 1727 6.4.2 Qualified locators 1729 There are two possibilities for locator information in a ticket: 1731 o The locator is fully qualified. 1733 o The locator is not qualified. 1735 6.4.2.1 Fully qualified locators 1737 If a locator is qualified then the issued ticket contains the 1738 locator for the end node. If the locator changes, that is the node 1739 moves, then a new ticket will need to be issued to the application. 1741 6.4.2.2 Unqualified locators 1743 If the locator is not qualified, then the locator information in the 1744 issued ticket contains a "not set" value. For instance, in the case 1745 the locator type is an index then the "not set" value may be -1 (all 1746 ones). The AMS forwarder in the upstream path of an end node may 1747 write a locator value into the locator information to make it 1748 qualified; most often this would just be its own locator value in 1749 cases where it is the first upstream hop of an end device that 1750 coincides with an AMS forwarder that provides location in the 1751 network. The implication is that this will be the locator used in the 1752 network overlay on the return path to reach the end node. Note that 1753 to write a locator into to a ticket requires that the ticket is in a 1754 modifiable Hop-by-Hop option. 1756 6.4.3 AMS forwarder processing and FAST 1758 Once an application has been issued a ticket with mapping information 1759 it will set the ticket in all packets sent to the peer node. The 1760 first hop upstream router, which might also be an AMS forwarder, in 1761 the FAST domain parses the ticket. 1763 If the ticket contains a qualified locator, the first hop node may 1764 validate it (as part of FAST ticket validation). If the ticket has 1765 unqualified locator information, the first hop node may set it to a 1766 qualified locator value in the packet. As described above, the 1767 locator information written is likely to be that corresponding to the 1768 locator of the first hop device which is an AMS forwarder. 1770 6.4.4 Transit to the peer 1771 Beyond the first hop router to the ultimate peer destination, no 1772 processing of mapping information in a ticket should be needed. 1773 Intervening networks and routers should deliver the ticket to the 1774 destination host unchanged. 1776 At the peer host, the procedures described in [FAST] are followed to 1777 save the received ticket in a flow context and to reflect it in 1778 subsequent packets. As with other reflected tickets, one containing 1779 mapping information is treated as an opaque value that is not parsed 1780 or modified by the peer or any network outside of the origin network. 1782 Packets sent by a peer will include reflected tickets for a flow. No 1783 processing of reflected mapping information in a ticket should be 1784 needed until the packet reaches the origin network of the ticket. 1785 Intervening networks and routers should deliver the ticket to the 1786 destination origin network unchanged. 1788 6.4.5 Ingress into the origin network 1790 At a border FAST router for the origin network, tickets are parsed 1791 and the encoded services are applied. If a ticket contains mapping 1792 information then the FAST router uses the information to perform 1793 overlay forwarding to the destination (the function of an AMS-F). 1794 Note that the FAST router performs no map query and does not need to 1795 maintain a mapping cache. 1797 The service parameters contained in the ticket may provide additional 1798 instructions about how the packet is to be sent over the network 1799 overlay. For instance, the service parameters might indicate the 1800 packet is encrypted or to use some extensions of an encapsulation 1801 protocol. 1803 6.4.6 Overlay termination 1805 When a forwarded packet is received at the targeted AMS-F, normal 1806 procedures for overlay termination and forwarding the packet on to 1807 its destination are done. 1809 At the end host, received reflected tickets are validated for 1810 acceptance as described in [FAST]. This is done by comparing the 1811 received ticket to that which was sent on the corresponding flow. 1813 6.4.7 Fallback 1815 The proposal described here is considered an optimization. Routing 1816 information in FAST tickets is not intended to completely replace a 1817 routing infrastructure. In particular, this solution relies on 1818 several parties to implement protocols correctly. For instance, the 1819 use of extension headers requires that they can be successfully sent 1820 through a network. As reported in [RFC7872], Internet support for 1821 forwarding packets with extension headers is not yet ubiquitous. 1823 Therefore, a fallback is required when encoding mapping information 1824 in FAST is not viable for a flow. The fallback in AMS is to route 1825 packets through AMS routers. 1827 6.4.8 Mobile events 1829 When a mobile node moves and its locator changes, it is desirable to 1830 converge to using the new locator as a quickly as possible. With 1831 tickets that contain locator information, a modified ticket needs to 1832 be sent to a peer host. 1834 If an application was issued a ticket with qualified locator 1835 information then a new ticket needs to be issued. This can be done by 1836 the application receiving a signal that a mobile event has occurred 1837 causing it to make new ticket requests for established flows. 1839 If an application has a ticket with an unqualified locator then the 1840 network should start writing the new locator information into packets 1841 that are sent by the application after the mobile event. This should 1842 be transparent to the application. 1844 Note that in either case, in order to update the tickets that a peer 1845 is reflecting, the application needs to send packets to the peer that 1846 includes an updated ticket. There is no guarantee when an application 1847 may send packets, so there is the possibility of a window where the 1848 peer node is sending reflected tickets with outdated locator 1849 information. The window should be limited by the expiration time of a 1850 ticket (see below), however it is recommended to implement mechanisms 1851 to avoid communication blackholes. For instance, a "care of address" 1852 mapping entry could be installed at the old locator node to forward 1853 to the new one. Such solutions are also used to mitigate database 1854 convergence time or cache synchronization time. 1856 6.4.9 Expired tickets 1858 FAST typically expects ticket to have an expiration time. If a ticket 1859 is received before the expiration time and is otherwise valid, then 1860 the packet is forwarded per the services indicated by the ticket. If 1861 a packet is received with an expired ticket, it might still be 1862 accepted subject to rate limiting. Accepting expired tickets is 1863 useful in the case that a connection goes idle and after some time 1864 the remote peer starts to send packets. 1866 For tickets that are expired and contain mapping information, a FAST 1867 node should ignore the mapping information and take the fallback 1868 path. When an application sends new packets, it can include a fresh 1869 ticket so that the fast path is taken on subsequent packets. Ignoring 1870 the mapping information in expired tickets puts an upper bound on the 1871 window that outdated information can be used. 1873 7 Privacy in Internet addresses 1875 This section discusses the interaction between the address mapping 1876 system and privacy in Internet addressing. The address mapping 1877 system can facilitate strong privacy in Internet addressing. 1878 [ADDRPRIV] discusses privacy in addressing. 1880 7.1 Criteria for privacy in addressing 1882 Per [ADDRPRIV], the ideal criteria for IPv6 addresses that provide 1883 strong privacy are: 1885 o Addresses are composed of a global routing prefix and a suffix 1886 that is internal to an organization or provider. This is the 1887 same property for IP addresses [RFC4291]. 1889 o The registry and organization of an address can be determined by 1890 the network prefix. This is true for any global address. The 1891 organizational bits in the address should have minimal hierarchy 1892 to prevent inference. It might be reasonable to have an internal 1893 prefix that divides identifiers based on broad geographic 1894 regions, but detailed information such as location, department 1895 in an enterprise, or device type should not be encoded in a 1896 globally visible address. 1898 o Given two addresses and no other information, the desired 1899 properties of correlating them are: 1901 o It can be inferred if they belong to the same organization 1902 and registry. This is true for any two global IP addresses. 1904 o It may be inferred that they belong to the same broad 1905 grouping, such as a geographic region, if the information is 1906 encoded in the organizational bits of the address. 1908 o No other correlation can be established. It cannot be 1909 inferred that the IP addresses address the same node, the 1910 addressed nodes reside in the same subnet, rack, or 1911 department, or that the nodes for the two addresses have any 1912 geographic proximity to one another. 1914 o Geographic location of a node cannot be deduced from an address 1915 with accuracy. 1917 o Given two observed addresses, no strong correlations can be 1918 drawn. In particular it must not be possible to correlate that 1919 two different flows originate from the same user. 1921 7.2 Achieving strong privacy 1923 Strong privacy in addressing can be achieved by using a different 1924 randomly generated identifier source address for each flow. 1925 Conceptually, this would entail that the network creates and assigns 1926 a unique and untrackable address to a host for every flow created by 1927 the host. 1929 In this scheme, each host would be assigned many addresses which are 1930 non-topological in the local network to both promote privacy and 1931 mobility. An identifier-locator protocol with an address mapping 1932 system can provide reachability. This would entail that the 1933 addressing mapping system contains a mapping entry for each ephemeral 1934 address. 1936 In large networks this solution presents an obvious scaling problem. 1937 Assigning an address per connection is a potential scaling problem on 1938 two accounts: 1940 o The amount of state needed in the address mapping system is 1941 significant. 1943 o Bulk host address assignment is inefficient. 1945 7.3 Scaling network state 1947 The amount of state necessary to assign each flow its own unique 1948 source IP address is equivalent, or at least proportional, to the 1949 amount of state needed for Carrier Grade NAT [RFC2663]-- basically 1950 this is one state element for every connection in the network. So in 1951 one sense this solution should scale as well as NAT has. 1953 7.3.1 Hidden aggregation 1955 A possible solution to reduce state is to make addresses aggregable, 1956 but use an aggregation method that is known only by the network 1957 provider and hidden to the rest of the world. The network could use a 1958 reversible hash or encryption function to create addresses. This 1959 method is called "hidden aggregation". 1961 The input to an address generation function includes a group 1962 identifier, a secret key, and a generation index. 1964 The address generation function may have the form: 1966 Address = Func(key, group_ident, gen) 1968 Where "key" is secret to network, "group_ident" is a group identifier 1969 for an aggregated set of addresses (for instance, the set of 1970 addresses for a device), and "gen" is generation number 0,1,2,... N. 1971 The generation value is changed for each invocation to create 1972 different addresses for assignment to a node. 1974 When a network ingress node is forwarded a packet it performs the 1975 inverse function on an address. 1977 The inverse function has the form: 1979 (group_ident, gen) = FuncInv(key, Address) 1981 The returned group_ident value is used as the identifier in the 1982 mapping lookup for a locator address. In this manner, the network can 1983 generate many addresses to assign to a node where they all share a 1984 single entry in the mapping system. 1986 7.3.2 Address format 1988 A possible address format for hidden aggregation is shown below. 1990 <------------ 64 bits ----------><--- 32 bits ---><--- 32 bits ---> 1991 +-------------------------------+----------------+----------------+ 1992 | Provider prefix | Key selector | Address bits | 1993 +-------------------------------+----------------+----------------+ 1995 Note the that provider prefix is not hidden, so the address does 1996 identify the network provider of a user. Key selector is an index 1997 into a table of keys. A key table should have at least 2^16 entries 1998 that are randomly generated and securely shared amongst AMS routers. 1999 Hosts can be assigned addresses in blocks based on a key, however the 2000 same key should be used for different hosts assignments and end hosts 2001 should be assigned blocks from different keys. 2003 The address bits are used to create unique addresses per key. A 2004 decoded address may contain a magic value to verify the hash 2005 function. 2007 Keys should be rotated periodically. Addresses assigned using a 2008 particular key will therefore have an expiration, the default 2009 expiration time should be one week (assuming one of 2^16 keys in 2010 table are rotated each minute). 2012 7.3.3 Practicality of hidden aggregation methods 2014 The premise of hidden aggregation is that only trusted devices in the 2015 network are able to decode the aggregation hidden within IPv6 2016 addresses. This implies that the network must keep secrets about the 2017 process. In the above examples, the secrets are keys used in the hash 2018 or encryption. The security of the key is then paramount, so 2019 techniques for key management, rotation, and using different key sets 2020 for obfuscation are pertinent. 2022 To perform a mapping lookup a node must apply the inverse address 2023 generation function to map addresses to their group identifiers. This 2024 lookup would occur in the critical data path so performance is 2025 important. Encryption and hashing are notoriously time consuming and 2026 computationally complex functions. 2028 Some possible mitigating factors for performance impact are: 2030 o The input to address generation functions is a small amount of 2031 data and has fixed size. The input is a key (presumably 128 or 2032 256 bits), part of all of an IPv6 address (128 bits), and a 2033 generation number (sixteen to twenty-four bits should work). 2035 o Given that the input is fixed size, specialized hardware might 2036 be used to optimize performance of the inverse address 2037 generation function. For instance, modern CPUs include 2038 instructions to perform crypto. Since the keys used in these 2039 functions are secret to the network and there are relatively few 2040 of them, they might be preloaded into a crypto engine to reduce 2041 setup costs. 2043 o The output of an inverse address generation function is 2044 cacheable. A cache on a device could contain address to locator 2045 mappings. When the inverse function and lookup on a group 2046 identifier are performed, a mapping of address to the discovered 2047 locator could be created in the cache. The node could then map 2048 addresses in subsequent packets sent on the same flow to the 2049 proper locator by looking up the address in the cache. 2051 7.4 Scaling bulk address assignment 2053 Assigning multiple addresses without aggregation is difficult to 2054 scale. Conceptually, each address would need to be individually 2055 specified in an assignment sent to a host. 2057 DHCPv6 might allow bulk singleton address assignment. As stated in 2058 [RFC7934]: 2060 Most DHCPv6 clients only ask for one non-temporary address, but 2061 the protocol allows requesting multiple temporary and even 2062 multiple non- temporary addresses, and the server could choose to 2063 provide multiple addresses. ... The maximum number of IPv6 2064 addresses that can be provided in a single DHCPv6 packet, given a 2065 typical MTU of 1500 bytes or smaller, is approximately 30. 2067 8 Address Mapping System in 5G networks 2069 The section describes applying AMS for use in 5G networks. AMS is 2070 instantiated as a function in the 5G services architecture described 2071 in [3GPP15]. 2073 8.1 Architecture 2075 The figure below depicts the use of AMS in a 5G reference point 2076 architecture. AMS is logically a network function and AMS interfaces 2077 to the 5G control plane via service based interfaces. 2079 Service Based Interfaces 2080 ----+-----+----+----+----+----+----+--------+----+-------- 2081 | | | | | | | | | 2082 +---+---+ | +--+--+ | +--+--+ | +--+--+ +--+--+ | 2083 | NSSF+ | | | NRF | | | DSF | | | UDM | | NEF | | 2084 +-------+ | +-----+ | +-----+ | +-----+ +-----+ | 2085 | | | | 2086 +----+--+ +--+--+ +---+--+ +-------------+--+ 2087 | AMF | | PCF | | AUSF | |AMS CP-SMF/GTPC | 2088 +---+-+-+ +-----+ +------+ +-+-----+--------+ ^ 2089 +-------+ | | | | | 2090 | 5G UE |-+ | +-----+ | +- N4 -+ 2091 +---+---+ | N2 | | | 2092 | | +-----+----+ +---+---+ V +----+ 2093 | | +------| AMS-F/R |--| AMS-R |------| DN | 2094 | | | N3 +-+---+--+-+ +-+-----+ +----+ 2095 | | | | | | | 2096 | +-+------+---+ +---+ +------+ 2097 +-----| gNB | N9 N9 2098 | +------------+ 2099 | +-----+----+ +---+---+ +----+ 2100 | +------| UPF |--| UPF |------| DN | 2101 | | N3 +-+---+--+-+ +-+-----+ +----+ 2102 | | | | | | 2103 | +----------+-+ +---+ +------+ 2104 +-----| gNB | N9 N9 2105 +------------+ 2107 AMS is used over the N3 and N9 interface. Address mappings in the 2108 downlink from the data network are done by an AMS-R. Transformations 2109 for edge traffic can be done by an AMS-F close to the gNB or by an 2110 AMS-R in the case of a cache miss. 2112 The control interface into AMS is via N4 interface that interacts 2113 with 5G network services. AMS Control Plane node (AMS-CP) uses 2114 RESTful APIs to make requests to network services (see section 8.3). 2115 An AMS-CP receives notifications when devices enter the network, 2116 leave it, or move within the network. The AMS-CP writes the address 2117 mapping entries accordingly. 2119 An AMS-CP communicates with other AMS-CPs, AMS-Fs, and AMS-Rs in the 2120 same address system mapping domain via control protocols that are 2121 independent of the 5G control plane. The address mapping database is 2122 shared amongst AMS-CP and AMS-Rs utilizing underlying distributed 2123 database technology deployed. 2125 8.2 Protocol layering 2127 The diagram below illustrates the protocol layers of packets sent 2128 over various data plane interfaces in the downlink direction of data 2129 network to a mobile node. Note that this assumes the topology shown 2130 above where GTP-U is used over N3 and IP routing is used on N9. 2132 ---> ---> ---> 2133 DN to AMS-R AMS-R to AMS-F AMS-F to gNB gNB to UE 2134 +-----------+ +-----------+ +------------+ +------------+ 2135 | Applic. | | Applic. | | Applic. | | Applic. | 2136 +-----------+ +-----------+ +------------+ +------------+ 2137 | L4 | | L4 | | L4 | | L4 | 2138 +-----------+ +-----------+ +------------+ +------------+ 2139 | IP | | IP | | IP | | PDU Layer | 2140 +-----------+ | +-----------+ | +------------+ +------------+ 2141 | L2 | | | L2 | | | GTP-U | | AN Protocol| 2142 +-----------+ | +-----------+ | +------------+ | Layers | 2143 | | | UDP/IP | | | 2144 N6 <--N9 --> N3 +------------+ +------------+ 2145 | L2 | 2146 +------------+ 2148 AMS and protocol layers in the Downlink core are depicted below. 2150 <--- <--- <--- 2151 AMS-H to VM AMS-F to AMS-H gNB to AMS-F UE to gNB 2152 +-----------+ +-----------+ +-----------+ +-----------+ 2153 | Applic. | | Applic. | | Applic. | | Applic. | 2154 +-----------+ +-----------+ +-----------+ +-----------+ 2155 | L4 | | L4 | | L4 | | L4 | 2156 +-----------+ +-----------+ +-----------+ +-----------+ 2157 | IP | | IP | | IP | | PDU Layer | 2158 +-----------+ | +-----------+ | +-----------+ +-----------+ 2159 | L2 | | | Overlay | | | GTP-U | |AN Protocol| 2160 +-----------+ | +-----------+ | +-----------+ | Layers | 2161 | | UDP/IP | | | UDP/IP | | | 2162 | +-----------+ +-----------+ 2163 | L2 | | L2 | 2164 +-----------+ +-----------+ 2166 8.3 Control plane between AMS and the network 2168 AMS is a consumer of several 5G network services. The service 2169 operations of interest to AMS are: 2171 o Nudm (Unified Data Management): Provides subscriber information. 2173 o Nsmf (Service Managment Function): Provides information about 2174 PDU sessions. 2176 o Namf (Core Access and Mobility Function): Provides notifications 2177 of mobility events. 2179 AMS-CP subscribes to notifications from network services. These 2180 notifications drive changes in the address mapping table. The service 2181 interfaces reference a UE by UE ID (SUPI or IMSI-Group Identifier), 2182 this is used as the key in the AMS identifier database to map UEs to 2183 addresses and identifier groups. Point of attachment is given by gNB 2184 ID, this is used as the key in the AMS locator database to map a gNB 2185 to an AMS-F and its locator. 2187 8.4 AMS and network slices 2189 The figure below illustrates the use of network slices with AMS. 2191 ----+-------------------------------------+-------------------- 2192 | | 2193 +-------------------------+ +----------------------------+ 2194 | +--------+ Slice | | +-------------+ Slice | 2195 | | SMF |-----+ #1 | | | AMS-CP |----+ #2| 2196 | +---+----+ | | | +-----------+-+ | | 2197 | N4 | | N4 | | | | | | 2198 | +---+--+ +--+----+ | | +--------+ | +--+----+ | +----+ 2199 | | UPF | | UPF | | | | AMS-F | | | AMS-R | |---| DN | 2200 | +-------+ +-------+ | | +--------+ | +-------+ | +----+ 2201 +-------------------------+ +--------------|-------------+ 2202 | | 2203 +--+-+ +------------|-------------+ 2204 | DN | | | Slice | 2205 +----+ | +------+----+ #3 | 2206 | | | | 2207 | +-------+ +-------+ | +----+ 2208 +-----+ | | AMS-F | | AMS-R | |---| DN | 2209 | MEC |----| +-------+ +-------+ | +----+ 2210 +-----+ +--------------------------+ 2212 In this figure, slice #1 illustrates legacy use of UPFs without AMS 2213 in a slice. AMS can be deployed incrementally or in parts of the 2214 network. As demonstrated, the use of network slices can provide 2215 domain isolation for this. 2217 Slice #2 supports AMS. Some number of AMS-Fs and AMS-Rs are deployed. 2218 Address transformations are performed over the N9 interface. AMS-Rs 2219 would be deployed at the N6 interface to perform address 2220 transformations on packets received from a data network. AMS-Fs will 2221 be deployed deeper in the network at one side of the N3 interface. 2222 AMS-Fs may be supplemented by AMS-Rs that are deployed in the 2223 network. AMS-CP manages the mapping database within the slice. 2225 Slice #3 shows another slice that supports AMS. In this scenario, the 2226 slice is for Mobile Edge Computing. The slice contains AMS-Rs and 2227 AMS-Fs, and as illustrated, it may also contain end hosts that run 2228 directly on edge computing servers. Note in this example, one AMS-CP, 2229 and hence one address mapping domain, is shared between slice #2 and 2230 slice #3. Alternatively, the two slices could each have their own 2231 AMS-CP and define separate address mapping domains. 2233 8.5 AMS in 4G networks 2235 The 4G architecture in 3GPP implements an address mapping system that 2236 is consistent with the architecture described in this document. 2237 Serving gateways have the role of AMS routers and GTP-C is the AMS 2238 routing protocol in 3GPP. 3GPP is based on an anchored routing model, 2239 however the protocol can be augmented with AMS forwarders to achieve 2240 anchorless routing bypass. Note that this can be done as an 2241 incremental addition to the 3GPP model, and in particular the core 2242 model and protocols of 3GPP, including GTP-C and GTP-U, require no 2243 change. The addition of AMS forwarders and mapping caches is done as 2244 an optimization for handling critical, low latency applications. 2246 8.6 Overlay forwarding methods in 5G networks 2248 As described in section 2.4, AMS forwarders may be implemented on 2249 servers. For instance, a mobile network may have server farms that 2250 provide VMs for running services close to users. For both performance 2251 and feasibility, it may be preferable for such servers to use an 2252 alternative overlay method than GTP. This document highlights that 2253 Generic UDP Encapsulation (UE) or Identifier Locator Addressing (ILA) 2254 may be good alternatives. GUE is a generic and extensible 2255 encapsulation protocol with good performance, ILA is 2256 identifier/locator split protocol that works with IPv6 and has very 2257 good performance. 2259 9 Security Considerations 2261 AMFP must have protection against message forgery. In particular 2262 secure redirects and mapping information message are required to 2263 prevent attacks by spoofing messages and illegitimately redirecting 2264 packets. This security is provided by using TCP connections so that 2265 origin of the messages is never ambiguous. 2267 Transport Layer Security (TLS) [RFC5246] MAY be used to provide 2268 secrecy, authentication, and integrity check for AMFP messages. The 2269 TCP Authentication Option [RFC5925] MAY be used to provide 2270 authentication for AMFP messages. 2272 10 IANA Considerations 2274 TBD 2276 11 Acknowledgments 2278 The authors would like to thank Dirk von Hugo for contributions to 2279 this document. 2281 12 References 2283 12.1 Normative References 2285 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 2286 (IPv6) Specification", STD 86, RFC 8200, DOI 2287 10.17487/RFC8200, July 2017, . 2290 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 2291 Architecture", RFC 4291, February 2006. 2293 12.2 Informative References 2295 [RFC7348] Mahalingam, M., Dutt, D., Duda, K., Agarwal, P., Kreeger, 2296 L., Sridhar, T., Bursell, M., and C. Wright, "Virtual 2297 eXtensible Local Area Network (VXLAN): A Framework for 2298 Overlaying Virtualized Layer 2 Networks over Layer 3 2299 Networks", RFC 7348, DOI 10.17487/RFC7348, August 2014, 2300 . 2302 [RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The 2303 Locator/ID Separation Protocol (LISP)", RFC 6830, DOI 2304 10.17487/RFC6830, January 2013, . 2307 [RFC6740] RJ Atkinson and SN Bhatti, "Identifier-Locator Network 2308 Protocol (ILNP) Architectural Description", RFC 6740, DOI 2309 10.17487/RFC6740, November 2012, . 2312 [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy 2313 Extensions for Stateless Address Autoconfiguration in 2314 IPv6", RFC 4941, DOI 10.17487/RFC4941, September 2007, 2315 . 2317 [RFC6462] Cooper, A., "Report from the Internet Privacy Workshop", 2318 RFC 6462, DOI 10.17487/RFC6462, January 2012, 2319 . 2321 [RFC7721] Cooper, A., Gont, F., and D. Thaler, "Security and 2322 Privacy Considerations for IPv6 Address Generation 2323 Mechanisms", RFC 7721, DOI 10.17487/RFC7721, March 2016, 2324 . 2326 [RFC7872] Gont, F., Linkova, J., Chown, T., and W. Liu, 2327 "Observations on the Dropping of Packets with IPv6 2328 Extension Headers in the Real World", RFC 7872, DOI 2329 10.17487/RFC7872, June 2016, . 2332 [RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address 2333 Translator (NAT) Terminology and Considerations", RFC 2334 2663, DOI 10.17487/RFC2663, August 1999, 2335 . 2337 [RFC7934] Colitti, L., Cerf, V., Cheshire, S., and D. Schinazi, 2338 "Host Address Availability Recommendations", BCP 204, RFC 2339 7934, DOI 10.17487/RFC7934, July 2016, . 2342 [RFC5246]] Dierks, T. and E. Rescorl, "The Transport Layer Security 2343 (TLS) Protocol Version 1.2", RFC 5246, DOI 2344 10.17487/RFC5246, August 2008, . 2347 [RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP 2348 Authentication Option", RFC 5925, DOI 10.17487/RFC5925, 2349 June 2010, . 2351 [GUE] Herbert, T., Yong, L., and Zia, O., "Generic UDP 2352 Encapsulation" draft-ietf-intarea-gue-06 2354 [GENEVE] Gross, J., Ed., Ganga, I. Ed., and Sridhar, T., "Geneve: 2355 Generic Network Virtualization Encapsulation", draft- 2356 ietf-nvo3-geneve-08 2358 [GTP] 3rd Generation Partnership Project (3GPP), "3GPP TS 2359 29.060", 2361 [ILA] Herbert, T., and Lapukhov, P., Privacy issues in 2362 ID/locator separation systems 2365 [NFV] ETSI Industry Specification Group (ISG) NFV, "ETSI GS NFV 2366 003 V1.2.1: Network Functions Virtualisation (NFV); 2367 Terminology for Main Concepts in NFV," 2014. 2368 . 2371 [ADDRPRIV] Herbert, T., "Privacy in IPv6 Network Prefix Assignment", 2372 draft-herbert-ipv6-prefix-address-privacy-00 2374 [IDLOCPRIV] Nordmark, E., "Privacy issues in ID/locator separation 2375 systems", draft-nordmark-id-loc-privacy-00 2377 [3GPP15] 3rd Generation Partnership Project (3GPP), "3GPP - 2378 Release 15", 2380 [BGPOLAY] Templin, F., Saccone, G., Dawra, G., Lindem, A., Moreno, 2381 V., "A Simple BGP-based Mobile Routing System for the 2382 Aeronautical Telecommunications Network", draft-templin- 2383 atn-bgp-08.txt 2385 [BGPILA] Lapukhov, P., "Use of BGP for dissemination of ILA 2386 mapping information" draft-lapukhov-bgp-ila-afi-02 2388 [FAST] Herbert, T., "Firewall and Service Tickets", draft- 2389 herbert-fast-03 2391 Authors' Addresses 2393 Tom Herbert 2394 Quantonium 2395 Santa Clara, CA 2396 USA 2398 Email: tom@quantonium.net 2400 Vikram Siwach 2402 Email: vsiwach@gmail.com