Cisco Cisco Packet Data Gateway (PDG)

Previous Behavior: Earlier, if the result of the UDPv6 checksum calculation is zero, GW used to send the
same, which effectively disables checksum for that packet. This was not compliant with the RFC2460, which
suggests the checksum value to be set to 0xFFFF if derived calculation is zero.

New Behavior: After the fix, the checksum value is set to 0xFFFF if the result checksum calculation is ZERO
and the compliance is met.

Impact on customer: Packet drops might be seen at peer, which does not support of handling packet with
0xFFFF checksum as suggested by the RFC.

CSCuz27274 - DHCPv6 related GTPU packets counted as data packets at sessmgr

Applicable Products: GGSN

Old Behavior: DHCPv6 uplink control packets were getting counted for charging.

New Behavior: This cdet retains the packet counting behavior. However, the charging of DHCPv6 packets
in the up-link direction for GGSN has been stopped.

Impact on Customer: GGSN Uplink DHCPv6 control packets are not charged.

CSCuz45804 - Issue in DSCP Marking in PPP Call

Applicable Products: GGSN

Previous Behavior: A PPP call was established after doing the following configuration:

• QCI-QoS mapping table was configured in an APN

• DSCP values were configured in the GGSN service

The DSCP marking for the downlink encapsulation packets was not as expected. The downlink packets must
have selected values from the QCI-QoS mapping table, as it did in an IPv4 call. However, instead of picking
values from the QCI-QoS mapping table, it selected values from the GGSN-service configuration.

For an IPv4 call, the DSCP marking for the downlink encapsulation was as configured in the QCI-QoS
mapping table.

New Behavior: A PPP call or an IPv4 call is established after doing the following configuration:

• QCI-QoS mapping table is configured in an APN