A UE reaching the core over WiFi has no radio bearer to carry an address in. The IKEv2 exchange with the ePDG carries it instead. This page follows that exchange down from the sequence diagram in 33.402 to the two packets that move the address.
- Tunnel Setup Sequence in 33.402
- Wireshark View of the Exchange
- Where the Address Is Requested and Assigned
- Example 1
- Reference
Tunnel Setup Sequence in 33.402
UE IP allocation and various server IP can be assinged to UE over ePDG. This IP allocation happens during the IKE process when UE first go through ePDG. Overall IKE(key exchanging) protocol sequence in 33.402 is as shown below. (This is from Figure 8.2.2-1).
Don't bother looking into each of these steps, only two of the steps in this sequence gets involved in the IP allocation. The simpler version of sequence will be shown after this figure. (If you are really interested in the details of each of these steps, refer to IKE page)
33.402 clause 8.2.2 names the two steps that matter here. At step 2 the UE sends the configuration payload, CFG_REQUEST, inside the IKE_AUTH request message, to obtain an IPv4 or IPv6 home address. At step 14 the ePDG puts the assigned remote IP address into the configuration payload, CFG_REPLY. Step 15 is the message that carries it, together with the AUTH parameter, the security associations and the rest of the IKEv2 parameters.
Everything between those two steps authenticates the subscriber. Steps 3 to 11 run EAP-AKA between the UE and the 3GPP AAA server, with the ePDG relaying and the HSS supplying vectors. The address is settled during that gap, and nothing about it crosses the WiFi link until step 15.
The pictures above are one figure : 33.402 Figure 8.2.2-1, split across three images, running from the IKE_SA_INIT pair to the final IKE_AUTH response.Only steps 2 and 15 carry the address : one asks and one answers, and every step between them belongs to the authentication.The ePDG is the network end of the tunnel : 33.402 clause 8.2.2 puts it there, and terminates the UE's authentication in the 3GPP AAA server instead.The configuration payload is the carrier : the same clause requires the UE to use it to obtain the remote IP address.
Wireshark View of the Exchange
The figure above is the specification's view of the exchange. A capture taken at the UE or at the WiFi access point shows fewer messages, because the steps between the ePDG and the core never cross the air interface. The two screenshots below show the same exchange at two levels of decoding.
The Log Without Decryption
If you have the IP log at the UE and WiFi AP, you may see only following part (the steps happening at core network parts will not be captured at this terminal log). I put the step number in parethesis to match each line on the wireshark to the step number in the figure shown above. This is ISAKMP log that is not decoded. So you would not get the full details from this log except step (1).
Eight frames carry the whole exchange : the numbers in brackets at the right are the author's, and they map each frame to a step of 33.402 Figure 8.2.2-1.The first two frames are IKE_SA_INIT : both are marked 1, because the figure counts the pair as one step.The other six are IKE_AUTH : steps 2, 6, 7, 11, 12 and 15, in that order down the screen.The Info column stops at the exchange type : without the keys the decoder cannot reach the payloads, so the frame lengths are the only other clue on the screen.
The Log With the Encrypted Payload Decoded
Wireshark can open the IKE_AUTH payloads when it is given the keys. The same eight frames then show what each one carries, and the EAP exchange inside steps 6, 7 and 11 becomes visible.
If you managed to decode the whole ISAKMP packet including the Encrypted Payload part, you will see the wireshark log as shown below.
Three frames change protocol : the ones marked 6, 7 and 11 are now listed as EAP rather than ISAKMP. Their Info column names the AKA challenge, the response and the success.The endpoint columns name the two roles : initiator and responder, where the screenshot above gives only source and destination.The two screenshots are not the same capture : the third and fourth frames measure 342 and 310 octets in the one above and 358 and 398 in this one.The step numbering survives both : 1, 2, 6, 7, 11, 12 and 15 appear in both screenshots, so the mapping to 33.402 Figure 8.2.2-1 holds either way.
Where the Address Is Requested and Assigned
To point out only the steps that are involved in IP allocation, it can be summarized as shown below. At step 2, UE can request IP configuration (UE IP, DNS IP and other server IP) and network (ePDG) can allocate all of the requested IP at step 15. (This request and reply process is similar to the IP allocation process by 'PDN Connectivity Request' and 'Activate Default EPS Bearer Request').
24.302 clause 7.2.2.1 gives the length field of that attribute a second job. For an initial attach the UE includes INTERNAL_IP4_ADDRESS or INTERNAL_IP6_ADDRESS with no value and the length set to zero. For a handover attach the UE puts its previously allocated address in the same attribute, and the ePDG reads that as a request to keep it.
So the attribute that asks for an address also says which kind of attach this is. An empty one asks for anything the network has. A filled one asks for one particular address back. The capture further down this page is the empty form throughout, which marks it as an initial attach.
A UE that sends no configuration payload still gets an address : the ePDG assigns one on its own, which is the right half of the diagram above.The assigned address becomes the inner address of the tunnel : the note at the left of the diagram says so, and every ESP packet the UE sends afterwards carries it inside.An empty attribute and a filled one mean different things : 24.302 clause 7.2.2.1 reads the empty form as an initial attach and the filled form as a handover attach.Two steps touch the address and no others : the diagram marks both of them against 33.402 Figure 8.2.2-1.
Example 1
The capture below is one IKE_AUTH exchange, taken apart into the request and the response that answers it. Both are boxed as they arrived. The author's colours mark the fields the sections above have been describing.
What the UE Asks For
This is the step 2 message. The configuration payload sits after the two identification payloads, and it carries nine attributes. Every one of them has length zero, so the message asks for kinds of address and names no values.
Wireshark decode of the step 2 IKE_AUTH request,
CFG Request (in Step 2 ) ------------------------------------------------------------------------
Internet Security Association and Key Management Protocol
Initiator SPI: 63b6607c34cf9e41
Responder SPI: aaaaaaaaaaaaaaaa
Next payload: Encrypted and Authenticated (46)
Version: 2.0
0010 .... = MjVer: 0x02
.... 0000 = MnVer: 0x00
Exchange type: IKE_AUTH (35)
Flags: 0x08 (Initiator, No higher version, Request)
.... 1... = Initiator: Initiator
...0 .... = Version: No higher version
..0. .... = Response: Request
Message ID: 0x00000001
Length: 428
Type Payload: Encrypted and Authenticated (46)
Next payload: Identification - Initiator (35)
0... .... = Critical Bit: Not Critical
Payload length: 400
Initialization Vector: 2e25ced9813fef344057cd7c1284b750 (16 bytes)
Encrypted Data (368 bytes)
Decrypted Data (368 bytes)
Contained Data (351 bytes)
Type Payload: Identification - Initiator (35)
Next payload: Identification - Responder (36)
0... .... = Critical Bit: Not Critical
Payload length: 80
ID type: ID_RFC822_ADDR (3)
Protocol ID: Unused
Port: Unused
Identification Data:0001010123456789@5C-A4-8A-1F-59-50
:nai.epc.mnc001.mcc001.3gppnetwork.org
ID_FQDN: 0001010123456789@5C-A4-8A-1F-59-50
:nai.epc.mnc001.mcc001.3gppnetwork.org
Type Payload: Identification - Responder (36)
Next payload: Configuration (47)
0... .... = Critical Bit: Not Critical
Payload length: 11
ID type: KEY_ID (11)
Protocol ID: Unused
Port: Unused
Identification Data:
ID_KEY_ID: 696d73
Type Payload: Configuration (47)
Next payload: Security Association (33)
0... .... = Critical Bit: Not Critical
Payload length: 44
Type: CFG_REQUEST (1)
Attribute Type: (t=16390,l=0) PRIVATE USE // 16390 indicate IPv6 P-CSCF
Type: PRIVATE USE (16390)
0... .... .... .... = Config Attribute Format: Type/Length/Value (TLV)
Length: 0
Attribut value is empty
Attribute Type: (t=10,l=0) INTERNAL_IP6_DNS
Type: INTERNAL_IP6_DNS (10)
0... .... .... .... = Config Attribute Format: Type/Length/Value (TLV)
Length: 0
Attribut value is empty
Attribute Type: (t=10,l=0) INTERNAL_IP6_DNS
Type: INTERNAL_IP6_DNS (10)
0... .... .... .... = Config Attribute Format: Type/Length/Value (TLV)
Length: 0
Attribut value is empty
Attribute Type: (t=8,l=0) INTERNAL_IP6_ADDRESS
Type: INTERNAL_IP6_ADDRESS (8)
0... .... .... .... = Config Attribute Format: Type/Length/Value (TLV)
Length: 0
Attribut value is empty
Attribute Type: (t=16389,l=0) PRIVATE USE // 16389 indicate IPv4 P-CSCF
Type: PRIVATE USE (16389)
0... .... .... .... = Config Attribute Format: Type/Length/Value (TLV)
Length: 0
Attribut value is empty
Attribute Type: (t=3,l=0) INTERNAL_IP4_DNS
Type: INTERNAL_IP4_DNS (3)
0... .... .... .... = Config Attribute Format: Type/Length/Value (TLV)
Length: 0
Attribut value is empty
Attribute Type: (t=3,l=0) INTERNAL_IP4_DNS
Type: INTERNAL_IP4_DNS (3)
0... .... .... .... = Config Attribute Format: Type/Length/Value (TLV)
Length: 0
Attribut value is empty
Attribute Type: (t=2,l=0) INTERNAL_IP4_NETMASK
Type: INTERNAL_IP4_NETMASK (2)
0... .... .... .... = Config Attribute Format: Type/Length/Value (TLV)
Length: 0
Attribut value is empty
Attribute Type: (t=1,l=0) INTERNAL_IP4_ADDRESS
Type: INTERNAL_IP4_ADDRESS (1)
0... .... .... .... = Config Attribute Format: Type/Length/Value (TLV)
Length: 0
Attribut value is empty
Type Payload: Security Association (33)
Next payload: Traffic Selector - Initiator (44)
0... .... = Critical Bit: Not Critical
Payload length: 88
Type Payload: Proposal (2) # 1
Next payload: NONE / No Next Payload (0)
0... .... = Critical Bit: Not Critical
Payload length: 84
Proposal number: 1
Protocol ID: ESP (3)
SPI Size: 4
Proposal transforms: 8
SPI: 217ab815
Type Payload: Transform (3)
Next payload: Transform (3)
0... .... = Critical Bit: Not Critical
Payload length: 8
Transform Type: Encryption Algorithm (ENCR) (1)
Transform ID (ENCR): ENCR_DES (2)
Type Payload: Transform (3)
Next payload: Transform (3)
0... .... = Critical Bit: Not Critical
Payload length: 8
Transform Type: Encryption Algorithm (ENCR) (1)
Transform ID (ENCR): ENCR_3DES (3)
Type Payload: Transform (3)
Next payload: Transform (3)
0... .... = Critical Bit: Not Critical
Payload length: 12
Transform Type: Encryption Algorithm (ENCR) (1)
Transform ID (ENCR): ENCR_AES_CBC (12)
Transform IKE2 Attribute Type (t=14,l=2) Key-Length : 128
1... .... .... .... = Transform IKE2 Format: Type/Value (TV)
Transform IKE2 Attribute Type: Key-Length (14)
Value: 0080
Key Length: 128
Type Payload: Transform (3)
Next payload: Transform (3)
0... .... = Critical Bit: Not Critical
Payload length: 12
Transform Type: Encryption Algorithm (ENCR) (1)
Transform ID (ENCR): ENCR_AES_CBC (12)
Transform IKE2 Attribute Type (t=14,l=2) Key-Length : 256
1... .... .... .... = Transform IKE2 Format: Type/Value (TV)
Transform IKE2 Attribute Type: Key-Length (14)
Value: 0100
Key Length: 256
Type Payload: Transform (3)
Next payload: Transform (3)
0... .... = Critical Bit: Not Critical
Payload length: 8
Transform Type: Integrity Algorithm (INTEG) (3)
Transform ID (INTEG): AUTH_HMAC_MD5_96 (1)
Type Payload: Transform (3)
Next payload: Transform (3)
0... .... = Critical Bit: Not Critical
Payload length: 8
Transform Type: Integrity Algorithm (INTEG) (3)
Transform ID (INTEG): AUTH_AES_XCBC_96 (5)
Type Payload: Transform (3)
Next payload: Transform (3)
0... .... = Critical Bit: Not Critical
Payload length: 8
Transform Type: Integrity Algorithm (INTEG) (3)
Transform ID (INTEG): AUTH_HMAC_SHA1_96 (2)
Type Payload: Transform (3)
Next payload: NONE / No Next Payload (0)
0... .... = Critical Bit: Not Critical
Payload length: 8
Transform Type: Extended Sequence Numbers (ESN) (5)
Transform ID (ESN): No Extended Sequence Numbers (0)
Type Payload: Traffic Selector - Initiator (44) # 2
Next payload: Traffic Selector - Responder (45)
0... .... = Critical Bit: Not Critical
Payload length: 64
Number of Traffic Selector: 2
Traffic Selector Type: TS_IPV4_ADDR_RANGE (7)
Protocol ID: Unused
Selector Length: 16
Start Port: 0
End Port: 65535
Starting Addr: 0.0.0.0 (0.0.0.0)
Ending Addr: 255.255.255.255 (255.255.255.255)
Traffic Selector Type: TS_IPV6_ADDR_RANGE (8)
Protocol ID: Unused
Selector Length: 40
Start Port: 0
End Port: 65535
Starting Addr: :: (::)
Ending Addr: ffff:ffff:ffff:ffff:ffff:ffff:ffff:ffff
(ffff:ffff:ffff:ffff:ffff:ffff:ffff:ffff)
Type Payload: Traffic Selector - Responder (45) # 2
Next payload: NONE / No Next Payload (0)
0... .... = Critical Bit: Not Critical
Payload length: 64
Number of Traffic Selector: 2
Traffic Selector Type: TS_IPV4_ADDR_RANGE (7)
Protocol ID: Unused
Selector Length: 16
Start Port: 0
End Port: 65535
Starting Addr: 0.0.0.0 (0.0.0.0)
Ending Addr: 255.255.255.255 (255.255.255.255)
Traffic Selector Type: TS_IPV6_ADDR_RANGE (8)
Protocol ID: Unused
Selector Length: 40
Start Port: 0
End Port: 65535
Starting Addr: :: (::)
Ending Addr: ffff:ffff:ffff:ffff:ffff:ffff:ffff:ffff
(ffff:ffff:ffff:ffff:ffff:ffff:ffff:ffff)
Nine attributes go up and all of them are empty : two private use types, two for IPv6 DNS and one for the IPv6 address. Two more ask for IPv4 DNS, one for the netmask and one for the address.The two private use types are the P-CSCF request : 16389 and 16390 fall in the private use range. The decoder can only print PRIVATE USE, and the author's green comment supplies the meaning.Asking twice does not guarantee two answers : 24.302 clause 7.4.1.1 has the ePDG return the same attribute carrying zero or more DNS server addresses.The identification payloads name the subscriber and the APN : ID_RFC822_ADDR carries the NAI, and the responder identity carries KEY_ID 696d73, which reads as ims.
The payload length is checkable against the attribute list. 24.302 clause 8.2.4.1 draws a configuration attribute as a reserved bit, a fifteen bit attribute type, a two octet length field, and then the value. An empty attribute is therefore four octets, and nine of them make 36. The decoder prints 44, so the configuration payload carries eight octets of header in front of its attributes.
The security association below the configuration payload offers eight transforms. Two of them are DES and triple DES. Two more are AES in CBC mode at 128 and at 256 bits, three are integrity algorithms, and the last one turns extended sequence numbers off. The traffic selectors under that ask for everything, from 0.0.0.0 to 255.255.255.255 and from the all zero IPv6 address to the all ones one.
What the ePDG Assigns
This is the step 15 message. The configuration payload now carries ten attributes rather than nine, and every one of them has a value. The extra attribute is one the UE never asked for.
Wireshark decode of the step 15 IKE_AUTH response,
CFG Response (in Step 15 ) ------------------------------------------------------------------------
Internet Security Association and Key Management Protocol
Initiator SPI: 63b6607c34cf9e41
Responder SPI: aaaaaaaaaaaaaaaa
Next payload: Encrypted and Authenticated (46)
Version: 2.0
0010 .... = MjVer: 0x02
.... 0000 = MnVer: 0x00
Exchange type: IKE_AUTH (35)
Flags: 0x20 (Responder, No higher version, Response)
.... 0... = Initiator: Responder
...0 .... = Version: No higher version
..1. .... = Response: Response
Message ID: 0x00000003
Length: 476
Type Payload: Encrypted and Authenticated (46)
Next payload: Authentication (39)
0... .... = Critical Bit: Not Critical
Payload length: 448
Initialization Vector: aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa (16 bytes)
Encrypted Data (416 bytes)
Decrypted Data (416 bytes)
Contained Data (367 bytes)
Type Payload: Authentication (39)
Next payload: Configuration (47)
0... .... = Critical Bit: Not Critical
Payload length: 28
Authentication Method: Shared Key Message Integrity Code (2)
Authentication Data: 5d3b1198bca744070d15361c12a611cbdce1c2ed
Type Payload: Configuration (47)
Next payload: Security Association (33)
0... .... = Critical Bit: Not Critical
Payload length: 151
Type: CFG_REPLY (2)
Attribute Type: (t=1,l=4) INTERNAL_IP4_ADDRESS
Type: INTERNAL_IP4_ADDRESS (1)
0... .... .... .... = Config Attribute Format: Type/Length/Value (TLV)
Length: 4
Value: c0a80101
INTERNAL IP4 ADDRESS: 192.168.1.1 (192.168.1.1)
Attribute Type: (t=2,l=4) INTERNAL_IP4_NETMASK
Type: INTERNAL_IP4_NETMASK (2)
0... .... .... .... = Config Attribute Format: Type/Length/Value (TLV)
Length: 4
Value: ffffff00
INTERNAL IP4 NETMASK: 255.255.255.0 (255.255.255.0)
Attribute Type: (t=3,l=4) INTERNAL_IP4_DNS
Type: INTERNAL_IP4_DNS (3)
0... .... .... .... = Config Attribute Format: Type/Length/Value (TLV)
Length: 4
Value: c0a80102
INTERNAL IP4 DNS: 192.168.1.2 (192.168.1.2)
Attribute Type: (t=3,l=4) INTERNAL_IP4_DNS
Type: INTERNAL_IP4_DNS (3)
0... .... .... .... = Config Attribute Format: Type/Length/Value (TLV)
Length: 4
Value: c0a80103
INTERNAL IP4 DNS: 192.168.1.3 (192.168.1.3)
Attribute Type: (t=16389,l=4) PRIVATE USE // 16389 indicate IPv4 P-CSCF
Type: PRIVATE USE (16389)
0... .... .... .... = Config Attribute Format: Type/Length/Value (TLV)
Length: 4
Value: c0a80102
Attribute Type: (t=8,l=17) INTERNAL_IP6_ADDRESS
Type: INTERNAL_IP6_ADDRESS (8)
0... .... .... .... = Config Attribute Format: Type/Length/Value (TLV)
Length: 17
Value: 2001000000000001000000000000000140
Attribute Type: (t=15,l=17) INTERNAL_IP6_SUBNET
Type: INTERNAL_IP6_SUBNET (15)
0... .... .... .... = Config Attribute Format: Type/Length/Value (TLV)
Length: 17
Value: 2001000000000001000000000000000040
INTERNAL_IP6_SUBNET (IP): 2001:0:0:1:: (2001:0:0:1::)
INTERNAL_IP6_SUBNET (PREFIX): 64
Attribute Type: (t=10,l=16) INTERNAL_IP6_DNS
Type: INTERNAL_IP6_DNS (10)
0... .... .... .... = Config Attribute Format: Type/Length/Value (TLV)
Length: 16
Value: 20010000000000010000000000000002
INTERNAL IP6 DNS: 2001:0:0:1::2 (2001:0:0:1::2)
Attribute Type: (t=10,l=16) INTERNAL_IP6_DNS
Type: INTERNAL_IP6_DNS (10)
0... .... .... .... = Config Attribute Format: Type/Length/Value (TLV)
Length: 16
Value: 20010000000000010000000000000003
INTERNAL IP6 DNS: 2001:0:0:1::3 (2001:0:0:1::3)
Attribute Type: (t=16390,l=17) PRIVATE USE // 16390 indicate IPv6 P-CSCF
Type: PRIVATE USE (16390)
0... .... .... .... = Config Attribute Format: Type/Length/Value (TLV)
Length: 17
Value: 2001000000000001000000000000000240
Type Payload: Security Association (33)
Next payload: Traffic Selector - Initiator (44)
0... .... = Critical Bit: Not Critical
Payload length: 44
Type Payload: Proposal (2) # 1
Next payload: NONE / No Next Payload (0)
0... .... = Critical Bit: Not Critical
Payload length: 40
Proposal number: 1
Protocol ID: ESP (3)
SPI Size: 4
Proposal transforms: 3
SPI: bbbbbbbb
Type Payload: Transform (3)
Next payload: Transform (3)
0... .... = Critical Bit: Not Critical
Payload length: 12
Transform Type: Encryption Algorithm (ENCR) (1)
Transform ID (ENCR): ENCR_AES_CBC (12)
Transform IKE2 Attribute Type (t=14,l=2) Key-Length : 128
1... .... .... .... = Transform IKE2 Format: Type/Value (TV)
Transform IKE2 Attribute Type: Key-Length (14)
Value: 0080
Key Length: 128
Type Payload: Transform (3)
Next payload: Transform (3)
0... .... = Critical Bit: Not Critical
Payload length: 8
Transform Type: Integrity Algorithm (INTEG) (3)
Transform ID (INTEG): AUTH_HMAC_SHA1_96 (2)
Type Payload: Transform (3)
Next payload: NONE / No Next Payload (0)
0... .... = Critical Bit: Not Critical
Payload length: 8
Transform Type: Extended Sequence Numbers (ESN) (5)
Transform ID (ESN): No Extended Sequence Numbers (0)
Type Payload: Traffic Selector - Initiator (44) # 2
Next payload: Traffic Selector - Responder (45)
0... .... = Critical Bit: Not Critical
Payload length: 64
Number of Traffic Selector: 2
Traffic Selector Type: TS_IPV4_ADDR_RANGE (7)
Protocol ID: Unused
Selector Length: 16
Start Port: 0
End Port: 65535
Starting Addr: 0.0.0.0 (0.0.0.0)
Ending Addr: 255.255.255.255 (255.255.255.255)
Traffic Selector Type: TS_IPV6_ADDR_RANGE (8)
Protocol ID: Unused
Selector Length: 40
Start Port: 0
End Port: 65535
Starting Addr: 2001:0:0:1:: (2001:0:0:1::)
Ending Addr: 2001::1:ffff:ffff:ffff:ffff (2001::1:ffff:ffff:ffff:ffff)
Type Payload: Traffic Selector - Responder (45) # 2
Next payload: Notify (41)
0... .... = Critical Bit: Not Critical
Payload length: 64
Number of Traffic Selector: 2
Traffic Selector Type: TS_IPV4_ADDR_RANGE (7)
Protocol ID: Unused
Selector Length: 16
Start Port: 0
End Port: 65535
Starting Addr: 0.0.0.0 (0.0.0.0)
Ending Addr: 255.255.255.255 (255.255.255.255)
Traffic Selector Type: TS_IPV6_ADDR_RANGE (8)
Protocol ID: Unused
Selector Length: 40
Start Port: 0
End Port: 65535
Starting Addr: :: (::)
Ending Addr: ffff:ffff:ffff:ffff:ffff:ffff:ffff:ffff
(ffff:ffff:ffff:ffff:ffff:ffff:ffff:ffff)
Type Payload: Notify (41)
Next payload: Notify (41)
0... .... = Critical Bit: Not Critical
Payload length: 8
Protocol ID: ESP (3)
SPI Size: 0
Notify Message Type: ESP_TFC_PADDING_NOT_SUPPORTED (16394)
Notification DATA: <MISSING>
Type Payload: Notify (41)
Next payload: NONE / No Next Payload (0)
0... .... = Critical Bit: Not Critical
Payload length: 8
Protocol ID: ESP (3)
SPI Size: 0
Notify Message Type: NON_FIRST_FRAGMENTS_ALSO (16395)
Notification DATA: <MISSING>
Padding (48 bytes)
Pad Length: 48
Integrity Checksum Data: 9d545b54aaae0a597e1aed4a (12 bytes)[correct]
The UE is given 192.168.1.1 behind a 24 bit mask : INTERNAL_IP4_ADDRESS carries c0a80101 and INTERNAL_IP4_NETMASK carries ffffff00.Two IPv4 DNS servers come back : 192.168.1.2 and 192.168.1.3, one for each attribute the UE sent.The IPv6 side arrives as a prefix rather than an address : the seventeen octet values end in 40, which is a prefix length of 64.One attribute arrives unasked : INTERNAL_IP6_SUBNET was not in the request, and 24.302 clause 7.4.1.1 lets the ePDG use it for the IPv6 home network prefix.The P-CSCF answers repeat the DNS addresses : the IPv4 private use attribute returns 192.168.1.2, and the IPv6 one returns 2001:0:0:1::2.
The same arithmetic works on this side. Five attributes carry four octets, three carry seventeen and two carry sixteen, and each one adds its four octet header, which comes to 143. The decoder prints 151, which is the same eight octets of payload header the request showed.
The INTERNAL_IP6_ADDRESS and INTERNAL_IP6_SUBNET values differ only in their last address octet. One holds 2001:0:0:1::1 and the other holds 2001:0:0:1::, and both end in 40. A note in 24.302 clause 7.4.1.1 covers that case. When either attribute is present, the UE considers only the IPv6 home network prefix defined by the prefix length value, so the last octet never reaches the UE's address configuration.
The security association narrows as well. Three transforms survive the eight the UE offered, which are AES in CBC mode at 128 bits, AUTH_HMAC_SHA1_96, and extended sequence numbers off. The initiator traffic selector narrows with them. The UE asked for the whole IPv6 range, and the ePDG answers with 2001:0:0:1:: up to the top of that same 64 bit prefix.
The reply adds one attribute and drops five transforms : INTERNAL_IP6_SUBNET was never asked for, and the eight transforms come back as three.Both payload lengths agree with their attribute lists : 36 plus 8 going up, and 143 plus 8 coming down.Length zero going up and a value coming down : the same attribute type does both jobs, and the direction settles which.The traffic selector is where the assignment becomes visible again : the ePDG narrows the initiator selector to the prefix it has just assigned.
Reference
[1] 33.402 : 3GPP - System Architecture Evolution; Security aspects of non-3GPP accesses, v19.0.0. Clause 8.2.2 and Figure 8.2.2-1 give the tunnel full authentication and authorization sequence, with the CFG_REQUEST at step 2 and the CFG_REPLY at steps 14 and 15.
[2] 24.302 : 3GPP - Access to the 3GPP Evolved Packet Core via non-3GPP access networks; Stage 3, v19.0.0. Clause 7.2.2.1 gives what the UE puts in the CFG_REQUEST and what an empty length field means, clause 7.4.1.1 gives what the ePDG returns, and clause 8.2.4.1 gives the shape of a configuration attribute.