Subject: Joint DNSEXT & NGTRANS summary

From: Matt Crawford <[email-masked]>
Date: Tue, 07 Aug 2001 05:10:34 -0500

I have overheard nearly opposite outcomes quoted by random people 
in the halls, and some of the joint co-chairs (all the ones I've 
asked so far) seem reluctant to say anything substantive in public
about the outcome of the joint dnsext/ngtrans meeting.  I know there
are some interested parties who were not present and I have no idea
whether or how well they heard it on the mbone.  So, here's my
view from the floor ... other views would be welcome, the sooner
the better.

There was a lot of discussion, culminating with a "hum" on the
following four choices:

1. Deploy A6 in full panoply, synthesize AAAA for transition period
2. Deploy A6 conservatively ("A6 0"), synthesize as above
3. Reclassify A6 as experimental, use AAAA for production
4. Reclasify A6 as historic, use AAAA for production.

The relative volumes of the hum seemed to be 3 > 2 > 1 > 4, by all
accounts.  There was quite obviously no consensus (i.e., unanimity)
or rough consensus (in the usual IETF sense of near-unanimity).  It
could not even be concluded that the loudest hum represented a
majority of those voicing an opinion.

The difference in impressions taken away, therefore, I would account
for by differences in opinion about whether the preference of a
plurality, possibly a slim majority, represent a decision to alter the
status quo.  (That being A6 on the standards track.)

to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.

---

From: Jun-ichiro itojun Hagino <[email-masked]>
Date: Tue, 07 Aug 2001 19:16:29 +0900

>accounts.  There was quite obviously no consensus (i.e., unanimity)

	I would say 3 >> 2 > 1 > 4, heard from my location (near the
	VGA projector).

itojun

---

From: Jim Bound <[email-masked]>
Date: Tue, 7 Aug 2001 06:28:30 -0400 (EDT)

I felt consensus for number 3 is my input.

/jim

---

From: Bill Manning <[email-masked]>
Date: Tue, 7 Aug 2001 03:18:33 -0700 (PDT)

% There was a lot of discussion, culminating with a "hum" on the
% following four choices:
% 
% 1. Deploy A6 in full panoply, synthesize AAAA for transition period
% 2. Deploy A6 conservatively ("A6 0"), synthesize as above
% 3. Reclassify A6 as experimental, use AAAA for production
% 4. Reclasify A6 as historic, use AAAA for production.

	I took a (perhaps) stricter view on these four choices:

	1) A6 stays on Stds track, syth AAAA when needed, AAAA is
	   depricated
	2) A6 stays on Stds track, tempered by a recommendation to
	   operationally use A6 0.
	3) Leave AAAA on Stds track, move A6 to experimental.
	4) Move A6 to historic, leave AAAA on Stds track.

% The relative volumes of the hum seemed to be 3 > 2 > 1 > 4, by all
% accounts.  There was quite obviously no consensus (i.e., unanimity)
% or rough consensus (in the usual IETF sense of near-unanimity).  It
% could not even be concluded that the loudest hum represented a
% majority of those voicing an opinion.

	That was my impression as well.

--bill

---

From: James Aldridge <[email-masked]>
Date: Tue, 07 Aug 2001 12:34:52 +0200

> I felt consensus for number 3 is my input.

That was my view too.  There certainly seemed to be consensus for using AAAA
records for production and deprecating A6 records (either as experimental or
historic)

--James

---

From: Marc Blanchet <[email-masked]>
Date: Tue, 07 Aug 2001 08:01:17 -0400

While I vote for 3, I do agree with your reading that:
- 3 > others
- the hummm was not cristal clear.

Marc.

---

From: Rob Austein <[email-masked]>
Date: Tue, 07 Aug 2001 13:41:20 +0100

Er, Matt, AAAA -and- A6 are both currently proposed standards.

Other than that (and its implications on what the "status quo" is), I
agree with your summary.

---

From: Olafur Gudmundsson <[email-masked]>
Date: Tue, 7 Aug 2001 09:56:05 -0400 (EDT)

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 [email-masked]

-----

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

---

From: Alexis Yushin <[email-masked]>
Date: Tue, 7 Aug 2001 16:23:52 +0200 (CEST)

>records for production and deprecating A6 records (either as experimental or

I see a big difference between deprecating/moving to historic and changing
status to experimental. Experemental implies further development.

Alexis

---

From: James Aldridge <[email-masked]>
Date: Tue, 07 Aug 2001 17:22:37 +0200

> status to experimental. Experemental implies further development.

I think that "implies" might be a bit strong - "permits" might be more
appropriate (just check rfc-index.txt for all those ancient "experimental"
RFCs).  But, yes, I do recognise the difference.

James

---

From: Paul A Vixie <[email-masked]>
Date: Tue, 07 Aug 2001 09:00:29 -0700

> status to experimental. Experemental implies further development.

I don't see that difference here.  Just as "let's let the market decide"
really just means "let's do whatever Microsoft wants", so it is that "let's
make it experimental" really just means "let's move on."  (I find it amusing
that SRV was experimental but that Microsoft's use of it pulled it forward.)

I was not able to be in London, but had I been there my comments would've been:

	Let's not expect stub resolvers to do the caching necessary to
	understand either A6 or SIG/KEY -- those are things which servers
	ought to use to talk to other servers.  Stub resolvers making
	recursive requests of their name servers should be using AAAA and
	TSIG.  AAAA synthesis of underlying A6, and TSIG to protect
	verified KEY/SIG data for the last mile, is all a client needs.
	Every argument against SIG/KEY or against A6 comes down to either
	the caching problem or the complexity problem, and if we insulate
	the end-stations from those problems, the arguments are reduced to
	things which authority-side tools can be made to cope with.

Hopefully this point was made by somebody.

---

From: Jun-ichiro itojun Hagino <[email-masked]>
Date: Wed, 08 Aug 2001 01:20:00 +0900

>	things which authority-side tools can be made to cope with.

	i have a major concern with AAAA synthesis - which is, it is unclear
	as to who needs to AAAA synthesis.  the concern is mentioned
	in my draft.

	- you can't guarantee every first-hop DNS server to do AAAA synthesis.
	- if anyone does not, AAAA queries go into non-first-hop DNS servers
	  by recurse (imagine when pre-BIND9/non-BIND name server is used
	  as the first-hop name server).

	therefore, AAAA synthesis basically asks everyone to run AAAA and A6
	in parallel, which raises a lot of concerns (query delays if you query
	both, database maintenance cost if you maintain both in zone, no-sign
	if you synthesize, and a lot of others).

itojun

---

From: Alexis Yushin <[email-masked]>
Date: Tue, 7 Aug 2001 18:38:47 +0200 (CEST)

>Alex K (?) asked if we know what the future is. IPv6 will be used in

Alexis Yushin, thank you very much!

Alexis

---

From: Masataka Ohta <[email-masked]>
Date: Wed, 8 Aug 2001 01:40:38 +0859 ()

itojun;

> 	I would say 3 >> 2 > 1 > 4, heard from my location (near the

So?

Considering that mailing lists are the WGs...

						Masataka Ohta

---

From: Alexis Yushin <[email-masked]>
Date: Tue, 7 Aug 2001 18:40:09 +0200 (CEST)

>RFCs).  But, yes, I do recognise the difference.

Well, to be more specific we do plan on doing quite some more research
and testing in the A6 area. (We as in NLnet Labs)

Alexis

---

From: Paul A Vixie <[email-masked]>
Date: Tue, 07 Aug 2001 10:48:17 -0700

> 	if you synthesize, and a lot of others).

i would much rather deal with those problems, since they are solvable, then
to deal with non-renumberable 128 bit addresses, since they simply lead to
NAT.

i cannot emphasize strongly enough that vast numbers of transit-consumers
who lack the various powers needed to own portable address space will NOT
deploy globally addressable IPv6 space if it simply means that they will
become even more captive of their ipv6-transit providers than they are of
their ipv4-transit providers today.

the gprs and other mobile data providers are mostly going to be able to
own portable address space so they don't care about this issue.

but for "the enterprise" this is a real problem.

if ipv6 is no easier to renumber than ipv4, then we're going to see large
scale NAT.  much larger scale NAT than we see today.

being a captive customer of some transit provider when you only have an
ipv4 /24 or even a /20 that you have to renumber if you change providers
has difficulty N.  being a captive customer of some transit provider when
you have an ipv6 /64 to renumber if you change providers has difficulty
N*(2^44).  if NAT is used then the difficulty in either case is a constant,
and for that matter, it's the same constant.

so, "let's standardize both and let the market decide."

but right now i'm hearing three camps trying to kill A6:

	implementors who consider bitstring, A6, and DNAME "too hard to do"

	transit providers who like the idea of captive ipv6 /64 customers

	transit customers who have enough power to own their own ipv6 blocks

who in this mix is representing the interests of the average MIS manager?
(and who do you think is going to drive the ipv6 economy, anyhow?)

this debate borders on "simply unbelievable."

---

From: Daniel Senie <[email-masked]>
Date: Tue, 07 Aug 2001 14:43:18 -0400

At 02:23 PM 8/7/01, Keith Moore wrote:
>Seems like we really need a group to study how to do renumbering.
>Such a group needs to consider not just DNS but everything that
>renumbering affects - e.g. DNS, routers, hosts, firewalls, applications
>using address-based authentication, long-running applications, and
>large-scale distributed applications.  We need to consider the
>whole process of renumbering rather than trying to solve the problem
>in a piecemeal fashion.
>
>Keith

This could be a worthwhile undertaking. There are two possible aspects of 
such a group: developing protocols and standards to lessen the effort in 
renumbering, and providing information on how to survive renumbering in the 
present world.

An example of providing information would be a handbook for the 
administrator facing a move to a new colo. Getting the timing of Registry 
changes (for TLD zone NS glue), DNS changes, and server changes done in 
proper order requires significant planning. I suspect many folks just get 
it wrong, and suffer with outages for longer than they need to. Having a 
document to enumerate the steps to follow could be a good deliverable of 
such a group.

-----------------------------------------------------------------
Daniel Senie                                        [email-masked]
Amaranth Networks Inc.                    http://www.amaranth.com

---

From: "D. J. Bernstein" <[email-masked]>
Date: 8 Aug 2001 00:14:32 -0000

> so, "let's standardize both and let the market decide."

So you don't mind us deploying clients that look for only AAAA and A?
And you don't mind us deploying caches that don't convert A6 to AAAA?
The BIND company will stop saying things like

   I will note that djbdns does not support A6, DNAME, bitstring labels,
   and other modern features of the DNS. We did not have the luxury of
   ignoring IETF standards; we prefer to work and play well with others.

and start saying things like ``Apparently the market has decided to use
AAAA'' and ``Beware that clients won't look for your A6/DNAME records''?

> who in this mix is representing the interests of the average MIS manager?

Such as a manager wondering why his users are having sporadic problems
reaching www.i.am?

Or a manager who wants his site renumbered _now_, and can't wait several
years for universal client-side A6 support?

Or a manager unable to find DNS software with the features he wants,
because DNS implementors have to waste so much time on garbage like A6?

> scale NAT.  much larger scale NAT than we see today.

Explain. If the renumbering costs are the same, why will NAT become more
popular? Why will users become ``even more captive''?

The NAT sites I've seen are using it for precisely one reason: to
conserve precious IPv4 address space. They won't use NAT with IPv6.

---Dan

---

From: "David R. Conrad" <[email-masked]>
Date: Tue, 07 Aug 2001 17:31:59 -0700

Dan,

At 12:14 AM 8/8/2001 +0000, D. J. Bernstein wrote:
>conserve precious IPv4 address space.

Large organizations also use NAT so they aren't held hostage by their 
service provider.  Really.  If you don't believe me, ask any large 
organization that does not have "portable" address space.

>They won't use NAT with IPv6.

Yes, they will.  As soon as they are told by their new ISP that they must 
renumber, they'll question if they are any better off than they were with 
IPv4.  Neat thing about IPv6 is that everyone will be in the same boat -- 
no historical "portable" prefixes, right?

The argument can be made that you can renumber with AAAA, but pretending 
that renumbering is not an incentive to use NAT is just silly.

Rgds,
-drc

P.S. Sorry if this is considered heretical.

---

From: Masataka Ohta <[email-masked]>
Date: Wed, 8 Aug 2001 17:30:20 +0859 ()

drc;

> organization that does not have "portable" address space.

So, you are saying that the large organiation is currently accepting
to manually change IP addresses of DNS servers on renumbering, aren't
you?

They should have small (maybe two) number of nameservers for the entire
organization visible from the outside in the public Internet and
willing to renumber them or have none and ask someone operate ones.

If so, A6 is perfectly fine for it for easy and quick renumbering.

> that renumbering is not an incentive to use NAT is just silly.

The only thing to do is to have an RFC for the organization to tell
renumbering with A6 is as easy as with NAT.

						Masataka Ohta

---

From: Bill Manning <[email-masked]>
Date: Wed, 8 Aug 2001 02:06:23 -0700 (PDT)

% 
% Seems like we really need a group to study how to do renumbering.
% Such a group needs to consider not just DNS but everything that 
% renumbering affects - e.g. DNS, routers, hosts, firewalls, applications
% using address-based authentication, long-running applications, and
% large-scale distributed applications.  We need to consider the
% whole process of renumbering rather than trying to solve the problem
% in a piecemeal fashion.
% 
% Keith
% 

	PIER did look at renumbering from the IPv4 perspective.
	We explicitly did not consider IPv6 issues as IPv6 was
	still newly hatched. Perhaps it is time to revisit PIER
	in light of the current state of IPv6.

	If there is interest,   [email-masked]  

-- 
--bill

---

From: Matt Crawford <[email-masked]>
Date: Wed, 08 Aug 2001 04:40:59 -0500

Not "changes in routing system" but "coupling of DNS prefix delegation
to routing system's idea of prefix delegation."

> Consensus building

Here's the problem.  There was no attempt at consenus *building* after
the discussion, only a quick measurement of opinions at that point.
Given that a state of consensus did not already exist at this point

> ...then a slightly louder hum when asked again...

It is my possibly-mistaken recollection that only the first two
question were asked twice, becaused of a long interval of discussion
after the second.  It seems to be everyone's recollection that the
fourth alternative got distinctly less volume than any of the other
three, yet these minutes state it otherwise.

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

Er, I don't think there was any coupling of DNAME and bit-string
labels in the question, so I think you mean to say "bit labels under
the reverse tree" or something of that sort.

> It was sense of the room that the hums indicated ..

There was no meta-question asked about what the hums indicated.
Maybe you mean to say "The sense of the room, as measured by hums, was...".
But this raises the question of what does this phrase "sense of the
room" mean?  Further own your minutes you make the leap to

> Summary of of meeting consensus to be verified on mailing lists: 

The sole contentious point seemed to be the four-pronged AAAA vs A6
question, and the aggregated (hum) mass of opinion did not show
consensus by any accepted definition of the word, nor even rough
consensus by most reckonings.

> - A6 moved to experimental by DNSEXT

I do not believe there was rough consensus on these points.  There was
a plurality in favor of this option.  It's impossible to say whether it
was a majority, but it was clearly not an overwhelming majority.

> - Bitlabels moved to experimental by DNSEXT

There was rough consensus on this.

> - DNAME standardization is out scope.

I do not recall this question having been asked of the room.

---

From: Johan Ihren <[email-masked]>
Date: 08 Aug 2001 12:02:58 +0200

> Hopefully this point was made by somebody.

It was made, but not as succinctly. However, AAAA synthesis was mostly
presented as a transition mechanism leading towards an A6-only future.
I think that is a mistake and what worries people who are satisfied
with their working AAAA-based stub resolver.

Your point (in another mail) about renumbering as a defence againg
being locked in by your provider was definitely not made.

Johan Ihren
Autonomica

---

From: Ron Tipton <[email-masked]>
Date: Wed, 08 Aug 2001 08:12:07 -0400

Dan,

I can only speak for myself, but we (the University of Tennessee) seriously
considered using NAT for our dorm network, not because of lack of IPv4
address space, but because of lack of PORTABLE IPv4 address space.  Most
of our free IPv4 address space belonged to one of our ISPs and we DO NOT
want to stay captive to them.  

In the end we decided to renumber our entire network to avoid NAT, but
for us, NAT was a better solution than using IPv4 address space belonging
to an ISP.  After the pain of that renumbering, I assure you that if IPv6
address space only belongs to ISPs and not to the University of Tennessee,
we will NAT to avoid captivity!

r

Ron Tipton
Advanced Internet Technologies
University of Tennessee

---

From: Keith Moore <[email-masked]>
Date: Wed, 08 Aug 2001 09:08:37 -0400

> renumbering with A6 is as easy as with NAT.

only thing is, it's not as easy with A6 as it is with NAT.

if you use NATs to renumber, when you change prefixes the only thing
you change is the NAT.  the NAT does translation of addresses within
external DNS queries and responses for you.  all of your internal
routers, firewalls, hosts, applications, etc. stay the same.

if you renumber using IPv6, all of that state in routers, firewalls,
hosts, applications, etc has to change somehow, and it has to change
with minimal disruption of service.  A6 only addresses one part of that.

renumbering is a hard problem.

Keith

---

From: Masataka Ohta <[email-masked]>
Date: Wed, 8 Aug 2001 23:13:27 +0859 ()

Keith;

> only thing is, it's not as easy with A6 as it is with NAT.

It is.

> routers, firewalls, hosts, applications, etc. stay the same.

It is stupid if internal routers, firewalls, hosts, applications, etc.
do not rely on DNS and use raw addresses.

DNS does translation of addresses for all of your internal
routers, firewalls, hosts, applications.

However, the problem is that router autoconfiguration is
a bad thing to do if we use DNS, regardless of whether we use
renumbering on ISP change or not.

> A6 only addresses one part of that.

So, we should have router configuration mechanism where routers
(and firewalls) automatically accept upper 48 bit of addresses but
nothing more.

> renumbering is a hard problem.

Except for DNS glue, renumbering is trivially easy.

						Masataka Ohta

---

From: Robert Elz <[email-masked]>
Date: Wed, 08 Aug 2001 21:44:48 +0700

Date:        Wed, 08 Aug 2001 09:08:37 -0400
    From:        Keith Moore <[email-masked]>
    Message-ID:  <[email-masked]>

  | if you use NATs to renumber, when you change prefixes the only thing
  | you change is the NAT.

This is only true if you only consider your own work.   When you change
addresses though, lots of other people need to update their firewall
configurations, etc.

