On Nov 11, 2009, at 2:20 AM, Keith Moore wrote:
Chris Engel wrote:
Gentlemen,
Unless I am misunderstanding how ULA works I don't see how it
addresses the 2nd issue I raised. It provides a private address
space, but doesn't provide any means to relate that space to your
public address space. I don't see any abstraction there.... just
the possibility to maintain an additional space.
Example: I have a service that I publicly advertise on Network A,
Host 1 (public address space). I provide that service on an
internal device on Network B, Host 1 (private address space) but I
want to move that service (either temporarily or permanently) to
be provided on a different internal device Network B, Host 2
(private address space). I don't see how ULA helps with that. It
allows me to have a private address space...but it doesn't provide
any mapping of that space to the Public Address space... that's
what NAT does.
I don't think NAT causes many problems when used in this manner - to
map specific hosts with specific, well-known, services, to specific
external addresses. The alternative would be to use a tunnel, which
has its own problems, and it's a case of choosing the lesser of two
evils. Which is better depends on specific circumstances.
But that kind of NAT has almost nothing in common with the kind of
NAT you cite below:
That kind of NAT has, of course, everything in common with NAT66.
Finally I don't believe you would have a very successful time
convincing a security auditor that ULA covers the PCI-DSS v1.2
Requirement 1.3.8, when they say use "Use network address
translation (NAT)" that is PRECISELY what they want you to do. I've
dealt alot with those type of audits. You are going to have a VERY
tough sell that ULA is an acceptable "compensating control" for that.
What PCI-DSS v1.2 requirement 1.3.8 actually says is:
"1.3.8 Implement IP masquerading to
prevent internal addresses from being
translated and revealed on the Internet,
using RFC 1918 address space. Use
network address translation (NAT)
technologies—for example, port address
translation (PAT). "
Obviously this would need to be updated to be met in IPv6 at all, as
RFC 1918 is IPv4-only. The simplest change would be to use ULAs (the
IPv6 replacement for RFC 1918 address space) instead. This section
does not actually require port translation, although it is mentioned.
So, I think you could meet this requirement for IPv6 by using ULAs for
internal addressing and NAT66 to translate the RFC 1918 space to
external addresses.
Chris, do you know if there is any plan to update the PCI requirements
to cover IPv6?
Margaret
_______________________________________________
nat66 mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/nat66
