9 IP Version Interworking at the IBCF/I-BGF

29.4213GPPEndorsement of 3GPP TS 29.162 Interworking between IM CN Sub-system and IP networksNGN Release 1Release 8TISPANTS

9.1 Control plane interworking

9.1.1 Originating Session Set-up to SIP network using different IP version

9.1.1.1 Receipt of the first SDP offer

Upon receipt of the first SDP offer the IBCF:

  • provides to the RACS the IPv6 address(es) (respectively IPv4 address(es)) and port number(s) as received in the c-line(s) and m-line(s) in the SDP; and
  • requests the RACS to bind corresponding IPv4 address(es) (respectively IPv6 address(es)) and port number(s) from its pool to the received IPv6 address(es) (respectively IPv4 address(es))and port number(s) to enable the routing of user plane traffic from the SIP network using different IP version through the I-BGF.

When the IBCF has received the requested information from the RACS the IBCF shall include the IPv4 address(es) (respectively IPv6 address(es)) and port number(s) in a new offer, which shall be sent to the IPv4 network (respectively IPv6 network). The IBCF shall create a SIP message in accordance with the rules for the IBCF described in
ES 283 003 (see bibliography) with the following clarification:

  • The IPv4 address(es) (respectively IPv6 address(es)) and port number(s) shall replace the IPv6 address(es) (respectively IPv4 address(es)) and port number(s) in the SDP.
  • The IBCF shall create a Record-Route header containing its own SIP URI.

9.1.1.2 Receipt of the first SDP answer

At the receipt of the first SDP answer from the IPv4 network (respectively IPv6 network) the IBCF:

  • provides to the RACS the IPv4 address(es) (respectively IPv6 address(es)) and port number(s) as received in the c-line(s) and m-line(s) in the SDP; and
  • requests the RACS to bind corresponding IPv6 address(es) (respectively IPv4 address(es)) and port number(s) from its pool to the received IPv4 address(es) (respectively IPv6 address(es)) and port number(s) to enable the routing of user plane traffic towards the IPv4 network (respectively IPv6 network) through the I-BGF.

When the IBCF has received the requested information, the IBCF shall send an SDP answer to the IPv6 network (respectively IPv4 network). The IBCF shall create the SIP message in accordance with the rules for the IBCF described in ES 283 003 (see bibliography) with the following clarification:

  • The IPv6 address(es) (respectively IPv4 address(es)) and port number(s) shall replace the received IPv4 address(es) (respectively IPv6 address(es)) and port number(s) in the SDP.

9.1.2 Terminating Session set-up from SIP network using different IP version

9.1.2.1 Receipt of an SDP offer

At the receipt of the first SDP offer the IBCF:

  • provides to the RACS the IPv4 address(es) (respectively IPv6 address(es)) and port number(s) as received in the c-lin(es) and m-lin(es) in the SDP; and
  • requests the RACS to bind corresponding IPv6 address(es) (respectively IPv4 address(es)) and port number(s) from its pool to the received IPv4 address(es) (respectively IPv6 address(es)) and port number(s) to enable the routing of user plane traffic towards the IPv4 network (respectively IPv6 network) through the I-BGF.

When the IBCF has received the requested information from the RACS the IBCF shall send an SDP offer to the IPv6 network (respectively IPv4 network). The IBCF shall create a SIP message in accordance with the rules for the IBCF described in ES 283 003 (see bibliography) with the following clarifications:

  • The IPv6 address(es) (respectively IPv4 address(es)) and port number(s) shall replace the received IPv4 address(es) (respectively IPv6 address(es)) and port number(s) in the SDP.
  • The IBCF shall create a Record-Route header containing its own SIP URI if the SIP message is a request.

9.1.2.2 Receipt of SDP answer

At the receipt of a SDP answer from the IPv6 network (respectively IPv4 network) the IBCF:

  • Provides to the RACS the IPv6 address(es) (respectively IPv4 address(es)) and port number(s) as received in the c-line(s) and m-line(s) in the SDP.
  • Requests the RACS to bind corresponding IPv4 address(es) (respectively IPv6 address(es)) and port number(s) from its pool with the received IPv6 address(es) (respectively IPv4 address(es)) and port number(s) to enable the routing of user plane traffic from the IPv4 network (respectively IPv6 network) through the
    I-BGF.

When the IBCF has received the requested information, the IBCF shall send a SDP answer to the IPv4 network (respectively IPv6 network). The IBCF shall create the SIP message in accordance with the rules for the IBCF described in ES 283 003 (see bibliography) with the following clarification:

  • The IPv4 address(es) (respectively IPv6 network) and port number(s) shall replace the received IPv6 address(es) (respectively IPv4 address(es)) and port number(s) in the SDP.

