IPv6 next generation protocol ppt

ipv4 and ipv6 ppt presentation and ipv6 neighbor discovery ppt and ipv4 ipv6 interoperability
Dr.ShivJindal Profile Pic
Dr.ShivJindal,India,Teacher
Published Date:19-07-2017
Your Website URL(Optional)
Comment
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, plug-n-play, multicast support, flows Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 2Pre-IP: Translation, ALGs ALG ALG ALG ALG  application-layer gateways  inevitable loss of some semantics  difficult to deploy new internet-wide applications  hard to diagnose and remedy end-to-end problems  stateful gateways= hard to route around failures  no global addressability  ad-hoc, application-specific solutions Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 3The IP Solution … IP IP IP IP  internet-layer gateways & global addresses  simple, application-independent, lowest denominator network service: best-effort datagrams  stateless gateways could easily route around failures  with application-specific 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 NAT-ALG NAT-ALG NAT-ALG IP  network address translators and app-layer gateways  inevitable loss of some semantics  hard to diagnose and remedy end-to-end 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 2009-2019 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: H-Ratio = 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 16-bit addresses  H = 0.26  3 Million Internet hosts currently using 32-bit addresses  H = 0.20  Huitema (Nov 01) estimates H = 0.26 next year Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 9IPv6 Addresses  128-bit 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, site-local, link-local  85% of the space is unassigned Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 10Colon-Hex Notation  Dot-Decimal: 127.23.45.88  Colon-Hex: 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 dot-decimal, 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  Hop-by-Hop 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 Provider-based 010 Link-Local 1111 1110 10 Unassigned 011 Site-Local 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:“provider-based” plan  Format: TLA + NLA + SLA + 64-bit 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  Sub-fields variable-length, non-self-encoding (like CIDR) Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 19Aggregatable Global Unicast Addresses (Continued)  Interface ID = 64 bits Will be based on IEEE EUI-64 format An extension of the IEEE 802 (48 bit) format. Possible to derive the IEEE EUI-64 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 20