Building an IPv6 Test Lab by Ron Broersma at gogoNET LIVE! 3 IPv6 Conference

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

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

Management over IPv6 in some products
Previously (June ‘2011):
SSH DNS Syslog SNMP NTP RADIUS Unified MIB Flow export TFTP CDP
HTTPS RFC4293 FTP LLDP
Cisco

Brocade

Juniper

Now: SSH DNS Syslog SNMP NTP RADIUS Unified MIB Flow TFTP CDP IPv6 No v4
HTTPS RFC4293 export FTP LLDP MTU
Cisco3 6

Brocade1 9

Juniper 5

ALU 4

A10 8 7

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
13-Nov-2012 8.  No plans 9
9.  fix planned for Apr 2013

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


13-Nov-2012 15

•  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
•  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

Building an IPv6 Test Lab by Ron Broersma at gogoNET LIVE! 3 IPv6 Conference

Recommandé

Recommandé

Contenu connexe

Dernier

Dernier (20)

En vedette

En vedette (20)

Building an IPv6 Test Lab by Ron Broersma at gogoNET LIVE! 3 IPv6 Conference