Question? Leave a message!




IP Next Generation (IPv6)

IP Next Generation (IPv6) 27
IP Next Generation (IPv6) Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 1Overview  Limitations of current Internet Protocol (IP)  How many addresses do we need  IPv6 Addressing  IPv6 header format  IPv6 features: routing flexibility, plugnplay, multicast support, flows Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 2PreIP: Translation, ALGs ALG ALG ALG ALG  applicationlayer gateways  inevitable loss of some semantics  difficult to deploy new internetwide applications  hard to diagnose and remedy endtoend problems  stateful gateways= hard to route around failures  no global addressability  adhoc, applicationspecific solutions Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 3The IP Solution … IP IP IP IP  internetlayer gateways global addresses  simple, applicationindependent, lowest denominator network service: besteffort datagrams  stateless gateways could easily route around failures  with applicationspecific knowledge out of gateways:  NSPs no longer had monopoly on new services  Internet: a platform for rapid, competitive innovation Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 4The Internet Today: with NATs NATALG NATALG NATALG IP  network address translators and applayer gateways  inevitable loss of some semantics  hard to diagnose and remedy endtoend problems  stateful gateways inhibit dynamic routing around failures  no global addressability = brokered with NATs  new Internet devices more numerous, and may not be adequately handled by NATs (e.g., mobile nodes) Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 5Address Shortage Causes More NAT Deployment 10000 1000 100 10 1 S M S M S M S M S M S M S M S M S M S M S M S M S M 96 97 97 98 98 99 99 00 00 01 01 02 02 03 03 04 04 05 05 06 06 07 07 08 08 09 Address exhaustion date estimate varies from 20092019 Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 6IPv4 Addresses  Example: 164.107.134.5 = 1010 0100 : 0110 1011 : 1000 0110 : 0000 0101 = A4:6B:86:05 (32 bits) 32  Maximum number of address = 2 = 4 Billion  Class A Networks: 15 Million nodes  Class B Networks: 64,000 nodes or less  Class C Networks: 250 nodes or less  Class B very popular…  Total allocated address space as seen by routing: 1Billion Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 7How Many Addresses  10 Billion people by 2020  Each person has more than one computer 12  Assuming 100 computers per person  10 computers  More addresses may be required since Multiple interfaces per node Multiple addresses per interface 6 8 Some believe 2 to 2 addresses per host 15  Safety margin  10 addresses 12 9  IPng Requirements  10 end systems and 10 12 15 networks. Desirable 10 to 10 networks Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 8How big an address space  H Ratio = log ( of objects)/available bits 10 n  2 objects with n bits: HRatio = log 2 = 0.30103 10 7  French telephone moved from 8 to 9 digits at 10 households  H = 0.26 (3.3 bits/digit) 8  US telephone expanded area codes with 10 subscribers  H = 0.24  Physics/space science net stopped at 15000 nodes using 16bit addresses  H = 0.26  3 Million Internet hosts currently using 32bit addresses  H = 0.20  Huitema (Nov 01) estimates H = 0.26 next year Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 9IPv6 Addresses  128bit long. Fixed size 128 38  2 = 3.4×10 addresses 21  665×10 addresses per sq. m of earth surface 6  If assigned at the rate of 10 /s, it would take 20 years 17 33  Expected to support 8×10 to 2×10 addresses 17 8×10 1,564 address per sq. m  Allows multiple interfaces per host.  Allows multiple addresses per interface  Allows unicast, multicast, anycast  Allows provider based, sitelocal, linklocal  85 of the space is unassigned Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 10ColonHex Notation  DotDecimal: 127.23.45.88  ColonHex: FEDC:0000:0000:0000:3243:0000:0000:ABCD Can skip leading zeros of each word Can skip one sequence of zero words, e.g., FEDC::3243:0000:0000:ABCD or ::3243:0000:0000:ABCD Can leave the last 32 bits in dotdecimal, e.g., ::127.23.45.88 Can specify a prefix by /length, e.g., 2345:BA23:7::/40 Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 11Header  IPv6: Version Class Flow Label Payload Length Next Header Hop Limit Source Address Destination Address  IPv4: Version IHL Type of Service Total Length Identification Flags Fragment Offset Time to Live Protocol Header Checksum Source Address Destination Address Options Padding Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 12The IPv4 Header Version Hdr Len Prec TOS Total Length Identification Flags Fragment Offset Time to Live Protocol Header Checksum Source Address Destination Address Options Padding 32 bits shaded fields are absent from IPv6 header Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 13IPv6 vs IPv4  IPv6 twice the size of IPv4 header  Version: only field w/ same position and meaning  Removed:  Header length, fragmentation fields (identification, flags, fragment offset), header checksum  Replaced:  Datagram length by payload length  Protocol type by next header  Time to live by hop limit  Type of service by “class” octet  Added: flow label  All fixed size fields.  No optional fields. Replaced by extension headers.  Idea: avoid unnecessary processing by intermediate routers w/o sacrificing the flexibility Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 14Extension Headers Base Extension Extension Data Header Header 1 Header n  Most extension headers are examined only at destination  Routing: Loose or tight source routing  Fragmentation: one source can fragment  Authentication  HopbyHop Options  Destination Options: Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 15Extension Header (Continued)  Only Base Header: Base Header TCP Next = TCP Segment  Only Base Header and One Extension Header: Base Header Route Header TCP Next = TCP Next = TCP Segment  Only Base Header and Two Extension Headers: Base Header Route Header Auth Header TCP Next = TCP Next = Auth Next = TCP Segment Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 16Fragmentation  Routers cannot fragment. Only source hosts can.  Need path MTU discovery or tunneling  Fragmentation requires an extension header  Payload is divided into pieces  A new base header is created for each fragment ... Part 1 Part n Base Header Data New Base Header Frag. 1 Header Part 1 New Base Header Frag. 2 Header Part 2 New Base Header Frag. n Header Part n Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 17Initial IPv6 Prefix Allocation Allocation Prefix Allocation Prefix Reserved 0000 0000 Unassigned 101 Unassigned 0000 0001 Unassigned 110 NSAP 0000 001 Unassigned 1110 IPX 0000 010 Unassigned 1111 0 Unassigned 0000 011 Unassigned 1111 10 Unassigned 0000 1 Unassigned 1111 110 Unassigned 0001 Unassigned 1111 1110 Unassigned 001 Unassigned 1111 1110 0 Providerbased 010 LinkLocal 1111 1110 10 Unassigned 011 SiteLocal 1111 1110 11 Geographic 100 Multicast 1111 1111 Has been renamed as “Aggregatable global unicast” Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 18Aggregatable Global Unicast Addresses  Address allocation:“providerbased” plan  Format: TLA + NLA + SLA + 64bit interface ID  TLA = “Top level aggregator.”  For “backbone” providers or “exchange points”  NLA = “Next Level Aggregator”  Second tier provider and a subscriber  More levels of hierarchy possible within NLA  SLA = “Site level aggregator”  Renumbering:change of provider = change the TLA and NLA. But have same SLA I/f ID  Subfields variablelength, nonselfencoding (like CIDR) Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 19Aggregatable Global Unicast Addresses (Continued)  Interface ID = 64 bits Will be based on IEEE EUI64 format An extension of the IEEE 802 (48 bit) format. Possible to derive the IEEE EUI64 equivalent of current IEEE 802 addresses 001 TLA NLA SLA interface ID public site interface topology topology identifier (45 bits) (16 bits) (64 bits) Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 20IPv6 Routing architecture Provider, Exchange TOP TOP Next level Next level Next level Site Link Host Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 21LocalUse Addresses  Link Local: Not forwarded outside the link, FE:80::xxx  Autoconfiguration and when no routers are present 10 bits n bits 118n 1111 1110 10 0 Interface ID  Site Local: Not forwarded outside the site, FE:C0::xxx  Independence from changes of TLA / NLA 10 bits n bits m bits 118nm bits 1111 1110 11 0 SLA Interface ID  Provides plug and play Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 22Multicast Addresses 11111111 flags scope group ID 8 4 4 112 bits  loworder flag indicates permanent / transient group; three other flags reserved  scope field: 1 node local 2 linklocal 5 sitelocal 8 organizationlocal B communitylocal E global (all other values reserved)  All IPv6 routers will support native multicast Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 23Eg: Multicast Scoping  Scoping. Eg: 43  NTP Servers FF01::43  All NTP servers on this node FF02::43  All NTP servers on this link FF05::43  All NTP servers in this site FF08::43  All NTP servers in this org. FF0F::43  All NTP servers in the Internet  Structure of Group ID: First 80 bits = zero (to avoid risk of group collision, because IP multicast mapping uses only 32 bits) Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 24Address Autoconfiguration  Allows plug and play  BOOTP and DHCP are used in IPv4  DHCPng will be used with IPv6  Two Methods: Stateless and Stateful  Stateless: A system uses linklocal address as source and multicasts to "All routers on this link" Router replies and provides all the needed prefix info Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 25Address Autoconfiguration (Continued) All prefixes have a associated lifetime System can use linklocal address permanently if no router  Stateful: Problem w stateless: Anyone can connect Routers ask the new system to go DHCP server (by setting managed configuration bit) System multicasts to "All DHCP servers" DHCP server assigns an address Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 26ICMPv6: Neighbor Discovery  ICMPv6 combines regular ICMP, ARP, Router discovery and IGMP.  The “neighbor discovery” is a generalization of ARP router discovery.  Source maintains several caches: destination cache: dest neighbor mapping neighbor cache: neighbor IPv6 link address prefix cache: prefixes learnt from router advertisements router cache: router IPv6 addresses Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 27Neighbor Discovery (Continued)  Old destination = look up destination cache  If new destination, match the prefix cache. If match = destination local  Else select a router from router cache, use it as the nexthop (neighbor). Add this neighbor address to the destination cache  Solicitationadvertisement model: Multicast solicitation for neighbor media address if unavailable in neighbor cache Neighbor advertisement message sent to soliciting station. Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 28IPv6 Autoconfiguration: 7 problems  1. Endnode acquires L3 address:  Use linklocal address as src and multicast query for advts  Multiple prefixes router addresses returned  2. Router finds L3 address of endnode: same netID  3. Router finds L2 address of endnode: neighbor discovery (generalization of ARP, w/ several caches)  4. Endnodes find router: solicit/listen for router advt  5. Endnodes send directly to each other: same prefix (prefix cache) = direct  6. Best router discovery: ICMPv6 redirects  7. Routerless LAN: same prefix (prefix cache) = direct. Link local addresses + neighbor discovery if no router.  Integrated several techniques from CLNP, IPX, Appletalk etc Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 29AutoReconfiguration (“Renumbering”)  Problem: providers changed = oldprefixes given back and new ones assigned THROUGHOUT the site  Solution:  we assume some overlap period between old and new, i.e., no “flash cutover”  hosts learn prefix lifetimes and preferability from router advertisements  old TCP connections can survive until end of overlap; new TCP connections can survive beyond overlap  Router renumbering protocol, to allow domaininterior routers to learn of prefix introduction / withdrawal  New DNS structure to facilitate prefix changes Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 30Other Features of IPv6  Flow label for more efficient flow identification (avoids having to parse the transportlayer port numbers)  Neighbor unreachability detection protocol for hosts to detect and recover from firsthop router failure  More general header compression (handles more than just IP+TCP)  Security (“IPsec”) differentiated services (“diff serv”) QoS features — same as IPv4 Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 31If IPv6 is so great, how come it is not there yet  Applications  Need upfront investment, stacks, etc.  Similar to Y2K, 32 bit vs. “clean address type”  Network  Need to rampup investment  No “pushbutton” transition Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 32Transition Issues: Protocol upgrades  Most application protocols will have to be upgraded: FTP, SMTP, Telnet, Rlogin  Several full standards revised for IPv6  NonIETF standards: XOpen, Kerberos, ... will be updated… Hosts, routers … the works  With a suite of “fixes” to IPv4, what is compelling in IPv6  Sticks: tight address allocation (3G going to IPv6), NAT becomes too brittle…  Incentives (carrots): stateless autoconf simplifies mobility, if p2p and multimedia grow, then NATs may pose a problem Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 33Transition Mechanisms  1. Recognize that IPv4 will coexist with IPv6 indefinitely  2. Recognize that IPv6 will coexist with NATs for a while  DualIP Hosts, Routers, Name servers  Tunneling IPv6overIPv4 (6over4), IPv4 as link (6to4)  Translation: allow IPv6only hosts to talk to IPv4only hosts Dual Internet Application TCP IPv4 IPv6 Ethernet IPv4 Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 34IPv4IPv6 CoExistence / Transition Three categories: (1) dualstack techniques, to allow IPv4 and IPv6 to coexist in the same devices and networks (2) tunneling techniques, to avoid order dependencies when upgrading hosts, routers, or regions (3) translation techniques, to allow IPv6only devices to communicate with IPv4only devices expect all of these to be used, in combination Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 35DualStack Approach  When adding IPv6 to a system, do not delete IPv4  this multiprotocol approach is familiar and wellunderstood (e.g., for AppleTalk, IPX, etc.)  note: in most cases, IPv6 will be bundled with new OS releases, not an extracost addon  Applications (or libraries) choose IP version to use  when initiating, based on DNS response: if (dest has AAAA or A6 record) use IPv6, else use IPv4  when responding, based on version of initiating packet  This allows indefinite coexistence of IPv4 and IPv6, and gradual, appbyapp upgrades to IPv6 usage Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 36Tunnels  Encapsulate IPv6 inside IPv4 packets (or MPLS).Methods:  Manual configuration  “Tunnel brokers” (using webbased service to create a tunnel)  “6over4” (intradomain, using IPv4 multicast as virtual LAN)  “6to4” (interdomain, using IPv4 addr as IPv6 site prefix)  can view this as:  IPv6 using IPv4 as a virtual linklayer, or  an IPv6 VPN (virtual public network), over the IPv4 Internet (becoming “less virtual” over time) Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 376to4 Automated tunneling across IPv4… Pure “Version 6” Internet Original “Version 4” Internet 1 v4 address = 6to4 Site 6to4 Site 1 v6 network Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 386to4 addresses: 1 v4 address = 1 v6 network FP (3bits) TLA (13bits) IPv4 Address (32bits) SLA ID (16bits) Interface ID (64bits) 001 0x0002 ISP assigned Locally administered Auto configured  Stateless tunnel over the IPv4 network without configuration  The IPv6 address contains the IPv4 address  Entire campus infrastructure fits behind single IPv4 address Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 396to4: tunnel IPv6 over IPv4 1.2.3.4 192.88.99.1 2002:102:304::b… 3001:2:3:4:c… 6to4A Relay C A Native IPv6 IPv4 Internet 2002:506:708::b… B Relay 6to4B 5.6.7.8 192.88.99.1  6to4 router derives IPv6 prefix from IPv4 address,  6to4 relays advertise reachability of prefix 2002::/16  Automatic tunneling from 6to4 routers or relays  Single address (192.88.99.1) for all relays Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 40ISATAP: IPv6 behind firewall  ISATAP router provides D IPv6 prefix IPv4 IPv6  Host complements prefix Internet Internet with IPv4 address  Direct tunneling between IPv4 FW IPv6 FW ISATAP hosts ISATAP  Relay through ISATAP B router to IPv6 local or Local Firewalled “native” global IPv4 IPv6 network network C A Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 41Shipworm: IPv6 through NAT C  Shipworm: IPv6 / UDP IPv6 Internet  IPv6 prefix: IP address UDP port Relay IPv4 Internet  Shipworm servers  Address discovery Server  Default “route”  Enable “shortcut” (AB) NAT NAT  Shipworm relays  Send IPv6 packets directly to nodes A B  Works for all NAT Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 42Translation: path from NATs  May prefer to use IPv6IPv4 protocol translation for:  new kinds of Internet devices (e.g., cell phones, cars, appliances)  benefits of shedding IPv4 stack (e.g. autoconfig)  Simple extension to NAT techniques, to translate header format as well as addresses  IPv6 nodes behind a translator get full IPv6 functionality when talking to other IPv6 nodes located anywhere  they get the normal (i.e., degraded) NAT functionality when talking to IPv4 devices  methods used to improve NAT functionality (e.g, ALGs, RSIP) can be used equally to improve IPv6 IPv4 functionality  Alternative: transportlayer relay or applayer gateways Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 43Network Address Translation and Protocol Translation (NATPT) IPv6only devices NATPT IPv4only and dualstack devices Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 44RSIPbased evolution leads to IPv6 IPv4 Crisis IPv4+NAT Broken... Unlikely direction… IPv4+RSIP Since RSIP is not Future proof... gaining traction IPv6+RSIP Backbone... IPv6 Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 45Firewall Control Protocol (FCP) Enterprise network Firewall Internet Media SIP Port 5060 Firewall SIP Control Proxy Work in progress: Protocol IETF “MIDCOM” Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 46Standards  core IPv6 specifications are IETF Draft Standards = welltested stable  IPv6 base spec, ICMPv6, Neighbor Discovery, Multicast Listener Discovery, PMTU Discovery, IPv6 overEthernet,...  other important specs are further behind on the standards track, but in good shape  mobile IPv6, header compression, A6 DNS support, IPv6overNBMA,...  for uptodate status: playground.sun.com / ipng  the 3GPP cellular wireless standards are highly likely to mandate IPv6 Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 47Implementations  most IP stack vendors have an implementation at some stage of completeness  some are shipping supported product today, e.g., 3Com, BSD, Epilogue, Ericsson/Telebit, IBM, Hitachi, KAME, Nortel, Sun, Trumpet  others have beta releases now, supported products “soon”, e.g., Cisco, Compaq, HP, Linux community, Microsoft  others known to be implementing, but status unkown  e.g., Apple, Bull, Mentat, Novell, SGI (see playground.sun.com/ipng for most recent status reports)  good attendance at frequent testing events Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 486bone etc…  Experimental infrastructure: the 6bone  for testing and debugging IPv6 protocols and operations  mostly IPv6overIPv4 tunnels  200 sites in 42 countries; mostly universities, network research labs, and IP vendors  Production infrastructure in support of education and research: the 6ren  CAIRN, Canarie, CERNET, Chunahwa Telecom, Dante, ESnet, Internet 2, IPFNET, NTT, Renater, Singren, Sprint, SURFnet, vBNS, WIDE  a mixture of native and tunneled paths  see www.6ren.net, www.6tap.net  Few commercial trials by ISPs announced Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 49Incentive: Peertopeer applications 4255551212 Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 50Problem 1: Peertopeer RTP audio example P1 P2 Home LAN NAT Internet NAT Home LAN  With NAT:  Need to learn the address “outside the NAT”  Provide that address to peer  Need either NATaware application, or application aware NAT  May need a third party registration server to facilitate finding peers Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 51Solution 1: Peertopeer RTP audio example P1 P2 Home Home Home LAN Internet Home LAN Gateway Gateway  With IPv6:  Just use IPv6 address Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 52Problem: Multiparty Conference P1 P2 Home LAN NAT Internet NAT Home LAN P3  With NAT, complex and brittle software:  2 Addresses, inside and outside  P1 provides “inside address” to P3, “outside address” to P2  Need to recognize inside, outside  P1 does not know outside address of P3 to inform P2 Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 53Multiparty IPv6 Conference P1 P2 Home Home Home LAN Internet Home LAN Gateway Gateway P3  With IPv6:  Just use IPv6 addresses Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 54P2P apps: w/ global addresses Server Alice Bob Carroll Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 55P2P apps w/ some firewalls and NAT. Server Alice Bob Carroll Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 56P2P apps: In a world of NAT Server Alice Bob Carroll Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 57Mobility (v4 version) mobile host correspondent foreign agent host home agent home location of mobile host Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 58Mobile IP (v6 version) mobile host correspondent host home agent home location of mobile host Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 59Key drivers Parting thoughts …  Alwayson requirement = large number of actively connected nodes online  3G, internet appliances  large numbers of addresses needed in short order…  IPv6 autoconfiguration and mobility model better  3GPP already moving towards IPv6  P2P apps and multimedia get popular and NAT/ALGs/Firewalls break enough of them  Multihomed sites and traffic engineering hacks in BGP/IPv4 make interdomain routing unscalable  Dual stack, simpler autoconf, automatic tunneling (6to4 etc) simplify migration path and provide installed base  Applications slowly start selfselecting IPv6 Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 60Summary  IPv6 uses 128bit addresses  Allows providerbased, sitelocal, linklocal, multicast, anycast addresses  Fixed header size. Extension headers instead of options for provider selection, security etc  Allows autoconfiguration  DualIP, 6to4 etc for transition Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 61
Website URL
Comment