MAP-T

Index

  1. Introduction
  2. Foreword
  3. Thought Process
  4. The MAP Address Format
    1. End-user IPv6 Prefix
    2. Rule IPv6 Prefix
    3. EA-bits
    4. Subnet ID
    5. Interface ID
    6. 16 bits
    7. IPv4 address
    8. PSID
  5. CE Configuration
  6. CE Behavior
  7. BR Configuration
  8. BR Behavior
  9. Additional Configuration

Introduction

This document is a layman’s (but exhaustive) slightly sardonic explanation of MAP-T. It is intended to serve as a replacement for RFC 7599, or at least, as preparatory reading for it. I’m assuming you’ve already consumed the general introduction to the topic, so you know what you’re getting into.

Warning! This page is still under construction. It’s bound to change. Do not use it as reference.

Foreword

The MAP RFCs argue that, depending on how many IPv4 addresses you have, and how many you’re willing to assign to each CE, there are three different MAP-T scenarios:

  1. You have less IPv4 addresses than CEs, so your CEs will have to share IPv4 addresses.
  2. You have the same number of IPv4 addresses as CEs, so each CE will have one IPv4 address.
  3. You have more IPv4 addresses than CEs, thus you can assign more than one IPv4 address to each CE.

In my opinion, the first one is the only one that truly makes sense. (If you have that many IPv4 addresses, I think it’d be more straightforward to just add NAPTs to a SIIT-DC-2xlat scenario. Way simpler than dealing with MAP-T.) To simplify this document, most of it will assume you’re dealing with scenario 1.

But there’s nothing in Jool stopping you from using it to assemble scenarios 2 and 3. (All you have to do is reduce the PSID length to zero. The PSID will be explained later.)

Thought Process

In order to define your MAP-T network, you first need a general idea of how you’re going to distribute your available public transport addresses.

Suppose you have the entirety of block 192.0.2.0/24 to distribute among your CEs. Suppose, as well, that you have 5000 customers.

Considering that the size of your IPv4 address pool is 256 (because of “/24”), with a simple division (ceiling of (customers divided by pool size)) you will conclude that you need to fit 20 customers per address.

Therefore, each address needs to be divided into 20 “Sets” of ports. (But MAP-T likes powers of two, so we’ll have to round that up to 32.) We will assing each set to a different customer, and leftovers will be reserved for a future growth of our customer pool or whatever.

Warning! The following paragraph assumes a = 0 and m = 11. Don’t worry about this for now; a and m will be explained later.

So, we will divide each address into 32 sets of 2048 ports each (65536 / 32). The first set consists of ports 0-2047, the second set has 2048-4095, the third set has 4096-6143, and so on. The last set has 63488-65535.

With that in mind, I would like to introduce the notion of Embedded Address bits (“EA-bits”). It’s basically a CE identifier. (Each CE has a different one, except in scenario 3, in which every CE has several, but they’re still unique.) It’s composed of a concatenation of the suffix of the IPv4 address that has been assigned to the CE, as well as the identifier of its Port Set. In our example, we would need 8 bits for the suffix and 5 bits for the Port Set IDentifier (PSID):

Diagram: EA-bits

Note! The general introduction used to refer to EA-bits as “slice ID.”

Note! Only scenario 1 includes PSID. Port Sets only need to exist if the IPv4 addresses are being shared.

Let’s visualize all of that:

Network: EA-bits distribution

THE CONTENTS OF THIS BLOCK ARE NOT ACCURATE. IGNORE THIS BLOCK. WIP

<lies>

Note! You might be wondering why we’re crossing out Port Set 0.

One reason is that it contains port 0, which is invalid. Port zero should never be used on the wire.

Another reason is that it contains the system port range (1-1023), which everyone is scared of (for reasons that are likely obsolete, IMO).

MAP implementations are supposed to be hardcoded into always leaving Port Set 0 unused.

</lies>

Warning! The RFCs define a rather important notion called “MAP domain,” whose meaning is unfortunately significantly inconsistent across the specification. (Probably as a result of its evolution as the documents were written.)

For the purposes of this documentation, I’ve decided to go with the meaning that makes the most sense to me:

The diagram pictured above represents exactly one MAP domain. It’s a group of MAP devices (CEs and BR) that share a common essential configuration known as the Basic Mapping Rule (BMR).

Stick to the diagram for now; I will properly define the BMR later.

Once you’ve designed your own version of that, you’re ready to start assigning IPv6 prefixes to the CEs.

The MAP Address Format

Remember when I lied? Well, here’s the full IPv6 address format defined by the MAP proposed standard:

