IP Apocalypse - RIPE confirms available IPv4 addresses will run out in November

[dalekphalm]

20 hours ago, bcredeur97 said:

I kinda wish they had just added another Octet or 2 to IPv4.

 

i.e. 0.0.0.0.0 or even 0.0.0.0.0.0

IPv6 is great, but I find the addresses are so much harder to remember because they aren't just numbers...

I always wondered why they didn't just use the existing system for IPv4 and expanded it in a logical manner.

9 hours ago, leadeater said:

I have to work with networking all the time, knowing IP addresses come up just as much and is more important than the DNS name. IPv6 address are just a right pain, we deal with that by prefix of our IPv6 network address then suffix is the IPv4 address so all our IPv6 addresses are identical to our IPv4 addresses just with an IPv6 prefix in front of it, mental life saver honestly.

Interesting idea - I never considered that. Can you give me a made up example of what an IPv6 would look like under your scheme?

8 hours ago, jagdtigger said:

Label the machine? We have two printers where i work. One main and one reserve. Main one is labeled as COK and reserve is COKR........  Stop looking for excuses why you cant use it. I also have IPv6 on my LAN. Infrastructure (routers, AP's, NAS's, etc) has fixed IP, everything else is dynamic. For the fixed stuff i have bookmarks and DNS entries for everything connected to the router. Thats about it

You can call it excuses all you want - but someone working in the industry dealing with networks - using IPv6 is simply more difficult than v4.

I can look at a v4 address and tell what subnet it's on. I can tell the gateway. I can tell a lot of details at a glance, without having to look anything up. From what I can tell from my v6 research (been a long time since College, and we barely even touched on v6), you can tell some of these details, but it's still a significantly more complicated structure.

 

And there are going to be situations where it's simply better to be able to remember a few key IP Addresses on the fly. With v6, that's going to become difficult.

 

They were obviously trying to solve the problem of "never running out of addresses again", but in my opinion, they went too far in this direction without considering usability as an equal factor.

[jasonvp]

29 minutes ago, dalekphalm said:

I always wondered why they didn't just use the existing system for IPv4 and expanded it in a logical manner.

Interesting idea - I never considered that. Can you give me a made up example of what an IPv6 would look like under your scheme?

dead:beef:1234:5678:10:200:5:3 could be an example.  It's a valid IPv6 address on the dead:beef:1234:5678/64.  See the IPv4 address there?

 

Quote

 

They were obviously trying to solve the problem of "never running out of addresses again", but in my opinion, they went too far in this direction without considering usability as an equal factor.

 

I don't think "usability" really needs to be a factor in that way.  They were likely thinking that things would be automated far more easily than what's actually happened.  As I wrote previously: folks have to get out of the whole "I need to remember these IP addresses" mindset.  Have.  To.  Seriously.  HAVE.  TO.

 

Or you're going to be automated out of a job because you got replaced by a poorly-written python script.

 

[BachChain]

9 hours ago, leadeater said:

I know immediately looking at any IPv4 address what subnet and VLAN it belongs to and which building it is coming from or which security zone in the datacenter.

IPv6 has a dedicated subnet group, so you should only have to memorize a four digit code which can follow a pattern similar to the actual layout. It should actually be easier since you don't also have to keep track of arbitrary CIDR boundaries

[jagdtigger]

10 hours ago, leadeater said:

ha you can't because you're not at your desk

We have a little throw around phrase for this:

"Whoever is stupid should have a notebook"    (notebook=the good old paper version,)

 

It may sound insulting but its meant as an advice. I for one follow it, its better than forgetting something and getting into trouble because of it...

[leadeater]

1 hour ago, jasonvp said:

dead:beef:1234:5678:10:200:5:3 could be an example.  It's a valid IPv6 address on the dead:beef:1234:5678/64.  See the IPv4 address there?

