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

[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

------------------------------

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.

Alberto