From Event to Action: Accelerate Your Decision Making with Real-Time Automation
IPv6 Implementation and Migration
1. IPv6 on the INTEROPNET
Interop, Wednesday, 3 October 2012
Brandon Ross, Routing Team Lead
Jeff Enters, WW IPv6 Portfolio Manager, HP
Aaron Hughes, CTO, 6connect
Chief Network Architect, Network Utility Force
http://www.netuf.net/
2. Agenda
• Background and Goals
• How IPv6 works on the InteropNET
• Subnetting and Addressing
• Challenges and Lessons Learned
• Results and Statistics
• Conclusions
3. RFC 6540
• Are you aware of this requirement?
• Are your nodes IPv6 capable?
4. IPv6 Support Required for All IP-
Capable Nodes – RFC 6540
• “Given the global lack of available IPv4
space, and limitations in IPv4 extension
and transition technologies, this document
advises that IPv6 support is no longer
considered optional.”
• “IPv6 support must be equivalent or better
in quality and functionality when compared
to IPv4 support in a new or updated IP
implementation.”
5. Background
• IPv4 depletion is already occurring
• IPv6 adoption is accelerating
• Most network hardware supports IPv6
• For the most part, dual stack Just Works
IPv6 Routing Table Growth
IPv4 Free Pool Depletion
http://www.ipv6actnow.org/info/statistics/#alloc http://www.potaroo.net/tools
6. US Feds Lesson Learned
The US federal government had a mandate for all public facing web
services to support IPv6 by September 30, 2012.
287 of 1494 sites had IPv6 web support by the deadline.
That’s nearly 20%. Not 100%, but far
ahead of most other large organizations.
Source: http://usgv6-deploymon.antd.nist.gov//
7. Europe out of Free Pool
• Asia (APNIC) effectively ran out of free
addresses in April, 2011
• Europe (RIPE) is also out of addresses as
of September 14th
• ARIN predicted to run out of free space in
August (Geoff Huston,
http://www.potaroo.net/tools/ipv4/index.ht
ml)
8. Goals
• Network must be fully dual stack
(IPv4+IPv6)
• All IPv4 services should be reachable over
IPv6
• Connections to IPv6-enabled websites
should use IPv6 by default
• Nothing should break ☺
9. Agenda
• Background and Goals
• How IPv6 works on the InteropNET
• Subnetting and Addressing
• Challenges and Lessons Learned
• Results and Statistics
• Conclusions
11. Autoconfiguration
• All client-facing networks use SLAAC to
allow clients to auto-assign themselves an
IPv6 address and default gateway on the
correct subnet
– Supported by all IPv6-capable devices
Auto-assigned
IPv6 address
Default Gateway
(Link-local from RA)
12. DNS
• All DNS services are provided by DynDNS
and load-balanced by F5
• In order to connect to Google and
Facebook over IPv6, we had to ask them
to whitelist the InteropNET DNS servers
– As a result, DNS requests for google.com and
facebook.com receive AAAA (IPv6) responses
13. InteropNET NOC Services
• Goal was to provide all internal services
over IPv6 as well as IPv4
• This required coordination with vendors to
enable IPv6, make sure services were
bound to their IPv6 ports, and publish
AAAA records
• Most (but not all) services ended up
reachable over IPv6
14. Wireless
• InteropNET wireless is provided by Xirrus
• Purpose-built VLANs are shared across all
APs and all are dual-stack
17. Agenda
• Background and Goals
• How IPv6 works on the InteropNET
• Subnetting and Addressing
• Challenges and Lessons Learned
• Results and Statistics
• Conclusions
18. State of Assignments
• All of the registries, for the most part,
assign initial blocks for
Service provider /32
Enterprise /48
19. What makes up a good
addressing plan?
• Depends on the type of network, the size of
the network, and problem to be solved
• Points to consider
Documentation
Ease of troubleshooting
Aggregation
Standards compliance
Growth
SLAAC
Existing IPv4 addressing plan
Human factors
20. Algorithmic Approach
• Encode every IPv4 address in the network
in an IPv6 address
10.10.10.10 (A0A0A0A)
2001:DB8:A0A:A0A::
21. Link Numbering Issues
• OSPFv3 masks this problem, unlike in IPv4
• Separation of addressing from the link state
database means that OSPFv3 neighbor
relationships will establish, even on links with
mismatched addressing and/or masks
• Link-local based forwarding prevents address
mismatches from being easily detected
because traffic flows normally and
traceroutes don’t appear too strange
22. Link Numbering Issues
• To detect link numbering errors, look for “Uturn” routing:
$ traceroute6 2620:144:B0C::
traceroute to 2620:144:B0C:: (2620:144:b0c::), 30 hops max, 80 byte
packets
1 2620:144:8fc:: (2620:144:8fc::) 26.747 ms 26.730 ms 26.716 ms
2 2620:144:b0c::2 (2620:144:b0c::2) 29.137 ms 29.222 ms 29.264 ms
3 2620:144:8fc:: (2620:144:8fc::) 29.355 ms 29.335 ms 29.350 ms
4 2620:144:8fc:: (2620:144:8fc::) 29.438 ms !H 29.433 ms !H
29.413 ms !H
Note hop 2 is the misnumbered address. This traceroute should have
looked like this:
$ traceroute6 2620:144:B0C::
traceroute to 2620:144:B0C:: (2620:144:b0c::), 30 hops max, 80 byte
packets
1 2620:144:8fc:: (2620:144:8fc::) 32.473 ms 32.447 ms 32.427 ms
24. Link Numbering Issues
• Should you number your links at all or just
use link-local?
• Loopback interfaces usually show up so
you know which routers traffic is following,
so why waste address space on links?
25. Link Numbering Issues
• Using equal cost multipath?
• $ traceroute6 2001:DB8::5:2
• traceroute to 2001:DB8::5:2 (2001:DB8::5:2),
30 hops max, 80 byte packets
• 1 2001:DB8::6:1 (2001:DB8::6:1) 22.723 ms
26.730 ms 26.716 ms
• 2 2001:DB8::1:1 (2001:DB8::1:1) 80.233 ms
* ms 72.173 ms
• 3 2001:DB8::5:2 (2001:DB8::5:2) * ms
99.223 ms 29.350 ms
• Which link did it take?
26. Link Numbering Issues
• Does your management system use link numbering for
monitoring or circuit identification?
• Are you really saving any significant addressing by not
assigning addresses?
27. Link Numbering Issues
• $ traceroute6 2001:DB8::5:2
• traceroute to 2001:DB8::5:2
(2001:DB8::5:2), 30 hops max, 80 byte
packets
• 1 2001:DB8::6:1 (2001:DB8::6:1)
22.723 ms 26.730 ms 26.716 ms
• 2 2001:DB8::4 (2001:DB8::4) * ms
88.322 ms * ms
• 3 2001:DB8::5:2 (2001:DB8::5:2) *
ms 90.123 ms 100.110 ms
• Better, now we know which link is having issues.
28. Standards Compliance
Networks smaller than /64 can be desirable,
especially using /127s for point to point links
(RFC 6164)
To avoid future breakage, allocate a /64 in your
documentation but use the smaller block
Similarly, reserve /48s for EVERYTHING you
can, there’s no reason to allocate densely,
there’s plenty of space
If you have a complex network, allocate in a
sparse way to enable easy aggregation
29. Addressing and Subnetting
Recommendations
• You can indeed add convenience and save
on documentation by using an algorithmic
approach
• But ONLY if you have reasonably few IPv4
blocks, if you have 100s, you’ll probably need
a different approach unless you can get a
large enough v6 allocation
• You DON’T want to reproduce IPv4 “cruft”
into IPv6. If your IPv4 subnetting is a mess,
it’s best to re-do it for IPv6.
30. Agenda
• Background and Goals
• How IPv6 works on the InteropNET
• Subnetting and Addressing
• Challenges and Lessons Learned
• Results and Statistics
• Conclusions
31. DUID
• When a Windows machine is cloned, you can get
two or more machines with the same DHCPv6
Unique IDentifier (DUID)
• This DUID is used by the DHCPv6 server to
identify the client, so when two clients with the
same DUID request IPv6 addresses with DHCPv6,
they will both be given the same address
• When the second machine receives its address
from the DHCPv6 server, it does IPv6 Duplicate
Address Detection, determines there is an IP
address conflict, and refuses the lease
32. Rogue RAs
• When a client is configured to run 6to4 (an
automatic tunneling protocol) and Internet
Connection Sharing, it will advertise itself as an
IPv6 router by sending out RAs on its wireless
interface
• Clients receiving such RAs will auto-assign
themselves an address in the wrong subnet
• Routers are generally configured with RA guard or
equivalent on their wired ports
• Unfortunately there is no way to block rogue RAs
over wireless APs (and some wired switches)
33. Agenda
• Background and Goals
• How IPv6 works on the InteropNET
• Subnetting and Addressing
• Challenges and Lessons Learned
• Results and Statistics
• Conclusions
34. Usage Statistics – Internet Traffic
• IPv6 usage on averaged 3% of total traffic
• That’s up from 2% of Interop’s traffic last year
36. Usage Statistics – By Type
Most traffic is HTTP, probably not a
surprise.
How much of that is peer2peer hiding in
port 80?
37. Usage Statistics – interop.com
• Users inside the InteropNET preferred IPv4
to reach www.interop.com .
• 29 GB delivered over IPv6
• 18 GB delivered over IPv4
• Possibly lower than previously due to Happy
Eyeballs
38. Agenda
• Background and Goals
• How IPv6 works on the InteropNET
• Subnetting and Addressing
• Challenges and Lessons Learned
• Results and Statistics
• Conclusions
39. Conclusions
• IPv6 works in the real world
• Over 60% of Interop attendees were using
IPv6 to reach interop.com without even
knowing it
• There are challenges to implementing IPv6,
but nothing show-stopping
• About 3% of the Internet’s content is
reachable over IPv6 (and growing fast)
• A much smaller percentage of Internet users
have IPv6 connectivity (though this may
change quickly with IPv4 depletion)
40. Today’s Reality
World IPv6 Launch
Facts
• There is a proliferation of IPv6 enabled mobile devices,
appliances, home networks, etc.
• Content is NOW served over IPv6
• More and more users are operating in an IPv6 world
UNKNOWNINGLY!
- AND these users are having a better Quality of Experience
• Companies that have not deployed IPv6 can’t get to these
users and these users can’t get to them over IPv6
IPv6 adopters have a distinct competitive advantage!
Don’t be shut out !
IPv6 is INEVITABLE!
41. Vote for Me!
AC – Advisory Council
“The Advisory Council serves in an advisory capacity to the
Board of Trustees on Internet number resource policy and
related matters. Adhering to the procedures in the Policy
Development Process, the Advisory Council forwards
consensus-based policy proposals to the Board for ratification.”
Voting from October 24th-November 3rd
Election HQ site:
https://www.arin.net/app/election/
42. Learn More!
• http://www.getipv6.info/
• http://tunnelbroker.net/
• http://www.sixxs.net/
• http://www.ipv6ready.org
• https://www.arin.net/knowledge/ipv6_info_center.ht
ml
• Contact us:
– Brandon Ross,
– Chief Network Architect and CEO
– Network Utility Force
• bross@netuf.net +1-404-635-6667