1.1.Requirements Language

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14[RFC2119][RFC8174] when, and only when, they appear in all capitals, as shown here.¶

3.1.Initial Registration

Initial registration is performed when an MN attaches to a network for the firsttime (rather than attaching to a new network after moving from a previous one).¶

In this description (shown inFigure 1), it is assumed that:¶

1. The MN is attaching to MAAR1.¶
2. The MN is authorized to attach to the network.¶

Upon MN attachment, the following operations take place:¶

1. MAAR1 assigns a global IPv6 prefix from its own prefix pool to the MN (Pref1).It also stores this prefix (Pref1) in the locally allocated temporary BCE.¶
2. MAAR1 sends a PBU[RFC5213] with Pref1 and the MN's MN-ID to theCMD.¶
3. Since this is an initial registration, the CMD stores a BCE containing theMN-ID, Pref1, and MAAR1's address (as a Proxy-CoA) as the primary fields.¶
4. The CMD replies with a PBA with the usual options defined in PMIPv6[RFC5213], meaning that the MN's registration is fresh and no paststatus is available.¶
5. MAAR1 stores the BCE described in (1) and unicasts a Router Advertisement (RA) tothe MN with Pref1.¶
6. The MN uses Pref1 to configure an IPv6 address (IP1) (e.g., with statelessaddress autoconfiguration (SLAAC)).¶

Note that:¶

1. Alternative IPv6 autoconfiguration mechanisms can also be used, though thisdocument describes the SLAAC-based one.¶
2. IP1 is routable at MAAR1 in the sense that it is on the path of packetsaddressed to the MN.¶
3. MAAR1 acts as a plain router for packets destined to the MN as no encapsulationor special handling takes place.¶

In the diagram shown inFigure 1 (and subsequent diagrams),the flow of packets is presented using '*'.¶

  +-----+      +---+                +--+  |MAAR1|      |CMD|                |CN|  +-----+      +---+                +*-+     |           |                   *    MN           |                   *     +---+  attach.        |               *****    _|CMD|_detection        |         flow1 *       / +-+-+ \     |           |               *      /    |    \ local BCE       |               *     /     |     \ allocation      |               *    /      |      \     |--- PBU -->|           +---*-+-'    +--+--+    `+-----+     |          BCE          |   * |      |     |     |     |     |        creation       |MAAR1+------+MAAR2+-----+MAAR3|     |<-- PBA ---|           |   * |      |     |     |     | local BCE       |           +---*-+      +-----+     +-----+ finalized       |               *     |           |         Pref1 *     |           |              +*-+     |           |              |MN|     |           |              +--+  Operations sequence                  Packet flow

Note that the registration process does not change regardless of the CMD's modes(relay, locator, or proxy) described in the following sections. The procedure is depicted inFigure 1.¶

3.2.The CMD as PBU/PBA Relay

Upon MN mobility, if the CMD behaves as a PBU/PBA relay, the following operations take place:¶

1. When the MN moves from its current point of attachment and attaches to MAAR2(now the S-MAAR), MAAR2 reserves an IPv6 prefix (Pref2), stores a temporaryBCE, and sends a PBU to the CMD for registration.¶
2. Upon PBU reception and BC lookup, the CMD retrieves an already existing entryfor the MN and binds the MN-ID to its former location; thus, the CMD forwards thePBU to the MAAR indicated as Proxy-CoA (MAAR1) and includes a new mobility optionto communicate the S-MAAR's global address to MAAR1 (defined as the Serving MAARoption inSection 4.6). The CMD updates the P-CoA field inthe BCE related to the MN with the S-MAAR's address.¶
3. Upon PBU reception, MAAR1 can install a tunnel on its side towards MAAR2 and therelated routes for Pref1. Then MAAR1 replies to the CMD with a PBA (includingthe option mentioned before) to ensure that the new location has successfullychanged. The PBA contains the prefix anchored at MAAR1 in the Home Network Prefixoption.¶
4. The CMD, after receiving the PBA, updates the BCE and populates an instanceof the P-MAAR list. The P-MAAR list is an additional field on the BCE thatcontains an element for each P-MAAR involved in the MN's mobility session. Thelist element contains the P-MAAR's global address and the prefix it hasdelegated. Also, theCMD sends a PBA to the new S-MAAR, which contains the previous Proxy-CoA and theprefix anchored to it embedded into a new mobility option called the Previous MAARoption (defined inSection 4.5). Then, upon PBAarrival, a bidirectional tunnel can be established between the two MAARs, andnew routes are set appropriately to recover the IP flow(s) carrying Pref1.¶
5. Now, packets destined for Pref1 are first received by MAAR1, encapsulated into thetunnel, and forwarded to MAAR2, which finally delivers them to their destination.In the uplink, when the MN transmits packets using Pref1 as a source address, they aresent to MAAR2 (as it is the MN's new default gateway) and then tunneled to MAAR1, whichroutes them towards the next hop to the destination. Conversely, packets carryingPref2 are routed by MAAR2 without any special packet handling both for the uplinkand downlink.¶

+-----+      +---+      +-----+           +--+            +--+|MAAR1|      |CMD|      |MAAR2|           |CN|            |CN|+-----+      +---+      +-----+           +*-+            +*-+   |           |           |               *               *   |           |          MN               *     +---+     *   |           |        attach.        *****    _|CMD|_    *   |           |          det.   flow1 *       / +-+-+ \   *flow2   |           |<-- PBU ---|           *      /    |    \  *   |          BCE          |           *     /     | *******   |        check+         |           *    /      | *    \   |        update         |       +---*-+-'    +--+-*+    `+-----+   |<-- PBU*---|           |       |   * |      |    *|     |     |route          |           |       |MAAR1|______|MAAR2+-----+MAAR3|update         |           |       |   **(______)**  *|     |     |   |--- PBA*-->|           |       +-----+      +-*--*+     +-----+   |         BCE           |                      *  *   |        update         |                Pref1 *  *Pref2   |           |--- PBA*-->|                     +*--*+   |           |         route         ---move-->|*MN*|   |           |         update                  +----+      Operations sequence                  Data Packet flowPBU/PBA messages with * contain     a new mobility option

For MN's next movements, the process is repeated, but the number of P-MAARsinvolved increases (according to the number of prefixes that the MN wishes tomaintain). Indeed, once the CMD receives the first PBU from the new S-MAAR, itforwards copies of the PBU to all the P-MAARs indicated in the BCE, namely theP-MAAR registered as the current P-CoA (i.e., the MAAR prior to handover) plus the onesin the P-MAAR list. Those P-MAARs reply with a PBA to the CMD, whichaggregates all of the PBAs into one PBA to notify the S-MAAR, which finally can establish the tunnelswith the P-MAARs.¶

It should be noted that this design separates the mobility management at theprefix granularity, and it can be tuned in order to erase old mobility sessionswhen not required, while the MN is reachable through the latest prefix acquired.Moreover, the latency associated with the mobility update is bound to the PBA sentby the furthest P-MAAR, in terms of RTT, that takes the longest time to reachthe CMD. The drawback can be mitigated by introducing a timeout at the CMD, bywhich, after its expiration, all the PBAs so far collected are transmitted, andthe remaining are sent later upon their arrival. Note that, in this case, theS-MAAR might receive multiple PBAs from the CMD in response to a PBU. The CMDSHOULD follow the retransmissions and rate-limiting considerations described inSection 3.6, especially when aggregating and relayingPBAs.¶

When there are multiple P-MAARs, e.g., k MAARs, a single PBU received bythe CMD triggers k outgoing packets from a single incoming packet. This may leadto packet bursts originating from the CMD, albeit to different targets. PacingmechanismsMUST be introduced to avoid bursts on the outgoing link.¶

3.3.The CMD as MAAR Locator

The handover latency experienced in the approach shown before can be reduced ifthe P-MAARs are allowed to directly signal their information to the new S-MAAR.This procedure reflects what was described inSection 3.2 upto the moment the P-MAAR receives the PBU with the Serving MAAR option. At that point,a P-MAAR is aware of the new MN's location (because of the S-MAAR's address inthe Serving MAAR option), and, besides sending a PBA to the CMD, it also sends a PBAto the S-MAAR, including the prefix it is anchoring. This latter PBA does notneed to include new options, as the prefix is embedded in the HomeNetwork Prefix (HNP) option and theP-MAAR's address is taken from the message's source address. The CMD isreleased from forwarding the PBA to the S-MAAR as the latter receives a copy directlyfrom the P-MAAR with the necessary information to build the tunnels and set theappropriate routes.Figure 3 illustrates the new messagesequence. The data forwarding is unaltered.¶

