Subject: (ngtrans) 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.)

---

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: 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: 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: 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: 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: Paul A Vixie <[email-masked]>
Date: Tue, 07 Aug 2001 09:00:29 -0700

> I see a big difference between deprecating/moving to historic and changing
> 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: OKABE Nobuo <[email-masked]>
Date: Wed, 08 Aug 2001 00:46:09 +0900

From: Paul A Vixie <[email-masked]>
Subject: Re: (ngtrans) Joint DNSEXT & NGTRANS summary 
Date: Tue, 07 Aug 2001 09:00:29 -0700

> that SRV was experimental but that Microsoft's use of it pulled it forward.)

this is not true.
i voted for 3, but it was not for microsort.
and other people who voted were the same.

---- nobuo

---

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: 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: 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: "JIM R FLEMING" <[email-masked]>
Date: Tue, 7 Aug 2001 05:56:19 -0500

----- Original Message -----
From: "Bill Manning" <[email-masked]>
To: "Matt Crawford" <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>;
<[email-masked]>; <[email-masked]>
Sent: Tuesday, August 07, 2001 5:18 AM
Subject: Re: Joint DNSEXT & NGTRANS summary

> That was my impression as well.

You might first want to first define "production".

When one talks about "production services", I assume they are at a minimum
talking about IPv16-Compliant equipment. (i.e. Carrier-Grade, NEBS,
24", -48vDC,Fault-Tolerant LANs,1000/100/10 Ethernets)
http://www.dot-biz.com/IPv16/

Jim Fleming
Why gamble with a .BIZ Lottery? Start a real .BIZ Today !
http://www.DOT-BIZ.com
http://www.BIZ.Registry
0:212 - BIZ World

---

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

Alexis

---

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

Once James Aldridge wrote:
>Alexis Yushin wrote:
>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.

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: James Aldridge <[email-masked]>
Date: Tue, 07 Aug 2001 17:22:37 +0200

James

---

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: Keith Moore <[email-masked]>
Date: Tue, 07 Aug 2001 14:23:41 -0400

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

---

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: Keith Moore <[email-masked]>
Date: Tue, 07 Aug 2001 21:30:57 -0400

> P.S. Sorry if this is considered heretical.

I don't think it's heretical at all.  I don't take it as an absolute
that people would inherently rather renumber than use NAT, but I think
it's reasonable to assume that large numbers of people will follow the
path of least resistance, or perhaps, of least apparent risk.  If at 
the time the decision is made, NAT looks easier than renumbering, 
that's what they'll do.

So if we want to avoid NAT in IPv6, we need to make renumbering *much*
easier than it is now.

Problem is, A6 in its current form doesn't really do this.  Even if it 
works as advertised, A6 only addresses one of many aspects of renumbering.  
And DNS is almost certainly not the mechanism that you want to use to 
advertise address changes in your local network.  And people have a 
difficult enough time configuring SOA, NS, A, CNAME, PTR and MX records 
correctly, without having to also sort out A6 and DNAME.  To me it 
appears that A6 could actually increase the difficulty of renumbering
without disruption.

OTOH, I can see how A6 (or some subset thereof) might end up being part of
an overall renumbering strategy.  For instance, I can see how a DNS-like 
identifier might be assigned to name the set of global address prefixes 
by which a given network might be reached, and how a DNS server for 
a domain might want to act as a cache for those name-to-prefix bindings,
and how those bindings might be suitably represented by A6 records.
I can even see how it might be desirable to expose those A6 records
outside of your local net if you are signing your records with DNSSEC.
I can also see how it would be desirable to just sign the AAAA records.

The presumption behind A6 seems to be that the party who signs your
prefix record is likely to be different than the party who signs the
suffixes.  I don't buy that at all, because I believe that renumberings,
no matter how easy they become, are still going to need to be explicitly 
managed events.  You don't want your ISP asserting that you have a new
prefix before your firewalls, routers, hosts, and applications know how 
to deal with it.  Re-signing the records in a zone is the least of the 
problems that must be solved in order to do the renumbering.

Keith

---

From: Michael Richardson <[email-masked]>
Date: Tue, 07 Aug 2001 21:09:49 -0400

Assuming that it is MOIRA (sp), is there a summary of this somewhere?

]       ON HUMILITY: to err is human. To moo, bovine.           |  firewalls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net architect[
] [email-masked] http://www.sandelman.ottawa.on.ca/ |device driver[
] panic("Just another NetBSD/notebook using, kernel hacking, security guy");  [

---

From: Michael Richardson <[email-masked]>
Date: Tue, 07 Aug 2001 21:18:29 -0400

-----BEGIN PGP SIGNED MESSAGE-----

>>>>> "Olafur" == Olafur Gudmundsson <[email-masked]> writes:
    Olafur> Steve Deering noted that we have AAAA, and going to A6 0 is a "no
    Olafur> brainer", but if it is lots of work to change to A6 for a limited
    Olafur> value, is it worth it? 

  While going to A6 0 is simple, if the stub resolver implementers simply ask 
for "A6 0", i.e. ask for A6 instead of AAAA as if it was AAAA, then if we
come up with a new situation that *requires* A6 X (X!=0), then we are in
trouble.
  Secondly, those code paths where X!=0 will not get tested even if they are
written, and security may be involved, and wouldn't a buffer overflow bug in
a stub resolver be pretty!

---

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: Johan Ihren <[email-masked]>
Date: 08 Aug 2001 11:54:00 +0200

Michael Richardson <[email-masked]> writes:

>   While going to A6 0 is simple, if the stub resolver implementers
> simply ask for "A6 0", i.e. ask for A6 instead of AAAA as if it was
> AAAA, then if we come up with a new situation that *requires* A6 X
> (X!=0), then we are in trouble.

Which is exactly why I think that the claim that A6 0 is equivalent to
AAAA is wrong. 

We should keep the AAAA as "what stub resolvers use" and synthesize it
from a DNS infrastructure built from A6. Non-stub resolvers have a
choice of whether to deal with possible chains by querying for an A6,
or stay with the easier-to-digest form by querying for a AAAA.

I really think that the humming in the room was based very much upon
fears of delaying deployment further, regardless of technical
solution. And a feeling that A6, even in the form of A6 0, would do
that (which is correct).

Since AAAA synthesis was presented as a transition mechanism, not the
"final solution" those concerns won out.

>   Secondly, those code paths where X!=0 will not get tested even if
> they are written, and security may be involved, and wouldn't a
> buffer overflow bug in a stub resolver be pretty!

By staying with the AAAA for stub resolvers this will simply not happen.

Regards,

Johan Ihren
Autonomica

PS. A popular description of the differences between AAAA and A6 is to
claim that AAAA is optimized for read, while A6 is optimized for
write. Possibly a better way out putting it would have been to say
that AAAA is optimised for the (stub) resolver and end applications,
while A6 is optimized for the nameserver and DNS infrastructure. 

By keeping AAAA synthetization as a permenent mechanism rather than as
a transition issue it would be possible to optimize for both...

---

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: "Tony Hain" <[email-masked]>
Date: Wed, 8 Aug 2001 12:56:27 +0100

Keith Moore wrote:

> So if we want to avoid NAT in IPv6, we need to make renumbering 
> *much* easier than it is now.

Or accept the reality that enforcing PA as the 'only' approach is 
in direct conflict with the ultimate goals of the consumer. 

> ... I think it's reasonable to assume that large numbers of 
> people will follow the path of least resistance, or perhaps, 
> of least apparent risk.

This is the best description of the problem I have seen. A missing
piece is that the local minimum is different depending on your 
perspective as provider or consumer. Our whole approach is biased
toward the provider, partially because of scale, but mostly because 
they had a voice in the decision while the consumer did not. Yes 
scale is a real problem, but the fact that the consumer will find the
path of least resistance is at least as big.

Tony

---

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: Robert Elz <[email-masked]>
Date: Wed, 08 Aug 2001 20:14:50 +0700

[email-masked] said:
  | Or accept the reality that enforcing PA as the 'only' approach is  in
  | direct conflict with the ultimate goals of the consumer.  

The ultimate goals of the consumer are surely to have a stable internet
connection that works, and allows all available services.

Or for many perhaps at an even higher level, to make lots of money however
it can be made, and care about very little else.

Very few ultimate consumers care at all about renumbering, except to the
extent that it interferes with one of the above real goals.   They care
even less about the format of DNS resource records of course.

If renumbering is forced, and that causes problems, and NAT seems to allow
those problems to be avoided, then NAT is what people will do.  Once NAT
is seen as an inappropriate solution (which it will be once people start
wanting most of their systems to be available as servers, not just clients,
for at least some protocols) then they'll look to find something else that
works.   Geographic based addresses, with their likely increased costs might
be the solution.

Of course, if we can keep on working and get renumbering to work so easily
and cleanly that it ceases to be any kind of real cost, then perhaps
enforcing PA won't be seen as being in direct conflict with anything any
more - as no-one (at the ultimate consumer level) will even notice it
happening.

That's what we should be working towards, what's more, it should be an
attainable target - there's nothing so complex about configuring an IP
address that it needs to be seen as some kind of black art, to be done
once and never repeated.  The only real problems are that with IPv4 we
allowed the IP addresses to be configured everywhere, we assumed they
were a fixture (more permanent that even a domain name, as they have
essentially no vanity value) - and that has made the update process
absurdly difficult.   We just need to make sure that everyone is aware
that the only places an IPv6 address should ever be written are in the
DNS zone files and in router configs for networks (and there, in a form
that router renumbering can update).   Anywhere else you're ever tempted
to enter an IPv6 address we need to find an alternative.

kre

---

From: "Tony Hain" <[email-masked]>
Date: Wed, 8 Aug 2001 14:53:20 +0100

Robert Elz wrote:

I have no arguments with your comments other than:

> The only real problems are that with IPv4 we
> allowed the IP addresses to be configured everywhere ...

If *configuration* were the 'only' problem it might be possible
to fix renumbering. The fact that applications expect they need
to know about the addresses in use will compound the problem
such that it will be very difficult if not impossible to make
renumbering completely transparent. I have no doubt we can find
a way to completely automate renumbering, but I seriously doubt
that we can 'fix' all of the application developers, and their 
products. Given this state, the end user will be exposed to 
renumbering events. We either accept this and find a way to 
scale routing without renumbering, or accept that NAT will 
persist.

Tony

---

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

Tony;

> renumbering completely transparent.

Are you talking about ancient whois implementation?

> I have no doubt we can find
> that we can 'fix' all of the application developers, and their=20

Or, are you saying an NAT server can be detached from old ISP and
attached to new ISP keeping the existing connections?

						Masataka Ohta

PS

With end-to-end multihoming, it is possible that application/transport
program periodically check DNS to be smoothly renumbered.

---

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: 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: Keith Moore <[email-masked]>
Date: Wed, 08 Aug 2001 11:01:07 -0400

> program periodically check DNS to be smoothly renumbered.

that's insane.  you've just decreased the reliability of applications by
at least two nines.

---

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: Robert Elz <[email-masked]>
Date: Wed, 08 Aug 2001 22:20:35 +0700

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

  | that's insane.  you've just decreased the reliability of applications by
  | at least two nines.

That makes no sense at all.

If an application goes and checks the DNS, and gets no answer back, or
anything else to indicate that communications should fail, it can simply
ignore that, and just keep on using the address it has.  That is,
until/unless that address stops working.

On the other hand, if the DNS tells you that the entity you're connecting
to has been renumbered, then if you were willing to trust the address the
DNS gave you initially, you'd be foolish to ignore it now...  Using the
updated address just has to be better than simply having things fail because
the old address is no longer available.

Of course, there are truly dumb ways to use addresses that can be
imagined (and are probably even used) where you see changing addresses
from what is really load balancing or similar.   Implemented sanely those
cause no problems (you see all the addresses, as long as the one you're
using is still there, carry on, even if it isn't the one you'd pick
if you were starting again now).

And even there, using A6 as the DNS mechanism allows much better
heuristics, if you have an A6 record that says "this is my address, and
it relies on this other A6 for its prefix", and later you get the same
result, but the value of the prefix has changed, then you can be fairly
sure that a renumbering has happened - as distinct from simply getting
back a different address, which gives you no clue as to why the address
is no longer the same (and you can't really just compare bits, because
from afar, you have no idea what is prefix and what isn't).

kre

---

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

Date:        Wed, 08 Aug 2001 11:13:52 -0400
    From:        Daniel Senie <[email-masked]>
    Message-ID:  <[email-masked]>

  | Not to mention melting the 'net under ever increasing DNS load, since we'd 
  | no longer be able to cache anything.

Huh???

No-one ever said anything about changing the definition or use of the
TTL field in DNS replies.   If you get a TTL that says an address is
valid for a day, then you can keep using it for a day without checking
again.  Or you can check again every 5 minutes if you want to, but
the answers will just keep coming back from your local cache, each with
a TTL 5 minutes shorter than the previous time...

kre

---

From: Keith Moore <[email-masked]>
Date: Wed, 08 Aug 2001 12:35:52 -0400

> until/unless that address stops working.

but if the application starts using a new address, and that address doesn't
reach the same peer (same socket on the same host) as before, then switching
to the new address causes premature failure.  the application is always
better off continuing to use the old address, attempting to switch 
addresses only to recover from apparently broken connections.  even then, 
the application has to guess as to whether it's more likely that the 
connection will begin working again or whether the old address is now
permanently invalid.

furthermore, it's always been the case that you could get multiple addresses
in response to a name lookup, and there's no license to assume that those
addresses are interchangable for open connections.  in that case, which 
address does an application choose?

> DNS gave you initially, you'd be foolish to ignore it now...  

and you'd be foolish to switch while the old address is still working,
for reasons cited above.

> if you were starting again now).

but this doesn't facilitate renumbering. 

> sure that a renumbering has happened 

no you can't.  just because DNS thinks that a new prefix exists for an
address is no indication that the application on the other end can 
deal with your using the new prefix.

it's hard enough to keep MX records in sync with SMTP servers, and
that's something that should be explicitly managed.  asking applications
to keep track of changes in DNS doesn't strike me as an effective way
to do renumbering.  we need an interrupt mechanism, not a polling one,
and we need something that works at the IP level, not using an application
that is layered on top of IP.

Keith

---

From: Robert Elz <[email-masked]>
Date: Wed, 08 Aug 2001 23:35:12 +0700

Date:        Wed, 08 Aug 2001 12:12:15 -0400
    From:        Daniel Senie <[email-masked]>
    Message-ID:  <[email-masked]>

  | Reread what Keith wrote.

It was actually what Keith quoted that Otha-san wrote, not that
that really matters.

  | If applications are going to use DNS to check for 
  | changes in addressing, how is caching going to help?

It isn't going to help, but it isn't going to be eliminated either.

  | You're suggesting the 
  | local caches just answer the every-5-minute lookups, but that's useless if 
  | the DNS lookups are used as a part of multihoming.

I'm not sure of the relevance of multihoming - it was renumbering we
were discussing, but never mind.

  | I interpreted the 
  | periodic lookup as being a way for applications to find out that a remote 
  | machine has migrated to a new address.

Yes.

  | If local caches mask that migration, how's that help?

It is giving the answer (as authorised by the owner of the data).

Consider what happens now, and forget about long lived applications
periodically polling - instead consider a series of short lived
applications (like web page accesses, which do a DNS lookup for
every URL usually).

Given that caches answer now for those queries, for as long as the
TTL allows, do you really see any difference at all?

  | Multihoming has to involve resiliancy. If the addresses are cached for a 
  | day, saying "oh, your application will start working again tomorrow" is 
  | unlikely to cut it.

No.   But that's never been the idea.

  | So, I guess the question back to the original point was, what information 
  | is going to be IN those lookups that happen every 5 minutes?

Nothing, which is why a sane app wouldn't do that, only when the TTL
it originally received (assuming it is using an API that reveals the TTL
of course) has expired.  On the other hnd, other than increased traffic
at the local DNS cache, checking the address more frequently doesn't hurt
either.

  | If that 
  | information needs to change on a minute by minute basis (or a 5 minute by 5 
  | minute basis) then caching is not going to help.

No.   Somehow I think you're missing the context of this whole discussion
though.

  | So, the question is, to 
  | use this effectively, do zones have to be set up with their TTL set to 60 
  | seconds?

No, bit when you set a TTL on a record in the DNS, that's a promise that
the data isn't going to change from the time someone fetches the record
until the TTL has expired.

No-one is planning on altering that.   That is, that's true today, and
will remain true tomorrow (you can cache this answer for at least 6
months...)

The effect is that you need to handle TTLs and address changes together.
The old address needs to remain valid while any RRs that were handed out
are still alive.   That's the DNS, and will remain.

kre

---

From: Keith Moore <[email-masked]>
Date: Wed, 08 Aug 2001 12:51:23 -0400

> TTL field in DNS replies.

this is a common source of confusion.

the TTL field in DNS refers to the binding between the DNS name and
the address.  it has nothing whatsoever to do with the lifetime 
of the binding between the address and any hosts/sockets/processes
that might be attached to it.

---

From: Robert Elz <[email-masked]>
Date: Wed, 08 Aug 2001 23:54:30 +0700

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

  | the application is always
  | better off continuing to use the old address, attempting to switch 
  | addresses only to recover from apparently broken connections.

Yes, probably, but you still need to discover the changed address.

  | furthermore, it's always been the case that you could get multiple addresses
  | in response to a name lookup, and there's no license to assume that those
  | addresses are interchangable for open connections.  in that case, which 
  | address does an application choose?

Does it matter?   If the connection is going to be broken anyway, because
the old address is no longer valid, then you either pick a new one that
works (and in many, probably even most, cases, any would do), or it fails
and things are no more broken than they were before.  The app could even
try all the possible new addresses (assuming there are more than one) if
it likes.

  | no you can't.  just because DNS thinks that a new prefix exists for an
  | address is no indication that the application on the other end can 
  | deal with your using the new prefix.

No, it isn't.   But if the DNS tells you that the old address is no
longer valid, that is an indication that you're going to have to do
something, sometime pretty soon.

  | to do renumbering.  we need an interrupt mechanism, not a polling one,
  | and we need something that works at the IP level, not using an application
  | that is layered on top of IP.

Unfortunately, not possible.   IP is stateless, it has no idea who its
peers are, to send some kind of "I just renumbered" indication (or I am
about to renumber - same problem).  TCP could handle that, but not everything
uses TCP (UDP has the same problem as IP).

Apps that need to deal with this (and that's really only those few that
have long lived connections that need to be able to continue through events
like renumbering ... that is, forget about HTTP, SMTP, probably FTP as well)
are going to have to deal with this at the application level.  That either
means adding stuff to all the protocols ("I'm moving now...") or having the
apps find some other way to discover that a peer has renumbered.

Or outlaw renumbering, and somehow route flat /48's (or find some other
addressing method that both aggregates nicely, and avoids needing
renumbering).

Or simply accept that some applications will necessarily fail when
renumbering happens (and NAT can't fix it).

kre

---

From: Keith Moore <[email-masked]>
Date: Wed, 08 Aug 2001 12:56:41 -0400

> until the TTL has expired.

actually, it's not.   if that were the case, we could never change
a name-to-address binding without first setting TTL to zero (or
providing a mechanism that allows them to diminish to zero)
and waiting for older TTLs to expire.

it's somewhat more realistic to say that a TTL indicates (for an address 
record) that any services referred to by the DNS name will continue to be 
available at that IP address until the TTL expires, if they're available 
at all.

it's even more realistic to say that TTL indicates the amount of time
for which the DNS administrator is willing to accept that the services
associated with the DNS name will be effectively unavailable, should 
he/she need to change the addresses.

Keith

---

From: Greg Maxwell <[email-masked]>
Date: Wed, 8 Aug 2001 13:02:05 -0400 (EDT)

On Wed, 8 Aug 2001, Robert Elz wrote:

[snip]
> renumbering happens (and NAT can't fix it).

Or just accept that addresses identify paths to hosts, move your host
definition to a higher level, and move to a transport level which can
handle this such as SCTP.

Such an approach would not be all or nothing, as legacy applications would
still function, but not during renumbering.

Such a solution would also save aggregation in the face of multihoming as
is being discussed in the multi6 working group.

---

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

> something, sometime pretty soon.

DNS cannot tell you that old addresses are no longer valid, it can only
tell you that some addresses should be valid.  The absence of some address 
in a list of A (or AAAA or A6) records is not an indication that the 
address is not valid.

> about to renumber - same problem).  TCP could handle that, but not 
> everything uses TCP (UDP has the same problem as IP).

any system for renumbering (including the one you are proposing)
will require changes to existing protocols.  the question is, 
where is the best place to make these changes?    my guess is, 
some combination of ND/RD and ICMP.  

but they're not going to be simple changes (well, not if we expect
them to work well) because right now we don't even have the concept
of a host or stack identifier in the architecture. (with the possible
exception of the last 64 bits of a v6 address, and even then, not
in all cases) 

> like renumbering ... that is, forget about HTTP, SMTP, probably FTP as well)

which apps are affected depends on the frequency of renumbering and the
overlap during which multiple addresses are valid.    and yes, if we can
make these periods large enough (and the number of apps affected few enough)
we can shift the burden of recovery to those apps.

we really need for these to be explicitly chosen design parameters.

my feeling is that the mean time between renumbering should be no worse 
than the mean time between shutdown of reasonable hosts for other reasons,
which is to say, several months.  that way, renumbering doesn't 
significantly affect application reliability.

Keith

---

From: Robert Elz <[email-masked]>
Date: Thu, 09 Aug 2001 00:17:09 +0700

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

  | actually, it's not.   if that were the case, we could never change
  | a name-to-address binding without first setting TTL to zero (or
  | providing a mechanism that allows them to diminish to zero)
  | and waiting for older TTLs to expire.

That's the way it should be done, yes.  And it is the way that people
who really care about keeping things working make changes where that
is needed, but ...

  | it's somewhat more realistic to say that a TTL indicates (for an address 
  | record) that any services referred to by the DNS name will continue to be 
  | available at that IP address until the TTL expires, if they're available 
  | at all.

that's fine too.   When I reread my words I see that I didn't really
say the right thing, what I should have said, rather than "that the
data isn't going to change" is "that the data is going to remain valid"
and as long as you can keep reaching the address that you were given,
that's OK, even if some other application, doing a new query (and not
hitting the cache for whatever reason) would get a different answer.

(and if I were a pedantic nerd, I'd make that "data are going to remain
valid", or better, since a TTL applies to an RR "datum is going to remain
valid", but I won't do either of those...)

However...

  | it's even more realistic to say that TTL indicates the amount of time
  | for which the DNS administrator is willing to accept that the services
  | associated with the DNS name will be effectively unavailable, should 
  | he/she need to change the addresses.

That's not an unfair description of what often happens, mostly through
ignorance of how things should be done though.  Fortunately, with v6
(whatever DNS RR format is chosen) having multiple addresses assigned to
an interface is designed as a normal case, rather than an unusual one.
There should rarely be a need to make an old address go away before its old
DNS data has had a chance to naturally expire, so the IPv4 style of
"old address out, new address in" as a indivisible operation should gradually
fade away, as the new methodology becomes familiar.

kre

---

From: Paul A Vixie <[email-masked]>
Date: Wed, 08 Aug 2001 10:18:21 -0700

> Not to mention melting the 'net under ever increasing DNS load, since we'd 
> no longer be able to cache anything.

that's a hyberbolic comment if ever i've heard one.  there would still be
caching.  TTL's would be the same as they are now, which means they'd have
to be reduced one TTL in advance of a renumbering event.

btw, i'm seeing a moderate amount (hundreds of packets per second to a /23) of
icmp from all of the companies (some white hat, some black hat) probing my
network for security problems.  traffic in and of itself is not a worry, is it?

---

From: Keith Moore <[email-masked]>
Date: Wed, 08 Aug 2001 13:25:59 -0400

> ignorance of how things should be done though.  

sometimes ignorance, and sometimes a realistic assessment (based on 
knowledge of the users and applications affected) of the harm that 
will be done.

> Fortunately, with v6

the stacks are designed to deal with this, yes.  whether ISPs and network
administrators and firewalls and applications will also deal with this is a 
separate question.

even so, renumbering for the purpose of new connections is a lot easier
than renumbering established connections.

Keith

---

From: Masataka Ohta <[email-masked]>
Date: Thu, 9 Aug 2001 02:18:28 +0859 ()

Daniel;

> Reread what Keith wrote.

that he is crazy?

> If applications are going to use DNS to check for 
> changes in addressing, how is caching going to help?

Caching helps because applications won't check DNS again until
TTL expires and even if it does cache will supress actual query.

Caching helps other applications share the result of query.

> You're suggesting the 
> local caches just answer the every-5-minute lookups, but that's useless if 
> the DNS lookups are used as a part of multihoming. I interpreted the 
> periodic lookup as being a way for applications to find out that a remote 
> machine has migrated to a new address. If local caches mask that migration, 
> how's that help?

You are merely saying that DNS TTL should not be unnecessarily small.

DNS semantics is that if TTL expires applications still relying on
the answer should query again.

BTW, it is also possible to modify applications to carry information
that addresses change occurred and a list of new addresses.

							Masataka Ohta

---

From: Masataka Ohta <[email-masked]>
Date: Thu, 9 Aug 2001 02:22:39 +0859 ()

Keith;

> that might be attached to it.

What you don't understand is that, today, most users/applications
use DNS name for identification.

						Masataka Ohta

---

From: Robert Elz <[email-masked]>
Date: Thu, 09 Aug 2001 00:56:50 +0700

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

  | DNS cannot tell you that old addresses are no longer valid, it can only
  | tell you that some addresses should be valid.  The absence of some address 
  | in a list of A (or AAAA or A6) records is not an indication that the 
  | address is not valid.

I'm not sure I agree with that.   The RRset should be the complete
list of addresses that belong to a name (which isn't necessarily the
complete set that belong to the node that owns the name of course).

If an address isn't in the RRset, then it doesn't belong to the name,
by definition, and hence, is invalid as a translation of the name.
Whether that address still happens to reach the entity that it reached
yesterday, when it was a valid translation of the name is a different
question.

  | any system for renumbering (including the one you are proposing)
  | will require changes to existing protocols.  the question is, 
  | where is the best place to make these changes?    my guess is, 
  | some combination of ND/RD and ICMP.

I'm not sure it is possible.   Sure, a node could respond with some
kind of message to a peer that sends a packet to an address that the
node is in the process of deprecating - but that doesn't help at all
for all the other peers that don't happen to send any traffic during
the deprecation period.

  | which apps are affected depends on the frequency of renumbering and the
  | overlap during which multiple addresses are valid.

The overlap period, yes, the frequency, no, not really.   I can renumber
7 times in a day, and as long as the first (and rest) of those addresses
remain valid long enough, then all is OK.

  | we really need for these to be explicitly chosen design parameters.

That means then the overlap period.

Unfortunately, I suspect that's not possible.

  | my feeling is that the mean time between renumbering should be no worse 
  | than the mean time between shutdown of reasonable hosts for other reasons,
  | which is to say, several months.  that way, renumbering doesn't 
  | significantly affect application reliability.

And unfortunately you're trying to equate two measures that are likely
moving in opposite directions.  Hosts (and OS's) are becoming more
stable, and remaining running between shutdowns far longer than used to
be possible (I recall the days when computers were turned off each night
when people went home...)

And renumbering is likely to become more necessary, hence more frequent,
as the net gets bigger, and the routing problems get worse (assuming no
revolutionary solution of course).

But in any case, it isn't host uptime that counts, but application connection
time - what you would like is for addresses to remain valid (after ceasing to
be preferred) for at least as long as the average app connection is likely
to remain.

It would be nice to aim for that where possible, but circumstances being
what they are, mandating it would just make us look foolish.

kre

---

From: "David R. Conrad" <[email-masked]>
Date: Wed, 08 Aug 2001 11:10:50 -0700

Ohta-san,

Yes.

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

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

>renumbering with A6 is as easy as with NAT.

But it wouldn't be since addresses are embedded in (manually edited) 
configuration files, filter lists, etc.

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

Rgds,
-drc

---

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

> complete set that belong to the node that owns the name of course).

why?  nothing in the standards requires that all IP addresses be listed,
and most applications are quite capable of using IP addresses as names
for services.  there's also no reason that you couldn't use a completely
different mechanism than DNS to determine the IP address associated with
a service.  (we will certainly need to do this someday, as DNS cannot 
last forever)

> by definition, and hence, is invalid as a translation of the name.

perhaps, but it might still be a valid address for the service that
the user wants.

> for all the other peers that don't happen to send any traffic during

if hosts are notified when their address prefixes change, that notification 
can be forwarded to any connections (TCP or otherwise) that the host knows 
about.  similarly, if those hosts can notify resident applications that the 
addresses prefixes have changed, those applications can at least potentially
notify their peers.

this doesn't solve the problem entirely, since more than one host 
in a conversation could be concurrently changing addresses.  but since
only the hosts and applications know who their communications peers are,
that's where you have to start.

> remain valid long enough, then all is OK.

probably so.  but there is also probably a practical limit to the number 
of address prefixes that should be used at any one time.

> Unfortunately, I suspect that's not possible.

well, we appear to have some people assuming that renumberings will be
so infrequent that we can disregard them, and others assuming that 
renumberings will be so frequent that protocols have to deal with them
explicitly.  that's no way to do engineering.  for applications to
make use of IPv6 there needs to be some reasonable bounds on tbe 
behavior of the network.

> revolutionary solution of course).

I concur.
 
> be preferred) for at least as long as the average app connection is likely

I don't think that's the right criterion - first of all, that would have 
50% of all connections being broken; second, it's based on assumptions
about the nature of traffic, which will vary widely over time. 

I'd rather say that we have expectations about how the network behaves -
just as (say) end-to-end packet loss should be no worse than 20%, 
address bindings should be good for at least several days.

Keith

---

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

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

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: Robert Elz <[email-masked]>
Date: Thu, 09 Aug 2001 02:28:57 +0700

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

  | why?  nothing in the standards requires that all IP addresses be listed,

Again, it depends upon exactly what you're measuring here.   The DNS
defines the name, and if it has A (or AAAA or A6) RR's, then those define
the addresses that belong to that name.

That someone might know of some other address that happens to reach
the same piece of hardware isn't really relevant - even if the other
address happens to work just as well.

  | there's also no reason that you couldn't use a completely
  | different mechanism than DNS to determine the IP address associated with
  | a service.  (we will certainly need to do this someday, as DNS cannot 
  | last forever)

Perhaps.   When that happens then we'll have two ways to define the
mapping between names and addresses, and when they're not the same,
we'll have a mess (unless we also design a whole new naming scheme to
go with it, which is a rat hole I think I'll avoid in this discussion).

  | if hosts are notified when their address prefixes change, that notification 
  | can be forwarded to any connections (TCP or otherwise) that the host knows 
  | about.

Yes, at the TCP level, things are easy (well, could be, assuming
adequate protocol support, and "easy" is probably the wrong term
even then, "possible" would be better).

It is everything else that causes the problems.   Long lived UDP
NFS mounts are one to really worry about.   With v6 they're almost
all going to be able to use site local addressing, and so be immune,
but they still show the problem - the server explicitly has no knowledge
of who is connected, and it can be weeks between packets from clients
to servers if nothing is happening...

If the client just validates the name it was given whenever its address
has expired, then it can pick up on address changes, and use the new
address (the server doesn't care what address requests come to).
Client renumberings in this scenario don't matter, as the server doesn't
send unsolicited packets - only replies (so as long as the address remains
valid for a RTT, that's enough...)

Each protocol really needs to be investigated separately, what might
work, and what mightn't will vary enormously.   Which is another reason
why attempting to fix it at the IP layer probably isn't the solution.

  | similarly, if those hosts can notify resident applications that the 
  | addresses prefixes have changed, those applications can at least potentially
  | notify their peers.

Only if the end that is renumbering has any idea who its peers are.
That isn't always the case.

  | this doesn't solve the problem entirely, since more than one host 
  | in a conversation could be concurrently changing addresses.

yes, that part is the real hard one to handle - but if we can't get it
right without that case, worrying about that one is a waste of energy.

  | but there is also probably a practical limit to the number 
  | of address prefixes that should be used at any one time.

Yes, but thanks to virtual web hosting (the old way) it isn't a limit
we're going to reach with almost any renumbering frequency that is
practical by any means...

  | well, we appear to have some people assuming that renumberings will be
  | so infrequent that we can disregard them, and others assuming that 
  | renumberings will be so frequent that protocols have to deal with them
  | explicitly.  that's no way to do engineering.  for applications to
  | make use of IPv6 there needs to be some reasonable bounds on tbe 
  | behavior of the network.

Yes.   Unfortunately, the very disagreement that you mention means that
deciding what those bounds should be isn't going to be easy.

Personally, I'm also not sure I need to know - I want to make it possible
to renumber easily, which should make it possible to do frequently if needed,
and then hope I almost never have to actually do it...

That is, I want to be able to deal with the worst case, but will hope that
the best case is what occurs.   If the hopes fade, I will at least know that
I'm not sunk - if they're realised, then everyone is happy.

  | I don't think that's the right criterion - first of all, that would have 
  | 50% of all connections being broken;

A factor of 2 or whatever isn't going to make any marked difference.

  | second, it's based on assumptions
  | about the nature of traffic, which will vary widely over time. 

Sure.   Though we only care about the traffic that is likely to get
caught in this net - anything too short lived, or whose characteristics
make broken connections essentially irrelevant (ie: will retry anyway)
can be ignored.   We only need to include the stuff that wants to live
a long life.

  | I'd rather say that we have expectations about how the network behaves -
  | just as (say) end-to-end packet loss should be no worse than 20%,

Hmm... if it gets to double figures I give up for the day...

But I don't think we've ever had such a definition, what packet loss
is tolerable also depends heavily upon the applications.

  | address bindings should be good for at least several days.

Would be a nice target.  Just as long as we don't actually assume that
we will be able to meet it.

kre

---

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

> address happens to work just as well.

it's relevant to renumbering, because renumbering affects whether those 
addresses continue to work well - independently of what the DNS says.  

> mapping between names and addresses

not necessarily.  the input to such a service doesn't have to be service 
names (they could for instance be queries for resources matching several 
criteria).  even if the input were service names, those names don't have 
to be from the same space as DNS names.

there are already several applications that work this way, because DNS
doesn't suit their needs.

>   | if hosts are notified when their address prefixes change, that 
>   | notification can be forwarded to any connections (TCP or otherwise) 
>   | that the host knows about.
> 

Right, I'm just generalizing this to "any thing for which the host's 
OS maintains per-connection state".  So (for example) it would also 
be true of UDP sockets for which a remote address were bound to the 
socket. 

> address (the server doesn't care what address requests come to).

as explained earlier, this doesn't work in general.  you're overloading
the DNS name to do something it wasn't designed to do.

> why attempting to fix it at the IP layer probably isn't the solution.

no, you can't fix everything at the IP layer. but the notifications that
address prefixes are being changed (or that old ones are invalid) should 
originate with the network, not with DNS.
 
>   | addresses prefixes have changed, those applications can at least 
>   | potentially notify their peers.
> 

no, but at least this will provide a mechanisms by which applications
can be aware of their peers.  existing non-connection-based applications 
won't be able to survive renumbering, no matter what fix we come up with.

> right without that case, worrying about that one is a waste of energy.

true enough.  the question is whether a solution that fails to address
that case is adequate.  (or, are we also wasting our energy if we fail 
to address that case?)

> deciding what those bounds should be isn't going to be easy.

Still, I think we'd be better off if we started trying to get consensus on
a figure, than by trying to make progress without a shared understanding
of the problem.

We've made recommendations on other design parameters, like prefix length.
 
> the best case is what occurs.   

Right.  But I want to know what the worst reasonable case is so that I can
design my applications to deal with it.  

> Hmm... if it gets to double figures I give up for the day...

I wish the network to my home worked that well.

> is tolerable also depends heavily upon the applications.

Right.  But at some point you stop expecting anything to work.

> we will be able to meet it.

Again, I think we need to be able to make *some* assumptions.
Just as TCP doesn't survive arbitrary amounts of packet lossage, neither
do applications survive arbitrary amounts of renumbering.

---

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

>whole process of renumbering rather than trying to solve the problem

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: 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: Daniel Senie <[email-masked]>
Date: Wed, 08 Aug 2001 11:13:52 -0400

---

From: "JIM R FLEMING" <[email-masked]>
Date: Wed, 8 Aug 2001 10:20:04 -0500

----- Original Message -----
From: "David R. Conrad" <[email-masked]>
To: "D. J. Bernstein" <[email-masked]>; <[email-masked]>;
<[email-masked]>; <[email-masked]>; <[email-masked]>
Sent: Tuesday, August 07, 2001 7:31 PM
Subject: Re: (ngtrans) Joint DNSEXT & NGTRANS summary

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

Large organizations also use NAT so that they are not held hostage by
the ICANN/IANA multi-level-marketing (MLM) structure of the large
IPv4 Address Block owners and the Regional Registries.[1] By using NAT,
companies do not have to pay "Internet taxes" to inefficient organizations
who continue to grow in size to support their traveling road shows of
gad-flys, groupies, industry pundits and politicians. What should be
a completely automated system of obtaining (and returning) blocks of
IP addresses to pools maintained on reliable database servers, continues
to be a *subjective*, manual system, which requires that people "grease"
the right parts of the system in order to obtain a useable IPv4 address
block.
The large companies (some listed below) who already have plenty of IPv4
allocations, are immune from dealing with the MLM monster. They regularly
claim they just do not see what the problem is, yet, they are able to grow
in
size and win contracts because they have the IPv4 allocations and others
pay dearly in fees and administrative overhead to obtain meager resources.

[1] http://www.iana.org/assignments/ipv4-address-space
000/8  IANA - Reserved    Sep 81
001/8  IANA - Reserved    Sep 81
002/8  IANA - Reserved    Sep 81
003/8  General Electric Company  May 94
004/8  Bolt Beranek and Newman Inc.  Dec 92
005/8  IANA - Reserved    Jul 95
006/8  Army Information Systems Center  Feb 94
007/8  IANA - Reserved    Apr 95
008/8  Bolt Beranek and Newman Inc.  Dec 92
009/8  IBM     Aug 92
010/8  IANA - Private Use   Jun 95
011/8  DoD Intel Information Systems  May 93
012/8  AT&T Bell Laboratories   Jun 95
013/8  Xerox Corporation   Sep 91
014/8  IANA - Public Data Network  Jun 91
015/8  Hewlett-Packard Company   Jul 94
016/8  Digital Equipment Corporation  Nov 94
017/8  Apple Computer Inc.   Jul 92
018/8  MIT     Jan 94
019/8  Ford Motor Company   May 95
020/8  Computer Sciences Corporation  Oct 94
021/8  DDN-RVN     Jul 91
022/8  Defense Information Systems Agency May 93
023/8  IANA - Reserved    Jul 95
024/8  ARIN - Cable Block   May 01
                (Formerly IANA - Jul 95)
025/8  Royal Signals and Radar Establishment Jan 95
026/8  Defense Information Systems Agency May 95
027/8  IANA - Reserved    Apr 95
028/8  DSI-North    Jul 92
029/8  Defense Information Systems Agency Jul 91
030/8  Defense Information Systems Agency Jul 91
031/8  IANA - Reserved    Apr 99
032/8  Norsk Informasjonsteknologi  Jun 94
033/8  DLA Systems Automation Center  Jan 91
034/8  Halliburton Company   Mar 93
035/8  MERIT Computer Network   Apr 94
036/8  IANA - Reserved    Jul 00
                (Formerly Stanford University - Apr 93)
037/8  IANA - Reserved    Apr 95
038/8  Performance Systems International Sep 94
039/8  IANA - Reserved    Apr 95
040/8  Eli Lily and Company   Jun 94
041/8  IANA - Reserved    May 95
042/8  IANA - Reserved    Jul 95
043/8  Japan Inet    Jan 91
044/8  Amateur Radio Digital Communications Jul 92
045/8  Interop Show Network   Jan 95
046/8  Bolt Beranek and Newman Inc.  Dec 92
047/8  Bell-Northern Research   Jan 91
048/8  Prudential Securities Inc.  May 95
049/8  Joint Technical Command   May 94
  Returned to IANA   Mar 98
050/8  Joint Technical Command   May 94
  Returned to IANA   Mar 98
051/8  Deparment of Social Security of UK Aug 94
052/8  E.I. duPont de Nemours and Co., Inc. Dec 91
053/8  Cap Debis CCS    Oct 93
054/8  Merck and Co., Inc.   Mar 92
055/8  Boeing Computer Services  Apr 95
056/8  U.S. Postal Service   Jun 94
057/8  SITA     May 95
058/8  IANA - Reserved    Sep 81
059/8  IANA - Reserved    Sep 81
060/8  IANA - Reserved    Sep 81
061/8  APNIC - Pacific Rim   Apr 97
062/8  RIPE NCC - Europe   Apr 97
063/8  ARIN     Apr 97
064/8  ARIN     Jul 99
065/8           ARIN     Jul 00
066/8  ARIN     Jul 00
067/8           ARIN     May 01
068/8           ARIN     Jun 01
069-079/8 IANA - Reserved    Sep 81
080/8  RIPE NCC    Apr 01
081/8           RIPE NCC    Apr 01
082-095/8 IANA - Reserved    Sep 81
096-126/8 IANA - Reserved    Sep 81
127/8  IANA - Reserved    Sep 81
128-191/8 Various Registries    May 93
192/8  Various Registries - MultiRegional May 93
193/8  RIPE NCC - Europe   May 93
194/8  RIPE NCC - Europe   May 93
195/8  RIPE NCC - Europe   May 93
196/8  Various Registries   May 93
197/8  IANA - Reserved    May 93
198/8  Various Registries    May 93
199/8  ARIN - North America    May 93
200/8  ARIN - Central and South America May 93
201/8  Reserved - Central and South America May 93
202/8  APNIC - Pacific Rim   May 93
203/8  APNIC - Pacific Rim   May 93
204/8  ARIN - North America    Mar 94
205/8  ARIN - North America    Mar 94
206/8  ARIN - North America    Apr 95
207/8  ARIN - North America    Nov 95
208/8  ARIN - North America    Apr 96
209/8  ARIN - North America   Jun 96
210/8  APNIC - Pacific Rim   Jun 96
211/8  APNIC - Pacific Rim   Jun 96
212/8           RIPE NCC - Europe                       Oct 97
213/8           RIPE NCC - Europe                       Mar 99
214/8  US-DOD     Mar 98
215/8  US-DOD                                  Mar 98
216/8           ARIN - North America                    Apr 98
217/8           RIPE NCC - Europe                       Jun 00
218/8           APNIC - Pacific Rim   Dec 00
219-223/8       IANA - Reserved    Sep 81
224-239/8 IANA - Multicast   Sep 81
240-255/8 IANA - Reserved    Sep 81
---------------------------------

Fortunately, that all now changes, since Microsoft has added the
ability to use 2002 "IPv8 Addressing" in Windows 2000. Rather than
allocating the IPv8 Address space to the same insiders above, the
address space has been dispersed to thousands of regional and
non-regional registries, in order to make it fair and open and to
encourage automation and low-cost or no-cost allocations. People
that get angry about this are generally expressing their concerns that
THEY are no longer going to be able to hold people hostage over some
simple IP address allocations.

http://www.dot-arizona.com/IPv8/IPv4/

The "toy" IPv4 Internet is a sewer.
IPv8 is designed to be a swamp to cover the sewer.
IPv16 is the "high-ground"....

...here are some links...

Jim Fleming
http://www.unir.com
Mars 128n 128e
http://www.unir.com/images/architech.gif
http://www.unir.com/images/address.gif
http://www.unir.com/images/headers.gif
http://www.ntia.doc.gov/ntiahome/domainname/130dftmail/unir.txt
http://msdn.microsoft.com/downloads/sdks/platform/tpipv6/start.asp
http://www.ietf.org/mail-archive/ietf/Current/msg12213.html
http://www.ietf.org/mail-archive/ietf/Current/msg12223.html

---

From: Daniel Senie <[email-masked]>
Date: Wed, 08 Aug 2001 12:12:15 -0400

>a TTL 5 minutes shorter than the previous time...

Reread what Keith wrote. If applications are going to use DNS to check for 
changes in addressing, how is caching going to help? You're suggesting the 
local caches just answer the every-5-minute lookups, but that's useless if 
the DNS lookups are used as a part of multihoming. I interpreted the 
periodic lookup as being a way for applications to find out that a remote 
machine has migrated to a new address. If local caches mask that migration, 
how's that help?

Multihoming has to involve resiliancy. If the addresses are cached for a 
day, saying "oh, your application will start working again tomorrow" is 
unlikely to cut it.

So, I guess the question back to the original point was, what information 
is going to be IN those lookups that happen every 5 minutes? If that 
information needs to change on a minute by minute basis (or a 5 minute by 5 
minute basis) then caching is not going to help. So, the question is, to 
use this effectively, do zones have to be set up with their TTL set to 60 
seconds?
-----------------------------------------------------------------
Daniel Senie                                        [email-masked]
Amaranth Networks Inc.                    http://www.amaranth.com

---

From: David Terrell <[email-masked]>
Date: Wed, 8 Aug 2001 18:29:54 -0700

> day, saying "oh, your application will start working again tomorrow" is 

I think they're talking about reestablishing existing connections
if the address published in the DNS changes.

I think that's pretty silly.  Application protocols should (where
appropriate) be able to reconnect, or users can -- and DNS records
near a renumbering event should have low TTLs, or multiple A* records
for a multihomed situation, and applications should not be caching
records excessively (or at all, really), and making multiple attempts
at multiple A* records.

-- 
David Terrell           | "We must go forward, not backwards; upwards,
Nebcorp Prime Minister  | not forwards; and always twirling, twirling,
[email-masked]            | twirling towards freedom!"
http://wwn.nebcorp.com/ |  - The Simpsons

---

From: David Terrell <[email-masked]>
Date: Wed, 8 Aug 2001 18:31:31 -0700

> program periodically check DNS to be smoothly renumbered.

If you need this sort of feature set, you should probably be using
something like SCTP which has explicit layer 4 support for multiple
valid layer 3 addresses.

-- 
David Terrell            | "My question is, if a mime types, isn't 
[email-masked]             |  that kinda cheating?"
http://wwn.nebcorp.com/  |    - Jason Zych

---

From: Robert Elz <[email-masked]>
Date: Thu, 09 Aug 2001 10:21:35 +0700

Date:        Wed, 8 Aug 2001 18:29:54 -0700
    From:        David Terrell <[email-masked]>
    Message-ID:  <[email-masked]>

For the purposes of this discussion, the difference between:

  | I think they're talking about reestablishing existing connections
  | if the address published in the DNS changes.

and

  | Application protocols should (where appropriate) be able to reconnect,

is immaterial.   The question is whether the user sees an interruption,
not how the interruption is handled.

Keith was asking for it to be fixed below the level of the applications,
presumably because updating lots of applications (different kinds, and
just different implementations) is going to be a very long process,
whereas if things could be fixed below that everything would see instant
benefits.   That's also why SCTP isn't the immediate answer, as aside
from actually getting that implemented and deployed itself, the applications
would still need to be converted to use it.

  | or users can

But that is exactly what people are claiming is unacceptable.   I suspect
that what it really depends upon is the particular application's nature.
Which also suggests that handling this in the applications, rather than
below, is the appropriate place.

  | -- and DNS records
  | near a renumbering event should have low TTLs, or multiple A* records
  | for a multihomed situation, and applications should not be caching
  | records excessively (or at all, really), and making multiple attempts
  | at multiple A* records.

Yes - but the question is how the app determines that it needs to do this.

If a peer renumbers, and you don't get told that happened, then all you can
expect to see is either packets vanishing into the void, or perhaps an
ICMP host unreachable.   Both of those are also consistent with a net
link going down.   If you wait long enough to be fairly confident that it
isn't just a transient net blip, then you've already caused enough of
an interruption to the service that there's a noticeable problem.

So, the question then is just how you decide that you should be establishing
a new connection (or somehow making an old one shift addresses).   That's
where the possibility of looking in the DNS and seeing that the address
you were told to use before is no longer there arose in the first place.
If there's some way that you can do that before there's any packet
interruption, then the renumbering can be made truly invisible to the users.
If we decide that we have to wait until we get some kind of failure
indication (even just a single RTT (or RTO) without a response - even
though that usually just indicates mild congestion) then you have already
altered the operation of the app - though perhaps imperceptably.

If it was possible to create a signalling protocol so peers could be
informed of address changes, that would solve the problems (any address
validity overlap time would allow for a seamless address switch).
But I can't see how to make that work for stateless protocols (DNS, NFS, ...)
where the server is renumbered - basically the server simply has no idea
who should be informed.   Perhaps we can live with these failing, given
that it is likely to be rare that such things cross site boundaries
(the general DNS case is already doing DNS watching for address changes
of course, using the TTL - it is a proof by example that it can be made
to work - the cases that fail are the two where addresses are configured,
that is root servers (where the problems are so great that the answer seems
to be to simply give those immutable addresses forever) and locating a
back end resolver for a stub - which is unlikely to cross a site boundary).

As for apps caching DNS replies - I disgaree there.  The TTL is there to
allow caching, anyone who agrees to respect the TTL should be able to
cache a DNS reply and re-use it until the TTL expires.   Attempt to outlaw
that and you just end up with semantic quibbles "That's not my application
caching that address, it is my application's local resolver that is doing
the caching..."

kre

---

From: Keith Moore <[email-masked]>
Date: Thu, 09 Aug 2001 00:13:47 -0400

> benefits.   

or more generally, I'm asking for some agreement on the degree of
address stability an application should be able to expect - hopefully
one that is large enough that most applications can work without
having to explicitly deal with the potential for renumbering.

even for those applications that do have to deal with renumbering,
DNS names do not always suffice as peer names, due to the common
need to map a single DNS name onto multiple addresses, the delay 
inherent in DNS queries, and the degraded reliability.

Keith

---

From: Greg Maxwell <[email-masked]>
Date: Thu, 9 Aug 2001 08:03:20 -0400 (EDT)

On Thu, 9 Aug 2001, Robert Elz wrote:

[snip]
[snip]

Why would this be unacceptable? Having connections survive renumbering is
an enhanced feature, and yet another reason applications should move to
an improved transport.

For the general case of site renumbering, such a change could typically
occur in off-hours (where they exist), and go service by service so I
don't think it's critical that every application should be able to survive
it seemlessly.

Mobile IP is a more intresting situation, It would be useful if a mobile
host could carry two prefixes, it's tunneled prefix, and a local prefix
and could utilize transport layer renumbering support to seemlessly move
between networks without the constant overhead of tunneling or dropping
connections.

---

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

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

> 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 06:01:19 -0400 (EDT)

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