61
Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 1 IP Next Generation (IPv6) Shivkumar Kalyanaraman Rensselaer Polytechnic Institute [email protected] http://www.ecse.rpi.edu/Homepages/shivkuma Based in part upon slides of Prof. Raj Jain (OSU), S.Deering (Cisco), C. Huitema (Microsoft)

Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 1 IP Next Generation (IPv6) Shivkumar Kalyanaraman Rensselaer Polytechnic Institute [email protected]

  • View
    227

  • Download
    0

Embed Size (px)

Citation preview

Page 1: Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 1 IP Next Generation (IPv6) Shivkumar Kalyanaraman Rensselaer Polytechnic Institute shivkuma@ecse.rpi.edu

Shivkumar KalyanaramanRensselaer Polytechnic Institute

1

IP Next Generation (IPv6)

Shivkumar KalyanaramanRensselaer Polytechnic Institute

[email protected] http://www.ecse.rpi.edu/Homepages/shivkuma

Based in part upon slides of Prof. Raj Jain (OSU), S.Deering (Cisco), C. Huitema (Microsoft)

Page 2: Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 1 IP Next Generation (IPv6) Shivkumar Kalyanaraman Rensselaer Polytechnic Institute shivkuma@ecse.rpi.edu

Shivkumar KalyanaramanRensselaer Polytechnic Institute

2

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

Overview

Page 3: Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 1 IP Next Generation (IPv6) Shivkumar Kalyanaraman Rensselaer Polytechnic Institute shivkuma@ecse.rpi.edu

Shivkumar KalyanaramanRensselaer Polytechnic Institute

3

Pre-IP: Translation, ALGs

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

ALG

ALGALG

ALG

Page 4: Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 1 IP Next Generation (IPv6) Shivkumar Kalyanaraman Rensselaer Polytechnic Institute shivkuma@ecse.rpi.edu

Shivkumar KalyanaramanRensselaer Polytechnic Institute

4

The IP Solution …

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

IP

IPIP

IP

Page 5: Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 1 IP Next Generation (IPv6) Shivkumar Kalyanaraman Rensselaer Polytechnic Institute shivkuma@ecse.rpi.edu

Shivkumar KalyanaramanRensselaer Polytechnic Institute

5

The Internet Today: with NATs

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)

NAT-ALG

IPNAT-ALG

NAT-ALG

Page 6: Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 1 IP Next Generation (IPv6) Shivkumar Kalyanaraman Rensselaer Polytechnic Institute shivkuma@ecse.rpi.edu

Shivkumar KalyanaramanRensselaer Polytechnic Institute

6

Address Shortage Causes More NAT Deployment

Address exhaustion date estimate varies from 2009-2019!

1

10

100

1000

10000

S-96

M-97

S-97

M-98

S-98

M-99

S-99

M-00

S-00

M-01

S-01

M-02

S-02

M-03

S-03

M-04

S-04

M-05

S-05

M-06

S-06

M-07

S-07

M-08

S-08

M-09

Page 7: Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 1 IP Next Generation (IPv6) Shivkumar Kalyanaraman Rensselaer Polytechnic Institute shivkuma@ecse.rpi.edu

Shivkumar KalyanaramanRensselaer Polytechnic Institute

7

IPv4 Addresses

Example: 164.107.134.5 = 1010 0100 : 0110 1011 : 1000 0110 : 0000 0101= A4:6B:86:05 (32 bits)

Maximum number of address = 232 = 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

Page 8: Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 1 IP Next Generation (IPv6) Shivkumar Kalyanaraman Rensselaer Polytechnic Institute shivkuma@ecse.rpi.edu

Shivkumar KalyanaramanRensselaer Polytechnic Institute

8

How Many Addresses? 10 Billion people by 2020 Each person has more than one computer Assuming 100 computers per person 1012

computers More addresses may be required since

Multiple interfaces per nodeMultiple addresses per interfaceSome believe 26 to 28 addresses per host

Safety margin 1015 addresses IPng Requirements 1012 end systems and 109

networks. Desirable 1012 to 1015 networks

Page 9: Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 1 IP Next Generation (IPv6) Shivkumar Kalyanaraman Rensselaer Polytechnic Institute shivkuma@ecse.rpi.edu

Shivkumar KalyanaramanRensselaer Polytechnic Institute

9

