LISP Canonical Address Format (LCAF)
There are two primary numbering spaces in the LISP architecture: EIDs and RLOCs. These addresses are either 32-bit for IPv4 or 128-bit for IPv6 and are encoded inside a LISP control message. Current deployment of LISP allows for only IPv4 and IPv6 AFI encodings, but other arbitrary address family identifier (AFI) values may need encodings for LISP to support them. To support such arbitrary AFIs, LISP introduced LISP Canonical Address Format (LCAF), defined in RFC 8060. IANA has assigned the AFI value 0x4003 (16387) to the LCAF.
The LCAF information gets encoded inside the LISP header. The initial 6 bytes of the canonical address are as follows (see Figure 2-6):
2-byte AFI field: Set to 16387.
1-byte Rsvd1 field: Reserved for future use. Set to 0.
1-byte Flags field: For future use. Set to 0.
1-byte Type field: Canonical Address Format encodings.
1-byte Rsvd2 field: Reserved for future use. Set to 0.
)
FIGURE 2-6 Canonical Address Header
The Length field is a 2-byte field that holds the value, in bytes. The value of this field represents canonical address payload starting with and including the byte after the Length field.
The Type field can contain various values that represent the kinds of information encoded in the LISP canonical address. The various approved and unapproved values and their use cases are as follows:
Type 0 (null body): In this case, the size of the Length field is set to 0 (that is, no other fields are part of the LCA payload). If the Length field is set to 0, the minimum length of the LCAF-encoded address will be either 8 bytes or 6 bytes, based on whether the AFI value is encoded as part of the LCA.
Type 1 (AFI list): The AFI List LCAF type is used in DNS names or URIs as ASCII strings when such information is part of the mapping database system.
Type 2 (instance ID): The instance IDs can be useful for creating multi-segmented VPNs within a LISP site. When the organizations inside LISP sites are using private addressing, the instance ID can help segregate those addresses.
Type 3 (AS number): Type 3 is used to encode the AS number in the canonical address when the AS number is stored in the mapping database.
Type 4 (application data): This type is unapproved.
Type 5 (geo-coordinates): If the RLOCs are geographically displaced, an ETR may want to send the geographic location in the map reply. In such cases, the ETR sends the LCAF Type 5 with the RLOC’s physical location (latitude and longitude) in its locator set. Figure 2-7 shows a geo-coordinates LCAF.
)
FIGURE 2-7 Geo-Coordinates LCAF
Type 7 (NAT traversal): Usually enterprises deploy network address translation (NAT) devices in their networks for security purposes. If a LISP system traverses a NAT device, it is required to convey the global address and mapped port information. In such instances, the NAT traversal LCAF type is used. Figure 2-8 shows a NAT traversal LCAF.
)
FIGURE 2-8 NAT Traversal LCAF
Type 9 (multicast info): The distributed mapping database holds multicast group information. If an ITR requests an information on a multicast group address EID, the MS may return a replication list of RLOC group addresses or RLOC unicast addresses. A multicast info LCAF allows for encoding of multicast group information for a given VPN as well. For a given VPN, the mapping database holds the three-tuple entry (Instance ID, S-Prefix, G-prefix), where S-Prefix represents the source EID and G-Prefix represents the group EID.
Type 10 (explicit locator path): Traffic engineering (TE) is the key to ensuring proper network and link utilization. The LISP control messages can be encoded with the explicit locator path (ELP) LCAF type to provide explicit re-encapsulation paths for a given EID prefix lookup in the mapping database to ensure that certain hops are traversed in order to reach a particular destination host. Figure 2-9 shows the ELP LCAF.
)
FIGURE 2-9 Explicit Locator Path LCAF
Type 11 (security key): When a locator has a security key associated with it, it needs to be securely transmitted across the LISP system and over the Internet. The security key LCAF is used to encode the key material of the security key.
Type 12 (source/dest key): Usually all the mapping database lookups are based on the destination EID prefix. But if the xTR requires a lookup based on a particular flow (for example, based on two-tuple entry of a source/destination pair), this LCAF type is used in the LISP control messages.
Type 13 (replication list entry): The replication list entry LCAF encodes the locator being used for the unicast replication for multicast forwarding, as pointed by the multicast info LCAF. This locator entry is registered by the re-encapsulating tunnel routers that are participating in the overlay distribution tree.