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

ack. I think SIIT, NAT64, and IVI have each addressed placing IPv4- 
accessible systems within an IPv6 network in a scalable fashion (at  
least as scalable as addressing itself). I obviously have a preference  
among those, but I think it is both possible and straightforward.

On Oct 1, 2008, at 2:22 PM, Mark Townsley wrote:

>
> Fred,
>
> By "hard" I didn't intend to predispose whether the solution itself  
> would be hard or easy to code, scale, or otherwise make work for  
> some scoped definition of the problem. The statement that this is  
> "hard" made it's way into the slide based on discussions at the last  
> ietf, on list, etc. where I found less understanding in the  
> community on exactly how IPv4 -> IPv6 translation could be made to  
> work in a scalable or useful manner. As you say, one needs to  
> approach and analyze the problem in a specific manner in order to  
> make it seem less "hard."
>
> Hopefully by the end of the meeting we will all be approaching and  
> analyzing the problem correctly. Then, it won't seem so hard and I  
> will happily erase the bullet from the slide deck.
>
> - Mark
>
> PS. Apologies that I didn't spend more time on this topic, it was  
> scenario #5 of 5 - we were running out of time during the slot, and  
> frankly I ran out of time making the slides leading up to the  
> meeting as well so perhaps did not give this full billing. I had no  
> intention of implying one scenario more important than the other  
> based on slide count.
>
>
> Fred Baker wrote:
>> I'm fairly disturbed by Mark's dismissal of IPv4->IPv6 translation  
>> as "hard". I'll take this note to say why. I am obviously a  
>> proponent of a particular class of solution, IVI, which is  
>> specifically targeted at solving this problem, so let me declare  
>> bias up front. But I do not consider the issue hard if correctly  
>> analyzed and approached.
>>
>> In this analysis, I am going to leave out the dual stack case,  
>> which I frankly consider the strongly preferable deployment model.  
>> Wherever it is used, matters get simplified. I am expressly looking  
>> at the more difficult IPv4-only/IPv6-only case.
>>
>> Mark's dismissal - I call it that because he spent an hour talking  
>> about CGN solutions and then spent less than a minute charging  
>> through two slides that discussed actually deploying IPv6 and  
>> declaring them both "hard" and therefore not worthy of  
>> consideration - is based on the observation that mapping 2^128  
>> addresses into 2^32 bits is hard. I will agree with him that making  
>> it possible for every IPv6 address to be mapped into IPv4 in a  
>> scalable manner has issues. The question that I will ask is: is  
>> that the real requirement? I don't think it is.
>>
>> While the addressing issue resolves to hosts, the connectivity  
>> problem is about applications. I think that today's applications  
>> can largely be broken down into two broad categories, and speakers  
>> in those applications into three. These are: the clients of client/ 
>> server applications, the servers in client/server applications, and  
>> the peer in peer-to-peer applications. In an IPv4-only/IPv6-only  
>> gateway, we have actually only our session initiation problems to  
>> solve:
>>
>>    IPv6 client->IPv4 server
>>    IPv4 client->IPv6 server
>>    IPv6 peer -> IPv4 peer
>>    IPv4 peer -> IPv6 peer
>>
>> Once a session is initiated, we can obviously continue the  
>> conversation.
>>
>> IPv6 client->IPv4 server is pretty simple. The DNS ALG advertises  
>> IPv4 addresses as mapped IPv6 addresses, and the gateway keeps 1:n  
>> overlaid mappings in a manner not all that different from current  
>> IPv4/IPv4 NATs. On the IPv6 side of the gateway, we simply use the  
>> mapped address; on the IPv4 side, we use IPv4 address+port overlay  
>> as we do in IPv4/IPv4 NATs.
>>
>> 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.
>>
>> IPv6 peer->IPv4 peer is simple enough; it is essentially the same  
>> problem as IPv6 client->IPv4 server, and is solved the same way.
>>
>> Initiating a session from an IPv4 peer to an IPv6 peer with an  
>> unmapped address is "hard"; that winds up calling for complex  
>> machinery like NAT-PT proposes. However, it is unnecessary to solve  
>> the case. p2p technologies open TCP connections between systems,  
>> leave them open long periods of time, and use them to transport  
>> data. They are in effect overlay networks. If one IPv6 peer opens a  
>> session to an IPv4 peer, connectivity is established between IPv4- 
>> only and IPv6-only p2p networks and the problem is solved.
>>
>> 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.
>>
>> None of those models is "hard" in light of our present experience  
>> with SIIT and IPv4/IPv4 NAT.
>>
>> Now, here is my issue with NAT64/SIIT's addressing model, which we  
>> deployed and then deprecated in RFC 4291. There are two. First, it  
>> is a lot like a default route, and limits the network  
>> administration's options in route management; to fix that, we need  
>> to have a prefix appropriate to the gateway as opposed to a flat  
>> "must be zero" style prefix. Second, th addressing architecture is  
>> essentially that of CIDR and therefore allows routing prefixes to  
>> be as long or as short as needed, but we have given clear guidance  
>> that router vendors should think about host routes or prefixes of / 
>> 64 or shorter, not normally prefixes in the 65..127 length range.  
>> If we believe that - and RFC 4291 clearly does - then enabling the  
>> gateway to support routing to multiple sites within the IPv6 domain  
>> using a single IPv4 prefix advertised in the IPv4 domain (as  
>> opposed to doing host routing to IPv4-mapped addresses in the IPv6- 
>> only domain) is important for scaling. IVI moves the address around  
>> to put IPv4-mapped prefixes within the /64 length rule.
>>
>> So the fundamental argument for IVI is that it works well with  
>> routing, and makes interchange of both p2p and client/server  
>> applications across the IPv4/IPv6 gateway simple.
>>
>> IPv4 access to the IPv6 network is most definitely *not* hard if  
>> the problem is correctly parsed and addressed.
>>
>> No pun intended.
>> _______________________________________________
>> v4v6interim mailing list
>> v4v6interim@ietf.org
>> https://www.ietf.org/mailman/listinfo/v4v6interim
>>
>

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