How big an address space ? H Ratio = log10(# of objects)/available bits 2n objects with n bits: H-Ratio = log102 = 0.30103 French telephone moved from 8 to 9 digits at 107

households H = 0.26 (~3.3 bits/digit) US telephone expanded area codes with 108

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

Page 10: Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 1 IP Next Generation (IPv6) Shivkumar Kalyanaraman Rensselaer Polytechnic Institute shivkuma@ecse.rpi.edu

Shivkumar KalyanaramanRensselaer Polytechnic Institute

10

IPv6 Addresses 128-bit long. Fixed size 2128 = 3.4×1038 addresses

665×1021 addresses per sq. m of earth surface If assigned at the rate of 106/s, it would take 20 years Expected to support 8×1017 to 2×1033 addresses

8×1017 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

Page 11: Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 1 IP Next Generation (IPv6) Shivkumar Kalyanaraman Rensselaer Polytechnic Institute shivkuma@ecse.rpi.edu

Shivkumar KalyanaramanRensselaer Polytechnic Institute

11

Colon-Hex Notation Dot-Decimal: 127.23.45.88 Colon-Hex:

FEDC:0000:0000:0000:3243:0000:0000:ABCDCan skip leading zeros of each wordCan 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

Page 12: Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 1 IP Next Generation (IPv6) Shivkumar Kalyanaraman Rensselaer Polytechnic Institute shivkuma@ecse.rpi.edu

Shivkumar KalyanaramanRensselaer Polytechnic Institute

12

Header

Version Class Flow LabelPayload Length Next Header Hop Limit

Source Address

Destination Address

Version IHL Type of Service Total LengthIdentification Flags Fragment Offset

Time to Live Protocol Header ChecksumSource Address

Destination AddressPaddingOptions

IPv6:

IPv4:

Page 13: Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 1 IP Next Generation (IPv6) Shivkumar Kalyanaraman Rensselaer Polytechnic Institute shivkuma@ecse.rpi.edu

Shivkumar KalyanaramanRensselaer Polytechnic Institute

13

The IPv4 Header

shaded fields are absent from IPv6 header

Version Total LengthIdentification

32 bits

Hdr Len Prec TOSFragment OffsetFlags

Time to Live Protocol Header ChecksumSource Address

Destination AddressPaddingOptions

Page 14: Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 1 IP Next Generation (IPv6) Shivkumar Kalyanaraman Rensselaer Polytechnic Institute shivkuma@ecse.rpi.edu

Shivkumar KalyanaramanRensselaer Polytechnic Institute

14

IPv6 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

Page 15: Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 1 IP Next Generation (IPv6) Shivkumar Kalyanaraman Rensselaer Polytechnic Institute shivkuma@ecse.rpi.edu

Shivkumar KalyanaramanRensselaer Polytechnic Institute

15

Extension Headers

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:

BaseHeader

ExtensionHeader 1

ExtensionHeader n

Data

Page 16: Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 1 IP Next Generation (IPv6) Shivkumar Kalyanaraman Rensselaer Polytechnic Institute shivkuma@ecse.rpi.edu

Shivkumar KalyanaramanRensselaer Polytechnic Institute

16

Extension Header (Continued)

Base HeaderNext = TCP

Route HeaderNext = TCP

TCPSegment

Base HeaderNext = TCP

Route HeaderNext = Auth

Auth HeaderNext = TCP

TCPSegment

Base HeaderNext = TCP

TCPSegment

Only Base Header:

Only Base Header and One Extension Header:

Only Base Header and Two Extension Headers:

Page 17: Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 1 IP Next Generation (IPv6) Shivkumar Kalyanaraman Rensselaer Polytechnic Institute shivkuma@ecse.rpi.edu

Shivkumar KalyanaramanRensselaer Polytechnic Institute

17

Fragmentation 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

Data

Frag. 1 Header Part 1

Frag. 2 Header Part 2

Frag. n Header Part n

New Base Header

New Base Header

New Base Header

Base HeaderPart 1 Part n...

Page 18: Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 1 IP Next Generation (IPv6) Shivkumar Kalyanaraman Rensselaer Polytechnic Institute shivkuma@ecse.rpi.edu

Shivkumar KalyanaramanRensselaer Polytechnic Institute

18

Initial IPv6 Prefix Allocation

PrefixUnassigned0000 0000

Allocation Allocation PrefixReserved 101Unassigned 0000 0001 Unassigned 110NSAP 0000 001 Unassigned 1110IPX 0000 010 Unassigned 1111 0Unassigned 0000 011 Unassigned 1111 10Unassigned 0000 1 Unassigned 1111 110Unassigned 0001 Unassigned 1111 1110Unassigned 001 Unassigned 1111 1110 0Provider-based* 010 Link-Local 1111 1110 10Unassigned 011 Site-Local 1111 1110 11Geographic 100 Multicast 1111 1111

*Has been renamed as “Aggregatable global unicast”

Page 19: Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 1 IP Next Generation (IPv6) Shivkumar Kalyanaraman Rensselaer Polytechnic Institute shivkuma@ecse.rpi.edu

Shivkumar KalyanaramanRensselaer Polytechnic Institute

19

Aggregatable 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)

