(ngtrans) DNSEXT NGTRANS Joint meeting DRAFT minutes

[Olafur Gudmundsson <[e-mail]>]

DNS-EXT/NGTRANS joint meeting on 
How to represent IPv6 addresses in DNS

IETF-51, London - 6 August 2001
Olafur Gudmundsson, Alain Durand & Tony Hain chairing

Minutes by: Bob Fink, David Lawrence, Jun-ichiro itojun Hagino
(thanks for great minutes) Edited by Bob Fink and Olafur Gudmundsson

This is draft minutes, please send edits/corrections for final minutes 
before 23:00 London time  Thursday (2001/08/09) to [e-mail]

-----

Agenda

 Introduction (2 min) - Olafur
 Bit labels (5 min) - Alain
 DNAME use in reverse IPv6 tree (5 min) - Alain
 AAAA vs A6 (60 min) - Alain
 Consensus building (40 min) - Tony
 Summary (8 min) -Olafur

----- 
Short names: Full names 
Alain	     Alain Durand
Bob	     Bob Hinden
Christian    Christian Huitema
Erik	     Erik Nordmark
Itojun	     Jun-ichiro itojun Hagino
Matt	     Matt Crawford
Olafur	     Olafur Gudmundsson
Perry	     Perry Metzger
Randy	     Randy Bush
Rob	     Rob Austein
Steve	     Steve Deering
Thomas	     Thomas Narten
Tony         Tony Hain



Introduction

Olafur explained that the meeting goal is to find rough consensus on
how to go forward with representation of IPv6 addresses in DNS. 

The meeting output will be an ID summarizing the meeting consensus,
which will be taken to the appropriate mailing list(s). 
 
----

Bit labels - Alain

Are bit labels necessary in IPv6 DNS reverse tree, and is anybody
planning to delegate on the last 4 bits? 

Matt Crawford stated that Bit Labels are not necessary if you are
willing to do the delegation hack on non-nibble boundaries. 

Rob Austein explained that the last 4 bits meant a /125 or larger.

There was no response from the floor to the questions posed by Alain.

Andrea Gustafsson asked for someone to clarify why last 4 bits are special.

Randy Bush explained that the issue is allocations in the last label
when using a text-based name format in the reverse tree.  In
IN-ADDR.ARPA that means allocations in the last octet; in the text
based version of IP6.ARPA (nibbles, not bitlabels), that means
allocations in the last nibble.

Being there was no discussion, Alain moved on.

--
DNAME use in reverse IPv6 tree

-
Do we need DNAME in the IPv6 reverse tree?

Alain noted that other DNAME uses were out of scope for the discussion.

Christian noted that if you really want renumbering on fly, DNAME is
needed, thus it follows the decision on need for A6. 

Matt Crawford noted that there is value in forward tree, even if not
in reverse tree. 

Michael Patton said that we if we do A6, require DNAME in reverse
tree, but if AAAA only, there is some value. 

Matt said that DNAME can be used to keep reverse map in the same zone
as direct map. 

Alain asked if this was still true if there were only AAAA and no A6.

Matt said yes.

Olafur summarized that, given the limited defense of DNAME it was a
DNS decision on whether other uses of DNAME justified it. 

---
AAAA vs A6

-
Does anybody have any other application that requires A6, that can not
be done by back-end processing and are not covered by
draft-ietf-dnsext-ipv6-dns-tradeoffs-00.txt? 

Christian noted a point only partially covered by Rob's ID. Assumption
is a db with all systems listed. There are schemes where hosts push
addresses to db and when renumbering, there are individual decision
that 1000's of hosts could to update the DNS with. 

Perry Metzger stated that if one does the db right, then tools can do
it cleanly, no special protocol hacks are needed. We only think not
due to lack of tools. It's only a SMOP :-), like MOIRA (sp) at MIT. 

Matt Crawford noted that this still relies on tools not yet
written. A6 buys ability to register as single RR in db for all
prefixes as it goes. 

Perry understands desire, but believes tools are needed, and for more
than A6. 

Jim Bound asked if, assuming backend processing (with better tools
than we now have), to evaluate if A6 make it more efficient, and thus
worth implementing in this context. 

Olafur said, yes, a natural representation in db looking something
like A6, would help. 

Jim Bound responded if we then agree, lets focus in the direction A6
points. 

Bill Sommerfield - I worked on MOIRA (sp) at MIT (that Perry mentioned
as example) and I don't think that is for all sites. Wrong to force on
all sites where model might not fit. 

