Issues in IPv 6 Deployment Jeff Doyle IPv

Issues in IPv 6 Deployment Jeff Doyle IPv 6 Solutions Manager jeff@juniper. net Copyright © 2003 Juniper Networks, Inc. http: //www. juniper. net

Objective A “wide but shallow” overview of the issues, proposed mechanisms, and protocols involved in deploying IPv 6 http: //www. juniper. net Copyright © 2003 Juniper Networks, Inc. 2

Assumption u You already understand IPv 6 basics v Addressing v Header format v Extension headers v ICMPv 6 and neighbor discovery v Address autoconfiguration http: //www. juniper. net Copyright © 2003 Juniper Networks, Inc. 3

IPv 6 Features u u Increased address space v 128 bits = 340 trillion addresses v (2128 = 340, 282, 366, 920, 938, 463, 374, 607, 431, 768, 211, 456) v = 67 billion addresses per cm 2 of the planet surface Hierarchical address architecture v u More efficient header architecture v u u Improved address aggregation Improved routing efficiency, in some cases Neighbor discovery and autoconfiguration v Improved operational efficiency v Easier network changes and renumbering v Simpler network applications (Mobile IP) Integrated security features http: //www. juniper. net Copyright © 2003 Juniper Networks, Inc. 4

IPv 6 Drivers: IPv 4 Address Exhaustion u IPv 4 addresses particularly scarce in Asia v Some U. S. universities and corporations have more IPv 4 address space than some countries u Imminent demise of IPv 4 address space predicted since mid 1990’s u NAT + RFC 1918 has slowed that demise u 70% of Fortune 1000 companies use NAT* *Source: Center for Next Generation Internet NGI. ORG http: //www. juniper. net Copyright © 2003 Juniper Networks, Inc. 5

NAT Causes Problems u u u u u Breaks globally unique address model Breaks address stability Breaks always-on model Breaks peer-to-peer model Breaks some applications Breaks some security protocols Breaks some Qo. S functions Introduces a false sense of security Introduces hidden costs IPv 6 = plentiful, global addresses = no NAT http: //www. juniper. net Copyright © 2003 Juniper Networks, Inc. 6

Transition Assumptions u No “Flag Day” v u Last Internet transition was 1983 (NCP TCP) Transition will be incremental v Possibly over several years No IPv 4/IPv 6 barriers at any time u Must be easy for end user u v u IPv 6 is designed with transition in mind v u Transition from IPv 4 to dual stack must not break anything Assumption of IPv 4/IPv 6 coexistence Many different transition technologies are A Good Thing™ v “Transition toolbox” to apply to myriad unique situations http: //www. juniper. net Copyright © 2003 Juniper Networks, Inc. 7

Transition Strategies u Edge-to-core v When services are important v When addresses are scarce v User (customer) driven u Core-to-edge v Good ISP strategy u By routing protocol area v When areas are small enough u By subnet v Probably too incremental http: //www. juniper. net Copyright © 2003 Juniper Networks, Inc. 8

Types of Transition Mechanisms u Dual Stacks v IPv 4/IPv 6 coexistence on one device u Tunnels v For tunneling IPv 6 across IPv 4 clouds v Later, for tunneling IPv 4 across IPv 6 clouds v IPv 6 <-> IPv 6 and IPv 4 <-> IPv 4 u Translators v IPv 6 <-> IPv 4 http: //www. juniper. net Copyright © 2003 Juniper Networks, Inc. 9

Dual Stacks u Network, Transport, and Application layers do not necessarily interact without further modification or translation IPv 6 Applications IPv 4 Applications TCP/UDPv 6 TCP/UDPv 4 IPv 6 IPv 4 0 x 86 dd 0 x 0800 Physical/Data Link http: //www. juniper. net Copyright © 2003 Juniper Networks, Inc. 10

“Dual Layers” Applications TCP/UDP IPv 6 IPv 4 0 x 86 dd 0 x 0800 Physical/Data Link http: //www. juniper. net Copyright © 2003 Juniper Networks, Inc. 11

Tunnel Applications IPv 4 IPv 6 Router to Router IPv 4 IPv 6 Host to Host IPv 4 IPv 6 http: //www. juniper. net Copyright © 2003 Juniper Networks, Inc. IPv 6 Host to Router / Router to Host 12

Tunnel Types u Configured tunnels v u Router to router Automatic tunnels v Tunnel Brokers (RFC 3053) u v 6 to 4 (RFC 3056) u v For tunneling through IPv 4 NAT IPv 64 u v Host to router, router to host Teredo u v Host to router, router to host Maybe host to host 6 over 4 (RFC 2529) u v Router to router ISATAP (Intra-Site Automatic Tunnel Addressing Protocol) u u v Server-based automatic tunneling For mixed IPv 4/IPv 6 environments DSTM (Dual Stack Transition Mechanism) u IPv 4 in IPv 6 tunnels http: //www. juniper. net Copyright © 2003 Juniper Networks, Inc. 13

Configuration Example: Configured GRE Tunnel IPv 4 IPv 6 gr-0/0/0 { unit 0 { tunnel { source 172. 16. 1. 1; destination 192. 168. 2. 3; } family inet 6 { address 2001: 240: 13: : 1/126; } } } http: //www. juniper. net Copyright © 2003 Juniper Networks, Inc. IPv 6 gr-1/0/0 { unit 0 { tunnel { source 192. 168. 2. 3; destination 172. 16. 1. 1; } family inet 6 { address 2001: 240: 13: : 2/126; } } } 14

