MAP Configuration Guide

introduction introduction in the wave of transition from ipv4 to ipv6 networks, two primary conflicts persist ipv4 address exhaustion vs thriving ipv4 services the shortage of ipv4 addresses clashes with the continued vigorous development of ipv4 based services abundant ipv6 address space vs scarce ipv6 applications the vast address space of ipv6 stands in contrast to the relative lack of widespread ipv6 applications on the ipv4 front, address reuse techniques (such as a+p) have seemingly alleviated the pressure of rapid ipv4 depletion however, this requires significant investment in equipment and can adversely affect various applications to varying degrees regarding ipv6 development, the sensitivity to ipv4 address exhaustion differs among end users, icps (internet content providers), isps, and carriers, leading to an unbalanced development of the ipv6 ecosystem while all parties are actively promoting ipv6 adoption, they harbor certain reservations furthermore, these two conflicts are interconnected ipv4 address sharing mechanisms appear to slow down the development of the ipv6 industry chain, while the continuous evolution of the ipv6 ecosystem challenges the deployment scale of ipv4 sharing mechanisms to ensure the operation of existing ipv4 services while fostering the development of evolving ipv6 services, the 4over6 scenario has become a focal point for long term evolution strategy research, given its ability to accommodate both ipv4 and ipv6 services within the 4over6 framework, various transition technologies have emerged among them, the mapping of address and port (map) technology, which integrates stateless operation with dual translation/encapsulation techniques, has garnered significant attention as a leading ietf recommended solution definitions definitions map t is the abbreviation for mapping of address and port using translation it is defined as a stateless mapping and dual translation technology, and serves as an ipv6 transition technology within the 4over6 framework map e is the abbreviation for mapping of address and port using encapsulation it is defined as a stateless mapping and dual encapsulation technology, and serves as an ipv6 transition technology within the 4over6 framework architecture overview architecture overview the map technology combines stateless operation with dual translation/encapsulation techniques map (mapping of address and port) employs a stateless method for address and port multiplexing based on packet format, it is categorized into two types dual encapsulation map e and dual translation map t fundamentally, map defines a stateless mechanism for address encapsulation or translation, enabling the transport of both ipv4 and ipv6 services over an ipv6 only network the map domain, demarcated by border devices (map ce and map br), is designed such that native ipv4 traffic resides exclusively outside its boundaries map e / map t packet processing flow map e / map t packet processing flow within the map domain, the network deploys an ipv6 only protocol stack traffic originating from ipv6 endpoints is natively carried over ipv6 for traffic from ipv4 endpoints, an ipv6 tunnel must be established between a map ce and a map br, or between two map ces depending on the method used to handle the ipv4 packets, the technology is categorized as either map e or map t map t (translation) employs a translation method the ipv4 header is translated into an ipv6 header, resulting in a packet with only a single ipv6 header map e (encapsulation) employs an encapsulation method the original ipv4 packet is encapsulated with an additional ipv6 header, resulting in an outer ipv6 header and an inner ipv4 header map t data processing flow map e data processing flow map e / map t packet processing flow map e / map t packet processing flow address mapping address mapping address mapping between ipv4 and ipv6 is achieved by embedding specific portions of the ipv4 address and the port set identifier into an ipv6 address the selected characteristic part from the ipv4 address is the ipv4 addr suffix, and from the port set is the port set identifier (psid) this process establishes a direct binding between the ipv4 address/port information and the ipv6 address, forming a stateless mapping as illustrated in the preceding diagram depicting the mapping relationship between ipv4+port and ipv6 addresses, the public ipv4 address and port set can be derived seamlessly by any node (whether a map ce or map br) possessing the following key parameters end user ipv6 prefix (essential for obtaining the psid) rule ipv6 prefix ea bits length rule ipv4 prefix psid offset note the length of the subnet id is typically defined as 0 furthermore, for a map ce device, if the end user ipv6 prefix is longer than /64, it will override the interface id the map technology constructs a unique identifier for a map ce within the map domain by combining the ipv4 address and the port set id to form the interface id this interface id is then appended to the end user ipv6 prefix to synthesize a complete ipv6 address, which serves as the unique identifier for the map ce the interface id can be formed using one of two methods rfc compliant method the higher order 16 bits are set to zero, combined with the ipv4 address field and the port set id field draft compliant method the higher order 8 bits and the lower order 8 bits are set to zero, combined with the ipv4 address field and the port set id field ipv4 address field rules if a public ipv4 address is assigned, the ipv4 address field is filled with this assigned address (32 bits in length) if an ipv4 prefix is assigned (e g , to an enterprise user), the ipv4 address field must be right padded with zeros to 32 bits example if the assigned prefix is 1 1 1 0/29, the ipv4 address field must be set to 0x01010100 (in hexadecimal) port set id field rules if the port set id value extracted from the ea bits is less than 16 bits, it is right padded with zeros to form a 16 bit field example a port set id of 0xac becomes 0xac00 if an ipv4 prefix or a dedicated public ipv4 address is assigned (meaning no port sharing), there is no extractable port set id value in this case, the port set id field is set to 0x0000 through this process, a stateless, strong binding is established between the ipv4 address/port set of a user and their corresponding ipv6 address within the map domain this binding enables the synthesized ipv6 address to uniquely identify the user across the entire map infrastructure port mapping port mapping the "a+p" concept from the perspective of ipv4 addresses and transport layer ports, the 32 bit ipv4 address space is limited in contrast, the 16 bit transport layer port space is currently underutilized therefore, the "a+p" (address plus port) model was introduced, which effectively extends the ipv4 address space by sharing public ipv4 addresses and partitioning the transport port space the map framework adopts this "a+p" concept, mapping a combination of a public ipv4 address and a port set to a private ipv4 address within map, the 16 bit transport layer port number is divided into three distinct fields a, port set id (psid), and m regarding a and a the port range 0 1023 is reserved for well known ports in map, this reserved range is recommended to be extended to 0 4095 (comprising 2¹² ports) this corresponds to a default recommended value of a = 4 (calculated as 16 total bits 12 reserved bits = 4) the a parameter generally takes a non zero value if a = 0, it indicates that the entire port range is available for allocation regarding port set id (psid) and k the length k of the port set id (psid) determines the sharing ratio the ratio value r = 2^k this means the transport layer port space is divided into 2^k distinct subsets, each allocated to a different cpe (customer premises equipment) sharing the same public ipv4 address each cpe sharing the ipv4 address is assigned a unique psid, which corresponds to a unique port set regarding m and m the length m of the m field determines the contiguous length of ports within a single port set the contiguous length is 2^m through this division scheme a total of 2^k port sets are made available each port set is identified by a unique psid value the number of ports contained within each psid's port set is ((2^a) 1) (2^m) example map mapping rule given a sharing ratio of r=1024 and a=4, we can derive m=2 since each port set is non contiguous, the following table segments them for clarity taking psid=0 as an example when the prefix a is 0001 (listed as contiguous segment 1 in the table), the corresponding ports are 0001000000000000 (4096) 0001000000000001 (4097) 0001000000000010 (4098) 0001000000000011 (4099) when the prefix a is 0010 (listed as contiguous segment 2), the corresponding ports are 0010000000000000 (8192) 0010000000000001 (8193) 0010000000000010 (8194) 0010000000000011 (8195) this pattern continues for all possible values of a, establishing the complete correspondence between the psid and its assigned port set true 66,163 09347355397458,167 94862168504775,70 95343697122804,194 00446778974964#4283c7 unhandled content type #4283c7 unhandled content type #4283c7 unhandled content type #4283c7 unhandled content type #4283c7 unhandled content type unhandled content type unhandled content type unhandled content type unhandled content type unhandled content type #d8e5f5 unhandled content type #d8e5f5 unhandled content type #d8e5f5 unhandled content type #d8e5f5 unhandled content type #d8e5f5 unhandled content type unhandled content type unhandled content type unhandled content type unhandled content type unhandled content type #d8e5f5 unhandled content type #d8e5f5 unhandled content type #d8e5f5 unhandled content type #d8e5f5 unhandled content type #d8e5f5 unhandled content type unhandled content type unhandled content type unhandled content type unhandled content type unhandled content type #d8e5f5 unhandled content type #d8e5f5 unhandled content type #d8e5f5 unhandled content type #d8e5f5 unhandled content type #d8e5f5 unhandled content type mapping rule definitions mapping rule definitions the map technology utilizes three primary mapping rules bmr (basic mapping rule) fmr (forwarding mapping rule) dmr (default mapping rule) note within the map e context, the dmr is also referred to as the rule for handling "destinations outside the map domain" in the current implementation of the device's map feature, the fmr is functionally consistent with the bmr and does not require separate configuration basic mapping rule (bmr)(mandatory) basic mapping rule (bmr)(mandatory) the basic mapping rule (bmr) is used to calculate the map customer edge (ce) device's ipv4 address, port set, and ipv6 address its primary function is to define the mapping relationship between an ipv6 address and the corresponding "ipv4 address + port" combination on the map ce the bmr is used to perform nat44 translation on user ipv4 packets subsequently, it governs the encapsulation (for map e) or translation (for map t) of these translated packets into ipv6 format for transmission across the map domain on the map br the bmr is applied to decapsulate (map e) or translate (map t) incoming ipv6 packets back into ipv4 for return traffic, the br uses the same rule to re encapsulate or re translate the ipv4 packets into ipv6 and forwards them within the map domain towards the appropriate map ce based on ipv6 routing the packets are then forwarded within the map domain to the destination map ce via ipv6 routing the fundamental parameters required for configuring the bmr include rule ipv6 prefix rule ipv4 prefix ea bits length psid offset by configuring these parameters on a map ce, the shared ipv4 address, the corresponding port set, and the map ce's own ipv6 address can be algorithmically derived the map domain can be logically partitioned into multiple sub domains based on ipv4 subnets, where each ipv4 subnet segment constitutes a sub domain this architecture allows the mapping rule (mr) configuration for all map ces within a sub domain to be simplified to a single, shared bmr each map ce within the same sub domain is configured with a unique end user ipv6 prefix but the same bmr forwarding mapping rule (fmr)(optional) forwarding mapping rule (fmr)(optional) in the current device implementation, the fmr is functionally aligned with the bmr and does not require separate configuration a detailed description is not provided at this time default mapping rule (dmr)(optional) default mapping rule (dmr)(optional) map t the default mapping rule (dmr) handles packets whose destination ipv4 address lies outside the map domain these packets are forwarded by the map br to external networks the dmr contains two parameters rule ipv6 prefix this is the ipv6 prefix of the map br rule ipv4 prefix this value is set to 0 0 0 0/0, making this rule function as the default route for ipv4 route matching on the map ce as illustrated in the figure below, when this rule is applied, the destination ipv6 address is formed by combining the dmr's rule ipv6 prefix with the original destination ipv4 address map e the rule is explicitly named "destinations outside the map domain", which more directly conveys its purpose in map e, where an ipv6 header encapsulates the original ipv4 packet, handling traffic destined outside the map domain simply requires adding an outer ipv6 header with the br's address when this packet arrives at the map br, the device only needs to remove (decapsulate) the outer ipv6 header to reveal the original destination ipv4 address therefore, for map e, configuring the "destinations outside the map domain" rule essentially means configuring the ipv6 address of the map br map configuration map configuration enable map globally enable map globally true 157,331 3574660633484,173 6425339366516 left #4283c7 unhandled content type left #4283c7 unhandled content type left #4283c7 unhandled content type left unhandled content type left unhandled content type left unhandled content type left #d8e5f5 unhandled content type left #d8e5f5 unhandled content type left #d8e5f5 unhandled content type configure map rules configure map rules true 157,331 3574660633484,173 6425339366516#4283c7 unhandled content type #4283c7 unhandled content type #4283c7 unhandled content type unhandled content type unhandled content type unhandled content type #d8e5f5 unhandled content type #d8e5f5 unhandled content type #d8e5f5 unhandled content type unhandled content type unhandled content type unhandled content type #d8e5f5 unhandled content type #d8e5f5 unhandled content type #d8e5f5 unhandled content type 1 1 unhandled content type 1 1 unhandled content type 1 1 unhandled content type #d8e5f5 1 1 unhandled content type #d8e5f5 1 1 unhandled content type #d8e5f5 1 1 unhandled content type create a map domain create a map domain true 229,292 6719821816826,140 3280178183174#4283c7 unhandled content type #4283c7 unhandled content type #4283c7 unhandled content type unhandled content type unhandled content type unhandled content type #d8e5f5 unhandled content type #d8e5f5 unhandled content type #d8e5f5 unhandled content type unhandled content type unhandled content type unhandled content type bind a map rule bind a map rule 183,304 8256115547425,174 17438844525748#4283c7 unhandled content type #4283c7 unhandled content type #4283c7 unhandled content type unhandled content type unhandled content type unhandled content type #d8e5f5 unhandled content type #d8e5f5 unhandled content type #d8e5f5 unhandled content type unhandled content type unhandled content type unhandled content type #d8e5f5 unhandled content type #d8e5f5 unhandled content type #d8e5f5 unhandled content type 1 1 unhandled content type 1 1 unhandled content type 1 1 unhandled content type display and maintenance display and maintenance true 256,257 6244343891403,148 37556561085972#4283c7 unhandled content type #4283c7 unhandled content type #4283c7 unhandled content type unhandled content type unhandled content type unhandled content type #d8e5f5 unhandled content type #d8e5f5 unhandled content type #d8e5f5 unhandled content type unhandled content type unhandled content type unhandled content type #d8e5f5 unhandled content type #d8e5f5 unhandled content type #d8e5f5 unhandled content type unhandled content type unhandled content type unhandled content type configuration example configuration example network requirements network setup and ipv4 ipv6 address translation validation (using map e br as an example) configure basic ip addresses on the device ports (ethernet13 towards the ipv4 side, ethernet14 towards the ipv6 side) ensure the server ports are directly connected to the corresponding device ports sonic(config)# interface ethernet 13 sonic(config if 13)# ip address 192 0 2 1/24 sonic(config if 13)# interface ethernet 14 sonic(config if 14)# ip address 2001\ db8 1012 1234 1/64 enable the map e br functionality on the port sonic(config)# interface ethernet 13 sonic(config if 13)# nat64 map zone br enable sonic(config if 13)# interface ethernet 14 sonic(config if 14)# nat64 map zone br enable configure a map rule and bind it to the map domain sonic(config)# map rule basic mapping rule bmr rule ip6 prefix 2001\ db8 1012 /48 rule ip4 prefix 192 0 2 0/24 ea length 16 psid len 8 psid offset 4 sonic(config)# map rule br ipv6 address braddr ipv6 address 2001\ db8 1012 1234 10/64 sonic(config)# map e domain test1 br sonic(config map e domain test1)# basic mapping rule bmr sonic(config map e domain test1)# br ipv6 address braddr verify configuration send ipv4/ipv6 test traffic as per the configuration the packets should be forwarded correctly with full connectivity