Matt Crawford noted that missing from questions is, we focus on
"today", not if it is needed in future. E.g., changes in routing
system might need A6. 

-
Is IPv6 going to do rapid renumbering or GSE-like routing?

Bob Hinden asked if hourly or daily likely? Weekly/monthly most
likely, i.e., not all that rapid. Rapid renumbering was not an
original (or even current) goal for IPv6. 

Tony GSE is a "per packet" renumbering

Matt Crawford noted that there was lots of discussion for minimal
allocation size (i.e., the /48 issue). There are other ways for a
body/system to move that might require rapid renumbering. One can't
say for sure rapid renumbering won't be needed, and thus A6. 

Margaret Wasserman asked if we ware talking automated renumbering or
not. 

Rob stated that if IPv6 going to do automated renumbering frequently,
that quad A can't cope with it, even with better tools, due to issues
like resigning time 

Christian noted there are scenarios with several prefixes: e.g., one
might toggle between them on a daily basis or faster. 

Christian felt that for fire exit usage, if renumbering not used often
(to check that it works) it would never be used. 

Steve Deering felt that many sites will have to renumber enough to know
protocol (and implementations) work. 

Christian noted that the argument on renumbering seems to be gated on
resigning. He is not convinced that we can't do security right. 

Steve stated that on issues other than security, an important goal
with IPv6 is to make renumbering easier, but to make it occur very
fast is unsolved, for more than just DNS records. Thus if we do rapid
renumbering, it will be a very different architecture, e.g., GSE, and
it is likely that it would keep site ignorant of changes and thus A6
wouldn't help. 

Ted Hardy asked if there are there applications for rapid renumbering,
that happen faster than route propagation, that fall under
multi-homing. Renumbering that happens faster than route propagation 
won't work. 

Alex K (?) asked if we know what the future is. IPv6 will be used in
new applications beyond our current Internet, and who knows what these
uses are. Choice is either put A6 flexibility there for the future, or
stop developing A6 now and invent something new in future. 

Jim Bound agreed w/Steve that one can't guarantee rapid
renumbering. A6 is a tool that underwent significant development and
that it is an abstraction like scoping, multi-casting, that adds
quality to the IPv6 architecture. Users will need renumbering to adopt
IPv6. 

Perry asked at what costs. DNS queries are under fire for getting
slower. Confident that he could renumber in hours or days, but
probably not faster. It does work with AAAA, though he admitted his
experience was for a small site. 

Randy noted that the problem with doing A6 for possibility of rapid
renumbering is following dreams, not reality. To get v6 traction, A6
not helping. 

Jim Bound agreed with Randy, but would like to see if A6 0 would work
and do testbeds to see what works. Concerned that the code base (we
now have) might be useful might be thrown away before we learn from it.

Simon Leinen noted that the performance issues are not straight
forward. A6 request might be handled faster than AAAA, when host has
many addresses. 

Matt Crawford asked do you think we can deploy A6 later on and really
get it deployed? 

Randy noted that playing with A6, IPv6 folk are maintaining their code
better than v4 folk may be. If we do renumbering it is analogous to,
"do we do the routing thing". A6 is a solution to a problem we haven't
yet defined, and constrains our solutions in future. Rather solve our
problems and solve DNS stuff after. 

Matt Crawford asked again if we can make a change in the future like that?

Thomas Narten asked, if we do rapid renumbering, are other changes
needed? Then couldn't putting in changes for DNS be done too? 

Steve Deering noted that we have AAAA, and going to A6 0 is a "no
brainer", but if it is lots of work to change to A6 for a limited
value, is it worth it? 

Someone (name please ??) asked if we do A6 0, isn't it really just as
hard to do a full-blown A6 later? 

Theo Pagtzis asked how would A6 handle really rapid renumbering?

Steve Deering noted again, Mobile IP could do it, thus A6 not needed
useful for rapid renumbering. 

Olafur felt that translation of A6 0 is easy, synthesis easy. The only
question is then one of delay. Some company has done this already. 

Steve Deering asked, at what transition cost?

Simon Linen (??) stated that AAAA and A6 are easy, and both can be
deployed at the same time in the same zone, simple to have tools
maintain one record type from the other.  

Itojun stated that maintaining A6 and AAAA is not easy.

Rob Austein asked if mechanisms ease pain, as it is several years to
do transition. This was discussed in Minneapolis. Another variation is
to modify servers to generate A6 0 when quad AAAA is found. Though,
when translating either way, signature is lost. However, it is
important to not use A6 in complex ways. It is an attractive nuisance
in that it does encourage people to try to exploit A6 beyond
reasonable usage.