Configuration Example: Configured MPLS Tunnel PE Router: mpls { ipv 6 -tunneling; label-switched-path v 6 -tunnel 1 IPv 6 { to 192. 168. 2. 3; CE no-cspf; } } bgp { group IPv 6 -neighbors { PE type internal; family inet 6 { labeled-unicast { explicit-null; } } neighbor 192. 168. 2. 3; } } http: //www. juniper. net Copyright © 2003 Juniper Networks, Inc. IPv 6 LSP PE IPv 4 MPLS CE IPv 6 15

Tunnel Setup Protocol (TSP) u Proposed control protocol for negotiating tunnel parameters v v v u Example tunnel parameters: v v v u Applicable to several IPv 6 tunneling schemes Can negotiate either IPv 6 or IPv 4 tunnels Uses XML messages over TCP session IP addresses Prefix information Tunnel endpoints DNS delegation Routing information Server redirects Three TSP phases: 1. 2. 3. Authentication Phase Command Phase (client to server) Response Phase (server to client) http: //www. juniper. net Copyright © 2003 Juniper Networks, Inc. 16

Tunnel Broker RFC 3053 describes general architecture, not a specific protocol u Designed for small sites and isolated IPv 6 hosts to connect to an existing IPv 6 network u Three basic components: u Client: Dual-stacked host or router, tunnel end-point v Tunnel Broker: Dedicated server for automatically managing tunnel requests from users, sends requests to Tunnel Server v Tunnel Server: Dual-stacked Internet-connected router, other tunnel end point v u A few tunnel brokers: v v v Freenet 6 [Canada] (www. freenet 6. net) CERNET/Nokia [China] (www. tb. 6 test. edu. cn) Internet Initiative Japan (www. iij. ad. jp) Hurricane Electric [USA] (www. tunnelbroker. com) BTexac. T [UK] (www. tb. ipv 6. btexact. com) Many others… http: //www. juniper. net Copyright © 2003 Juniper Networks, Inc. 17

Tunnel Broker 1. 2. 3. 4. 5. 6. 3 Tunnel Broker 1 2 6 IPv 4 Network Client 7 4 DNS 7. AAA Authorization Configuration request TB chooses: • TS • IPv 6 addresses • Tunnel lifetime TB registers tunnel IPv 6 addresses Config info sent to TS Config info sent to client: • Tunnel parameters • DNS name Tunnel enabled 5 Tunnel Server IPv 6 Network IPv 6 Tunnel http: //www. juniper. net Copyright © 2003 Juniper Networks, Inc. 18

6 to 4 Designed for site-to-site and site to existing IPv 6 network connectivity u Site border router must have at least one globally-unique IPv 4 address u Uses IPv 4 embedded address u Example: u u Reserved 6 to 4 TLA-ID: 2002: : /16 IPv 4 address: 138. 14. 85. 210 = 8 a 0 e: 55 d 2 Resulting 6 to 4 prefix: 2002: 8 a 0 e: 55 d 2: : /48 Router advertises 6 to 4 prefix to hosts via RAs Embedded IPv 4 address allows discovery of tunnel endpoints http: //www. juniper. net Copyright © 2003 Juniper Networks, Inc. 19

6 to 4 IPv 4 address: 138. 14. 85. 210 6 to 4 prefix: 2002: 8 a 0 e: 55 d 2: : /48 IPv 6 Public Internet IPv 4 address: 65. 114. 168. 91 6 to 4 prefix: 2002: 4172: a 85 b: : /48 6 to 4 Relay Router I 6 v P IPv 6 Site 2002: 8 a 0 e: 55 d 2: : a 4 ff: fea 0: bc 97 http: //www. juniper. net Copyright © 2003 Juniper Networks, Inc. IPv 6 Site IPv 6 6 to 4 Router 6 to 4 address: IPv 4 Network 6 to 4 Router 6 to 4 address: 2002: 4172: a 85 b: : 4172: a 85 b 20

Configuration Example: Windows XP 6 to 4 Interface C: Documents and SettingsJeff Doyle>ipv 6 if 3 Interface 3: 6 to 4 Tunneling Pseudo-Interface does not use Neighbor Discovery does not use Router Discovery preferred global 2002: 4172: a 85 b: : 4172: a 85 b, life infinite link MTU 1280 (true link MTU 65515) current hop limit 128 reachable time 23000 ms (base 30000 ms) retransmission interval 1000 ms DAD transmits 0 6 to 4 Prefix http: //www. juniper. net Copyright © 2003 Juniper Networks, Inc. = 65. 114. 168. 91 21

ISATAP u Forms 64 -bit Interface ID from IPv 4 address + special reserved identifier Format: : : 0: 5 efe: W. X. Y. Z v 0: 5 efe = 32 -bit IANA-reserved identifier v W. X. Y. Z = IPv 4 address mapped to last 32 bits v Example: IPv 4 address: Global IPv 6 prefix: 65. 114. 168. 91 2001: 468: 1100: 1: : /64 Link-local address: fe 80: : 5 efe: 65. 114. 168. 91 Global IPv 6 address: 2001: 468: 1100: 1: : 5 efe: 65. 114. 168. 91 http: //www. juniper. net Copyright © 2003 Juniper Networks, Inc. 22

ISATAP IP v 6 IPv 4/IPv 6 Router IPv 6 IPv 4 IP v 6 IPv 6 6 to 4 Router http: //www. juniper. net Copyright © 2003 Juniper Networks, Inc. IPv 4 23

