Description
The IP Control Protocol (IPCP) is defined by the IETF in RFC 1332 and is a crucial component of the Point-to-Point Protocol (PPP) framework. PPP itself provides a standard method for transporting multi-protocol datagrams over point-to-point links. IPCP operates as a sibling to other NCPs like IPv6CP (for IPv6) and operates in the PPP Network Layer phase. Its sole purpose is to negotiate IPv4-specific parameters for the PPP link, transitioning it from a mere data link to a functional network layer connection capable of carrying IPv4 packets.
IPCP works through a simple symmetric state machine using a similar packet exchange mechanism as the Link Control Protocol (LCP). After the PPP link is established and authenticated (via LCP and potentially PAP/CHAP), IPCP negotiation begins. The two peers exchange Configure-Request packets containing configuration options they desire. The most critical option is the IP-Address, where a peer can request a specific address, suggest an address for the remote end, or indicate it will provide an address later. Other options include Primary DNS Server address, Primary NBNS (NetBIOS Name Server) address, and IP-Compression-Protocol for Van Jacobson TCP/IP header compression. Each peer responds with a Configure-Ack (acceptance), Configure-Nak (rejection with a counter-proposal), or Configure-Reject (rejection of an unrecognized option). This exchange continues until both sides send and receive Configure-Acks.
Once IPCP reaches the Opened state, the IPv4 protocol is considered configured for this PPP link. All IPv4 packets are then encapsulated within PPP frames (Protocol field 0x0021) and transmitted. IPCP also handles the termination of the IPv4 network layer connection through Terminate-Request and Terminate-Ack packets, and can re-negotiate parameters dynamically via Configure-Request at any time while the link is active. In 3GPP contexts, IPCP historically played a role in the early PS data services (GPRS) where the terminal-to-network interface (e.g., over Um/Gb interfaces) could use PPP, and it remains relevant for certain legacy interworking functions and specific backhaul link configurations.
Purpose & Motivation
IPCP was created as part of the IETF's PPP suite to solve the problem of automating the configuration of network-layer parameters over simple point-to-point links. Before PPP and IPCP, establishing an IP connection over a serial line (like a dial-up modem connection) required manual configuration of IP addresses on both ends, which was error-prone and impractical for large-scale deployments like Internet Service Providers (ISPs). IPCP provided a lightweight, standardized protocol to dynamically negotiate these parameters, enabling 'plug-and-play' IP connectivity.
Within 3GPP, the adoption of IPCP was driven by the need for a reliable, standardized data link protocol for early packet-switched services. In GPRS and early UMTS releases, the connection between the Mobile Station (MS) and the network across the radio interface could be established using PPP, with IPCP performing the crucial task of assigning the MS its IPv4 address from the network. This integrated the mobile device seamlessly into the IP network. While later 3GPP systems (EPS, 5GS) moved towards a pure GTP-based model where IP address assignment is handled by the core network (DHCPv4 or from the PGW/UPF) during PDN/PDU Session establishment, IPCP remains specified for certain interworking scenarios, legacy support, and for specific access types where PPP is still the underlying link protocol.
Key Features
- Negotiates IPv4 address assignment for both ends of a PPP link
- Configures auxiliary parameters like DNS and NBNS server addresses
- Supports Van Jacobson TCP/IP header compression via a dedicated option
- Uses a simple request/ack/nak/reject state machine for robust negotiation
- Allows for dynamic re-negotiation of parameters during an active session
- Works in conjunction with LCP and authentication protocols within the PPP stack
Evolution Across Releases
Formally referenced IPCP within 3GPP specifications for interworking scenarios, particularly for legacy MS-to-network interfaces and specific fixed broadband interworking where PPP was the underlying data link protocol. It was used as one method for IPv4 address negotiation between the User Equipment and the network.
Maintained support for IPCP as part of the continued evolution of fixed-mobile convergence and interworking with DSL networks, where PPP over Ethernet (PPPoE) was prevalent. Enhancements focused on ensuring seamless policy and QoS mapping between PPP/IPCP sessions and 3GPP bearers.
Support for IPCP was considered in the context of Machine-Type Communication (MTC) optimizations, particularly for devices with very simple IP stacks. However, the primary direction for MTC moved towards more efficient, header-compressed solutions like 6LoWPAN and dedicated CIoT optimizations, reducing reliance on full PPP/IPCP.
With the introduction of NB-IoT and further CIoT optimizations, the focus shifted decisively towards solutions like Control Plane CIoT EPS optimization and Non-IP Data Delivery (NIDD). IPCP's role diminished for new IoT device types, remaining primarily for legacy interworking and specific backhaul links.
In the 5G era, IPCP is not a primary protocol for the N1 or user plane interfaces. IPv4 address assignment for PDU Sessions is handled by the SMF using DHCPv4 or static allocation. IPCP support is retained in specifications for completeness regarding interworking with external networks that may use PPP.
Defining Specifications
| Specification | Title |
|---|---|
| TS 23.852 | 3GPP TS 23.852 |
| TS 29.061 | 3GPP TS 29.061 |