RE: comments on draft-wbeebee-on-link-and-off-link-determination-00
"Hemant Singh (shemant)" <shemant@cisco.com> Thu, 01 November 2007 21:00 UTC
Return-path: <ipv6-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Inh9D-00044Z-4y; Thu, 01 Nov 2007 17:00:15 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Inh9B-00043r-F6 for ipv6@ietf.org; Thu, 01 Nov 2007 17:00:13 -0400
Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Inh95-00027c-4a for ipv6@ietf.org; Thu, 01 Nov 2007 17:00:13 -0400
X-IronPort-AV: E=Sophos;i="4.21,359,1188792000"; d="scan'208";a="136019092"
Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 01 Nov 2007 16:59:48 -0400
Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id lA1KxlVT010734; Thu, 1 Nov 2007 16:59:47 -0400
Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id lA1KxWfJ009065; Thu, 1 Nov 2007 20:59:47 GMT
Received: from xmb-rtp-20e.amer.cisco.com ([64.102.31.40]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 1 Nov 2007 16:59:22 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Thu, 01 Nov 2007 16:59:22 -0400
Message-ID: <B00EDD615E3C5344B0FFCBA910CF7E1D03EDDDD5@xmb-rtp-20e.amer.cisco.com>
In-Reply-To: <B00EDD615E3C5344B0FFCBA910CF7E1D03EDDDD1@xmb-rtp-20e.amer.cisco.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: comments on draft-wbeebee-on-link-and-off-link-determination-00
Thread-Index: AcgZ7vq0hJ/wP5eTSmqqKtWwZ0eseAAges9gAJSZ2xAAAaBmkA==
References: <m11wbeeao8.wl%jinmei@isl.rdc.toshiba.co.jp> <B00EDD615E3C5344B0FFCBA910CF7E1D03EDDD8F@xmb-rtp-20e.amer.cisco.com> <B00EDD615E3C5344B0FFCBA910CF7E1D03EDDDD1@xmb-rtp-20e.amer.cisco.com>
From: "Hemant Singh (shemant)" <shemant@cisco.com>
To: "Hemant Singh (shemant)" <shemant@cisco.com>, jinmei@isl.rdc.toshiba.co.jp, "Wes Beebee (wbeebee)" <wbeebee@cisco.com>
X-OriginalArrivalTime: 01 Nov 2007 20:59:22.0544 (UTC) FILETIME=[140D3300:01C81CCA]
X-TM-AS-Product-Ver: SMEX-8.0.0.1181-5.000.1023-15518.002
X-TM-AS-Result: No--20.243700-8.000000-31
X-TM-AS-User-Approved-Sender: No
X-TM-AS-User-Blocked-Sender: No
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=16225; t=1193950787; x=1194814787; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=shemant@cisco.com; z=From:=20=22Hemant=20Singh=20(shemant)=22=20<shemant@cisco.com> |Subject:=20RE=3A=20comments=20on=20draft-wbeebee-on-link-and-off-link-de termination-00 |Sender:=20 |To:=20=22Hemant=20Singh=20(shemant)=22=20<shemant@cisco.com>, =0A=20=20=2 0=20=20=20=20=20<jinmei@isl.rdc.toshiba.co.jp>, =0A=20=20=20=20=20=20=20=20 =22Wes=20Beebee=20(wbeebee)=22=20<wbeebee@cisco.com>; bh=cvL+/TRIHs2n7tmRNkHWTeHvY7Ki2a0pSw9yDHyTBD0=; b=AYltOiwjhmbn8EXn3jPLIksmGodSW1olTr61DYpk4/4XDDC17SXCBfblgXN6Y8/J0eQhPPGA L2epOjd8119synC4HK1ZI52fWKpD0svpBkiBPPKPWofysHVe8xhADaiy;
Authentication-Results: rtp-dkim-2; header.From=shemant@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; );
X-Spam-Score: -4.0 (----)
X-Scan-Signature: 715d0e6950aaebd45af78ef9318d0186
Cc: ipv6@ietf.org
Subject: RE: comments on draft-wbeebee-on-link-and-off-link-determination-00
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
Errors-To: ipv6-bounces@ietf.org
Sorry folks, The 2nd URL below is same as the first. The two drafts we want reviewed are as follows - this time correctly. http://www.ietf.org/internet-drafts/draft-wbeebee-on-link-and-off-link-d etermination-00.txt http://www.ietf.org/internet-drafts/draft-wbeebee-nd-implementation-prob lems-00.txt Hemant -----Original Message----- From: Hemant Singh (shemant) Sent: Thursday, November 01, 2007 4:18 PM To: Hemant Singh (shemant); jinmei@isl.rdc.toshiba.co.jp; Wes Beebee (wbeebee) Cc: ipv6@ietf.org Subject: RE: comments on draft-wbeebee-on-link-and-off-link-determination-00 Jinmei, Did you get a chance to review our responses to your comments? We need closure from you on our responses so that we can see when to publish a newer revision of this draft. Please see attached .txt file where we have incorporated responses to your comments in a new version - this version is not posted to IETF yet. It's sent out only to help you read a completed version that has incorporated responses to your comments. Anyone else is welcome to review our drafts. We'll wait for a week or two if anyone else has any comments on our two drafts before we publish any newer version. http://www.ietf.org/internet-drafts/draft-wbeebee-on-link-and-off-link-d etermination-00.txt http://www.ietf.org/internet-drafts/draft-wbeebee-on-link-and-off-link-d etermination-00.txt Thanks. Hemant -----Original Message----- From: Hemant Singh (shemant) Sent: Tuesday, October 30, 2007 5:03 PM To: jinmei@isl.rdc.toshiba.co.jp; Wes Beebee (wbeebee) Cc: ipv6@ietf.org Subject: RE: comments on draft-wbeebee-on-link-and-off-link-determination-00 Hi Jinmei, Thanks very much for the review of this draft. Please see in line below for our responses that are preceded by "<hs>" and ended by "</hs>". -----Original Message----- From: jinmei@isl.rdc.toshiba.co.jp [mailto:jinmei@isl.rdc.toshiba.co.jp] Sent: Monday, October 29, 2007 1:45 AM To: Hemant Singh (shemant); Wes Beebee (wbeebee) Cc: ipv6@ietf.org Subject: comments on draft-wbeebee-on-link-and-off-link-determination-00 I've read the draft. Here are my comments on it. - General According to the title and introduction, this draft apparently focuses on issues about on/off-link determination, but there also seem to be other topics, such as address configuration issues or issues about DAD. If the intent is to cover these broader topics, I think the title, abstract, introduction (and perhaps some other part) should be changed accordingly. <hs> We'll keep the title, abstract, introduction etc. as is and move bullets 5 and 6 from section 2 of this draft to the nd-updates draft. </hs> - Section 1 Where behavior has not changed between RFC 2461 [ND] and draft-ietf-ipv6-2461bis-11 [NDbis] and behavior has not changed between RFC 2462 [ADDRCONF] and draft-ietf-ipv6-rfc2462bis-08 [ADDRCONFbis], this document only refers to RFC 2461 [ND] and RFC 2462 [ADDRCONF] respectively. Where behavior has changed, this document refers to both the original and the new version. 2461bis and 2462bis have been published as RFCs. The references should be updated. <hs> Will do. We had written these drafts when 2461bis and 2462bis were not RFCs yet. </hs> - Section 2, bullet 1 1. On-link determination and addresses acquired using DHCPv6 SHOULD NOT persist across IPv6 interface initializations. I'm not sure if I understand what this means. Does this mean, for example, a node should not keep using addresses configured via DHCPv6 after the node reboots (even if it records the lifetimes in a volatile storage and they do not expire)? <hs> Yes. We have assumed if a node reboots, a node has to perform a new DHCPv6 address acquisition that can change the DHCPv6 address. </hs> If so, while I'm not necessarily opposing to the restriction, but I don't see a strong reason for that either. In fact, the sense of the following part of RFC4862 seems to be applicable to addresses configured via DHCPv6: Assuming the lifetimes used are reasonable, this technique implies that a temporary outage (less than the valid lifetime) of a router will never result in losing a global address of the node even if the node were to reboot. (BTW: this seems to be an out-of-scope thing - see the general comment above). <hs> We agree DHCPv6 is out of scope of this draft. We will remove the mention of DHCPv6 from bullet 1. However, we have bullet 1 from this draft included in our nd-updates draft so we don't lose the DHCPv6 context we wanted to preserve. </hs> - Section 2, bullet 2 While I personally agree with this policy, we should note that there are other (probably a non-negligible number of) people who want to introduce a DHCPv6 option specifying on-link prefix information. In my understanding it's still an ongoing issue and the result of the discussion may affect this bullet. <hs> Our drafts have been written based on RFCs up till 4861 and 4862 which still make no mention of DHCPv6 carrying on-link prefix information. One should not confuse our drafts which are dealing with clarifications related to existing ND RFCs up to 4861 and 4862 with existing tentative discussions currently taking place in the DHCPv6 WG. One cannot expect new DHCPv6 WG items and impacting ND just yet. We personally haven't even agreed to the DHCPv6 WG item in this regard. </hs> - Section 2, bullet 6 (just as a comment) Optimistic DAD (RFC4429) implicitly indicates possible benefit of using a larger DupAddrDetectTransmits value: These problems exist, and are not gracefully recoverable, in Standard DAD. Their probability in both Optimistic and Standard DAD can be reduced by increasing the RFC 2462 DupAddrDetectTransmits variable to greater than 1. <hs> True. All we wanted to highlight here was that default for DupAddrDetectTransmits is one. Some new implementors to IPv6 who are developing RFC 2461 or RFC 4861 protocol don't see a value of this variable in the RFC 2461 or 4861. These folks don't look into RFC 2462 or 4862 where the default is defined. Also, as described above, we'll move this bullet to the nd-updates draft. </hs> - Section 2, bullet 7 Point 2 and 3 seem to contradict each other, or at least be confusing. Point 2 states address resolution must not be performed: 2. The host MUST NOT perform address resolution for non-link- local addresses. while point 3 talks about the case where address resolution fails: 3. [...], address resolution has failed. As specified in the last paragraph of section 7.2.2 I think this is just a matter of wording. Maybe we should use a different term than "address resolution" in point 3. <hs> You are correct. We will change wording of point 3 as follows: "Since the host cannot assume the destination is on-link, and off-link traffic cannot be sent to the default router (since the Default Router List is empty), address resolution cannot be performed. This case is analogous to the behavior specified in the last paragraph of section 7.2.2 (RFC 4861) [RFC4861]: when address resolution fails, the host SHOULD send an ICMPv6 Destination Unreachable message. The specified behavior MAY be extended to cover this case where address resolution cannot be performed." </hs> - Section 2, bullet 7 (point 3) [...]. As specified in the last paragraph of section 7.2.2 of draft-ietf-ipv6-rfc2461bis-11 [NDbis], when address resolution fails, the host SHOULD send an ICMPv6 Destination Unreachable message. Section 7.2.2 of [NDbis] does not actually cover this case: it only talks about the actual address resolution fails after a number of transmissions of NS without any NA replied. If this tries to suggest an analogous behavior, that might be fine, but then saying "As specified in..." is not appropriate. <hs> Our intent was to suggest analogous behavior. See changed text if item 3 above. </hs> Also, I actually don't necessarily think sending an ICMPv6 error in this case is the best way. Since this is a synchronous error, the protocol stack (depending on the implementation details, though) can return an immediate error to the caller (e.g., a failure of a system call). In my understanding BSD and Linux would behave that way rather than sending an ICMPv6 error. <hs> That is why the changed text specifies MAY. However, in general, the way a particular implementation's API is currently laid out should not dictate protocol design. </hs> - Section 2, bullet 7 [I.D.ietf-v6ops-onlinkassumptions] has been published as RFC4943. <hs> Right - this draft became an RFC after we published our drafts. We will make that change. </hs> - Section 2.1 An IPv6 router sends an RA with no prefix advertised and the M bit set, does not send any Redirects, nor any NA or ND messages for non- link local addresses. First of all, I couldn't parse this sentence. <hs> We can reword this to "For example, an IPv6 router can send an RA with no PIO, the M bit set, does not send any Redirects, and does not send any NA or ND messages for non-link-local addresses." </hs> But in any event, this seems to talk about the case where a host configures its addresses via DHCPv6 and RA does not provide any on-link information. While 'no prefix advertised' is included in this scenario, I think it should be a more general form, that is, RA does not contain a prefix information option with the L flag being on. <hs> We discuss the L bit clear case in section 2.3 </hs> [...] On receipt of the RA, the host uses DHCPv6 to acquire an IPv6 address. I would rephrase this to "the host can use DHCPv6 to acquire an IPv6 address" because our latest interpretation of the M bit just indicates the availability of a DHCPv6 server for address configuration, and does not necessarily specify the host's behavior. <hs> We can reword this to "On receipt of the RA, the host in this example chooses to use DHCPv6 to acquire its IPv6 address." </hs> [...] Since the Redirect contains all the information necessary to resolve the address of the destination host, the source host MUST NOT issue an NS to resolve a destination other than a link-local address. This does not make sense since Redirect does not always include target link-layer address option; then the host MUST rather perform address resolution. <hs> We have re-worded the entire Redirect text to make several Redirect cases clear. 1. At the end of sections 2.1 and 2.2.1, the last paragraph is the same as below. "In the presence of Redirects, only the on-link behavior of the destination addresses of the original packets for which the Redirects were sent change from what is specified in the rules above. These destination addresses are considered to be on-link and the host MAY now send non-link-local traffic destined to the destination addresses directly without sending it first to the default router. Since the Redirect contains all the information necessary to resolve the address of the destination host, the source host MUST NOT issue an NS to resolve a destination other than a link-local address." The paragraph above has been changed to "In the presence of Redirects, only the on-link behavior of the destination addresses of the original packets for which the Redirects were sent change from what is specified in the rules above. For changes to the on-link behavior in the presence of Redirects, see the Redirect Clarifications section." 2. See new section 4 below. "Redirects are not sent by aggregation routers except when two hosts behind the same bridge CPE, with no router between the host and the aggregation router, communicate with each other. The aggregation router sends a Redirect to a source host which communicates with a destination host behind the same bridge CPE if the router can make a determination that the two hosts lie behind the same bridge CPE. The ICMP field of the Redirect message has a Target Address field. In the presence of a Target link-layer option included in the Redirect, the host MUST NOT issue an NS to resolve the destination. In the absence of any Target link-layer option included in the Redirect, host behavior depends upon the type of the target. If the target is a router, that router's link-local address is the Target Address. The source IP address of a Redirect is always a link-local address. If the target link-local address matches the source IP address, then the L2 header of the Redirect message tells the host the link-layer address of the target. The purpose of such a Redirect message is to tell a host that a destination which the host assumes to be on-link is in fact off-link. If the target address does not match the source IP address, then the Redirect target is another router than the router that issued the Redirect. In this case, the host MUST issue an NS to resolve the link-local address of the target if the host does not already have this address in its neighbor cache. This Redirect indicates that the destination is off-link, but the host MUST use a different router than the one issuing the Redirect in order to reach the destination. In summary, if the target of a Redirect is a router, then the destination is off-link and the host MUST NOT issue an NS to resolve a destination other than a link-local address. If the target is a host, the target address is the same value as the ICMP Destination address. On receiving this Redirect, the source host MUST issue an NS to resolve a non-link-local destination if the host does not already have this information in its neighbor cache. Once the destination host responds to the NS, the source host will thereafter send packets directly to the destination host." </hs> - Section 2.2 Consider the following scenario with one rogue node and two other hosts on the same link. [...] [...] Host1 decides to send all of its traffic to the on-link authority, the default router, even though the destination prefix is on-link. I don't understand what this paragraph tries to indicate. Please elaborate. <hs> What we are saying is that even with the On-Link bit set, the host MAY still decide to send all its non-link-local traffic to the default router. Setting the on-link bit does NOT guarantee that a host will always perform address resolution. Our paragraph describes an example of a situation where the host decides to send traffic to the default router even when the address has been specified to be on-link. The reason why the host may do this is because the host knows that only the router is the authoritative source of on-link information, and the host's own on-link cache cannot be trusted. </hs> - Section 2.2.1 [...] Since the Redirect contains all the information necessary to resolve the address of the destination host, the source host MUST NOT issue an NS to resolve a destination other than a link-local address. This doesn't make sense (see comment about Section 2.1). <hs> See our explanation above in response to your comment about Section 2.1. </hs> - Section 4 Since the Redirect contains all the information necessary to resolve the address of the destination host, the source host MUST NOT issue an NS to resolve the destination contained within the Redirect. This doesn't make sense (see comment about Section 2.1). <hs> See our explanation above in response to your comment about Section 2.1. </hs> Thanks. Hemant & Wes JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
- comments on draft-wbeebee-on-link-and-off-link-de… JINMEI Tatuya / 神明達哉
- RE: comments on draft-wbeebee-on-link-and-off-lin… Hemant Singh (shemant)
- RE: comments on draft-wbeebee-on-link-and-off-lin… Hemant Singh (shemant)
- RE: comments on draft-wbeebee-on-link-and-off-lin… Hemant Singh (shemant)
- Re: comments on draft-wbeebee-on-link-and-off-lin… JINMEI Tatuya / 神明達哉
- RE: comments on draft-wbeebee-on-link-and-off-lin… Hemant Singh (shemant)