IPv6 Testbeds Testing IPv6-only configurations

gogoNET LIVE! 3 13 Nov, 2012 San Jose, CA

Ron Broersma DREN Chief Engineer

SPAWAR Network Security Manager Federal IPv6 Task Force

ron@spawar.navy.mil

Purpose of a Testbed

•  Test new products and capabilities without breaking your production network

•  To test how well equipment supports IPv6 •  To serve as a learning environment •  Experiment with various configurations

13-Nov-2012 2

Are IPv6 testbeds still a necessity?

•  Rarely –  IPv6 on mainstream switches, routers, and

operating systems works well, and won’t break your production network.

–  Implementing IPv6 on production networks can be done incrementally, in ways that will not impact operations.

•  But testbeds are needed where you know things might break –  IPv6-only environments

13-Nov-2012 3

Easy Testbeds •  “Learning” testbed – Your Home Network

–  IPv6 capable home router plus HE tunnel. –  take the HE IPv6 certification.

•  Parallel infrastructure –  e.g. IPv6 firewall next to production firewall

•  “Test” subnet on production network –  on a separate VLAN –  or over wireless on separate SSID

•  Existing isolated network •  Tools: dumb hub, wireshark, RFCs, IPvFoo,

IPvFox, Little Snitch, etc.

13-Nov-2012 4

Some IPv6-only Experiments

•  IPv6-only Management LAN •  Client environments

– pure IPv6-only –  IPv6-only + NAT64/DNS64

•  IPv6-only Server farm

13-Nov-2012 5

IPv6-Only Management LAN

Management LAN

•  Can you do all your network management using IPv6?

•  Can you turn off IPv4 on your management LAN?

•  How well do various products operate in this environment?

13-Nov-2012 7

Findings •  Very few products can be fully managed using

IPv6 •  You won’t learn what’s missing or broken unless

you try it in production –  remove the training wheels, and live on it

•  Bugs take 6 to 12 months to get fixed •  Feature requests take 18 to 48 months to get fixed •  You can’t turn off IPv4 completely (yet)

–  always some devices with no IPv6 •  T-1 and DSL bridges, microwave radios, old dialup and VPN

servers, ATM switches, cameras, etc.

13-Nov-2012 8

Previously (June ‘2011):

Management over IPv6 in some products

13-Nov-2012

SSH HTTPS

DNS Syslog SNMP NTP RADIUS Unified MIB RFC4293

Flow export

TFTP FTP

CDP LLDP

IPv6 MTU

No v4

Cisco3 6

Brocade1 9

Juniper 5

ALU 4

A10 8 7

SSH HTTPS

DNS Syslog SNMP NTP RADIUS Unified MIB RFC4293

Flow export TFTP FTP

CDP LLDP

Cisco

Brocade

Juniper

Now:

1.  Can’t reboot using SNMP over IPv6 2.  . 3.  15.2(2)TR 4.  10.0R6 (Nov 2012) 5.  12.3R1 Nov 2012 (beta in August) 6.  ASR1K:3.7S (July 2012) 7.  3.0 release, 2012Q4 8.  No plans 9.  fix planned for Apr 2013

9

Example of an IPv6-only bug (recently fixed)

•  when disabling IPv4 on Brocade FESX switches, they start responding to all ip-subnet-broadcasts, and start ARPing (from 0.0.0.0), and other strange behaviors.

•  Example: echo request to x.x.x.255/24:

13-Nov-2012 10

IPv6-only client networks

IPv6-only client network •  My test environment:

–  enterprise sub-network with ONLY IPv6 turned on (no IPv4 configuration or routing)

•  “A” bit enabled (SLAAC) •  “M” and “O” enabled (for DHCPv6)

–  delivered over wireless on SSID “IPv6 Only”, and on separate wired VLAN.

–  DHCPv6 service –  Many operating systems connected, to see how they behave

•  Windows, MacOSX, Linux (multiple distributions), FreeBSD •  iPhone, iPad, Android

•  Anything without a dhcpv6-client won’t get DNS addresses –  Windows XP, MacOSX before Lion, Android

13-Nov-2012 12

IPv6-only •  Observation (MacOSX Lion):

–  You can browse OK with Safari, but Chrome and Firefox hang when trying to browse to IPv6-only web sites

•  happy-eyeballs not working –  tcpdump shows it ARPing for Internet addresses –  … because there is a default-route-to-interface installed in the routing

table –  … because it assigns IPv4 link-local (RFC 3927) and implements “ARP

for everything” (paragraph 2.6.2) –  … so it “thinks” it has full IPv4-internet reachability (unlike IPv6

behavior) •  Most other OS’s exhibit similar behavior •  Work-arounds?

13-Nov-2012 13

IPv6-only + NAT64/DNS64

•  Add NAT64/DNS64 to previous experiment – maps entire IPv4 Internet into 64:ff9b::/96 – DNS64 server maps the addresses on the fly – NAT64 provides stateful v6/v4 translation

•  Yes, NAT is evil, but here the breakage is local to your NAT64 domain. – may be a viable means to reduce OP-EX of

dual-stack

13-Nov-2012 14

IPv6-only + NAT64/DNS64

13-Nov-2012 15

IPv6-only + NAT64/DNS64

•  Most things actually work pretty well •  Things that don’t work

–  sites with broken IPv6 (won’t fall back to IPv4) •  e.g. www.ntia.doc.gov

– web sites and apps with embedded IPv4 literals –  skype, games, P2P, some IM

•  Read RFC 6586 for detailed experiences •  Watch the IETF “Sunset4” working group

–  http://tools.ietf.org/wg/sunset4/

13-Nov-2012 16

IPv6-only servers

IPv6-only servers •  Scenario #1 – weaning

–  run server as dual-stack –  when client base is (mostly) IPv6-enabled, remove

the “A” record from DNS –  works well for corporate Intra-nets that are largely

dual-stack –  great incentive for stragglers to IPv6-enable their

clients –  helps network administrators find the stragglers and

special cases, without totally breaking things. –  IPv4 is still there as a fall-back for special cases,

using explicit IPv4 address. •  Intranet users coming in over IPv4-only VPNs.

13-Nov-2012 18

IPv6-only servers •  Scenario #2 – remove training wheels

–  run server as IPv6-only (IPv4 disabled) –  do this when all issues in Scenario #1 are

resolved. – works in Intranet environment, not when Internet

access is required. •  see next scenario

•  Scenario #3 – legacy IPv4 reachability –  use a dual-stack reverse proxy or LB –  use SIIT (RFC 6145)

•  read draft-anderson-siit-dc-00

13-Nov-2012 19

END

Contact me: ron@spawar.navy.mil