Diagram: MAP Address Format

The addresses that are supposed to follow this structure are all “assigned” to the CEs. (In their CE configuration, not their interface configuration.)

Here’s an explanation of every field:

End-user IPv6 Prefix

The CE’s unique prefix. All the traffic headed towards this prefix needs to be routed by the network towards the corresponding CE. It is interesting to note that this is actually the only part of the address that really matters; everything else is filler.

Rule IPv6 Prefix

This is just an arbitrary prefix owned by your organization, reserved for CE usage. (All CEs sharing a common MAP domain will have the same Rule IPv6 Prefix.)

Way I see it, if your organization is assigned 2001:db8::/48, you might for example assign something like 2001:db8:0:4464::/67 as your “Rule IPv6 prefix.” Each of your CEs needs to pick a subprefix from this pool to operate.

EA-bits

The CE’s unique identifier. It contains both the IPv4 address suffix and the PSID. See Thought Process above.

Subnet ID

This is a big fat hilariously overnamed nothing.

Perhaps this field makes more sense in the context of encapsulation (as MAP-T is a sibling technology to MAP-E, ie. “MAP-T but with Encapsulation instead of Translation”), but neither of the MAP RFCs have much to say about it.

As it stands, the Subnet ID is just an optional block of padding (zeroes) meant to ensure that the Interface ID starts in bit number 64. (Which, considering the Interface ID starts with padding, itself doesn’t really seem to serve any purpose.)

Interface ID

I’m guessing the length of IPv6 addresses left the MAP designers with too many surplus bits, and they decided to grant pointless purpose to the leftovers instead of leaving them in reserved status.

The Interface ID is just redundant data. It’s so unnecesary, in fact, that the End-user IPv6 Prefix is allowed to length up to 128 bits, an in order to accomplish this, it unapologetically overrides the Interface ID bits. (So, even if I stated in the diagram that the Interface ID lengths 64 bits, some of its leftmost bits might be chopped off.)

My guess is that this field only exists so that, given a MAP address, you can visually locate the CE’s public IPv4 address and PSID without having to analyze the EA-bits. (Assuming the former haven’t been chopped off.) (And you’ll still need to mentally convert the IPv4 address from hex to decimal.)

Note! Because they can be truncated, Jool doesn’t do anything with any of the Interface ID’s subfields. They simply exist. (Or not.)

Without further ado, the Interface ID is composed of three subfields:

16 bits

Just padding; sixteen zeroes with no meaning.

IPv4 address

Basically the full IPv4 address from which we extracted the EA-bits’s IPv4 address suffix subfield.

It’s also the NAPT’s public side address.

PSID

The CE’s PSID again, right-aligned and left-padded with zeroes for your viewing convenience. (I guess.)

CE Configuration

Note! Please note that, in this context, “CE” is used to refer to the translator mechanism exclusively (ie. Jool). The NAPT is assumed to be a separate tool, configured independently.

In addition to usually requiring a NAPT to really make sense, a “minimal” (not really) CE configuration contains

  1. The End-user IPv6 Prefix
  2. A Basic Mapping Rule (BMR)
  3. A Default Mapping Rule (DMR)

More configuration parameters are defined by the standards, but we’ll get to them later.

Mapping Rules are “always” (not really) triplets of the following form:

{
	<IPv6 Prefix>,
	<IPv4 Prefix>,
	<EA-bits length>
}

CEs sharing a MAP domain will have the same BMR and DMR. The End-user IPv6 prefix is the only configuration-wise distinction between them.

BMR

Warning! Because the definition of the BMR is intrinsically tied to the concept of a “MAP domain,” the BMR is also inconsistent across the RFCs. Once again, the definition presented here is my preferred one.

A MAP domain’s common MAP address configuration.

It refers specifically to addresses that will be governed by the MAP address format, not the RFC 6052 address format. Again, the BMR defines the base MAP address configuration that all CEs share, while the End-user IPv6 prefix describes the additional MAP address specifics that belong to one particular CE.

Here’s what each of the triplet fields stand for in the BMR:

{
	<Rule IPv6 Prefix>,
	<IPv4 prefix reserved for CEs>,
	<EA-bits length>
}

The “Rule IPv6 Prefix” is the same one defined above. The “IPv4 prefix reserved for CEs” is exactly what it sounds like (192.0.2.0/24 in the example). The “EA-bits length” is the length (in bits) of the EA-bits field.