+-----+      +---+      +-----+           +--+            +--+|MAAR1|      |CMD|      |MAAR2|           |CN|            |CN|+-----+      +---+      +-----+           +*-+            +*-+   |           |           |               *               *   |           |          MN               *     +---+     *   |           |        attach.        *****    _|CMD|_    *   |           |          det.   flow1 *       / +-+-+ \   *flow2   |           |<-- PBU ---|           *      /    |    \  *   |          BCE          |           *     /     | *******   |        check+         |           *    /      | *    \   |        update         |       +---*-+-'    +--+-*+    `+-----+   |<-- PBU*---|           |       |   * |      |    *|     |     |route          |           |       |MAAR1|______|MAAR2+-----+MAAR3|update         |           |       |   **(______)**  *|     |     |   |--------- PBA -------->|       +-----+      +-*--*+     +-----+   |--- PBA*-->|         route                    *  *   |          BCE        update             Pref1 *  *Pref2   |         update        |                     +*--*+   |           |           |           ---move-->|*MN*|   |           |           |                     +----+       Operations sequence                  Data Packet flowPBU/PBA messages with * contain     a new mobility option

3.4.The CMD as PBU/PBA Proxy

A further enhancement of previous solutions can be achieved when the CMD sendsthe PBA to the new S-MAAR before notifying the P-MAARs of the location change.Indeed, when the CMD receives the PBU for the new registration, it is already inpossession of all the information that the new S-MAAR requires to set up thetunnels and the routes. Thus, the PBA is sent to the S-MAAR immediately after aPBU is received, including the Previous MAAR option in this case. In parallel, aPBU is sent by the CMD to the P-MAARs containing the Serving MAAR option to notifythem about the new MN's location so that they receive the information to establishthe tunnels and routes on their side. When P-MAARs complete the update, theysend a PBA to the CMD to indicate that the operation has concluded and theinformation is updated in all network nodes. This procedure is obtained fromthe first procedure rearranging the order of the messages, but the parameterscommunicated are the same. This scheme is depicted inFigure 4, where, again, the data forwarding is kept untouched.¶

+-----+      +---+      +-----+           +--+            +--+|MAAR1|      |CMD|      |MAAR2|           |CN|            |CN|+-----+      +---+      +-----+           +*-+            +*-+   |           |           |               *               *   |           |          MN               *     +---+     *   |           |        attach.        *****    _|CMD|_    *   |           |          det.   flow1 *       / +-+-+ \   *flow2   |           |<-- PBU ---|           *      /    |    \  *   |          BCE          |           *     /     | *******   |        check+         |           *    /      | *    \   |        update         |       +---*-+-'    +--+-*+    `+-----+   |<-- PBU*---x--- PBA*-->|       |   * |      |    *|     |     |route          |         route     |MAAR1|______|MAAR2+-----+MAAR3|update         |         update    |   **(______)**  *|     |     |   |--- PBA*-->|           |       +-----+      +-*--*+     +-----+   |          BCE          |                      *  *   |         update        |                Pref1 *  *Pref2   |           |           |                     +*--*+   |           |           |           ---move-->|*MN*|   |           |           |                     +----+       Operations sequence                 Data Packet flowPBU/PBA messages with * contain     a new mobility option

