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

From: "Wes Beebee (wbeebee)" <[email-masked]>
Date: Wed, 9 Jul 2008 10:08:02 -0400

Tatuya,

Please see in line below between <wb> and </wb> 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Tuesday, July 08, 2008 9:50 PM
To: Wes Beebee (wbeebee)
Cc: Hemant Singh (shemant); Thomas Narten; Brian Haberman; Bob Hinden; [email-masked]
Subject: Re: 6MAN WG Last Call:draft-ietf-6man-ipv6-subnet-model-00.txt

At Thu, 3 Jul 2008 17:07:34 -0400,
"Wes Beebee (wbeebee)" <[email-masked]> wrote:

> >    3.  On-link determination SHOULD NOT persist across IPv6 interface
> >        initializations.  Note that section 5.7 of [RFC4862] describes
> >        the use of stable storage for addresses acquired with stateless
> >        address autoconfiguration with a note that the Preferred and
> >        Valid Lifetimes must be retained if this approach is used.
> >        However no RFC suggests or recommends retaining the on-link
> >        prefixes.
> 
> Hmm. I agree that the current specs don't suggest doing this, but is 
> it forbidden or wrong? I.e., is caching on-link information any worse 
> than caching the generated addresses? The PIO has Lifetime fields, and 
> as long as they are honored... ANd indeed, that is what point 4 
> reinforces...
> 
> <hs>True, but what if someone has manually configured an IPv6 address 
> with prefix length, what are the Lifetime values for such a prefix? I 
> am not sure what happens here. Why not be then explicit and include 
> such a bullet. Also, the subject of our draft is focused on on-link 
> determination so we added such a bullet for completeness sake since
> RFC4862 mentions persistent data across initializations. It is RFC4861 
> that deals with on-link determination. So why not have RFC4861 have 
> such text for on-link determination related to persistent storage.
> </hs>
> 
> <wb>
> What if there are cache-inconsistency problems, prefix renumbering, or 
> stale information?  I think it's better just to get rid of caching 
> on-link information in stable storage and get such information fresh 
> from RA's.  That way, administrators can better rationalize the 
> behavior of their network from the configured RA's.
> </wb>

The same argument applies to caching the address, so it cannot be a reason why we specifically prohibit the (on-link) prefix part of this behavior.  

<wb>
We agree - and we believe implementations shouldn't be caching the address either - but, unfortunately, the text of RFC4862 already allows it and an implementation already does it - so that is something we cannot change.  However, our draft is dealing with on-link determination and we've shown clear problems with caching on-link determination.  RFC4861 and RFC4862 do not mention caching on-link information, so we can add this rule to our draft.
</wb>

Actually, I see it can rather be harmful if we only prohibit the on-link prefix part of this behavior.  Recall that the background motivation of address caching is that it may help the situation of a temporary outage of a router.  Now that we've deprecated the 'on-link by default' behavior, if the host doesn't also cache the on-link information, the cached address is almost meaningless.

<wb>
Again, they probably shouldn't be caching the address anyway - but that's an argument for another day.  We have already given our justification why on-link determination should not be cached.
</wb>

I'm not necessarily a fan of this tricky behavior, but prohibiting one aspect of feature that will make the other aspect meaningless makes logically no sense to me.

So, I tend to agree with Thomas here:

> I don't see right off why rule 3 is needed.

After all, such caching is a minor implementation detail.  I suspect it doesn't do any harm in practice even if we remove this dicey bullet.

<wb>
No - screwing up on-link determination is not a minor thing nor caching of it. See section 3 of our draft where we give one example of how data forwarding by a host may totally break down if a wrong on-link determination is made.
</wb>

Another note about the wording if still decide to keep this point:
this bullet does not correctly reflect the sense of the referred part of RFC4862: "Note that section 5.7 of [RFC4862] describes the use of stable storage for addresses acquired with stateless address autoconfiguration..."  The intent of Section 5.7 of RFC4862 was not to "describe" this behavior.  It was written because there was one known implementation that supports this behavior and we thought it might be useful to make note **just in case** other implementations want to do the same thing.  This is why this section uses weak wording such as "An implementation ... may want to retain..." and makes an explicit note of "Further details on this kind of extension are beyond the scope of this document."

As stated above, I'd rather suggest remove this bullet, in which case this concern will be resolved automatically.  But if we keep it, I'd like the wording to reflect the original intent of RFC4862.

<wb>
We would like to keep this bullet. But we totally agree with your analysis above related to the intent of section 5.7 of RFC4862. We have replaced the word "describes" in our 3rd bullet with "mentions". See new text below - does this work for you?

                  On-link determination SHOULD NOT 
                  persist across IPv6 interface initializations. 
                  This is a new requirement compared to [RFC4861].
                  Note that section 5.7 of [RFC4862] mentions the 
                  use of stable storage for addresses acquired 
                  with stateless address autoconfiguration but no RFC has any 
                  similar text about retaining or not retaining the on-link
                  prefixes.