9.1.3 Change of connection information

After the dialog is established it is possible for both ends of the session to change the connection data for the session. When the IBCF receives a SDP offer/answer where port number(s) or IP address(es) is included., there are four different possibilities:

1) IP address(es) or/and port number(s) have been added. In this case additional binding(s) shall be provided by the RACS to the IBCF as detailed for the first SDP offer in the clauses above;

2) IP address(es) or/and port number(s) have been deleted. In this case binding(s) shall be made free by the RACS;

3) IP address(es) and port number(s) have been reassigned of the users. In this case the binding(s) shall reflect the reassignment;

4) No change has been made to the IP address(es) and port number(s). In this case no change shall be made to the existing binding(s).

9.1.4 Release of the session

At the receipt of BYE, CANCEL request or non 200 final responses the IBCF shall release the session and request the RACS to release the bindings established for the session.

9.2 User plane transport

9.2.1 Payload transport

The I-BGF shall use the established bindings described above to transport the messages between the IPv6 network and IPv4 network in the following way.

At the receipt of a payload message the I-BGF shall:

  • Replace the received IPv4 address(es) and port number(s) in the payload message with the corresponding IPv6 address(es) and port number(s).
  • Replace the received IPv6 address(es) and port number(s) in the payload message with the corresponding IPv4 address(es) and port number(s).

9.2.2 IP header interworking

9.2.2.1 IPv4 to IPv6

When the I-BGF receives an IPv4 message the following codings shall be set in the IPv6 headers of the message sent to the IPv6 network.

  • If the DF bit is set and the packet is not a fragment (i.e. the MF flag is not set and the Fragment Offset is zero) The IPv6 headers shall be set as described in table 1.
  • If the DF bit is not set or the packet is a fragment the IPv6 headers shall be set as described in table 2.

Table 1: Derivation of IPv6 Header from IPv4 header (no fragmentation)

IPv6 field

Value

Version

6

Traffic Class

The default behaviour is that the value of the IPv6 field Traffic Class field is the value of the IPv4 Type Of Service field (all 8 bits are copied). An implementation of a I-BGF should also provide the ability to ignore the value of the IPv4 Type of Service and always set the IPv6 traffic class field to zero.

Flow label

The Ipv6 Flow Label Field is set to 0 (all zero bits).

Payload Length

The IPv6 Payload Length field value is the IPv4 Total length field value minus the size of the IPv4 header and IPv4 options field length, if present.

Next Header

The IPv6 Next Header value is copied from IPv4 Protocol field.

Hop Limit

The IPv6 Hop Limit value is The value of IPv4 field Time To Live minus 1.

Source Address

Shall be handled as the addresses of the payload message as described in clause 9.2.1.

Destination Address

Shall be handled as the addresses of the payload message as described in clause 9.2.1.

Table 2: Derivation of IPv6 Header from IPv4 Header (fragmentation)

IPv6 field

Value

Version

6

Traffic Class

The default behaviour is that the value of the IPv6 field Traffic Class field is the value of the IPv4 Type Of Service field (all 8 bits are copied). An implementation of a I-BGF should also provide the ability to ignore the value of the IPv4 Type of Service and always set the IPv6 traffic class field to zero.

Flow label

The Ipv6 Flow Label Field is set to 0 (all zero bits).

Payload Length

The IPv6 Payload Length field value is the IPv4 Total length field value plus 8 for the fragment header minus the size of the IPv4 header and IPv4 options field length, if present.

Next Header

The IPv6 Next header field is set to Fragment header (44).

Hop Limit

The IPv6 Hop Limit value is The value of IPv4 field Time To Live minus 1.

Source Address

Shall be handled as the addresses of the payload message as described in clause 9.2.1.

Destination Address

Shall be handled as the addresses of the payload message as described in clause 9.2.1.

Fragments headers

a) next header

Copied from IPv4 Protocol field.

b) fragment Offset

Copied from the IPv4 Fragment offset field.

c) More fragment bit

Copied from the value of the more fragment bit in the IPv4 flags field.

d) Identification

The value of this field should be mapped from the triple of the source address, destination address and IPv4 identification field of the incoming packet/fragments to a unique value for the source and destination address of the outgoing IPv6 packet/fragments.

9.2.2.2 Abnormal cases

If IPv4 options are present in the IPv4 packet, they should be ignored i.e. there is no attempt to translate them. However, if an unexpired source route option is present then the packet shall instead be discarded, and an ICMPv4 "destination unreachable/source route failed" Type 3/Code 5 error message shall be returned to the sender as defined in RFC 792 [1010].