3.5.De-registration

The de-registration mechanism devised for PMIPv6 cannot be used as is in thissolution because each MAAR handles an independent mobilitysession (i.e., a single prefix or a set of prefixes) for a given MN, whereas theaggregated session is stored at the CMD. Indeed, if a P-MAAR initiatesa de-registration procedure because the MN is no longer present on the MAAR'saccess link, it removes the routing state for the prefix(es), thatwould be deleted by the CMD as well, hence defeating any prefix continuityattempt. The simplest approach to overcome this limitation is to deny a P-MAARto de-register a prefix, that is, allowing only an S-MAAR to de-registerthe whole MN session. This can be achieved by first removing any L2detachment event so that de-registration is triggered only when the bindinglifetime expires, hence providing a guard interval for the MN to connect to anew MAAR. Then, a change in the MAAR operations is required, and at this stage,two possible solutions can be deployed:¶

• A P-MAAR stops the BCE timer upon receiving a PBU from the CMD containinga "Serving MAAR" option. In this way, only the S-MAAR is allowed tode-register the mobility session, arguing that the MN definitely left thedomain.¶
• P-MAARs can, upon BCE expiry, send de-registration messages to the CMD,which, instead of acknowledging the message with a 0 lifetime, sends back a PBAwith a non-zero lifetime, hence renewing the session if the MN is stillconnected to the domain.¶

3.6.Retransmissions and Rate Limiting

The node sending PBUs (the CMD or S-MAAR)SHOULD make use ofthe timeout to also deal with missing PBAs (to retransmit PBUs). TheINITIAL_BINDACK_TIMEOUT[RFC6275]SHOULD be used for configuringthe retransmission timer. The retransmissions by the nodeMUST use anexponential backoff process in which the timeout period is doubled upon eachretransmission until either the node receives a response or the timeout periodreaches the value MAX_BINDACK_TIMEOUT[RFC6275]. The nodeMAYcontinue to send these messages at this slower rate indefinitely. The nodeMUST NOT send PBU messages to a particular node more than MAX_UPDATE_RATE timeswithin a second[RFC6275].¶

3.7.The Distributed Logical Interface (DLIF) Concept

One of the main challenges of a network-based DMM solution is how to allow aMN to simultaneously send/receive traffic that is anchored atdifferent MAARs and how to influence the MN's selection process of itssource IPv6 address for a new flow without requiring special support from theMN's IP stack. This document defines the DLIF, which is a software construct in the MAAR that can easily hidethe change of associated anchors from the MN.¶

  +---------------------------------------------------+ (                      Operator's                     ) (                         core                        )  +---------------------------------------------------+            |                               |    +---------------+     tunnel    +---------------+    |   IP  stack   |===============|   IP  stack   |    +---------------+               +-------+-------+    |    mn1mar1    |--+ (DLIFs) +--|mn1mar1|mn1mar2|--+    +---------------+  |         |  +-------+-------+  |    | phy interface |  |         |  | phy interface |  |    +---------------+  |         |  +---------------+  |          MAAR1       (o)       (o)       MAAR2       (o)                                   x                 x                                     x             x                        prefA::/64     x         x   prefB::/64                      (AdvPrefLft=0)     x     x                                           (o)                                            |                                         +-----+                             prefA::MN1  | MN1 |  prefB::MN1                            (deprecated) +-----+

The basic idea of the DLIF concept is the following: each S-MAAR exposesitself to a given MN as multiple routers, one per P-MAARassociated with the MN. Let's consider the example shown inFigure 5: MN1 initially attaches to MAAR1,configuring an IPv6 address (prefA::MN1) from a prefix locally anchored at MAAR1(prefA::/64). At this stage, MAAR1 plays the role of both anchoring and servingMAAR and also behaves as a plain IPv6 access router. MAAR1 creates a DLIF to communicate (through a point-to-point link) with MN1, exposing itselfas a (logical) router with specific MAC and IPv6addresses (e.g., prefA::MAAR1/64 and fe80::MAAR1/64) using the DLIFmn1mar1. As explained below, these addresses represent the "logical" identity ofMAAR1 for MN1 and will "follow" the MN while roaming within thedomain (note that the place where all this information is maintained and updatedis out of scope of this document; potential examples are to keep it on the homesubscriber server -- HSS -- or the user's profile).¶

