Hello, and welcome back to CS615 System Administration! This is week 5, segment 4, and so far we've covered a fair bit of ground with respect to the IP protocol, having looked at the details of the IPv4 and IPv6 headers, but we have so far avoided the difficult question "Mommy, where do IP addresses come from?" And just why do we have an IPv4 and an IPv6 address, and, wait a second, what happened to IPv5? Alright, let's quickly resolve that last question, because that's easy: there is in fact an IP layer protocol using protocol version 5, the "Internet Stream Protocol", and yes, logically, there also were in fact protocols versions 1, 2, and 3, with version 3 being the first version in which TCP and IP were split. But let's get back to IPv4... --- As we said, an IPv4 address is a 32-bit number, meaning - we can have exactly 2^32 such numbers. 2^32 is a large number, and so the entire IPv4 internet address is space is approximately - 4.3 billion IP addresses. Well, at least that's the theoretical space we have. Now... how do you go about _getting_ one of those? As you may know, many systems come up and seemingly magically acquire an IP address via e.g., DHCP. Where do they get that address from? Let's take Stevens, for example: how did we end up with almost all our IP addresses beginning with 155.246? To answer that, let's take a short trip back in time... --- ...to the early days of the internet, when IP address space management -- and much more -- lay in the hands of just one man, more or less: Jon Postel. Jon Postel was an immensely influential person in the development of the internet, and - initially administered the "Internet Assigned Numbers Authority" (or IANA), meaning when an organization needed to have IP space assigned, he took care of this. He also co-authored a significant number of RFC, including those that became the foundation of the Domain Name System, which we'll revisit in a future video lecture. But obviously having any one person in charge of IP address space allocation is not a scalable solution, and so the administration of IANA was transferred to ICANN. Now, I'm really glossing over an incredibly impressive history of one of the biggest internet pioneers and architects, so I strongly recommend you read up on Jon Postel on your own. You likely have heard of "Postel's Law", also known as the "Robustness Principle" in software programming: "Be liberal in what you accept, and conservative in what you send". This, too, is named after Jon Postel. --- But ok, so we now have IANA, a non-profit standards organization, which oversees global IP address and Autonomous Systems number allocation, root zone management etc. We'll revisit these areas in future videos, but for today we'll stay focused on the management of the IP spaces. --- So IANA is in control of the IPv4 and IPv6 spaces, meaning it can take out large netblocks and assign them to other entities. Now you'll note that I have illustrated the IP spaces as missing certain parts that are not available to IANA to hand out, --- which is because for both IPv4 and IPv6 there are certain netblocks that are reserved for special purposes, such as the RFC1918 private IP space you're all familiar with and it's IPv6 equivalent. Anyway, so of the netblocks that remain available, IANA --- may then assign large chunks to the _regional internet registries_, such as the "African Network Information Centre" or AFRINIC --- the Asia-Pacific Network Information Centre, or APNIC --- the American Registry for Internet Numbers, or ARIN --- the Latin America and Caribbean Network Information Centre or LACNIC --- and the Réseaux IP Européens Network Coordination Centre, or RIPE NCC. --- Each of these RIRs manages the allocations for a specific geographical region, which illustrates the distributed nature of the internet, despite its obvious US origins. By the way, Randall Munroe, the artist behind xkcd, did a neat illustration of the IP space, which I recommend you check out. Anyway, so the RIRs together are loosely organized as the Number Resource Organization or NRO, which helps coordinate internet governance on this level. Now each of the RIRs, having been assigned IP space by IANA, can then --- further divide and assign those netblocks to the so-called Local Internet Registries to use or further allocate. --- Most of these LIRs are internet service providers --- or academic institutions as well as large scale enterprises, as shown here under ARIN. So to answer our earlier question as to how Stevens got its IP space: it was allocated to Stevens by ARIN from a netblock assigned to _it_ by IANA. Now ARIN is, however, a bit of a special case: due to the US-centric management of the internet in the early days, ARIN did receive a large number of historical allocations, which it then - may further allocate to another RIR, such as in the example of the 157.92/16 netblock shown here, which it delegates to LACNIC... --- ...which LACNIC may then further delegate in its entirety to, as shown here, the University of Buenos Aires in Argentina. --- So we see that IP space may actually have geographical properties, and if you've been working with these netblocks for long enough, you may even have memorized some and know that "hey, this traffic connecting to my system comes from Asia", for example. But that can be a bit misleading, since obviously IP addresses do not have a specific physical location inherently bound to it, but rather it's a question for the administrative ownership of the IP space, but that, in turn, can be used to seed the geolocation databases used around the world. Anyway, the LIRs now --- further delegate the netblocks as they see fit, possibly dividing them using netmasks as we discussed in a previous video. For example, we know that - Stevens, having been assigned the 155.246/16 netblock has assigned the 155.246.89/24 netblock to the CS department, and we can observe that Verizon, after having bought Yahoo a few years ago, - became the new owner of the netblock shown here, and specifically assigns several IP addresses to a specific service. We also note that the allocation from IANA at the top down to the end sites often times follows some general rules: --- For IPv4 space, for example, IANA only handles /8 allocations, which it hands to the RIRs. The RIRs tend to divide the /8s into smaller networks and hand out, for example, /16s to the LIRs, which then can divide the networks further, as we just noted. But ok, so now we know where IP addresses come from. But then why do we have IPv6 in addition to IPv4? Well, think about the allocations we just discussed. Our IPv4 space is 32 bits in since because... --- ...well, because that's what Vint Cerf thought would be a reasonable choice for a little experiment to see if this internet thing might take off or not. Turns out, it did, and we've been stuck with this 32-bit IP space ever since. And even though 4.3 billion addresses sounds like a lot, --- it really isn't. For starters, we don't even get the full 2^32 space for use on the internet! - There's certain blocks that are reserved, as I mentioned earlier. The private IP space, for example, - as well as several other netblocks reserved for different purposes. Those together make up approxmiately 13% of the entire IPv4 space! - But not only that -- in the early days of the internet, allocations - were made rather liberally, and so some of the early participants did get entire class A networks assigned -- over 16 million addresses assigned to AT&T, Apple, MIT, etc. - The other problem is that organizations themselves have not been allocating space efficiently themselves, leading to fragmented subnets requiring additional allocations after the fact, and - of course it's not helping that we're now putting lightbulbs and refrigerators and tooth brushes on the internet, each requiring allocations, too. --- So the 2^32 addresses we started out with quickly began to be depleted. - IANA exhausted its pool of unallocated /8 networks just about ten years ago, and the RIRs then - followed quickly, with APNIC in April 2011, - RIPE in 2012 - LACNIC in 2014 - ARIN in 2015 - and AFRINIC in January of last year, meaning we're officially out of IP addresses in the IPv4 space. 4.3 billion addresses pretty much used up, a problem that we all knew for a long time was coming. - Which is why IPv6 was introduced way back in 1995, and why it's so disappointing to see that now, 10 years after IANA ran out of v4 addresses to allocate, we still have organizations and companies that do not support IPv6! But ok, so with IPv6, what are our default allocations? --- The RIRs generally get assigned - a /12, which they then delegate to the LIRs in - chunks down to a /32, which - those, then, may delegate to end sites in chunks of /48s, and final end-user LANs -- the addresses your Wifi AP hands out to you, for example, being, for the - most part, a /64. Now think about that -- most end-users will get a /64. That sounds incredibly wasteful. Sure, you can put all your refrigerators and TVs and lightbulbs and toothbrushes on the /64, but you'll still have so many IPs left over that are basically wasted. Aren't we going to run out of IPv6 addresses in this way? --- To understand why this is not a problem, it's critical to understand just _how large_ the IPv6 space really is. 2^32 is 4.3 billion addresses, which we just realized really isn't all _that much_. Now you're all CS majors, so hopefully you understand better than the average person how exponentiation works, --- but let's illustrate just how many addresses we have available in the IPv6 space. So 2^128 is a number that... looks like this. 39 decimal digits, 340 undecillion, 282 decillion, 366 nonillion, ... a really large number. How large a number is that? Let's see how many IP addresses we can give every person on the planet... ok, that's 4.41 times 10^28 IP addresses *per person*. That's hard to fathom. How many atoms are there in a regular human being? Around 7 time 10^27, so... we could give 6 IP addresses to every atom of every single person on the planet. An internet of atoms! What's another thing that we know there are a lot of? I know: stars! Oooh, so not enough stars in the milky way to really make a dent here. How about the observable universe? Hey, we could give 340 trillion IP addresses to every star in the observable universe! What if every single star in the observable universe had a planet with people like us? Well, then we could give over 44 thousand IP addresses to every person on an earth orbiting every single star in the observable universe. _That_'s how many IP addresses we have. And _that_'s why assigning a /64 to every end user is not going to deplete the IPv6 address pool. Even though... by assigning a /64 or 18 quintillion addresses... we are giving every end user 4.3 billion IPv4 internets. I know, exponentiation is fun, isn't it? Anyway, I hope this little bid here gives you an idea of the size of the IPv6 address space. Play around with it some more -- Wolfram Alpha is a pretty neat engine for this sort of thing. --- Alright, so let's pause here. We've seen how IP addresses are assigned: IANA allocates net blocks to the RIRs, which carve those up and assign them to the LIRs, which then may further delegate or assign them. - Now look around -- can you find out what IP blocks belong to which companies or organizations? - How can you go about finding out what geographical region an IP block is allocated to? Next, to better understand what IPv4 exhaustion means in practice from a RIR's perspective - take a look at the information provided by, say, AFRINIC, and see how many IP addresses they have left to assign. Also think about why it is that AFRINIC is the last one to run out, and what that says about internet proliferation and traffic distribution around the globe. Think about what normally happens when a resource becomes scarce... - Often times, a new market emerges -- can you find out where and how organizations could trade IP space they might not need any longer? All of these questions are intended to get you to think about the internet in "real world" terms, meaning: it is not an abstract thing, but has certain physical properties and implications. - We'll go into some of the details of the physical structure of the internet in our next video. Until then, thanks for watching - cheers!