Page 20: Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 1 IP Next Generation (IPv6) Shivkumar Kalyanaraman Rensselaer Polytechnic Institute shivkuma@ecse.rpi.edu

Shivkumar KalyanaramanRensselaer Polytechnic Institute

20

Aggregatable Global Unicast Addresses (Continued)

Interface ID = 64 bitsWill be based on IEEE EUI-64 formatAn extension of the IEEE 802 (48 bit) format.Possible to derive the IEEE EUI-64 equivalent

of current IEEE 802 addresses

sitetopology(16 bits)

interfaceidentifier(64 bits)

publictopology(45 bits)

interface IDSLA*NLA*TLA001

Page 21: Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 1 IP Next Generation (IPv6) Shivkumar Kalyanaraman Rensselaer Polytechnic Institute shivkuma@ecse.rpi.edu

Shivkumar KalyanaramanRensselaer Polytechnic Institute

21

TOP TOP

Next level Next level Next level

Site

LinkHost

Provider,Exchange

IPv6 Routing architecture

Page 22: Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 1 IP Next Generation (IPv6) Shivkumar Kalyanaraman Rensselaer Polytechnic Institute shivkuma@ecse.rpi.edu

Shivkumar KalyanaramanRensselaer Polytechnic Institute

22

Local-Use Addresses Link Local: Not forwarded outside the link, FE:80::xxx

Auto-configuration and when no routers are present

0 Interface ID1111 1110 1010 bits n bits 118-n

Site Local: Not forwarded outside the site, FE:C0::xxx Independence from changes of TLA / NLA*

Provides plug and play

0 SLA*1111 1110 1110 bits n bits m bits

Interface ID118-n-m bits

Page 23: Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 1 IP Next Generation (IPv6) Shivkumar Kalyanaraman Rensselaer Polytechnic Institute shivkuma@ecse.rpi.edu

Shivkumar KalyanaramanRensselaer Polytechnic Institute

23

Multicast Addresses

low-order flag indicates permanent / transient group; three other flags reserved

scope field: 1 - node local2 - link-local5 - site-local8 - organization-localB - community-localE - global

(all other values reserved) All IPv6 routers will support native multicast

4 112 bits8

group IDscopeflags11111111

4

Page 24: Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 1 IP Next Generation (IPv6) Shivkumar Kalyanaraman Rensselaer Polytechnic Institute shivkuma@ecse.rpi.edu

Shivkumar KalyanaramanRensselaer Polytechnic Institute

24

Eg: Multicast Scoping Scoping. Eg: 43 NTP Servers

FF01::43 All NTP servers on this nodeFF02::43 All NTP servers on this linkFF05::43 All NTP servers in this siteFF08::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)

Page 25: Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 1 IP Next Generation (IPv6) Shivkumar Kalyanaraman Rensselaer Polytechnic Institute shivkuma@ecse.rpi.edu

Shivkumar KalyanaramanRensselaer Polytechnic Institute

25

Address Auto-configuration 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 link-local address as source and multicasts to "All routers on this link"

Router replies and provides all the needed prefix info

Page 26: Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 1 IP Next Generation (IPv6) Shivkumar Kalyanaraman Rensselaer Polytechnic Institute shivkuma@ecse.rpi.edu

Shivkumar KalyanaramanRensselaer Polytechnic Institute

26

Address Auto-configuration (Continued)

All prefixes have a associated lifetimeSystem can use link-local address

permanently if no router Stateful:

Problem w stateless: Anyone can connectRouters ask the new system to go DHCP

server (by setting managed configuration bit)System multicasts to "All DHCP servers"DHCP server assigns an address

Page 27: Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 1 IP Next Generation (IPv6) Shivkumar Kalyanaraman Rensselaer Polytechnic Institute shivkuma@ecse.rpi.edu