I know, it's the way we do our IPv6 addresses as well, actually mentioned that. But that doesn't mean the other public ones you end up looking at are that easy to remember, it's not that big of an issue because just have it copied and pasted as needed etc. Where you generally lose work efficiency is when you're having to go between different management interfaces, on to difference devices and are switching between the data item you are querying so having to often minimize and maximize that window with the address in it to re-copy it.

 

Nothing world ending, just annoying.

[leadeater]

6 hours ago, dalekphalm said:

Interesting idea - I never considered that. Can you give me a made up example of what an IPv6 would look like under your scheme?

IPv4 - 10.5.248.101

IPv6 - 1234:4321:999:55:10:5:248:101

 

 

IPv4 - 10.5.248.102

IPv6 - 1234:4321:999:55:10:5:248:102

 

 

IPv4 - 10.6.242.23

IPv6 - 1234:4321:999:66:10:6:242:23

[AidenTheBotLol]

IPv6 would be a great move forward for more secure networks but the issue is that do the ISP's want to spend the money to developing and deploying IPv6 to everyone? some ISP's would rather see everyone fight over an IP so that they can get access to the internet.

[Guest]

On 10/29/2019 at 6:40 AM, VegetableStu said:

wonder who would get 255.255.255.255

 

...

 

i'm thinking of it wrong, aren't i ,_,

who got 69.69.69.69 

[vanished]

21 hours ago, floofer said:

who got 69.69.69.69 

CenturyLink in Monroe Louisiana

[Guest]

40 minutes ago, Ryan_Vickers said:

CenturyLink in Monroe Louisiana

well. I was expecting something kinkier, but there you go.

[LAwLz]

On 10/29/2019 at 12:29 PM, jagdtigger said:

Label the machine? We have two printers where i work. One main and one reserve. Main one is labeled as COK and reserve is COKR........  Stop looking for excuses why you cant use it. I also have IPv6 on my LAN. Infrastructure (routers, AP's, NAS's, etc) has fixed IP, everything else is dynamic. For the fixed stuff i have bookmarks and DNS entries for everything connected to the router. Thats about it

If you work with networking you will encounter IP addresses all the time. It's not as simple as just going "use DNS and label it". When you for example need to troubleshoot a connection issue you might need to chart the traffic flow. You can't do that with DNS names because a single machine might have multiple addresses. The configuration files aren't done with DNS names either, it's done with IPs. Firewall rules are generally not done with host names either, because different DNSes might have different IPs for different the same host (for example internal and external DNSes).

 

DNS solves almost all the end user stuff like "how do I add this printer to my computer", but it doesn't solve the headaches network engineers get.

 

 

On 10/29/2019 at 8:16 PM, jasonvp said:

Really, any company with a large global presence and lots of public-facing servers will want to avoid doing any sort of NAT for their high bandwidth services.  NATs suck, through and through.  They're a bitch to troubleshoot, and they're potentially a bandwidth bottleneck.

I don't think there is any issue with doing NAT for high bandwidth services. NAT only has a very small performance penalty, and almost all of that penalty is in the initial connection setup. Once the session is established the translation is done in

Totally agree with that it can cause issues for troubleshooting though.

 

 

 

 

On 10/29/2019 at 9:27 PM, dalekphalm said:

I always wondered why they didn't just use the existing system for IPv4 and expanded it in a logical manner.

Adding another octet or two would mean that we would probably encounter the same issue again in maybe 100 years or so.

IPv6 was designed to be future proof and as a result they really cranked up the number of available addresses.

Also, IPv4 has a lot of tings that needs improving, so they wanted to redesign the entire packet anyway, and at that point why not do it "properly" all the way?

IPv6 addresses are 4 times as large.

192.168.81.61.132.231.241.184.192.128.177.122.188.118.6.1 would have probably have been even harder to remember than the hexadecimal system IPv6 uses.

[jasonvp]

12 minutes ago, LAwLz said:

I don't think there is any issue with doing NAT for high bandwidth services. NAT only has a very small performance penalty, and almost all of that penalty is in the initial connection setup.

Totally agree with that it can cause issues for troubleshooting though.

When you have a large collection of things (eg: public facing servers) trying to egress through a small number of things (NATs), you have a bottleneck.  Simply by definition.  And before you say, "but routers are a small number of things!!!" ... large routers aren't limited to PCI-E bandwidth like a server is.  They can push way more bits/second through them than any server.

 

So yes, there's a bottleneck.

 

[LAwLz]

8 minutes ago, jasonvp said:

When you have a large collection of things (eg: public facing servers) trying to egress through a small number of things (NATs), you have a bottleneck.  Simply by definition.  And before you say, "but routers are a small number of things!!!" ... large routers aren't limited to PCI-E bandwidth like a server is.  They can push way more bits/second through them than any server.

 

So yes, there's a bottleneck.

I don't understand what you mean. Please elaborate.

What do you mean by "NATs being a small number of things"?

 

Also, what do you mean specifically when you say bottleneck? I got a feeling we have different definitions. You said it was a bandwidth bottleneck so I assume you mean that NAT has a negative impact on throughput (as in, how many MB of data you can send and receive each second), which it does, but it's not a big one. Like I said, the biggest impact is in the initial session setup. Once everything is loaded into the firewall's (or whichever devices is doing the NAT) memory it is done very quickly.

[jasonvp]

1 minute ago, LAwLz said:

which it does, but it's not a big one.

We're not talking about the same scales.  I design large-scale data center networks for a living, and that's what I was referring to in my earlier post.  Not little office or small company networks.

[LAwLz]

20 minutes ago, jasonvp said:

We're not talking about the same scales.  I design large-scale data center networks for a living, and that's what I was referring to in my earlier post.  Not little office or small company networks.

Yes... and? You didn't answer any of my questions.

 

What do you mean when you say "NATs is a small number of things"?

What do you mean when you say bottleneck?

 

 

Again, the performance impact of NAT is mostly in the initial session creation (when things are being initialized in memory). Once that is done, the NAT device will save the translation state in memory and do the translation in hardware, really quickly. It has next to no performance impact on throughput.

[jasonvp]

6 minutes ago, LAwLz said:

Yes... and? You didn't answer any of my questions.

 

What do you mean when you say "NATs is a small number of things"?

What do you mean when you say bottleneck?

I'm not sure what you're trying to accomplish here.  I stated my position quite clearly and attempted to clarify it a few times.  If you can't grok what I was saying, then we're talking past one another and there's nothing I can do to fix that.

 

Exercise for you: design a network that has 20 racks of 40 servers each, all with 1x10GigEth uplinks.  Now show me how you'd put a NAT in front of that collection of servers so that they can egress out of that data center.

 

[LAwLz]

13 minutes ago, jasonvp said:

I'm not sure what you're trying to accomplish here.

You said that you want to avoid doing NAT for high bandwidth servers. That it's a bitch to troubleshoot and potentially a bandwidth bottleneck.

I said that I agree that NAT makes things more complex to troubleshoot, but that performance shouldn't be a factor in why you shouldn't do NAT. NAT affects performance very little.

 

13 minutes ago, jasonvp said:

I stated my position quite clearly and attempted to clarify it a few times.

You've made your position clear, but you haven't justified it.

 

13 minutes ago, jasonvp said:

If you can't grok what I was saying, then we're talking past one another and there's nothing I can do to fix that.

Yes there is something you can do. You can start by answering my questions.

 

What do you mean when you say "NATs is a small number of things"? You should be able to implement NAT on all your edge devices.

What do you mean when you say bottleneck? I interpreted your post as saying NAT reduces throughput, but it shouldn't do that in any meaningful capacity.

 

13 minutes ago, jasonvp said:

Exercise for you: design a network that has 20 racks of 40 servers each, all with 1x10GigEth uplinks.  Now show me how you'd put a NAT in front of that collection of servers so that they can egress out of that data center.

Wait a minute... Do you know what NAT is? You refer to it as if it's a device or something. "Put a NAT in front of it".

NAT should be done at the border routers (or firewalls, or some other NAT capable device). A data center with and without NAT will look exactly the same, physically.

[Kilrah]

1 hour ago, LAwLz said:

What do you mean by "NATs being a small number of things"?

The whole point of using the NAT is to be the sole point of transit for a large number of machines so those all go through the same endpoit and use the same address. Hence a bottleneck since all these machines' traffic has to go through that poor NAT.

 

Not to mention the difficulty of routing incoming requests...

[LAwLz]

2 minutes ago, Kilrah said:

The whole point of using the NAT is to be the sole point of transit for a large number of machines so those all go through the same endpoit and use the same address.

1) "The whole point of using NAT" isn't to translate multiple addresses to one address. NAT is used for way more things than that.

2) Not in data centers. There it's not uncommon to do 1:1 NAT.

Even if you do many-to-one NAT (aka, PAT, aka NAT-overload) you're still not limited to just 1 device to do the NAT. You can have 10 routers all doing NAT-overload if you want. All traffic going out from the data center has to pass through some routing capable device anyway, and that device can do NAT.

 

So doing NAT will be no different than not doing NAT. You'll still have a group of devices passing traffic through a single device, unless you got 1 router for each server.

[jasonvp]

23 minutes ago, LAwLz said:

Wait a minute... Do you know what NAT is? You refer to it as if it's a device or something. "Put a NAT in front of it".

NAT should be done at the border routers (or firewalls, or some other NAT capable device). A data center with and without NAT will look exactly the same, physically.

And this is precisely why I said we're not talking about the same scale.  It's clear you're not familiar with large scale data centers.

 

Routers don't NAT at line rate.  They can't.  Therefore, network engineers don't configuring NAT'ing on large routers because it throttles them.

Firewalls don't sit at the border of large scale data centers because firewalls are ALSO a bottleneck.

[Kilrah]

2 minutes ago, LAwLz said:

1) "The whole point of using NAT" isn't to translate multiple addresses to one address. NAT is used for way more things than that.

2) Not in data centers. There it's not uncommon to do 1:1 NAT.

In the context of this discussion which is to reduce the number of public addresses it is what you're looking after, not 1:1.

[LAwLz]

23 minutes ago, jasonvp said:

Routers don't NAT at line rate. 

What crappy routers do you use? Both Arista and Cisco routers can do NAT at line rate. I would be very surprised if for example Juniper or other vendors can't do it either.

In Nexus you can allocate TCAM space to NAT using the "hardware access-list tcam region nat" command.

 

On page 61 in this document you can see that the Cisco ASR 1000 also uses TCAM for NAT.

If you go to page 195 you can also see that the performance of NAT matches CEF perfectly. Wanna know why? Because both are at line rates and done in hardware.

 

Don't you think that ISPs who implement carrier grade NAT want hardware based implementation of it for performance reasons?

 

 

NAT doesn't impact performance in any meaningful way. Again, the initial session creation takes a tiny bit longer, but once the translation is loaded into TCAM it is done at full speed.

 

 

 

20 minutes ago, Kilrah said:

In the context of this discussion which is to reduce the number of public addresses it is what you're looking after, not 1:1.

Oh, sorry. I was just scrolling through the thread and saw someone say NAT shouldn't be used because of throughput issues I went "what? No it doesn't".

Then with each additional response I got more and more confident than the person I was responding to didn't understand what NAT was, because of for example how he referred to it. Especially since a lot of generalized statements has been thrown around when they only really apply to one type of NAT (PAT).

But anyway, I am pretty sure PAT can be done at line rate as well. For example I mentioned Nexus earlier. It can do NAT-Overload and Cisco specifically says that Nexus do not support software translation, and that all translations are done in hardware.