If MN1 moves and attaches to a different MAAR of the domain (MAAR2 in theexample ofFigure 5), this MAAR willcreate a new logical interface (mn1mar2) to expose itself to MN1, providingit with a locally anchored prefix (prefB::/64). In this case, since the MN1 hasanother active IPv6 address anchored at MAAR1, MAAR2 also needs to create anadditional logical interface configured to resemble the one used by MAAR1 tocommunicate with MN1. In this example, MAAR1 is the only P-MAAR (MAAR2 is thesame as S-MAAR), so only the logical interface mn1mar1is created. However, the same process would be repeated if moreP-MAARs were involved. In order to keep the prefix anchored at MAAR1 reachable, atunnel between MAAR1 and MAAR2 is established and the routing is modifiedaccordingly. The PBU/PBA signaling is used to set up the bidirectional tunnelbetween MAAR1 and MAAR2, and it might also be used to convey theinformation about the prefix(es) anchored at MAAR1 and the addresses ofthe associated DLIF (i.e., mn1mar1) to MAAR2.¶

+------------------------------------------+ +----------------------+|                  MAAR1                   | |         MAAR2        ||+----------------------------------------+| |+--------------------+|||+------------------++------------------+|| ||+------------------+|||||+-------++-------+||+-------++-------+||| |||+-------++-------+|||||||mn3mar1||mn3mar2||||mn2mar1||mn2mar2|||| ||||mn1mar1||mn1mar2|||||||| LMAC1 || LMAC2 |||| LMAC3 || LMAC4 |||| |||| LMAC5 || LMAC6 |||||||+-------++-------+||+-------++-------+||| |||+-------++-------+||||||    LIFs of MN3   ||    LIFs of MN2   ||| |||   LIFs of MN1    |||||+------------------++------------------+|| ||+------------------+||||              MAC1   (phy if MAAR1)     || || MAC2 (phy if MAAR2)|||+----------------------------------------+| |+--------------------+|+------------------------------------------+ +----------------------+                    x        x                            x                   x          x                          x                 (o)          (o)                      (o)                  |            |                        |               +--+--+      +--+--+                  +--+--+               | MN3 |      | MN2 |                  | MN1 |               +-----+      +-----+                  +-----+

Figure 6 shows the logical interface concept in moredetail. The figure shows two MAARs and three MNs. MAAR1 is currently serving MN2and MN3, while MAAR2 is serving MN1. Note that an S-MAAR always plays therole of anchoring MAAR for the attached (served) MNs. Each MAAR has one singlephysical wireless interface as depicted in this example.¶

