Subject: Re: [DNSOP] Updated cheese-shop: cost/benefit analysis, please?

From: Ted Lemon <[email-masked]>
Date: Thu, 25 Feb 2016 18:18:49 +0000

I'm sorry to be a sticky wicket here, but I have to ask: have you thought about what a guaranteed-correct implementation of this would look like?   I think you need to actually do that analysis before we proceed with this.   As best I understand it, getting this right is not trivial, and getting it wrong would be harmful.   While it clearly would help in the context of widespread adoption of DNSSEC, I'm not convinced that the security risk of the added complexity would be compensated for by an actual reduction in woe at the root.

I would like to see the WG seriously analyze this problem before considering proceeding with either this proposal or the other.
________________________________________
From: DNSOP [[email-masked]] on behalf of Warren Kumari [[email-masked]]
Sent: Wednesday, February 24, 2016 23:58
To: dnsop
Subject: [DNSOP] Updated cheese-shop.

Dear DNSOP,

We have recently updated "Believing NSEC records in the DNS root" (https://tools.ietf.org/html/draft-wkumari-dnsop-cheese-shop-01).

This incorporates some comments, but also does a better job of explaining the technique, what the benefits are, and why we are only handling the special case of the root zone.
We believe that, in this limited use-case the suggestions in Section 4.5 of RFC4035 are not as relevant. We also believe that the NSEC case (and no wildcards :-)) is simpler to solve than the NSEC3 case.

For these reasons we think that it is worth pursuing this in parallel with Fujiwara-san's "Aggressive use of NSEC/NSEC3" document.
cheese-shop does not conflict with "Aggressive use...",  rather it complements it, and can demonstrate the technique (in this restricted use case).

We welcome any feedback, including tomatoes, howls of derisive laughter, etc.

W

---

From: Ted Lemon <[email-masked]>
Date: Thu, 25 Feb 2016 18:32:32 +0000

An additional point about this: the case where the cheese shop solution works is really the case where large service provider DNS caches do the aggressive caching.   In this case we can get the same benefit without DNSSEC by simply keeping a complete copy of the root zone at the DNS cache.   This adds a small operational complexity in keeping that copy up to date, but eliminates the implementation complexity of the cheese shop or fullly aggressive NSEC cache.

So why isn't that a better way to address this problem?
________________________________________
From: DNSOP [[email-masked]] on behalf of Ted Lemon [[email-masked]]
Sent: Thursday, February 25, 2016 13:18
To: Warren Kumari; dnsop
Subject: Re: [DNSOP] Updated cheese-shop: cost/benefit analysis, please?

Dear DNSOP,

W

_______________________________________________
DNSOP mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dnsop

---

From: "Paul Hoffman" <[email-masked]>
Date: Thu, 25 Feb 2016 10:34:55 -0800

On 25 Feb 2016, at 10:18, Ted Lemon wrote:

> I'm sorry to be a sticky wicket here, but I have to ask: have you 
> thought about what a guaranteed-correct implementation of this would 
> look like?   I think you need to actually do that analysis before we 
> proceed with this.

Can you say more? It seems like the spec in the draft is a 
guaranteed-correct implementation: if you have a current validated 
statement that nothing exists between N1 and N2, and you later get a 
query for something between N1 and N2, send back NXDOMAIN directly.

> As best I understand it, getting this right is not trivial, and 
> getting it wrong would be harmful.   While it clearly would help in 
> the context of widespread adoption of DNSSEC, I'm not convinced that 
> the security risk of the added complexity would be compensated for by 
> an actual reduction in woe at the root.

Please say more about the "security risk". I'm missing it.

--Paul Hoffman

---

From: "Paul Hoffman" <[email-masked]>
Date: Thu, 25 Feb 2016 10:36:18 -0800

On 25 Feb 2016, at 10:32, Ted Lemon wrote:

> An additional point about this: the case where the cheese shop 
> solution works is really the case where large service provider DNS 
> caches do the aggressive caching.   In this case we can get the same 
> benefit without DNSSEC by simply keeping a complete copy of the root 
> zone at the DNS cache.   This adds a small operational complexity in 
> keeping that copy up to date, but eliminates the implementation 
> complexity of the cheese shop or fullly aggressive NSEC cache.
>

Saying "without DNSSEC" doesn't seem like a better way to address any 
problem...

--Paul Hoffman

---

From: Bob Harold <[email-masked]>
Date: Thu, 25 Feb 2016 15:16:32 -0500

On Thu, Feb 25, 2016 at 1:36 PM, Paul Hoffman <[email-masked]> wrote:

> An additional point about this: the case where the cheese shop solution
>> works is really the case where large service provider DNS caches do the
>> aggressive caching.   In this case we can get the same benefit without
>> DNSSEC by simply keeping a complete copy of the root zone at the DNS
>> cache.   This adds a small operational complexity in keeping that copy up
>> to date, but eliminates the implementation complexity of the cheese shop or
>> fullly aggressive NSEC cache.
>>

"without adding more code that has to deal with the complexity of DNSSEC
NSEC records"

DNSSEC will still be in use, but we don't need any new code to do a local
copy of root.

-- 
Bob Harold

---

From: Ted Lemon <[email-masked]>
Date: Thu, 25 Feb 2016 20:20:08 +0000

> Saying "without DNSSEC" doesn't seem like a better way to address any

Depends on how far in front of the horse you want to put the cart, I guess.   By "without DNSSEC," I mean "without requiring DNSSEC."   Of course we want DNSSEC, but it's not widely enough deployed yet to really make a difference, is it?

As for your question about complexity, I'm going to include an answer from our engineering team here, because I don't think I can paraphrase their explanation in a way that would improve on it:

Consider a zone with names "@", "aa", "bb", ... "zz".  ("@" being "the empty name", and I'm using relative names for brevity.)

You query for "m" and get an NSEC proving there's nothing between "ll" and "mm", and a proof that there is no wildcard.  Let this be denoted by "!ll->mm" and "!@->aa".

Meanwhile, at the authority, "m" is added and "ll" is deleted.

You query for "l".  The authority gives back "!kk->m" and "!@->aa".  How should you update your state as a resolver?  The !ll->mm and !kk->m rules are mutually inconsistent.  Do you store inconsistent data?  If asked about "m" do you answer "NXDOMAIN" or go recurse to find out the answer?  Do you flush any specific NXDOMAIN entries you have in your O(1) cache that might be affected (maybe you made them for performance reasons), or do changes to the tree only affect new resolutions?

IMO, the only "right" thing to do is to drop !ll->mm and keep !kk->m since it is more recent.  (In this example, we know it is more recent, but in the real world how do you know you're not talking to a slave that's behind?  Are you meant to look at the serial in the SOA RR too or signature expiration times?)  I'm OK with not flushing things out of the O(1) cache.

Meanwhile at the authority, everything but @ is deleted.

You query for "b" and get "!@->@".  Now you have to delete everything in the tree.  The point here is just that the tree maintenance can affect multiple nodes in the tree, as any new truth you learn from the authority can be inconsistent with some sequence of things you already know.

---

From: Mark Andrews <[email-masked]>
Date: Fri, 26 Feb 2016 08:59:28 +1100

In message <[email-masked]>, Ted Lemon writes:
> Depends on how far in front of the horse you want to put the cart, I
> guess.   By "without DNSSEC," I mean "without requiring DNSSEC
> ."   Of course we want DNSSEC, but it's not widely enough deployed yet to
> really make a difference, is it?
>
> As for your question about complexity, I'm going to include an answer
> from our engineering team here, because I don't think I can p
> araphrase their explanation in a way that would improve on it:
>
> Consider a zone with names "@", "aa", "bb", ... "zz".  ("@" being "the
> empty name", and I'm using relative names for brevity.)
>
> You query for "m" and get an NSEC proving there's nothing between "ll"
> and "mm", and a proof that there is no wildcard.  Let this b
> e denoted by "!ll->mm" and "!@->aa".
>
> You query for "l".  The authority gives back "!kk->m" and "!@->aa".  How
> should you update your state as a resolver?  The !ll->mm a
> nd !kk->m rules are mutually inconsistent.  Do you store inconsistent
> data?  If asked about "m" do you answer "NXDOMAIN" or go recu
> rse to find out the answer?  Do you flush any specific NXDOMAIN entries
> you have in your O(1) cache that might be affected (maybe y
> ou made them for performance reasons), or do changes to the tree only
> affect new resolutions?

Well the DLV code, which does do aggresssive negative caching, looks
for the NSEC which sorts before the QNAME and uses it to determine
if it needs to make a query (is the QNAME covered by the record).
You don't have to be perfect as the DNS is loosely coherent, you
just need to return a self consistent proof.  DLV doesn't have
wildcards so it is a little easier but the principle is the same.

> IMO, the only "right" thing to do is to drop !ll->mm and keep !kk->m
> since it is more recent.  (In this example, we know it is more
>  recent, but in the real world how do you know you're not talking to a
> slave that's behind?  Are you meant to look at the serial in
>  the SOA RR too or signature expiration times?)  I'm OK with not flushing
> things out of the O(1) cache.
>
> You query for "b" and get "!@->@".  Now you have to delete everything in
> the tree.  The point here is just that the tree maintenanc
> e can affect multiple nodes in the tree, as any new truth you learn from
> the authority can be inconsistent with some sequence of th
> ings you already know.

No, you don't need to do that.  Just let the negative answer expire
when they are scheduled to do so based on TTL.

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: "John Levine" <[email-masked]>
Date: 25 Feb 2016 22:17:58 -0000

>You query for "m" ...

>Meanwhile, at the authority, "m" is added and "ll" is deleted. ...

>You query for "l". ...

>Meanwhile at the authority, everything but @ is deleted.

This doesn't strike me as a very persuasive argument.  The DNS is not
Oracle, and has never promised to be perfectly coherent.  If my cache
queries you for x, you say x doesn't exist, then you add x to the
server, my cache will continue to say x doesn't exist until the TTL
for the cache entry expires.  This shouldn't surprise anyone.  

Synthesized NXDOMAINs slightly increase the range of x for which
cached answers might be stale, but it's hard to see that as a big
deal.  If your applications depend on up to date cached data, use
short TTLs like everyone else does.  For example, I see the SOA for
www.nominum.com have a TTL of one minute.

R's,
John

---

From: "Paul Hoffman" <[email-masked]>
Date: Thu, 25 Feb 2016 14:35:31 -0800

On 25 Feb 2016, at 12:20, Ted Lemon wrote:

> guess.   By "without DNSSEC," I mean "without requiring DNSSEC."   Of 
> course we want DNSSEC, but it's not widely enough deployed yet to 

How can one argue with logic like that? (That's a serious question.)

If a protocol requires DNSSEC (which more are these days), then only 
systems that have DNSSEC can implement them. That's an operational 
choice.

Or are you saying we should not deploy any protocols that require DNSSEC 
(such as DANE) until some group decides that DNSSEC has been widely 
enough deployed?

> from our engineering team here, because I don't think I can paraphrase 
> their explanation in a way that would improve on it:
>
> and "mm", and a proof that there is no wildcard.  Let this be denoted 
> by "!ll->mm" and "!@->aa".
>
> You query for "l".  The authority gives back "!kk->m" and "!@->aa".  
> How should you update your state as a resolver?  The !ll->mm and 
> !kk->m rules are mutually inconsistent.  Do you store inconsistent 
> data? If asked about "m" do you answer "NXDOMAIN" or go recurse to 
> find out the answer?  Do you flush any specific NXDOMAIN entries you 
> have in your O(1) cache that might be affected (maybe you made them 
> for performance reasons), or do changes to the tree only affect new 
> resolutions?

RFC 4035 is silent on this situation, I believe. At least, I don't see 
it covered in Section 4.5. Maybe this should be an update to RFC 4035.

> since it is more recent.  (In this example, we know it is more recent, 
> but in the real world how do you know you're not talking to a slave 
> that's behind?  Are you meant to look at the serial in the SOA RR too 
> or signature expiration times?)  I'm OK with not flushing things out 
> of the O(1) cache.

This sounds right, but I hope someone more familiar with RFC 403[3-5] 
would chime in.

--Paul Hoffman

---

From: "Wessels, Duane" <[email-masked]>
Date: Thu, 25 Feb 2016 22:38:59 +0000

> On Feb 25, 2016, at 2:17 PM, John Levine <[email-masked]> wrote:
> 
>> You query for "m" ...
> 

Well said.  I agree.

> www.nominum.com have a TTL of one minute.

Since cheese-shop is specific to the root zone, the TTLs are already
well known (and, I think, unlikely to change).   The document says:

   For the limited use case of this document (the DNS root) we believe
   that this is an acceptable trade off - the (current) TTL of the
   "negative cache" (in the SOA) is the same as the NSEC TTL (1 day).
   This means that, for a new TLD to begin resolving everywhere will
   require a minimum of a day - and this is true whether or not this is
   implemented (if someone had queried for the exact name, there would
   be a negatively cached answer, this simply expands the range of
   negative caches).

I would note, however, that one popular implementation limits negative
caching to 3 hours by default:

  [bind-9.9.2rc1]$ grep ncache bin/named/config.c 
	max-ncache-ttl 10800; /* 3 hours */\n\

In other words, today (as a BIND user) you might only have to wait 3 hours
when a new TLD is added, not the whole SOA minimum.

For implementations that treat "positive" and "negative" cache entries
separately, perhaps the document should say whether a validated proof of
non-existence should be considered "positive" or "negative."

DW

---

From: Ted Lemon <[email-masked]>
Date: Thu, 25 Feb 2016 22:43:28 +0000

> How can one argue with logic like that? (That's a serious question.)

I know, it sucks.

> systems that have DNSSEC can implement them. That's an operational

Yes.   But the case where aggressive NSEC caching works appreciably better than just copying the zone is in the precise case that this draft excludes.   So if we are _just_ trying to protect the root, this seems like an overly complex solution.

> (such as DANE) until some group decides that DNSSEC has been widely

Absolutely not.   I want us to deploy DNSSEC sooner rather than later.   I'm just not convinced that this draft is making an effective use of DNSSEC.   I'm willing to be argued around on the topic, but I think this particular problem is adequately addressed by IXFR.

> This sounds right, but I hope someone more familiar with RFC 403[3-5]

That wouldn't be me.   But if you will refer back to what I originally requested, it was not that we scuttle this document, but that we seriously consider how it would be implemented, in detail, and not just say "cache NSEC" as if how that's done is obvious.   And we should do the cost/benefit analysis: is what we are proposing to do better than what we can already do?

---

From: "John R Levine" <[email-masked]>
Date: 25 Feb 2016 18:12:20 -0500

> when a new TLD is added, not the whole SOA minimum.

Given that new TLDs publish a 127.53.53.53 wildcard for a month to try and 
show people where they have collisions, I'd think the root's one day TTL 
would be the least of your problems.

> non-existence should be considered "positive" or "negative."

How could it be other than negative?  It signals an NXDOMAIN to the 
ultimate client?

Regards,
John Levine, [email-masked], Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail.

---

From: Mark Andrews <[email-masked]>
Date: Fri, 26 Feb 2016 10:19:05 +1100

In message <[email-masked]>, "Paul Hoffman" writ
> it covered in Section 4.5. Maybe this should be an update to RFC 4035.

Why? The DNS is loosely coherent.  There isn't any requirement for
the SOA records from servers to be consitent so you can't tell which
answer is the "newest" as apposed to which was returned the latest
which you do know.  They may not be the same.

A sane implemention doesn't re-construct negative proofs sets.  They
store them as a set.  These result in self consistent answers being
returned.  It also means that a cache can return answers that say
a record does not exist and a also return the record at the same
time depending upon which QNAME/QTYPE is being queries for.

I can query for example/A and have a proof that says AAAA does not
exist and at the same time query for example/AAAA and get a RRset
as the cache has learnt the answers from two different version of
the zone.  This is expected behaviour from RFC 4035.

> This sounds right, but I hope someone more familiar with RFC 403[3-5] 

With RFC 403[45] the answers to <QNAME,QTYPE,QCLASS> are independent
of each other.  There is no need to clean anything.  About the only
thing that happens is that when you learn about a NXDOMAIN it wipes
out anything that is cached at that <QNAME,QCLASS>.  This also what
happens with RFC 103[45] but is implementation dependent.  That the
extent of the "cleaning" of other records that is potentially
expected.  Now caches could be made that don't do this cleaning
(only cache NXDOMAIN against the <QNAME,QTYPE,QCLASS> tuple) or
only see the NXDOMAIN if there is not a explict record cached for
<QNAME,QTYPE,QCLASS> or clean out everything below a QNAME on
NXDOMAIN (not currently specified behaviour).

Some of this is like do you overwrite the delegating NS RRset when
you get a answer from the child zone that contains a NS RRset in
the authority section.  There are implementations that do and
implementations that don't.

I'm actually fine with different behaviours in different implementations.
I don't think there is a "correct" behaviour.  Some of the behaviours
result in resolution failing if the authoritative servers don't
return consistent answers for the same instance of a zone but then
you are dealing with a broken server / broke delegation.

Mark

---

From: "Wessels, Duane" <[email-masked]>
Date: Thu, 25 Feb 2016 23:25:12 +0000

> On Feb 25, 2016, at 3:12 PM, John R Levine <[email-masked]> wrote:
> 
> Given that new TLDs publish a 127.53.53.53 wildcard for a month to try and show people where they have collisions, I'd think the root's one day TTL would be the least of your problems.

I don't disagree, but the document seemed to be saying that the TTL was
one day either way.

> How could it be other than negative?  It signals an NXDOMAIN to the ultimate client?

An argument could be made that the NSEC records positively exist and would be cached for
their full TTL.  Quoting the draft:

3.  Generating negatives responses from NSEC

   ...

   So, if a resolver generates negative answers from an NSEC record, it
   will not send any queries for names within that NSEC range (for the
   TTL).  If a new name is added to the zone during this interval the
   resolver will not know this.

DW

---

From: Warren Kumari <[email-masked]>
Date: Fri, 26 Feb 2016 23:39:19 +0000

> query for something between N1 and N2, send back NXDOMAIN directly.

As discovered by Geoff Huston, Google Public DNS (8.8.8.8) already does
this[0].

>
> > As best I understand it, getting this right is not trivial,and

> getting it wrong would be harmful.

I think that the "getting it right" for a DNSSEC validator is fairly
trivial[1], but I fully agree that cocking it up would be harmful.

W

[0]: IIRC, this was while collecting data for his "On Queries to the Root"
presentation.  Sorry for not saying this earlier, I wanted to clear it with
folk / not step on toes.
[1]: much more so than many of the other thingies that DNSSEC validators do!

> While it clearly would help in

---

From: Warren Kumari <[email-masked]>
Date: Fri, 26 Feb 2016 20:02:19 -0500

[I accidentally hit "Reply", not "Reply all" earlier, and sent the
below just to Duane. (mentioning because I cut and pasted into this
email, and it may have mucked up quoting / formatting ]

> I don't disagree, but the document seemed to be saying that the TTL was

Yup, the document does say that (although it words it poorly - I wrote
this bit of text in a rush).

> >> non-existence should be considered "positive" or "negative."

I think that implementations which treat "positive" and "negative"
cache entries separately have made an implementation choice, and it is
not our place to say which cache they should go in, merely the
behavior that we want. I suspect that that is what you are asking for?

>    resolver will not know this.

I think that we are having a terminology / implementation
disagreement, and that the "positive" / "negative" terms are
confusing.

I was intended what Duane said - you do this for the TTL of hte NSEC
record. So, in the case of:
beer. 86400 IN NSEC bentley. NS DS RRSIG NSEC
you will generate NXDOMAINs for .belkin for 86400 seconds.

I had not considered (and so not specified!) the behavior if you do
max-ncache-ttl. I could see us saying:
1: The NSEC record says that nothing exists *for the TTL of the
record*, so do this for the TTL of the record.
2: Follow the minimum of negative cache time in the SOA / max-ncache-ttl.

I was intending to say #1, but I can see a case for #2 (the root zone
NSEC TTL  / SOA TTL *currently* match, so the deciding factor in #2
would be max-ncache-ttl).
I'm (of course) happy to put whatever people want in here.

---

From: Ted Lemon <[email-masked]>
Date: Sat, 27 Feb 2016 01:58:28 +0000

> Please say more about the "security risk". I'm missing it.

Ideally you want your cache code to be as simple as possible.   More code means more bugs.

---

From: Paul Vixie <[email-masked]>
Date: Fri, 26 Feb 2016 18:21:25 -0800

> Ideally you want your cache code to be as simple as possible. More

for features with local benefit (dnssec validation for example) this is 
a cost:benefit tradeoff worth making. for those with only a remote 
benefit (client subnet for example) it's less arguably beneficial.

sadly, this same engineering economic argument applies to SAV.

-- 
P Vixie

---

From: Ted Lemon <[email-masked]>
Date: Sat, 27 Feb 2016 02:50:02 +0000

> sadly, this same engineering economic argument applies to SAV.

Do you mean that aggressive nsec in the cheese shop (which is now my epithet for the root, apparently) is as important as SAV?

The sad irony of SAV of course is that everybody would benefit from everybody else doing it, but nobody benefits from doing it themself.   I suspect the same could be said of either this proposal or the simpler proposal of simply mirroring the root.

---

From: "Wessels, Duane" <[email-masked]>
Date: Sat, 27 Feb 2016 02:57:07 +0000

> On Feb 26, 2016, at 5:02 PM, Warren Kumari <[email-masked]> wrote:
> 

I probably should've phrased it differently.  I was thinking about 
RFC 2308 "Negative Caching of DNS Queries (DNS NCACHE)" which talks about
caching of negative responses versus positive responses.  

So your draft may want to clearly state whether the type of caching that
it proposes should be treated as a negative or a positive response.  I can
see a good case being made for either.  Or maybe it doesn't matter much and,
as you say, the implementor can choose.

Perhaps this document would even need to state that it updates RFC 2308 in
in some way?

DW

---

From: "John R Levine" <[email-masked]>
Date: 26 Feb 2016 22:14:52 -0500

> as you say, the implementor can choose.

For the root, the NSEC and SOA both have TTL of a day, so it doesn't seem 
to matter much.

Regards,

---

From: Paul Vixie <[email-masked]>
Date: Fri, 26 Feb 2016 19:54:54 -0800

Ted Lemon wrote:
> Do you mean that aggressive nsec in the cheese shop (which is now my
> epithet for the root, apparently) is as important as SAV?

no. only that the benefit of doing either ANC (aggressive negative 
caching, which warren didn't know was part of DLV at the time he named 
this cheese-shop proposal) or SAV is remote/external, whereas the cost 
and risk in each case is internal/local.

deploying ipv4 originally was a make-money proposal. if you deployed it, 
you could make money. so everybody did. no discussion was required. 
there were variations like peering that were also save-money proposals, 
but fundamentally, turning on ipv4 was a rationally selfish act for all.

dnssec, ipv6, sav, anc, and a lot of other follow-on technologies, are 
not make-money proposals, nor save-money proposals. it makes absolutely 
zero business sense to do any of it unless you can be a late adopter 
after others have (stupidly and/or selflessly) created a market for you.

i believe there's a section missing in RFC's, after IANA CONSIDERATIONS 
and SECURITY CONSIDERATIONS. we need to specify ECONOMIC CONSIDERATIONS 
and expose feel-good proposals as what they obviously are, so that only 
those with long term public good as their motive know to pay attention.

-- 
P Vixie

---

From: Ted Lemon <[email-masked]>
Date: Sat, 27 Feb 2016 04:38:12 +0000

> those with long term public good as their motive know to pay attention.

I like it!   :)

(Actually, I think that's kind of what I was asking for, but you put it rather more directly... :)

---

From: Philip Homburg <[email-masked]>
Date: Sat, 27 Feb 2016 18:53:04 +0100

>after others have (stupidly and/or selflessly) created a market for you.

To me, dnssec and anc are in a different category than ipv6 and sav.

For ipv6 and sav, it makes almost no sense to do it locally. Both basically
need global adoption to be truely useful.

ANC can have immediate local benefits if it reduces the cost of running a
resolver or if the performance of the resolver is noticeably better.

In my experience, dnssec works very well for sshfp. And I think there are
plenty of tls connections that would benefit from from tlsa. With tls
becoming more and more wide spread, this includes a lot of traffic that is
logically within one organisation.

---

From: Paul Vixie <[email-masked]>
Date: Sun, 28 Feb 2016 18:13:28 -0800

> resolver or if the performance of the resolver is noticeably better.

in an attack scenario (random subdomain for example) there would be a measurable improvement from ANC. in normal use, you'll get more from resimprove's "NXDOMAIN means no children can exist" change than from ANC.

note, i'm in favour of ANC, and i will agree that unlike ipv6 and sav, there's a possibility of local benefit. we could argue longer as to whether the non-attack benefit is worth the full-time cost of the added complexity. bugs per KLOC is probably a universal constant.

-- 
P. Vixie