I would like to touch on some of the strategic aspects of the transition
to IPv6. Exactly what is the objective and what is the plan to
accomplish it. My understanding of the objective is to reduce the two
existing Internets to one. This is what 'transition to IPv6' means. It
means to eliminate one of the Internets, namely the IPv4 one, and use
just one of them, the IPv6 one. That's the essence of the 'transition to
IPv6'. Notably, making everyone switch to IPv6 is not an objective. It
is more of an activism of the kind 'my protocol is better than yours'.
In contrast, reducing the number of Internets to just one has tangible
economic ramifications. So let's concentrate on phasing out IPv4 Internet.
In the transition process, special technologies are used that can bridge
IPv4 and IPv6 thus help with the task. Unfortunately the use of those
special technologies has the effect of unintentionally extending the
life of IPv4 Internet. For example, NAT64/SIIT gateways requires IPv4
addresses, quite a number of them depending on the complexity of the
transition. These gateways cannot be taken down until transition is
completed thus extending the life of IPv4 Internet. Because they are the
last removed from IPv4 Internet, they create the undesirable IPv4 creep.
That extra period of time is quite lengthy. It is not a hyperbole to say
it extends into decades. Many organizations have very legitimate reasons
to go slowly with transitions, in many cases certain subsystems simply
cannot be transitioned, they must be replaced by next gen designs. This
is why the creep easily reaches several years.
A. NAT64/SIIT contribute to IPv4 creep
| Internet |
| | IPv6
------+-- IPv6 --+=========+============
| | |
| +---+--+ |
Network A | | NAT64| | Network B
| | SIIT | |
| +--+---+ |
IPv4 | | |
============+=========+-- IPv4 --+------
| |
| |
NAT64/SIIT gateways are setup first but are taken down LAST. This
creates IPv4 creep.
B. IPREF eliminates IPv4 creep
IPREF dramatically enhances transition process by eliminating IPv4
Internet very early in the process. The remaining, potentially lengthy,
transition continues without IPv4 Internet.
If the ASCII art diagrams come out garbled, equivalent diagrams can be
viewed on: https://github.com/ipref/ietf/blob/main/stop-ipv4-creep.md
1. Starting point
| Internet |
+-------+ | | +-------+
+ + +- IPv6 -+ + +
IPv4 | IPREF | | | | IPREF | IPv4
=====+ + GWA + +==+===== IPv4 =====+==+ + GWB + +=====
| +-------+ | | | | +-------+ |
'==============' | | '=============='
2. Switching traffic to IPREF
| Internet |
+-------+ | | +-------+
+ + +- IPv6 -+ + +
IPv4 | IPREF | | | | IPREF | IPv4
=====+===+ GWA +==+==+===== IPv4 =====+==+==+ GWB +===+=====
| +-------+ | | | | +-------+ |
'--------------' | | '--------------'
3. Acquiring IPv6 Internet addresses
| Internet |
+-------+ | | +-------+
+ +-----+----- IPv6 -+ + +
IPv4 | IPREF | | | | IPREF | IPv4
=====+===+ GWA +==+==+===== IPv4 =====+==+==+ GWB +===+=====
+-------+ | | +-------+
| |
4. Swiching IPREF gateways traffic to IPv6
| Internet |
+-------+ | | +-------+
+ +=====+===== IPv6 =====+=====+ +
IPv4 | IPREF | | | | IPREF | IPv4
=====+===+ GWA +--+--+----- IPv4 -----+--+--+ GWB +===+=====
+-------+ | | +-------+
| |
5. Dropping IPv4 Internet
| Internet |
IPv6 +-------+ | | +-------+ IPv6
-----+---+ +=====+===== IPv6 =====+=====+ +---+-----
IPv4 | IPREF | | | | IPREF | IPv4
=====+===+ GWA + +- IPv4 -+ + GWB +===+=====
+-------+ | | +-------+
| |
6. Switching to IPv6 independently
| Internet |
IPv6 +-------+ | | +-------+ IPv6
-----+---+ +=====+===== IPv6 =====+=====+ +===+=====
IPv4 | IPREF | | | | IPREF |
=====+===+ GWA + +- IPv4 -+ + GWB +
+-------+ | | +-------+
| |
7. Completing transition
| Internet |
IPv6 +-------+ | | +-------+ IPv6
=====+===+ +=====+===== IPv6 =====+=====+ +===+=====
| IPREF | | | | IPREF |
+ GWA + +- IPv4 -+ + GWB +
+-------+ | | +-------+
| |
In step 1, and 2, IPREF gateways are setup and traffic is directed to go
through them. At this stage everything is still IPv4.
In step 3 and 4, both networks connect to IPv6 Internet. The networks
remain IPv4 but they connect to IPv6 Internet. This is possible thanks
to IPREF. The traffic is not tunneled over IPv6, rather, IPREF gateways
repackage payload to IPv6, and then back to IPv4. The gateways do not
know the final destination protocol (they only get references, not real
addresses), therefore cannot tunnel IPv4-in-IPv6.
Step 5 is crucial. As the gateway-to-gateway traffic goes over IPv6
Internet, both networks can disconnect from IPv4 Internet. This happens
very early in the process before any real transition takes place. IPv4
is gone before any serious changes to the networks are made. This
eliminates IPv4 creep and speeds up adoption of IPv6 Internet dramatically.
This has also an effect of greatly reducing costs of transition. The
organization are not forced to upgrade any services or network segments
that they do not want to for any reasons. These could be economical
reasons, high risk reasons, sometimes regulatory reasons (certification
might be revoked if changes made), etc. The organizations have full
comfort to proceed at their chosen pace. Meanwhile, the Internet has
dropped another IPv4 customer forever.
Steps 6, and 7 are really no longer relevant to the objective. The
actions in step 5 have already produced the desired effect.
Organizations may take as much time as they desire after that.
IPREF is not that complicated. In terms of IETF work, it needs an IPv6
extension header, probably a udp tunnel for IPv4 (no hope for an
option), a document describing the reference itself, and possibly a new
DNS RR record for IPREF addresses. In exchange, it will dramatically
shorten the time to a single IPv6 Internet. It will also save a huge
amount of costs for organizations, will greatly reduce the risks as well.
Please, support this project.
Waldemar
_______________________________________________
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area
