ietf-corpus

rfc-5121

Transmission of IPv6 via the IPv6 Convergence Sublayer over IEEE 802.16 Networks

B. Patil, F. Xia, B. Sarikaya, JH. Choi, S. Madanapalli
date2008-02 streamIETF areaint wg16ng statusPROPOSED STANDARD pages22 canonicalhttps://www.rfc-editor.org/rfc/rfc5121 doi10.17487/RFC5121 errataview
IEEE Std 802.16 is an air interface specification for fixed and mobile Broadband Wireless Access Systems. Service-specific convergence sublayers to which upper-layer protocols interface are a part of the IEEE 802.16 MAC (Medium Access Control). The Packet convergence sublayer (CS) is used for the transport of all packet- based protocols such as Internet Protocol (IP) and IEEE 802.3 LAN/MAN CSMA/CD Access Method (Ethernet). IPv6 packets can be sent and received via the IP-specific part of the Packet CS. This document specifies the addressing and operation of IPv6 over the IP-specific part of the Packet CS for hosts served by a network that utilizes the IEEE Std 802.16 air interface. It recommends the assignment of a unique prefix (or prefixes) to each host and allows the host to use multiple identifiers within that prefix, including support for randomly generated interface identifiers. [STANDARDS-TRACK]

updated by

Extracted elements (27)

design-rationale §Appendix D

In WiMAX networks, the recommended MTU for IPv6 is 1400 octets rather than the default 1500, because GRE tunnel overhead between BS and AR plus the 6-byte 802.16 MAC header would cause fragmentation of 1500-byte packets. This value must be communicated to the MS via the RA MTU option.

ip, v6ops

design-rationale §8.3

The MaxRtrAdvInterval and router lifetime are set to very large values (default 10800 seconds) in 802.16 to avoid waking mobile stations that are in idle mode, in which the radio link is torn down and paging is required to deliver packets. Frequent RAs would waste air interface resources.

ip, v6ops, realtime

design-rationale §6.1

The point-to-point link model for IPv6 over 802.16 is used because each MS is connected to the AR via a unique CID-identified transport connection, making each MS belong to a separate subnet. This model is fully consistent with RFC 4861's definition of a point-to-point link.

ip, v6ops

design-rationale §8.1

Use of router advertisements for movement detection is not recommended for MNs connected via 802.16 links because the frequency of periodic RAs would need to be impractically high. Instead, link triggers or other means are preferred for detecting attachment changes.

ip, v6ops, mobility

interoperability-note §6.2

IPv6 support over IP CS is indicated by Bit #2 of the CS capability parameter in REG-REQ/REG-RSP messages. By default, Packet, IPv4, and 802.3/Ethernet are supported; absence of this parameter implies only those defaults, not IPv6 over IP CS.

ip, v6ops

interoperability-note §1

This specification covers only IPv6 over the IP-specific part of the Packet CS (IP CS). Transmission of IP over Ethernet over 802.16 is specified separately in [IPoE-over-802.16], and IPv4 over IP CS is specified in [IPv4-over-IPCS].

ip, v6ops

normative-requirement §6.1 MUST

A unique IPv6 prefix (or prefixes) MUST be assigned to each link (MS/host). The point-to-point link model requires per-MS prefix assignment; a different prefix should be assigned to each unique link.

ip, v6ops

normative-requirement §4 REQUIRED

BS implementations are REQUIRED to support all standards-track encapsulations defined for 802.16 by the IETF, to ensure interoperability between devices supporting different encapsulations.

ip, v6ops

normative-requirement §9.2 SHOULD

DAD SHOULD be performed as per RFC 4861 and RFC 4862. However, DAD on a global unicast address may be redundant if (1) the AR assigns unique prefixes per link and (2) the AR does not autoconfigure IPv6 global unicast addresses from the advertised prefix.

ip, v6ops

normative-requirement §4 MUST

Every Internet host connected via an 802.16 link MUST be able to send and receive IPv6 packets via IP CS when the MS and BS indicate IPv6 protocol support over IP CS.

ip, v6ops

normative-requirement §10 SHOULD

MLDv2 (RFC 3810) SHOULD be supported by hosts and routers attached via an 802.16 link. The AR SHOULD NOT send periodic MLD queries if the host is in idle/dormant mode, using paging controller state information to determine host status.

ip, v6ops, multicast

normative-requirement §8.3 MUST