Configuration Example: Windows XP ISATAP Interface C: Documents and SettingsJeff Doyle>ipv 6 if 2 Interface 2: Automatic Tunneling Pseudo-Interface does not use Neighbor Discovery does not use Router Discovery router link-layer address: 0. 0 EUI-64 embedded IPv 4 address: 0. 0 preferred link-local fe 80: : 5 efe: 169. 254. 113. 126, life infinite preferred link-local fe 80: : 5 efe: 65. 114. 168. 91, life infinite preferred global : : 65. 114. 168. 91, life infinite link MTU 1280 (true link MTU 65515) current hop limit 128 reachable time 24000 ms (base 30000 ms) retransmission interval 1000 ms DAD transmits 0 Link-Local IPv 6 Address ISATAP Identifier http: //www. juniper. net Copyright © 2003 Juniper Networks, Inc. IPv 4 Address 24

6 over 4 aka “Virtual Ethernet” u Early proposed tunnel solution u Isolated IPv 6 hosts create their own tunnels u Assumes IPv 4 multicast domain u v Multicast for neighbor/router discovery, autoconfiguration Example IPv 4 Multicast Address: 239. 192. A. B A, B = Last 2 Bytes of IPv 6 Address http: //www. juniper. net Copyright © 2003 Juniper Networks, Inc. 25

Teredo aka “Shipworm” u For tunneling IPv 6 through one or several NATs u Other tunneling solutions require global IPv 4 address, and so do not work from behind NAT v Can be stateless or stateful (using TSP) v Tunnels over UDP (port 3544) rather than IP protocol #41 u Basic components: u v v v Teredo Client: Dual-stacked node Teredo Server: Node with globally routable IPv 4 Internet access, provides IPv 6 connectivity information to client Teredo Relay: Dual-stacked router providing connectivity to client Teredo Bubble: IPv 6 packet with no payload (NH #59) for creating mapping in NAT Teredo Service Prefix: Prefix originated by TS for creating client IPv 6 address Teredo navalis http: //www. juniper. net Copyright © 2003 Juniper Networks, Inc. 26

Teredo 1. 2. 3. 4. 5. 6. u TSP can be used in place of RS/RA for: RS to server NAT maps inside address/port v Stateful tunnel to outsde address/port v Authentication TS notes: • source address/port • NAT type RA to client containing: • Service prefix IPv 4 =1. 2. 3. 4 • origin indication IPv 6 prefix = 3 ffe: 831 f: : /32 Network Client creates IPv 6 address from: Teredo • Server prefix Server • “Obfusticated” origin 2 3 indication Source: 9. 0. 0. 1: 4096 IPv 6 packets Destination: 1. 2. 3. 4: 3544 4 tunneled to relay Source: 1. 2. 3. 4 1 Destination: 9. 0. 0. 1: 4096 Prefix: 3 ffe: 831 f: 0102: 0304: : /64 Source: 10. 0. 0. 1: 2716 Origin Indication: 9. 0. 0. 1: 4096 Destination: 1. 2. 3. 4: 3544 IPv 6 Client 10. 0. 0. 2 5 3 ffe: 831 f: 102: 304: : efff: f 6 ff: fffe http: //www. juniper. net Copyright © 2003 Juniper Networks, Inc. NAT Network IPv 6 over UDP tunnel Inside Address: 10. 0. 0. 1 Outside Address: 9. 0. 0. 1 6 Teredo Relay 27

IPv 64 Proposed for highly interconnected IPv 4 and IPv 6 networks (mid-transition) u IPv 64 packets: IPv 6 encapsulated in IPv 4 u Ver. HL 4 TOS Datagram-ID v u 48 th bit of IPv 4 header indicates IPv 64 packet IPv 64 routers: Process IPv 64 packets as IPv 6 v Process IPv 4 packets as IPv 4 v Process IPv 6 packets as IPv 6 TTL IPv 4 routers: v u Process IPv 64 packets as IPv 4 Flag Frag Offset Protocol. Header Checksum Source IPv 4 Address Destination IPv 4 Address v u Datagram Length IP Options IPv 64 bit 1 = IPv 64 0 = IPv 4 Ver. Traffic 6 class Payload Length Flow label Next Hdr. Hop Limit Source IPv 6 Address IPv 6 routers: Destination IPv 6 Address Cannot process IPv 64 packets v IPv 64 -to-IPv 4 translation required at IPv 64 routers v Proposed IPv 6 Extension Header carries necessary IPv 4 information for re-translating back to IPv 64, if necessary v http: //www. juniper. net Copyright © 2003 Juniper Networks, Inc. 28

Dual-Stack Transition Mechanism (DSTM) u aka 4 over 6 v v u Tunnels IPv 4 over IPv 6 networks Next-Header Number for IPv 4 = 4 Three basic components: Tunnel End Point: Border router between IPv 6 -only network and IPv 4 Internet or intranet v DSTM Clients: Dual-stacked nodes, create tunnels to Tunnel End Pont (TEP) v DSTM Address Server: Allocates IPv 4 addresses to clients v u Uses existing protocols v u DSTM Server can communicate with Client or TEP via DHCPv 6 or TSP Server can optionally assign port range for IPv 4 address conservation v Multiple clients have same IPv 4 address, different port ranges http: //www. juniper. net Copyright © 2003 Juniper Networks, Inc. 29