Quote

The Cisco Nexus device does not support the following:

• Software translation. All translations are done in the hardware.

 

[NumLock21]

Was this like mentioned about a year ago that IPv4 is running out.
Oh wait it was also mentioned a year before that.

 

 

[jasonvp]

2 minutes ago, LAwLz said:

What crappy routers do you use? Both Arista and Cisco routers can do NAT at line rate. I would be very surprised if for example Juniper or other vendors can't do it either.

Again I say: it's clear you don't have any actual, hands-on experience with this topic, but you can Google like no one's business.  You came into a discussion half-assed and are trying so desperately to act like the smartest guy in the room.

 

You're not.  Stop trying.

 

I know exactly what Cisco's and Arista's (and Juniper's) documentation says about line rate NAT'ing.  I also know they don't actually achieve it in real world use cases.  Specially when we start talking about 100GigE and 400GigE (or bundles of aforementioned) throughput numbers.

 

And finally, you came in full of piss and vinegar talking about how NATs aren't a performance hit and didn't even realize we were talking about a 4-to-6 NAT.  Not a 4-to-4.  Again with the "half-assed" approach.

 

After you've had a few decades of hands-on design and engineering experience, come back and we'll have this conversation again.  'K?

 

[LAwLz]

38 minutes ago, jasonvp said:

Again I say: it's clear you don't have any actual, hands-on experience with this topic, but you can Google like no one's business.  You came into a discussion half-assed and are trying so desperately to act like the smartest guy in the room.

 

You're not.  Stop trying.

 

I know exactly what Cisco's and Arista's (and Juniper's) documentation says about line rate NAT'ing.  I also know they don't actually achieve it in real world use cases.  Specially when we start talking about 100GigE and 400GigE (or bundles of aforementioned) throughput numbers.

 

And finally, you came in full of piss and vinegar talking about how NATs aren't a performance hit and didn't even realize we were talking about a 4-to-6 NAT.  Not a 4-to-4.  Again with the "half-assed" approach.

 

After you've had a few decades of hands-on design and engineering experience, come back and we'll have this conversation again.  'K?

I don't get why you keep bringing up what you work with or how many years of experience you got.

1) It's not really relevant. At best it's the logical fallacy "argument from authority".

2) This is the Internet. Anyone can say anything they want. I can say I have worked as a professional botanist if I want.

 

Anyway, multiple vendors all say they can do line rate NAT. Modifying headers is also a hardware feature in many controller chips (needed for things like changing TTL fields), and we know that for example Cisco reserves TCAM space for it, and we have benchmarks of a single ASR 1000 doing over 200Gbps of NAT throughput. If an ASR 1000 can do over 200Gbps of NAT throughput, then something like a couple of ASR 9000s should be able to handle all the NAT you can throw at it, even from a massive data center.

 

I think I'll believe those things over some random person on the Internet who says it slow things down without any evidence.

 

 

38 minutes ago, jasonvp said:

And finally, you came in full of piss and vinegar talking about how NATs aren't a performance hit and didn't even realize we were talking about a 4-to-6 NAT.  Not a 4-to-4.  Again with the "half-assed" approach.

Yeah sorry about that. I was talking about IPv4 to IPv4 NAT. Not sure what performance impact IPv4 to IPv6 NAT has.

But what I do know is that if you are designing a data center you will want NAT capability. If you look up any best practice or recommendation for data centers it will say that NAT support is a must.

The only time that might not be necessary is in the extremely rare cases where it's a single company who has a massive data center all to themselves. Like Uber. For anything else, especially in shared environments like AWS and Azure, NAT is a need since you have multiple tenants with overlapping IPs.

 

 

38 minutes ago, jasonvp said:

After you've had a few decades of hands-on design and engineering experience, come back and we'll have this conversation again.  'K?

No