Brief history IPv6 part I Section 4.3.5 in the textbook • Used to be IPng (“IP next generation”) • Discussion started getting serious in the early 1990s • People want to fix the problems with IPv4, especially address allocation! Why not IPv5? • In 1979, an experimental network protocol What’s wrong with IPv4 • Address allocation is the biggest problem was devised to handle virtual circuit type stuff over Internet infrastructure • • It was, at the time, assigned version “5” • No one uses it • The more recent VC stuff we’ve talked Not enough addresses • • Allocated poorly about (e.g., ATM) does it better • Hard to route Routers actually have unnecessary work to do IPv4 IPv6 IPv4 IPv6 32 bits 128 bits 32 bits 128 bits ~4 billion ~3!1038 ~4 billion ~3!1038 1 per human adult 1 quadrillion per millisecond per human during their life 1 per human adult 1 quadrillion per millisecond per human during their life IPv4 IPv6 IPv4 IPv6 Address size 32 bits 128 bits Address size 32 bits 128 bits Address space ~4 billion ~3!1038 Address space ~4 billion ~3!1038 1 per human adult 1 quadrillion per millisecond per human during their life Enough addresses for... 1 per human adult 1 quadrillion per millisecond per human during their life First things first • IPv6 addresses are written in hexadecimal • Separated by colons instead of dots • Grouped by double-bytes instead of bytes • Leading zeroes are omitted • Groups of zeroes are omitted (only once) Address size First things first • 2004:0700:0000:0000:0002:1e3a:980e:6400 • written as 2004:700::2:1e3a:980e:6400 • We still use CIDR notation for blocks of addresses • E.g., 2004:700::/16 IPv6 addresses • Each address starts with a “format prefix” • 0000 0000::/8 is “special addresses” • 1111 1110 10::/10 is “link local” • 1111 1110 11::/10 is “site local” • 1111 1111::/8 is multicast • 001::/3 is global unicast • Everything else is reserved right now IPv6 view of things X X X X X X IPv6 view of things X X X X X X X IPv6 view of things X X X IPv6 view of things X X X IPv6 view of things X X X X X X Unicast addresses • 48-bit “prefix” • 16-bit “subnet ID” • 64-bit “interface ID” • The last 64 bits should actually be globally unique! Woah! • Why do we need the first 64 bits then? Building an interface ID Building an interface ID • Ethernet is the easiest • Take your 48-bit MAC address • E.g., 00-19-e3-43-41-74 • The first 3 octets are a “organizational unique ID” (or “company ID”). Insert ff fe after those • E.g., 00-19-e3-ff-fe-43-41-74 Now what? • What if we’re not using Ethernet? • • • If an IEEE global identifier (EUI-48 or EUI-64) is available anywhere on the node, it should be used to construct the tentative Interface-Identifier due to its uniqueness properties. If an IEEE global identifier is not available a different source of uniqueness should be used. Suggested sources of uniqueness include link-layer addresses, machine serial numbers, et cetera. If a good source of uniqueness cannot be found, it is recommended that a random number be generated. • The interface ID gives us a unique address at the link level at least (theoretically a globally unique address as well) and hence also the node level • IPv6 allows us to make up our “link local address”. Cool! • In the last 2 cases, bit 7 must be set to 0 Acquiring more addresses Be gone, DHCP! • Using the example before, our interface ID is • IPv6 allows you to acquire a global unicast • 1111 1110 10::/10 is a link local prefix • Mash the two together to get • Why would we want to do this? • DHCP requires state (lease times, 00-19-e3-ff-fe-43-41-74 fe80::19:e3ff:fe43:4174 to get our IPv6 address • This actually a valid address! • We only exist at the link level (or site level if we use fe81 instead of fe80) address without any DHCP server mappings between link layer and network layer) • State requires complex routers/servers Be gone, DHCP! Solicited node address • Before we can get our global unicast • What if someone wants to send something address, we need to use our third address that we get by magic, the solicited node address • IPv6 removes the need for ARP (mapping between MAC address and IP address) at every level of routing! Towards multicasting • ff02::1:ff43:4174 is a multicast address! • How do we (or how does a router know)? 1111 1111::/8 (everything starting with ff) is multicast • Multicast addresses are very particularly formatted in IPv6 Solicited node • ff02::1: ff43:4174 — we know it’s a pre-defined multicast group at the link level • The “1” by its lonesome tells us this is a “solicited node” multicast group • The router will send this to the (unique!) host with interface ID ending in 43:7174 • Link level addressing at the network layer! to us at the link layer? • Take the last three octets of your link local address (fe80::19:e3ff:fe43:4174 becomes 43:4174) • Append ff02:0:0:0:0:1:ff00:: to get ff02::1:ff43:4174) Anatomy of a multicast address • 8-bit Format Prefix (“ff”) • 4-bit flags (right now, 0 = pre-defined, 1 = “transient”) • 4-bit scope identifier (1 is node, 2 is link, 5 is site, e is global) • 112-bit multicast group identifier • ff02 tells us “pre-defined group at the link level” Solicited node and trust • How do we know there’s only one host on our network with that ID? A little trust is needed • When we come on the network, we do a “uniqueness” test • After we generate our link level IPv6 address, we use the Neighbour Discovery (ND) protocol over ICMPv6 to determine if someone with that address is already on the network Getting our global unicast address • Once we know we’re unique, we find our router Getting our global unicast address • The subnet ID is a /64 which is common to the entire network • We also use ND over ICMPv6 here • Piecing together the subnet ID and the feels like it (in practice everyone does. Why?) • The router isn’t required to remember • Our router can implement DHCPv6 if it • Or! It can just tell us the subnet ID! More on multicast • ff02::1:ffxx:xxxx is one “pre-defined” multicast group we’ve seen already • ff01::/8 is really boring. ff02::/8 is a subset of ff03::/8 below • ff03::1 is every host; ff03::2 is every router ff03::fb is an experiment called mDNS (multilink DNS) What about not predefined multicast? • The “temporary” multicast group can be set to 1 • E.g., ff15::3 is a multicast group #3 at the site level • What’s it for? Who knows • Same problems we already discussed with multicast. You need something out of band to assign meaning to this multicast groups and who’s in them and who’s not interface ID will give us a complete 128-bit address anything (i.e., state) beyond its own subnet ID Variable-scope predefined multilink groups • “Variable-scope” in that any 4-bit scope is valid (e.g., ff0x::fb is valid for any 4-bit scope) • ff0x::101 is NTP • ff0x::118 is Microsoft Directory Service • ff0x::12b is X Display Anycasting • Anycasting is weird • No one really uses it currently • An anycast address looks exactly like a unicast address • Uh oh. This is trouble for the router Anycasting Anycasting • Idea: someone wants to connect to your • Currently load balancing is done primarily webserver, they connect to an anycast address at the DNS level • Looking up “microsoft.com” well give you • Your router will redirect the packet to any one of many hosts that are assigned to that anycast group a different IP every time you look it up • Doesn’t this already exist? Load balancing? • Each IP still takes you to a particular host • Easy to DoS a host Special addresses A router’s life • ::/128 — “unspecified address”, must never be used for any host • • ::ffff:0:0/96 — IPv4 address space (more on • No more checksumming at the network level ::1/128 — loopback (127.x.x.x) this later!) • No more fragmenting at the network level (sort of!) • fc00::/7 — unique local address, used for things which aren’t actually on the Internet Checksumming • IPv4 had a checksum field • IPv6 does not • IPv4 checksum almost never caught any errors • The TCP checksum catches what the IP checksum does • Error detection is done at the link level anyay! Checksumming in IPv4 • A calculates link layer checksum • • A sends frame to B • B verifies network layer checksum B verifies link layer checksum • B decrements TTL and regenerates the network layer checksum • B calculates link layer checksum and the process starts again Checksumming in IPv6 • A calculates link layer checksum • • A sends frame to B • B calculates link layer checksum and the process starts again B verifies link layer checksum ICMPv6 • ICMPv6 is much like ICMP, but there is one important new error message: “Packet too big” • A host now has two choices • Keep packets to 1280 bytes • Ask the network the maximum packet Fragmentation • Routers in IPv6 are now prohibited from fragmenting or assembling packets • This makes life easy (for the router) • Two problems: • What if a router gets a packet that’s too big? • How do we make sure our packets aren’t too big? Binary search! let min = 1280 bytes let max = 50 gajillion bytes while max - min ! threshhold let len = (max + min) / 2 send packet of length len case response of Packet Too Large: max := len Success!: min := len size “50 gajillion”? • IPv6 (like IPv4) has a 16-bit length field • Certainly we can’t send a packet larger than 65535 bytes! • There’s a standard (optional on routers) for “jumbograms” • Set the 16-bit length to 0 and you can supply a 32-bit length • Routers are only required to handle up to 1280 QoS in IPv6 • IPv4 had the concept of “priority” in its packets • 8 bits. 3 gave a “precedence” value and 4 gave hints for maximizing/minimizing delay, throughput, reliability and monetary cost, respectively • These aren’t used very often QoS in IPv6 • IPv6 keeps the 8-bit priority field and adds a 20-bit “flow control” field • Idea: pay in advance (or set up some payper-use system) where you can pay for packets to get guaranteed latency, guaranteed bandwidth, etc. From Wikipedia IPv6 Header (Cont) Priority: identify priority among datagrams in flow Flow Label: identify datagrams in same “flow.” (concept of“flow” not well defined). Next header: identify upper layer protocol for data CS357b 64