Re: IPv6 only host NAT64 requirements?

[Ole Troan <[e-mail]>]

> > In your letter dated Mon, 13 Nov 2017 10:50:40 +0800 you wrote:
> >> If this is the direction we want to go. Encourage IPv6 only host
> >> deployments (as opposed to dual stack hosts), are these requirements
> >> we'd like to add to the IPv6 node requirements document? Somewhere else
> >
> > Personally I don't like how NAT64 requires an IPv6 stack to deal with all
> > kinds of IPv4 issues. So for IPv6 node requirements, it should not go
> > beyond the level of MAY.
> 
> Yes, that's certainly the bind we are in. Are we going to require all IPv6 only nodes to be able to communicate with IPv4? And what does that entail? Do you have examples of "all kinds of IPv4 issues"?
> 
> Apart from the requirement of NAT64 prefix discovery and IPv4 synthesising, is there anything you don't need to do anyway?
> I can't quite see ICE/STUN going away, just because the end to end path is IPv6.
> 
> 1. ICE and STUN are apps, and they should be fixed in the app layer not network.

Right, AFAIK IOS solves it at the stack level (with some application requirements). So this can go both ways.

> 
> 2.  ICE and STUN work great today with v4 and v6 peer candidates, especially when combined with their close cousin TURN, in TRAM WG and specifically https://datatracker.ietf.org/doc/draft-ietf-tram-turnbis/

But we did find ICE/STUN applications not working in an IPv6 only + NAt64 network at the hackathon.

> While I'm also concerned about the consequences of carrying IPv4 debt in all IPv6 implementations, the alternative seems to be that we are stuck with Dual stack forever (for some definition of forever). This would at least allow us to move to single stack IPv6. Which appears to me to be a step forward. And we're very close to that already, and there are millions of devices already implementing it.

Cheers,
Ole