Re: [v6ops] IPREF as a transitioning tool

[waldemar <[e-mail]>]

On 11/9/23 22:12, Mark Andrews wrote:
> There is nothing new in this proposal other than adding an unnecessary new DNS record.
>
> Many moons ago the IETF/IRTF was presented with a DNS server that talked to a NAT64 to
> establish A to AAAA mappings on demand to allow IPv4 machines to connect to IPv6 machines.
> See section 3.2 of your proposal.  It worked but clearly had scaling limitations as it needed
> a large IPv4 block to service a small IPv4 client base.  Putting one in every home CPE router
> would probably work but is it really necessary when 99.99% of clients already support dual
> stack.
...scaling issues.  Yes, exactly. IPREF does not have scaling issues.
>
> We already have the ability for IPv6 to connect to IPv6 to IPv4 using NAT64.  This can be run
> with initiating traffic coming from both directions at the same time.  IPv6 on the public side
> to IPv4 on the private side with static mapping and AAAA records in the DNS as well as the more
> common use of dynamic mappings when running IPv6 only on the private side.  This has been done
> for many years now.

...thereby reinforcing IPv4. You will never do away with IPv4 Internet 
this way.

For as long as IPv4 Internet exists, the transition to IPv6 will never 
be completed.  Are you concerned at all that this may happen? Has there 
ever been a doubt in your mind that IPv4 might survive?  Is the fight 
over transition tools worth risking IPv6? IPREF transitions only to pure 
IPv6, it uses only pure IPv6 Internet. It removes IPv4 addresses.

>
>> On 10 Nov 2023, at 14:13, waldemar <[e-mail]> wrote:
>>
>>
>> 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.
> But you have the DNS synthesising A records.  This does not work with DNSSEC.
No, I don't.  DNS returns what is configured. It does not do any address 
processing. And, it does work with DNSSEC. The paragraph below indicates 
that because hosts are unmodified, thus don't understand IPREF 
addresses, the resolver must encode them. The gateways then restore them 
when the packets reach them. There is no synthesis, just dealing with 
unmodified hosts.
>
> 3.2. Local Network Resolvers
>
> Local network resolvers must recognize IPREF addresses returned by DNS queries.
> They must also be capable of encoding them into native IP addresses in consultation
> with IPREF gateways. This is shown in Figure 4 as a line connecting local DNS resolver
> with IPREF gateway GWA. Encoding is needed because local hosts do not understand IPREF
> addresses. Instead, local hosts use encoded equivalents which are then replaced with
> the actual IPREF addresses by the gateways. There may be a need to standardize on how
> resolvers communicate with gateways.
>
>
>>> - 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.
> You are mistaken. Section 3.2 requires NODATA being turned into records.  This does not work with DNSSEC.
>>> 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.
> And how is this different to ISPs providing IPv6 only connections like they do today with ISP NAT64 (which fills the role of the missing IPPREF gateway at the other end). You can publish AAAA records in the DNS which are mapped to internal IPv4 addresses through a NAT64 on the CPE.
Those gateways are not needed thus freeing ISPs from maintaining 
unnecessary services.
>
>>>> 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
>> _______________________________________________
>> v6ops mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/v6ops
>