Defining a settlement rule for cases of IPv4-IPv6 connectivity. When the user of a network (a carrier) only supports IPv4 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.
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 delay the adoption of IPv6 – the protocol that is to prevail in the future. There are likely to be many cases in the not too 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.
Current textIt is proposed that a rule should be established to settle disputes relating to connectivity problems between a user supporting 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.
New textIt is proposed that a rule should be established to settle disputes relating to connectivity problems between a user supporting 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.
Additional informationNone
TimetableOn a case-by-case basis
ReferencesNone
Presented at:-
Defining a recommendation or rule for settling cases of IPv4-IPv6 connectivity disputes when a network or carrier only supports 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 promote the adoption of IPv6, the protocol that will prevail in the future. Although certain solutions exist which can be used during the transition (e.g., NAT64), it is desirable that all users and operators evolve towards IPv6. If disputes were to arise in the near future over who should make changes in their infrastructure to allow interconnecting IPv4 and IPv6 networks, and if it were decided that the operator using IPv6 should make changes 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 obtain 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 adopt IPv6. This strategy will lead us in the right direction and is in line with future trends in technology such as the Internet of Things.
Current text11.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 supports IPv6, the operator/user that only supports IPv4 will be advised to evolve to IPv6 (e.g., using dual-stack). Implementing a solution for communicating from IPv6 to IPv4 (e.g., NAT64) should be avoided, as these temporary solutions require public IPv4 addresses, which will be scarce or unavailable.
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 supports IPv6, the operator/user that only supports IPv4 will be advised to evolve to IPv6 (e.g., using dual-stack). Implementing a solution for communicating from IPv6 to IPv4 (e.g., NAT64) should be avoided, as these temporary solutions require public IPv4 addresses, which will be scarce or unavailable.
None
TimetableCase by case
ReferencesNone
Presented at:LACNIC 25 (02/05/2016)