[Shellghostt]

Description

IE_UE_IP_Address decoded octet 5 as a 5-bit spare followed by SD, V4 and V6, but 3GPP TS 29.244 clause 8.2.62 assigns bits 4 to 7 to IPv6D, CHV4, CHV6 and IP6PL, and only bit 8 is spare. The IPv6 prefix delegation bits and the IPv6 prefix length that IPv6D and IP6PL announce were left in extra_data.

IE_UE_IP_Address(bytes.fromhex("005d000110")).show()

now shows CHV4 = 1, and the two optional octets that follow the IPv6 address are decoded as well.

fixes #5282

This message was written with the help of AI (DeepSeek V4.1 Flash).

[gpotter2]

Hi, can you share that spec, or at least the extract where that's explained? Thanks

[Shellghostt]

The spec is 3GPP TS 29.244 V20.1.0, clause 8.2.62 and Figure 8.2.62-1. 3GPP hosts it at https://www.3gpp.org/ftp/Specs/archive/29_series/29.244/29244-k10.zip and the docx is inside the zip.

Octet 5 is, from bit 8 to bit 1, Spare, IP6PL, CHV6, CHV4, IPv6D, S/D, V4, V6. The clause says bit 4 is IPv6D, and if it is set to 1 the IPv6 Prefix Delegation Bits field shall be present. Bit 5 is CHV4, and if it is set to 1 the IPv4 address shall not be present and the UP function shall assign an IPv4 address. Bit 6 is CHV6, with the same meaning for IPv6. Bit 7 is IP6PL, and if it is set to 1 the IPv6 Prefix Length field shall be present. Bit 8 is spare. Octets r and s carry the delegation bits and the prefix length as 8-bit integers.

I also checked the bit positions against Wireshark's packet-pfcp.c, which uses the same ones. While preparing this I noticed my second test case set IPv6D and IP6PL together, which the clause does not define, so I split it into one case with IPv6D and one with IP6PL.