[Int-area] Re: New draft: draft-vanmook-intarea-ipv6-resolved-gateway-00

["[e-mail]" <[e-mail]>]

Probably, even if it requires some additional text, you want to better describe the situation, as it may be good also to differentiate if we are talking of the complete network or just a segment. Suggested changes for that:

Abstract:
… to enable IPv4 communication to dual-stack hosts connected to IPv6-only segments without subnets …

Intro:
… Networks transitioning to IPv6-only segments still need to carry IPv4 traffic ...

PS:
… In an IPv6-only segment …
… gap for dual-stack hosts on IPv6-only segments ...

And may be at some point (intro probably), clarify that the document speak about IPv6-only segments, because in a complete network, there may be a mix of IPv4-only, dual-tack, and IPv6-only segments, etc., so the solution in this draft can be applied granularly as needed.


Also, I think it will be good, in the deployment considerations sections, to add some text and references not just to RFC8925, but also to
- draft-ietf-v6ops-6mops
- draft-ietf-v6ops-claton
and make sure there is not any unwanted issue.

Regards,
Jordi

@jordipalet


> El 6 may 2026, a las 11:26, Remco van Mook <[e-mail]> escribió:
> 
> Hi Jordi,
> 
> You are correct - the host in this mechanism is dual-stack by any reasonable definition: it has at least one IPv4 address configured and applications can use it via the standard socket API. The distinction I was trying to draw is between the host and the segment: the segment is IPv6-only (no IPv4 subnet, no ARP infrastructure), while the host itself carries both stacks.
> 
> I was avoiding "dual-stack" because I didn't want to imply the full dual-stack infrastructure model that the draft is specifically designed to replace. But you are right that the term accurately describes the host, and using it with the appropriate qualifier -"the host is dual-stack; the segment is IPv6-only" - is both correct and clearer.
> 
> I'll admit it's somewhat reassuring that even seasoned IPv6 professionals find the terminology treacherous; I'll make sure to be more precise in -01, informed by the scope distinctions in draft-palet-v6ops-ipv6-only. The "IPv6-Only-Strict" rename is noted: happy to align with whatever the v6ops working group settles on.
> 
> Thanks again.
> 
> Remco
> 
>> On 6 May 2026, at 11:01, [e-mail] <jordi.palet=[e-mail]> wrote:
>> 
>> Hi Remco,
>> 
>> Regarding the dual-stack point, we are working in a terminology document in v6ops (https://datatracker.ietf.org/doc/draft-palet-v6ops-ipv6-only/) and the most important point is scope. So in the scope of the host in your draft, this host is dual-stack, because it has at least 1 IPv4 address configured and applications can use it, right? It may be connected to an IPv6-only or IPv6-Mostly segment, but unless I got it wrong, the host itself is dual-stack.
>> 
>> Just a note about “True-IPv6-Only” as in the next version, considering the last weeks discussion in v6ops, will be renamed to IPv6-Only-Strict.
>> 
>> Regards,
>> Jordi
>> 
>> @jordipalet
>> 
>> 
>>> El 4 may 2026, a las 18:34, Remco van Mook <[e-mail]> escribió:
>>> 
>>> Hi Jordi,
>>> 
>>> Thank you for the quick and constructive feedback.
>>> 
>>> On the abstract: agreed. The IANA allocation is a consequence of the mechanism, not the point of the document. I will reorder the abstract in -01 to lead with the host behavior specification. I originally set out to write a short "can I please have this number" document, but the host behavior specification turned out to be a necessary part of justifying the allocation -- so here we are.
>>> 
>>> On the IPv6 stack requirement: I would prefer not to use "dual-stack" here, as that term implies both stacks are fully configured for end-to-end routing. The outbound path defined in this document requires only a functional IPv6 implementation sufficient for Neighbor Discovery; a link-local address is enough for that. However, for return traffic to work in the RFC 8950 / v4-via-v6 forwarding model, the first-hop router must advertise the host's /32 with a routable next-hop, which in practice means the host needs a GUA or ULA. That is a consequence of the return path requirement rather than of this mechanism itself, and I will clarify the distinction in -01.
>>> 
>>> On "migrating" vs. "transitioning": you are right, and I should have known better. Will fix.
>>> 
>>> All three points will go into -01. I am still working my way through the current IETF author toolchain, and will get the datatracker linkage to the previous draft sorted as well.
>>> 
>>> Thanks again.
>>> 
>>> Remco
>>> 
>>>> On 1 May 2026, at 11:51, [e-mail] <jordi.palet=[e-mail]> wrote:
>>>> 
>>>> Hi Remco,
>>>> 
>>>> I think it is a very interesting idea.
>>>> 
>>>> My main comment is that this document is doing more than what the abstract seems to say. The main point of the document is not requesting the special purpose address, but actually specifying a host behaviour to enable IPv4 communication over an IPv6-Only network. Requesting IANA to reserve a special address is a “consequence” of that, as it happens with many other documents that request some “number” allocation to IANA.
>>>> 
>>>> In section 6, when you say "Hosts without an IPv6 stack are outside the scope of this document”, if I understood correctly the behaviour, the host must be dual-stack, so may be you want to say so and even set a MUST for dual-stack before section 4.
>>>> 
>>>> Last comment, in IETF we haven’t defined “migration” mechanisms, but “transition and coexistence”. Even if it may seem very similar (in English, but in other languages not), in many situations you discover that this confuses people, they believe that they can completely get rid-off the IPv4 stack (in this case in the host is not the case). So I will suggest that you replace in the intro “Networks migrating to IPv6-Only” to “Networks transitioning to IPv6-Only”.
>>>> 
>>>> PS: when you publish a new version, the datatracker allows you to say that this (new version) replaces draft-ipv6-resolved-gateway (even if expired), so both are linked in the time line, can be easily compared with diff, etc.
>>>> 
>>>> Regards,
>>>> Jordi
>>>> 
>>>> @jordipalet
>>>> 
>>>> 
>>>>> El 1 may 2026, a las 9:24, Remco van Mook <[e-mail]> escribió:
>>>>> 
>>>>> 
>>>>> Hi all,
>>>>> 
>>>>> I have submitted a revised and substantially updated version of the IPv6-Resolved IPv4 Gateway draft:
>>>>> 
>>>>> https://datatracker.ietf.org/doc/draft-vanmook-intarea-ipv6-resolved-gateway/ 
>>>>> 
>>>>> this replaces the now expired (and unfortunately named) 
>>>>> 
>>>>> https://datatracker.ietf.org/doc/draft-ipv6-resolved-gateway/
>>>>> 
>>>>> This document defines a special-purpose IPv4 address (192.0.0.11/32) that enables IPv4 communication over IPv6-only network segments without ARP, subnets, tunneling, or translation. Hosts configured with this address as their IPv4 default gateway resolve the next-hop link-layer address through the IPv6 neighbor cache rather than via ARP. IPv4 packets are forwarded natively end-to-end. The routing table entry is unchanged; only the ARP resolution path is affected.
>>>>> 
>>>>> Background: I presented an early version of this mechanism at RIPE91 in Bucharest and IETF 124 in Montreal (November 2025). The discussion there was encouraging, and I have since significantly developed the draft to address the feedback received, including:
>>>>> 
>>>>> - Full normative host behavior specification with pseudocode
>>>>> - Router behavior and backward compatibility with unmodified hosts (two-tier deployment model)
>>>>> - Integration with RFC 8950 (IPv4 routes with IPv6 next-hops) for end-to-end forwarding
>>>>> - Relationship to RFC 8925 (IPv6-Only Preferred Option)
>>>>> - Security, deployment, and implementation considerations
>>>>> - IANA request for 192.0.0.11/32 in the Special-Purpose Address Registry
>>>>> 
>>>>> A reference implementation is available at:
>>>>> https://github.com/remcovanmook/v4-with-v6-nh
>>>>> 
>>>>> I believe this work is a natural fit for IntArea and would like to request that the working group consider adoption. The mechanism addresses the specific first-hop gap that draft-ietf-intarea-v4-via-v6 explicitly leaves open (host access, not router-to-router), and complements rather than competes with draft-equinox-intarea-dhcpv4-route4via6. In my eyes, it completes the narrative of RFC8925, RFC8950 and the v4-via-v6 draft which is currently in IETF Last Call.
>>>>> 
>>>>> I would welcome review and discussion on the list, and am happy to present again at an upcoming IntArea session if the chairs consider that useful.
>>>>> 
>>>>> Thanks,
>>>>> 
>>>>> 
>>>>> Remco van Mook
>>>>> 
>>>>> _______________________________________________
>>>>> Int-area mailing list -- [e-mail]
>>>>> To unsubscribe send an email to [e-mail]
>>>> 
>>>> 
>>>> **********************************************
>>>> IPv4 is over
>>>> Are you ready for the new Internet ?
>>>> http://www.theipv6company.com
>>>> The IPv6 Company
>>>> 
>>>> This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.
>>>> 
>>>> _______________________________________________
>>>> Int-area mailing list -- [e-mail]
>>>> To unsubscribe send an email to [e-mail]
>>> 
>>> _______________________________________________
>>> Int-area mailing list -- [e-mail]
>>> To unsubscribe send an email to [e-mail]
>> 
>> 
>> **********************************************
>> IPv4 is over
>> Are you ready for the new Internet ?
>> http://www.theipv6company.com
>> The IPv6 Company
>> 
>> This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.
>> 
>> _______________________________________________
>> Int-area mailing list -- [e-mail]
>> To unsubscribe send an email to [e-mail]
> 



**********************************************
IPv4 is over
Are you ready for the new Internet ?
http://www.theipv6company.com
The IPv6 Company

This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.