ICANN participation

RSSAC 17 @ IETF
58

Minneapolis, MN

Attendees:

Note takers: Bill Manning,
Cathy Murphy, George Michaelson, Piet Barber, and John Crain



Agenda:

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