As discussed before, each MN always "sees" multiple logical routers -- one peranchoring MAAR -- independently of its currently S-MAAR. From the point ofview of the MN, these MAARs are portrayed as different routers, although the MNis physically attached to a single interface. This is achieved bythe S-MAAR configuring different logical interfaces. MN1 is currently attached to MAAR2 (i.e., MAAR2 is its S-MAAR) and, therefore,it has configured an IPv6 address from MAAR2's pool (e.g., prefB::/64). MAAR2has set up a logical interface (mn1mar2) on top of its wireless physicalinterface (phy if MAAR2), which is used to serve MN1. This interface has alogical MAC address (LMAC6) that is different from the hardware MAC address (MAC2) ofthe physical interface of MAAR2. Over the mn1mar2 interface, MAAR2 advertisesits locally anchored prefix prefB::/64. Before attaching to MAAR2, MN1 wasattached to MAAR1 and configured a locally anchored address at that MAAR,which is still being used by MN1 in active communications. MN1 keeps "seeing" aninterface connecting to MAAR1 as if it were directly connected to the twoMAARs. This is achieved by the S-MAAR (MAAR2) configuring an additionalDLIF, mn1mar1, which behaves as the logical interfaceconfigured by MAAR1 when MN1 was attached to it. This means that both the MACand IPv6 addresses configured on this logical interface remain the sameregardless of the physical MAAR that is serving the MN. The informationrequired by an S-MAAR to properly configure this logical interfaces can beobtained in different ways: as part of the information conveyed in the PBA, froman external database (e.g., the HSS) or by other means. As shown in the figure,each MAAR may have several logical interfaces associated with each attached MNand always has at least one (since an S-MAAR is also an anchoring MAAR forthe attached MN).¶

In order to enforce the use of the prefix locally anchored at the S-MAAR,the RAs sent over those logical interfaces playing the role ofanchoring MAARs (different from the serving one) include a zero preferred prefixlifetime (and a non-zero valid prefix lifetime, so the prefix remains validwhile being deprecated). The goal is to deprecate the prefixes delegated bythese MAARs (so that they will no longer be serving the MN). Note that ongoingcommunications may keep on using those addresses even if they are deprecated,so this only affects the establishment of new sessions.¶

The DLIF concept also enables the following use case:suppose that access to a local IP network is provided by a given MAAR (e.g.,MAAR1 in the example shown inFigure 5)and that the resources available at that network cannot be reached from outsidethe local network (e.g., cannot be accessed by an MN attached to MAAR2). This issimilar to the local IP access scenario considered by 3GPP, where a localgateway node is selected for sessions requiring access to services providedlocally (instead of going through a central gateway). The goal is to allow an MNto be able to roam while still being able to have connectivity to this local IPnetwork. The solution adopted to support this case makes use of more specificroutes, as discussed in RFC 4191[RFC4191], when the MN moves to a MAAR differentfrom the one providing access to the local IP network (MAAR1 in theexample).These routes are advertised through the DLIF wherethe MAAR is providing access to the local network (MAAR1 in thisexample). In this way, if MN1 moves from MAAR1 to MAAR2, any active session thatMN1 may have with a node on the local network connected to MAAR1 will survivevia the tunnel between MAAR1 and MAAR2. Also, any potential future connectionattempt to the local network will be supported even though MN1 is nolonger attached to MAAR1, so long as a source address configured from MAAR1 isselected for new connections (see[RFC6724], rule 5.5).¶

4.1.Proxy Binding Update

A new flag (D) is included in the PBU to indicate that thePBU is coming from a MAAR or a CMD and not from a MAG. The rest of the PBU format remains the same as definedin[RFC5213].¶

0               1               2               30 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                                +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                                |            Sequence #         |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+|A|H|L|K|M|R|P|F|T|B|S|D| Rsrvd |            Lifetime           |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+|                                                               |.                                                               ..                        Mobility Options                       ..                                                               .|                                                               |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

DMM Flag (D)

The D flag is set to indicate to the receiver of the message that the PBU is from a MAAR or a CMD. When an LMA that does not support theextensions described in this document receives a message with the D flag set,the PBU in that caseMUST NOT be processed by the LMA, and an errorMUST bereturned.¶

Mobility Options

Variable-length field of such length that the complete Mobility Header is aninteger that is a multiple of 8 octets long. This field contains zero or more TLV-encodedmobility options. The encoding and format of the defined options are described inSection 6.2 of [RFC6275]. The receiving nodeMUST ignore andskip any options that it does not understand.¶

4.2.Proxy Binding Acknowledgement

