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

"Hemant Singh (shemant)" <> Fri, 18 July 2008 14:36 UTC

Return-Path: <>
Received: from [] (localhost []) by (Postfix) with ESMTP id 384343A69D8; Fri, 18 Jul 2008 07:36:14 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 87F603A69D8 for <>; Fri, 18 Jul 2008 07:36:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -5.864
X-Spam-Status: No, score=-5.864 tagged_above=-999 required=5 tests=[AWL=0.735, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id P7p54GRcoUyQ for <>; Fri, 18 Jul 2008 07:36:12 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 5BED43A68A9 for <>; Fri, 18 Jul 2008 07:36:12 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.31,210,1215388800"; d="scan'208";a="18233839"
Received: from ([]) by with ESMTP; 18 Jul 2008 14:36:45 +0000
Received: from ( []) by (8.12.11/8.12.11) with ESMTP id m6IEajSW015438; Fri, 18 Jul 2008 07:36:45 -0700
Received: from ( []) by (8.13.8/8.13.8) with ESMTP id m6IEah5i013650; Fri, 18 Jul 2008 14:36:45 GMT
Received: from ([]) by with Microsoft SMTPSVC(6.0.3790.1830); Fri, 18 Jul 2008 10:36:43 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Subject: RE: 6MAN WG Last Call:draft-ietf-6man-ipv6-subnet-model-00.txt
Date: Fri, 18 Jul 2008 10:36:42 -0400
Message-ID: <>
In-Reply-To: <>
Thread-Topic: 6MAN WG Last Call:draft-ietf-6man-ipv6-subnet-model-00.txt
Thread-Index: AcjoffIht3XLj5syRRGbvqLpvK5DRwAY69Eg
References: <><> <> <>
From: "Hemant Singh (shemant)" <>
To: <>, "Erik Nordmark" <>
X-OriginalArrivalTime: 18 Jul 2008 14:36:43.0193 (UTC) FILETIME=[B29D4290:01C8E8E3]
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=5932; t=1216391805; x=1217255805; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;;; z=From:=20=22Hemant=20Singh=20(shemant)=22=20<shemant@cisco. com> |Subject:=20RE=3A=206MAN=20WG=20Last=20Call=3Adraft-ietf-6m an-ipv6-subnet-model-00.txt |Sender:=20; bh=XJSXBSuDo9rz2O8CzcHue172o8diKwVH5XsiBzYnv1Q=; b=V2O1dQmHQikwYzXSqGYmIgjXT3R36iqXYPfgstNemiQR/oCa6sX5lTJZtz ADbk9GjrhRbRcYZqMzLvpzkuOjvkqBMoDGvhmLtg6DbllaE+y6hzk56Er6/5 FD1oxb47cS;
Authentication-Results: sj-dkim-3;; dkim=pass ( sig from verified; );
Cc: Thomas Narten <>,, Brian Haberman <>, Bob Hinden <>
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit

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

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


-----Original Message-----
From: [] On Behalf Of
Sent: Thursday, July 17, 2008 10:28 PM
To: Erik Nordmark
Cc: Thomas Narten; Bob Hinden;; 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 <>; 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 
> 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
Administrative Requests:
IETF IPv6 working group mailing list
Administrative Requests: