will IPv6 have private addressing?

[mammador]

I personally think it should, even if the IEEE hasn't developed an RFC yet.

Depending on the nodes one has available, i don't get just because there is a new IP version, that Joe Internet user in China or Senegal can see inside your network, when the chance of that is limited in IPv4.

 

[drebo]

Couple of things... IPv6 does have the concept of non-routable prefixes, similar to RFC1918 addresses that IPv4 has. These are defined in RFC5156. There are several... The scope of fe80::/10 is designated for "link-local" addressing. These define local addresses a shared ethernet segment. These are automatically generated and assigned. These are still used for things like routing protocols and next-hops.

Original specifications also called for "site-local" addressing in the scope of fec0::/10. Site-local addresses are perfectly analogous to RFC1918 addresses. These have, however, been depricated and are not recommended for use in modern networks.

Why? Because NAT has been depricated with IPv6. NAT is an ugly hack that breaks a lot of protocols and is generally not a great idea. It also does not, by itself, provide any sort of security what so ever. An open PAT on a router (which has to happen for an inside host to talk to an outside host) is bidirectional and stateless. There are no protections offered what so ever. It is only when you begin to add firewalling that protections start to be seen. Stateful packet inspection, for instance, will make sure that only packets of the same L4-7 protocol as the protocol that originated the PAT pass through the open PAT.

Firewalling, however, can also be done without NAT, and is equally effective. Routed firewalling can be done without NAT and firewalling can also be completely transparent. It is equally as effective as firewalling with NAT, but is safe in terms of L7 protocols which rely on L3 addressing (SIP, HTTP, FTP, PPTP, and RPC, to name a few.) NAT breaks a lot of things and the only thing it does for IPv4 is provide for reusable IP space.

IPv6, on the other hand, has no shortage of addresses. And, in fact, there exist enough addresses for every person on Earth both now and to be born in the next hundred years to have the equivilent of the current IPv4 address space for every minute of their lives. The smallest available block requestable from ARIN by an enterprise is a /64, which is nearly incomprehensibly larger than the existing IPv4 address space. So much so that they've decided that they're only going to assign global unicast IP addresses from the 2000::/3 scope.

Basically, there is no need for NAT anymore, and thus no need for a "private" IP scope. This is a GOOD thing, not a bad thing. NAT is not security and should not be considered as such. A good firewall does not require NAT to be effective. It is very possible to shield your internal network from external view without NAT.

 

[theevilsharpie]

I personally think it should, even if the IEEE hasn't developed an RFC yet.

http://en.wikipedia.org/wiki/Unique_local_address

Although their general-purpose use isn't recommended.

 

[mammador]

Couple of things... IPv6 does have the concept of non-routable prefixes, similar to RFC1918 addresses that IPv4 has. These are defined in RFC5156. There are several... The scope of fe80::/10 is designated for "link-local" addressing. These define local addresses a shared ethernet segment. These are automatically generated and assigned. These are still used for things like routing protocols and next-hops.

Original specifications also called for "site-local" addressing in the scope of fec0::/10. Site-local addresses are perfectly analogous to RFC1918 addresses. These have, however, been depricated and are not recommended for use in modern networks.

Why? Because NAT has been depricated with IPv6. NAT is an ugly hack that breaks a lot of protocols and is generally not a great idea. It also does not, by itself, provide any sort of security what so ever. An open PAT on a router (which has to happen for an inside host to talk to an outside host) is bidirectional and stateless. There are no protections offered what so ever. It is only when you begin to add firewalling that protections start to be seen. Stateful packet inspection, for instance, will make sure that only packets of the same L4-7 protocol as the protocol that originated the PAT pass through the open PAT.

Firewalling, however, can also be done without NAT, and is equally effective. Routed firewalling can be done without NAT and firewalling can also be completely transparent. It is equally as effective as firewalling with NAT, but is safe in terms of L7 protocols which rely on L3 addressing (SIP, HTTP, FTP, PPTP, and RPC, to name a few.) NAT breaks a lot of things and the only thing it does for IPv4 is provide for reusable IP space.

IPv6, on the other hand, has no shortage of addresses. And, in fact, there exist enough addresses for every person on Earth both now and to be born in the next hundred years to have the equivilent of the current IPv4 address space for every minute of their lives. The smallest available block requestable from ARIN by an enterprise is a /64, which is nearly incomprehensibly larger than the existing IPv4 address space. So much so that they've decided that they're only going to assign global unicast IP addresses from the 2000::/3 scope.

Basically, there is no need for NAT anymore, and thus no need for a "private" IP scope. This is a GOOD thing, not a bad thing. NAT is not security and should not be considered as such. A good firewall does not require NAT to be effective. It is very possible to shield your internal network from external view without NAT.

I agree for the most part, but in IPv4 private addressing was for security purposes as much as conserving addressing space. and yeah, v6 has a shitload of addresses so that aspect of private addressing makes little sense.

But wouldn't this make firewalls more prone to hacking, if that's the only thing preventing unauthorised access?

 

[drebo]

I agree for the most part, but in IPv4 private addressing was for security purposes as much as conserving addressing space. and yeah, v6 has a shitload of addresses so that aspect of private addressing makes little sense.

But wouldn't this make firewalls more prone to hacking, if that's the only thing preventing unauthorised access?

No, because firewalls ARE CURRENTLY the only thing preventing unauthorized access.

"Security through obscurity," which is what NAT is in terms of security, is not security at all. It's like saying that because I don't broadcast my SSID, people won't be able to find my network and so won't be able to attack it. NAT is no different. NAT, by itself, does not provide security in any tangible form. The only security it provides is the same type of security not broadcasting your SSID provides.

 

[Nothinman]

I agree for the most part, but in IPv4 private addressing was for security purposes as much as conserving addressing space. and yeah, v6 has a shitload of addresses so that aspect of private addressing makes little sense.

But wouldn't this make firewalls more prone to hacking, if that's the only thing preventing unauthorised access?

Firewalls deny by default so the security a firewall provides will be virtually the same, it just won't require NAT or PAT to allow access to certain services back into the protected network.

 

[Cooky]

Security is achieved via properly configured ACL or policies on firewall.
Even if NAT is in place, you're prone to a breach if the firewall is not configured correctly.

 

[Gryz]

even if the IEEE hasn't developed an RFC yet.

IEEE has nothing to do with IP-standards.
It is the IETF that produces RFCs.

And btw, I completely disagree about almost everything that is being said here about NAT. If I ever get IPv6 (which I don't think I will), the first thing I will do is turn on NAT. Easy simple security, without the risk of configuration mistakes. I love it.

Lucky for me, we don't have to do this discussion here again, because there is no IPv6, and there won't be any IPv6 in the next 10 years. Or maybe ever.

 

[drebo]

IPv6 has no current standard for NAT at the moment, so good luck with that.

Also, before you completely fuck over the company you're working for, you might want to let someone above your paygrade know about your little "plan." He might know a little bit more about NAT than you do, as you clearly know nothing about how NAT works.

 

[Nothinman]

IEEE has nothing to do with IP-standards.
It is the IETF that produces RFCs.

And btw, I completely disagree about almost everything that is being said here about NAT. If I ever get IPv6 (which I don't think I will), the first thing I will do is turn on NAT. Easy simple security, without the risk of configuration mistakes. I love it.

Lucky for me, we don't have to do this discussion here again, because there is no IPv6, and there won't be any IPv6 in the next 10 years. Or maybe ever.

There's always a risk of configuration mistakes, the types of failure just change (and normally get more complicated) once you start using PAT/NAT.

 

[Gryz]

Also, before you completely fuck over the company you're working for, you might want to let someone above your paygrade know about your little "plan." He might know a little bit more about NAT than you do, as you clearly know nothing about how NAT works.

Was that directed at me ?
Is that a personal attack ?

I would not suggest that a (large) company would use only NAT, and not use a firewall. But for networks at home, or networks at very small companies, I see no problem enabling NAT on your access router and have that as your main security.

NAT is a tool. You use it where it has value. And it happens NAT has a lot of value in a lot of situations. NAT is probably be the main reason people haven't been forced to switch to IPv6 yet.

IPv6 is a missed opportunity. We knew it in 1995, we know it now. IPv4 has a number of architectural flaws. (No identifier/locator separation, no support for proper multi-homing, no on-the-fly renumbering, etc). IPv6 was an opportunity to fix those issues. But the IPv6-folks decided to not do that. All they did was increase the address-space. As a result, IPv6 has no attraction to the individual, only to "the Internet as a whole". Also, because the IPv6-folks declared NAT as "evil", and stubbornly refused to standardize anything about IPv6/IPv4 NAT (or other interoperability), we have never had a good migration scheme. The result it known. 16 years of IPv6, and nothing has happened. Will somthing happen in the next 16 years ? Nobody knows.

 

[Nothinman]

Was that directed at me ?
Is that a personal attack ?

I would not suggest that a (large) company would use only NAT, and not use a firewall. But for networks at home, or networks at very small companies, I see no problem enabling NAT on your access router and have that as your main security.

NAT is a tool. You use it where it has value. And it happens NAT has a lot of value in a lot of situations. NAT is probably be the main reason people haven't been forced to switch to IPv6 yet.

IPv6 is a missed opportunity. We knew it in 1995, we know it now. IPv4 has a number of architectural flaws. (No identifier/locator separation, no support for proper multi-homing, no on-the-fly renumbering, etc). IPv6 was an opportunity to fix those issues. But the IPv6-folks decided to not do that. All they did was increase the address-space. As a result, IPv6 has no attraction to the individual, only to "the Internet as a whole". Also, because the IPv6-folks declared NAT as "evil", and stubbornly refused to standardize anything about IPv6/IPv4 NAT (or other interoperability), we have never had a good migration scheme. The result it known. 16 years of IPv6, and nothing has happened. Will somthing happen in the next 16 years ? Nobody knows.

They didn't declare it evil, they just acknowledged that it's a bad idea that breaks many protocols and shouldn't be perpetuated in future networking schemes.

 

[Gryz]

They didn't declare it evil, they just acknowledged that it's a bad idea that breaks many protocols and shouldn't be perpetuated in future networking schemes.

Networking technology is religion.
People express their feelings in the same exaggerated ways as they do when talking about religion.
Believe me, I have heard many people say that NAT is evil.
And imho the IPv6-folks shot themselves in the foot when they insisted that migration tools that would allow IPv4 and IPv6 work together, would only delay the migration to IPv6.

Again, NAT is a useful tool. It is here. And it is here to stay. If you design a new protocol, you better make sure that it works with NAT in general. That's not so hard actually. (Just don't embed raw IP addresses in your protocol-fields).

The tricky part of getting a new protocol to work with NAT is that nobody can initiate a connection to a box behind my NAT router. That is a problem. But it is also a very useful feature. To enable services behind a NAT router, you have to "poke a hole". That is extra work. But at least the user is aware that he is poking a hole in his security. (Personally I think that UPnP is evil for this reason). I think the benefit outweighs the downsides.

 

[Nothinman]

Networking technology is religion.
People express their feelings in the same exaggerated ways as they do when talking about religion.
Believe me, I have heard many people say that NAT is evil.
And imho the IPv6-folks shot themselves in the foot when they insisted that migration tools that would allow IPv4 and IPv6 work together, would only delay the migration to IPv6.

Again, NAT is a useful tool. It is here. And it is here to stay. If you design a new protocol, you better make sure that it works with NAT in general. That's not so hard actually. (Just don't embed raw IP addresses in your protocol-fields).

The tricky part of getting a new protocol to work with NAT is that nobody can initiate a connection to a box behind my NAT router. That is a problem. But it is also a very useful feature. To enable services behind a NAT router, you have to "poke a hole". That is extra work. But at least the user is aware that he is poking a hole in his security. (Personally I think that UPnP is evil for this reason). I think the benefit outweighs the downsides.

I know people do, but that doesn't immediately make them wrong. NAT is a nice feature, but the fact that you can't initiate direct connections back to the client makes things like FTP and SIP break and can require a lot of work to make function and isn't a simple as "poking a hole".

 

[Gryz]

NAT is a nice feature, but the fact that you can't initiate direct connections back to the client makes things like FTP and SIP break and can require a lot of work to make function and isn't a simple as "poking a hole".

FTP broke in 1995, when Network Translation Inc came out with their PIX. But within 1-2 years, every ftp implementation switched from having separate control and data connections, to having both go over 1 TCP connection. Problem fixed. Lesson learned.

SIP is a problem. I agree. Having SIP in your cable or adsl modem (or access router at a bigger company) is a solution. There are downsides here, like not having the flexibility to upgrade software/features on your router as you want. And depending on your vendor. But maybe one day Software Defined Networking will solve that too ! (Yes, I learned a new word this week. 🙂)

 

[Nothinman]

FTP broke in 1995, when Network Translation Inc came out with their PIX. But within 1-2 years, every ftp implementation switched from having separate control and data connections, to having both go over 1 TCP connection. Problem fixed. Lesson learned.

SIP is a problem. I agree. Having SIP in your cable or adsl modem (or access router at a bigger company) is a solution. There are downsides here, like not having the flexibility to upgrade software/features on your router as you want. And depending on your vendor. But maybe one day Software Defined Networking will solve that too ! (Yes, I learned a new word this week. 🙂)

No FTP implementation uses 1 connection unless you use another protocol like SFTP. FTP still uses either passive or port, one has the server initiate the data connection back to the client and the other has the client initiate the data connection back to the server over port 20. And of course IE defaults to the former so most people can't use FTP without a firewall doing inspection and fixing the packets as they pass through.

Having your router be a voice gateway works, but then I have to buy more hardware instead of just setting up something like IP Communicator. Cisco has other options too like the phone proxy support in ASAs, but that's more licensing required.

 

[imagoon]

I am on the fence with NAT. #1) at home it works fine for me. I also am a person that believes that my fridge doesn't need a world routable IP. However after the cluster f*** that I was involved in digging a fortune 500 out of with NAT devices, I consider them pretty much evil for anything other than LAN😛ublic Internet points, specifically those for "general web surfing" not the "companies web gateways / smtp gateways etc.

Also FTP to this day uses 2 sessions. Like Nothingman said "PASV / PORT." You need an FTP Daemon that is "nat aware" to work properly. Typically doing things like mapping ports on the NAT IP (typically a lot of them) to the FTP server for PASV based connections. Then the FTPd needs to be aware that only a certain range is assigned to it and only send back port connections in the PASV command that are mapped. At the same time, the FTPd needs to be willing to accept the connections on whatever port the PAT actually sends it on.

I have made it work but it seems beyond quite a few companies IT groups.

 

[Gryz]

Are you guys serious ? Are there still a large number of FTP implementations around that do not do passive FTP ? Or any, actually ? (I haven't done any support for over a decade, so I have zero touch with current days).

Back in the day, when this was an issue for the first time, I thought passive FTP fixed it. And it was just a matter of time before all FTP implementations would do only passive FTP. That was 1995 or 1996. I can't believe what I hear. 🙂 So much for technology improvements.

 

[RadiclDreamer]

Repeat after me folks: Nat is not security!

It is essentially locking your screen door and thinking you are secure.

 

[Gryz]

So please enlighten me.

I have a PC behind a router with NAT. PAT to be precise. The router is a Fritzbox, the PC runs Win7. I have configured the router to poke holes for TCP range 22000-22500. No other TCP is allowed in.

Now tell me, how would you attack my PC ?
You won't be able to reach it even ?
I am really curious.
Just explaining a general outline of a strategy would make me already happy.

(We're talking network layer security here, right ? Not at the application layer, viruses, trojans, etc. Right ?)

 

[imagoon]

Are you guys serious ? Are there still a large number of FTP implementations around that do not do passive FTP ? Or any, actually ? (I haven't done any support for over a decade, so I have zero touch with current days).

Back in the day, when this was an issue for the first time, I thought passive FTP fixed it. And it was just a matter of time before all FTP implementations would do only passive FTP. That was 1995 or 1996. I can't believe what I hear. 🙂 So much for technology improvements.

PASV FTP still uses 2 connections. Control and Data.

Also to specify, in the enterprise we still had firewalls doing filtering and not only NAT.

 

[Nothinman]

Are you guys serious ? Are there still a large number of FTP implementations around that do not do passive FTP ? Or any, actually ? (I haven't done any support for over a decade, so I have zero touch with current days).

Back in the day, when this was an issue for the first time, I thought passive FTP fixed it. And it was just a matter of time before all FTP implementations would do only passive FTP. That was 1995 or 1996. I can't believe what I hear. 🙂 So much for technology improvements.

We just had a client with an issue because IE on Win7 doesn't do PASV by default and there's no clear-cut GPO to fix it, so yes it's very much still an issue today. And even with the IE GPO that I created 3rd party apps that use FTP weren't doing PASV so we had to roll back the network changes we made. It's very much an issue still and one that having all of the clients using routable IPs would have avoided.

I'm not saying FTP is a good protocol by any means, but it's still heavily in use so you can't just disregard it's use. BitTorrent has similar issues as well, which is why most clients either do UPnP or let you set a range of ports for incoming connections and give you instructions on how to forward them to your PC. Essentially, NAT/PAT causes more problems than it fixes.

 

[theevilsharpie]

So please enlighten me.

I have a PC behind a router with NAT. PAT to be precise. The router is a Fritzbox, the PC runs Win7. I have configured the router to poke holes for TCP range 22000-22500. No other TCP is allowed in.

Now tell me, how would you attack my PC ?

Assuming that your equipment is working properly, and discounting any potential security vulnerabilities in the application listening on those ports, no one would be able to attack your PC outside of the port range that you've specified.

However, limiting what port ranges are accessible is the function of the firewall, not NAT.

 

[drebo]

So please enlighten me.

I have a PC behind a router with NAT. PAT to be precise. The router is a Fritzbox, the PC runs Win7. I have configured the router to poke holes for TCP range 22000-22500. No other TCP is allowed in.

Now tell me, how would you attack my PC ?
You won't be able to reach it even ?
I am really curious.
Just explaining a general outline of a strategy would make me already happy.

(We're talking network layer security here, right ? Not at the application layer, viruses, trojans, etc. Right ?)

Every external connection you make creates a hole that will allow inbound traffic through. Any data can pass through that hole. It's up to Stateful Packet Inspection (a feature of the firewall) to make sure only the RIGHT data is allowed through. Unsolicited inbound traffic being blocked by an ACL is a function of firewalling, not NAT.

More than that, I can accomplish the same thing with a transparent firewall without utilizing NAT and breaking bunches of protocols.

 

[Gryz]

Every external connection you make creates a hole that will allow inbound traffic through. Any data can pass through that hole.

AFAIK the NAT box will create a temporary "nat entry" in its translation table. This is triggered when my PC starts a TCP connection (or a UDP flow). The nat entry consists of: src address, src portnr, dst address, dst portnr and protocol type (tcp or udp). This looks to me a lot like an ACL. The NAT box will now allow packets back in, with src/dst values inverted.

So it seems to me that nothing else gets in from the outside. If you want to do something malicious, you'll have to try to insert fake packets/segments into an existing tcp connection. Guessing TCP sequencenumbers, etc. But if you can do that for a connection with a dynamic nat entry, you should be able to do the same thing for a TCP connection that goes through a static ACL. I don't see the difference. Except that with NAT, it might be harder to guess the random source portnr, while with an ACL, things are less random.

It's up to Stateful Packet Inspection (a feature of the firewall) to make sure only the RIGHT data is allowed through. Unsolicited inbound traffic being blocked by an ACL is a function of firewalling, not NAT.

NAT happens to fullfill the same goal. Unsolicited inbound traffic will not get through NAT. Assuming you haven't opened an abundance of ports. Sure, suppose you run a sshd, with a firewall you can specify from where people can connect via ssh. But generally, you want (or your users) to be able to connect via ssh from anywhere in the world. Make sure your sshd is configured proberly and patched up to date. I don't see the difference.

I don't see how stateful packet inspection of a firewall can see if an incoming ssh connection is valid or not.

More than that, I can accomplish the same thing with a transparent firewall without utilizing NAT and breaking bunches of protocols.

Agreed. A firewall has a lot more features and functionality than a simple NAT box. But my original point was: for (very) small businesses and home users, NAT is giving them enough security. And a complex firewall won't bring them much value added. Except more headaches. And more potential to configure something wrong. NAT gives basic protection against unwanted incoming traffic. If you don't do anything fancy, you don't need more security, imho. If some (badly designed) protocols can't handle NAT, I don't find that price too high too pay.