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: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Hemant Singh (shemant) Sent: Thursday, July 10, 2008 4:06 PM To: [EMAIL PROTECTED] 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: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] 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)" <[EMAIL PROTECTED]> 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 --------------------------------------------------------------------