So what does this do? Well, the suffix length of the IPv4 prefix reserved for CEs (p) (Yes, the suffix is called p, because of course it is) and the EA-bits length (o) describes the structure of the EA-bits, and the Rule IPv6 Prefix length describes their offset. If we define r as the length of the IPv4 prefix reserved for CEs,

  • If o + r > 32, we’re dealing with scenario 1. (And the length of the PSID field (q) is > 0.)
  • If o + r = 32, we’re dealing with scenario 2. (q = 0)
  • If o + r < 32, we’re dealing with scenario 3. (q = 0)

In our example, the BMR would be

{
	2001:db8:0:4464::/64,
	192.0.2.0/24,
	13
}

That pretty much covers what the BMR is and what you need to put in it. I feel, however, that here linger a couple of inevitable questions that should probably be addressed:

What’s with the redundant configuration?

If you stare at the CE configuration for long enough, you might notice that either the Rule IPv6 Prefix or the EA-bits length seems to be redundant. According to the MAP Address Format, the EA-bits length is the difference between the length of the End-user IPv6 prefix and the length of the Rule IPv6 prefix. Right? So, since the CE has both prefixes, we could do without it. Or better yet: The End-user IPv6 prefix always contains the Rule IPv6 prefix, and the difference is, why unsurprisingly, EA-bits length. So we could chop off the entire Rule IPv6 prefix and not miss anything.

Well, all of that is correct. Thing is, the BMR makes more sense when you look at the whole picture, rather than one CE configuration specifically. The BMR is not only shared by all CEs, but once we get to the BR, you will notice that we will also echo the BMR in its configuration, and the BMR’s fullness will make more sense there because the BR lacks End-user IPv6 prefixes.

Also, the BMR can be reused in the FMR (I’ll explain the FMR later), but only in its full representation.

You might therefore conclude that the End-user IPv6 prefix is actually the one cluttering up the configuration. In its stead, the EA-bits alone would suffice. But my guess is that this would make things look confusing if the EA-bits are not aligned to 8-bit boundaries. For example, if the Rule IPv6 Prefix is 2001:db8::/33, then EA-bits 101010102 would look like “AA16” in configuration, but the actual End-user IPv6 prefix would be “2001:db8:55::” (“55” being “AA” shifted one bit to the right). So specifying the End-user IPv6 prefix instead of the EA-bits looks more consistent with the actual addressing in these cases.

Jool will, however, let you skip the Rule IPv6 Prefix or the EA-bits length, or specify EA-bits instead of an End-user IPv6 prefix if you want.

Does the CE really need the BMR at all?

Not exactly. Though the BMR contains information that is formally essential to translate a MAP Address, there are situations in which a CE can infer (or obviate) each of the BMR fields.

This is, however, nonstandard behavior. Make of it what you will.

DMR

The Default Mapping Rule is just pool6. It’s the “default” prefix that should be added to an outbound destination address so the packet is routed by the IPv6 network towards the BR (and therefore, towards the IPv4 Internet).

{
	<pool6>,
	<unused>,
	<unused>
}

Yes, defining this as a “Mapping Rule” triplet is a stretch. Code-wise, it doesn’t even make sense to implement it as one.

In our example, the DMR would be

{
	64:ff9b::/96,
	<unused>,
	<unused>
}

CE Behavior

When one of the CE’s clients makes an outbound request, the CE uses the BMR and/or the End-user IPv6 prefix to translate the source address, and the DMR to translate the destination address.

Packet flow: CE outbound

Here’s the breakdown:

The opposite happens in the other direction:

Packet flow: CE inbound

BR Configuration

The BR needs two things:

  • A Forwarding Mapping Rule (FMR) table
  • The Default Mapping Rule (DMR)

The FMR table is a bunch of BMRs. One BMR per connected MAP domain.

In our example, the FMR would only have one entry:

IPv6 Prefix IPv4 Prefix EA-bits length
2001:db8:0:4464::/64 192.0.2.0/24 13

The DMR is, once again, pool6.

{
	64:ff9b::/96,
	<unused>,
	<unused>
}

BR Behavior

Packet flow: BR outbound

Source is translated by FMR, destination by DMR.

Packet flow: BR inbound

Source is translated by DMR, destination by FMR.

Additional Configuration

FMR on the CE

The CEs also have an FMR table. When an outgoing destination address matches one of the FMRs, the FMR is used as translation method instead of the DMR. This allows the clients of CEs to communicate directly with the clients of other CEs, without having to use the BR as a middleman.

(Again, each BMR in the FMR table allows communication to a different MAP domain.)

In fact, a CE’s BMR is usually added to its own FMR table. This allows clients from a MAP domain’s CE to speak directly with other clients from the same MAP domain, but different CE.

a, k and m

Warning! Under construction