ietf-corpus

rfc-5026

Mobile IPv6 Bootstrapping in Split Scenario

G. Giaretta (Editor), J. Kempf, V. Devarapalli (Editor)
date2007-10 streamIETF areaint wgmip6 statusPROPOSED STANDARD pages28 canonicalhttps://www.rfc-editor.org/rfc/rfc5026 doi10.17487/RFC5026
A Mobile IPv6 node requires a Home Agent address, a home address, and IPsec security associations with its Home Agent before it can start utilizing Mobile IPv6 service. RFC 3775 requires that some or all of these are statically configured. This document defines how a Mobile IPv6 node can bootstrap this information from non-topological information and security credentials pre-configured on the Mobile Node. The solution defined in this document solves the split scenario described in the Mobile IPv6 bootstrapping problem statement in RFC 4640. The split scenario refers to the case where the Mobile Node's mobility service is authorized by a different service provider than basic network access. The solution described in this document is also generically applicable to any bootstrapping case, since other scenarios are more specific realizations of the split scenario. [STANDARDS-TRACK]

updated by

Extracted elements (26)

design-rationale §4

DNS-based HA address discovery is chosen over DHAAD because DHAAD requires the Mobile Node to be pre-configured with the home network prefix and does not allow load balancing across Home Agents in different subnets. The only pre-configured information needed is the MSP domain name.

mobility, dns

design-rationale §6

The dynamic DNS update is recommended to be performed by the Home Agent rather than the Mobile Node, for security and administrative reasons: requiring all Mobile Nodes to share security associations with MSP DNS servers is operationally cumbersome and introduces address authorization complexity.

mobility, dns

design-rationale §3

The split scenario assumes mobility service and network access are authorized by different entities (MSA != ASA). This separation allows, for example, an enterprise to offer Mobile IPv6 service to a user accessing the Internet via a personal WiFi hotspot account, independent of the enterprise account.

mobility, ip

interoperability-note §5.3.2

The MIP6_HOME_PREFIX attribute provides only a single prefix and does not carry all information present in an IPv6 router advertisement. It is used solely for Home Address auto-configuration during bootstrapping and does not replace Mobile Prefix Discovery (RFC 3775) for its defined purposes.

mobility, ip

normative-requirement §9.2 MUST

Addresses MUST be marked as used for at least as long as the binding exists and associated with the mobile node identity. The home agent MUST also ensure that a requested address is not the authorized address of any other mobile node.

mobility, security

normative-requirement §9.2 MUST

Home agents MUST authorize each home address allocation and use, linked to the mobile node identity used in IKEv2 authentication. Home agents MUST implement at least configured home address(es) per mobile node and first-come-first-served (FCFS) authorization modes.

mobility, security

normative-requirement §5.1.2 SHOULD

If multiple Home Agents are available in the DNS SRV record and the chosen HA does not respond to IKE_SA_INIT messages or IKEv2 authentication fails, the Mobile Node SHOULD try the next Home Agent on the list.

mobility, dns

normative-requirement §5.1.2 SHOULD

If none of the Home Agents respond, the Mobile Node SHOULD try again after a configurable period of time. If IKEv2 authentication fails with all Home Agents, it is an unrecoverable error.

mobility

normative-requirement §5.3.2 MUST

If the Mobile Node receives a Binding Acknowledgement with status 134 (DAD failed), it MUST stop using the current Home Address, configure a new HoA, and run an IKEv2 CREATE_CHILD_SA exchange for the new HoA before sending a new Binding Update.

mobility, ip

normative-requirement §5.3.2 MUST

If the Mobile Node receives a USE_ASSIGNED_HoA Notify Payload in response to a CFG_REQUEST containing MIP6_HOME_PREFIX, it MUST use the address contained in the INTERNAL_IP6_ADDRESS attribute in the subsequent CREATE_CHILD_SA exchange.

mobility, ipsec

normative-requirement §5.2 MUST

If the Mobile Node wants the HA to register the Home Address in the DNS, it MUST use the FQDN as the initiator identity (IDi) in the IKE_AUTH step of the IKEv2 exchange, to prove ownership of the FQDN provided in the DNS Update Option.

mobility, ipsec, dns

normative-requirement §5.1.2 RECOMMENDED

It is RECOMMENDED that the DNS server return the IP addresses of the Home Agents in AAAA records as part of the additional data section of the SRV reply, to avoid requiring an additional DNS round trip.

