Subject: RE: (ngtrans) Joint DNSEXT & NGTRANS summary

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=20
> *much* easier than it is now.

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

> ... I think it's reasonable to assume that large numbers of=20
> people will follow the path of least resistance, or perhaps,=20
> 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=20
perspective as provider or consumer. Our whole approach is biased
toward the provider, partially because of scale, but mostly because=20
they had a voice in the decision while the consumer did not. Yes=20
scale is a real problem, but the fact that the consumer will find the
path of least resistance is at least as big.

Tony

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

---

From: Randy Bush <[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=20
products. Given this state, the end user will be exposed to=20
renumbering events. We either accept this and find a way to=20
scale routing without renumbering, or accept that NAT will=20
persist.

Tony=20

=20

---

From: Randy Bush <[email-masked]>
Date: Wed, 08 Aug 2001 14:54:30 +0100

> you just sent out a message that i'm pretty sure originated with kre
> but it showed up under your name.  oops....

<blush> new approval macro. <sigh> 

randy

---

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

> With end-to-end multihoming, it is possible that application/transport
> 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: 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
> 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.

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

---

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

>that's insane.  you've just decreased the reliability of applications by

Not to mention melting the 'net under ever increasing DNS load, since we'd 
no longer be able to cache anything.
-----------------------------------------------------------------
Daniel Senie                                        [email-masked]
Amaranth Networks Inc.                    http://www.amaranth.com

---

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: 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: 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: 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: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: 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: Keith Moore <[email-masked]>
Date: Wed, 08 Aug 2001 13:25:59 -0400

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

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
> (whatever DNS RR format is chosen) having multiple addresses assigned to
> an interface is designed as a normal case, rather than an unusual one.

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

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: Paul A Vixie <[email-masked]>
Date: Wed, 08 Aug 2001 10:18:21 -0700

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

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: 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: 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:47:22 -0400

>     Date:        Wed, 08 Aug 2001 14:54:32 -0400
>     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.

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

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

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

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. 

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

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

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

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

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.

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

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

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

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

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

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

I wish the network to my home worked that well.

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

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

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

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

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.

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

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

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

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.

kre

---

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: 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: 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]
> would still need to be converted to use it.
[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.