</wb>

Thanks.

Wes & Hemant

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

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Wed, 09 Jul 2008 17:34:37 -0700

At Wed, 9 Jul 2008 10:08:02 -0400,
"Wes Beebee (wbeebee)" <[email-masked]> wrote:

> The same argument applies to caching the address, so it cannot be a
> reason why we specifically prohibit the (on-link) prefix part of
> this behavior.

> <wb>
> We agree - and we believe implementations shouldn't be caching the
> address either - but, unfortunately, the text of RFC4862 already
> allows it and an implementation already does it - so that is
> something we cannot change.  However, our draft is dealing with
> on-link determination and we've shown clear problems with caching
> on-link determination.  RFC4861 and RFC4862 do not mention caching
> on-link information, so we can add this rule to our draft.
> </wb>

Note: as I said in my previous comment, RFC4862 does not *allow*
address caching.  It just makes note when an implementation chooses to
adopt it.

Anyway, I'm not convinced with this logic.  As I pointed out, killing
on-link information caching effectively kills address caching, too, by
making the cached address of almost no use.  Again, I'm personally not
a fan of this caching trick, but effectively killing address caching
with saying "we don't talk about address caching because it's out of
scope of this document" sounds like an unfair action for me.

I'd accept, if

1. we prohibit both address caching and on-link caching (with
   reasonable argument, of course)
or,
2. we don't talk about on-link caching (either allow or prohibit) if
   we don't talk about address caching

but it would be unfair if
3. we prohibit on-link caching while ignoring its effect on address
   caching.

> <wb>
> Again, they probably shouldn't be caching the address anyway - but
> that's an argument for another day.  We have already given our
> justification why on-link determination should not be cached.
> </wb>

Sorry, I've not seen the justification.  At least I don't see it in
the draft.

> <wb>
> No - screwing up on-link determination is not a minor thing nor
> caching of it. See section 3 of our draft where we give one example
> of how data forwarding by a host may totally break down if a wrong
> on-link determination is made.
> </wb>

I see the problem described in Section 3 and that's why I basically
support this document.  But I don't understand why this problem
justifies killing on-link caching.

As a meta level comment, my basic understanding of the purpose of this
document is to clarify a subtle point in the existing RFC(s) that can
be misinterpreted by implementors and can cause problems in the real
world operation.  I support that, but I'm not really comfortable if
this document tries to set new rules or amend the published document
as long as we deem this document as a "clarification".  Of course, I
don't oppose to that discussion per se, which will eventually be
necessary anyway, but that should be performed more explicitly and
with seeking consensus among implementors that might be affected by
that action.  I'd like this document to concentrate on its
"clarification" work.

---
JINMEI, Tatuya

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Wed, 9 Jul 2008 20:54:04 -0400

Tatuya,

Thanks for the reply. Let's see if we can meet common ground with you.

Our justification for prohibiting on-link caching is only in emails to
6man as follows:

 "What if there are cache-inconsistency problems, prefix renumbering, 
 or stale information?  I think it's better just to get rid of 
 caching on-link information in stable storage and get such 
 information fresh from RA's.  That way, administrators can better 
 rationalize the behavior of their network from the configured RA's." 

We can add such text to the draft against bullet 3 and also add text
that even address SHOULD NOT be cached like we say for on-link
determination. Notice our rule is also not very strict by saying "MUST
NOT". It's a SHOULD NOT. With the SHOULD NOT also including address, we
still do not go against any existing RFC and also allow an existing
implementation to still cache the address if the implementation wants
to.

    3. On-link determination and IPv6 address SHOULD NOT persist 
       across IPv6 interface initializations.  This is a new requirement

       compared to [RFC4861].  If such information is cached, there is 
       risk associated with cache-inconsistency problems, prefix
renumbering, 
       or stale information.  It is better to just get information fresh

       from RA's.  That way, administrators can better rationalize the
behavior 
       of their network from the configured RA's.

Thanks.

Hemant

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Wednesday, July 09, 2008 8:35 PM
To: Wes Beebee (wbeebee)
Cc: Hemant Singh (shemant); Thomas Narten; Brian Haberman; Bob Hinden;
[email-masked]

At Wed, 9 Jul 2008 10:08:02 -0400,
"Wes Beebee (wbeebee)" <[email-masked]> wrote:

> > <wb>
> > What if there are cache-inconsistency problems, prefix renumbering, 
> > or stale information?  I think it's better just to get rid of 
> > caching on-link information in stable storage and get such 
> > information fresh from RA's.  That way, administrators can better 
> > rationalize the behavior of their network from the configured RA's.
> > </wb>
> 
> reason why we specifically prohibit the (on-link) prefix part of this 
> behavior.

> allows it and an implementation already does it - so that is something

> we cannot change.  However, our draft is dealing with on-link 
> determination and we've shown clear problems with caching on-link 
> determination.  RFC4861 and RFC4862 do not mention caching on-link 
> information, so we can add this rule to our draft.
> </wb>

