North American Network Operators Group|
Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical
NANOG36-NOTES 2006.02.15 talk 1 ipv6fix (and boy, does it need it)
Morning intro notes--don't forget to fill out
six lightening talks signed up, should be very
cool. If you have slides, get them to Steve
Feldman start with!
Wireless movie after break should be cool to watch.
Ren? Steve mistakenly introduces her, she corrects
them. Don't forget to give feedback via the Survey
2006.02.15 v6fix: Wiping the Slate Clean for IPv6
Kenjiro Cho, WIDE/IIJ, Ruri Hiromi, WIDE/Intec NetCore
Will be talking about their efforts to deploy
IPv6, called v6fix.
v6fix is an effort to solve problems in the current
focuses on v4/v6 dual stack environments.
it's a technical analysis of real world problem
Kenjiro will talk about tools and measurements.
majority of equipment out there is v6 available
from major vendors
still many applications and appliances just work
v6 is starting to get into various business fields
Many people lack knowledge/experience with v6.
when non-experts hit problems, they're clueless.
Hotel internet systems have instructions for guest.
troubleshooting: if you have IPv6 enabled, please
disable IPv6--brochure in guest room.
Cause of problem: combination.
DNS redirection returns specific A record for AAAA
clients stub-resolver accepts the A for AAAA, can't
Wiping the slate clean for the v6
faulty behaviours only 1% and combinatorial often, but
could be fatal to deployment.
slow fallback to v4 after v6 errors
misbehaving DNS resolvers
filtering of ICMPv6
poorly configured tunnels
lack of peering or v6 paths
v6fix activities (research group)
identify/analysze/solve real-world tech problems
in v6 deployment.
Enemy: "after disabling v6, my problems went away"
Cooperation needed between researches, implementers, ops.
harmful effects of the on-link assumption.
misbehaving DNS servers and resolvers
slow fallback to v4 after v6 failures
case 1: DNS loop at hotel
real story of hotel internet system--went to same room,
DNS is intercepted, redirected to signup page
ipv6 users can't get beyond first page
hotel instructions say to disable v6
erroneus DNS redirection system and stub-resolver
redirection system always returns specific A record
when getting non-A queries
client's stub resolver queries AAAA for any address,
blindly accepts A return response.
case 2: DNS server slowdown
ISP upgraded a DNS cache to BIND9, recieved complaints
recompiling BIND9 with --disable-ipv6, fixed problem,
reported to JANOG
Caused by older BIND9 w/o IPv6 connectivity
server w/o v6 connectivity always tries to talk over v6,
ends up failing back to v4 after timeouts
fixed in BIND9.2.5 and 9.3.1
1 problems appear only with specific combinatorial conditions
2 implementors and operators didn't notice until reported
3 even for professionals, not easy to track down problems.
Kenjiro Cho, Tools:
v6 tools and measurement results
Goal: to understand the macro-level v6 healthiness
wide area meaasuremetn of behaviours of 2nd/3rd level
dual stack issues
DNS server measurements of .jp domain
AAAA responses: 0.13% DNS servers can't deal with
Most are lame delegation type errors.
ignore AAAA queries
respond with RCODE 3 ("name error") NXDOMAIN
dual-stack path analysis
measurement techniques specifically designed for
take measurements for v4 and v6 at same time
compare v6 results with v4 results
extract problems that exist in v6 only
dual-stack node discovery
create dual-stack node list by monitoring DNS AAAA replies.
dual stack ping
run ping/ping6 to target dual-stack nodes
select a few representative nodes per site (/48) by RTT
trace/trac6 to selected nodes
visula v6 MTU to look at issues
visualize path issues
distribution of v6/v4 RTTs
4000 ping targets v4 on x-axis, v6 on y axis
individual nodes far above unity line--leaf issues
paths and PMTU visualization
from NYSERNET to ARIN sites
Many of ARIN paths via jp! (lack of peering)
>From ISC to ARIN sites--paths look much better, but
lots of blue == lots of tunnels
Abilene case: well known problem.
Abilene trying to encourage v6 adoption
no AUP, tunnel services for v6
but ended up with horrible v6 paths, mostly with tunnels
ISPs are reluctant to move to paid v6 connectivity
Abilene thinking about suspending its relaxed AUP for v6
tool tries to illustrate such issues, convince users to
move to native v6
dual stack traceroute to ABILENE from WIDE (v4 upper,
similar RTTs/hops for v4/v6; native dual-stack paths
dual-stack trace to ABILENE from IIJ
similar RTTs, but different paths: currently more common
dualstack traceroue to ABILINE fro ES
v6 RTTs much larger than v4: roundabout tunnels
Conclusion: faulty behaviours are only 1% and often
combinatorial, but can be fatal to acceptance of v6
slow fallback to v4 on v6 errors
need to realize the dangers of harmful of adoption of v6
cooperation among researchers, implementers, and ops
need to act now, or will bring negative impact to v6
v6fix members, etc.
overview, documents, and fact database.
contact at v6fix.net
reports of issues are welcome