DSTM 1. 2. 3. 4. 1 Client needs IPv 4 connectivity Client requests tunnel info Server sends IPv 4 tunnel endpoint addresses Tunnel set up jeff. juniper. net = 192. 168. 1. 2 DSTM Server 2 3 IPv 6 Network 3 IPv 4 Network 4 IPv 4 in IPv 6 Tunnel Client http: //www. juniper. net Copyright © 2003 Juniper Networks, Inc. Tunnel End-Point 30

Translators u Network level translators Stateless IP/ICMP Translation Algorithm (SIIT)(RFC 2765) v NAT-PT (RFC 2766) v Bump in the Stack (BIS) (RFC 2767) v u Transport level translators v u Transport Relay Translator (TRT) (RFC 3142) Application level translators Bump in the API (BIA)(RFC 3338) v SOCKS 64 (RFC 3089) v Application Level Gateways (ALG) v http: //www. juniper. net Copyright © 2003 Juniper Networks, Inc. 31

Stateless IP/ICMP Translation (SIIT) u u Translator replaces headers IPv 4 IPv 6 Translates ICMP messages v v Contents of message translated ICMP pseudo-header checksum added Fragments IPv 4 messages to fit IPv 6 MTU when necessary u Uses IPv 4 -translated addresses to refer to IPv 6 enabled nodes u v u Uses IPv 4 -mapped addresses to refer to IPv 4 -only nodes v u 0: 0: ffff: 0: 0: 0/96 + 32 -bit IPv 4 address 0: 0: 0: ffff/96 + 32 -bit IPv 4 address Requires IPv 6 hosts to acquire an IPv 4 address v SIIT must know these addresses http: //www. juniper. net Copyright © 2003 Juniper Networks, Inc. 32

Stateless IP/ICMP Translation (SIIT) 204. 127. 202. 4 IPv 4 Network IPv 6 Network Source = 216. 148. 227. 68 Dest = 204. 127. 202. 4 SIIT Source = 204. 127. 202. 4 Dest = 216. 148. 227. 68 Source = : : ffff: 0: 216. 148. 227. 68 Dest = : : ffff: 204. 127. 202. 4 Source = : : ffff: 204. 127. 202. 4 Dest = : : ffff: 0: 216. 148. 227. 68 SIIT also changes: 3 ffe: 3700: 1100: 1: 210: a 4 ff: fea 0: bc 97 216. 148. 227. 68 http: //www. juniper. net Copyright © 2003 Juniper Networks, Inc. • Traffic Class TOS • Payload length • Protocol Number NH Number • TTL Hop Limit 33

Network Address Translation - Protocol Translation (NAT-PT) u Stateful address translation v v u u Tracks supported sessions Inbound and outbound session packets must traverse the same NAT Uses SIIT for protocol translation Two variations: Basic NAT-PT provides translation of IPv 6 addresses to a pool of IPv 4 addresses v NAPT-PT manipulates IPv 6 port numbers so that multiple IPv 6 sources can share a single IPv 4 address v u DNS Application Level Gateway (DNS-ALG) is also specified, but has some problems v v v v Internal A queries might return AAAA record Possible problems for internal zone transfers, mixed v 4/v 6 networks, etc. Possible problems resolving to external dual-stacked hosts Assumes DNS traffic traverses NAT-PT box (topology limitation) No DNS-sec Vulnerable to Do. S attacks by depletion of address pools See: u draft-durand-natpt-dns-alg-issues-00 for more information u draft-hallin-natpt-dns-alg-solutions-01 for some proposed solutions http: //www. juniper. net Copyright © 2003 Juniper Networks, Inc. 34

Network Address Translation - Protocol Translation (NAT-PT) IPv 4 Pool: 120. 130. 26/24 IPv 6 prefix: 3 ffe: 3700: 1100: 2/64 IPv 6 Network IPv 4 Network DNS v 4 host. 4 net. org? NAT-PT v 4 host. 4 net. org A 204. 127. 202. 4 v 4 host. 4 net. org AAAA 3 ffe: 3700: 1100: 2: : 204. 127. 202. 4 v 4 host. 4 net. org 204. 127. 202. 4 v 6 host. 6 net. com 3 ffe: 3700: 1100: 1: 210: a 4 ff: fea 0: bc 97 http: //www. juniper. net Copyright © 2003 Juniper Networks, Inc. 35

Network Address Translation - Protocol Translation (NAT-PT) IPv 4 Pool: 120. 130. 26/24 IPv 6 prefix: 3 ffe: 3700: 1100: 2/64 IPv 6 Network IPv 4 Network Mapping Table Inside 3 ffe: 3700: 1100: 1: 210: a 4 ff: fea 0: bc 97 DNS Outside 120. 130. 26. 10 Source = 3 ffe: 3700: 1100: 1: 210: a 4 ff: fea 0: bc 97 Dest = 3 ffe: 3700: 1100: 2: : 204. 127. 202. 4 NAT-PT Source = 120. 130. 26. 10 Dest = 204. 127. 202. 4 Source = 204. 127. 202. 4 Dest = 120. 130. 26. 10 v 4 host. 4 net. org 204. 127. 202. 4 Source = 3 ffe: 3700: 1100: 2: : 204. 127. 202. 4 Dest = 3 ffe: 3700: 1100: 1: 210: a 4 ff: fea 0: bc 97 v 6 host. 6 net. com 3 ffe: 3700: 1100: 1: 210: a 4 ff: fea 0: bc 97 http: //www. juniper. net Copyright © 2003 Juniper Networks, Inc. 36

