IPv4 vs IPv6 in AWS


Amazon Web Services (AWS) are based on Elastic Computer (EC2)  instances, with additional features added to each instance as the users of the cloud services choose.
First, an EC2 instance is usually a virtual machine provided with an operating system, which is some version of Linux or Windows. For an extra fee, the user may select one or more physical machines provided by Amazon.
Each instance has a variety of addresses, but the ones we will focus on in this section are the various possible IP addresses of each instance.

The questions we intend to address in this section revolve around the issues of what gates can be put around each instance using IP and TCP protocols, so we will start by taking a look into IP address ranges.

This aspect of AWS is called the Virtual Private Cloud (VPC).
EVERY instance is part of some VPC.
Without explicit choices made as an instance is being created, that instance would become a part of the default VPC for the AWS user.
DEFAULT VPC - among other things, this VPC will not support IPv6 - which means that if you want to use IPv6 features, you will have to explicitly create a new VPC (before you create the instances that will use it), and use it when creating new EC2 instances.

IP addresses naturally form hierarchical groups, called subnets, and communications between and among instances and the outside world using packets can be filtered using routing tables and Network Address Translators (NAT's), so eventually we will explain how the features of AWS VPC's can be used to set up subnets, routing tables and security groups to filter traffic among them.

Natrually, you will need to create multiple instances to explore just how VPC's work in AWS, but:
CAUTION: once a subnet with certain characteristics has been assigned to an instance, it can be very hard to nearly impossible to change some of the selections.
THUS: one really wants to map out a connection hierarchy (ie, subnets) BEFORE one goes about instantiating EC2 instances and moving work to the cloud.

Note that in addition to the IPv4 and IPv6 addresses, each instance may be given a public DNS address, but those tend to be as long or even longer than the IP address, so one may easily find that they are not really all that interesting.

IPv4 addressing ranges

  • 32 bits per address, which means that the entire system only supports 232 which is about 4 Billion (4B) addresses.
    • This is not even enough for one address per person in world, much less all the computers, and even harder to get an internet of things (IoT) addresses to work.
    • In addition, the addressses are controlled in a hierarchical manner, with various organization given ranges, and those ranges can in turn be subranged to clients of those organizations.
    • And some specific ranges have been designated as "non-routing", meaning that one can use those addresses in a LAN (local area network), but they cannot leave the network through a router connected to the internet.
    • Other address ranges are unique throughout the internet, and are used by IP routers to send packets to their destination routers or public hosts, that is, network devices that have addresses that are guaranteed to be unique in the internet.
  • Devices on LAN's can talk through the internet to other devices by using network address translators (NAT's).
  • - 4 decimal numbers, separated by dots, and each entry < 256 (0-255).
  • NOTATION for address ranges - this depends on specifying the number of BITS in the prefix part of a 32-bit IPv4 address. For example:
    • - the leftmost 24 bits are a network prefix, representing addresses in the range: through
      or in binary:
      0111 1011 . 0011 1000 . 1011 0010 . 0000 0000 through
      0111 1011 . 0011 1000 . 1011 0010 . 1111 1111 .
    • CIDR - Classless Inter-Domain Routing, the notation used to specify address ranges, or, in other words, subnets.

AWS IPv4 addressing

  • EC2 instances will have local IPv4 addresses, typically starting with the non-routing address, meaning the first 8 bits of the 32 bit address will be 0000 1010 binary or 10 base 10. All other addresses will be assigned as each EC2 instance is created.
    • These devices are automatically on the same subnet, but the user can change the subnet configurations using routers, isolating groups of devices into the various subnets by address range.
  • An EC2 instance may have a routing IPv4 address as well.
    • The user may pay for a permanent IPv4 address, since they are a scarce and valuable commodity. AWS calls these fixed public IP addressess - "Elastic IP addresses".
    • (Free!) Or, if configured, the EC2 environment will assign a (kind of) random IPv4 address to a running instance of the EC2 instance, but release that address each time the instance runs.

IPv6 addressing

  • This is a lot of bits, 128, meaning that the potential address space is rather large.
  • Thus, there is room for unique IPv6 addresses for IoT.
  • The user may configure routers and subnets to limit the exposure of various address ranges, as desired.
  • Try:
    • whois 2607:f8b0::
  • http or https example addressing:
    • http://[2600:1f18:773:e300:f196:4444:f557:3290]:8080
  • Address ranges - the notation for IPv6 addresses is similar to IPv4, with the additional feature that fields of all 0's can be replaced with ::.
    • Each hex digit takes 4 bits, each field of 4 hex digits takes 16 bits.
    • For example:
      2600:1f18:773::/48 - the first 48 bits define this address range
    • 2600 takes 16 bits
    • 1f18 is another 16 bits
    • 0773 is another 16 bits
    • This leaves 128 - 48 = 80 bits, or 5 fields of 16 bits each, free for subnets and individual instances.

AWS IPv6 addressing

Python IPv4 and IPv6 addressing - AFTER an IPv6 Cloud9 environment has been created:

Be sure to open the TCP port 8080 for this example to work.

You can run this example in a Cloud9 environment.
Include the Flask module using the following command at the shell level:

> sudo pip install flask

# file: flask016.py
# date: Aug 22, 2020
# purpose: IPv4 vs IPv6 testing

import time

# File: flask010.py
from flask import Flask
app = Flask (__name__)

@app.route ("/")
def reply () :
  str = "\nThis is a simple web page - 016 \n"
  str += "\nProfessor Nicholas Duchon \n"
  str += time.asctime(time.localtime(time.time()))
  str += "\n\n"
  return str

if __name__ == "__main__":
  # the following will respond to both IPv4 and IPv6 addresses
  # as configured by the EC2/Cloud9 environment
  app.run (host="::", port=8080)


Create a set of EC2 instances that implement a VPC net/subnet hierarchy - something like the following:
  1. Before your start, specify the instances and specify to which subnet each instance should belong.
  2. At a minimum, your example should have:
    1. 10 EC2 instances
    2. 4 subnets
    3. Use IPv6
    4. At least one instance should be Cloud9 implementing the Flask example above
    5. The Flask example should be viewable from an internet browser
  3. Implement your hierarchy in AWS, using IPv6 addressing.
    1. Create the CIDR's you will require for each subnet using the VPC Management Console
      if you don't find the VPC link in Recently visited services, look down the page until you find the VPC link.
    2. VPC Management Console - this is an EXCEPTIONALLY informative and powerful page.
      Begin using the Launch VPC Wizard - among other things, the wizard will automatically create reasonable routing tables and security groups
    3. VPC nets and subnets displays:
      Note the address ranges in the VPC's and subnets!

    4. DO Give items memorable names - the default names are automatically generated, but are hardly memorable when putting the system together.
    5. Adjust the security group settings to match the example you defined in Step 2.
    6. You might want to update your example as you work with these selections.
    7. Create and configure your instances using:
      EC2 console --> Launch Instance --> Next: Configure Instance Details -->
      Configure Instance and Review
  4. Demonstrate that you have correctly implemented the hierarchy by documenting the specifications of each instance, the subnets, and the routing tables used.