Shivkumar KalyanaramanRensselaer Polytechnic Institute

27

ICMPv6: 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 mappingneighbor cache: neighbor IPv6 -> link addressprefix cache: prefixes learnt from router

advertisements router cache: router IPv6 addresses

Page 28: Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 1 IP Next Generation (IPv6) Shivkumar Kalyanaraman Rensselaer Polytechnic Institute shivkuma@ecse.rpi.edu

Shivkumar KalyanaramanRensselaer Polytechnic Institute

28

Neighbor 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

next-hop (neighbor). Add this neighbor address to the destination

cache Solicitation-advertisement model:

Multicast solicitation for neighbor media address if unavailable in neighbor cache

Neighbor advertisement message sent to soliciting station.

Page 29: Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 1 IP Next Generation (IPv6) Shivkumar Kalyanaraman Rensselaer Polytechnic Institute shivkuma@ecse.rpi.edu

Shivkumar KalyanaramanRensselaer Polytechnic Institute

29

IPv6 Auto-configuration: 7 problems 1. End-node acquires L3 address:

Use link-local address as src and multicast query for advts Multiple prefixes & router addresses returned

2. Router finds L3 address of end-node: same net-ID 3. Router finds L2 address of end-node: neighbor discovery

(generalization of ARP, w/ several caches) 4. End-nodes find router: solicit/listen for router advt 5. End-nodes send directly to each other: same prefix (prefix

cache) => direct 6. Best router discovery: ICMPv6 redirects 7. Router-less LAN: same prefix (prefix cache) => direct. Link-

local addresses + neighbor discovery if no router.

Integrated several techniques from CLNP, IPX, Appletalk etc

Page 30: Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 1 IP Next Generation (IPv6) Shivkumar Kalyanaraman Rensselaer Polytechnic Institute shivkuma@ecse.rpi.edu

Shivkumar KalyanaramanRensselaer Polytechnic Institute

30

Auto-Reconfiguration(“Renumbering”)

Problem: providers changed => old-prefixes given back and new ones assigned THROUGHOUT the site

Solution: we assume some overlap period between old and

new, i.e., no “flash cut-over” 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 domain-interior routers to learn of prefix introduction / withdrawal

New DNS structure to facilitate prefix changes

Page 31: Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 1 IP Next Generation (IPv6) Shivkumar Kalyanaraman Rensselaer Polytechnic Institute shivkuma@ecse.rpi.edu

Shivkumar KalyanaramanRensselaer Polytechnic Institute

31

Other Features of IPv6

Flow label for more efficient flow identification (avoids having to parse the transport-layer port numbers)

Neighbor un-reachability detection protocol for hosts to detect and recover from first-hop router failure

More general header compression (handles more than just IP+TCP)

Security (“IPsec”) & differentiated services (“diff-serv”) QoS features — same as IPv4

Page 32: Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 1 IP Next Generation (IPv6) Shivkumar Kalyanaraman Rensselaer Polytechnic Institute shivkuma@ecse.rpi.edu

Shivkumar KalyanaramanRensselaer Polytechnic Institute

32

If 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 ramp-up

investment No “push-button”

transition

Page 33: Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 1 IP Next Generation (IPv6) Shivkumar Kalyanaraman Rensselaer Polytechnic Institute shivkuma@ecse.rpi.edu

Shivkumar KalyanaramanRensselaer Polytechnic Institute

33

Transition Issues: Protocol upgrades Most application protocols will have to be upgraded: FTP,

SMTP, Telnet, Rlogin Several full standards revised for IPv6 Non-IETF standards: X-Open, 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

Page 34: Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 1 IP Next Generation (IPv6) Shivkumar Kalyanaraman Rensselaer Polytechnic Institute shivkuma@ecse.rpi.edu

Shivkumar KalyanaramanRensselaer Polytechnic Institute

34

Transition Mechanisms 1. Recognize that IPv4 will co-exist with IPv6 indefinitely 2. Recognize that IPv6 will co-exist with NATs for a while Dual-IP Hosts, Routers, Name servers Tunneling IPv6-over-IPv4 (6-over-4), IPv4 as link (6-to-4) Translation: allow IPv6-only hosts to talk to IPv4-only hosts

Application

IPv4 IPv6

TCP

Ethernet

Internet Dual

IPv4