Bump in the Stack (BIS) Translator resides in host u Allows IPv 4 applications to run on IPv 6 host u Three components: u v Translator u IPv 4 IPv 6 u Uses SIIT v Address mapper u Maintains IPv 4 address pool u Maps IPv 6 addresses to IPv 4 addresses v IPv 4 Applications TCP/IPv 4 Ext. Name Resolver Translator Address Mapper Extension Name Resolver u Manages DNS queries u Converts AAAA records to A records u Similar to NAT-PT DNS ALG http: //www. juniper. net Copyright © 2003 Juniper Networks, Inc. Network Card Drivers Network Cards 37 IPv 6

Transport Relay Translator (TRT) u Based on proxy firewall concept u No IP packets transit the TRT u Two connections established: v Initiator to TRT v TRT to target node u Requires special DNS to translate IPv 4 addresses into IPv 6 and vice versa v TRT u Only does not translate DNS queries/records works with TCP and UDP http: //www. juniper. net Copyright © 2003 Juniper Networks, Inc. 38

Transport Relay Translator (TRT) Query to “special” DNS from v 6 host for v 4 host. 4 net. org returns: AAAA fec 0: 0: 0: 1: : 204. 127. 202. 4 IPv 4 Network u TCP/IPv 6 Session Source = 3 ffe: 3700: 1100: 1: 210: a 4 ff: fea 0: bc 97 Dest = fec 0: 0: 0: 1: : 204. 127. 202. 4 TCP/IPv 4 Session Source = 216. 148. 227. 68 Dest = 204. 127. 202. 4 TRT TCP/IPv 4 Session Source = 204. 127. 202. 4 Dest = 216. 148. 227. 68 “Dummy” Prefix = fec 0: 0: 0: 1: : /64 IPv 4 Address = 216. 148. 227. 68 TCP/IPv 6 Session Source = fec 0: 0: 0: 1: : 204. 127. 202. 4 Dest = 3 ffe: 3700: 1100: 1: 210: a 4 ff: fea 0: bc 97 v 6 host. 6 net. com 3 ffe: 3700: 1100: 1: 210: a 4 ff: fea 0: bc 97 http: //www. juniper. net Copyright © 2003 Juniper Networks, Inc. v 4 host. 4 net. org 204. 127. 202. 4 IPv 6 Network 39

Bump in the API (BIA) u Allows dual-stacked IPv 6 hosts to use IPv 4 applications v Same goal as BIS, but translation is between IPv 4 and IPv 6 APIs v API Translator resides between socket API module and IPv 4/IPv 6 TCP/IP modules v No header translation required v Uses SIIT for conversion mechanism http: //www. juniper. net Copyright © 2003 Juniper Networks, Inc. 40

Bump in the API (BIA) u API Translator consists of three modules: Name Resolver intercepts IPv 4 DNS calls, uses IPv 6 calls instead v Address Mapper maintains mappings of internal pool unassigned of IPv 4 addresses (0. 0. 0. 1 ~ 0. 0. 0. 255) to IPv 6 IPv 4 Applications addresses Socket API (IPv 4, IPv 6) v Function Mapper translates API Translator IPV 4 socket API functions to Address Name Function IPv 6 socket API functions Mapper Resolver Mapper and vice versa v TCP (UDP)/IPv 4 TCP (UDP)/IPv 6 Network Card Drivers Network Cards http: //www. juniper. net Copyright © 2003 Juniper Networks, Inc. 41

SOCKS 64 u Uses existing SOCKSv 5 protocol v v u RFC 1928 Designed for firewall systems Two basic components: v Gateway u SOCKS server u IPv 4 and IPv 6 connections terminate at gateway u Gateway relays connections at application layer v SOCKS Lib u Installs on client u Can replace: v v between application layer and socket layer Applications’ socket APIs DNS name resolving APIs u Maintains mapping table between “fake” IPv 4 addresses (0. 0. 0. 1 ~ 0. 0. 0. 255) and logical host names (FQDNs) http: //www. juniper. net Copyright © 2003 Juniper Networks, Inc. 42

SOCKS 64 CLIENT Application Same API SOCKS Lib Socket DNS IPv 6 Network Interface “SOCKSified” connection (control + data) http: //www. juniper. net Copyright © 2003 Juniper Networks, Inc. GATEWAY DESTINATION Gateway Application Socket DNS IPv 6 IPv 4 Network Interface normal connection (data only) 43

Application Layer Gateways u Application-specific translator u Needed when application layer contains IP address u Similar to ALGs used in firewalls, some NATs http: //www. juniper. net Copyright © 2003 Juniper Networks, Inc. 44

Transition Issues: DNS u Namespace fragmentation Some names on IPv 4 DNS, others on IPv 6 DNS v How does an IPv 4 -only host resolve a name in the IPv 6 namespace, and vice versa? v How does a dual-stack host know which server to query? v How do root servers share records? v u MX records v u How does an IPv 4 user send mail to an IPv 6 user and vice versa? Solutions: Dual stacked resolvers v Every zone must be served by at least one IPv 4 DNS server v Use translators (NAT-PT does not work well for this) v totd: proxy DNS translator v u Some DNS transition issues discussed in RFC 1933, Section 3. 2 http: //www. juniper. net Copyright © 2003 Juniper Networks, Inc. 45

