Re: [v6ops] IPREF as a transitioning tool

[waldemar <[e-mail]>]

On 11/9/23 17:12, Martin Huněk wrote:
> Hi,
>
> I'm missing these parts:
> - How this technology would interact with the networks that would not use IPREF.
It wouldn't. Gateways are needed on both ends. You should think of GWs 
as a software upgrade on the edge routers, although stand alone gateways 
make sense in certain configurations, too.
> - How the GWs would know when to switch to the IPv6 on the Internet.
They wouldn't. The servers would advertise addresses with IPv6 context 
addresses. GWs don't choose, the endpoints do.
> - What about DNSSEC?
This was discussed (offline). No issue here. Unlike NAT64, IPREF 
actually places the exact returned addresses in the packets. It does 
encode them for local hosts, which are unmodified, but GWs decode them 
back to their original values when sending out of the network. Also, 
there is a proposal for a new RR which would simplify things for DNSSEC.
> - What benefits does it bring to the network that already did the transition?
They would be able to communicate with those that did not, or with some 
more exotic or experimental networks like SCION. IPREF also allows peer 
networking. Dealing with references might be viewed as easier than 
dealing with IP addresses.
>
> A lot of us do not start with just IPv4 running. We run dual-stack or braver ones IPv6-mostly/only. The IPv4-only starting point would be around 15 years ago.
A lot is still less than all.  Dual stacks prevent taking down IPv4 
Internet. The hope that somehow everyone switches  to IPv6 and we can 
take down IPv4 is a mirage.  These existing technologies perpetuate 
IPv4. They will never be able to eliminate IPv4 Internet.
>
> Modifying DNS replies on a local recursive resolver is not a good idea. This would break DNSSEC signatures, so IPREF would not work for DNSSEC-validating clients.
As mentioned above, DNS replies are not modified. DNSSEC is fine.
>
> Rest see inline.
>
> Dne středa 8. listopadu 2023 10:08:14 CET, waldemar napsal(a):
>> I wanted to address one comment that I did not have time to during the
>> session yesterday.
>>
>> There was a gentleman who questioned the wisdom of introducing another
>> transition strategy. He said such a proposal would make sense 15 years
>> ago, he also said many could propose new strategies but refrain from
>> doing so. He ended by stating that there is no need for another
>> transition strategy.
> I must agree with the thought of the above-mentioned gentleman. Maybe 15 years ago, this could be a viable solution even though we would probably have thought the IPv6 adoption would have been faster than it actually was. Anyway, now we have the proper tools to do the transition to IPv6-only even without IPREF. We can use, for example, SIIT-DC to shut down IPv4 internally without waiting for latecomers. The IPv4-only operator would not care about the reachability of IPv6-only services (together with any transitional mechanism) until there is something really important there. When so, it is not a good idea to give such an operator tool how to not implement native IPv6.
The opposite is true. It is the existing transition technologies that 
give operators tools to not implement pure IPv6. IPREF transitions only 
to pure IPv6.
>> I generally agree with the line of thought. Excessive proliferation of
>> methods is detrimental to the cause. I questioned myself whether to go
>> with the proposal or not. In the end I decided that IPREF is so
>> different and so distinct from anything currently available that it
>> should be presented. I already mentioned that it is based on a different
>> principle which will make it succeed where existing methods would fail.
>> There are other factors, even more significant:
>>
>> (a) IPREF is 100% customer premise technology. As such, its use is
>> totally dependent on the customers choice. There is nothing IETF can do
>> to stop them. It is similar to NAT in this respect. NAT was widely
>> despised, still is, by IPv6 enthusiast but it took over the world in
>> spite of attempts to  block it.
>>
>> (b) Related to (a), enterprises love the ability to control the process
>> themselves, without anybody dictating what they should or should not do
>> with their networks. In addition, the economic profile hugely favors
>> IPREF. It is simply cheaper not to do dual stacks, not to do two step
>> transition, not to have to upgrade what they don't want to upgrade, not
>> to have to coordinate with peers. Less cost, less risk.
> With the "Enterprise" admin hat on, I like more tools; there is no dispute about that. However, I don't like the idea of placing some translator in the way of all my traffic and being forced to keep it there until the last latecomer finishes the transition. I run full dual-stack now. If I want to run IPREF, it would cost me additional money to do so - buy the translator. There is more risk that an additional device in the way, the translator, would fail. Higher latency. And because all would have to go through it, for me, it means up to 100 Gbps throughput. I'm not convinced if it is better than dual-stack or 464XLAT + SIIT-DC. Seams more like charity work for latecomers than an economically viable solution.
Dual stacks is a huge problem. They re-enforce IPv4. These technologies 
you mention will never be able to do away with IPv4 Internet.
>> (c) Related to (b) the economic profile of IPREF is hugely attractive
>> to  ISPs as well. Why doing IPv4-as-a-service if it is not necessary,
>> why burden pure IPv6 Internet with IPv4 services if they're not needed?
>> How can IPv6 compete with IPv4 if it is required to provide extra
>> functionality but which can be avoided? Less cost, less risk.
> Now, ISP admin hat on. I'm also doing dual-stack now. I would rather love to get rid of NAT/CGNAT. Putting all the traffic through yet another translator that I do not have now. And keep it for how long? I see the additional cost, not less. Also, there is an additional risk of implementing new transitional technology and to run it.
IPREF will eliminate NAT, NAT6, and CGNAT, albeit not the first thing 
that will happen. ISPs running dual stacks?? Yeah, exactly. We need to 
do away with it. IPREF is 100% customer premise technology, ISPs don't 
need to do anything, just provide pure IPv6 Internet.
>> I am just an individual, an inventor, I can do only so much. There are
>> different roles played by different entities. IPREF must be picked up by
>> others. By vendors to build commercial gateways, by architects and
>> operators to complete its specification. This project is in a very
>> vulnerable stage. It can be easily dismissed. Because of (a), (b), and
>> (c) above, it would be foolish to do so. You must allow that the project
>> might be picked up at some point, the gateways will be built, and in the
>> end the economy of the method will prevail. IPv6 cause is better served
>> embracing it than fighting it.
> The whole reasoning is full of claims but very little data and very "heavy" (GWs in every network, modified DNS, etc.) without clear motivation for those who already made the transition.
Yes, it is in a vulnerable stage for the moment. There is no way to 
convince doubters without advancing it by building a GW and 
demonstrating results. But what else is new?
>
> Regards,
> Martin
>> _______________________________________________
>> v6ops mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/v6ops
>>
>
> _______________________________________________
> v6ops mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/v6ops