Note: as I said in my previous comment, RFC4862 does not *allow* address
caching.  It just makes note when an implementation chooses to adopt it.

Anyway, I'm not convinced with this logic.  As I pointed out, killing
on-link information caching effectively kills address caching, too, by
making the cached address of almost no use.  Again, I'm personally not a
fan of this caching trick, but effectively killing address caching with
saying "we don't talk about address caching because it's out of scope of
this document" sounds like an unfair action for me.

I'd accept, if

> justification why on-link determination should not be cached.

Sorry, I've not seen the justification.  At least I don't see it in the
draft.

> caching of it. See section 3 of our draft where we give one example of

> how data forwarding by a host may totally break down if a wrong 

As a meta level comment, my basic understanding of the purpose of this
document is to clarify a subtle point in the existing RFC(s) that can be
misinterpreted by implementors and can cause problems in the real world
operation.  I support that, but I'm not really comfortable if this
document tries to set new rules or amend the published document as long
as we deem this document as a "clarification".  Of course, I don't
oppose to that discussion per se, which will eventually be necessary
anyway, but that should be performed more explicitly and with seeking
consensus among implementors that might be affected by that action.  I'd
like this document to concentrate on its "clarification" work.

---
JINMEI, Tatuya

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Wed, 9 Jul 2008 21:13:21 -0400

Also, when Suresh Krishnan pointed out that he supports bullet 3, he
made us explicitly mention in the bullet that it's a new rule. We have
been clear in the draft where there is a new rule and where it's
clarification. Besides this new rule, the rest of the draft is
clarification.

Hemant 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Hemant Singh (shemant)
Sent: Wednesday, July 09, 2008 8:54 PM
To: [email-masked]; Wes Beebee (wbeebee)
Cc: Thomas Narten; [email-masked]; Brian Haberman; Bob Hinden
Subject: RE: 6MAN WG Last Call:draft-ietf-6man-ipv6-subnet-model-00.txt

Tatuya,

 "What if there are cache-inconsistency problems, prefix renumbering,
or stale information?  I think it's better just to get rid of  caching
on-link information in stable storage and get such  information fresh
from RA's.  That way, administrators can better  rationalize the
behavior of their network from the configured RA's." 

Thanks.

Hemant

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Wednesday, July 09, 2008 8:35 PM
To: Wes Beebee (wbeebee)
Cc: Hemant Singh (shemant); Thomas Narten; Brian Haberman; Bob Hinden;
[email-masked]

I'd accept, if

---
JINMEI, Tatuya

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Wed, 09 Jul 2008 22:15:00 -0700

At Wed, 9 Jul 2008 20:54:04 -0400,

>  rationalize the behavior of their network from the configured RA's." 

And I replied to this justification, saying this itself cannot justify
killing on-link caching while (perhaps implicitly) allowing address
caching.

> clarification. Besides this new rule, the rest of the draft is

Suresh has his right to express his opinion, of course, and so do I.
I would not like this document to set new rules (note, again, that I'm
not objecting to discussing new changes to RFC4861/4862.  I'm simply
objecting to doing that in this document).

---
JINMEI, Tatuya

---

From: Suresh Krishnan <[email-masked]>
Date: Thu, 10 Jul 2008 11:55:56 -0400

Hi Tatuya,

> objecting to doing that in this document).

Of course :-). I was not sure about this either, but I was fine with 
leaving this in as long as it explicitly stated it is a new rule. But I 
agree with you in principle.

Cheers
Suresh

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Thu, 10 Jul 2008 12:09:01 -0400

Tatuya,

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 old text of bullet 3 was:

       On-link determination SHOULD NOT persist across IPv6 interface

New text is as follows:

                  If on-link determination persists across IPv6
interface initializations,
                  then lack of IPv6 connectivity can result.  For
example, a host receives
                  an RA from a router with on-link prefix A.  The host
reboots.  During the 
                  reboot, the router sends out prefix A with on-link bit
set and a zero 
                  lifetime to indicate a renumbering.  The host misses
the renumbering.  
                  The host comes online.  Then, the router sends an RA
with no PIO.
                  The host uses cached on-link prefix A and issues NS's
instead of sending
                  traffic to a default router.  The "Observed Incorrect
Implementation Behavior"
                  section below describes how this can result in lack of
IPv6 connectivity. 

Hemant

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Thursday, July 10, 2008 1:15 AM
To: Hemant Singh (shemant)
Cc: Wes Beebee (wbeebee); Thomas Narten; Brian Haberman; Bob Hinden;
[email-masked]

---
JINMEI, Tatuya

---

From: "Wes Beebee (wbeebee)" <[email-masked]>
Date: Thu, 10 Jul 2008 13:38:52 -0400

We're against blind caching and re-use of unverified (and possibly
bogus) information.  If that information is deprecated and later
verified (as it is in DNA) - then the information can be re-used without
a problem.

Tatuya - 
In the new text, we have eliminated any normative language.  Therefore,
the draft is simply clarifying this point by demonstrating via example
what can go wrong if unverified cached information is later reused
blindly.

We have also changed the title of section 2 from "Host Behavior Rules"
to "Host Behavior and Rules".

- Wes 

-----Original Message-----
From: Hemant Singh (shemant) 
Sent: Thursday, July 10, 2008 12:09 PM
To: [email-masked]'; 'Suresh Krishnan'
Cc: Wes Beebee (wbeebee); Thomas Narten; Brian Haberman; Bob Hinden;
[email-masked]

Tatuya,

New text is as follows:

Hemant

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Thursday, July 10, 2008 1:15 AM
To: Hemant Singh (shemant)
Cc: Wes Beebee (wbeebee); Thomas Narten; Brian Haberman; Bob Hinden;
[email-masked]

---
JINMEI, Tatuya

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Thu, 10 Jul 2008 12:53:53 -0700

At Thu, 10 Jul 2008 12:09:01 -0400,

> 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

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Thu, 10 Jul 2008 16:06:00 -0400

Jinmei,

Thanks for the comment. 

For this comment from you:

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

Yes, we have realized that and moved the bullet entirely out of the list
of bullets and moved the text to end of section 2. Here is the new
section 2.

2.  Host Behavior and Rules

   A correctly implemented IPv6 host MUST adhere to the following rules:

   1.  By default only the link-local prefix is on-link.

   2.  The configuration of an IPv6 address, whether through IPv6
       stateless address autoconfiguration [RFC4862], DHCPv6 [RFC3315],
       or manual configuration MUST NOT implicitely cause a prefix
       derived from that address to be treated as on-link.  A host
       considers a prefix to be on-link only through explicit means,
       such as those specified in the on-link definition in the
       Terminology section of [RFC4861] or via manual configuration.
       Note that the requirement for manually configured addresses is
       not explicitly mentioned in [RFC4861].

   3.  In the absence of other sources of on-link information, including
       Redirects, if the RA advertises a prefix with the on-link(L) bit
       set and later the Valid Lifetime expires, the host MUST then
       consider addresses of the prefix to be off-link, as specified by
       the PIO paragraph of section 6.3.4 of [RFC4861].

   4.  Newer implementations, which are compliant with [RFC4861] MUST
       adhere to the following rules.  Older implementations, which are
       compliant with [RFC2461] but not [RFC4861] may remain as is.  If
       the Default Router List is empty and there is no other source of
       on-link information about any address or prefix:

       1.  The host MUST NOT assume that all destinations are on-link.

       2.  The host MUST NOT perform address resolution for non-link-
           local addresses.

       3.  Since the host cannot assume the destination is on-link, and
           off-link traffic cannot be sent to a default router (since
           the Default Router List is empty), address resolution cannot
           be performed.  This case is specified in the last paragraph
           of section 4 of [RFC4943]: when there is no route to
           destination, the host should send an ICMPv6 Destination
           Unreachable indication (for example, a locally delivered
           error message) as specified in the Terminology section of
           [RFC4861].

       On-link information concerning particular addresses and prefixes

Singh, et al.           Expires January 11, 2009                [Page 4]

Internet-Draft              IPv6 Subnet Model                  July 2008

       can make those specific addresses and prefixes on-link, but does
       not change the default behavior mentioned above for addresses and
       prefixes not specified.  [RFC4943] provides justification for
       these rules.

   Using cached on-link determination information without first
   verifying that the information is still valid after IPv6 interface
   re-initialization may lead to lack of IPv6 network connectivity.  For
   example, a host receives an RA from a router with on-link prefix A.
   The host reboots.  During the reboot, the router sends out prefix A
   with on-link bit set and a zero lifetime to indicate a renumbering.
   The host misses the renumbering.  The host comes online.  Then, the
   router sends an RA with no PIO.  The host uses cached on-link prefix
   A and issues NS's instead of sending traffic to a default router.
   The "Observed Incorrect Implementation Behavior" section below
   describes how this can result in lack of IPv6 connectivity.

Hemant

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Thursday, July 10, 2008 3:54 PM
To: Hemant Singh (shemant)
Cc: Suresh Krishnan; Wes Beebee (wbeebee); Thomas Narten; Brian
Haberman; Bob Hinden; [email-masked]
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)" <[email-masked]> wrote:

> 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

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

---

From: "Wes Beebee (wbeebee)" <[email-masked]>
Date: Thu, 10 Jul 2008 16:21:35 -0400

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:[email-masked]] 
Sent: Thursday, July 10, 2008 3:54 PM
To: Hemant Singh (shemant)
Cc: Suresh Krishnan; Wes Beebee (wbeebee); Thomas Narten; Brian Haberman; Bob Hinden; [email-masked]
Subject: Re: 6MAN WG Last Call:draft-ietf-6man-ipv6-subnet-model-00.txt

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

---

From: Erik Nordmark <[email-masked]>
Date: Mon, 14 Jul 2008 03:30:50 -0700