DNS AAAA Records u u u RFC 1886 BIND 4. 9. 4 and up; BIND 8 is recommended Simple extension of A records v v u Resource Record type = 28 Query types performing additional section processing (NS, MX, MB) redefined to perform both A and AAAA additional section processing ip 6. arpa analogous to in-addr. arpa for reverse mapping v IPv 6 address represented in reverse, dotted hex nibbles AAAA record: homer IN AAAA 2001: 4210: 3: ce 7: 8: 0: abcd: 1234 PTR record: 4. 3. 2. 1. d. c. b. a. 0. 0. 8. 0. 0. 0. 7. e. c. 0. 3. 0. 0. 1. 2. 4. 1. 0. 0. 2. ip 6. arpa. IN PTR homer. simpson. net u RFC 3152 deprecates ip 6. int in favor of ip 6. arpa http: //www. juniper. net Copyright © 2003 Juniper Networks, Inc. 46

DNS A 6 Records u Proposed alternative to AAAA records RFC 2874 v Resource Record type = 38 v u A 6 RR can contain: Complete IPv 6 address, or v Portion of address and information leading to one or more prefixes v Supported in BIND 9 u More complicated records , but easier renumbering u Segments of IPv 6 address specified in chain of records v Only relevant records must be changed when renumbering v Separate records can reflect addressing topology v http: //www. juniper. net Copyright © 2003 Juniper Networks, Inc. 47

A 6 Record Chain Queried Name: homer. simpson. net $ORIGIN simpson. net homer IN A 6 64 : : 8: 0: abcd. 1234 sla 5. subnets. simpson. net. $ORIGIN subnets. simpson. net sla 5 IN A 6 48 0: 0: 0: ce 7: : site 3. sites. net. $ORIGIN sites. net site 3 IN A 6 32 0: 0: 3: : area 10. areas. net. $ORIGIN areas. net area 10 IN A 6 24 0: 10: : tla 1. tlas. net. $ORIGIN tlas. net tla 1 IN A 6 0 2001: 4200: : Returned Address: 2001: 4210: 3: ce 7: 8: 0: abcd: 1234 http: //www. juniper. net Copyright © 2003 Juniper Networks, Inc. 48

DNAME u DNAME: RFC 2672 u DNAME for IPv 6: RFC 2874 u Provides alternate naming to an entire subtree of domain name space v Rather than to a single node u Chaining complementary to A 6 records u DNAME not much more complex than CNAME u DNAME changed from Proposed Standard to Experimental status in RFC 3363 http: //www. juniper. net Copyright © 2003 Juniper Networks, Inc. 49

Bitstring Labels New scheme for reverse lookups u Bitstring Labels: RFC 2874 u Bitstring Labels for IPv 6: RFC 2673 u Examples: Address: Bitstring labels: u Pro: v u 2001: 4210: 3: ce 7: 8: 0: abcd: 1234 [x 2001421000030 ce 700080000 abcd 1234/128]. ip 6. arpa. [x 00080000 abcd 1234/64]. [x 0 ce 7/16]. [x 20014210/48]. ip 6. arpa. More compact than textual (ip 6. int) representation Con: v All resolvers and authoritative servers must be upgraded before new label type can be used http: //www. juniper. net Copyright © 2003 Juniper Networks, Inc. 50

DNAME Reverse Lookup Queried Address: 2001: 4210: 3: ce 7: 8: 0: abcd: 1234 $ORIGIN ip 6. arpa. [x 200142/24] IN DNAME ip 6. tla. net $ORIGIN ip 6. tla. net [x 10/8] IN DNAME ip 6. isp 1. net $ORIGIN ip 6. isp 1. net [x 0003/16] IN DNAME ip 6. isp 2. net $ORIGIN ip 6. isp 2. net [x 0 ce 7/16] IN DNAME ip 6. simpson. net $ORIGIN ip 6. simpson. net [x 00080000 abcd 1234/64] IN PTR homer. simpson. net Returned Name: homer. simpson. net http: //www. juniper. net Copyright © 2003 Juniper Networks, Inc. 51

AAAA or A 6? u u Good discussion of tradeoffs in RFC 3364 AAAA Pros: Essentially identical to A RRs, which are backed by extensive experience v “Optimized for read” v u AAAA Cons: v u A 6 Pros: v v u “Optimized for write” Possibly superior for rapid renumbering, some multihoming approaches (GSE-like routing) A 6 Cons: v v u Difficult to inject new data Long chains can reduce performance Very little operational experience A 6 RRs changed from Proposed Standard to Experimental status in RFC 3363 v AAAA preferred for production deployment http: //www. juniper. net Copyright © 2003 Juniper Networks, Inc. 52

Open or Semi-Open Issues u Security v v v u Management v v u End-to-end security is better than hiding behind NATs Firewalls must become smarter Transiton vulnerabilities need to be better understood IPv 6 must be managed in conjunction with IPv 4 Long-term, IPv 6 networks should be cheaper to manage than IPv 4 networks Multihoming Transition provides a limited timeframe for fixing the present IPv 4 multihoming mess v Myriad proposed solutions, none ideal, some lousy v IPv 6 PI address spaces are needed! v u Marketing v Plenty of misconceptions and myths remain to be killed http: //www. juniper. net Copyright © 2003 Juniper Networks, Inc. 53

Thank You! http: //www. juniper. net jeff@juniper. net Copyright © 2003 Juniper Networks, Inc. http: //www. juniper. net

