Re: [sunset4] draft-ietf-sunset4-nat64-port-allocation

[GangChen <[e-mail]>]

Hello Alberto,

Thank you for reading the draft.

2015-09-25 4:15 GMT+08:00, Alberto Leiva <[e-mail]>:
> Hi
>
> Regarding Port Randomization:
>
> Isn't hole punching worth mentioning? This being an analysis and all. Hole
> punching is like the "good" counterpart of TCP port-guessing attacks.
>
> It seems port randomization trumps simultaneous open of TCP connections
> (RFC 6146 pp. 28-30), so a random NAT64 could even forego or optional-out
> their implementation to avoid its complexity and performance hit (due to
> packet storage).
>
> See
> http://ietf.10.n7.nabble.com/Re-Last-Call-draft-ietf-behave-v6v4-xlate-stateful-Stateful-NAT64-Network-Address-and-Protocol
> and
> http://ietf.10.n7.nabble.com/Re-Review-of-the-NAT64-document-td214997.html

I read the discussion you pointed. It seems talking about the impacts
of TCP state change on NAT64 to the hole punching (I miss the first
link, it's invalid any more).
It would be helpful if you could elaborate more on the relation of
port randomization and hole punching. Not sure I understand correctly,
it seems you prefer using port randomization to facilitate the hole
punching process, in which simultaneous open of TCP connections are
involved. I may not able to figure out the hole punching process based
on port randomization, since port randomization may not can help users
to discover their exact NAT mapping, also it can't replace outbound
signalling, e.g., SIP.

Would be good to hear you more;)

> ------------------------------
>
> Also a small nitpick, feel free to ignore:
>
> Isn't the terminology a bit all over the place?
>
> In particular
>
>> Stateless NAT is performed in compliance with [RFC6145].
>> (...) Thus the NAT64 can directly extract the address and has
>> no need to record mapping states.
>
> What do you mean? RFC 6145 is SIIT, which to my knowledge is only
> informally (and some might say incorrectly) known as "Stateless NAT64"
> (much less "Stateless NAT")... even if it's "network address translating".
>
> Through the whole document the word "NAT64" is used where "IPv4/IPv6
> translation" would perhaps be more appropriate.
>
> "Stateless NAT64" doesn't exist. Or, at the very least, it isn't defined in
> any standards that I have seen.

RFC7599 may help.
There are several statements, like "It builds on existing stateless
NAT64 techniques specified in [RFC6145],...", "A stateless NAT64
function [RFC6145] is extended to allow stateless mapping of IPv4 ..."

BRs

Gang

> Alberto
>