When a translator receives the first fragment of a fragmented UDP IPv4 packet and the checksum field is zero the translator should drop the packet and generate a system management event specifying at least the IP addresses and port numbers in the packet. When it receives fragments other than the first it should silently drop the packet since there is no port information to log.

When a translator receives an unfragmented UDP IPv4 packet and the checksum field is zero the translator shall compute the missing UDP checksum as part of translating the packet. Also, the translator should maintain a counter of how many UDP checksums are generated in this manner.

9.2.2.3 IPv6 to IPv4

When the I-BGF receives an IPv6 message the following codings shall be set in the IPv4 headers of the message sent to the IPv4 network.

  • If there is no IPv6 fragment header, the IPv4 header fields shall be set as described in table 3.
  • If there is an IPv6 fragment header, the IPv4 header fields shall be set as described in table 4.

Table 3: Derivation of IPv4 Header from IPv6 Header (no fragmentation)

IPv4 field

Value

Version

4

Internet header length

5 (No IPv4 options).

Type of Service

The default behaviour is that the value of the IPv4 field Type of service field is the value of the IPv6 Traffic class field (all 8 bits are copied). An implementation of a
I-BGF should also provide the ability to ignore the value of the IPv6 Traffic Class and always set the IPv4 Type of Service field to zero.

Total length

The IPv4 Total Length field value is the IPv6 Payload length value plus the size of the IPv4 headers.

Identification

All bits are set to zero.

Flags

The more fragment flag is set to zero. The Don’t fragment flag is set to one.

Fragment offset

Set to zero

Time to live (TTL)

The value of the field shall be set to the received IPv6 Hop Limit field value minus 1.

Protocol

The IPv4 field Protocol shall be set to the value of IPv6 field The next header value.

Header checksum

Computed once the IPv4 header has been created.

Source Address

Shall be handled as the addresses of the payload message as described in clause 9.2.1.

Destination Address

Shall be handled as the addresses of the payload message as described in clause 9.2.1.

Table 4: Derivation of IPv4 Header from IPv6 Header (fragmentation)

IPv4 field

Value

Version

4

Internet header length

5 (No IPv4 options).

Type of Service and Precedence

The default behaviour is that the value of the IPv4 field Type of service field is the value of the IPv6 Traffic class field (all 8 bits are copied). An implementation of a
I-BGF should also provide the ability to ignore the value of the IPv6 Traffic Class and always set the IPv4 Type of Service field to zero.

Total length

The IPv4 Total Length field value is the IPv6 Payload length value plus the size of the IPv4 headers minus 8 for the Fragment header.

Identification

The value of this field should be mapped from the triple of the source address, destination address and IPv6 fragmentation header field “identification” of the incoming packet/fragments to a unique value for the source and destination address of the outgoing IPv4 packet/fragments.

Flags

The IPv4 More Fragments flag is copied from the IPv6 M flag in the IPv6 Fragment header. The IPv4 Don’t Fragments flag is set to zero allowing this packet to be fragmented by IPv4 routers.

Time to live (TTL)

The value of the field shall be set to the received IPv6 Hop Limit field value minus 1.

Protocol

The IPv4 field Protocol shall be set to the value of IPv6 field The next header value.

Header checksum

Computed once the IPv4 header has been created.

Source Address

Shall be handled as the addresses of the payload message as described in clause 9.2.1.

Destination Address

Shall be handled as the addresses of the payload message as described in clause 9.2.1.

9.2.2.4 Abnormal cases

If any of an IPv6 hop-by-hop options header, destination options header, or routing header with the Segments Left field equal to zero are present in the IPv6 packet, they are ignored i.e. there is no attempt to translate them. However, the Total Length field and the Protocol field shall be adjusted to "skip" these extension headers.

If a routing header with a non-zero Segments Left field is present then the packet shall be translated, and an ICMPv6 "parameter problem/erroneous header field encountered" Type 4/Code 0 error message as defined in RFC 2463 [1111], with the Pointer field indicating the first byte of the Segments Left field should be returned to the sender.

9.2.3 Fragmentation

If the DF flag is not set and the IPv4 packet will result in an IPv6 packet larger than 1 280 bytes the I-BGF shall prior to transferring it in the IPv6 network:

  • Add the fragment header to the message.
  • Fragment the IPv4 packets so that their length, excluding the IPv4 header, is at most 1 232 bytes (1 280 – 40 for the IPv6 header and 8 for the Fragment header).

9.2.4 Abnormal cases

As a part of decrementing the Time To Live/Hop Limit value and the I-BGF discovers that the zero value is reached the I-BGF shall send an ICMPv4/ICMPv6 message with the error "time to live exceeded in transit" type 11 code 0 as defined in RFC 792 [1010] and "hop limit exceeded in transit" type 3 code 0 as defined in RFC 2463 [1111].