Jinmei,

there are currently two places where we treat autoconfigured addresses 
differently than on-link prefixes.
One is the text about storing the address and associated lifetime in RFC 
4862 that we are debating here.
The other one is the 2 hour rule that was very explicitly added only for 
the addrconf property of the prefix and not the on-link property.

I don't recall the different treatment for the first case.
But for the second case I clearly recall the argument that loosing the 
IP address (by an accidental or malicious RA with a zero valid lifetime 
for the prefix) was considered a lot worse than loosing the on-link 
property. Basically that loosing the IP address for a short time (it 
might be re-added by the next RA) is something we must avoid, but that 
"routing" (the on-link property) is something which must be able to 
recover from temporary failures in any case.

[I don't know if the same argument was present when the storing of 
addresses was discussed.]

> 3. we prohibit on-link caching while ignoring its effect on address

If we are going to require that all aspects of a prefix should be 
treated identically then to be consistent we must also make the 2 hour 
rule be consistent (by either removing it for the addrconf property or 
adding it to the on-link property).

FWIW I think forcing such consistency is not necessary; it would just 
result in unneeded changes to already deployed standards.

Is your concern that there are deployed implementations which store 
on-link prefixes across reboots?

Regards,
    Erik

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Thu, 17 Jul 2008 14:06:11 -0400

Tatuya,

Another ping on this one.

>From the new section 2 text of our draft below, I have snipped a
paragraph that needs closure. The new text brings our draft to same
feature parity as DNA. The new text has no Normative requirements and
also justifies why we need the new text - the justification has said the
same problem described in section 3 of our draft can occur if blind
caching is done. So why is this justification not enough? Please see if
the new para below works to be added to the end of section 2 as shown in
my original email from July 10th.

Thanks.

Hemant 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Hemant Singh (shemant)
Sent: Thursday, July 10, 2008 4:06 PM
To: [email-masked]
Cc: Thomas Narten; [email-masked]; Suresh Krishnan; Bob Hinden; Brian
Haberman
Subject: RE: 6MAN WG Last Call:draft-ietf-6man-ipv6-subnet-model-00.txt

Jinmei,

Thanks for the comment. 



Hemant

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Thursday, July 10, 2008 3:54 PM
To: Hemant Singh (shemant)
Cc: Suresh Krishnan; Wes Beebee (wbeebee); Thomas Narten; Brian

---
JINMEI, Tatuya

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Thu, 17 Jul 2008 18:43:49 -0700

At Thu, 10 Jul 2008 16:21:35 -0400,
"Wes Beebee (wbeebee)" <[email-masked]> wrote:

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

You're using inappropriate examples to justify the proposed text:

This reads to me that the outage is a pretty short time (i.e., while
the host is rebooting), while assuming the administrator stops
advertising the 0-lifetime RAs so quickly.  That's why I said "what's
wrong in this scenario is that the router doesn't keep advertising
0-lifetime-prefixes sufficiently long".

Even if in the vacation case, the administrator shouldn't stop
advertising 0-lifetime RAs as long as some hosts may keep an old
address or prefix.  Note that they don't have to predict anything
about the users' vacation plan to do so: the necessary period can be
calculated from the previously advertised lifetime and the time when
the renumbering procedure starts.

