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

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.

   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.

Thanks.

Hemant 

-----Original Message-----
From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of
Hemant Singh (shemant)
Sent: Thursday, July 10, 2008 4:06 PM
To: Jinmei_Tatuya@isc.org
Cc: Thomas Narten; ipv6@ietf.org; 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. 

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: Jinmei_Tatuya@isc.org [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
--------------------------------------------------------------------
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------