The recent message on the ipng list from Isaac Aldrin (and apologies if
I inverted that name - the mail headers weren't clear...) shows that
quite clearly - a major problem is notifying your peers of the new address
and having them update their configurations.

Of course, A6 doesn't solve that problem, though its use might make it
a little simpler.   That is, if have an A6 record that defines my network
prefix, that I refer to from the A6 records for all my host names, etc,
then I can tell my peer sites that they can use that same A6 record to
configure their firewalls (and they can verify it using dnssec, etc).
Then, when my addresses change, which I make known in the DNS by updating
my prefix A6 record, your firewall should be able to automatically
update itself.

Assuming I'm sane (and the circumstances allow), I'll have two different
prefixes for a while, both would be made known from the same prefix name
in the DNS, your firewall would then allow both through during the
transition - when the old address expires, your firewall will automatically
stop allowing that old address in.

I'd hate to think how many IPv4 firewalls exist that have IP addresses
configured in them, where the owner (user) of the IPv4 address now is
completely unrelated to the user at the time the firewall was configured.

It's possible to achieve all this with AAAA as well, I could have an AAAA
record that defines my prefix, but that would be used by nothing that I
care about, so it would require real discipline to remember to keep that
one updated.   On the other hand, the A6 record would be referred to by
most other A6 records in the zone file - that's one of the few that would
need to be touched by a renumbering, so you can be fairly sure that
updating it will never be forgotten.

  | if you renumber using IPv6, all of that state in routers, firewalls,
  | hosts, applications, etc has to change somehow, and it has to change
  | with minimal disruption of service.  A6 only addresses one part of that.

This is certainly true.   I don't think anyone is claiming that A6
solves any problems of itself.   What it does is remove a part of one
impediment to getting a solution.   That doesn't sound like much, and
it probably isn't ... but I'd rather not have that impediment, than
have to deal with it forever.

  | renumbering is a hard problem.

That's certainly true too.

kre

---

From: Keith Moore <[email-masked]>
Date: Wed, 08 Aug 2001 10:57:32 -0400

> have to deal with it forever.

agreed that we'd be better off without that impediment.  but the A6 method 
of removing that impediment creates impediments of its own, and some folks 
believe it's not a good tradeoff.  and it's hard to understand the value 
of A6 (to understand whether it is worth the cost) without having a good 
understanding of the total cost of renumbering.

Keith

---

From: Keith Moore <[email-masked]>
Date: Wed, 08 Aug 2001 15:10:55 -0400

> Sorta reminds me of the IDN situation.  Instead of focusing on the real
> problem (getting higher layers to do the right thing), the focus is on
> fixing the DNS...

we might disagree that higher layers are the best place to fix the problem
or that the fix exclusively belongs there.  but it should be clear that
we cannot do a good job of fixing this with DNS alone.

Keith

---

From: "D. J. Bernstein" <[email-masked]>
Date: 9 Aug 2001 20:05:02 -0000

David R. Conrad writes:
> But it wouldn't be since addresses are embedded in (manually edited) 
> configuration files, filter lists, etc.

What relevance does this have to the topic at hand?

If you want to change the software to look up addresses in DNS, go
ahead. A6 doesn't make this any easier.

---Dan

---

From: "David R. Conrad" <[email-masked]>
Date: Thu, 09 Aug 2001 14:46:15 -0700

Dan,

I know it is hard when you're so busy lying about "The BIND Company", but 
do try to keep up.

I was responding to a message that said A6 makes renumbering trivial.  I 
was suggesting that the real renumbering problem can't be solved just in 
the DNS.  It would, at best, solve only a portion of the problem.

However, please continue to remove context and misrepresent -- you do it so 
well.

Rgds,
-drc

At 08:05 PM 8/9/2001 +0000, D. J. Bernstein wrote:
>--------------------------------------------------------------------
>IETF IPng Working Group Mailing List
>IPng Home Page:                      http://playground.sun.com/ipng
>FTP archive:                      ftp://playground.sun.com/pub/ipng
>Direct all administrative requests to [email-masked]
>--------------------------------------------------------------------

---

From: Masataka Ohta <[email-masked]>
Date: Fri, 10 Aug 2001 15:20:58 +0859 ()

drc;

> Yes.
> I don't think so.  A6 is only a small part of the full problem.

The beggest part of the full problem is updating DNS glue.

> configuration files, filter lists, etc.

It is really painful to do so with 128 bit addresses.

With A6, DNS provides not only addresses but also bitmasks that
writing cofiguration becomes easy.

> problem (getting higher layers to do the right thing), the focus is on 

The right thing to do for IDN and NAT, is not to use them.

						Masataka Ohta

---

From: Olafur Gudmundsson <[email-masked]>
Date: Fri, 10 Aug 2001 23:33:16 -0700

Final Minutes of the DNS-EXT/NGTRANS joint meeting on 
How to represent IPv6 addresses in DNS

-----

Agenda

----- 
Short names: Full names 
Alain	     Alain Durand
Bob	     Bob Hinden

Introduction

 
----

Bit labels - Alain

-

Matt said yes.

---
AAAA vs A6

-

Matt Crawford noted that missing from questions is, we focus on
"today", not if it is needed in future. E.g., coupling of DNS prefix
delegation to routing system's idea of prefix delegation.

-

Alexis Yushin 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.

---

====
consensus building

---

---

---

---

---
Next the chairs attempted to get the sense of the room to the 
reading material and discussions. Consensus is to be judged on
the mailing list.

-
Straw polling the 4 address options for rough consensus:
The first 3 questions where asked then there was restart
after clarification on what experimental status was. 

- A6 0 w/ AAAA synthesis 

The chairs judged the sense of the room that the hums indicated
deploying AAAA and moving A6 to Experimental. Again, this will be taken
to list to confirm.  

-
Bit labels -

- make historic 
  - medium hum

- make experimental 
  - loud hum

- keep 

Therefore, DNAME for bit label use is limited to experimental use of
bitlabels in the reverse tree.

---

Summary of the sense of the meeting, to be verified on mailing lists: 

-end