Re: IPv6 only host NAT64 requirements?

[james woodyatt <[e-mail]>]

On Nov 15, 2017, at 15:24, Ole Troan <[e-mail]> wrote:
>>> 
>>>>> IMHO the optimal solution is:
>>>>> - the network SHOULD provide a host with NAT64 prefix information in RA;
>>>> 
>>>> Disagree. If the network has NAT64, then it should deploy RFC 7225. Ye gods, this is the very last thing that should be jammed into RA messages.
>>> 
>>> Do we really want PCP in IPv6?
>> 
>> If we have any kind of NAT, then we need PCP. Using NAT without PCP considered harmful. That goes for NAT64 and NAT66.
> 
> It's not for the lack of trying that IPv6 isn't adopted everywhere.
> As IPv4 address sharing ratio's increase, say good bye to endpoint independent NATs, IP fragmentation...
> 
> But now I have to first implement a PCP client, discover the PCP server address, and then finally get the NAT64 prefix. ;-)

Having implemented a PCP client, I can say from experience that it is a lot easier than implementing a DHCPv6 client.

Oh, and you have to discover all the PCP server addresses (in addition to the PCP server anycast address by RFC 7723) before you can use RFC 7225 to discover the NAT64 network-specific prefix (NSP) for each one. If you’re really married to DHCPv6, then I suppose you could use RFC 7291 for that. But if you want to add those data to RA messages too, why not? (Oh right, I remember why not: because it’s a bad idea. Just use the anycast address.)

>>> Is PCP successful in IPv4?
>> 
>> Well, there was this: <https://www.ietf.org/proceedings/88/slides/slides-88-pcp-5.pdf>
>> 
>>> Or does it even work well with A+P based solutions?
>> 
>> Designed expressly for it.
> 
> Ah, yes so it does.
> Doesn't work well with address and port dependent filtering though.

Is there a reason you think <https://tools.ietf.org/html/rfc6887#section-13.3 <https://tools.ietf.org/html/rfc6887#section-13.3>> doesn’t work well? Seemed to work well when I implemented it.


--james woodyatt <[e-mail] <mailto:[e-mail]>>