What is Multihoming? u Host multihoming More than one unicast address on an interface v Interfaces to more than one network v u Site multihoming Multiple connections to the same ISP v Connections to multiple ISPs Site Multihoming v Host Multihoming ISP pref 1: : /n ISP 1 pref 1: : /n ISP 2 pref 2: : /n pref 1: sitepref: intid pref 2: sitepref: intid HOST Site pref 2: sitepref: intid HOST http: //www. juniper. net Copyright © 2003 Juniper Networks, Inc. 55

Why Multihome? u Redundancy v Against router failure v Against link failure v Against ISP failure u Load sharing u Local connectivity across large geography u Corporate or external policies v Acceptable use policies v Economics http: //www. juniper. net Copyright © 2003 Juniper Networks, Inc. 56

The Multihoming Problem 207. 17/16 207. 17. 137/24 SP 1 207. 17/16 Customer 207. 137/24 “The World” 207. 137/24 SP 2 198. 133/16 207. 137/24 198. 133/16 u u ISP 2 must advertise additional prefix ISP 1 must “punch a hole” in its CIDR block Contributes to routing table explosion Contributes to Internet instability v v u Due to visibility of customer route flaps Due to increased convergence time Same problem can apply to provider-independent (PI) addresses http: //www. juniper. net Copyright © 2003 Juniper Networks, Inc. 57

IPv 6 and The Multihoming Problem IPv 6 does not have a set solution to the problem u Currently, 6 Bone disallows IPv 4 -style multihoming (RFC 2772) u ISPs cannot advertise prefixes of other ISPs v Sites cannot advertise to upstream providers prefixes longer than their assigned prefix v u However, IPv 6 offers the possibility of one or more solutions Router-based solutions v Host-based solutions v Mobile-based solutions v Geographic or Exchange-based solutions v http: //www. juniper. net Copyright © 2003 Juniper Networks, Inc. 58

Multihoming Requirements for IPv 6 Site-Multihoming Architectures (draft-ietf-multi 6 -multihoming-requirements-03) u u u u Must support redundancy Must support load sharing Protection from performance difficulties Support for multihoming for external policy reasons Must not be more complex than current IPv 4 solutions Re-homing transparency for transport-layer sessions (TCP, UDP, SCTP) No impact on DNS Must not preclude packet filtering Must scale better than IPv 4 solutions Minor impact on routers No impact on host connectivity May involve interaction between hosts and routers Must be manageable Must not require cooperation between transit providers http: //www. juniper. net Copyright © 2003 Juniper Networks, Inc. 59

Possible Solution #1: Do Nothing u Allow Internet default free zone (DFZ) to continue to grow u Put responsibility on router vendors to keep increasing memory, performance to compensate Pros: • As simple as it gets • No special designs, policies, or mechanisms needed Cons: • Does nothing to increase Internet stability • Large routing tables = Large convergence times • No guarantee vendors can continue to stay ahead of the curve http: //www. juniper. net Copyright © 2003 Juniper Networks, Inc. 60

Possible Solution #2: GSE/8+8 GSE: Global, Site, and End System Address Elements (draft-ipng-gseaddr-00. txt) (draft-ietf-ipngwg-esd-analysis-05. txt) u Router-based u Key solution concepts: v Distinct separation of Locator and Identifier entities in IPv 6 addresses v Rewriting of locator (Routing Goop) at Site Exit Router v Identifier (End System Designator) is globally unique v DNS AAA and RG records http: //www. juniper. net Copyright © 2003 Juniper Networks, Inc. 61

Possible Solution #2: GSE/8+8 6+ Bytes Global Routing Goop (RG) ~2 Bytes 8 Bytes Site Topology Partition (STP) End System Designator (ESD) Identifier Locator RG 1 a SP 1 RG 1 Customer RG = Site Local Prefix Site Exit Routers rewrite RG for outgoing source, incoming destination addresses “The World” RG 2 SP 2 RG 2 a http: //www. juniper. net Copyright © 2003 Juniper Networks, Inc. RG 2 62

Possible Solution #2: GSE/8+8 u GSE as proposed rejected by IPng WG in 1997 v Thought solved to introduce more problems than it u “Separating Identifiers and Locators in Addresses: An Analysis of the GSE Proposal for IPv 6” (draft-ietf 0 ipngwg-esd-analysis-04. txt) v But, concept is still being discussed http: //www. juniper. net Copyright © 2003 Juniper Networks, Inc. 63

Possible Solution #3: Multihoming with Route Aggregation (draft-ietf-ipngwg-ipv 6 multihome-with-aggr-01. txt) Router-based solution u Customer site gets PA from primary ISP u PA advertised to both ISPs, but not upstream u PA advertised from ISP 2 to ISP 1 u Customer Site PA = pref 1: prefsite: : link 2 pref 1: prefsite: : http: //www. juniper. net Copyright © 2003 Juniper Networks, Inc. pref 1: : link 4 link 3 link 1 SP 1 (primary) pref 1: prefsite: : SP 2 pref 2: : “The World” pref 2: : link 5 64

Possible Solution #3: Multihoming with Route Aggregation u Pros: No new protocols or modifications needed v Fault tolerance for links 1 and 2 v Load sharing with ISPs 1 and 2 v Link failure does not break established TCP sessions v u Cons: No fault tolerance if ISP 1 or link 4 fails v No load sharing if link 3 fails v Problematic if link 3 must pass through intermediate ISP v Assumes ISP 1 and ISP 2 are willing to provide link 3 and appropriate route advertisements v http: //www. juniper. net Copyright © 2003 Juniper Networks, Inc. 65

