[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: v6ops-nat64-pb-statement-req: Scoping and title



Brian E Carpenter  - Le 7/26/08 12:24 AM :
Note that, using RFC 2663's terminology, the distinction is more precisely: - NAT64: IPv6 internal side, IPv4 external side - NAT46:
IPv4 internal side, IPv6 external side

Where do you find that in 2663?

In the introduction:
"network's internal IP addresses cannot be used outside the network either because they are invalid for use outside, or because the internal addressing must be kept private from the external network."


Another way to say it is that addresses that need translation are those of hosts in the internal side network. They are translated as source addresses in the internal to external direction, as destination addresses in the external to internal direction.


In any case I think the notions of "internal" and "external" are not
well-defined in a network which mixes regions of pure IPv6, regions
of pure IPv4 and dual-stack regions. Also, NAT terminology tends to be based on the distinction between private ambiguous and public
global addresses, which makes no sense for IPv6.

(NATs that do port forwarding support connections initiated from
both sides.)

Exactly. I don't think this can be reduced to two acronyms.

I also find that more precise acronyms could be useful.
For example, private IPv4 address spaces (RFC 1918), say 4p, could advantageously be distinguished from the global IPv4 address space, say 4g.

Thus:
- NAT4p6 and NAT64g can be cascaded to be equivalent to a NAT4p4g for connections initiated by 4p hosts (no DNS ALG needed). - In the reverse cascade, NAT4g6-NAT64p, the NAT 4g6 has the problem that, for connections initiated by 4g hosts, there is no stateless translation of 4g addresses into routable v6 addresses.


Regards

Rémi Després