Re: NAT66 : A first implementation

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

 



On 7/15/11 17:12, Jul 15, Jeff Haran wrote:
I was unaware of the RFC. Thanks for the reference, however I have to
point out the following quote from its introduction:

"For reasons discussed in [RFC2993] and Section 5, the IETF does not
recommend the use of Network Address Translation technology for IPv6."

That statement is simple IETF politics. A substantial portion of RFC 2993 doesn't apply to the RFC 6296 mechanism. For example, of the seven problems enumerated in section 7, only two -- 7.2 and 7.5 -- remain applicable. And, to be fair, those two issues are very minor compared to the other five.

I'm not saying nobody is going to use IPv6 NAT nor that the Linux world
should somehow make it hard on them to do so. There may be a few cases
where it makes sense.


Exactly. Even the most recent IAB statement on IPv6 NATs (RFC 5902) concedes: "[I]n smaller managed networks that cannot get provider-independent IP address blocks, renumbering remains a serious issue. Regional Internet Registries (RIRs) constantly receive requests for PI address blocks; one main reason that they hesitate in assigning PI address blocks to all users is the concern about the PI addresses' impact on the routing system scalability."

So, yes, IPv6 NAT remains inadvisable for most residential applications (which can simply propagate their ISP's assigned prefix down to devices), and some very large enterprise deployments (which can get PI address blocks). But it does solve a very real problem for small to medium (and even large, depending on where you want to draw the line) enterprises -- basically, "everyone else."

It seems a little silly to refuse _consideration_ of NAT technologies when (1) a preponderance of the problems historically present in IPv4 NATs have been addressed, and (2) a small but nontrivial portion of networks that will be using IPv6 soon will desire this technology for operational cost reasons.

What I'm saying is that this age-old policy statement: <http://lists.netfilter.org/pipermail/netfilter/2005-March/059463.html> needs to be revisited. The facts on the ground have changed. Adhering to beliefs in the face of contrary evidence isn't principle -- it's religion. And imposing religion on others doesn't help anyone.

/a
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Netfitler Users]     [LARTC]     [Bugtraq]     [Yosemite Forum]

  Powered by Linux