Localized Routing for Proxy Mobile IPv6
Extracted elements (29)
No synchronization between MAGs is required before local forwarding begins in Scenario A21 because each MAG initiates LR in only one direction independently. Asymmetric LR (one direction localized, one through LMA) is a valid transient state and avoids packet duplication.
Scenario A22 (two MNs at different MAGs with different LMAs) is explicitly excluded from the protocol because PMIPv6 defines no inter-LMA communication mechanism. When a supported scenario morphs into A22, LR must be torn down, accepting transient packet loss rather than permanent misdirection.
To eliminate ambiguity about who initiates LR, the protocol assigns initiation responsibility based on topology: the LMA initiates when it anchors both MNs (same-LMA scenarios), while the MAG initiates only when both MNs are attached to it but anchored at different LMAs. This ensures exactly one entity initiates per scenario.
Both MAGs SHOULD support the same encapsulation modes defined for the LMA-MAG tunnel (IPv4/IPv6-over-IPv6, IPv4/IPv6-over-IPv4, IPv4/IPv6-over-IPv4-UDP per RFC 5844, TLV-header UDP and GRE tunneling per RFC 5845) to ensure compatibility for the inter-MAG localized routing tunnel.
If one MAG returns a successful LRA (Status=0) and the other returns an error in Scenario A21, localized routing proceeds asymmetrically: traffic in one direction goes MAG-to-MAG while return traffic traverses the LMA path, which is a valid operational state.
If the initiator wishes to terminate localized routing before the lifetime expires, it MUST send a new LRI message with the lifetime set to zero.
If the transport network between PMIPv6 entities is IPv4-only, LRI and LRA messages MUST be encapsulated in the same manner as PBU/PBA messages as specified in RFC 5844.
In Scenario A21 (two MNs at different MAGs, same LMA), the LMA MUST send two separate LRI messages to the two MAGs. Each LRI MUST contain the IP address of the counterpart MAG.
LREs MUST override the Binding Update List (BUL) entries for the specific HNPs identified in the LRI message so that all matching traffic is forwarded locally. If the MAG is unable to deliver packets using LREs, it MUST fall back to using the BUL entry.
MAG1 and MAG2 MUST use the same tunneling mechanism for data traffic tunneled between them. The encapsulation mode SHOULD be configurable and defaults to the same mode used for the PMIPv6 LMA-MAG tunnel.
MAGs MUST perform ingress filtering on MN-sourced packets before encapsulating them into MAG-MAG tunnels in order to prevent address spoofing.
Support for integrity protection using IPsec is REQUIRED; support for confidentiality is OPTIONAL. The same security association defined in RFC 5213 between the LMA and MAG is used to protect LRI and LRA messages.
The LMA MUST include the MN-Identifier and Home Network Prefix (as Mobility Header options) for each MN in the LRI message and MUST send it to the MAG where the two MNs are attached.
The LMA MUST initiate LR if both communicating MNs are anchored to it. The LMA MUST NOT initiate LR in any other case.
The LRI message SHOULD be re-transmitted if no corresponding LRA is received within LRA_WAIT_TIME, up to a maximum of LRI_RETRIES attempts each separated by LRA_WAIT_TIME.
The MAG MUST initiate LR if both communicating MNs are attached to it and the MNs are anchored at different LMAs. The MAG MUST NOT initiate LR in any other case.
The MAG MUST verify the attachment status of both MNs locally via the binding cache and MUST verify that the EnableMAGLocalRouting flag is set to 1; if not, it MUST reject the LRI and send an LRA with Status code 'Localized Routing Not Allowed'.
To support IPv4 Home Addresses, MAGs MUST add IPv4 HoAs into their LREs and MUST support IPv4 packet encapsulation per RFC 5844. LR signaling messages MUST include an IPv4 HoA option when IPv4 addresses are involved.
Upon expiry of the localized routing lifetime, forwarding MUST revert to bidirectional tunneling. Corresponding Localized Routing Entries (LREs) MUST be removed when localized routing ceases.
When Scenario A22 arises (MNs at different MAGs with different LMAs), the initiator of LR MUST tear it down to prevent lasting packet loss. Use of localized routing is NOT RECOMMENDED for packet-loss-sensitive applications in deployments where A22 is possible.
Configuration variables LRA_WAIT_TIME (default 3 seconds, interval between LRI retransmissions) and LRI_RETRIES (default 3, maximum retransmission count) MUST be configurable on both LMA and MAG.
The Localized Routing Acknowledgment (LRA) message uses Mobility Header type 18. It carries a Sequence Number copied from the LRI, a 'U' unsolicited flag, an 8-bit Status code (0 = success, 128 = Not Allowed, 129 = MN Not Attached), a Lifetime, and Mobility Options with MN-ID/HNP tuples.
The Localized Routing Initiation (LRI) message uses Mobility Header type 17. It carries a Sequence Number, a Reserved field (MUST be zero), a Lifetime in seconds (0xffff = infinite, 0 = stop), and Mobility Options containing MN-ID and HNP tuples for each communicating MN.
The LRA 'U' (unsolicited) flag, when set to 1, indicates that the LRA message is sent without a preceding LRI. The receiving MAG must wait for a regular LRI to confirm any new Lifetime value indicated in an unsolicited LRA.
IANA assigned Mobility Header type 17 to the Localized Routing Initiation (LRI) message and type 18 to the Localized Routing Acknowledgment (LRA) message in the 'Mobility Header Types' registry.
IANA assigned Mobility Option type 51 to the MAG IPv6 Address option in the 'Mobility Options' registry at IANA mobility-parameters.
The protocol inherits the threats to PMIPv6 (RFC 5213) identified in RFC 4832. LRI and LRA messages are protected using the same LMA-MAG IPsec security association defined in RFC 5213; a preexisting MAG-MAG security association is assumed when inter-MAG LR is needed.
The LRI message wire format includes a 16-bit Sequence Number, 16-bit Reserved field, 16-bit Lifetime, followed by variable-length Mobility Options. The Mobility Options MUST contain two MN-ID options each followed by one or more HNP options, in order: [MN1-ID, MN1-HNP], [MN2-ID, MN2-HNP].
The MAG IPv6 Address mobility option (Type 51) has an alignment requirement of 8n+4, a 1-byte Type, 1-byte Length (MUST be set to 18), 1-byte Reserved (MUST be 0), 1-byte Address Length (MUST be 128), and a 16-byte MAG IPv6 Address field.