Matt Crawford felt that transition best be kept short.

Itojun is concerned that Rob says years to do transition tools and
that his users can't wait.

Alain stated that the plan from Minneapolis roughly described the
transition. 

Rob said that Itojun correct; we can't take a long time for a
transition. It is important to decide on A6 very soon. 

Mohsen Suissi from FRNIC noted that many users have been waiting
for years to move to IPv6 production. AAAA works fine. If we say we
have to move to A6 0 and wait for bind 9, and/or new O/S, we are
waiting for more years. customers keep waiting. 

Itojun asked how many BIND 4 servers are still around versus BIND 9?

Perry - how many folks using v6 all the time. A number of hands. Of
these how many could run A6 soon, not so many of the hands. Folks
around us using AAAA, can we go backwards and wait? 

Randy asked that for installed AAAA base would you use A6, and the he
would, if it was a significant value, which it isn't. 

Jim Bound would change resolvers not O/S thus AAAA use would continue
and this is only an operational issue. 

Margaret Wasserman asked why this is an issue of one against other. We
have AAAA, so question is do we continue to work on A6, say as
experimental. Plan for success, for renumbering, why not keep both? 

Steve Deering agree w/Margaret and Jim. Lack of decision here doesn't
keep people from moving to IPv6. It should not be viewed as blocking
IPv6. 

Alain said that the root operators are trying to get IPv6 accessible
root servers, and that they are concerned about what to implement. 

---
Returning to GSE-like routing usage for A6

Randy stated that if a critical architectural change needed for A6, he
would support it. However, we don't know what it will be yet. 

Thomas said that when Rob talked about transition time being a couple
years this means at least 2, but he believes it would take 5 years
given what is shipping and what current plans are. 

Tony Hain also noted that since decision is taking a while, we are
talking about 6 months. before real development could even start. Maybe
it's a 7 year transition.

====
consensus building
(one minute break while chairs huddle)

Tony Hain summarized what we are hearing from this meeting's discussions:

---
Bitstring not necessary, so will take to list to confirm.

---
DNAME - only one case where its necessary is if we choose A6. 

Matt believes you don't need but will really wish for it. 

Rob said without A6, DNAME use is a more general DNS question, i.e.,
equally relevant to v4. 

So again Tony noted that we will take to list to confirm.

---
A6/AAAA - tools needed, and could make host push update vs relational
   db  work. So again Tony noted that we will take to list to confirm. 

---
Renumbering - no consensus on time frames and out of scope here. If
rapid implies less than hourly and requires significant architectural
change than DNSSEC fails in verifying signature changes. 

Randy agreed but asked that GSE/8+8 also is in category of rapid
renumbering (i.e., can't tell now if it will happen or when, and what
it will look like). 

Also, noted that it is an operationally attractive nuisance.

---
Consensus building

-
Straw polling the 4 address options for rough consensus:

- full A6 development with AAAA synthesis 
   - low hum, then a slightly louder hum when asked again

- A6 0 w/ AAAA synthesis 
   - medium hum, then a slightly louder hum when asked again

- AAAA deployed, A6 to experimental 
   - larger hum, then a slightly louder hum when asked again

Randy elaborated that the value of going to Experimental means anyone
using A6 has a consistently specified A6 spec to use. 

Thomas added, we want to signal developers about our A6 shipping
intentions, and how defaults are set. 

Bill Manning believes AAAA should be left in standards track, and A6
to experimental. 


- AAAA deployed, A6 to historic 
  -  medium hum, then a slightly louder hum when asked again

It was sense of the room that the hums indicated deploying AAAA and
putting A6 to Experimental. Again, this will be take to list to
confirm.  

-
Bit labels -

- make historic 
  - medium hum

- make experimental 
  - loud hum

- keep 
  - no hum taken due to lack of comment earlier

Therefore, DNAME for bit label use is limited to experimental use.


When someone asked if the ip6.int vs ip6.arpa choice was going to be
discussed, it was noted that it was out of scope for this group as it
was an IAB decision. 

There was a brief discussion of what list the discussion should go
to. Randy and Erik (our area directors in attendance) agreed it should
fall under DNSEXT. and the results published to all the other lists. 

---
Meeting adjourned (ahead of schedule)


Summary of of meeting consensus to be verified on mailing lists: 
 - AAAA stays on standards track in DNSEXT, 
 - A6 moved to experimental by DNSEXT
 - Bitlabels moved to experimental by DNSEXT
 - DNAME standardization is out scope.

-end