Re: Sending traffic to default router when RA has no PIO
Vlad Yasevich <vladislav.yasevich@hp.com> Thu, 05 July 2007 18:40 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 1I6WFY-0005eM-Nq; Thu, 05 Jul 2007 14:40:20 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6WFW-0005dp-L2 for ipv6@ietf.org; Thu, 05 Jul 2007 14:40:18 -0400
Received: from atlrel7.hp.com ([156.153.255.213]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I6WEZ-0008B9-Fn for ipv6@ietf.org; Thu, 05 Jul 2007 14:40:18 -0400
Received: from smtp1.fc.hp.com (smtp.cnd.hp.com [15.15.136.127]) by atlrel7.hp.com (Postfix) with ESMTP id BF1263401D; Thu, 5 Jul 2007 14:38:58 -0400 (EDT)
Received: from galen.zko.hp.com (galen.zko.hp.com [16.116.113.226]) by smtp1.fc.hp.com (Postfix) with ESMTP id 58A34145175; Thu, 5 Jul 2007 18:38:58 +0000 (UTC)
Received: by galen.zko.hp.com (Postfix, from userid 1000) id E7CB7318056; Thu, 5 Jul 2007 14:38:57 -0400 (EDT)
From: Vlad Yasevich <vladislav.yasevich@hp.com>
To: shemant@cisco.com
Date: Thu, 05 Jul 2007 14:38:57 -0400
Message-Id: <11836607373870-git-send-email-vladislav.yasevich@hp.com>
X-Mailer: git-send-email 1.5.0.3.438.gc49b2
In-Reply-To: <B00EDD615E3C5344B0FFCBA910CF7E1D03589CE5@xmb-rtp-20e.amer.cisco.com>
References: <B00EDD615E3C5344B0FFCBA910CF7E1D03589CE5@xmb-rtp-20e.amer.cisco.com>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7c1a129dc3801d79d40c5ca8dee767eb
Cc: ipv6@ietf.org
Subject: Re: Sending traffic to default router when RA has no PIO
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "IP Version 6 Working Group \(ipv6\)" <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
Hi Hemant Here is my review of your draft. Comments are inside the <vy> </vy> blocks. -vlad 1. Introduction IPv6 host data forwarding and address resolution is complex. For example, RFC 2461 [ND] (section 3.1) implies that if the RA received by the host does not advertise any prefix, then the host must send all non-link-local data to the default router. This section of the RFC also implies that no address resolution is to be performed in this case. Sections 5.2 and 7.2.2 imply that the host performs address resolution before transmitting a packet if the destination of the packet is on the same link as the host. Some current host implementations perform address resolution in all cases even when the destination is not clearly on-link. However, RFC 2461 [ND] section 6.3.4 implies that hosts must clearly determine that a destination is on-link before performing address resolution. <vy> I believe that you are reading too much into section 3.1. That section simply does a comparison to IPv4. It does not mandate anything and doesn't not specify any specific beavhior. That is saved for later. One could argue that this section might have a touch more technical information there then strictly need, but it is still not meant to specify any requiremens. </vy> These implications in RFC 2461 [ND] need to be made explicit. Failure of host implementations to comply can result in lack of IPv6 connectivity. For example, a host receives an RA with no prefix advertised and incorrectly decides to perform address resolution when the host should have sent all traffic to the default router. The router may not respond to the address resolution and the layer 2 driver of the host stops transmitting IPv6 packets. <vy> Are these meant to describe 2 different scenarios or just one? If only one, both implementations violate multiple aspects of the protocol. </vy> 2. Host Models A correctly implemented IPv6 host MUST adhere to the following rules: 1. On-link determination and address information MUST NOT persist across IPv6 interface initializations. <vy> Either you are not clear enough here, or this requirement is overly strict. There is nothing with having configured address information persist acrsoss across full system or interface initializations. I agree that on-link determination information SHOULD NOT persist, but clever people can do some very clever things. I think SHOULD NOT is strong enough. </vy> 2. The RA and Redirects from the default router are the only sources of information for on-link determination. DHCPv6 or any other configuration on the host MUST NOT be used for on-link determination. <vy> You should really restrict this to other types for dynamic configuration </vy> 3. The host MUST NOT add a direct delivery route to the prefix from an assigned address, independent of the information about the prefix received from the RA or Redirects. <vy> Can you please explain what exactly you mean here. I am having difficulty properly understanding this sentence. </vy> 5. The host SHOULD issue only a single NS(DAD) for each address. The default value for DupAddrDetectTransmits variable is specified as 1 in section 5.1 of RFC 2462 [ADDRCONF]. <vy> What exactly are you trying to address with this text? When I read it, my first impulse is to assume that you want to limit the number of DAD Soliciations to 1 per address, which is not really correct and is _probably_ not what you mean. Can you explain a little more. </vy> 6. If the Default Router List is empty, the host MUST NOT assume that all destinations are on-link. The host MUST NOT perform address resolution for non-link-local addresses. The host SHOULD send an ICMPv6 Destination Unreachable message instead. <vy> No that's not correct. The host can perform address resolution if he has on-link prefexis. It it permissable to have on-link prefixes without specifying a default router (I have a private isolated network). </vy> 2.1. RA Sets M and O Bits but does not Include the Prefix Information Option (PIO) [... draft text snipped ...] An IPv6 router sends an RA with no prefix advertised and the M and O bits set and does not send any Redirects. On receipt of the RA, the host uses DHCPv6 to acquire an IPv6 address. After completing IPv6 address acquisition, the host MUST obey RFC 2461 [ND], section 3.1. Since the RA is the only authority to a host for on-link determination and this RA does not advertise any prefix, the host cannot determine that a destination is on-link. Therefore, the host MUST adhere to the following rules: 1. The host MUST NOT assume any default prefix length. 2. The host MUST send all non-link-local traffic to the default router. 3. The host MUST NOT issue an NS to resolve a destination other than a link-local address. <vy> One can argue that a host/DHCP client that inferes a prefix length from a leased address is prone to other failures as well. In this case, it's the DHCP client that is most likely a problem, unless the host implementation mistakenly alwasy assumes /64 length. I think this is actually warned against in the Address Architure document. 2461bis clearly states that a set 'L' flag is the only determination of on-link. Anything else you can report to your vendor as "Bug". The above actually would be a very good test to add to the TAHI conformance test suite. </vy> 2.2. RA Advertises a Prefix with the On-link(L) Bit Set [... draft text sniped ...] Consider the following scenario with one rogue node and two other hosts on the same link. The rogue sends a malicious RA with an on- link prefix with a Valid Lifetime of zero. Host1 correctly implements section 5.5.3 of RFC 2462 [ADDRCONF] and resets its StoredLifetime (or RemainingLifetime in draft-ietf-ipv6-rfc2462bis-08 [ADDRCONFbis]) to two hours and avoids the denial of service attack. Host1 tries to send traffic to Host2, but cannot trust its own two hour StoredLifetime. For instance, a legitimate operator may have tried to time out the prefix due to an impending renumbering. Host1 decides to send all of its traffic to the on-link authority, the default router, even though the destination prefix is on-link. IF the host decides to send all traffic (including on-link traffic) to the default router, then the host MUST follow the following rule: 1. The host MUST NOT issue an NS to resolve a destination other than a link-local address. <vy> This is kind of reduntant. The host can either determine that the destination is on-link (i.e it trusts its prefix list), or it sends it to the default router. The only time it would preform NS would be for on-link determination which means that it trust the prefix list. I don't see any further need to call out this particular scenario. </vy> 2.3. RA Advertises a Prefix with the On-link(L) Bit Clear Regardless of whether the host performs DHCPv6 and/or stateless autoconfiguration, the host MUST adhere to the following rules for addresses contained within the advertised prefix: 1. The host MUST NOT issue an NS to resolve a destination other than a link-local address. 2. The host MUST send all non-link-local traffic to the default router. <vy> No. If the host already had a on-link prefix in the list that matches the the one with 'L' bit clear, it should not change the on-link assumption and continue using address resolution. If this is a new prefix with the 'L' bit clear, then 2461bis already addresses this issue appropriatly. </vy> 3.1. Aggregation Router Deployment Model No NS to resolve any address other that that of the default router will reach the aggregation router from any device on the customer side of the aggregator. CPEs do not communicate with each other in this deployment model since a CPE does not run any applications that need to communicate with other CPEs. Hosts do communicate with each other, but every host is off-link to any other host on the aggregation router. <vy> Yes, they are off-link. So why would they thing their are on-link? Each CPE Rtr or Cust Rtr whould have it's own prefix that would be advertized to the CPE hosts. Therese prefixes would aggregate at the Agregator. Why would NSs from the CPE hosts escape? </vy> 5. Changes to draft-ietf-ipv6-rfc2461bis-11 [... old text snipped ...] "Multiple prefixes can be associated with the same link. By default, hosts learn all on-link prefixes from Router Advertisements. However, routers may be configured to omit some or all prefixes from Router Advertisements. In such cases hosts assume that destinations are off-link and send traffic to routers. A router can then issue redirects as appropriate. Without advertised prefixes, without manual configuration, and without redirects, hosts MUST NOT assume a default prefix length, MUST send all non-link-local traffic to the default router and MUST NOT issue an NS to resolve any destination other than a link-local address. <vy> No, this is the wrong section to include such requirements since the section currenlty doesn't place any specific requirements on the implementation. </vy> 6. Changes to draft-ietf-ipv6-rfc2462bis-08 [... old text snipped ...] to read as follows: Each individual unicast address SHOULD be tested for uniqueness. Note that some deployed implementations perform Duplicate Address Detection (DAD) only for the link-local address and skip the test for the global address using the same interface identifier. Whereas this document does not invalidate such implementations, this kind of 'optimization' is NOT RECOMMENDED, and new implementations MUST NOT do that optimization. This optimization came from the assumption that all of an interface's addresses are generated from the same interface identifier (see RFC 2462 [ADDRCONF]). However, even with this assumption, skipping DAD for non-link-local addresses with manual configuration creates an additional problem. This optimization allows an interface to claim a duplicate address in a way that would not be detected. For a more detailed description of this problem, see the Host Models section of draft-wbeebee-nd-implementation-pitfalls-01. Further, new types of addresses have been introduced where the interface identifiers are not necessarily the same for all unicast addresses on a single interface [RFC3041] [RFC3972]. Requiring an interface to perform DAD for all unicast addresses will make the algorithm more robust. <vy> Two issues: 1. This text is not any stronger then the existing text in 2461bis and doesn't add anything significant. 2. It creates a normative reference to a personal draft at a very late stage in the life of 2461bis. I don't see a reason to add this text </vy> My conlcusion: After re-reading 2461bis and 2462bis multiple times as result of reviewing this draft, I can see some small value in creating an "On-Link Determination" section in draft 2461bis. Alternatively, this draft should crate such section and, with references to text in 2461bis, should clarify the on-link determination behavior. It could then be issued as an update. -vlad -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
- Sending traffic to default router when RA has no … Wes Beebee (wbeebee)
- RE: Sending traffic to default router when RA has… Hemant Singh (shemant)
- Re: Sending traffic to default router when RA has… Vlad Yasevich
- RE: Sending traffic to default router when RA has… Hemant Singh (shemant)
- Re: Sending traffic to default router when RA has… Ole Troan
- RE: Sending traffic to default router when RA has… Hemant Singh (shemant)
- Re: Sending traffic to default router when RA has… Ole Troan
- RE: Sending traffic to default router when RA has… Hemant Singh (shemant)
- Re: Sending traffic to default router when RA has… Vlad Yasevich
- Re: Sending traffic to default router when RA has… Markku Savela
- RE: Sending traffic to default router when RA has… Hemant Singh (shemant)
- RE: Sending traffic to default router when RA has… Hemant Singh (shemant)
- Re: Sending traffic to default router when RA has… JINMEI Tatuya / 神明達哉
- RE: Sending traffic to default router when RA has… Hemant Singh (shemant)
- Re: Sending traffic to default router when RA has… Vlad Yasevich
- Re: Sending traffic to default router when RA has… JINMEI Tatuya / 神明達哉
- Re: Sending traffic to default router when RA has… Julien Laganier
- FW: Sending traffic to default router when RA has… Hemant Singh (shemant)
- RE: Sending traffic to default router when RA has… Hemant Singh (shemant)
- Re: Sending traffic to default router when RA has… Vlad Yasevich
- RE: Sending traffic to default router when RA has… Hemant Singh (shemant)
- Re: Sending traffic to default router when RA has… Vlad Yasevich
- RE: Sending traffic to default router when RA has… Hemant Singh (shemant)
- Re: Sending traffic to default router when RA has… Vlad Yasevich
- Re: Sending traffic to default router when RA has… JINMEI Tatuya / 神明達哉
- RE: Sending traffic to default router when RA has… Hemant Singh (shemant)
- Re: Sending traffic to default router when RA has… Vlad Yasevich
- RE: Sending traffic to default router when RA has… Hemant Singh (shemant)