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

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: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of
Jinmei_Tatuya@isc.org
Sent: Thursday, July 17, 2008 10:28 PM
To: Erik Nordmark
Cc: Thomas Narten; Bob Hinden; ipv6@ietf.org; Brian Haberman
Subject: Re: 6MAN WG Last Call:draft-ietf-6man-ipv6-subnet-model-00.txt

At Mon, 14 Jul 2008 03:30:50 -0700,
Erik Nordmark <erik.nordmark@sun.com> wrote:

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

Yes, I recall that discussion, too.

> [I don't know if the same argument was present when the storing of 
> addresses was discussed.]
> 
> > 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.
> 
> 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.

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.

> Is your concern that there are deployed implementations which store 
> 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
Internet Systems Consortium, Inc.
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------