A new flag (D) is included in the PBA to indicate thatthe sender supports operating as a MAAR or CMD. The rest of the PBA format remains the same as defined in[RFC5213].¶

 0                   1                   2                   3 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                                +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                                |   Status      |K|R|P|T|B|S|D| |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+|         Sequence #            |           Lifetime            |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+|                                                               |.                                                               ..                        Mobility Options                       ..                                                               .|                                                               |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

DMM Flag (D)

The D flag is set to indicate that the sender of the message supports operatingas a MAAR or CMD. When a MAG that does not support the extensions described inthis document receives a message with the D flag set, itMUST ignore the message,and an errorMUST be returned.¶

Mobility Options

Variable-length field of such length that the complete Mobility Header is aninteger multiple of 8 octets long. This field contains zero or more TLV-encodedmobility options. The encoding and format of the defined options are described inSection 6.2 of [RFC6275]. The MAARMUST ignore and skip anyoptions that it does not understand.¶

4.3.Anchored Prefix Option

A new Anchored Prefix option is defined for use with the PBU and PBA messages exchanged between MAARs and CMDs.Therefore, this option can only appear if the D bit is set in a PBU/PBA. Thisoption is used for exchanging the MN's prefix anchored at the anchoringMAAR. There can be multiple Anchored Prefix options present in the message.¶

The Anchored Prefix option has an alignment requirement of 8n+4. Its format isas follows:¶

 0                   1                   2                   3 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+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+|      Type     |   Length      |   Reserved    | Prefix Length |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+|                                                               |+                                                               +|                                                               |+                        Anchored Prefix                        +|                                                               |+                                                               +|                                                               |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Type

65¶

Length

8-bit unsigned integer indicating the length of the option in octets, excludingthe type and length fields. This fieldMUST be set to 18.¶

Reserved

This field is unused at the time of publication. The valueMUST be initialized to 0 by the senderandMUST be ignored by the receiver.¶

Prefix Length

8-bit unsigned integer indicating the prefix length in bits of the IPv6 prefixcontained in the option.¶

Anchored Prefix

A 16-octet field containing the MN's IPv6 Anchored Prefix. Only thefirst Prefix Length bits are valid for the Anchored Prefix option. The rest of thebitsMUST be ignored.¶

4.4.Local Prefix Option

A new Local Prefix option is defined for use with the PBU and PBA messages exchanged between MAARs or between a MAARand a CMD. Therefore, this option can only appear if the D bit is set in aPBU/PBA. This option is used for exchanging a prefix of a local network that isonly reachable via the anchoring MAAR. There can be multiple Local Prefixoptions present in the message.¶

The Local Prefix option has an alignment requirement of 8n+4. Its format isas follows:¶

 0                   1                   2                   3 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+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+|      Type     |   Length      |   Reserved    | Prefix Length |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+|                                                               |+                                                               +|                                                               |+                         Local Prefix                          +|                                                               |+                                                               +|                                                               |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Type

66¶

Length

8-bit unsigned integer indicating the length of the option in octets, excludingthe type and length fields. This fieldMUST be set to 18.¶

Reserved

This field is unused at the time of publication. The valueMUST be initialized to 0 by the senderandMUST be ignored by the receiver.¶

Prefix Length

8-bit unsigned integer indicating the prefix length in bits of the IPv6 prefixcontained in the option.¶

Local Prefix

A 16-octet field containing the IPv6 Local Prefix. Only the first PrefixLength bits are valid for the IPv6 Local Prefix. The rest of the bitsMUST beignored.¶

4.5.Previous MAAR Option

This new option is defined for use with the PBA messages exchanged by the CMD to a MAAR. This option is used to notify theS-MAAR about the P-MAAR's global address and the prefix anchored to it.There can be multiple Previous MAAR options present in the message.¶