Page 35: Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 1 IP Next Generation (IPv6) Shivkumar Kalyanaraman Rensselaer Polytechnic Institute shivkuma@ecse.rpi.edu

Shivkumar KalyanaramanRensselaer Polytechnic Institute

35

IPv4-IPv6 Co-Existence / TransitionThree categories:

(1) dual-stack techniques, to allow IPv4 and IPv6 to co-exist in the same devices and networks

(2) tunneling techniques, to avoid order dependencies when upgrading hosts, routers, or regions

(3) translation techniques, to allow IPv6-only devices to communicate with IPv4-only devices

expect all of these to be used, in combination

Page 36: Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 1 IP Next Generation (IPv6) Shivkumar Kalyanaraman Rensselaer Polytechnic Institute shivkuma@ecse.rpi.edu

Shivkumar KalyanaramanRensselaer Polytechnic Institute

36

Dual-Stack Approach When adding IPv6 to a system, do not delete IPv4

this multi-protocol approach is familiar andwell-understood (e.g., for AppleTalk, IPX, etc.)

note: in most cases, IPv6 will be bundled withnew OS releases, not an extra-cost add-on

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 co-existence of IPv4 and IPv6, and gradual, app-by-app upgrades to IPv6 usage

Page 37: Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 1 IP Next Generation (IPv6) Shivkumar Kalyanaraman Rensselaer Polytechnic Institute shivkuma@ecse.rpi.edu

Shivkumar KalyanaramanRensselaer Polytechnic Institute

37

Tunnels Encapsulate IPv6 inside IPv4 packets (or MPLS).Methods:

Manual configuration “Tunnel brokers” (using web-based service to create a

tunnel) “6-over-4” (intra-domain, using IPv4 multicast as virtual

LAN) “6-to-4” (inter-domain, using IPv4 addr as IPv6 site prefix)

can view this as: IPv6 using IPv4 as a virtual link-layer, or an IPv6 VPN (virtual public network), over the IPv4

Internet(becoming “less virtual” over time)

Page 38: Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 1 IP Next Generation (IPv6) Shivkumar Kalyanaraman Rensselaer Polytechnic Institute shivkuma@ecse.rpi.edu

Shivkumar KalyanaramanRensselaer Polytechnic Institute

38

Pure “Version 6” InternetPure “Version 6” Internet

Original “Version 4” InternetOriginal “Version 4” Internet

6to4 Site6to4 Site 6to4 Site6to4 Site

6to4

1 v4 address = 1 v4 address = 1 v6 network1 v6 network

Automated tunneling across IPv4…

Page 39: Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 1 IP Next Generation (IPv6) Shivkumar Kalyanaraman Rensselaer Polytechnic Institute shivkuma@ecse.rpi.edu

Shivkumar KalyanaramanRensselaer Polytechnic Institute

39

6to4 addresses:1 v4 address = 1 v6 network

Stateless tunnel over the IPv4 network without configuration The IPv6 address contains the IPv4 address Entire campus infrastructure fits behind single IPv4

address

FP  (3bits)

TLA  (13bits)

IPv4 Address  (32bits) SLA ID  (16bits) Interface ID (64bits)

001 0x0002 ISP assignedLocally

administeredAuto configured

Page 40: Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 1 IP Next Generation (IPv6) Shivkumar Kalyanaraman Rensselaer Polytechnic Institute shivkuma@ecse.rpi.edu

Shivkumar KalyanaramanRensselaer Polytechnic Institute

40

6to4: tunnel IPv6 over IPv4

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

IPv4 Internet

6to4-A

6to4-B

Relay

Native IPv6

Relay

C

B

A

1.2.3.4

5.6.7.8

192.88.99.1

192.88.99.1

3001:2:3:4:c…

2002:506:708::b…

2002:102:304::b…

Page 41: Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 1 IP Next Generation (IPv6) Shivkumar Kalyanaraman Rensselaer Polytechnic Institute shivkuma@ecse.rpi.edu

Shivkumar KalyanaramanRensselaer Polytechnic Institute

41

ISATAP: IPv6 behind firewall

ISATAP router provides IPv6 prefix

Host complements prefix with IPv4 address

Direct tunneling between ISATAP hosts

Relay through ISATAP router to IPv6 local or global

Firewalled IPv4

network

IPv4 FW

A

Local “native” IPv6

network

IPv6 FW

ISATAP

B

IPv6Internet

C

D

IPv4Internet

