rfc-5648

Multiple Care-of Addresses Registration

R. Wakikawa (Editor), V. Devarapalli, G. Tsirtsis, T. Ernst, K. Nagami
date2009-10 streamIETF areaint wgmext statusPROPOSED STANDARD pages36 canonicalhttps://www.rfc-editor.org/rfc/rfc5648 doi10.17487/RFC5648 errataview
According to the current Mobile IPv6 specification, a mobile node may have several care-of addresses but only one, called the primary care-of address, can be registered with its home agent and the correspondent nodes. However, for matters of cost, bandwidth, delay, etc, it is useful for the mobile node to get Internet access through multiple accesses simultaneously, in which case the mobile node would be configured with multiple active IPv6 care-of addresses. This document proposes extensions to the Mobile IPv6 protocol to register and use multiple care-of addresses. The extensions proposed in this document can be used by mobile routers using the NEMO (Network Mobility) Basic Support protocol as well. [STANDARDS-TRACK]

updated by

Extracted elements (28)

design-rationale §2

A mobile node MAY change its BID value at any time according to administrative policy, for instance to protect privacy. However, implementations must carefully assign BIDs to keep the same BID for the same binding even when binding status changes.

mobility, ip, privacy

design-rationale §3

Binding cache lookup for data packets does not carry BID information, so when no flow-filter-based BID selection mechanism is available, a node SHOULD use the binding last verified by receiving data or signaling from the mobile node. This avoids requiring per-packet BID signaling overhead.

mobility, ip

design-rationale §3

Bulk registration to correspondent nodes is explicitly not supported because the return routability mechanism in RFC 3775 cannot be easily extended to verify multiple care-of addresses stored in a single Binding Update, which would require per-CoA Care-of Keygen tokens.

mobility, ip, security

interoperability-note §9.1 MUST

For IKEv2/IPsec interaction, if the mobile node needs to change the care-of address used for the IKE SA, it sends a BU with the 'K' bit set. If 'K' is unsupported, the mobile node MUST re-establish the IKEv2 SA with the new care-of address, resulting in new IPsec SAs.

mobility, ipsec, ip

interoperability-note §6.2

If a Binding Update without a Binding Identifier mobility option is received and the receiver already has multiple bindings for the home address, it MUST replace all existing bindings with the received single binding, restoring RFC 3775 single-binding semantics.

mobility, ip

interoperability-note §3

This specification maintains backward compatibility with RFC 3775. If a receiver does not understand the Binding Identifier mobility option, it skips it and processes the Binding Update per RFC 3775. If the mobile node finds no Binding Identifier mobility option in the received Binding Acknowledgement, it MUST fall back to legacy RFC 3775 behavior.

mobility, ip

interoperability-note §8.1

When MCoA is used with DSMIPv6 (RFC 5555), the IPv4 Care-of Address mobility option MUST NOT be used when the BID mobility option is present. The receiver MUST treat the IPv4 address in the BID option as equivalent to the IPv4 Care-of Address mobility option.

mobility, ip, nat

normative-requirement §2 MUST NOT

A mobile node MUST NOT perform bulk registration with a correspondent node. Bulk registration is supported only for home registration with the home agent.

mobility, ip

normative-requirement §3 MUST

After receiving a Binding Update with a Binding Identifier mobility option, the home agent MUST copy the BID to the corresponding binding cache entry. If the BID does not match any existing entry, the home agent MUST create a new binding cache entry for the new care-of address and BID.

mobility, ip

normative-requirement §5.2 MUST

For binding registration to a correspondent node, the mobile node MUST have both active Home and Care-of Keygen tokens for each care-of address before sending the Binding Update. The Binding Authorization Data mobility option MUST be placed after the Binding Identifier mobility option.

mobility, ip, security

normative-requirement §8.1 MUST NOT

For DSMIPv6, bulk registration MUST NOT be used for the initial binding registration from an IPv4 care-of address, because the initial BU/BA exchange is used for NAT detection between the mobile node and the home agent.

mobility, ip, nat

normative-requirement §5.2 MUST

For multiple care-of addresses registration, the mobile node MUST include a Binding Identifier mobility option in the Binding Update. When IPsec ESP protects the Binding Update, the care-of address MUST be carried in the Care-of Address field of the Binding Identifier mobility option, and the alternate Care-of Address option MUST NOT be included.

mobility, ip, ipsec

normative-requirement §5.1 MUST

If a mobile node wants to register multiple bindings, it MUST generate a unique BID for each care-of address and store the BID in the Binding Update List. A BID MUST be unique for a given home address; once multiple care-of addresses exist, all MUST be mapped to BIDs.

mobility, ip

normative-requirement §5.6.3 MUST NOT

