Owen DeLong wrote:
> In terms of implementing the code, sure, the result is about the same,
> but, the key point here is that there really isn't a benefit to having that
> packet mangling code in IPv6.
Unless your SOX auditor requires it in order to give you a non-qualified
audit of your infrastructure.
The SOX auditor ought to know better. Any auditor that
requires NAT is incompenent.
The real problem with IPv6 deployment is not that it can't be done, but
that there are so many still-to-be-answered questions between here and
there...
And the only way to answer them is to go ahead and find the
gaps. Waiting and waiting won't find the problems and will
just put you under more time presure.
The SOX auditor ought to know better. Any auditor that
requires NAT is incompenent.
Sadly, there are many audit REQUIREMENTS explicitly naming NAT and
RFC1918 addressing ...
SOX auditors are incompetent. I've been asked about anti-virus software
on UNIX servers and then asked to prove that they run UNIX.........
Not just SOX. I vaguely remember something in PCI about NAT. It wouldn't
surprise me if every auditing thing involving computers said something
about requiring NAT. See my earlier comment about NAT=firewall.
> The SOX auditor ought to know better. Any auditor that
> requires NAT is incompenent.
Sadly, there are many audit REQUIREMENTS explicitly naming NAT and
RFC1918 addressing ...
SOX auditors are incompetent. I've been asked about anti-virus software on
UNIX servers and then asked to prove that they run UNIX.........
Fair enough, but my point was that it isn't the auditors' faults in _all_
cases.
When the compliance explicitly requires something they are required to check
for it, they don't have the option of ignoring or waving requirements ...
and off the top of my head I don't recall if it is SOX that calls for
RFC1918 explicitly but I know there are some that do.
When the compliance explicitly requires something they are required to check
for it, they don't have the option of ignoring or waving requirements ...
and off the top of my head I don't recall if it is SOX that calls for
RFC1918 explicitly but I know there are some that do.
I believe that RFC1918 space won't be a requirement for IPv6. I'm pretty sure the requirements will change as the addressing changes. Of course, I'm sure you will have a lot of NEW requirements.
When the compliance explicitly requires something they are required to
check for it, they don't have the option of ignoring or waving
requirements ...
and off the top of my head I don't recall if it is SOX that calls for
RFC1918 explicitly but I know there are some that do.
I believe that RFC1918 space won't be a requirement for IPv6. I'm pretty
sure the requirements will change as the addressing changes. Of course, I'm
sure you will have a lot of NEW requirements.
But that is the problem - it doesn't say "You must use RFC1918 for IPv4" ...
it just says "You must use RFC1918".
Meaning, you must not run IPv6. And some regulations do not mention/address
IPv6 at all. Silence != security.
Considering that RFC1918 says nothing about IPv at all, could that be a
blocker for deployment in general? That'd also make for an interesting
discussion re: other legacy protocols (IPX, anyone?)...
Considering that RFC1918 says nothing about IPv at all,
That may technically be true, but it does explicitly reference IPv4
addresses.
Oh, and when RFC1918 (or more correctly, RFC1597) was written, "IP",
"TCP/IP", etc. all directly meant IPv4.
(RFC1597 @ 03/94 ... RFC1883 @ 12/95)