Possible Solution #4: Multihoming Using Router Renumbering (draft-ietf-ipngwg-multi-isp-00. txt) Router-based solution u All customer device interfaces carry addresses from each ISP u Router Advertisements and Router Renumbering Protocol (RFC 2894) used u pref 1: prefsite: : SP 1 Customer Site PA = pref 1: prefsite: : pref 2: prefsite: : link 1 link 3 “The World” link 2 pref 2: prefsite: : http: //www. juniper. net Copyright © 2003 Juniper Networks, Inc. pref 1: : SP 2 pref 2: : link 4 66

Possible Solution #4: Multihoming Using Router Renumbering u If an ISP fails: Site border router detecting failure sends RAs to deprecate ISP’s delegated addresses v Router Renumbering Protocol propagates information about deprecation to internal routers v u Pros: No new protocols or modifications needed v Fault tolerance for both links and ISPs v u Cons: No clear criteria for selecting among multiple interface addresses v No clear criteria for load sharing among ISPs v Link or ISP failure breaks established TCP sessions v http: //www. juniper. net Copyright © 2003 Juniper Networks, Inc. 67

Possible Solution #4: Multihoming Support at Site Exit Routers (RFC 3178) Router-based solution u Links 3 and 4 (IP in IP tunnels) configured as secondary links u Primary and secondary links on separate physical media for link redundancy u Prefixes advertised over secondary links have weak preference relative to prefixes advertised over primary links u pref 1: prefsite: : link 1 link 3 Customer Site PA = pref 1: prefsite: : pref 2: prefsite: : SP 1 pref 1: : pref 2: prefsite: : pref 1: : link 5 “The World” pref 1: prefsite: : link 4 link 2 pref 2: prefsite: : http: //www. juniper. net Copyright © 2003 Juniper Networks, Inc. SP 2 pref 2: : link 6 68

Possible Solution #4: Multihoming Support at Site Exit Routers u Pros: v No new protocols or modifications needed v Link fault tolerance v Link failure does not break established TCP sessions u Cons: v No fault tolerance if ISP fails v No clear criteria for selecting among multiple interface addresses v No clear criteria for load sharing among ISPs http: //www. juniper. net Copyright © 2003 Juniper Networks, Inc. 69

Possible Solution #5: Host-Centric IPv 6 Multihoming (draft-huitema-multi 6 -hosts-01. txt) u Hostu Key and router-based solution Concepts: v Multiple addresses per host interface v Site exit router discovery v Site exit anycast address v Site exit redirection u New Site Exit Redirection ICMP message defined http: //www. juniper. net Copyright © 2003 Juniper Networks, Inc. 70

Possible Solution #5: Host-Centric IPv 6 Multihoming u u u Site anycast address indicates site exit address Site anycast address advertised via IGP Hosts tunnel packets to selected site exit router L bits 128 – L bits All Ones (1111……………………. . 1111) Site Prefix RTA Site Exit Anycast = pref 1: 1111…. 1111 SP 1 pref 1: : Customer Site PA = pref 1: prefsite: : pref 2: prefsite: : Site Exit Anycast = pref 2: 1111…. 1111 http: //www. juniper. net Copyright © 2003 Juniper Networks, Inc. SP 2 RTB pref 2: : 71

Possible Solution #5: Host-Centric IPv 6 Multihoming u Site redirection: Tunnels created between all site exit routers 2. Source address of outgoing packets examined 3. Packet tunneled to correct site exit router 4. Site exit redirect sent to host 1. RTA SP 1 Customer Site PA = pref 1: prefsite: : pref 2: prefsite: : Outgoing Packet pref 1: : ICMP Site Exit Redirect Site Exit Address = RTA Source Address = pref 1: prefsite: : int. ID http: //www. juniper. net Copyright © 2003 Juniper Networks, Inc. SP 2 RTB pref 2: : 72

Possible Solution #5: Host-Centric IPv 6 Multihoming u Pros: v Fault tolerant of link, router, and ISP failure v Overcomes problem of ingress source address filtering at ISPs u Cons: v Requires new ICMP message v Requires modification to both routers and hosts v Tunneling can become complex u Between site exit routers u Hosts to all site exit routers http: //www. juniper. net Copyright © 2003 Juniper Networks, Inc. 73

And Many Other Proposed Solutions… u Extension Header for Site Multihoming Support v (draft-bagnulo-multi 6 -mh. Ext. Hdr-00. txt) Host Identity Payload Protocol (HIP) u Exchange-Based Aggregation u Multihoming Aliasing Protocol (MHAP) u v u Provider-Internal Aggregation Based on Geography to Support Multihoming in IPv 6 v u (draft-van-beijnum-multi 6 -isp-int-aggr-00. txt) GAPI: A Geographically Aggregatable Provider Independent Address Space to Support Multihoming in IPv 6 v u (draft-py-mhap-01 a. txt) (draft-py-multi 6 -gapi-00. txt) An IPv 6 Provider-Independent Global Unicast Address Format v (draft-hain-ipv 6 -pi-addr-03. txt) http: //www. juniper. net Copyright © 2003 Juniper Networks, Inc. 74

Other IPv 6 Multihoming Issues u How does a host choose between multiple source and destination addresses? v See u How draft-ietf-ipv 6 -default-addr-select-09 are DNS issues resolved? v See RFC 2874, “DNS Extensions to Support IPv 6 Address Aggregation and Renumbering, ” section 5. 1, for DNS proposals for multihoming http: //www. juniper. net Copyright © 2003 Juniper Networks, Inc. 75