10 Interworking with DN (DHCP)
29.5613GPP5G SystemInterworking between 5G Network and external Data NetworksRelease 17Stage 3TS
10.1 General
In current LAN environments the most commonly used configuration protocol is DHCP (Dynamic Host Configuration Protocol, IETF RFC 2131 [18]) and DHCPv6 (Dynamic Host Configuration Protocol for IPv6, IETF RFC 3315 [21]). It provides a mechanism for passing a large set of configuration parameters to hosts connected to a TCP/IP network (IP address, sub-net mask, domain name, MTU, etc.) in an automatic manner. Moreover, DHCP may assign IP addresses to clients for a finite lease time, allowing for sequential reassignment of addresses to different users.
The lease time is chosen by the administrator of the DHCP server (in the external network), and is therefore out of the scope of the present document.
The 3GPP network may obtain IP address via external DHCP server during the PDU establishment procedure, the SMF acts a DHCP server towards the UE and it acts as a DHCP client towards the external DHCP server.
In the following cases the PDU session associated with the allocated IPv4 address or IPv6 prefix shall be released:
– if the DHCP lease expires;
– if the DHCP renewal is rejected by the DHCP server;
– if the IP address is changed during the renewal process. Usually when the lease is renewed, the IP address remains unchanged. However, if for any reason (e.g. poor configuration of the DHCP server), a different IP address is allocated during the lease renewal process the associated PDU session shall be released.
A RG may request DHCP singalling for a UE behind the RG as specified in 3GPP TS 23.316 [43].When handling DHCP signalling coming from the wireline BBF access, the SMF shall support the DHCP signalling as described in BBF TR-456 [54].
10.2 DN interworking Model of SMF for DHCP
10.2.1 Introduction
A DHCP client shall be located in the SMF used for interworking with the IP network as illustrated in figure 10.2.1-1.
Figure 10.2.1-1: The protocol stacks for the N6 reference point for DHCP
The DHCP client function in the SMF shall be used to allocate IPv4 address or IPv6 prefix to the UE and/or to configure associated parameters via external DHCP servers. The SMF shall have both DHCPv4 and DHCPv6 client functions.
The procedures where the DHCP client function in the SMF is used are further described in 3GPP TS 23.501 [2]. The procedures are IPv4 address allocation and IPv4 parameter configuration via an external DHCPv4 server; IPv6 Prefix allocation via stateless address autoconfiguration; and IPv6 parameter configuration via stateless DHCPv6. These procedures are detailed in the clauses below.
10.2.2 IPv4 Address allocation and IPv4 parameter configuration via DHCPv4
The UE may obtain the IPv4 address and/or its configuration parameters at or after the initial access signalling (i.e. Nsmf_PDUSession_CreateSMContext) to the 3GPP network. The request for IPv4 address and/or configuration parameters from the UE may trigger the SMF acting as a DHCPv4 client to request the IPv4 address and/or configuration parameters from an external DHCPv4 server and deliver them to the UE. The DHCPv4 functions in the SMF, the UE and the external DHCPv4 server shall be compliant to IETF RFC 2131 [18], IETF RFC 1542 [19] and IETF RFC 4039 [20].
The following system procedure describes the successful IPv4 address allocation and parameter configuration signalling flow between the SMF and the external DHCPv4 server as depicted in figure 10.2.2-1. For a detailed description of the DHCPv4 messages, refer to IETF RFC 2131 [18], IETF RFC 1542 [19] and IETF RFC 4039 [20].
1) The DHCPv4 client function in the SMF sends a DHCPDISCOVER as an IP limited broadcast message, i.e. the destination address 255.255.255.255, towards the external DN. If the SMF has the DHCPv4 server IP addresses configured for the DNN, the DHCPDISCOVER shall be send as unicast (or even multicast) to the external DHCPv4 servers.
2) Upon receiving the DHCPDISCOVER request message, the external DHCPv4 servers reply by sending a DHCPOFFER message including an offered IP address. Several DHCPOFFER messages may be received by the SMF if multiple DHCPv4 servers respond to the DHCPDISCOVER.
3) The DHCPv4 client function in the SMF processes the messages and sends a DHCPREQUEST towards the selected external DHCPv4 server.
NOTE: If the optimized signalling (Rapid Commit Option) is used as per IETF RFC 4039 [20], the messages 2-3 can be eliminated.
4) Upon receiving the DHCPREQUEST message, the selected external DHCPv4 server acknowledges the address allocation by sending a DHCPACK containing the lease period (T1), the time-out time (T2) and the configuration information requested in DHCPREQUEST. The SMF stores the allocated IPv4 address, the lease timers and the configuration parameters. The SMF shall further deliver the IPv4 address and the configuration parameters to the UE by SM NAS message.
Figure 10.2.2-1: The signalling flow for IPv4 address allocation and parameter configuration using DHCPv4
Figure 10.2.2-2 is a signalling flow for IPv4 address lease renew by using DHCPv4 protocol as specified in IETF RFC 2131 [18].
1) The DHCPv4 client function in the SMF sends a unicast DHCPREQUEST towards the external DHCPv4 server to extend the lease period of the allocated IPv4 address.
2) The external DHCPv4 server replies with a DHCPACK message confirming the renewed lease and the T1 and T2 timers are restarted.
Figure 10.2.2-2: The signalling flow for IPv4 address lease renew using DHCPv4
10.2.3 IPv6 Prefix allocation via IPv6 stateless address autoconfiguration via DHCPv6
When the IPv6 prefix is allocated from the external DN, the SMF is responsible to obtain the IPv6 prefix for external DN, allocate and release the IPv6 prefix. The SMF may use DHCPv6 to obtain the IPv6 prefix from the external DN. In this context, the SMF shall act as a DHCP client as per IETF RFC 3315 [21] towards the external DHCPv6 server.
The SMF may allocate a second IPv6 prefix for routing traffic via a second UPF to enable simultaneous access via remote and local networks or to enable SSC mode 3 (i.e. make-before-break) mobility, as described in clause 4.3.5.3 of 3GPP TS 23.502 [3].
The following system procedure describes the signalling flows for the IPv6 Stateless Address Autoconfiguration procedures for 5G system. The procedures are based on the descriptions in 3GPP TS 23.501 [2] and 3GPP TS 23.502 [3].
1. UE initiates the PDU Session Establishment procedure, indicating IPv6 address is required.
2. The AMF sends PDU Session Establishment Request in Nsmf_PDUSession_CreateSMContext to the SMF.
3. The SMF may retrieve IPv6 prefix using DHCPv6 mechanism. This procedure is performed when an external DN allocates an IPv6 prefix, the signaling between the SMF and external DN is exchanged via UPF which is omitted in the figure 10.2.3-1.
4. The SMF sends PDU Session Establishment Accept included in Namf_Communication_N1N2MessageTransfer to the AMF. It includes the IPv6 prefix.
5. The AMF sends PDU Session Establishment Accept message to the UE without the IPv6 prefix. The UE shall ignore the IPv6 prefix if it receives it in the message.
6. The UE may send a Router Solicitation to the SMF via the UPF to solicit a Router Advertisement message.
7. The SMF sends a Router Advertisement message to the UE via the UPF, solicited or unsolicited. It shall include an IPv6 prefix in Prefix Information option field of the message. The prefix is the same as the one in the PDU Session Establishment Accept message, if it is provided during the previous PDU Session Establishment procedure.
8. At any time after PDU session establishment, the SMF may trigger the establishment on an alternative route via UPF2 for access to a local data network or for SSC mode 3 mobility.
9. Like step 3, the SMF may retrieve a second IPv6 prefix using DHCPv6 mechanism.
10. The SMF sends a Router Advertisement to the UE via UPF2 to update the UE. Note that this will occur without a Router Solicitation since the UE is unaware of the network’s decision to form an alternative Route.
11. Specific to the case of SSC mode 3 mobility, the SMF sends a Router Advertisement to the UE via UPF1 with zero value in the preferred lifetime field and a value in the valid lifetime field according to IETF RFC 4862 [34]. The UE shall update the valid lifetime of the old IPv6 prefix to the signalled value, regardless of the remaining lifetime. The signalled lifetime value indicates how long the SMF is willing to keep the old IPv6 prefix.
NOTE: Alternative routes can be established repeatedly through additional UPFs and old routes can be terminated when required by the SMF. More complex scenarios are not described here for the sake of simplicity.
Figure 10.2.3-1: IPv6 Stateless Address Autoconfiguration
10.2.4 IPv6 parameter configuration via stateless DHCPv6
A UE that has obtained an IPv6 address may use stateless DHCP to request other configuration information such as a list of DNS recursive name servers or SIP servers.
For 3GPP networks, when an external DHCPv6 server in a DN is used to obtain the requested parameters, the SMF acts as a DHCPv6 client towards the external DHCPv6 server while acting a DHCPv6 server towards the UE.
The IPv6 parameter configuration via stateless DHCPv6 function in the UE, the SMF and the external DHCPv6 Server shall be compliant to IETF RFC 3736 [22]. The following system procedure describes the signalling flows for the IPv6 parameter configuration via stateless DHCPv6 procedures for 5G system. All messages in the following steps between the UE and the SMF are sent via the UPF.
1) A Router Advertisement with the O-flag set, is sent from SMF to UE to indicate to it to retrieve other configuration information.
2) The UE sends an INFORMATION-REQUEST message with the IP destination address set to the All_DHCP_Relay_Agents_and_Servers multicast address defined in the DHCPv6 IETF RFC 3315 [21]. The source address shall be the link-local address of the UE. The DHCP relay agent in the SMF shall forward the message.
3) DHCP servers receiving the forwarded INFORMATION-REQUEST message, reply by sending a RELAY‑REPLY message, with the "Relay Message" option including a REPLY message with the requested configuration parameters.
The UE chooses one of the possibly several REPLY messages and extracts the configuration information.
Figure 10.2.4-1: DHCPv6 Other configuration signal flow
10.2.5 IPv6 Prefix Delegation via DHCPv6
A RG may request IPv6 prefix allocation for UE behind the RG as specified in 3GPP TS 23.316 [43]. A SMF may receive both DHCP options for IA_NA and IA_PD together in a single DHCPv6 message, the SMF may provide a reply to both IA_NA and IA_PD in the same message or alternatively process the DHCPv6 IA_NA before the DHCPv6 IA_PD.
Optionally, a single network prefix shorter than the default /64 prefix may be assigned to a PDU Session. In this case, the /64 default prefix used for IPv6 stateless autoconfiguration will be allocated from this network prefix; the remaining address space from the network prefix can be delegated to the PDU Session using prefix delegation after the PDU session Setup/default QoS flow establishment and IPv6 prefix allocation via IPv6 stateless address autoconfiguration as defined in clause 10.2.3. When PLMN based parameter configuration is used, the SMF provides the requested IPv6 prefix from a locally provisioned pool. When external DN based IPv6 prefix allocation is used, the SMF may obtain the prefix from the external DN.
For the detailed description of the RG uses DHCPv6 to request additional IPv6 prefixes refer to 3GPP TS 23.316 [43].The use of prefix exclude option is optional, and it is possible for SMF to assign a /64 prefix using stateless address autoconfiguration and a completely different shorter prefix using DHCPv6 Prefix Delegation.
10.3 3GPP Vendor-Specific Options
This clause describes 3GPP Vender-Specific Options that will be included in DHCP messages exchanged between SMF and DHCP Server. Other DHCP options may be used as defined in DHCP RFC(s). Unless otherwise stated, when the encoding scheme of an attribute is specified as UTF-8 encoding, this shall be interpreted as UTF-8 hexadecimal encoding.
The DHCPv4 vendor specific option is encoded as per IETF RFC 2132 [47] or IETF RFC 3925 [48]. The DHCPv6 vendor specific option is encoded as per IETF RFC 8415 [49]. For DHCP vendor specific option code 17 or 125, the Enterprise Number shall be set to value 10415.
The table 10.3-1 lists the encapsulated 3GPP Vendor-Specific Options in DHCP vendor specific option (17/43/125).
Table 10.3-1: List of the encapsulated 3GPP Vendor-Specific sub-options
|
Sub-opt # |
Sub-option Name |
Presence |
|---|---|---|
|
1 |
3GPP-IP-Pool-Info |
Optional |
1 – 3GPP-IP-Pool-Info
|
DHCPv4 |
Bits |
||||||||||
|
Octets |
8 |
7 |
6 |
5 |
4 |
3 |
2 |
1 |
|||
|
1 |
VS option code = 1 |
||||||||||
|
2 |
VS option length |
||||||||||
|
3-m |
IP address pool ID |
||||||||||
|
DHCPv6 |
Bits |
||||||||||
|
Octets |
8 |
7 |
6 |
5 |
4 |
3 |
2 |
1 |
|||
|
1-2 |
VS option code = 1 |
||||||||||
|
3-4 |
VS option length |
||||||||||
|
5-m |
IP address pool ID |
||||||||||
VS option code: 1
Length: m-2 or m-4
The IP address pool ID is of Octet String type.
The SMF may determine an IP address pool ID based on UPF ID, S-NSSAI, DNN, and IP version as described in clause 5.8.2.2.1 in 3GPP TS 23.501 [2] and includes the IP address pool ID within 3GPP Vendor-Specific-Option and send it to the DHCP server. The DHCP server assigns IPv6 prefix or IPv4 address from the requested IP address pool. Multiple 3GPP-IP-Pool-Info sub-options may be sent in a DHCP request message. The DHCP server shall return the selected IP address pool ID within 3GPP Vendor-Specific-Option to the SMF in the DHCP successful response message (e.g. DHCPACK).