Settling IPv4-IPv6 connectivity disputes when only one of the protocols is supported

LAC-2016-1-v1 LAC-2016-1-v2 Vs
References:
New
Deleted
Modified
Authors

Name: Juan José Gaytán Hernández Magro
Email: jgaytanh@alestra.com.mx
Organization: Alestra, S. de R.L. de C.V.

Name: Juan José Gaytán Hernández Magro
Email: jgaytanh@alestra.com.mx
Organization: Alestra, S. de R.L. de C.V.

Summary

Defining a settlement rule for cases of IPv4-IPv6 connectivity. When the user of a network (a carrier) only supports IPv
4 and wants to communicate with a user of another network (another carrier) that supports only IPv6, which results in a
dispute, the user that supports only IPv4 must be required to update their infrastructure to support dual stack.

Defining a recommendation or rule for settling cases of IPv4-IPv6 connectivity disputes when a network or carrier only s
upports IPv4 and wants to communicate with another network which only supports IPv6. The recommendation would be for the
user who only supports IPv4 to upgrade their infrastructure to support dual stack and be able to connect with IPv6.

Rationale (Describe the problem you intend to solve)

It is important to establish rules to prevent NAT64 solutions as far as possible. Otherwise, such measures will only del
ay the adoption of IPv6 – the protocol that is to prevail in the future. There are likely to be many cases in the not to
o distant future of disputes over who should make changes in their infrastructure: the user/carrier supporting only IPv4
or the one supporting only IPv6. The use of NAT64 is not sustainable in the long term.

It is important to establish rules to promote the adoption of IPv6, the protocol that will prevail in the future. Althou
gh certain solutions exist which can be used during the transition (e.g., NAT64), it is desirable that all users and ope
rators evolve towards IPv6. If disputes were to arise in the near future over who should make changes in their infrastru
cture to allow interconnecting IPv4 and IPv6 networks, and if it were decided that the operator using IPv6 should make c
hanges to communicate with the IPv4 networks, this would discourage or slow down the rate of IPv6 adoption, which we are
trying to promote. In order for the IPv6 operator to try to connect to an IPv4 network, this operator would need to obt
ain new IPv4 address blocks in order to implement a NAT64 solution. However, in the long run, IPv4 blocks will no longer
be available and it will be impossible to use NAT64. The recommended alternative is for all operators and users to adop
t IPv6. This strategy will lead us in the right direction and is in line with future trends in technology such as the In
ternet of Things.

Current text

It is proposed that a rule should be established to settle disputes relating to connectivity problems between a user sup
porting only IPv4 and another supporting only IPv6. The user/carrier supporting only IPv4 must be required to upgrade to
IPv6; or else the adoption of IPv6 will be delayed.

11.4 Connectivity disputes between IPv4- and IPv6-only operators/users in the face of IPv4 scarcity
When a connectivity dispute arises between an operator/user that only supports IPv4 and an operator/user that only suppo
rts IPv6, the operator/user that only supports IPv4 will be advised to evolve to IPv6 (e.g., using dual-stack). Implemen
ting a solution for communicating from IPv6 to IPv4 (e.g., NAT64) should be avoided, as these temporary solutions requir
e public IPv4 addresses, which will be scarce or unavailable.

New text

It is proposed that a rule should be established to settle disputes relating to connectivity problems between a user sup
porting only IPv4 and another supporting only IPv6. The user/carrier supporting only IPv4 must be required to upgrade to
IPv6; or else the adoption of IPv6 will be delayed.

11.4 Connectivity disputes between IPv4- and IPv6-only operators/users in the face of IPv4 scarcity
When a connectivity dispute arises between an operator/user that only supports IPv4 and an operator/user that only suppo
rts IPv6, the operator/user that only supports IPv4 will be advised to evolve to IPv6 (e.g., using dual-stack). Implemen
ting a solution for communicating from IPv6 to IPv4 (e.g., NAT64) should be avoided, as these temporary solutions requir
e public IPv4 addresses, which will be scarce or unavailable.

Additional information

None

None

References

None

None