IP addresses.... hmmmm
Very difficult to give a "definitive, and concise" pointer on this...
I'll start by being a bit controversial:
"IP addresses are perhaps the LEAST interesting thing about networking in my opinion... OK maybe a very close second to MAC addresses"
A large number of people waste pointless hours getting into messes with IP addresses because they can't just leave them alone.
There is a large amount of largely correct information here... for the definitive rundown on IP addresses (if you are really that interested) asking a good source of training such as www.commsupport.co.uk
(who are providing free webinar training) will give you all the information you never wanted to know.
Why the lack of enthusiasm?
IPV4 addresses... the www.xxx.yyy.zzz
type addresses we are used to seeing have been seriously messed around with since they were first thought up. Nobody predicted that everyone on the planet would need several IP addresses, so the address range wasn't built to a large enough scale. That was the first problem....
Well the global communications system hasn't ground to a halt - this is largely because a lot of IPV4 got revised and re-functioned... the truth is that 2^32 is actually a reasonably respectable number... its about 4.3 billion- ok there are more people on earth than that... well using an IP address to describe the address of a group of machines solved that... and the sockets layer was already there for application handling... so no problem.
The problem was that IPv4 was "shared out" in an inefficient way (20/20 hindsight... its not like these were unintelligent people doing it) Actually as soon as the problem was realised two proposals happened... IPv4 got re-functioned a bit (which immediately addressed the issue) and IPv6 was born.
IPv6 was nice because of historical context... IPV4 was born when fixed line phones were around - IPv6 by contrast had huge contributions from (inter alia) Nokia and Cisco. Mobile phones work differently to fixed line phones... so it is more a technology of its era. Someone alluded to what is known as IPv6 global addressing... this is where a device has a global public address... not a bad idea... but that changed a bit last year. There was concern about device security... so now IPv6 devices can have a global address and a private address (anyone getting deja vu?) OK so its not a big problem - IPv6 has such a big address pool - 128 bits instead of 32 bits... that we will never run out of addresses... so cutting that pool in half immediately isn't a big deal... and "640K should be enough for anyone". I of course say this partly in jest
I'll explain with an example - IPv4 of course (IPv6 is great... but not human readable)
I have a bunch of devices in the network I am working in... counting up now... there are about 30 devices... there are multiple interfaces on most of them... so there are about 150 ports in this subnet. I'll be honest- I only know (or care) about the IP addresses on four devices (and even then I should only really care about two of them).
I know the IP addresses of my routers (Cisco enterprise boxes) and the IP addresses of two switches (the ones that the serial port is physically difficult to get at... IE I have to get out of my chair).
I need to know the IP addresses of my routers... because one is connected to the Local rack room directly, and the other is connected to another building across town for redundancy of Internet connection- both via Ethernet.
Naturally the backup route is in a different network to the main route, so those two routers have to be able to send traffic to and from each other, and load balance.
I am DHCP serving addresses to everything in the subnet that has the devices connected...
Every Dante device will obtain a DHCP address if there is a DHCP server present by Default - correctly identifying 169.254.xxx.yyy as APIPA (we prefer the term link-local) is- just like Windows, OSX and most Linux distributions- as in if there is no DHCP server present we fall back to this addressing method. Please Please Please do not statically assign APIPA range addresses... It "shouldn't" matter as most popular APIPA/Link Local mechanisms can deal with this (ours included)... but it is "non-standard practise" to do so.
So I care about the IP address of my router- so that I can configure the DHCP server I am running on it, and configure the routes to the other networks. Naturally My enterprise network has public IP addresses, and I may choose to function these as entire other networks or single devices...
To put it another way... I don't know the IP address of the server that handled my last google search - it is probably not of any immediate concern to google either (I hope)... they could probably find out if they really really wanted to.
What I did was I typed www.google.com
into my browser, and then searched... DNS resolved the IP address for me, and I assume the google data-centre handled the assignment of which machine the request went to through their load-balancing algorithms.
Dante Devices (and an increasing number of other devices too) use MDNS - which means that you can talk to a device by typing its name .local into your browser... or ping using the name rather than the IP address... Even my newer Cisco switches do this, and I have worked on installations where the IT department use MDNS names to communicate with switches... much easier to remeber westgate.local than a bunch of numbers.
This mode of working is going to become the norm... as IPv6 addresses (at 128 bits long) are impossible to remember!
There was a time... once upon a time, where software implementations cared about IP addresses... this was largely solved with "updates" to certain operating systems...
Now if I write a software application that uses a network port- some nice open-source code and the operating system device driver take care of it for me...
The IP addresses you need to know are:
The public IP address of your network (if you are manually configuring an enterprise network)
And then the IP address range you are telling your DHCP server to dish out - suggest choosing a private IP address range (the router will keep those devices "invisible" to the outside world).
OK so there are some software applications that "force" you to use static IP addresses. This is nothing to do with the network being any different.
The "gentle" path is probably to describe how I set up my own web domain.
I purchased a domain name from a domain registration service... but I want to use a different hosting service (located at a different place) to actually hold the information for say my email and web services.
Lets think about what happens when I type the web address www.mydomain.com
into a browser...
The first thing that happens is that the browser application asks something called the DNS what IP address www.mydomain.com
is at (I am unaware as to whether this is IPV6 or IPv4 from an end user perspective... if my browser, and infrastructure support IPv6, then it might be IPv6... the application will deal with all of this for me. Because I "purchased" the domain from a registration company - they hold the DNS record for my domain... its a big database. If I edit the DNS record here - for example I can "point" ftp.mydomain.com direct to a hard drive on my desk in my office if I know how to set up a public IP address for that hard drive. I can point www at a server of my choosing elsewhere.
If I change the DNS record, then this change will take a few hours to copy itself across the web of DNS servers globally (it doesn't work so well if all the computers in the world make requests to the same machine...)
Once my application knows the IP address of the "other end" it can communicate with the other device.
MDNS (sometimes known as Bonjour) does this in microcosm. That is after all how you can find printers so easily when connected to a network... there is a nice record of that network printer sitting in the MDNS domain waiting for your Bonjour client (inside your operating system) to browse for it.
Using MDNS- we can "discover" what is out there... and some other information about it. Once we "know" that something is there... and that this "something" is of interest to our application (from its description), then we can display it seemingly automatically to the user.
Of course we don't have to use MDNS to do this... we could make up our own parallel method- MDNS is one open-source technique to do this.
The important aspect to note here is that I am using names... not IP addresses. Just like on the big bad internet- If I get angry with my hosting company (which I have done before... mainly due to charges) I can move elsewhere very quickly... I go back to DNS, and I simply change the IP address or master domain of my new host in the DNS record... a few hours later, and its as if the old host never existed... but users will not notice... they will still type www.mydomain.com
and get the same content (as long as I copied it correctly). In the same way...
Dante uses a naming scheme for channels that looks like firstname.lastname@example.org
If I name a new piece of equipment stageleft and call a channel on that piece of equipment kickdrum, the Dante network will not be able to tell any difference. The IP address (which we don't care about) may be different, and the MAC address will also be different (we care even less about this), but if I put this identically named device into the network, after removing the "original" the system will pick up the information from the new device as if it were the "original".
I could go further and of course use other metrics to stop this happening... if that was a needed feature... but I would still not use the IP address to achieve this.
This is why some devices have the "identify" LED on them... Out of the factory a device will be called <sometext>nnnnnn which will uniquely identify it. Not a very snappy name- granted. but there are ways to change this name and if the name is changed according to a template, then pre-configuration is achievable in software without having to blindly target IP addresses.
In fact it is possible to push complex information to a device in a very easy way... think...
OK so I have a new device with uncool name
- i'll change the name,
- my application knows it has information for that device name
- ah yes there it is
- send message to device named my_new_toy
- IP address is known- all automatically handled
In terms of actual sending of data there is no big difference in sending the data- instead of targeting an IP address, you target a name (that resolves to an IP address)
Some have argued "what if the name resolution breaks?"
The IP address is resolved to the MAC address don't forget... What if ARP breaks?
The advantage with the name approach is that there is a concept of automatic discovery. IP address based software tends to either rely upon a entering numbers in each endpoint locally, or doing a ping of every address in a subnet to find out what is there, and then populating a table much like a quasi DNS record in any case.
This is a complex subject, and I have not done it justice here... please post questions/comments for discussion