Page 42: Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 1 IP Next Generation (IPv6) Shivkumar Kalyanaraman Rensselaer Polytechnic Institute shivkuma@ecse.rpi.edu

Shivkumar KalyanaramanRensselaer Polytechnic Institute

42

Shipworm: IPv6 through NAT

Shipworm: IPv6 / UDP IPv6 prefix: IP address

& UDP port Shipworm servers

Address discovery Default “route” Enable “shortcut” (A-B)

Shipworm relays Send IPv6 packets

directly to nodes Works for all NAT

NAT

B

Server

IPv4 Internet

IPv6 Internet

Relay

C

A

NAT

Page 43: Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 1 IP Next Generation (IPv6) Shivkumar Kalyanaraman Rensselaer Polytechnic Institute shivkuma@ecse.rpi.edu

Shivkumar KalyanaramanRensselaer Polytechnic Institute

43

Translation: path from NATs May prefer to use IPv6-IPv4 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: transport-layer relay or app-layer gateways

Page 44: Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 1 IP Next Generation (IPv6) Shivkumar Kalyanaraman Rensselaer Polytechnic Institute shivkuma@ecse.rpi.edu

Shivkumar KalyanaramanRensselaer Polytechnic Institute

44

NAT-PT

Network Address Translationand Protocol Translation (NAT-PT)

IPv4-only anddual-stack devices

IPv6-onlydevices

Page 45: Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 1 IP Next Generation (IPv6) Shivkumar Kalyanaraman Rensselaer Polytechnic Institute shivkuma@ecse.rpi.edu

Shivkumar KalyanaramanRensselaer Polytechnic Institute

45

RSIP-based evolution leads to IPv6

IPv4

IPv4+NAT

IPv4+RSIP

IPv6+RSIP

IPv6

Crisis

Broken...

Future proof...

Backbone...

Unlikely direction…

Since RSIP is not gaining traction

Page 46: Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 1 IP Next Generation (IPv6) Shivkumar Kalyanaraman Rensselaer Polytechnic Institute shivkuma@ecse.rpi.edu

Shivkumar KalyanaramanRensselaer Polytechnic Institute

46

Firewall Control Protocol (FCP)

SIPProxy

Enterprise network

Internet

FirewallControl Protocol

Firewall

Media

Port 5060SIPUser

Work in progress: Work in progress: IETF “MIDCOM”IETF “MIDCOM”

Page 47: Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 1 IP Next Generation (IPv6) Shivkumar Kalyanaraman Rensselaer Polytechnic Institute shivkuma@ecse.rpi.edu

Shivkumar KalyanaramanRensselaer Polytechnic Institute

47

Standards

core IPv6 specifications are IETF Draft Standards=> well-tested & stable IPv6 base spec, ICMPv6, Neighbor Discovery,

Multicast Listener Discovery, PMTU Discovery, IPv6-over-Ethernet,...

other important specs are further behind on the standards track, but in good shape mobile IPv6, header compression, A6 DNS support,

IPv6-over-NBMA,... for up-to-date status: playground.sun.com / ipng

the 3GPP cellular wireless standards are highly likely to mandate IPv6

Page 48: Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 1 IP Next Generation (IPv6) Shivkumar Kalyanaraman Rensselaer Polytechnic Institute shivkuma@ecse.rpi.edu

Shivkumar KalyanaramanRensselaer Polytechnic Institute

48

Implementations 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

Page 49: Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 1 IP Next Generation (IPv6) Shivkumar Kalyanaraman Rensselaer Polytechnic Institute shivkuma@ecse.rpi.edu

Shivkumar KalyanaramanRensselaer Polytechnic Institute

49

6-bone etc… Experimental infrastructure: the 6bone

for testing and debugging IPv6 protocols and operations mostly IPv6-over-IPv4 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

Page 50: Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 1 IP Next Generation (IPv6) Shivkumar Kalyanaraman Rensselaer Polytechnic Institute shivkuma@ecse.rpi.edu

Shivkumar KalyanaramanRensselaer Polytechnic Institute

50

Incentive: Peer-to-peer applications?

4255551212

Page 51: Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 1 IP Next Generation (IPv6) Shivkumar Kalyanaraman Rensselaer Polytechnic Institute shivkuma@ecse.rpi.edu

Shivkumar KalyanaramanRensselaer Polytechnic Institute

51

Problem 1: Peer-to-peerRTP audio example

With NAT: Need to learn the address “outside the NAT” Provide that address to peer Need either NAT-aware application, or application-

