Re: A straightforward transition plan (was: Re: V6 still not supported)

Mailman List Mirror (Read Only)
1

If by ?straightforward transition plan? one means a clear and rational set of
options that allows networks to plan their own migration from IPv4-only to IPv
6, while maintaining connectivity to IPv4-only hosts and with a level of effor
t reasonable comparable to just running IPv4, then I would disagree, as such a
n "IPng transition plan? was achievable, expected, and we collectively failed
to deliver on it (as noted below)

I'm a bit confused about the achievable part.

Obviously, the adoption of IPv6 without a clear transition plan was a process
failure. However, it is not clear to me that waiting a few years would
have brought something much better. And waiting more than a decade would
mean that today there would not be a mature IPv6.

Transition to IPv6 so far seems to have consisted of 3 phases:
1) Lots of tunnels due lack of a wide spread IPv6 backbone.
2) Early adopters being happy that they can run IPv6 native, usually as
   dual stack.
3) Lots of people looking into IPv6-only.

I'd say 1) mostly worked. 6to4 was a bit of mess. But otherwise tunnels
worked. Obviously, deploying IPv6 using tunnels is a lot more complex
than deploying native IPv4 without NAT.
From a technical perspective 2) just works. From an operational perspective
it is about twice as expensive as IPv4-only. So 2) is popular with people
who really want IPv6.

The big issue is 3). If we look at the current internet, there are parties
who lack IPv4 addresses and want to switch to IPv6. Obviously, they
want to be IPv6-only. The lack of IPv4 address makes dual stack even harder.
On the other hand, there are parties who have enough IPv4 addresses and
have no reason to switch to IPv6.

So we are clearly in the situation of 'migration from IPv4-only to IPv6,
while maintaining connectivity to IPv4-only hosts'

It should be clear that an IPv4-only host only speaks IPv4. This means that
communication with an IPv4-only host has to be IPv4. So either the
IPv6-only host or something in the network has to speak IPv4. If the
IPv6 host speaks IPv4 then we get dual stack, which has been rejected
as a broken solution. Technically, it is also possible to tunnel IPv4
packets, then the host is in some sense dual stack, but most of the network
is not. However, automatic tunnel configuration is hard, and tunnels
tend to be fragile.

So the only option is a device in the network that translates between
IPv6 and IPv4. Currently we have such a protocol, NAT64. And from
a technical point of view it is a disaster.

Looking back, we can say that the only feature of IPv6 that makes people
invest in IPv6 is the bigger address space. So it is safe to say that
most of the internet would have waited to invest in IPv6 until we were
(almost) out of IPv4 addresses. So by its very nature this transation
between IPv6 and IPv4 would have NAT component.

In my opinion, It is clear that during the time IPv6 was developed, any
solution involving NAT would have been rejected.

So I'm confused, what transition technology was achievable (also in the
political sense) but not delivered?

If there is a magical transition technology that allows an IPv6-only host to
talk to an IPv4-only host, then let's deploy it.

2

I don't think we can say that NAT64 is a disaster. I will say so if we want to keep IPv4 only hosts in the "6" side, of course it doesn't work. However, that's why we moved further with 464XLAT. And the demonstration is that most of the operators are using it.

I think in your picture you're missing 2 phases:
4) IPv6-only with IPv4aaS (we have 5 technologies, see RFC8585 for a summary of what is needed in the CPEs), when there is still a significant amount of IPv4 traffic in the customer LANs.
5) IPv6-only with IPv4aaS when IPv4 traffic is residual in most of the customers LANs. How fast we move to this phase depends on more and more devices, and apps using IPv6.

The advantage is:
a) The job is done in the CPE (no need for a more powerful one, etc.), customers are not aware of it. Part of the job is done in the operators networks, of course, but it is comparable and much cheaper, in terms of OpEx and CapEx, to alternatives such as dual-stack or NAT444/CGN.
b) When moving to 5 above, the operators can measure the reduction on the usage of the NAT64 (in the case of 464XLAT), and even in the usage of IPv4 public addresses, so they can transfer them, so laggers can use them for their own transition. On the side of the customers, there is nothing to do. You may remove IPv4, but actually is not costing you "anything" to keep it.

Regards,
Jordi
@jordipalet