The Previous MAAR option has an alignment requirement of 8n+4. Its format isas follows:¶

 0                   1                   2                   3 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+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+|      Type     |     Length    |   Reserved    | Prefix Length |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+|                                                               |+                                                               +|                                                               |+                     Previous MAAR                             +|                                                               |+                                                               +|                                                               |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+|                                                               |+                                                               +|                                                               |+                    Home Network Prefix                        +|                                                               |+                                                               +|                                                               |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Type

67¶

Length

8-bit unsigned integer indicating the length of the option in octets, excludingthe type and length fields. This fieldMUST be set to 34.¶

Reserved

This field is unused at the time of publication. The valueMUST be initialized to 0 by the senderandMUST be ignored by the receiver.¶

Prefix Length

8-bit unsigned integer indicating the prefix length in bits of the IPv6 prefixcontained in the option.¶

Previous MAAR

A 16-octet field containing the P-MAAR's IPv6 global address.¶

Home Network Prefix

A 16-octet field containing the MN's IPv6 Home Network Prefix. Onlythe first Prefix Length bits are valid for the MN's IPv6 Home NetworkPrefix. The rest of the bitsMUST be ignored.¶

4.6.Serving MAAR Option

This new option is defined for use with the PBU messageexchanged between the CMD and a P-MAAR. This option is used to notify theP-MAAR about the current S-MAAR's global address. Its format is asfollows:¶

The Serving MAAR option has an alignment requirement of 8n+6. Its format is asfollows:¶

 0                   1                   2                   3 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                                +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                                |      Type     |     Length    |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+|                                                               |+                                                               +|                                                               |+                     S-MAAR's Address                          +|                                                               |+                                                               +|                                                               |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Type

68¶

Length

8-bit unsigned integer indicating the length of the option in octets, excludingthe type and length fields. This fieldMUST be set to 16.¶

Serving MAAR

A 16-octet field containing the S-MAAR's IPv6 global address.¶

4.7.DLIF Link-Local Address Option

A new DLIF Link-Local Address option is defined for use with the PBA message exchanged between MAARs and between a MAAR and a CMD.This option is used for exchanging the link-local address of the DLIF to beconfigured on the S-MAAR so it resembles the DLIF configured on theP-MAAR.¶

The DLIF Link-Local Address option has an alignment requirement of 8n+6. Itsformat is as follows:¶

 0                   1                   2                   3 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                                +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                                |   Type        |    Length     |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+|                                                               |+                                                               +|                                                               |+                  DLIF Link-Local Address                      +|                                                               |+                                                               +|                                                               |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Type

69¶

Length

8-bit unsigned integer indicating the length of the option in octets, excludingthe type and length fields. This fieldMUST be set to 16.¶

DLIF Link-Local Address

A 16-octet field containing the link-local address of the logical interface.¶

4.8.DLIF Link-Layer Address Option

A new DLIF Link-Layer Address option is defined for use with the PBA message exchanged between MAARs and between a MAAR and a CMD. Thisoption is used for exchanging the link-layer address of the DLIF to beconfigured on the S-MAAR so it resembles the DLIF configured on theP-MAAR.¶

The format of the DLIF Link-Layer Address option is shown below. Based on thesize of the address, the optionMUST be aligned appropriately,as per the mobilityoption alignment requirements specified in[RFC6275].¶

 0                   1                   2                   3 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+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+|   Type        |    Length     |          Reserved             |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+|                                                               |+                    DLIF Link-Layer Address                    +.                              ...                              .|                                                               |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Type

70¶

Length

8-bit unsigned integer indicating the length of the option in octets, excludingthe type and length fields.¶

Reserved

This field is unused at the time of publication. The valueMUST be initialized to 0 by the senderandMUST be ignored by the receiver.¶

DLIF Link-Layer Address

A variable length field containing the link-layer address of the logicalinterface to be configured on the S-MAAR.¶

The content and format of this field (including octet and bit ordering) is asspecified inSection 4.6 of [RFC4861] for carrying link-layeraddresses. On certain access links where the link-layer address is not used orcannot be determined, this option cannot be used.¶