[arin-ppml] The role of NAT in IPv6
Gary T. Giesen
ggiesen at akn.ca
Thu Apr 15 18:51:00 EDT 2010
On Thu, 2010-04-15 at 18:48 -0400, Stuart Sheldon wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> I have never seen anything in writing that states you must run NAT to
> maintain HIPAA, PCI, or DSS compliance. If such a rule actually exists,
> can someone please post a URL for reference?
>
One of the arguments for NAT earlier in this thread stated that hiding
the topology of the network from hosts outside the network was a
requirement, which is most easily achievable with 1:many NAT.
> And for what it's worth, I agree with Gary... It's our job to educate
> the less experienced about IPv6. It's not just IPv4 with more addresses,
> and for most of the built in security RFCs to work properly in IPv6, NAT
> is not a viable option...
>
> Stu
>
>
> Gary T. Giesen wrote:
> > Let's see if we can summarize the major reasons people are led to NAT:
> >
> > 1) Address scarcity - This is not an issue with IPv6, is the vast
> > majority of cases, and the reason NAT/PAT was created in the first place
> >
> > 2) Renumbering pain - Can be solved with relatively cheap,
> > readily-available GUA. Since every address is globally unique, you no
> > longer need to do 1:1 address translation. Since people can get their
> > allocations cheaply, it solves the renumbering pain/being tied to a
> > service provider. Some might argue this introduces a new cost through
> > the expansion of the DFZ and numbering of routing slots required, but
> > I'd argue the economic costs of NAT *far* outweigh this.
> >
> > 3) Regulatory requirements (HIPPA, PCI DSS) - This a policy obstacle,
> > not a technical one. Solving this involves no new implementations, just
> > educating regulators on what the realities of IPv6 are (or should be).
> > Yes, this one is the biggest obstacle, but not completely out of reach.
> > Isn't it our job as network operators to help both our customers and the
> > regulators understand that "IPv6 should work like this?"
> >
> > If we can resolve all the reasons that lead people to NAT, we all
> > benefit. Through less complexity, lower deployment and support costs,
> > and better interoperability. Whether I'm a hardware vendor, ASP, ISP,
> > anything that touches IPv6 benefits. It shortens the time to market of
> > new products, and accelerates IPv6 deployment.
> >
> > I couldn't even fathom what NAT has cost anyone who product uses IP, but
> > it's *huge*. Getting rid of it is win-win.
> >
> > GG
> >
> > On Thu, 2010-04-15 at 17:59 -0400, Owen DeLong wrote:
> >> On Apr 15, 2010, at 2:48 PM, Chris Engel wrote:
> >>
> >>> Gary T. Giesen wrote:
> >>>
> >>>> As Owen has pointed out many times, the cost of supporting
> >>>> NAT is rarely borne by the person implementing it. It's borne
> >>>> by everyone else trying to sell services to the the NAT'd customer.
> >>> So let me get this straight, you're complaining that your customers demand support for X functionality (NAT or fill in whatever blank you want) in the services that you are trying to sell them and then assert how unfair it is that you have to carry the costs of meeting your own (potential) customers demand?
> >>>
> >> I'm not sure what Gary is asserting. However, I suspect his assertion
> >> is similar to mine...
> >>
> >> I'm asserting that NAT creates the following costs borne by people
> >> providing services to NON-NATTed customers who have nothing
> >> whatsoever to do with NAT:
> >>
> >> 1. Additional troubleshooting difficulty/cost (web sites, services,
> >> network providers, network providers selling to web sites, etc.)
> >> 2. Additional software complexity (ISVs)
> >> 3. Decreased security (inability to correlate events/logs)
> >> 4. Increased legal costs (see 3)
> >>
> >>> Let me introduce you to this concept called a "free market economy".
> >>>
> >> Even in a free market economy, you're not supposed to dump toxic
> >> chemicals in the river upstream from my water treatment plant.
> >>
> >>
> >> Owen
> >>
> >> _______________________________________________
> >> PPML
> >> You are receiving this message because you are subscribed to
> >> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> >> Unsubscribe or manage your mailing list subscription at:
> >> http://lists.arin.net/mailman/listinfo/arin-ppml
> >> Please contact info at arin.net if you experience any issues.
> >
> > _______________________________________________
> > PPML
> > You are receiving this message because you are subscribed to
> > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> > Unsubscribe or manage your mailing list subscription at:
> > http://lists.arin.net/mailman/listinfo/arin-ppml
> > Please contact info at arin.net if you experience any issues.
> >
>
>
> - --
> Tambourines and elephants are playing in the band. Wont you take a
> ride on the flyin spoon? Doo, doo doo. Wondrous apparition provided
> by magician. Doo, doo, doo, lookin out my back door.
> -- Creedence Clearwater Revival - "Looking out my back door"
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (GNU/Linux)
>
> iQIcBAEBCAAGBQJLx5enAAoJEFKVLITDJSGSFn8QAJUkwfSrMJu8HR3xIRGB5d9j
> 0isjPJbhh3XDKYrb9AXzMc0L9r21h6rgZPT6qwdJ4wGJuFLi2wrKAYMeHatseXql
> GkP1vsMOK69JrG4vlAm+VqodCWscXDim/1YxGZIDAqYl17Bfdhfnw6KebSIr0Jz4
> PiZiGga0sD1AYQSGiIGZNf/4ockpIIEvd0RTBSFIig3h3eBECz7DUjqWBWGqmx8I
> 4ICX1aMLLCd6LwEj9wUuzZJscPXo7IeqNDhC4xju19rjQCxg9IWMIdvV5VmIwPFI
> vGfspIEZSeirYPvP23xYlb/DilsmLgZZFWzanoZ0O/KVfcddkVYY1ujILQrUyPpB
> uIOR7mDmSTV0AIwk5fPEbVL8QOj3RQaCM7hyzQNS/AghGuzS8xHYFzU2Pbfg/UXb
> hI9pXqAIpZjLNwzIqnf1+xqs6GwYOYMvxuo+GTFRi7NiAw0sLT6MrcqNJjPa5E/Z
> nj85NGHmZHyYJd8kqILjhRiTPWNFt/2EthHkostmJTnb3ppunO7l5wPzILXNFt9A
> x8u0b5bLFdpoOe1vK39gOTiQfOQhfO67W0yoQAnqUYcSS+XLuKmKKwUibKWmnBak
> cinIfgAu5fmqq9BZv42wNZ73y6b1qUJtV+hR7Pk1JszP2mWORdR/8F5nvTFZwxLG
> sl6C16FOS1u+vGrrc0OH
> =mje+
> -----END PGP SIGNATURE-----
More information about the ARIN-PPML
mailing list