DREN IPv6 Implementation Update
Techs in Paradise, 2008
Jan 21, 2008
Honolulu, HI

Background
WAN provider for the DoD R&D community
Also serving as DoDÕs IPv6 pilot implementation of the DoD CIO June Õ08 mandate
Deploying IPv6 where possible in a production environment
See what works and whatÕs broken
See whatÕs missing
Share lessons learned

Previously
Reported to you previously:
Most serious problem is lack of IPv6 support in many security products (firewall, IDS, IPS, VPNs, web proxy, etc).
Major inhibitor to deployment of IPv6 in protected enclaves
Numerous bugs
 hurts deployment and require workarounds
Increased complexities with running dual-stack
Vista missing some v6 support
Some things getting better
Important fixes in key software components
Some incentives from Asian demands
The scare over RH0, now deprecated
Router meltdown
Proponents and providers arenÕt eating their own dogfood

WhatÕs new
Still finding bugs, but they are getting harder to diagnose
Increased campus deployment efforts
Expanded peering
Testbed downsizing
Tunnel brokers updated
www.v6.dren.net web site restored and updated
Moved to new server (virtual)
Fedora 7
Some cleanup and restructuring of content
DHPCv6 interoperability testing
Vendors still arenÕt eating their own dogfood

DREN IPv6 Testbed
Starting to shut down DRENv6 testbed
3 (of 9) Core nodes shut down
ERDC
NAVO
AFRL Kirtland
Moving Peering from testbed to production network
SPRINT
UUNET
NTT/Verio
É and others in the works

Slide 6
Peering
Upgraded all NIDS at peering locations to insure visibility of IPv6 traffic (security).
Renewed effort to improve peering
Production network only had 8 operational as of 2 months ago.
Move peers from testbed to production
Production network used testbed for transit to most peers.
Add new peers
UUNET (WAE and HAY)
TWAREN (Seattle, working on Starlight)
SPRINT (MAEwest)
NTT/Verio (vastly improved performance to Japan sites0
NLR (Seattle, MAEwest)
Hurricane Electric (WAE tunnel 1/22/08, MAE west cross connect being worked)
UH (last week)
HIX and LavaNet in the works
USGS (this week)
Qwest (working final draft of agreement)
Had to adjust policy
Waive requirement to peer at 3 locations
Waive requirement for high bandwidth native peering

Path from UH to DREN
Recent Frustrations
Products still not doing IPv6
Juniper NSM - slipped 18 months
Tipping Point - slipped 18 months
Bluecoat web/proxy - still no beta code, although promised a year ago
Bugs, bugs, bugs
Netscreen ND is broken
BIND sometimes stops responding when using IPv6 transport
Losing first packet breaks NTP
ping6 annoyance
É and more

Netscreen ND bug
Neighbor Advertisement
Switch loses first packet
Foundry BigIron will lose first packet after period of no activity

Losing first packet
Losing first packet: impact
NTP fails
Normally backs off to 1024 second updates
Single UDP packet sent on update
Client never sees packet, declares server down, and restart at 64 seconds, backs off, then fails again

ping6 annoyance
ping6 does a DNS lookup on EVERY packet
Bug in addrconf patch
The value was never copied to the cache

Expanded deployment
Many campus LANs now 100% IPv6 enabled
One site has achieved dual-stacking ALL desktops and servers (except 2)
Others have active programs to do the same, along with getting help desk trained and tooled for supporting it.
Remove ÒAÓ record from DNS for servers
Possible when all clients for that server are dual-stack
Servers running v6-only (no IPv4 address on any interface, nor on network it is connected to)
Fedora 7 - some manual fiddling of the config is required, but works
DNS issues (BIND sometimes stops responding when doing v6 transport queries)

Fedora 7 IPv6-only
Connect to IPv6-only LAN, so no cheating.
Configure from GUI, like any point-and-click sysadmin would do.
Getting it to actually workÉ
Manual hacking of ifcfg-eth0
Delete IPV6ADDR and IPV6PREFIX
Set ONBOOT = yes
Fix broken /etc/hosts
Configure sendmail to listen on ::1
Fix /etc/yum.repos.d/* files to point to an IPv6-capable mirror

IPv6-enablement milestones
and scoring (proposed)
IPv6 address allocation and address/routing plan developed
LAN (wired and wireless) is fully v6-enabled (all routers do v6 on all interfaces) and is connected to the IPv6 Internet (WAN).
The implication is that any v6-enabled device can connect anywhere in the LAN and get IPv6 Internet connectivity.
(worry about routing implementation, make sure address plan is right, think about security and performance, play with multicast, make sure network staff is trained to support it, etc)
Internal infrastructure services (DNS, NTP, DHCP, SMTP, etc) are IPv6-enabled
Public facing services (public DNS, MXs, public web site) are IPv6-enabled
Network management infrastructure (management LAN, SNMP, SYSLOG, MIBs, management access to switches/routers/etc) is IPv6-enabled
Most workstations and servers are v6-enabled
(behind this is the support infrastructure, i.e. help desk and other IT support, and a message to sys admins to turn on IPv6 where possible, and servers have AAAA records in DNS, and your help desk tools/scripts for things like host registration and update are upgraded to handle IPv6 addresses
Once critical mass is reached on the client side, remove "A" records for servers (resulting in final incentive and some pain for those that didn't dual-stack their workstations).
You don't need to do them all at once, just one at a time as their clients all become dual-stack
Migrate some network segments to IPv6-only, with no IPv4 addresses anywhere
(this forces one to figure out how to make hosts operate in a v6-only environment, helps the organization figure out what's missing, forces the implementation of some kind of transition mechanism to bridge to the IPv4-only world, plus adds continued incentive to get more stragglers upgraded since they can't even get there by typing the IP address
Deploy advanced features (mobile-ip, v6 multicast, etc.), provide remote IPv6 access (travellers, telecommuters, home, etc) from v4-only environments, cleanup and reduce complexity (readdressing network if necessary), ....
Declare victory
you claim a perfect score in public, and are willing to stand up to scrutiny

Commitment to IPv6?
Are network product vendors really committed to IPv6 support?
Are they using it in their production networks?
Do they have an IPv6 presence on the Internet?
Do they follow the Òeat your own dogfoodÓ principle?
A surveyÉ

Vendor scorecard
Looked in DNS to see if there were AAAA records for www, MX, and DNS.
Quick sampling of major computer and network companies showed no public facing IPv6.
6 months ago, and then today.

Scorecard – IPv6 Summit Sponsors (March Õ07)
Grand and Gold Sponsors of 2007 IPv6 Summit.
Only one has an IPv6 presence at their corporate Òfront doorÓ

Summary: Situation Today
DREN has been successfully using IPv6 in a production environment, with many dual-stack systems and services, for years
Modern operating systems just work, out of the box (MacOSX, Linux, Vista, Solaris 10, etc)
Most urgent needs from our perspective:
Need parity with IPv4 in all implementations
Enabling IPv6 must NOT break things
Need to make security stacks fully IPv6 capable
Firewalls, IDS, proxies, IDP/IPS, ACLs
Eat your own dogfood
The rest of DoD will not make the June Õ08 deadline.
The US is falling far behind Asia and other regions.
Prevalent attitude:  IPv6 just another GOSIP, or ADA, or É.
A call to action

END