* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
Download IPv6
Survey
Document related concepts
Wake-on-LAN wikipedia , lookup
Remote Desktop Services wikipedia , lookup
IEEE 802.1aq wikipedia , lookup
Multiprotocol Label Switching wikipedia , lookup
Internet protocol suite wikipedia , lookup
Recursive InterNetwork Architecture (RINA) wikipedia , lookup
Dynamic Host Configuration Protocol wikipedia , lookup
Cracking of wireless networks wikipedia , lookup
SIP extensions for the IP Multimedia Subsystem wikipedia , lookup
Transcript
Internet Protocol version 6 cs423-cotter 1 Outline • • • • Background IPv6 Structure Transition from IPv4 to IPv6 Example IPv6 Client / Server cs423-cotter 2 IPv4 • Developed – 1981 – Internet Size: 200 – 300 hosts • Internet Grew – – – – – – 1985 - about 1000 computers 1990 - about 100,000 – 2,000,000 1995 - about 10,000,000 – 45,000,000 2000 - about 100,000,000 – 400,000,000 2005 - about 325,000,000 – 1,000,000,000 2010 - ? – 2,000,000,000 – 5,000,000,000 The Motivation for Change • Large growth by Asian Carriers • 200 million addresses allocated in first 8 months of 2010 • Many addresses inefficiently allocated • Intermediate sites (~500 – 1000 hosts) require class B address (64k addresses) • Addresses projected to run out (9/2011) • www.potaroo.net/tools/ipv4/index.html • US government required to convert by September 2012 4 The Hourglass Model © 2009 Pearson Education Inc., Upper Saddle River, NJ. All rights reserved. 5 Intermediate Changes • Private IPv4 addresses and NAT – 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16 • Classless Interdomain Routing (CIDR) – Remove the address class limitation • DHCP – Share addresses within a network • Carrier Grade NAT – Use NAT at carrier level. IPv6 Goals • • • • • • • • • Support lots (~billions) of hosts Reduce the size of routing tables Simplify the routing protocol Provide better security Support QoS Improve multi-casting Support host roaming (w/o changing address) Support future protocol expansion / evolution Coexist with IPv4 IPv6 Features • Header Format – very different from IPv4 • Extension Headers • IPv6 encodes information into separate headers • A datagram consists of the base IPv6 header followed by zero or more extension headers, followed by data • Support for Real-Time Traffic • a mechanism exists that allows a sender and receiver to establish a high-quality path and to associate datagrams with that path, intended for audio / video, but can also be used for cost sensitive routing • Extensible Protocol • IPv6 allows a sender to add additional information to a datagram • The extension scheme makes IPv6 more flexible than IPv4 • and means that new features can be added to the design as needed © 2009 Pearson Education Inc., Upper Saddle River, NJ. All rights reserved. 8 IPv6 Datagram Format © 2009 Pearson Education Inc., Upper Saddle River, NJ. All rights reserved. 9 IPv6 Base Header Format • Although it is twice as large as an IPv4 header, the IPv6 base header contains less fields • Figure 24.3 (below) illustrates the format © 2009 Pearson Education Inc., Upper Saddle River, NJ. All rights reserved. 10 IPv6 Base Header Format • VERS ( Version 6) • TRAFFIC CLASS (DS + ECN) • Differentiated services (6 bits) to specify general characteristics that the datagram needs • For example, to send interactive traffic (e.g., keystrokes/mouse), one might specify a class that has low latency • To send real-time audio across the Internet, a sender might request a path with low jitter • Explicit Congestion Notification (2 bits) • PAYLOAD LENGTH • Specifies only the size of the data being carried (i.e., the payload) • Size of the header is excluded © 2009 Pearson Education Inc., Upper Saddle River, NJ. All rights reserved. 11 IPv6 Base Header Format • HOP LIMIT • Corresponds to the IPv4 TIME-TO-LIVE field • Field FLOW LABEL • Intended to associate a datagram with a particular path • NEXT HEADER • Used to specify the type of information that follows the current header • If the datagram includes an extension header • NEXT HEADER field specifies the type of the extension header • If no extension header exists • NEXT HEADER field specifies the type of data being carried in the payload © 2009 Pearson Education Inc., Upper Saddle River, NJ. All rights reserved. 12 IPv6 Flow Label • Flow represents a sequence of packets from one source to one (unicast, anycast, multicast) destination with special handling requriements for the intermediate routers. • Could be a single TCP connection or multiple connections (think FTP) • Special handling conditions must be set up prior to flow commencement • Intermediate Router rules – Routers that do not support flow labeling must set the field to 0 on originating packets and pass the field unchanged for forwarded packets – All packets that share the same flow label must have the same source addr, destination addr, hop-by-hop options and router header options (if used) – Source assigns the flow label. All labels are pseudo-random numbers between 1 and 220 -1. Zero label is reserved for no flow label use. IPv6 Base Header Format © 2009 Pearson Education Inc., Upper Saddle River, NJ. All rights reserved. 14 Implicit and Explicit Header Size • No ambiguity about the interpretation of the NEXT HEADER • the standard specifies a unique value for each possible header • A receiver processes headers sequentially • NEXT HEADER field in each header to determine what follows • Some header types have a fixed size • For example, a base header has a fixed size of exactly 40 octets • Some extension headers do not have a fixed size • the header must contain sufficient information to allow IPv6 to determine where the header ends © 2009 Pearson Education Inc., Upper Saddle River, NJ. All rights reserved. 15 Extension IPv6 Headers • • • • • • Hop-by-Hop Options header (protocol 0) Destination Options header (protocol 60) Routing header (protocol 43) Fragment header (protocol 44) Authentication header (protocol 51) Encapsulating Security Payload header (protocol 50) Multiple Extension Headers • When multiple extension headers are used in an IPv6 packet, their order must be as follows: • Basic IPv6 header • Hop-by-Hop Options • Destination Options (if the Routing header is used) • Routing • Fragment • Authentication • Encapsulating Security Payload • Destination Options • Upper-layer (TCP, UDP, ICMPv6, ...) Fragmentation, Reassembly, and Path MTU • Similarities with IPv4 • a prefix of the original datagram is copied into each fragment • and the payload length is modified to be the length of the fragment • Differences from IPv4 • It does not include fields for fragmentation in the base header • It places the fragment information in a separate fragment extension header • the presence of the header identifies the datagram as a fragment • Fragmentation is managed at the source, NOT at intermediate nodes © 2009 Pearson Education Inc., Upper Saddle River, NJ. All rights reserved. 18 Fragmentation, Reassembly, Path MTU © 2009 Pearson Education Inc., Upper Saddle River, NJ. All rights reserved. 19 IPv6 Address Format • 128 bit colon hexidecimal notation – 8 groups of 16 bits, separated by colons – 2001:0DB8:0000:0000:0000:0000:FF00:0000 • Addresses can be abbreviated – 2001:DB8:0:0:0:0:FF00:0 – 2001:0DB8::FF00:0000 – 2001:DB8::FF00:0 IPv6 Addressing © 2009 Pearson Education Inc., Upper Saddle River, NJ. All rights reserved. 21 IPv6 Address Types Address Type Range Application Aggregatable global unicast 2000::/3 Host-to-Host communications; same as IPv4 unicast Multicast FF00::/8 One-to-many and many-to-many; same as IPv4 multicast Anycast Same as Unicast App. Based (load balancing, optimixing traffic, redundancy) Link-local unicast FE80::/10 Connected-link communications Solicited-node multicast FF02::1:FF00:0/104 Neighbor solicitation IPv6 Address Format • Aggregatable Global Unicast Addresses (2000::/3) Global Prefix Interface ID 48 bits 64 bits 001 16 bit SLA or Subnet ID SLA: Site Local Aggregator Aggregatable Global Unicast Addresses • 2001::/16 • 2002::/16 • 2003::/16 to 3FFD::/16 • 3FFE::/16 IPv6 Internet address 6to4 Transition Mechanism Unassigned 6bone (legacy – dropped 2006) IPv6 Address Format • Link-local Address zeros MAC address FE80:0000:0000:0000:0000: 0050:56C0:0001 • IPv4 Compatible IPv6 Addresses zeros 0000:0000:0000:0000: zeros IPv4 address 134:193:123:234 IPv4 address 0000:0000:0000:0000: 0086:00C1:007B:00EA IPv6 Address Format • Multicast Addresses FFLS :0000:0000:0000: xxxx:xxxx:xxxx:xxxx L: Lifetime (0 = Permanent, 1= Temporary) S: Scope 0001 = Node (Interface) 0010 = Link 0011 = Subnet 0101 = Site (deprecated 1000 = Organization 1110 = Global Anycast Addresses • Use aggregatable global unicast addresses • Can use site-local o rlink-local addresses • Reserved anycast address – Unicast_prefix:0:0:0:0 IPv6 Special Addresses • Loopback address – 0:0:0:0:0:0:0:1 • Reserved request address – 0:0:0:0:0:0:0:0 Solicited-node Multicast Addresses • Used as a replacement for ARP function of identifying MAC addr for IP addr. • Used to test whether a proposed new IPv6 address is already assigned • Format – FF02:0:0:0:0:1:FFxx:xxxx /104 – Where xx:xxxx is least significant 24 bits of IPv6 address. IPv6 Address Autoconfiguration • EUI-64 – globally unique address – Use network prefix – Use globally unique Interface ID • Stateless Autoconfiguration – Locally determined • Stateful Autoconfiguration – DHCPv6 IPv6 Address Autoconfiguration • Extended Unique Identifier - 64 bit – Use Network prefix (typically 48 bits) 2001:0DB8:001F:F123: • Use SLA / subnet mask for 16 bits – Use 48 bit MAC address as seed for 64 bit EUID 2001:0DB8:001F: F123: 0050:56FF:FEC0:0001 • Insert FFFF in the middle of the MAC addr. • Insert FFFE in the middle of an EUI-64 addr. – Preferred - IPv6 Address Autoconfiguration • Stateless Autoconfiguration Objectives: • • • • • No manual configuration required SOHO should not require a stateful server / router Large site should not require an address server Should support gradeful renumbering of sites Router advertisements should support multiple configuration methods Stateless Autoconfiguration Process • Host generates a link-local address for the interface • Send Neighbor Solicitation msgs containing tentative address to verify that the address isn’t being used • If address is not unique, process stops • If address is unique, host has connectivity • Wait for router advertisement from router to determine what kind of autoconfig to use (link-local, site-local, etc). • May send Router Solicitations to the all-routers multicast group to get a faster answer. IPv6 Address Autoconfiguration • Stateful Autoconfiguration – DHCPv6 – Client creates a link-local address – Client communicates with a reserved link-scoped multicast address (FF02::1:2) using UDP – Four message exchange used to acquire initial IPv6 address (solicit, advertise, request, reply) – Two message exchange used to update or renew IPv6 address (solicit, reply) Transition Strategies • • • • • Do Nothing Dual Stack Large Scale NAT (LSN) Dual Stack Lite (DSLite) 6to4 Transition Dual Stack • Best (most long-term) approach • Requires IPv4 Addresses for all sites ISP IPv4 Network Ipv4 channel Host Ipv6 channel IPv6 Network Large Scale NAT (LSN) • AKA Carrier Grade NAT (NAT444) • Utilizes IPv4 address space well • Problems with incoming connections ISP IPv4 NAT Host IPv4 NAT IPv4 Network Endpoint Independent Mapping • NAT (NAPT) must always translates a given source address into the same outgoing address, independent of the destination. S: 192.168.10.25:80 D: 123.234.45.56:789 192.168.10.25 S: 192.168.10.25:80 D: 134.193.12.34:678 S: 72.56.99.125:123 D: 123.234.45.56:789 123.234.45.56 72.56.99.125 S: 72.56.99.125:123 D: 123.234.45.56:789 134.193.12.34 Client / Server with IPv6 • New Functions, structures, constants – inet_pton( ) - instead of inet_addr( ) – inet_ntop( ) – instead of inet_ntoa( ) – struct sockaddr_in6 addr – AF_INET6, PF_INET6 cs423-cotter 39 Server6.cpp (TCP echo server) #include <iostream>, <stdio.h>, <resolv.h>, etc. #define BUFSIZE 100 using namespace std; void error(char* msg, ...) { va_list ap; va_start(ap, msg); vprintf(msg, ap); va_end(ap); exit (1); }cs423-cotter 40 Server6.cpp (TCP echo server) int main(int count, char *argv[]) { int sd, portnum; struct sockaddr_in6 addr; int sent, size=sizeof(addr); int client; char buf[BUFSIZE]; if ( count == 2 ) portnum = atoi(argv[1]); else portnum = 1234; bzero(&addr, sizeof(addr)); cs423-cotter 41 Server6.cpp (TCP echo server) if ( (sd = socket(PF_INET6, SOCK_STREAM, 0)) < 0 ) error("Socket failed. "); addr.sin6_family = AF_INET6; addr.sin6_port = htons(portnum); if ( inet_pton(AF_INET6, "0::0", &addr.sin6_addr) == 0 ) error("Inet_pton failed "); if ( bind(sd, (struct sockaddr *) &addr, sizeof(addr)) != 0 ) error("Bind6 failed "); if ( listen(sd, 5) != 0 ) error("Connect failed. "); cs423-cotter 42 Server6.cpp (TCP echo server) while (1) { client = accept(sd, (struct sockaddr *) &addr, (socklen_t *) &size); cerr << "Connected to " << inet_ntop(AF_INET6, &addr.sin6_addr, buf, BUFSIZE); cerr << " port = " << ntohs(addr.sin6_port) << endl; do { recv (client, buf, BUFSIZE, 0); sent = send(client, buf,strlen(buf) , 0); cerr << "Server received: " << buf << endl; } while ( sent > 0 && strcmp(buf, "quit") != 0 ); close(client); } } cs423-cotter 43 client6.cpp (TCP echo client) #include <iostream>, <stdio.h>, <resolv.h>, etc. #define BUFSIZE 100 using namespace std; void error(char* msg, ...) { va_list ap; va_start(ap, msg); vprintf(msg, ap); va_end(ap); exit (1); } cs423-cotter 44 client6.cpp (TCP echo client) int main(int count, char *argv[]) { int sock, portnum; struct sockaddr_in6 addr; char buf[BUFSIZE]; if ( count == 3 ) portnum = atoi(argv[2]); else portnum = 1234; memset (&addr, 0, sizeof(addr)); if ( (sock = socket(PF_INET6, SOCK_STREAM, 0)) < 0 ) error("Socket failed. "); addr.sin6_family = AF_INET6; addr.sin6_port = htons(portnum); cs423-cotter 45 client6.cpp (TCP echo client) if ( inet_pton(AF_INET6, argv[1], &addr.sin6_addr) == 0 ) error("Inet_pton failed "); if ( connect(sock, (struct sockaddr *) &addr, sizeof(addr)) != 0 ) error("Connect failed. "); do { memset (buf, 0, BUFSIZE); cin.getline(buf, BUFSIZE -1); send(sock, buf, strlen(buf)+1, 0); memset (buf, 0, BUFSIZE); recv(sock, buf, sizeof(buf), 0); cout << " Reply = " << buf << endl; } while ( strcmp(buf, "quit") != 0 ); close(sock); return 0; }cs423-cotter 46 Example: Client Side - Windows C:\data\cs423_fs12\examples\IPv6\ipv6_client\Debug>ipv6_client.exe 2610:e0:a040:cdfd:210:4bff:fe2b:22c2 23456 We are using port 1377 This is a test Reply = This is a test This is only a test Reply = This is only a test If this was useful, it would say something Reply = If this was useful, it would say something quit Reply = quit C:\data\cs423_fs12\examples\IPv6\ipv6_client\Debug> cs423-cotter 47 Example: Server Side - Linux [rcotter@kc-sce-450p2 IPv6]$ ./server6_v2 23456 Connected to 2610:e0:a040:cdfd:e46d:ebb2:2057:d582 port = 1377 Server received: This is a test Server received: This is only a test Server received: If this was useful, it would say something Server received: quit ^C [rcotter@kc-sce-450p2 IPv6]$ cs423-cotter 48 References • • • • • • • • • RFC 2460 – IPv6 Specification RFC 2462 – IPv6 Stateless Address Autoconfig RFC 3056 - Connection of IPv6 Domains via IPv4 Clouds RFC3315 – DHCPv6 RFC 4443 – ICMP v6 RFC 4861 – Neighbor Discovery Protocol RFC 2553 – Basic Socket Interface Extensions for IPv6 Computer Networks and Internets – 5ed – Comer, Prentice Hall, 2009 CCIE Routing and Switching Certification Guide 4ed – Odom, Healy, Donohue – Cisco Press, 2010 • Computer Networks 5ed – Tanenbaum, Wetherall – Prentice hall, 2011 • Data and Computer Communications 9ed – Stallings – Prentice Hall, 2011 cs423-cotter 49 Summary • IPv6 Needed SOON! Deployment much slower than expected. • IPv6 very different from IPv4 – Much more flexible – More secure – Less overhead for routers • Interworking with IPv4 will be needed for a long time. cs423-cotter 50