mobility, dns

normative-requirement §6 RECOMMENDED

It is RECOMMENDED that the Home Agent perform DNS entry updates for the Mobile Node. The Mobile Node MAY include a DNS Update mobility option in the Binding Update; after receiving it, the Home Agent MUST update the DNS entry and MUST send a Binding Acknowledgement with the DNS Update option.

mobility, dns

normative-requirement §9.5 MUST

The authorization of the Mobile Node to update a FQDN MUST be checked prior to the DNS update. The Mobile Node MUST use a FQDN as the IDi in the IKE_AUTH step, and that FQDN MUST be the same as the one provided in the DNS Update Option.

mobility, dns, security

normative-requirement §9.5 MUST

The dynamic DNS update SHOULD be performed in a secure way; usage of TKEY and TSIG or DNSSEC is recommended. The Home Agent MUST have a security association with the DNS server, and that SA MUST be separate from SAs used for other purposes such as AAA.

mobility, dns, security

normative-requirement §5.3.2 MUST

When the Home Agent receives a CFG_REQUEST containing the MIP6_HOME_PREFIX attribute, it MUST include in the CFG_REPLY payload prefix information for one prefix on the home link, including the prefix length.

mobility, ip

privacy-consideration §9.1

Assignment of a home agent from the serving network access provider (local HA) or a nearby network may compromise a mobile node's location privacy, since the home address reveals topological location. Mobile nodes requiring location privacy should not disclose this home address to unauthorized nodes (e.g., by updating DNS).

mobility, privacy

protocol-element §5.1.2

The DNS SRV service name for Mobile IPv6 Home Agent service is 'mip6' with protocol name 'ipv6'. A Mobile Node constructs a query with QNAME set to '_mip6._ipv6.<domain>' and QTYPE to SRV to discover available Home Agents.

mobility, dns

protocol-element §8.1

The DNS Update Mobility Option (type 17) is a new Mobility Option included in Binding Update and Binding Acknowledgement messages. It carries a Status field, an R flag (set to remove, clear to add/update), and the Mobile Node's FQDN identity.

mobility, dns

protocol-element §8.2

The MIP6_HOME_PREFIX attribute is carried in IKEv2 Configuration Payload messages to convey the home link prefix from which the Mobile Node auto-configures its Home Address. The Mobile Node includes it in CFG_REQUEST with Length=0; the Home Agent returns it in CFG_REPLY with Length=21 and the full prefix information.

mobility, ipsec

registry §10

This document assigns DNS-UPDATE-TYPE (value 17) in the 'Mobility Option' namespace; MIP6_HOME_PREFIX attribute (value 16) in the 'IKEv2 Configuration Payload Attribute Types' namespace; and USE_ASSIGNED_HoA error type (value 42) in the 'IKEv2 Notify Payload Error Types' namespace.

registry, mobility, ipsec

registry §10

This document creates a new 'Status Codes (DNS Update Mobility Option)' namespace for the Status field in the DNS Update mobility option. Values 0, 128, 129, and 130 are defined. Future values may be allocated via Standards Action or IESG approval.

registry, mobility, dns

security-consideration §9.1

An attacker obtaining a legitimate HA address via DNS could use it to mount a DoS attack on the Home Agent. This is not unique to bootstrapping; every MIPv6 HA faces this risk. Mitigations include overprovisioning, traffic monitoring, hot spares, and IKEv2 cookie-based anti-DoS.

mobility, security

security-consideration §9.1

DNS-based HA address discovery is vulnerable to pharming attacks (bogus DNS server returning bogus HA address), but this risk is mitigated because the Mobile Node must complete an IKEv2 exchange with a valid certificate before establishing Mobile IPv6 service.

mobility, dns, security

wire-format §8.1

The DNS Update Mobility Option has an 8-bit Option Type (17), 8-bit Option Length, 8-bit Status field, 1-bit R flag, 7-bit Reserved, and a variable-length MN identity (FQDN) field. Status values: 0=success, 128=reason unspecified, 129=administratively prohibited, 130=DNS update failed.

mobility, dns

wire-format §8.2

The MIP6_HOME_PREFIX attribute has a 1-bit Reserved field, 15-bit Attribute Type (16), 2-octet Length (0 in request, 21 in reply), 4-octet Prefix Lifetime, 16-octet Home Prefix, and 1-octet Prefix Length.

mobility, ipsec