Re: Does IPv6 preclude use of a NAT gateway?
On Mon, Jul 11, 2011 at 11:50 PM, Scott Ferguson
<prettyfly.productions@gmail.com> wrote:
> On 12/07/11 12:22, Nico Kadel-Garcia wrote:
>> Oh, my. You can load the IP addresses *directly*, by IP address, and
>> access them if you have a route to them.
>
> *If you have a route*.... in the examples given there is no route, hence
> NAT.
*Really*. Then I suggest you look up the output of your local "route
-n" command on any internal network that uses both 192.168.0.0/24 and
10.0.0.0/8, or look up the output of the "traceroute" command. The
route between them is handled by whatever internal gateway is used to
connect them, but it counts. It's not typically routed in the sense of
having BGP scores associated with them, but you';d better believe that
the routers of a company that VPN connects such local address spaces
had better know about them.
>
> I simplified things (as noted in the original post) as a means of
> explaining why NAT != security.
> CIDR would take more time than I have available to explain.
>
>> This is quite common inside VPN's,
>
> You can NAT VPN can *you*? :-)
Was I unclear on this? Organizations large enough to run VPN's,
"Virtual Private Networks", use an encrypted channel to present a
gateway to another location. It's typically done with the other
location on a different address range, a different "VLAN", and often
those address ranges are precisely the private, "non-routable" address
ranges we're talking about.
The routing between these so-called "non-routable" address spaces is
done via encrypted channels with VPN tools, but oh, yes, it can be
full-blown genuine "routing". The distinction between a "route" and a
"gateway" can get muddied, it's true.
>> and as an example is common to all of AOL's internal server address
>> space (which uses the 10.0.0.0/24 address space,
>
> See my comment about CIDR.
> AFAIK AOL only started that in early 90s - so I'm not sure what you're
> trying to say.
Their backend server IP addresses, the ones that support their service
infrastructure, were all in the 10.0.0.0/24 address space and dould
only reach out with NAT or port forwarding. I dealt with a number of
such hosts and allocating servers inside their network space: I had to
be very careful not to step on their unpublished address space with
the 10.* addresses my own company's servers normally used.
>> or did a few years ago.) It's also common in internal networks where
>> 192.168.1.0/24
>
> Apropos of the examples given - access from the internet to
> machines behind a NAT??
Separate issue. The *internal* access is routed. It's not very
complex, it's not public, but yes, indeed, it can be routed, whether
in the sense of declaring individual static "routes" on specific
hosts, or in the sense of full load balanced routing for multiple VPN
connections.
>> might be dedicated to a demilitarized zone for external servers,
>> 192.168.2.0/24 might be your internal hosts, 192.168.100.0/24 is
>> dedicated for idiots who connect internal NAT gateways, etc.
>
> Again - I used "Class" addressing for the purposes of the example - feel
> free to use 8.8.8.8 for a private address. The point of your comment
> is?? (seriously)
See above.
>> The lack of routes to to such non-routable address ranges is a
>> *convention*, (http://en.wikipedia.org/wiki/Private_network), and
>> published in numerous RFC's.
>
> No dispute there - see my comment about the distinction between illegal
> and unworkable.
>> IPv6 has its own..... ideas about how to deal with thus, but it
>> certainly has reserved, non-routable address spaces.
>>
> Not sure what post you're replying to - I certainly didn't say anything
> about a lack of reserved address with IPV6.
It gets confusing if you don't mention it. The "go use IPv6, NAT is
unnecessary, you can have public IP addresses for *EVERYTHING* misses
several of the real reasons for NAT. Not having your address spaces
exposed, and not having to *register* them in any way if you have a
NAT working, are several of those reasons.
> If information is your desire - I was, clearly, responding to Randy's
> question. Apart from the redundant wikipedia quote I can't see the
> relevance of your post to anything I've said.
We seem to have a disagreement about what the word "route" means, at
the core of this. I'm using it in the broader sense, which would also
include gateway and bridge functions. This is reflected in local
system state, such as the output of the "route" command.
Reply to: