Re: [v4v6interim] "IPv4->IPv6 is hard"

Iljitsch van Beijnum wrote:
> [catching up...]
>
> On 1 okt 2008, at 18:13, Fred Baker wrote:
>
>> An IPv4 client accessing an IPv6 server is equally simple given a 1:1 
>> mapping such as NAT64 or IVI describes. One maps the headers and the 
>> addresses.
>
> [...]
>
>> So to my mind, the requirement is that the gateway provide three 
>> services:
>>  - a DNS algorithm that maps IPv4 addresses to a subset of IPv6
>>    addresses.
>>  - a 1:1 NAT algorithm that statelessly supports the common case of
>>    IPv4 clients accessing IPv6 servers, which will be used by a
>>    relatively small set of hosts in the IPv6-only domain.
>>  - 1 1:n NAT algorithm that statefully maps general IPv6 to IPv4
>>    address plus port, which might be used by an arbitrarily large
>>    number of hosts in the IPv6-only domain, but unlikely to be all
>>    at the same time and diminishing as IPv6 deployment grows.
>
> So you _don't_ want to solve the situation where an IPv4-only host 
> gets to talk to any given IPv6 host.
>
> I think it would be fair to call _that_ scenario "hard".
>
> However, I think there are others who are interested in solving this 
> case.
There was some discussion at the Montreal meeting.  I believe I said 
something like

"...folks I work with would like to see solutions in that space, but it 
is certainly not a high priority.  For the foreseeable future, it does 
not seem critical to enable an IPv4-only host to talk to an arbitrary 
number of IPv6-only hosts/servers/applications.  There really aren't any 
to worry about." 

The priorities as I see them are first, make sure a host "turning on" 
IPv6 doesn't lose anything (like access to the whole IPv4 Internet) and 
second, make sure an IPv4-only server is still reachable if somebody 
else (eventually everybody else) turns on IPv6 (either they are 
dual-stack and reach it via IPv4 or through a translator near the 
IPv4-only server). 

The situation where an IPv4-only legacy client keeps working in a world 
where lots of services turn off IPv4 to me seems a "maybe later" problem 
to solve.  Doesn't matter if it's hard - it is deferrable.  Of course, 
framework and other solutions should keep this scenario in mind at least 
to the level of not making it harder to do that later...

> _______________________________________________
> v4v6interim mailing list
> v4v6interim@ietf.org
> https://www.ietf.org/mailman/listinfo/v4v6interim
>

-- 
Ed Jankiewicz - SRI International
Fort Monmouth Branch Office - IPv6 Research 
Supporting DISA Standards Engineering Branch
732-389-1003 or  ed.jankiewicz@sri.com 

_______________________________________________
v4v6interim mailing list
v4v6interim@ietf.org
https://www.ietf.org/mailman/listinfo/v4v6interim