RSSAC Meeting, Minneapolis
RSSAC 17 @ IETF
58
Minneapolis, MN
Attendees:
| Jun Murai | Gerry Sneeringer | Olaf Kolkman |
| Paul Vixie | Bill Manning | Ed Lewis |
| Steve Crocker | Suzanne Wolf | Daniel Karrenberg (telephone) |
| John Crain | K.C. Claffy | Rob Payne |
| Randy Runkles | Andrei Robachevsky | Yuji Sekiya |
| Ray Plzak | Cathy Murphy | Greg Ruth |
| Cathy Handley | Lars Liman | Kenjuro Cho |
| Brian Coppola | Rob Austein | Akiro Kato |
| Steven Perschas | George Michaelson | Neville Brownlee |
| Matt Larson | German Valdez | Mark Kosters |
| Piet Barber | Frederico Neves | Johan Ihren |
Agenda:
- ipv6/aaaa
- measurement and analysis
- reports from CAIDA/WIDE & partners
- bogus queries - CAIDA
- futures
- anycast
- security relations
- reports
- Tunisia
- ICANN admin
- secsac
- admin issues
- presentations @ icann
- other org activities
- publications/presentations
-
schedule
1. ipv6/aaaa - paul vixie
Some roots & tlds wish ipv6 transport – addresses are already assigned and in play – no formal process within ICANN to formally & safely add data. Over a year in the development process – we need to do testing in two or three independent labs to validate assumptions before recommending aaaa root support to IANA – expect to recommend by next meeting.
Daniel – not just about adding aaaa glue to roots, tlds want it also. – Kato/Paul paper has been augmented w/ work done by NLnetlabs and RIPE – published report. primarly looking at the additional section. sent to rssac on 14oct03, conclusion is that for nearly all tlds, five aaaa records will work. some will not. the summary – no technical reason for withholding addition request now for tlds.
Paul – our testing will focus on root issues, not tlds. tlds can safely add aaaa glue now.
Bill – we had talked earlier about testing up to eight aaaa records for root, is there any reason we do not test
for all 13?
Daniel – none, would be a good idea.
Crain – there are tlds in queue – two formal requests, as many as thirty have support now.
Cathy – DoC would really like the recommendation from rssac when iana sends in requests.
Daniel – would like rssac to make that recommendation today.
Jun will send in a two/three paragraph recommendation from rssac to icann on adoption.
Bill / Daniel will draft the cover letter.
Daniel – no preference assumption on glue in our report. We tested BIND-8, BIND-Current (9.2.2) and NSD
Jun – should have the report to icann no later than 02dec2003
2. Measurement
3. CAIDA - kc – here goes: (slides)
- workshops – second held last week @ ISI – next one held april 2004.
- no longer looking for "optimal location for roots"
- performance of systems / software for rssac and others using live data and simulations
- active and passive tools focused on servers – data does not correlate well.
- some look into resolver behaviour as impacts to roots
- some tools now but instrumenting anycast is hard
- more work needed on automation of configuration & management of systems
- clarification of assumptions is needed
Open issues:
- behaviour of resolvers towards the root/gtld servers –
- www.caida.org/~marina/UCSD/A_Sep03/index.html
- brad's proposed study of anycast effects
- monitor client distribution
- dnsstat info for 24hrs for all anycast nodes for a root
- compare/contrast client distribution among/between nodes
- how does the distribution compare w/ AS graph data
- instrument new site first….
- how long does it take to stabilize
- can we predict stable state?
- need anycast topology info from rssac !!!!
Johan – how to distinguish a new instance and a new peer?
KC – don't care.
Paul – we should notify measurement folks about peering changes.
Bill – routing stability is a concern.
This is a dynamic system and its hard – don't even know how to formulate the right questions.
It would be nice to have a dedicated set of meetings for working on this. may add an item to the next workshop for this.
We should review Duane's presentation for impact of resolvers on server performance.
(www.nanog.org/mtg-0310/pdf/wessels.pdf)
Bill - Interesting to see how resolver behavior effects the roots and other authoritative servers. May need to be more proactive in working with folks who design resolvers. Bill's bad idea put in servers to punish bad resolvers.
KC - v6 skitter coming, working with WIDE. skitter now is near end-of-life as-is. matthew @ waikato writing scamper, a possible replacement.
WIDE looking into performance differences v4/v6
Daniel – Would like to see something put in place to uniquely identify the server that is actually answering. - unique -structure so that can see if jumping between services at location and between locations implement server.id in all anycast services to facilitate measurement/performance
KC. – server.id draft? - Yes. Daniel – should be in the IETF :
Bind has the code, we should turn it on. - Rob – label nits and semantic issues have held up advancement, asks, why not use STATUS opcode?
Daniel – needs some ietf work – could not help w/ static measurement w/o doing edns type hacks
4. Bogus queries
Kato has the slides: the number of bogus queries to the M root server; many odd "tlds" generate significant and measurable traffic. add new top level domains with blackhole (AS112) name servers as the NS set; such as local, localdomain, localhost, the 0-255, etc. Such a request may need to be sent to ICANN from RSSAC.
Bill: Resolver behavior and the roots: interesting to see how caching affects the roots. This information will be useful in the future.
5. Futures:
- resolver impact
- caching impact
- Jun - need changes? if not, stay with this format of measurement activity
6. Anycast update:
- A – no plans
- B - by Nov2003
- C - two new sites – all inside Cogent
- D - six months or more
- E – hard – no plans
- F - 13 sites now
- G - future plans, no dates
- H - no plans
- I - four cities – had to change AS as well.
- J - 11 sites now; still no peering, but transit, still thinking about it – five planed
- K - Two now, adding 10 within the next 5 months; anycast introduced a new AS number.
- L - no plans so far
- M - is in two sites; two different exchange points, plans to go to Seoul.
(see www.root-servers.org for details)
Paul - v4 RFC describes anycast accurately
Steve C – any thoughts on SEasia, Africa, latin America?
Bill - Yes, in all of those sites and others too.
The IPv6 RFC 2373 has two unfortunate paragraphs about how to announce anycast addresses: you can’t announce an anycast route unless you’re an anycast router. (draft standard)
Paul – F is in violation of section 2.6 now.
Bill - there will need to be new language to correct/clarify?
Rob - yes. other parts of RFC 2373 are being challenged as well.
Kato: Itojun has a document that clarifies ipv6 anycast.
Meetings@ICANN
Tunisia
Suzanne – GAC/IPv6 – glad things are emerging, Anycast, ICANN Board look forward to more reports. Was asked about DNSSEC. Answer was that we are in a testing phase, leading to recommendations. (see www.rs.net)
John C. – ICANN update was on AAAA activity, not much more.
Bill – ICANN constituents would like rssac to meet w/ ICANN.
Jun - Invite GAC rep info? like we did with secsac? In future meetings?
SECSAC / testing monitoring – Steve Crocker
Slides: Intriguing Observation on stability of root-ops – does/can this model apply elsewhere?
7. Security relations… when will dnssec be deployed?
There are still roadblocks, past IETF work may impede deployment. there are other hurdles after the IETF standards are settled. ISC indicates new code will be quickly forthcoming once IETF work is settled. The www.rs.net testbed is testing key management issues.
Administrative issues
Presentation at ICANN meetings
Meeting conflicts ICANN/Rome and IETF/Seoul - set up webcast? Who will make arrangements?
Bill – I've done the IETF section, may be willing to do the Rome location as well.
RSSAC on Sunday before IETF in Seoul 4pm is 8am Rome (9am?) -- List discussion depending on how it goes.
GAC meeting is Sun-Mon-Tue; last meeting, RSSAC joint meeting was on Sunday.
DoC will check on conflicts and try to mitigate.
Other organizational activities
Publications/Presentation
Schedule
6:20 pm (CST) Meeting Adjourn