The AdvDefaultLifetime (router lifetime) in router advertisements MUST be either zero or between MaxRtrAdvInterval and 43200 seconds. The default value is 2 * MaxRtrAdvInterval. This overrides the RFC 4861 specification.

ip, v6ops

normative-requirement §6.3 MUST

The default MTU for IPv6 packets over an 802.16 link SHOULD be 1500 octets. If a value different from 1500 is used, the AR MUST advertise the MTU value via the MTU option in router advertisements as defined in RFC 4861.

ip, v6ops

normative-requirement §8.3 MUST

The MaxRtrAdvInterval MUST be no less than 4 seconds and no greater than 21600 seconds. The default value for MaxRtrAdvInterval is 10800 seconds, overriding RFC 4861's recommendation.

ip, v6ops

normative-requirement §4 MUST

The MS and BS MUST negotiate at most one convergence sublayer for IPv6 transport on a given link. Failure to negotiate a common CS results in failure to set up the transport connection.

ip, v6ops

normative-requirement §6.2 MUST

The MS MUST request the establishment of a service flow for IPv6 packets over IP CS if the MS and BS have confirmed capability for supporting IPv6 over IP CS. The service flow MAY also be triggered by the network via pre-provisioning.

ip, v6ops

normative-requirement §9.1 MUST

The MS MUST use its 48-bit globally unique MAC address (as specified in 802.16) to generate a modified EUI-64 format-based interface identifier as specified in RFC 4291. Other mechanisms such as random interface identifiers per RFC 4941 MAY also be used.

ip, v6ops

normative-requirement §9.4 MUST

When stateful address autoconfiguration is performed, it MUST be performed as specified in RFC 4861 and RFC 3315 (DHCPv6).

ip, v6ops

normative-requirement §9.3 MUST

When stateless address autoconfiguration is performed, it MUST be performed as specified in RFC 4861 and RFC 4862.

ip, v6ops

normative-requirement §4 MUST

When the MS and BS indicate IPv6 protocol support over both IP CS and Ethernet CS, the MS and BS MUST use IP CS for sending and receiving IPv6 packets, making IP CS the default and preferred mode.

ip, v6ops

protocol-element §Appendix B

In WiMAX, the IPv6 link is formed by combining (1) a CID-identified transport connection over the 802.16 air interface between MS and BS, and (2) a GRE tunnel between BS and AR/ASN-GW. From IPv6's perspective, MS and AR are connected by a single point-to-point link.

ip, v6ops

protocol-element §7

One or more /64 prefixes SHOULD be assigned to each 802.16 link (MS). Prefixes are advertised with the on-link (L-bit) flag set. DHCP or AAA-based prefix delegation MAY be used to provide one or more prefixes for an AR connected over 802.16.

ip, v6ops

protocol-element §4

The IP-specific part of the Packet Convergence Sublayer (IP CS) is the mechanism by which IPv6 packets are transported directly over the IEEE 802.16 MAC. The Packet CS classifiers differentiate IPv4 and IPv6 packets and map them to specific transport connections identified by a Connection Identifier (CID).

ip, v6ops

protocol-element §6.1

The IPv6 link in 802.16 is defined as the collection of transport connections (CIDs) and, when the AR is separate from the BS, GRE tunnels between BS and AR. The granularity of the GRE tunnel SHOULD be no greater than per-MS or per-service-flow. Each MS belongs to a distinct point-to-point link.

ip, v6ops

security-consideration §11

This document does not introduce new vulnerabilities to IPv6 operation. The 802.16 air interface provides traffic encryption using a Traffic Encryption Key (TEK) generated by the MS and BS on successful authentication. IPv6 security mechanisms (e.g., IPsec) may be used in addition to 802.16 link-layer security.

security, ip, v6ops

state-machine §6.2

IPv6 link establishment in 802.16 follows a sequential procedure: (1) initial ranging/synchronization, (2) SBC-REQ/RSP basic capability exchange, (3) PKMv2-based authentication, (4) 802.16 registration, (5) REG-REQ/RSP capability exchange with IPv6 CS capability indicated by Bit #2, (6) service flow establishment for IPv6 over IP CS, (7) router advertisement/solicitation exchange.

ip, v6ops

wire-format §4.1

IPv6 packets carried over the IP CS are encapsulated by a 6-byte IEEE 802.16 Generic MAC header. An optional CRC covers the header and payload. The actual MAC address is not included in the MAC header; the Len field in the header is 11 bits, giving a total MAC PDU size of 2048 bytes.

ip, v6ops