El 28/3/22, 15:23, "NANOG en nombre de Philip Homburg" <nanog-bounces+jordi.palet=consulintel.es@nanog.org en nombre de pch-nanog-2@u-1.phicoh.com> escribió:

    >If by ?straightforward transition plan? one means a clear and rational set of
    >options that allows networks to plan their own migration from IPv4-only to IPv
    >6, while maintaining connectivity to IPv4-only hosts and with a level of effor
    >t reasonable comparable to just running IPv4, then I would disagree, as such a
    >n "IPng transition plan? was achievable, expected, and we collectively failed
    >to deliver on it (as noted below)

    I'm a bit confused about the achievable part.

    Obviously, the adoption of IPv6 without a clear transition plan was a process
    failure. However, it is not clear to me that waiting a few years would
    have brought something much better. And waiting more than a decade would
    mean that today there would not be a mature IPv6.

    Transition to IPv6 so far seems to have consisted of 3 phases:
    1) Lots of tunnels due lack of a wide spread IPv6 backbone.
    2) Early adopters being happy that they can run IPv6 native, usually as
       dual stack.
    3) Lots of people looking into IPv6-only.

    I'd say 1) mostly worked. 6to4 was a bit of mess. But otherwise tunnels
    worked. Obviously, deploying IPv6 using tunnels is a lot more complex
    than deploying native IPv4 without NAT.
    From a technical perspective 2) just works. From an operational perspective
    it is about twice as expensive as IPv4-only. So 2) is popular with people
    who really want IPv6.

    The big issue is 3). If we look at the current internet, there are parties
    who lack IPv4 addresses and want to switch to IPv6. Obviously, they
    want to be IPv6-only. The lack of IPv4 address makes dual stack even harder.
    On the other hand, there are parties who have enough IPv4 addresses and
    have no reason to switch to IPv6.

    So we are clearly in the situation of 'migration from IPv4-only to IPv6,
    while maintaining connectivity to IPv4-only hosts'

    It should be clear that an IPv4-only host only speaks IPv4. This means that
    communication with an IPv4-only host has to be IPv4. So either the
    IPv6-only host or something in the network has to speak IPv4. If the
    IPv6 host speaks IPv4 then we get dual stack, which has been rejected
    as a broken solution. Technically, it is also possible to tunnel IPv4
    packets, then the host is in some sense dual stack, but most of the network
    is not. However, automatic tunnel configuration is hard, and tunnels
    tend to be fragile.

    So the only option is a device in the network that translates between
    IPv6 and IPv4. Currently we have such a protocol, NAT64. And from
    a technical point of view it is a disaster.

    Looking back, we can say that the only feature of IPv6 that makes people
    invest in IPv6 is the bigger address space. So it is safe to say that
    most of the internet would have waited to invest in IPv6 until we were
    (almost) out of IPv4 addresses. So by its very nature this transation
    between IPv6 and IPv4 would have NAT component.

    In my opinion, It is clear that during the time IPv6 was developed, any
    solution involving NAT would have been rejected.

    So I'm confused, what transition technology was achievable (also in the
    political sense) but not delivered?

    If there is a magical transition technology that allows an IPv6-only host to
    talk to an IPv4-only host, then let's deploy it.

3

If by ?straightforward transition plan? one means a clear and rational set of
options that allows networks to plan their own migration from IPv4-only to IPv
6, while maintaining connectivity to IPv4-only hosts and with a level of effor
t reasonable comparable to just running IPv4, then I would disagree, as such a
n "IPng transition plan? was achievable, expected, and we collectively failed
to deliver on it (as noted below)

I’m a bit confused about the achievable part.

Obviously, the adoption of IPv6 without a clear transition plan was a process
failure. However, it is not clear to me that waiting a few years would
have brought something much better. And waiting more than a decade would
mean that today there would not be a mature IPv6.

Transition to IPv6 so far seems to have consisted of 3 phases:

  1. Lots of tunnels due lack of a wide spread IPv6 backbone.
  2. Early adopters being happy that they can run IPv6 native, usually as
    dual stack.
  3. Lots of people looking into IPv6-only.

I’d say 1) mostly worked. 6to4 was a bit of mess. But otherwise tunnels
worked. Obviously, deploying IPv6 using tunnels is a lot more complex
than deploying native IPv4 without NAT.
From a technical perspective 2) just works. From an operational perspective
it is about twice as expensive as IPv4-only. So 2) is popular with people
who really want IPv6.

The big issue is 3). If we look at the current internet, there are parties
who lack IPv4 addresses and want to switch to IPv6. Obviously, they
want to be IPv6-only. The lack of IPv4 address makes dual stack even harder.
On the other hand, there are parties who have enough IPv4 addresses and
have no reason to switch to IPv6.

So we are clearly in the situation of ‘migration from IPv4-only to IPv6,
while maintaining connectivity to IPv4-only hosts’

It should be clear that an IPv4-only host only speaks IPv4. This means that
communication with an IPv4-only host has to be IPv4. So either the
IPv6-only host or something in the network has to speak IPv4. If the
IPv6 host speaks IPv4 then we get dual stack, which has been rejected
as a broken solution. Technically, it is also possible to tunnel IPv4
packets, then the host is in some sense dual stack, but most of the network
is not. However, automatic tunnel configuration is hard, and tunnels
tend to be fragile.

So the only option is a device in the network that translates between
IPv6 and IPv4. Currently we have such a protocol, NAT64. And from
a technical point of view it is a disaster.

I think what you mean to say is you don’t like NAT64.

You may also be trying to say you disapprove of how history unfolded.

Fair.

But it may be worth acknowledge that some small and some very large (100M mobiles, growing FWA broadband business) have happily operated NAT64 for coming on 10 years with no problems or regrets.

Yes, we would like the internet to be on a single unified and high scale address family, but we all play the hand we are dealt.

4

Philip Homburg wrote:

It should be clear that an IPv4-only host only speaks IPv4. This means that communication with an IPv4-only host has to be IPv4.

This did not have to be true, had there been an extension/option standardized at the same time as IPv6 for IPv4 packets to be gateway'd into IPv6 transparently and efficiently (thru any dual stacked host/router), than at this point we would have likely been looking at 4 classes of nodes

- IPv4 only, legacy, requires translation to communicate directly with ipv6

- IPv4 only, extended, just needs a gateway to communicate directly with IPv6

- Dual Stack

- IPv6 only

Such additional functionality, could have been organically updated into most major OS's without any required network topology changes.

Joe