RE: 6MAN WG Last Call:draft-ietf-6man-ipv6-subnet-model-00.txt

The problem is that one problem is FAR more likely to happen than the other.

I shutdown my machine every night and power it on again in the morning when I come to work.
Therefore, every night of every workday I experience the type of outage described in our draft.
Furthermore, I occasionally go on vacations too - so the outage may last more than a day.

What this means for an administrator is that he has to predict, in advance, how long I may 
be on vacation so that the RA deprecating the old prefix can last long enough.  That puts
an unreasonable expectation on the network administrator.  Furthermore, I don't want to
have to get permission from my network administrator in order to go on vacation.

On the other hand, switch/router outages are typically noticed right away by many angry engineers
and are usually fixed in a matter of hours by the same administrators who control the RA.

This is not a minor implementation detail.  Fortunately, the DNA people also realized that this
was a potential problem and they have a solution specified - first deprecate the cached information
and verify before using it.  This solution will fix the blind cache reuse problem.  We propose this 
same solution in our new text (last paragraph of section 2) that Hemant just sent out.

- Wes

-----Original Message-----
From: JINMEI Tatuya / 神明達哉 [mailto:Jinmei_Tatuya@isc.org] 
Sent: Thursday, July 10, 2008 3:54 PM
To: Hemant Singh (shemant)
Cc: Suresh Krishnan; Wes Beebee (wbeebee); Thomas Narten; Brian Haberman; Bob Hinden; ipv6@ietf.org
Subject: Re: 6MAN WG Last Call:draft-ietf-6man-ipv6-subnet-model-00.txt

At Thu, 10 Jul 2008 12:09:01 -0400,
"Hemant Singh (shemant)" <shemant@cisco.com> wrote:

> Since you don't want any new rules added by our draft, we changed 
> bullet
> 3 related to caching on-link determination. The new bullet text does 
> not add any normative requirements but clearly says why it is a bad 
> idea to cache on-link determination.  Also, our draft is about on-link 
> determination - we are not adding anything related to IPv6 address 
> caching - we have said repeatedly, save it for another day.

The new text does not make sense to me.

In this scenario, the same problem can occur when a host (that just keeps working, without a reboot) happens to fail to receive the RAs containing 0-lifetime prefixes (such a failure can happen for various reasons: there may be a temporary failure in an intermediate switch; the host may have been just too busy and cannot handle the RAs, etc).  So, what's wrong in this scenario is that the router doesn't keep advertising 0-lifetime-prefixes sufficiently long.  This scenario itself doesn't explain 'why caching on-link prefix is a bad idea'.

This story also explains why I previously said "such caching is a minor implementation detail".  In terms of external behavior, a node that caches configured address/on-link prefix and reuses it after a reboot is often indistinguishable from a node that happens to fail receiving some updates from RA for some period.  Killing the former (while forgetting the latter) can just miss the more fundamental problem.

Aside from this essential point, the new bullet does also not make sense in the context of 'A correctly implemented IPv6 host MUST adhere to the following rules'.  If we find any valid 'justification' like this, it should be described outside this listing, somewhere more appropriate in the entire context.

---
JINMEI, Tatuya
Internet Systems Consortium, Inc.
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------