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

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