If the mobile node receives a MCOA RETURNHOME WO/NDP status in the Binding Acknowledgement, it MUST NOT respond to Neighbor Solicitation for its home address and MUST NOT operate Neighbor Discovery for the home address, instead sending packets directly to the default router's link-layer address.

mobility, ip

normative-requirement §5.7 MUST

If the mobile node receives MCOA PROHIBITED status, it MUST stop registering multiple bindings with that node. If MCOA NON-MCOA BINDING EXISTS is received, the mobile node MUST set the 'O' flag to replace all bindings with an MCoA registration.

mobility, ip

normative-requirement §4.1 MUST

The sequence number value MUST be shared among all Binding Update List entries related to Binding Updates sent to a particular home agent or correspondent node. Whenever a mobile node sends an individual or bulk Binding Update, the sequence number is incremented.

mobility, ip

normative-requirement §6.2 MUST

When a correspondent node sends a Binding Acknowledgement, the status value MUST always be stored in the Status field of the Binding Acknowledgement and the Status field of the Binding Identifier mobility option MUST always be set to zero.

mobility, ip

normative-requirement §6.5 MUST

When a node receives packets with a Home Address destination option from a mobile node, it MUST verify that the source care-of address matches one of the care-of addresses in the binding cache entry. If no match is found, the packets MUST be discarded and a Binding Error message MUST be sent.

mobility, ip, security

normative-requirement §5.9 MUST

When bootstrapping and registering multiple bindings for the first time, the mobile node MUST set the 'O' flag in the Binding Update to replace any stale bindings the home agent may still hold from before the mobile node rebooted.

mobility, ip

normative-requirement §5.6.3 MUST

When registering a home binding (simultaneous home and foreign link operation), the Binding Update MUST include the Binding Identifier mobility option with the H flag set, the lifetime MUST be non-zero, and the Care-of Address field MUST be set to the home address.

mobility, ip

protocol-element §2

The Binding Identification Number (BID) is a 16-bit unsigned integer assigned by the mobile node to distinguish multiple bindings for the same home address. BIDs must be unique per home address at any given time; the value zero is reserved and SHOULD NOT be used. The mobile node stores BIDs in its Binding Update List and sends them in Binding Updates.

mobility, ip

protocol-element §4.2

The Overwrite (O) flag is added to the Binding Update message. When set, all existing binding cache entries for the mobile node are replaced by entries registered in this Binding Update. It is only meaningful when a Binding Identifier mobility option is present.

mobility, ip

protocol-element §4.3

The Simultaneous Home and Foreign Binding (H) flag in the Binding Identifier mobility option indicates that the mobile node is registering multiple bindings while attached to its home link. This flag is valid only in Binding Updates sent to the home agent.

mobility, ip

registry §11

IANA assigned Binding Identifier mobility option Type 35 from the Mobile IPv6 mobility option space. New Binding Acknowledgement status codes assigned: successful values MCOA NOTCOMPLETE (4) and MCOA RETURNHOME WO/NDP (5); error values MCOA MALFORMED (164), MCOA NON-MCOA BINDING EXISTS (165), MCOA PROHIBITED (166), MCOA UNKNOWN COA (167), MCOA BULK REGISTRATION PROHIBITED (168), MCOA SIMULTANEOUS HOME AND FOREIGN PROHIBITED (169).

mobility, ip, registry

security-consideration §10

Bulk registration prevents the home agent from verifying care-of address reachability for addresses carried in Binding Identifier mobility options. Home agents MAY reject bulk registration using MCOA BULK REGISTRATION PROHIBITED to mitigate this risk. Alternatively, initial per-CoA registration allows reachability verification before bulk refresh is used.

mobility, ip, security

security-consideration §10

Simultaneous multiple care-of address binding increases the risk of redirection attacks. A malicious mobile node can bind multiple victims' addresses as valid care-of addresses, then instruct the home agent to tunnel large traffic flows to those addresses. Unlike single-CoA MIPv6, the attacker can retain a valid care-of address for control while redirecting traffic to victims.

mobility, ip, security

state-machine §5.5

When a mobile node returns home, it may enter one of three states: (1) full de-registration via the home interface (RFC 3775 behavior), (2) continued foreign-link-only operation with the home interface shut down, or (3) simultaneous home and foreign link operation requiring home binding registration with the H flag. Transition to state 3 is triggered by sending a BU with H flag set and non-zero lifetime.

mobility, ip

wire-format §4.3

The Binding Identifier mobility option (Type=35) carries the BID, an 8-bit Status field, a 1-bit H flag, and an optional Care-of Address field. The Length field MUST be 4 (no CoA), 8 (IPv4 CoA), or 20 (IPv6 CoA). Alignment is 2n without CoA, 8n+2 with CoA.

mobility, ip