Having said that, I see your point if we are mainly considering a case
of reconnecting after a long term absence such as a vacation.  Even
though the administrator should keep advertising 0-lifetime RAs to
avoid confusion, it should also be advisable for the host to purge the
old information (or at least confirm whether it's still valid).

So, for example, if the proposed text were something like this:

   Using cached on-link determination information without first
   verifying that the information is still valid after IPv6 interface
   re-initialization may lead to lack of IPv6 network connectivity.  For
   example, consider the case where a host caches an on-link prefix
   and leaves the subnet for weeks.  If the network renumbers during
   the period but the host continues to keep the cached (already
   invalid) information when it returns, it may lead to a problem
   described in Section 3 below.

that would make sense to me.  I'd then be wondering whether this is
really something to be noted explicitly since it may sound something
pretty obvious.

---
JINMEI, Tatuya

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Thu, 17 Jul 2008 18:45:01 -0700

At Thu, 17 Jul 2008 14:06:11 -0400,

> Another ping on this one.

Sorry for the long delay.  I just sent to a reply to the response from
Wes.  I believe it also covers your point.

---
JINMEI, Tatuya

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Thu, 17 Jul 2008 19:28:06 -0700

At Mon, 14 Jul 2008 03:30:50 -0700,

> recover from temporary failures in any case.

Yes, I recall that discussion, too.

> result in unneeded changes to already deployed standards.

There's a subtle difference.  In the two-hour-rule case, we assume we
have a working router.  So even if the host looses its on-link prefix
information, it can still send packets to the router, having it
forward the packets and/or send a redirect back, etc.

In the address storing case, (at least in my understanding) we
consider the case when a router is temporarily out of service.  And
since we dropped the on-link-by-default rule, the cached address will
effectively be of no use.

> on-link prefixes across reboots?

No, it's rather a meta level concern.  What I wanted to say (in case I
was not clear) is that we should not pretend that killing on-link
prefix caching is independent from address caching.  If we kill the
former, we will effectively also kill the latter (which has
implementors - note: we don't implement it).  So, IMO, if this
document wants to kill on-link caching, it should at least note that
it also kills address caching in effect.  If implementors of address
caching still think it's acceptable, then I have no objection to that
(I have no stake in that area, anyway).

I hope I'm clear this time.

---
JINMEI, Tatuya

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Fri, 18 Jul 2008 10:36:42 -0400

Tatuya & Erik,

Note, that our document is not killing on-link determination caching due
to two reasons:

1. We don't have any Normative text.
2. Killing means don't use cached information. Our new text is saying,
after re-init, deprecate cached information temporarily, verify
information, and if information is verified, then use cached
information. As Suresh also corroborated, this is what DNA does.

Please wait for another email from me when I reply to one of your other
emails. 

Further, note the 2-hour rule from RFC4862 does not apply in RFC4861 to
Lifetime. The Lifetime also affects on-link determination because if a
prefix expires the host sends data to a default router rather than
issuing an NS to resolve a non-link-local destination. See this text
snipped from section 6.3.4 of RFC4861.

  [Stateless address autoconfiguration [ADDRCONF] may in some
   circumstances use a larger Valid Lifetime of a prefix or ignore it
   completely in order to prevent a particular denial-of-service attack.
   However, since the effect of the same denial of service targeted at
   the on-link prefix list is not catastrophic (hosts would send packets
   to a default router and receive a redirect rather than sending
   packets directly to a neighbor), the Neighbor Discovery protocol does
   not impose such a check on the prefix lifetime values.  Similarly,
   [ADDRCONF] may impose certain restrictions on the prefix length for
   address configuration purposes.  Therefore, the prefix might be
   rejected by [ADDRCONF] implementation in the host.  However, the
   prefix length is still valid for on-link determination when combined
   with other flags in the prefix option.

      Note: Implementations can choose to process the on-link aspects of
      the prefixes separately from the stateless address
      autoconfiguration aspects of the prefixes by, e.g., passing a copy
      of each valid Router Advertisement message to both an "on-link"
      and an "addrconf" function.  Each function can then operate
      independently on the prefixes that have the appropriate flag set.]

Hemant

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
[email-masked]
Sent: Thursday, July 17, 2008 10:28 PM
To: Erik Nordmark
Cc: Thomas Narten; Bob Hinden; [email-masked]; Brian Haberman
Subject: Re: 6MAN WG Last Call:draft-ietf-6man-ipv6-subnet-model-00.txt

> The other one is the 2 hour rule that was very explicitly added only 
> for the addrconf property of the prefix and not the on-link property.
> 

> IP address (by an accidental or malicious RA with a zero valid 
> lifetime for the prefix) was considered a lot worse than loosing the 
> on-link property. Basically that loosing the IP address for a short 
> time (it might be re-added by the next RA) is something we must avoid,

> but that "routing" (the on-link property) is something which must be 
> able to recover from temporary failures in any case.

There's a subtle difference.  In the two-hour-rule case, we assume we
have a working router.  So even if the host looses its on-link prefix
information, it can still send packets to the router, having it forward
the packets and/or send a redirect back, etc.

In the address storing case, (at least in my understanding) we consider
the case when a router is temporarily out of service.  And since we
dropped the on-link-by-default rule, the cached address will effectively
be of no use.

No, it's rather a meta level concern.  What I wanted to say (in case I
was not clear) is that we should not pretend that killing on-link prefix
caching is independent from address caching.  If we kill the former, we
will effectively also kill the latter (which has implementors - note: we
don't implement it).  So, IMO, if this document wants to kill on-link
caching, it should at least note that it also kills address caching in
effect.  If implementors of address caching still think it's acceptable,
then I have no objection to that (I have no stake in that area, anyway).

---
JINMEI, Tatuya

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Fri, 18 Jul 2008 11:19:45 -0400

Tatuya,

Thanks for all your email. Please see in line between <hs> and </hs>.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Thursday, July 17, 2008 9:44 PM
To: Wes Beebee (wbeebee)
Cc: Hemant Singh (shemant); Suresh Krishnan; Thomas Narten; Brian

At Thu, 10 Jul 2008 16:21:35 -0400,
"Wes Beebee (wbeebee)" <[email-masked]> wrote:

> 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
Tatuya
> last more than a day.
> advance, how long I may be on vacation so that the RA deprecating the 
> old prefix can last long enough.  That puts an unreasonable 
> to have to get permission from my network administrator in order to go

> on vacation.

<hs>
Agreed. However, Wes did make a point that these are problems FAR more
likely to happen and also gave examples of timeframes that are much
longer than the reload time for a host. Like weeks of vacation or 6-8
hours every night. 
</hs>

This reads to me that the outage is a pretty short time (i.e., while the
host is rebooting), while assuming the administrator stops advertising
the 0-lifetime RAs so quickly.  That's why I said "what's wrong in this
scenario is that the router doesn't keep advertising 0-lifetime-prefixes
sufficiently long".

Even if in the vacation case, the administrator shouldn't stop
advertising 0-lifetime RAs as long as some hosts may keep an old address
or prefix.  Note that they don't have to predict anything about the
users' vacation plan to do so: the necessary period can be calculated
from the previously advertised lifetime and the time when the
renumbering procedure starts.

Having said that, I see your point if we are mainly considering a case
of reconnecting after a long term absence such as a vacation.  Even
though the administrator should keep advertising 0-lifetime RAs to avoid
confusion, it should also be advisable for the host to purge the old
information (or at least confirm whether it's still valid).

<hs>
We just don't want to completely rely on an admin of the router network
to do the right thing and not say, fat-finger any configuration. Soon as
any admin mis-configuration is done, we can get into the problem of
Section 3 and data forwarding stops. The host should be defensive as
well. The goal of our draft it to cover any case that can cause the
problem of Section 3. We see blind caching of on-link determination as a
candidate that may cause the problem.
</hs>

<hs>
The renumbering may sound obvious to you after we have discussed the
case of overnight shutdown and vacation and gave a specific example of
prior and post RA (with PIO and without PIO). Anyway, this is the
example in the paragraph. The main point is that blind caching of
on-link determination is not recommended host behavior. We would like to
keep this text  - your proposed text looks fine to me. We may modify
your proposed text by giving a specific prior and post RA example.

Further, since RFC4862 and RFC4861 differ in the 2-hour rule for address
autoconfiguration vs. on-link determination, why is it not OK to only
mention on-link determination blind caching in our draft and not mention
any address with blind caching? I am not too strong on this one. If we
are allowed to keep our text and you still insist we add address to
blind caching paragraph, I can do that. But note, even when we add
address to the blind caching paragraph, there is no normative text in
our paragraph that overrules anything related to caching addresses in
RFC4862. So why do any host implementors have to worry about anything?
Wes is on vacation till Wednesday next week. My statements here only
represent me. I need to talk to Erik and Wes too about this one. 
</hs>

Hemant

---
JINMEI, Tatuya

---

From: "Wes Beebee (wbeebee)" <[email-masked]>
Date: Fri, 25 Jul 2008 09:45:03 -0400

Sounds good to me...  We mainly want to say blind caching of on-link
determination is bad,
but verifying that it's still good (as DNA does) will fix the problem.

I'm happy with adopting Tatuya's new text.  After all, an administrator
may set the lifetime of 
a prefix to 0xFFFFFFFF (infinity) - which means that the renumbering
state would have to go
on forever in order to deprecate the prefix and be sure that every host
will get the information.

At least if hosts verify the information is still good, then the
administrator could end the renumbering
in a reasonable time frame and hopefully the affected hosts will be able
to recover.

Also, my example was one person going on vacation - but if Comcast ends
up doing this, they 
could end up having to deal with any of 10 million+ people turning on
and off their computers...

I appreciate that we were able to reach consensus on this and close on
this issue.

Thanks,
- Wes

> _____________________________________________ 
> Sent:	Friday, July 18, 2008 11:20 AM
> To:	[email-masked]'; Wes Beebee (wbeebee)
> Cc:	Suresh Krishnan; Thomas Narten; Brian Haberman; Bob Hinden;
> [email-masked]
> Subject:	RE: 6MAN WG Last
> Call:draft-ietf-6man-ipv6-subnet-model-00.txt
> 
> Tatuya,
> 
> Subject: Re: 6MAN WG Last
> Call:draft-ietf-6man-ipv6-subnet-model-00.txt
> 
> morning 
> the 
> go 
> We just don't want to completely rely on an admin of the router
> network to do the right thing and not say, fat-finger any
> configuration. Soon as any admin mis-configuration is done, we can get
> into the problem of Section 3 and data forwarding stops. The host
> should be defensive as well. The goal of our draft it to cover any
> case that can cause the problem of Section 3. We see blind caching of
> on-link determination as a candidate that may cause the problem.
> </hs>
> 
> on-link determination is not recommended host behavior. We would like
> to keep this text  - your proposed text looks fine to me. We may
> modify your proposed text by giving a specific prior and post RA
> example.
> 
> Further, since RFC4862 and RFC4861 differ in the 2-hour rule for
> address autoconfiguration vs. on-link determination, why is it not OK
> to only mention on-link determination blind caching in our draft and
> not mention any address with blind caching? I am not too strong on
> this one. If we are allowed to keep our text and you still insist we
> add address to blind caching paragraph, I can do that. But note, even
> when we add address to the blind caching paragraph, there is no
> normative text in our paragraph that overrules anything related to
> caching addresses in RFC4862. So why do any host implementors have to
> worry about anything?

---

From: "Azinger, Marla" <[email-masked]>
Date: Wed, 30 Jul 2008 10:14:08 -0400

Hello-

This may be nit picky but I have a request to change the title of this document.

Reason why is because in my world and around the RIR's when someone says "subnet model" it actually refers to a model of subnetting plans and diagrams.

Could this title possibly be changed to directly reflect what exactly its about?

For example:

IPv6 Prefix and its effect on Link-Local

or

IPV6 Prefix Cause and Effect on Links

Thank you for considering this change

Marla Azinger
Frontier Communications

________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of Wes Beebee (wbeebee)
Sent: Friday, July 25, 2008 6:45 AM
To: Hemant Singh (shemant); [email-masked]
Cc: Thomas Narten; [email-masked]; Brian Haberman; Bob Hinden; Suresh Krishnan
Subject: RE: 6MAN WG Last Call:draft-ietf-6man-ipv6-subnet-model-00.txt

Sounds good to me...  We mainly want to say blind caching of on-link determination is bad,
but verifying that it's still good (as DNA does) will fix the problem.

I'm happy with adopting Tatuya's new text.  After all, an administrator may set the lifetime of
a prefix to 0xFFFFFFFF (infinity) - which means that the renumbering state would have to go
on forever in order to deprecate the prefix and be sure that every host will get the information.

At least if hosts verify the information is still good, then the administrator could end the renumbering
in a reasonable time frame and hopefully the affected hosts will be able to recover.

Also, my example was one person going on vacation - but if Comcast ends up doing this, they
could end up having to deal with any of 10 million+ people turning on and off their computers...

I appreciate that we were able to reach consensus on this and close on this issue.

Thanks,
- Wes

Cc:     Suresh Krishnan; Thomas Narten; Brian Haberman; Bob Hinden; [email-masked]

Tatuya,

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Thursday, July 17, 2008 9:44 PM
To: Wes Beebee (wbeebee)
Cc: Hemant Singh (shemant); Suresh Krishnan; Thomas Narten; Brian Haberman; Bob Hinden; [email-masked]
Subject: Re: 6MAN WG Last Call:draft-ietf-6man-ipv6-subnet-model-00.txt

At Thu, 10 Jul 2008 16:21:35 -0400,
"Wes Beebee (wbeebee)" <[email-masked]> wrote:

> Furthermore, I occasionally go on vacations too - so the outage may Tatuya
> last more than a day.
>

<hs>
Agreed. However, Wes did make a point that these are problems FAR more likely to happen and also gave examples of timeframes that are much longer than the reload time for a host. Like weeks of vacation or 6-8 hours every night.

</hs>

This reads to me that the outage is a pretty short time (i.e., while the host is rebooting), while assuming the administrator stops advertising the 0-lifetime RAs so quickly.  That's why I said "what's wrong in this scenario is that the router doesn't keep advertising 0-lifetime-prefixes sufficiently long".

Even if in the vacation case, the administrator shouldn't stop advertising 0-lifetime RAs as long as some hosts may keep an old address or prefix.  Note that they don't have to predict anything about the users' vacation plan to do so: the necessary period can be calculated from the previously advertised lifetime and the time when the renumbering procedure starts.

Having said that, I see your point if we are mainly considering a case of reconnecting after a long term absence such as a vacation.  Even though the administrator should keep advertising 0-lifetime RAs to avoid confusion, it should also be advisable for the host to purge the old information (or at least confirm whether it's still valid).

<hs>
We just don't want to completely rely on an admin of the router network to do the right thing and not say, fat-finger any configuration. Soon as any admin mis-configuration is done, we can get into the problem of Section 3 and data forwarding stops. The host should be defensive as well. The goal of our draft it to cover any case that can cause the problem of Section 3. We see blind caching of on-link determination as a candidate that may cause the problem.

</hs>

that would make sense to me.  I'd then be wondering whether this is really something to be noted explicitly since it may sound something pretty obvious.

<hs>
The renumbering may sound obvious to you after we have discussed the case of overnight shutdown and vacation and gave a specific example of prior and post RA (with PIO and without PIO). Anyway, this is the example in the paragraph. The main point is that blind caching of on-link determination is not recommended host behavior. We would like to keep this text  - your proposed text looks fine to me. We may modify your proposed text by giving a specific prior and post RA example.

Further, since RFC4862 and RFC4861 differ in the 2-hour rule for address autoconfiguration vs. on-link determination, why is it not OK to only mention on-link determination blind caching in our draft and not mention any address with blind caching? I am not too strong on this one. If we are allowed to keep our text and you still insist we add address to blind caching paragraph, I can do that. But note, even when we add address to the blind caching paragraph, there is no normative text in our paragraph that overrules anything related to caching addresses in RFC4862. So why do any host implementors have to worry about anything?

Wes is on vacation till Wednesday next week. My statements here only represent me. I need to talk to Erik and Wes too about this one.

</hs>

Hemant

---
JINMEI, Tatuya