aware NAT May need a third party registration server to

facilitate finding peers

Home LAN Internet

P1

NAT Home LAN

P2

NAT

Page 52: Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 1 IP Next Generation (IPv6) Shivkumar Kalyanaraman Rensselaer Polytechnic Institute shivkuma@ecse.rpi.edu

Shivkumar KalyanaramanRensselaer Polytechnic Institute

52

Solution 1: Peer-to-peer RTP audio example

With IPv6: Just use IPv6 address

P1 P2

Home LAN InternetHomeGateway Home LANHome

Gateway

Page 53: Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 1 IP Next Generation (IPv6) Shivkumar Kalyanaraman Rensselaer Polytechnic Institute shivkuma@ecse.rpi.edu

Shivkumar KalyanaramanRensselaer Polytechnic Institute

53

Problem: Multiparty Conference

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

P1 P2

P3Home LAN InternetNAT Home LANNAT

Page 54: Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 1 IP Next Generation (IPv6) Shivkumar Kalyanaraman Rensselaer Polytechnic Institute shivkuma@ecse.rpi.edu

Shivkumar KalyanaramanRensselaer Polytechnic Institute

54

Multiparty IPv6 Conference

With IPv6: Just use IPv6 addresses

P1 P2

P3Home LAN InternetHome

Gateway Home LANHomeGateway

Page 55: Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 1 IP Next Generation (IPv6) Shivkumar Kalyanaraman Rensselaer Polytechnic Institute shivkuma@ecse.rpi.edu

Shivkumar KalyanaramanRensselaer Polytechnic Institute

55

P2P apps: w/ global addresses

AliceAlice BobBob CarrollCarroll

ServerServer

Page 56: Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 1 IP Next Generation (IPv6) Shivkumar Kalyanaraman Rensselaer Polytechnic Institute shivkuma@ecse.rpi.edu

Shivkumar KalyanaramanRensselaer Polytechnic Institute

56

P2P apps w/ some firewalls and NAT.

AliceAlice BobBob CarrollCarroll

ServerServer

Page 57: Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 1 IP Next Generation (IPv6) Shivkumar Kalyanaraman Rensselaer Polytechnic Institute shivkuma@ecse.rpi.edu

Shivkumar KalyanaramanRensselaer Polytechnic Institute

57

P2P apps: In a world of NAT

AliceAlice BobBob CarrollCarroll

ServerServer

Page 58: Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 1 IP Next Generation (IPv6) Shivkumar Kalyanaraman Rensselaer Polytechnic Institute shivkuma@ecse.rpi.edu

Shivkumar KalyanaramanRensselaer Polytechnic Institute

58

Mobility (v4 version)

home agent

home location of mobile host

foreign agent

mobile host

correspondenthost

Page 59: Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 1 IP Next Generation (IPv6) Shivkumar Kalyanaraman Rensselaer Polytechnic Institute shivkuma@ecse.rpi.edu

Shivkumar KalyanaramanRensselaer Polytechnic Institute

59

Mobile IP (v6 version)

home agent

home location of mobile host

mobile host

correspondenthost

Page 60: Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 1 IP Next Generation (IPv6) Shivkumar Kalyanaraman Rensselaer Polytechnic Institute shivkuma@ecse.rpi.edu

Shivkumar KalyanaramanRensselaer Polytechnic Institute

60

Key drivers? Parting thoughts … Always-on requirement => large number of actively

connected nodes online 3G, internet appliances

large numbers of addresses needed in short order… IPv6 auto-configuration and mobility model better 3GPP already moving towards IPv6

P2P apps and multimedia get popular and NAT/ALGs/Firewalls break enough of them

Multi-homed sites and traffic engineering hacks in BGP/IPv4 make inter-domain routing un-scalable

Dual stack, simpler auto-conf, automatic tunneling (6to4 etc) simplify migration path and provide installed base Applications slowly start self-selecting IPv6

Page 61: Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 1 IP Next Generation (IPv6) Shivkumar Kalyanaraman Rensselaer Polytechnic Institute shivkuma@ecse.rpi.edu

Shivkumar KalyanaramanRensselaer Polytechnic Institute

61

Summary

IPv6 uses 128-bit addresses Allows provider-based, site-local, link-local,

multicast, anycast addresses Fixed header size. Extension headers instead of

options for provider selection, security etc Allows auto-configuration Dual-IP, 6-to-4 etc for transition