Skip to main content

RSSAC Meeting, Minneapolis

RSSAC 17 @ IETF 58
Minneapolis, MN


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
Note takers: Bill Manning, Cathy Murphy, George Michaelson, Piet Barber, and John Crain

  1. ipv6/aaaa
  2. measurement and analysis
  3. reports from CAIDA/WIDE & partners
  4. bogus queries - CAIDA
  5. futures
  6. anycast
  7. security relations
  8. reports
  9. Tunisia
  10. ICANN admin
  11. secsac
  12. admin issues
  13. presentations @ icann
  14. other org activities
  15. publications/presentations
  16. 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 –
  • 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.


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 in all anycast services to facilitate measurement/performance

KC. – 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 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.



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

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



6:20 pm (CST) Meeting Adjourn

Domain Name System
Internationalized Domain Name ,IDN,"IDNs are domain names that include characters used in the local representation of languages that are not written with the twenty-six letters of the basic Latin alphabet ""a-z"". An IDN can contain Latin letters with diacritical marks, as required by many European languages, or may consist of characters from non-Latin scripts such as Arabic or Chinese. Many languages also use other types of digits than the European ""0-9"". The basic Latin alphabet together with the European-Arabic digits are, for the purpose of domain names, termed ""ASCII characters"" (ASCII = American Standard Code for Information Interchange). These are also included in the broader range of ""Unicode characters"" that provides the basis for IDNs. The ""hostname rule"" requires that all domain names of the type under consideration here are stored in the DNS using only the ASCII characters listed above, with the one further addition of the hyphen ""-"". The Unicode form of an IDN therefore requires special encoding before it is entered into the DNS. The following terminology is used when distinguishing between these forms: A domain name consists of a series of ""labels"" (separated by ""dots""). The ASCII form of an IDN label is termed an ""A-label"". All operations defined in the DNS protocol use A-labels exclusively. The Unicode form, which a user expects to be displayed, is termed a ""U-label"". The difference may be illustrated with the Hindi word for ""test"" — परीका — appearing here as a U-label would (in the Devanagari script). A special form of ""ASCII compatible encoding"" (abbreviated ACE) is applied to this to produce the corresponding A-label: xn--11b5bs1di. A domain name that only includes ASCII letters, digits, and hyphens is termed an ""LDH label"". Although the definitions of A-labels and LDH-labels overlap, a name consisting exclusively of LDH labels, such as"""" is not an IDN."