From rja.lists@gmail.com Thu Feb 3 07:13:58 2011 Return-Path: X-Original-To: ipv6@core3.amsl.com Delivered-To: ipv6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 346FE3A69BD for ; Thu, 3 Feb 2011 07:13:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.474 X-Spam-Level: X-Spam-Status: No, score=-3.474 tagged_above=-999 required=5 tests=[AWL=0.125, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sCUKnjoF2jWs for ; Thu, 3 Feb 2011 07:13:54 -0800 (PST) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by core3.amsl.com (Postfix) with ESMTP id 396523A695D for ; Thu, 3 Feb 2011 07:13:54 -0800 (PST) Received: by qwi2 with SMTP id 2so1077893qwi.31 for ; Thu, 03 Feb 2011 07:17:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:from:content-type:content-transfer-encoding :subject:date:message-id:to:mime-version:x-mailer; bh=xAAY/J5AKHADR0c9yvWYPwDX/hsAW1O9ntqYVNZxOzk=; b=LlOhdt1ix4m0Ja/W+1tFUnSA1lT2GzIoGF3tHv34YcnUrZ4jjw3zwT4934KEFtVPOZ 4p8LSFR66iTPsXawhdNiezT3GS4F3Z/YYMLuCp/z9WlReowfJkVoNCkpvzjLCFHZf+f7 WlGYmTeQI8kgRRr0bUT1gbW0f7T+zXM6ewAoM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:content-type:content-transfer-encoding:subject:date:message-id :to:mime-version:x-mailer; b=aKq71ZJHo4iNVlJuCB/9ZWllpdq36RiGl1u9/qE3vQBYxuLdvzxEoqDIY4Aq74rfe2 HslmQAOZ25zbb1SCmPIIWMkIKvJ8Zdu/kPh8YHCOo84OhbVshC+FrvJMDGiZbi2MUwx4 N7GrNUQduBp0rC+Eal0BRnf+HG5lJeCPBUozs= Received: by 10.224.10.208 with SMTP id q16mr10126823qaq.65.1296746236361; Thu, 03 Feb 2011 07:17:16 -0800 (PST) Received: from vi-mhowell55.leclairryan.com ([38.103.42.150]) by mx.google.com with ESMTPS id s10sm631231qco.23.2011.02.03.07.17.14 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 03 Feb 2011 07:17:15 -0800 (PST) From: RJ Atkinson Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: RFC 3697bis Open issue 9 Date: Thu, 3 Feb 2011 10:17:12 -0500 Message-Id: <52DDCC67-7912-4C18-BEF2-C75ADB2C1A38@gmail.com> To: ipv6@ietf.org Mime-Version: 1.0 (Apple Message framework v1082) X-Mailer: Apple Mail (2.1082) X-BeenThere: ipv6@ietf.org 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: , X-List-Received-Date: Thu, 03 Feb 2011 15:13:58 -0000 On 31 Jan 2011 at 09:17:47 -0500, Joel Halpern wrote: > Several of these comments have a common theme of requiring domains > to remark flow-labels on ingress. While we have agreed to allow > remarking of packets with 0 values in their flow label, expecting > repeated remarking seems to me a very bad idea. Basically, if we do that, > then I expect that most routers will simply assume that the flow label > is useless, since we can not expect peering scale routers to remark > the flow label of packets based on deep packet inspection. Also, > in many cases, as described in other documents, such re-marking > is effectively impossible. Joel's comments are well put. That noted, everyone interested in the Flow Label issue needs to keep in mind that various operational domains (e.g. sites, organisations, providers) have various domain-specific and site-specific security policies that preclude end-to-end Flow Label values. In particular, a number of domains connected to the public Internet, including a number of commercial firms, are concerned about use of "covert channels" by their adversaries (e.g. to steal IPR, to probe interior network segments). While most (all ?) useful communications protocols have at least some low-bandwidth covert channels, the IPv6 Flow Label stands out as a relatively high-bandwidth covert channel -- due to its size. Packets entering or leaving a domain with such a security policy very likely will have their IPv6 Flow Label either zeroed or otherwise overwritten with new values upon ingress or egress. I understand that such capabilities commonly exist in currently deployed commercially available firewall products. I'm further told that the larger sized commercial firewalls have hardware (e.g. ASICs) that can zero or remark IPv6 Flow Label values at interestingly high speeds (e.g. at least wire-speed for a 1 GigE interface, possibly faster). Similarly, organisations operating such domains do NOT want their end systems putting non-zero bits into the IPv6 Flow Label during packet origination, as that is a particularly interesting high speed way to covertly export data from such end systems. One imagines that sysctl() or similar knobs might be used by some system administrators to disable generation of non-zero IPv6 Flow Labels within the originating nodes of a given domain. Kindly note that I'm merely reporting what I understand to be the case in an interesting number of cases. I'm not advocating any particular behaviour on the part of any enterprise/ISP/other network operator. Also note that the IETF normally levies requirements upon device/protocol implementers, but does not normally levy requirements upon enterprise/ISP/other network operators. In any event, one imagines the local security policy will de facto take precedence over what any RFC says, within a given domain, should an RFC contradict local security policy. When one intersects Joel's comments above and my observations above, it is not obvious to me that an arbitrary router somewhere in the global Internet reasonably could expect that the IPv6 Flow Label of an arbitrary IPv6 packet will contain values useful for LAG, SLB, etc. Yours, Ran Atkinson From bob.hinden@gmail.com Thu Feb 3 10:04:14 2011 Return-Path: X-Original-To: ipv6@core3.amsl.com Delivered-To: ipv6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4C1A73A6A33 for ; Thu, 3 Feb 2011 10:04:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vpXuoi60RDZq for ; Thu, 3 Feb 2011 10:04:12 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by core3.amsl.com (Postfix) with ESMTP id 27BAB3A698E for ; Thu, 3 Feb 2011 10:04:12 -0800 (PST) Received: by iym1 with SMTP id 1so854244iym.31 for ; Thu, 03 Feb 2011 10:07:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to:x-mailer; bh=9Y9BWOyffdwYem7qdTg/fKMetoLGTxHM3xabC0g/BQY=; b=qv3UCc92IwwG2cbB+wYaXhJxMqqYCR4/EY+K/WjXa9qDYTuF07R4VpTAoYlms/EVGk SscE6HghejKnpXzik+myhQ0gIAAWqhyQEB1rUR9XZrDU+dG7eCf1ohDAR9mcaCnZl3o/ etkwc8H8TBk5ef6FbFiHle7fxq7TSAqgX8psU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=ugy5rTJe3lXkH+Q55oefS81frTya2TSYc2q5bsjE7GyvLtYCJ1u+TL+/UsVn5KHNdn VkZ+m41pPzNiq9uq1YykBgXYsSIRBKPZEnodHqTR8D6YcKq2+VQuA155gWJGaAV/7BN9 os1X4w8nEBgtZY4Ca62tZ8RDaKkFKSceA6MZg= Received: by 10.42.218.66 with SMTP id hp2mr13134540icb.244.1296756454802; Thu, 03 Feb 2011 10:07:34 -0800 (PST) Received: from [10.36.0.182] (sdcc-66-78-210-213.smartcity.com [66.78.210.213]) by mx.google.com with ESMTPS id z4sm877673ibg.19.2011.02.03.10.07.32 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 03 Feb 2011 10:07:33 -0800 (PST) Subject: Re: RFC 3697bis Open issue 9 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Bob Hinden In-Reply-To: <52DDCC67-7912-4C18-BEF2-C75ADB2C1A38@gmail.com> Date: Thu, 3 Feb 2011 10:07:29 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <4B601F98-60B0-4B29-AEFA-B17CC8A0219A@gmail.com> References: <52DDCC67-7912-4C18-BEF2-C75ADB2C1A38@gmail.com> To: RJ Atkinson X-Mailer: Apple Mail (2.1082) Cc: ipv6@ietf.org, Bob Hinden X-BeenThere: ipv6@ietf.org 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: , X-List-Received-Date: Thu, 03 Feb 2011 18:04:14 -0000 Ran, On Feb 3, 2011, at 7:17 AM, RJ Atkinson wrote: > On 31 Jan 2011 at 09:17:47 -0500, Joel Halpern wrote: >> Several of these comments have a common theme of requiring domains=20 >> to remark flow-labels on ingress. While we have agreed to allow=20 >> remarking of packets with 0 values in their flow label, expecting=20 >> repeated remarking seems to me a very bad idea. Basically, if we do = that,=20 >> then I expect that most routers will simply assume that the flow = label=20 >> is useless, since we can not expect peering scale routers to remark=20= >> the flow label of packets based on deep packet inspection. Also,=20 >> in many cases, as described in other documents, such re-marking=20 >> is effectively impossible. >=20 > Joel's comments are well put. I agree with Joel's comments on negative aspects of remarking flow = labels. >=20 > That noted, everyone interested in the Flow Label issue needs=20 > to keep in mind that various operational domains (e.g. sites, > organisations, providers) have various domain-specific and=20 > site-specific security policies that preclude end-to-end > Flow Label values. >=20 > In particular, a number of domains connected to the public Internet, > including a number of commercial firms, are concerned about use of=20 > "covert channels" by their adversaries (e.g. to steal IPR, to probe=20 > interior network segments). =20 It would be helpful if someone could come forward who has this = requirement. I could beleive there are some users who have this = requirement, I think it is a very small subset. =20 I remain skeptical that the flow label field is really an effective = "covert channel". There are so many better ways of insider attacks = available than sending it in the flow label field. This seems to me to = be more theoretical than real to me. =20 I did some searches on the web for IPv6 covert channels. Most of what I = found was talking about not filtering any IPv6 traffic, or using things = like ICMPv6 echo request/reply. Further, why doesn't the fragment ID in IPv4 cause a similar problem? = It's 16 bits, vs. the flow label's 20 bits. =20 > While most (all ?) useful communications protocols have at least=20 > some low-bandwidth covert channels, the IPv6 Flow Label stands out=20 > as a relatively high-bandwidth covert channel -- due to its size. 20 bits per packet. At 100 packets / second that 2K bps. Is that high = bandwidth? =20 >=20 > Packets entering or leaving a domain with such a security policy=20 > very likely will have their IPv6 Flow Label either zeroed or otherwise=20= > overwritten with new values upon ingress or egress. I understand that=20= > such capabilities commonly exist in currently deployed commercially > available firewall products. I'm further told that the larger > sized commercial firewalls have hardware (e.g. ASICs) that can > zero or remark IPv6 Flow Label values at interestingly high speeds=20 > (e.g. at least wire-speed for a 1 GigE interface, possibly faster). They may be available in some firewalls, but the one I am familiar with = does not do this. I also don't see anything like this in PF (an open = source firewall that I have used). Can you point to some product specs? A determined insider has an almost infinite number of communication = paths available. They don't even need Internet access, let alone IPv6. = I don't think we should limit the use of the flow label for load = balancing due to a concern about covert channels using the flow label. Bob >=20 > Similarly, organisations operating such domains do NOT want their > end systems putting non-zero bits into the IPv6 Flow Label during > packet origination, as that is a particularly interesting high > speed way to covertly export data from such end systems. One > imagines that sysctl() or similar knobs might be used by some > system administrators to disable generation of non-zero IPv6 > Flow Labels within the originating nodes of a given domain. >=20 > Kindly note that I'm merely reporting what I understand to be the > case in an interesting number of cases. I'm not advocating any > particular behaviour on the part of any enterprise/ISP/other > network operator. Also note that the IETF normally levies > requirements upon device/protocol implementers, but does not > normally levy requirements upon enterprise/ISP/other network=20 > operators. In any event, one imagines the local security policy > will de facto take precedence over what any RFC says, within > a given domain, should an RFC contradict local security policy. >=20 > When one intersects Joel's comments above and my observations=20 > above, it is not obvious to me that an arbitrary router somewhere=20 > in the global Internet reasonably could expect that the IPv6 Flow=20 > Label of an arbitrary IPv6 packet will contain values useful for=20 > LAG, SLB, etc. Without more evidence, I don't agree. =20 From rja.lists@gmail.com Thu Feb 3 10:38:02 2011 Return-Path: X-Original-To: ipv6@core3.amsl.com Delivered-To: ipv6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 370DB3A6A7E for ; Thu, 3 Feb 2011 10:38:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.484 X-Spam-Level: X-Spam-Status: No, score=-3.484 tagged_above=-999 required=5 tests=[AWL=0.115, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZAz3RYySgsKQ for ; Thu, 3 Feb 2011 10:38:01 -0800 (PST) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by core3.amsl.com (Postfix) with ESMTP id 4F8E63A6A7D for ; Thu, 3 Feb 2011 10:38:01 -0800 (PST) Received: by vws7 with SMTP id 7so925621vws.31 for ; Thu, 03 Feb 2011 10:41:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:content-type:mime-version:subject:from :in-reply-to:date:content-transfer-encoding:message-id:references:to :x-mailer; bh=gXkEgPtaosEhkR76tmf6dF49aybsNIIXTFvel704kCk=; b=SbDeyCR1Q0BhvCUoQ93e0QxwYUVukUtCA6ny/ZZlMzcVXKYZtFRi0HIm/PHVUIABME xq/q9qjFoemLPRFrvr0uk4ZlHgmLbIGZ56gCr9yn5FgYfLzG7+UjswiZa7RNK1JF0Qlb l64MjyUdK9IpamsrTEDb7oXWZpyFdq1h4Jits= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=content-type:mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to:x-mailer; b=Q749jrge/WCr2nRU79AV7w5N2M7Jq6PRpYnCr5OTw5UUWK07VEFn0W3JaQawyFfa5U aW3BqF9Zwdt+ffDXfUZ7Ise8hfQoqYUASxT6RIrJCn0PhP7Yx7Pub0kUWhaPiIfFVjed bbXe1OZpbRFERW53vhrF1q3+dMi5/HISYDi6s= Received: by 10.220.178.200 with SMTP id bn8mr298460vcb.169.1296758484024; Thu, 03 Feb 2011 10:41:24 -0800 (PST) Received: from vi-mhowell55.leclairryan.com ([38.103.42.150]) by mx.google.com with ESMTPS id s6sm456710vch.47.2011.02.03.10.41.22 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 03 Feb 2011 10:41:23 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1082) Subject: Re: RFC 3697bis Open issue 9 From: RJ Atkinson In-Reply-To: <4B601F98-60B0-4B29-AEFA-B17CC8A0219A@gmail.com> Date: Thu, 3 Feb 2011 13:41:20 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <4639A785-A715-4DF9-AE2E-0817782355BB@gmail.com> References: <52DDCC67-7912-4C18-BEF2-C75ADB2C1A38@gmail.com> <4B601F98-60B0-4B29-AEFA-B17CC8A0219A@gmail.com> To: ipv6@ietf.org X-Mailer: Apple Mail (2.1082) X-BeenThere: ipv6@ietf.org 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: , X-List-Received-Date: Thu, 03 Feb 2011 18:38:02 -0000 On 03 Feb 2011, at 13:07 , Bob Hinden wrote: > I don't think we should limit the use of the flow label > for load balancing due to a concern about covert channels using the = flow label. So far as I am aware, no one has suggested not specifying how the Flow Label field might be used for load balancing. =20 What I suggested was distinctly different, namely that some operational domains are likely to zero that field, either in=20 the origin node or as the packet crosses an administrative=20 boundary, in order to comply with domain-specific policy. In turn that means (A) it is unlikely that IPv6 Flow Labels will reliably be unchanged end-to-end and (B) it is likely that some=20 IPv6 packets with zero-filled Flow Label fields will continue=20 to be seen on the global public Internet for the forseeable future. I also suggested that trying to legislate this issue out of existence=20 by putting words in an RFC was unlikely to be effective. Operational folks in a wide range of organisations routinely configure their=20 systems to match local security policies, even when that policy or=20 configuration is not consistent with existing RFCs. Cheers, Ran From slblake@petri-meat.com Thu Feb 3 10:51:07 2011 Return-Path: X-Original-To: ipv6@core3.amsl.com Delivered-To: ipv6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7733F3A6A4B for ; Thu, 3 Feb 2011 10:51:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZNUV-nC2JJce for ; Thu, 3 Feb 2011 10:51:05 -0800 (PST) Received: from elom.tchmachines.com (elom.tchmachines.com [208.76.80.198]) by core3.amsl.com (Postfix) with ESMTP id 841DF3A69D5 for ; Thu, 3 Feb 2011 10:51:05 -0800 (PST) Received: from localhost ([127.0.0.1] helo=petri-meat.com) by elom.tchmachines.com with esmtpa (Exim 4.69) (envelope-from ) id 1Pl4Jz-0003zP-U1; Thu, 03 Feb 2011 13:54:23 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Date: Thu, 03 Feb 2011 14:54:23 -0400 From: Steven Blake To: RJ Atkinson Subject: Re: RFC 3697bis Open issue 9 In-Reply-To: <52DDCC67-7912-4C18-BEF2-C75ADB2C1A38@gmail.com> References: <52DDCC67-7912-4C18-BEF2-C75ADB2C1A38@gmail.com> Message-ID: X-Sender: slblake@petri-meat.com User-Agent: Roundcube Webmail/0.4.2 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - elom.tchmachines.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - petri-meat.com Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org 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: , X-List-Received-Date: Thu, 03 Feb 2011 18:51:07 -0000 On Thu, 3 Feb 2011 10:17:12 -0500, RJ Atkinson wrote: > In particular, a number of domains connected to the public Internet, > including a number of commercial firms, are concerned about use of > "covert channels" by their adversaries (e.g. to steal IPR, to probe > interior network segments). > > While most (all ?) useful communications protocols have at least > some low-bandwidth covert channels, the IPv6 Flow Label stands out > as a relatively high-bandwidth covert channel -- due to its size. [snip] > When one intersects Joel's comments above and my observations > above, it is not obvious to me that an arbitrary router somewhere > in the global Internet reasonably could expect that the IPv6 Flow > Label of an arbitrary IPv6 packet will contain values useful for > LAG, SLB, etc. Would a one-byte covert channel in the flow label be considered a problem? I.e., if a firewall only zeroed out the most significant 12 bits of the flow label, that would still leave 8 random bits for the LAG/ECMP hash key, which is probably more than enough in practice. The firewall could alternatively choose to recompute the lower 8 bits using 5-tuple hash, since presumably it is already digging its way through the packet headers. Actually, a firewall could always choose to rewrite the whole flow label with the output of its own hash calculation (or a per-flow cached pseudo-random number), eliminating any covert channel. Regards, // Steve From rja.lists@gmail.com Thu Feb 3 11:10:24 2011 Return-Path: X-Original-To: ipv6@core3.amsl.com Delivered-To: ipv6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 49DCE3A6AB1 for ; Thu, 3 Feb 2011 11:10:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.992 X-Spam-Level: X-Spam-Status: No, score=-2.992 tagged_above=-999 required=5 tests=[AWL=-0.393, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BtE1T0B5xWAp for ; Thu, 3 Feb 2011 11:10:23 -0800 (PST) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by core3.amsl.com (Postfix) with ESMTP id 5F5F93A6AA5 for ; Thu, 3 Feb 2011 11:10:23 -0800 (PST) Received: by vxi40 with SMTP id 40so447120vxi.31 for ; Thu, 03 Feb 2011 11:13:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:content-type:mime-version:subject:from :in-reply-to:date:content-transfer-encoding:message-id:references:to :x-mailer; bh=EKFmZBCx1KWSXEBSkzpN7SFVHOFmqzfqszL3sltyZoU=; b=VoxJZBfVgDfnDPirgzpLZaJLB3VMAySj66ukg0Gqgl8UaSkD/RpJsbt2eTtWMyB2UK FlCahTlJrJDfE9G4za/bEMptbCBbL3gzHkcPdOI8YxoPK+KXtH53CEj1rDmNfYIJPiu7 Gr4ICoHGacf9j9uedXq0MeLG/zptnCNvVt5sA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=content-type:mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to:x-mailer; b=t5rQGsfJetLsmXAARZB0CnsaZpm5Y7ZHs9BIPZmT9a8VozZ18v01+nSoFim96oJNdO oy8ENLojOiL9V5kUceNf2fBY11NOxu5qWlxz1ADW6Pb0XzZz3HxD4qdN963v1MQ0y7K5 2w2P4oFse/M7sCeDOmHs7Za7+UTbjhH5kFAbU= Received: by 10.220.201.204 with SMTP id fb12mr2991788vcb.72.1296760425974; Thu, 03 Feb 2011 11:13:45 -0800 (PST) Received: from vi-mhowell55.leclairryan.com ([38.103.42.150]) by mx.google.com with ESMTPS id f17sm782051vbv.16.2011.02.03.11.13.44 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 03 Feb 2011 11:13:44 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1082) Subject: Re: RFC 3697bis Open issue 9 From: RJ Atkinson In-Reply-To: Date: Thu, 3 Feb 2011 14:13:41 -0500 Content-Transfer-Encoding: 7bit Message-Id: <42F4645E-03A7-40D5-8026-9EC7986FC6B8@gmail.com> References: <52DDCC67-7912-4C18-BEF2-C75ADB2C1A38@gmail.com> To: ipv6@ietf.org X-Mailer: Apple Mail (2.1082) X-BeenThere: ipv6@ietf.org 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: , X-List-Received-Date: Thu, 03 Feb 2011 19:10:24 -0000 On 03 Feb 2011, at 13:54 , Steven Blake wrote: > The firewall could alternatively choose to recompute the lower 8 bits > using 5-tuple hash, since presumably it is already digging its way > through the packet headers. I think sites with this concern would be comfortable with that approach. As you say, a site firewall/border-router that is applying a policy to Flow Label field bits is already rummaging through packet headers looking at various other stuff, so creating its own replacement (full or partial) Flow-Label value is probably not a lot of extra work. > Actually, a firewall could always choose to rewrite the whole flow label > with the output of its own hash calculation (or a per-flow cached > pseudo-random number), eliminating any covert channel. Exactly so. That noted, Joel is quite correct that a larger sized inter-domain transit/backbone router is not terribly likely to have the ability today to regenerate a Flow Label while also forwarding packets at wire-speed. Yours, Ran From bob.hinden@gmail.com Thu Feb 3 11:18:57 2011 Return-Path: X-Original-To: ipv6@core3.amsl.com Delivered-To: ipv6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 934D93A6A32 for ; Thu, 3 Feb 2011 11:18:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3kR3H4TPtfxH for ; Thu, 3 Feb 2011 11:18:56 -0800 (PST) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id A2CF73A6A2C for ; Thu, 3 Feb 2011 11:18:56 -0800 (PST) Received: by iwc10 with SMTP id 10so1527576iwc.31 for ; Thu, 03 Feb 2011 11:22:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to:x-mailer; bh=iqM73zPCNd+0lj2jzd4oYSJpkDGqNdBCPz/AGxXPZS4=; b=v68bdziz9io1Ml70H2txlxxnXe/KzHxGafGrwB+X5LBn1qnynuR+tlsw1rmGtuo4YX FLELEEbZmLpYwZsNKaNna+OdjUkrkTxAZy35PmlCvF6NDe85aBo1LETRouHkxrNoMQ2N 2Vn3oRdPfuHdQg5No14MMWZlbqDYJiXBoJazQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=XOcJpEwJ1grkCIwpSrcoyOVt/wniORdsxFnf3SP+BipXSZnI5sceaOX/zOcg2huxGW BARkQl5T1V7WBvkwYqfypmFyocpYQoY5Mk41FY6wBFIzBlluTkQXpBAUG3YRjzwo5odI rzuhoOcf9mk6+i53aIXo6oRJ+wC4PHOSe1r+g= Received: by 10.42.218.202 with SMTP id hr10mr11680330icb.149.1296760939378; Thu, 03 Feb 2011 11:22:19 -0800 (PST) Received: from [10.36.0.182] (sdcc-66-78-210-213.smartcity.com [66.78.210.213]) by mx.google.com with ESMTPS id c4sm823987ict.7.2011.02.03.11.22.17 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 03 Feb 2011 11:22:18 -0800 (PST) Subject: Re: RFC 3697bis Open issue 9 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Bob Hinden In-Reply-To: <4639A785-A715-4DF9-AE2E-0817782355BB@gmail.com> Date: Thu, 3 Feb 2011 11:22:15 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <52DDCC67-7912-4C18-BEF2-C75ADB2C1A38@gmail.com> <4B601F98-60B0-4B29-AEFA-B17CC8A0219A@gmail.com> <4639A785-A715-4DF9-AE2E-0817782355BB@gmail.com> To: RJ Atkinson X-Mailer: Apple Mail (2.1082) Cc: ipv6@ietf.org, Bob Hinden X-BeenThere: ipv6@ietf.org 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: , X-List-Received-Date: Thu, 03 Feb 2011 19:18:57 -0000 Ran, On Feb 3, 2011, at 10:41 AM, RJ Atkinson wrote: >=20 > On 03 Feb 2011, at 13:07 , Bob Hinden wrote: >> I don't think we should limit the use of the flow label >> for load balancing due to a concern about covert channels using the = flow label. >=20 > So far as I am aware, no one has suggested not specifying > how the Flow Label field might be used for load balancing. =20 OK, it's good to make that clear. > What I suggested was distinctly different, namely that some > operational domains are likely to zero that field, either in=20 > the origin node or as the packet crosses an administrative=20 > boundary, in order to comply with domain-specific policy. >=20 > In turn that means (A) it is unlikely that IPv6 Flow Labels will > reliably be unchanged end-to-end and (B) it is likely that some=20 > IPv6 packets with zero-filled Flow Label fields will continue=20 > to be seen on the global public Internet for the forseeable future. For sure, but I suspect this will be the case for the foreseeable future = due to the time it takes to update existing implementations that don't = currently set the flow label. > I also suggested that trying to legislate this issue out of existence=20= > by putting words in an RFC was unlikely to be effective. Operational > folks in a wide range of organisations routinely configure their=20 > systems to match local security policies, even when that policy or=20 > configuration is not consistent with existing RFCs. That's why the current draft says SHOULD. The usual definition of = SHOULD covers the scenario you describe. Bob >=20 > Cheers, >=20 > Ran >=20 >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From brian.e.carpenter@gmail.com Thu Feb 3 14:13:30 2011 Return-Path: X-Original-To: ipv6@core3.amsl.com Delivered-To: ipv6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3B12D3A699F for ; Thu, 3 Feb 2011 14:13:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.48 X-Spam-Level: X-Spam-Status: No, score=-103.48 tagged_above=-999 required=5 tests=[AWL=0.119, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PHcnqryou+nr for ; Thu, 3 Feb 2011 14:13:29 -0800 (PST) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id 410123A6A00 for ; Thu, 3 Feb 2011 14:13:29 -0800 (PST) Received: by fxm9 with SMTP id 9so1819811fxm.31 for ; Thu, 03 Feb 2011 14:16:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:organization:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=6rZ9DfTBNfi64vJMtYpfyCE2shkplH+6GPbb+ZMVKjg=; b=Q7xPH/Gq/ksRQgGzmo45EL3w9e3dsl6R7laNpYqQqH/L966JUZtVtRsFCAUAFU/k2v I0ZLO73D5IFsj7uD020rL3oI/P3YD+sejGKHldL+jmJKg9KuYB1TvhnTinaVo011BYEh +y1eq1w9HBfEiycCXEMHi1X0b0K2844FPztlA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; b=flWGSxYhBkmmW5g+u4di2B5DwQ7w/0fFi3goJRDklh05R/Nut8wY93z9RYY7zBMUA4 GpBqmK4LOlj/3oW4Ia5Ga7UVUfIu1h/I/zTlNZ9fUw6/PYFkyXL4LcG5Z95Ijx7X0lkS USZzvVWwQatmh8dOxaaJ5OLcSRdGS1Ku+am5k= Received: by 10.223.54.132 with SMTP id q4mr1972710fag.117.1296771411940; Thu, 03 Feb 2011 14:16:51 -0800 (PST) Received: from [10.1.1.4] ([121.98.190.33]) by mx.google.com with ESMTPS id y1sm1752fak.39.2011.02.03.14.16.47 (version=SSLv3 cipher=RC4-MD5); Thu, 03 Feb 2011 14:16:50 -0800 (PST) Message-ID: <4D4B294A.9090805@gmail.com> Date: Fri, 04 Feb 2011 11:16:42 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Bob Hinden Subject: Re: RFC 3697bis Open issue 9 References: <52DDCC67-7912-4C18-BEF2-C75ADB2C1A38@gmail.com> <4B601F98-60B0-4B29-AEFA-B17CC8A0219A@gmail.com> <4639A785-A715-4DF9-AE2E-0817782355BB@gmail.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: ipv6@ietf.org, RJ Atkinson X-BeenThere: ipv6@ietf.org 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: , X-List-Received-Date: Thu, 03 Feb 2011 22:13:30 -0000 On 2011-02-04 08:22, Bob Hinden wrote: ... >> I also suggested that trying to legislate this issue out of existence >> by putting words in an RFC was unlikely to be effective. Operational >> folks in a wide range of organisations routinely configure their >> systems to match local security policies, even when that policy or >> configuration is not consistent with existing RFCs. > > > That's why the current draft says SHOULD. The usual definition of SHOULD covers the scenario you describe. Exactly. So does anybody want to propose precise changes to the current text, which is intended to navigate between the various issues? We can always add discussion to the rationale document, but IMHO the normative text needs to be as short as possible while being logically complete. Brian From narten@us.ibm.com Thu Feb 3 16:56:52 2011 Return-Path: X-Original-To: ipv6@core3.amsl.com Delivered-To: ipv6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0ED513A699D for ; Thu, 3 Feb 2011 16:56:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.128 X-Spam-Level: X-Spam-Status: No, score=-106.128 tagged_above=-999 required=5 tests=[AWL=0.471, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bu10xyNn8P1X for ; Thu, 3 Feb 2011 16:56:48 -0800 (PST) Received: from e34.co.us.ibm.com (e34.co.us.ibm.com [32.97.110.152]) by core3.amsl.com (Postfix) with ESMTP id EF0E23A68E7 for ; Thu, 3 Feb 2011 16:56:47 -0800 (PST) Received: from d03relay04.boulder.ibm.com (d03relay04.boulder.ibm.com [9.17.195.106]) by e34.co.us.ibm.com (8.14.4/8.13.1) with ESMTP id p140mu6o001005 for ; Thu, 3 Feb 2011 17:48:56 -0700 Received: from d03av05.boulder.ibm.com (d03av05.boulder.ibm.com [9.17.195.85]) by d03relay04.boulder.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id p14108xx116126 for ; Thu, 3 Feb 2011 18:00:09 -0700 Received: from d03av05.boulder.ibm.com (loopback [127.0.0.1]) by d03av05.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id p14107vY032535 for ; Thu, 3 Feb 2011 18:00:08 -0700 Received: from cichlid.raleigh.ibm.com (sig-9-76-135-212.mts.ibm.com [9.76.135.212]) by d03av05.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id p14106qf032440 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 3 Feb 2011 18:00:07 -0700 Received: from cichlid.raleigh.ibm.com (localhost.localdomain [127.0.0.1]) by cichlid.raleigh.ibm.com (8.14.4/8.12.5) with ESMTP id p14103Q1011224; Thu, 3 Feb 2011 20:00:03 -0500 Message-Id: <201102040100.p14103Q1011224@cichlid.raleigh.ibm.com> To: "Joel M. Halpern" Subject: Re: RFC 3697bis Open issue 9 In-reply-to: <4D46C48B.1060806@joelhalpern.com> References: <4D46315C.3050806@gmail.com> <23233BB6-C4D8-414F-A079-5A53B9A49AFF@nsn.com> <4D46C48B.1060806@joelhalpern.com> Comments: In-reply-to "Joel M. Halpern" message dated "Mon, 31 Jan 2011 09:17:47 -0500." Date: Thu, 03 Feb 2011 20:00:03 -0500 From: Thomas Narten Cc: 6man , ext Brian E Carpenter X-BeenThere: ipv6@ietf.org 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: , X-List-Received-Date: Fri, 04 Feb 2011 00:56:52 -0000 FWIW.... I agree with Joel. I'd like Flow Labels to remain immutable *except* in the case where it is zero. I know we can't enforce that, but that is the principle we should continue to support, and devices that violate this principle should be flogged by the Protocol Police. :-) I think we really do want the Flow Label to retain end-to-end meaning. That is, it's contents are created as close to the originating source as possible, since the source probably has the most information available to set it sensibly. That means a first hop router or a router at the originating site's boundary should be able to change it from 0 to something sensible. I view this is a sort of optimization that allows the Flow Label to get set to a useful value even in cases where the host can't be upgraded to do that. I do not want to encourage routers elsewhere in the network to be modifying the Flow Label. We should not just say that because we can't enforce that Flow Labels in received packets satisfy certain properties, we should give up and let it be modified in any way anyone sees fit. My view is that we are just relaxing the Flow Label semantics a little bit. We aren't completely changing them. I think we can do this, while still preserving the original intent (at least in most aspects). No need to change the semantics of the Flow Label any more than the minimal necessary to make it useful for load balancing. IMO, the old text in the document should just be tossed. It makes no sense to me and I don't understand what it is trying to say. :-( If someone can explain to me what the intention of that text is, or what thinking motivated it, that might be useful. :-) E.g. > >> 2. To enable stateless load distribution at any point in the > >> Internet, a network domain MUST NOT forward packets outside the > >> domain whose flow label values are other than zero or pseudo- > >> random. So, If I'm an AS out in the middle of the network, and I'm forwarding packets I don't originate, I'm *required* to reset the Flow Label value because I have no idea if they satisfy the above properties? Say it ain't so! > >> Neither domain border egress routers nor intermediate > >> routers/devices (using a flow-label, for example, as a part of an > >> input-key for a load-distribution hash) can determine by > >> inspection that a value is not pseudo-random. Correct. But this isn't necessarily fatal either. > >> Therefore, if > >> nodes within a domain ignore the above recommendations to set > >> zero or pseudo-random flow label values, and such packets are > >> forwarded outside the domain, this would likely result in > >> undesirable operational implications (e.g., congestion, > >> reordering) Reordering? I don't understand why this is so. Congestion? Maybe, but it is going to far to say "likely". > >> for not only the inappropriately flow-labelled > >> packets, but also well-behaved flow-labelled packets, during > >> forwarding at various intermediate devices. Thus, a domain must > >> protect its peers by never exporting inappropriately labelled > >> packets. Right. And Bad Guys are really respectful of doing the right thing that the spec says in order NOT to be Bad Guys... > >> This document does not specify the method for enforcing > >> this rule. The suggested way to enforce it is that nodes within > >> a domain MUST NOT set the flow label to a non-zero and non- > >> pseudo-random number if the packet will leave the domain. If > >> this is not known to be the case, the border router will need to > >> change outgoing flow labels. Thomas From hingkam16@gmail.com Thu Feb 3 17:06:29 2011 Return-Path: X-Original-To: ipv6@core3.amsl.com Delivered-To: ipv6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 57BA03A68F3 for ; Thu, 3 Feb 2011 17:06:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.302 X-Spam-Level: X-Spam-Status: No, score=-3.302 tagged_above=-999 required=5 tests=[AWL=0.297, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S8mrT8OMMsQo for ; Thu, 3 Feb 2011 17:06:28 -0800 (PST) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id 6D6F73A68FD for ; Thu, 3 Feb 2011 17:06:28 -0800 (PST) Received: by iwc10 with SMTP id 10so1825695iwc.31 for ; Thu, 03 Feb 2011 17:09:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:date:message-id:subject:from:to :content-type; bh=WfdezR8pofh3Io2wpHIAMmgzmJN3edDXritNm1KeS34=; b=jS29JoWcMLk9ZMdquA9YrP699y55+MSv9voJX2lH0hi/8fN8+oYwI7N+K1Ir5bd8U8 h5PdMvG92mjpe63nnyId1v+KKBfhznXiHnBJbeN4GuWsYkF8ScUHnQqlIuqdam1h/9cZ 9M2vCbdHx/qyIKEEGot8EmTq3VYR+t7Pw6L18= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=h3aSXOUw/JM2FDFP9b1GRVz66tUthmytjDSZ1gMkwj3CEgTqqgvm0ztIBYwOh51CH2 0JUYgYjZhOC0mATnbHPEQTAX57BiyjqQwcmFHX6R1YsxKwBAQnZIoYYzgcO0bA4F9o7n RzGXbAN/ib+TqvCjbxQS2L6OWjI+J7MhaJLQM= MIME-Version: 1.0 Received: by 10.231.199.12 with SMTP id eq12mr12450256ibb.2.1296781791965; Thu, 03 Feb 2011 17:09:51 -0800 (PST) Received: by 10.231.207.11 with HTTP; Thu, 3 Feb 2011 17:09:51 -0800 (PST) Date: Fri, 4 Feb 2011 06:39:51 +0530 Message-ID: Subject: Hop-by-Hop Extension Header processed in Slow Path? From: "Hing-Kam (Kam) Lam" To: ipv6@ietf.org Content-Type: text/plain; charset=ISO-8859-1 X-BeenThere: ipv6@ietf.org 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: , X-List-Received-Date: Fri, 04 Feb 2011 01:06:29 -0000 The below white paper from Cisco asserts that most vendors including Cisco process Hop-by-Hop extension headers in CPU (slow path). Is this correct? http://www.cisco.com/en/US/technologies/tk648/tk872/technologies_white_paper0900aecd8054d37d.html If Yes, then we should not add support for more sub options with HBH header. Kam From narten@us.ibm.com Thu Feb 3 17:21:32 2011 Return-Path: X-Original-To: ipv6@core3.amsl.com Delivered-To: ipv6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 17BF23A688A for ; Thu, 3 Feb 2011 17:21:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.195 X-Spam-Level: X-Spam-Status: No, score=-106.195 tagged_above=-999 required=5 tests=[AWL=0.404, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W-reufIIAWmL for ; Thu, 3 Feb 2011 17:21:31 -0800 (PST) Received: from e33.co.us.ibm.com (e33.co.us.ibm.com [32.97.110.151]) by core3.amsl.com (Postfix) with ESMTP id 1AC3B3A659C for ; Thu, 3 Feb 2011 17:21:30 -0800 (PST) Received: from d03relay04.boulder.ibm.com (d03relay04.boulder.ibm.com [9.17.195.106]) by e33.co.us.ibm.com (8.14.4/8.13.1) with ESMTP id p141IfYj018350 for ; Thu, 3 Feb 2011 18:18:41 -0700 Received: from d03av05.boulder.ibm.com (d03av05.boulder.ibm.com [9.17.195.85]) by d03relay04.boulder.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id p141OslJ087928 for ; Thu, 3 Feb 2011 18:24:54 -0700 Received: from d03av05.boulder.ibm.com (loopback [127.0.0.1]) by d03av05.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id p141OrJA027577 for ; Thu, 3 Feb 2011 18:24:53 -0700 Received: from cichlid.raleigh.ibm.com (sig-9-76-135-212.mts.ibm.com [9.76.135.212]) by d03av05.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id p141Oq10027555 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 3 Feb 2011 18:24:53 -0700 Received: from cichlid.raleigh.ibm.com (localhost.localdomain [127.0.0.1]) by cichlid.raleigh.ibm.com (8.14.4/8.12.5) with ESMTP id p141OpwL011459; Thu, 3 Feb 2011 20:24:51 -0500 Message-Id: <201102040124.p141OpwL011459@cichlid.raleigh.ibm.com> To: Jarno Rajahalme Subject: Re: RFC3697bis Open issues 1 & 2 In-reply-to: References: <4D462E51.3040408@gmail.com> Comments: In-reply-to Jarno Rajahalme message dated "Mon, 31 Jan 2011 14:30:19 +0200." Date: Thu, 03 Feb 2011 20:24:51 -0500 From: Thomas Narten Cc: 6man , ext Brian E Carpenter X-BeenThere: ipv6@ietf.org 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: , X-List-Received-Date: Fri, 04 Feb 2011 01:21:32 -0000 Jarno Rajahalme writes: > These are two different things: flow labeling (which labels to > assign) and flow state establishment (how to treat specific > flows). My own reading has been that flow labeling mechanisms may be > stateful or stateless (for example, pseudo-random sequences were > mentioned explicitly), and that signaling mechanisms may be needed > to provide flow-specific treatment. This is an important observation. I think we can allow for stateless use of the Flow Label while preserving the original definition for other types of usages. The original restrictions about not reusing Flow Label values had to do with stateful setup protocols. There was an assumption of sorts that there was agreement between the source of the traffic and the routers on what a particular Flow Label value meant and how the router was to assign resources. If an originating node reboots, and reuses a Flow Label value too soon, the routers may not have timed out their state and undesirable things might happen. We should preserve those semantics, not that I'm optimistic we will ever need to, but because we can easily enough. For stateless usages of the flow label, it really doesn't matter if a particular Flow Label value is reused too soon. It's in the stateful case that it matters. So just require that when the Flow Label is set to a value as part of a stateful flow usage, in *that* case, make sure we don't reuse Flow Label values too soon. That is, for the more complex case (stateful involving setup) it's still fine to required adherance to the original semantics. For the stateless use, we can relax the requirements. The only place where this gets potentially messy is if you have an originating node setting the Flow Label using stateful means, but is also originating packets with zero Flow Label values, and then some intermediate device changes those values from 0 to something else -- potentially colliding with the stateful value. But this is a bit of an edge case. We could require any node that uses stateful Flow Setup to set all Flow Labels properly, or at a minimum not to send out Flow Label values that are zero. Thomas From narten@us.ibm.com Thu Feb 3 17:28:09 2011 Return-Path: X-Original-To: ipv6@core3.amsl.com Delivered-To: ipv6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BD3353A6895 for ; Thu, 3 Feb 2011 17:28:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.246 X-Spam-Level: X-Spam-Status: No, score=-106.246 tagged_above=-999 required=5 tests=[AWL=0.353, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eiQsGcEhq8R0 for ; Thu, 3 Feb 2011 17:28:08 -0800 (PST) Received: from e35.co.us.ibm.com (e35.co.us.ibm.com [32.97.110.153]) by core3.amsl.com (Postfix) with ESMTP id D78F53A659C for ; Thu, 3 Feb 2011 17:28:08 -0800 (PST) Received: from d03relay03.boulder.ibm.com (d03relay03.boulder.ibm.com [9.17.195.228]) by e35.co.us.ibm.com (8.14.4/8.13.1) with ESMTP id p141HU8V006040 for ; Thu, 3 Feb 2011 18:17:30 -0700 Received: from d03av03.boulder.ibm.com (d03av03.boulder.ibm.com [9.17.195.169]) by d03relay03.boulder.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id p141VUmQ124026 for ; Thu, 3 Feb 2011 18:31:30 -0700 Received: from d03av03.boulder.ibm.com (loopback [127.0.0.1]) by d03av03.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id p141VUu4010161 for ; Thu, 3 Feb 2011 18:31:30 -0700 Received: from cichlid.raleigh.ibm.com (sig-9-76-135-212.mts.ibm.com [9.76.135.212]) by d03av03.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id p141VSLu010143 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 3 Feb 2011 18:31:29 -0700 Received: from cichlid.raleigh.ibm.com (localhost.localdomain [127.0.0.1]) by cichlid.raleigh.ibm.com (8.14.4/8.12.5) with ESMTP id p141VRkx011488; Thu, 3 Feb 2011 20:31:28 -0500 Message-Id: <201102040131.p141VRkx011488@cichlid.raleigh.ibm.com> To: Jarno Rajahalme Subject: Re: RFC 3697bis Open issue 4 In-reply-to: References: <4D46315C.3050806@gmail.com> Comments: In-reply-to Jarno Rajahalme message dated "Mon, 31 Jan 2011 14:48:45 +0200." Date: Thu, 03 Feb 2011 20:31:27 -0500 From: Thomas Narten Cc: 6man , ext Brian E Carpenter X-BeenThere: ipv6@ietf.org 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: , X-List-Received-Date: Fri, 04 Feb 2011 01:28:10 -0000 I'm not an RSVP expert, but I wonder if the wording at issue comes from the notion that (in some cases) the receiver is the one that actually initates flow setup (in the reverse direction) and wants to tell the routers what Flow Labels the source is using. The source is labeling the packets, but is not actually involved in doing the Flow Setup (and indeed, may not even know it is in use). I think it is OK to drop the words. Thomas Jarno Rajahalme writes: > > ISSUE 4. The Introduction previously included: > > > > Doing this [setting the flow label] > > enables load spreading and receiver oriented resource allocation, for > > example. > > > > The phrase "receiver oriented resource allocation" has been deleted because > > we don't know what it means. > > > > QUESTION: Is this deletion OK? > Full context: > "The minimum level of IPv6 flow support consists of labeling the > flows. IPv6 source nodes supporting the flow labeling MUST be able > to label known flows (e.g., TCP connections, application streams), > even if the node itself would not require any flow-specific > treatment. Doing this enables load spreading and receiver oriented > resource reservations, for example." > The phrase "receiver oriented resource allocation" was intended to refer to a case where a receiver of a flow allocated resources for the flow (e.g. on a radio interface). This could be useful where the source considers the traffic best-effort, but where the destination wants/needs better than best-effort treatment (without involving the source in any way). > It is OK for deletion. > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From narten@us.ibm.com Thu Feb 3 17:33:31 2011 Return-Path: X-Original-To: ipv6@core3.amsl.com Delivered-To: ipv6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B84E93A672E for ; Thu, 3 Feb 2011 17:33:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.285 X-Spam-Level: X-Spam-Status: No, score=-106.285 tagged_above=-999 required=5 tests=[AWL=0.314, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bjLqTScP0Ii7 for ; Thu, 3 Feb 2011 17:33:30 -0800 (PST) Received: from e5.ny.us.ibm.com (e5.ny.us.ibm.com [32.97.182.145]) by core3.amsl.com (Postfix) with ESMTP id B97B93A659C for ; Thu, 3 Feb 2011 17:33:30 -0800 (PST) Received: from d01dlp02.pok.ibm.com (d01dlp02.pok.ibm.com [9.56.224.85]) by e5.ny.us.ibm.com (8.14.4/8.13.1) with ESMTP id p141CMcA024643 for ; Thu, 3 Feb 2011 20:13:01 -0500 Received: from d01relay03.pok.ibm.com (d01relay03.pok.ibm.com [9.56.227.235]) by d01dlp02.pok.ibm.com (Postfix) with ESMTP id C06DC4DE804A for ; Thu, 3 Feb 2011 20:36:15 -0500 (EST) Received: from d01av01.pok.ibm.com (d01av01.pok.ibm.com [9.56.224.215]) by d01relay03.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id p141arsZ291934 for ; Thu, 3 Feb 2011 20:36:53 -0500 Received: from d01av01.pok.ibm.com (loopback [127.0.0.1]) by d01av01.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id p141ar9D017350 for ; Thu, 3 Feb 2011 20:36:53 -0500 Received: from cichlid.raleigh.ibm.com (sig-9-76-135-212.mts.ibm.com [9.76.135.212]) by d01av01.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id p141aqxc017317 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 3 Feb 2011 20:36:52 -0500 Received: from cichlid.raleigh.ibm.com (localhost.localdomain [127.0.0.1]) by cichlid.raleigh.ibm.com (8.14.4/8.12.5) with ESMTP id p141apKn011527; Thu, 3 Feb 2011 20:36:51 -0500 Message-Id: <201102040136.p141apKn011527@cichlid.raleigh.ibm.com> To: Jarno Rajahalme Subject: Re: RFC3697bis Open Issue 5 In-reply-to: <05834D09-0E37-497D-B1E6-3F008E98AECB@nsn.com> References: <4D46315C.3050806@gmail.com> <05834D09-0E37-497D-B1E6-3F008E98AECB@nsn.com> Comments: In-reply-to Jarno Rajahalme message dated "Mon, 31 Jan 2011 14:51:36 +0200." Date: Thu, 03 Feb 2011 20:36:51 -0500 From: Thomas Narten X-Content-Scanned: Fidelis XPS MAILER Cc: 6man , ext Brian E Carpenter X-BeenThere: ipv6@ietf.org 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: , X-List-Received-Date: Fri, 04 Feb 2011 01:33:31 -0000 Jarno Rajahalme writes: > > ISSUE 5. Section 2 says: > > > > IPv6 nodes MUST NOT assume that the Flow Label value in a incoming > > packet is identical to the value set by the source node. > > > > QUESTION: This needs to be reconciled with the security usage mentioned in > > draft-gont-. Would SHOULD NOT be acceptable? IMO, "MUST NOT" is the wrong word. What we want to say here is that it is possible for intruders, Bad Guys, and broken implementations to produce packets in which the Flow Label is not identical to its original value. Implementations MUST (SHOULD?) take necessary steps to protect themselves from being vulnerable to DOS and other types of attack that could result. Or something like that. I.e., give the implementor some practice advice, rather than making this a protocol requirement. And if we have some examples of the kinds of bad things that an implementation should look out for, list a few of them. Thomas From brian.e.carpenter@gmail.com Thu Feb 3 18:49:26 2011 Return-Path: X-Original-To: ipv6@core3.amsl.com Delivered-To: ipv6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 97A433A697B for ; Thu, 3 Feb 2011 18:49:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.479 X-Spam-Level: X-Spam-Status: No, score=-103.479 tagged_above=-999 required=5 tests=[AWL=0.120, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j413jcH-nfqM for ; Thu, 3 Feb 2011 18:49:25 -0800 (PST) Received: from mail-qy0-f179.google.com (mail-qy0-f179.google.com [209.85.216.179]) by core3.amsl.com (Postfix) with ESMTP id 390C23A6973 for ; Thu, 3 Feb 2011 18:49:24 -0800 (PST) Received: by qyj19 with SMTP id 19so1552540qyj.10 for ; Thu, 03 Feb 2011 18:52:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:organization:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=AOHnP6RDxfrf0s33jWFSNcV18BPAIg0JkcFCJdFg6yk=; b=qLebXrgf2C4xmEEU2sUUgSkKuhfijg1vieXkjUZAypEBu2yyHsvY1tlkqoWdTQyFk+ rgzRoQ1jMApFcy+8uipfM6+1W0OvZHy5oThQgrOq1ZGH1kr3blCM/MAma2AIFyG1Dul5 SCQZp4GAj9j6DKY9AO7VkN4SGGy+p9aQF1TQY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; b=lbBxrf7ASJ7sOiXYu7lQDG8Y5ONttlj8dx8yQeZLxEKToLw+hVLaG98fOLOJysvvo4 jiMdfqdMgD7jwwTq8HQy8OT/wbJaG3L/ZsHyHdskrIKdMlaXZCOTA/0+1R/4VazvrIJd emZ8iq8JebkAHxtp3dSpgI+RzrJvOXViWwnMI= Received: by 10.224.61.15 with SMTP id r15mr4106707qah.9.1296787968392; Thu, 03 Feb 2011 18:52:48 -0800 (PST) Received: from [10.1.1.4] ([121.98.190.33]) by mx.google.com with ESMTPS id y17sm173147qci.45.2011.02.03.18.52.45 (version=SSLv3 cipher=RC4-MD5); Thu, 03 Feb 2011 18:52:47 -0800 (PST) Message-ID: <4D4B69F8.6040507@gmail.com> Date: Fri, 04 Feb 2011 15:52:40 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Thomas Narten Subject: Re: RFC 3697bis Open issue 9 References: <4D46315C.3050806@gmail.com> <23233BB6-C4D8-414F-A079-5A53B9A49AFF@nsn.com> <4D46C48B.1060806@joelhalpern.com> <201102040100.p14103Q1011224@cichlid.raleigh.ibm.com> In-Reply-To: <201102040100.p14103Q1011224@cichlid.raleigh.ibm.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: 6man X-BeenThere: ipv6@ietf.org 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: , X-List-Received-Date: Fri, 04 Feb 2011 02:49:26 -0000 On 2011-02-04 14:00, Thomas Narten wrote: > FWIW.... > > I agree with Joel. I'd like Flow Labels to remain immutable *except* > in the case where it is zero. I know we can't enforce that, but that > is the principle we should continue to support, and devices that > violate this principle should be flogged by the Protocol Police. :-) > > I think we really do want the Flow Label to retain end-to-end > meaning. That is, it's contents are created as close to the > originating source as possible, since the source probably has the most > information available to set it sensibly. > > That means a first hop router or a router at the originating site's > boundary should be able to change it from 0 to something sensible. I > view this is a sort of optimization that allows the Flow Label to get > set to a useful value even in cases where the host can't be upgraded > to do that. I do not want to encourage routers elsewhere in the > network to be modifying the Flow Label. > > We should not just say that because we can't enforce that Flow Labels > in received packets satisfy certain properties, we should give up and > let it be modified in any way anyone sees fit. > > My view is that we are just relaxing the Flow Label semantics a little > bit. We aren't completely changing them. I think we can do this, while > still preserving the original intent (at least in most aspects). No > need to change the semantics of the Flow Label any more than the > minimal necessary to make it useful for load balancing. > > IMO, the old text in the document should just be tossed. It makes no > sense to me and I don't understand what it is trying to say. :-( > > If someone can explain to me what the intention of that text is, or > what thinking motivated it, that might be useful. :-) > > E.g. > >>>> 2. To enable stateless load distribution at any point in the >>>> Internet, a network domain MUST NOT forward packets outside the >>>> domain whose flow label values are other than zero or pseudo- >>>> random. > > So, If I'm an AS out in the middle of the network, and I'm forwarding > packets I don't originate, I'm *required* to reset the Flow Label > value because I have no idea if they satisfy the above properties? Say > it ain't so! That certainly wasn't the intention. The intention was to say that a domain that is mucking with the flow label internally must not export packets with mucked-about flow labels. The problem here is (and I think we basically agree) that we don't want people to do strange things with the flow label, but we know that we can't detect if they do. I'd like to have normative language that allows the protocol police to prosecute if somebody exports strange flow labels. Now, getting back to another of your points, if somebody does (for example) export every packet with the flow label set to abcde, the worst this can do in the load-sharing model is make the hash function work less well. So maybe the current text worries about this too much? > > >>>> Neither domain border egress routers nor intermediate >>>> routers/devices (using a flow-label, for example, as a part of an >>>> input-key for a load-distribution hash) can determine by >>>> inspection that a value is not pseudo-random. > > Correct. But this isn't necessarily fatal either. Agreed. > >>>> Therefore, if >>>> nodes within a domain ignore the above recommendations to set >>>> zero or pseudo-random flow label values, and such packets are >>>> forwarded outside the domain, this would likely result in >>>> undesirable operational implications (e.g., congestion, >>>> reordering) > > Reordering? I don't understand why this is so. If they break the rule that all packets of a given flow carry the same label, reordering can happen in an ECMP or LAG scenario. But of course the traffic that suffers is the traffic with wrongly set labels, so maybe we don't care. > > Congestion? Maybe, but it is going to far to say "likely". Oops, I thought that had been changed to "might". > >>>> for not only the inappropriately flow-labelled >>>> packets, but also well-behaved flow-labelled packets, during >>>> forwarding at various intermediate devices. Thus, a domain must >>>> protect its peers by never exporting inappropriately labelled >>>> packets. > > Right. And Bad Guys are really respectful of doing the right thing > that the spec says in order NOT to be Bad Guys... Well, this is where the protocol police would come in. But actually it seems that this is going to hurt the Bad Guys' own traffic more than anyone else. > >>>> This document does not specify the method for enforcing >>>> this rule. The suggested way to enforce it is that nodes within >>>> a domain MUST NOT set the flow label to a non-zero and non- >>>> pseudo-random number if the packet will leave the domain. If >>>> this is not known to be the case, the border router will need to >>>> change outgoing flow labels. I'm inclined to change my mind about this and simply make it a SHOULD with the observation that traffic that breaks the rule will not get treated correctly further downstream. Brian From brian.e.carpenter@gmail.com Thu Feb 3 18:51:00 2011 Return-Path: X-Original-To: ipv6@core3.amsl.com Delivered-To: ipv6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C7AC43A68CF for ; Thu, 3 Feb 2011 18:51:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.48 X-Spam-Level: X-Spam-Status: No, score=-103.48 tagged_above=-999 required=5 tests=[AWL=0.119, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZWfulqw9OWSL for ; Thu, 3 Feb 2011 18:50:58 -0800 (PST) Received: from mail-qy0-f179.google.com (mail-qy0-f179.google.com [209.85.216.179]) by core3.amsl.com (Postfix) with ESMTP id C6FEC3A694C for ; Thu, 3 Feb 2011 18:50:57 -0800 (PST) Received: by qyj19 with SMTP id 19so1553188qyj.10 for ; Thu, 03 Feb 2011 18:54:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:organization:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=b2GV3cxKJmoFqsIt10Htqqy+V3ZXJ1roy7wxMO9imro=; b=CbmQJkGAr7FLex39WFGTmIBOhVnEDVDKEClAKVgijdP0ZHIPxY0VYBcO1XeX8U29aq +LqcOid6NDujkYwQBOoWEMDM8vhrkR6zG+IdHiGbPlgPqI47ACsq+bd/5D8GguZNq0GD KuW3S7RL0TROTemcukkAts/Jfp4LiOUhM/m+0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; b=QNqIDTXR4kR9B1DclqDPWUnBM/UdEFuPShS/tWn/ts+7bVERbmkXMjQwl3HVNsLn2M cELNm/zdRzJqj/4kxx9/NaYlYYmc2ByPUpUvHObi7okVKxTjA9cY7VZ0cFCOH3lfEbnE rgKHPe/adXp3DIG76Xmam8eRnAaKXXZj7K8pQ= Received: by 10.229.81.206 with SMTP id y14mr10080635qck.127.1296788061466; Thu, 03 Feb 2011 18:54:21 -0800 (PST) Received: from [10.1.1.4] ([121.98.190.33]) by mx.google.com with ESMTPS id t7sm180736qcs.16.2011.02.03.18.54.19 (version=SSLv3 cipher=RC4-MD5); Thu, 03 Feb 2011 18:54:20 -0800 (PST) Message-ID: <4D4B6A56.6010104@gmail.com> Date: Fri, 04 Feb 2011 15:54:14 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Thomas Narten Subject: Re: RFC3697bis Open issues 1 & 2 References: <4D462E51.3040408@gmail.com> <201102040124.p141OpwL011459@cichlid.raleigh.ibm.com> In-Reply-To: <201102040124.p141OpwL011459@cichlid.raleigh.ibm.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: 6man X-BeenThere: ipv6@ietf.org 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: , X-List-Received-Date: Fri, 04 Feb 2011 02:51:00 -0000 I agree. This can be cleaned up in the text. Brian On 2011-02-04 14:24, Thomas Narten wrote: > Jarno Rajahalme writes: > >> These are two different things: flow labeling (which labels to >> assign) and flow state establishment (how to treat specific >> flows). My own reading has been that flow labeling mechanisms may be >> stateful or stateless (for example, pseudo-random sequences were >> mentioned explicitly), and that signaling mechanisms may be needed >> to provide flow-specific treatment. > > This is an important observation. > > I think we can allow for stateless use of the Flow Label while > preserving the original definition for other types of usages. > > The original restrictions about not reusing Flow Label values had to > do with stateful setup protocols. There was an assumption of sorts > that there was agreement between the source of the traffic and the > routers on what a particular Flow Label value meant and how the router > was to assign resources. If an originating node reboots, and reuses a > Flow Label value too soon, the routers may not have timed out their > state and undesirable things might happen. > > We should preserve those semantics, not that I'm optimistic we will > ever need to, but because we can easily enough. > > For stateless usages of the flow label, it really doesn't matter if a > particular Flow Label value is reused too soon. > > It's in the stateful case that it matters. So just require that when > the Flow Label is set to a value as part of a stateful flow usage, in > *that* case, make sure we don't reuse Flow Label values too soon. That > is, for the more complex case (stateful involving setup) it's still > fine to required adherance to the original semantics. For the > stateless use, we can relax the requirements. > > The only place where this gets potentially messy is if you have an > originating node setting the Flow Label using stateful means, but is > also originating packets with zero Flow Label values, and then some > intermediate device changes those values from 0 to something else -- > potentially colliding with the stateful value. But this is a bit of an > edge case. We could require any node that uses stateful Flow Setup to > set all Flow Labels properly, or at a minimum not to send out Flow > Label values that are zero. > > Thomas > From brian.e.carpenter@gmail.com Thu Feb 3 18:53:02 2011 Return-Path: X-Original-To: ipv6@core3.amsl.com Delivered-To: ipv6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 413DA3A6973 for ; Thu, 3 Feb 2011 18:53:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.481 X-Spam-Level: X-Spam-Status: No, score=-103.481 tagged_above=-999 required=5 tests=[AWL=0.118, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r3zbehL6tzk6 for ; Thu, 3 Feb 2011 18:53:00 -0800 (PST) Received: from mail-qy0-f179.google.com (mail-qy0-f179.google.com [209.85.216.179]) by core3.amsl.com (Postfix) with ESMTP id 99DDC3A68CF for ; Thu, 3 Feb 2011 18:53:00 -0800 (PST) Received: by qyj19 with SMTP id 19so1554044qyj.10 for ; Thu, 03 Feb 2011 18:56:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:organization:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=2c+QrfS3huVGmjwrKx1UtymfYYgnz9PcbEQQEoswGQE=; b=CYArx3tXiQP6Lv9lwLrIs1gU2BMCmj0dbcKDsIUDb1zeEwjwjICp4JgFyK/7IHfYrT M7bzW2sTZqQakWsIfxt8mZVPNThqvOnVJBX+jszdIhxQfqklsP+BBuqTxNhPmxlDyI/j Cv+sa6bwArwEDvClU2+4I0IOMJcG3jMrhWQlk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; b=Zweg5PCE7Y23ZfZEPkjQQxE3Fsvevn4bN14iLx7F3IznGvbKVdxckfwnwqXqVxG9VS Rd1mu5Eeka8fOGYmezVNZpwN/hbqwtHsJ8gnTHc6bkxi1OALBokxmrP78+RSLsywlRZO TJBNlLFKVfTDJgnKL2Nd04HNsTwKPEaEskRTk= Received: by 10.224.29.6 with SMTP id o6mr10346314qac.380.1296788184184; Thu, 03 Feb 2011 18:56:24 -0800 (PST) Received: from [10.1.1.4] ([121.98.190.33]) by mx.google.com with ESMTPS id nb15sm179793qcb.26.2011.02.03.18.56.21 (version=SSLv3 cipher=RC4-MD5); Thu, 03 Feb 2011 18:56:23 -0800 (PST) Message-ID: <4D4B6AD1.1030809@gmail.com> Date: Fri, 04 Feb 2011 15:56:17 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Thomas Narten Subject: Re: RFC 3697bis Open issue 4 References: <4D46315C.3050806@gmail.com> <201102040131.p141VRkx011488@cichlid.raleigh.ibm.com> In-Reply-To: <201102040131.p141VRkx011488@cichlid.raleigh.ibm.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: 6man X-BeenThere: ipv6@ietf.org 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: , X-List-Received-Date: Fri, 04 Feb 2011 02:53:02 -0000 On 2011-02-04 14:31, Thomas Narten wrote: > I'm not an RSVP expert, but I wonder if the wording at issue comes > from the notion that (in some cases) the receiver is the one that > actually initates flow setup (in the reverse direction) and wants to > tell the routers what Flow Labels the source is using. The source is > labeling the packets, but is not actually involved in doing the Flow > Setup (and indeed, may not even know it is in use). > > I think it is OK to drop the words. Yes. A flow label can in theory be signalled in an RSVP TSpec, but that is outside the scope of 3697bis, as long as we do the appropriate text clean-up about stateless v stateful v signalled methods. Brian > > Thomas > > Jarno Rajahalme writes: > > >>> ISSUE 4. The Introduction previously included: >>> >>> Doing this [setting the flow label] >>> enables load spreading and receiver oriented resource allocation, for >>> example. >>> >>> The phrase "receiver oriented resource allocation" has been deleted because >>> we don't know what it means. >>> >>> QUESTION: Is this deletion OK? > >> Full context: > >> "The minimum level of IPv6 flow support consists of labeling the >> flows. IPv6 source nodes supporting the flow labeling MUST be able >> to label known flows (e.g., TCP connections, application streams), >> even if the node itself would not require any flow-specific >> treatment. Doing this enables load spreading and receiver oriented >> resource reservations, for example." > >> The phrase "receiver oriented resource allocation" was intended to refer to a case where a receiver of a flow allocated resources for the flow (e.g. on a radio interface). This could be useful where the source considers the traffic best-effort, but where the destination wants/needs better than best-effort treatment (without involving the source in any way). > >> It is OK for deletion. >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list >> ipv6@ietf.org >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- > From christopher.morrow@gmail.com Thu Feb 3 18:54:21 2011 Return-Path: X-Original-To: ipv6@core3.amsl.com Delivered-To: ipv6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 412AD3A69DF for ; Thu, 3 Feb 2011 18:54:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9I6uTk3M7ajw for ; Thu, 3 Feb 2011 18:54:20 -0800 (PST) Received: from mail-ew0-f44.google.com (mail-ew0-f44.google.com [209.85.215.44]) by core3.amsl.com (Postfix) with ESMTP id 1C9383A6984 for ; Thu, 3 Feb 2011 18:54:19 -0800 (PST) Received: by ewy8 with SMTP id 8so1154456ewy.31 for ; Thu, 03 Feb 2011 18:57:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=WiiT9bQQM4ljvYfgoscSkOi1x2kENV7UQoYcEqiSMrU=; b=oSZMGKg5Pv6KPIusbYVZZ/EFR8OMSP/cNt0PjPBtn58XaL61QZEsYxeX+ZxJkUVeQK GzPIruQ3c89gmbHVcuWV/mScLgCH/Ny2LOKgo8A+VKG7TycOmS/70cMfQWTxr52CqSs+ XryFzjH0Tnk6uoSYGqmn/lA1Tg3LrJmFIB5dU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=oi8fXHFbzEufecBFKEtF/h4MrJtQjfYF9FgV8sir36m8YFy1uQCvJ7Py07ywiFB3cq /HGG6ZYJBlrOBaqK6fJIBOQ/6dEsf3+xKHqmJxGeylwfgy6dxirckNIXePBpFR1h03NM Tcbmf9gh8vVEiDbMlhdWLG32iVbNQjlnbHTyA= MIME-Version: 1.0 Received: by 10.213.19.20 with SMTP id y20mr716591eba.75.1296788263104; Thu, 03 Feb 2011 18:57:43 -0800 (PST) Received: by 10.213.113.6 with HTTP; Thu, 3 Feb 2011 18:57:43 -0800 (PST) In-Reply-To: References: Date: Thu, 3 Feb 2011 21:57:43 -0500 Message-ID: Subject: Re: Hop-by-Hop Extension Header processed in Slow Path? From: Christopher Morrow To: "Hing-Kam (Kam) Lam" Content-Type: text/plain; charset=ISO-8859-1 Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org 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: , X-List-Received-Date: Fri, 04 Feb 2011 02:54:21 -0000 On Thu, Feb 3, 2011 at 8:09 PM, Hing-Kam (Kam) Lam wrote: > The below white paper from Cisco asserts that most vendors including > Cisco process Hop-by-Hop extension headers in CPU (slow path). Is this > correct? > > http://www.cisco.com/en/US/technologies/tk648/tk872/technologies_white_paper0900aecd8054d37d.html > > If Yes, then we should not add support for more sub options with HBH header. yes, see notes from me (in particular) about this from the last 2+ years... no more HBH header options pls... OR understand that these may/will get dropped (probably the whole packet actually) at some provider edges. From brian.e.carpenter@gmail.com Thu Feb 3 19:00:23 2011 Return-Path: X-Original-To: ipv6@core3.amsl.com Delivered-To: ipv6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C27B73A6ADE for ; Thu, 3 Feb 2011 19:00:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.482 X-Spam-Level: X-Spam-Status: No, score=-103.482 tagged_above=-999 required=5 tests=[AWL=0.117, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SuYeFftcNK9q for ; Thu, 3 Feb 2011 19:00:22 -0800 (PST) Received: from mail-qy0-f179.google.com (mail-qy0-f179.google.com [209.85.216.179]) by core3.amsl.com (Postfix) with ESMTP id 5B3553A6AB7 for ; Thu, 3 Feb 2011 19:00:22 -0800 (PST) Received: by qyj19 with SMTP id 19so1557139qyj.10 for ; Thu, 03 Feb 2011 19:03:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:organization:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=PyXkeozna8b7XASSY+kfCHohwmxkvf/75cLPMtTaNeE=; b=EH1S6W0uZze2TTovNt46WayfCgTxkYTgeRBa11jJUASGEh6+qdxbkFO86MC+HFteZW w5pE08ICP2f9oMkQ+pFZQ+Negai5DOpIKA8+BNmvnPw5Plv0DsEOCOUoN3I+8qc9rzEm ENPHetZ4AevB5ozM9c+NCd17wzodyH4NMn6Z8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; b=BjMmko21bFJIVYAG5kNNx+ml0pCzm83EeQQmotTvaY6BFymxYeFhAjHuiGRqAXd1ks lwDVZH7Ogcx9Ug+z+CHSfmeYV6Sbvl9v5h4Nh4gpUJeu2LOUogL5K4euczqoNdiJnfQQ tN6xFG3EGmXwhggA5quqx7A54AZwgxhgW9Egs= Received: by 10.224.89.78 with SMTP id d14mr10445030qam.263.1296788626056; Thu, 03 Feb 2011 19:03:46 -0800 (PST) Received: from [10.1.1.4] ([121.98.190.33]) by mx.google.com with ESMTPS id s10sm182331qco.35.2011.02.03.19.03.43 (version=SSLv3 cipher=RC4-MD5); Thu, 03 Feb 2011 19:03:45 -0800 (PST) Message-ID: <4D4B6C8A.2060306@gmail.com> Date: Fri, 04 Feb 2011 16:03:38 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Thomas Narten Subject: Re: RFC3697bis Open Issue 5 References: <4D46315C.3050806@gmail.com> <05834D09-0E37-497D-B1E6-3F008E98AECB@nsn.com> <201102040136.p141apKn011527@cichlid.raleigh.ibm.com> In-Reply-To: <201102040136.p141apKn011527@cichlid.raleigh.ibm.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: 6man X-BeenThere: ipv6@ietf.org 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: , X-List-Received-Date: Fri, 04 Feb 2011 03:00:23 -0000 On 2011-02-04 14:36, Thomas Narten wrote: > Jarno Rajahalme writes: > > >>> ISSUE 5. Section 2 says: >>> >>> IPv6 nodes MUST NOT assume that the Flow Label value in a incoming >>> packet is identical to the value set by the source node. >>> >>> QUESTION: This needs to be reconciled with the security usage mentioned in >>> draft-gont-. Would SHOULD NOT be acceptable? > > IMO, "MUST NOT" is the wrong word. > > What we want to say here is that it is possible for intruders, Bad > Guys, and broken implementations to produce packets in which the Flow > Label is not identical to its original value. Implementations MUST > (SHOULD?) take necessary steps to protect themselves from being > vulnerable to DOS and other types of attack that could result. > > Or something like that. > > I.e., give the implementor some practice advice, rather than making > this a protocol requirement. > > And if we have some examples of the kinds of bad things that an > implementation should look out for, list a few of them. OK, something like Although the flow label is defined as immutable once it has been set to a non-zero value, implementers should be aware that it is an unprotected field that could have been accidentally or intentionally changed en route. Implementations MUST take appropriate steps to protect themselves from being vulnerable to denial of service and other types of attack that could result. Brian From jmh@joelhalpern.com Thu Feb 3 19:07:53 2011 Return-Path: X-Original-To: ipv6@core3.amsl.com Delivered-To: ipv6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4820E3A69E4 for ; Thu, 3 Feb 2011 19:07:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.595 X-Spam-Level: X-Spam-Status: No, score=-102.595 tagged_above=-999 required=5 tests=[AWL=0.004, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Va4wFItdFYpY for ; Thu, 3 Feb 2011 19:07:52 -0800 (PST) Received: from hermes.out.tigertech.net (hermes.out.tigertech.net [74.114.88.72]) by core3.amsl.com (Postfix) with ESMTP id 4C4513A69CF for ; Thu, 3 Feb 2011 19:07:52 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 6779F4300B7; Thu, 3 Feb 2011 19:11:16 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at hermes.tigertech.net Received: from [10.10.10.102] (pool-71-161-50-121.clppva.btas.verizon.net [71.161.50.121]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by hermes.tigertech.net (Postfix) with ESMTPSA id ACD1A4300B6; Thu, 3 Feb 2011 19:11:15 -0800 (PST) Message-ID: <4D4B6E54.9000703@joelhalpern.com> Date: Thu, 03 Feb 2011 22:11:16 -0500 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.13) Gecko/20101207 Lightning/1.0b2 Thunderbird/3.1.7 MIME-Version: 1.0 To: Christopher Morrow Subject: Re: Hop-by-Hop Extension Header processed in Slow Path? References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org 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: , X-List-Received-Date: Fri, 04 Feb 2011 03:07:53 -0000 Lets be a little careful here: 1) If we say "No Extension Headers for intermediate processing", and "No Hop By Hop Options", then we are saying that we do not want any extensions intended to be processed in intermediate routers. While I personally like that, I want to make really sure that we understand that is what we are saying. 2) I have been told that many large rotuers have a setting that causes them to ignore the hop by hop options field. To the degree that is both true and turned on, then we need to allow for that in our think (both positive and negative.) Yours, Joel On 2/3/2011 9:57 PM, Christopher Morrow wrote: > On Thu, Feb 3, 2011 at 8:09 PM, Hing-Kam (Kam) Lam wrote: >> The below white paper from Cisco asserts that most vendors including >> Cisco process Hop-by-Hop extension headers in CPU (slow path). Is this >> correct? >> >> http://www.cisco.com/en/US/technologies/tk648/tk872/technologies_white_paper0900aecd8054d37d.html >> >> If Yes, then we should not add support for more sub options with HBH header. > > yes, see notes from me (in particular) about this from the last 2+ > years... no more HBH header options pls... OR understand that these > may/will get dropped (probably the whole packet actually) at some > provider edges. > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > From christopher.morrow@gmail.com Thu Feb 3 19:13:44 2011 Return-Path: X-Original-To: ipv6@core3.amsl.com Delivered-To: ipv6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2F0EB3A69E6 for ; Thu, 3 Feb 2011 19:13:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SmFl7S2STH16 for ; Thu, 3 Feb 2011 19:13:43 -0800 (PST) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by core3.amsl.com (Postfix) with ESMTP id DB14C3A69A1 for ; Thu, 3 Feb 2011 19:13:42 -0800 (PST) Received: by eyd10 with SMTP id 10so1153920eyd.31 for ; Thu, 03 Feb 2011 19:17:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=tYgSi27ggltY9zJ171ks6SAHF6E+kYdKTfrK3cOCviE=; b=dz8xUNeSWSLLzqoFFKR+HdPbhCPr4cCPBv93vE1Ito48QjCC6QIzFHI0hLBzSliUme HGvZ6g4VWiHZS2WiYgdaw5R2k+oiJI2QOeb3n01r61G5UhxFfKZXk77PI+43ZQK+JONR F/0otakTB/T9nYh66V+ftE9xOqTaY7yAtF4o8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=VIbVsHFF6A4ecYSaciehYacGjIj2D6dbsJ/8CKrUhKVgFpYA3jNLgKr/u+fYBN6PWn SdAoIZ/3AP7IoeAfYGVBiquXRN3aILQXd6pAwNbZUcqZAVYtUByTSD3BmbaoqE/sTAsA lHUhzeV8SozGdvWY1Cb3BO0xITQWCrQ14U218= MIME-Version: 1.0 Received: by 10.213.15.135 with SMTP id k7mr12731986eba.26.1296789426095; Thu, 03 Feb 2011 19:17:06 -0800 (PST) Received: by 10.213.113.6 with HTTP; Thu, 3 Feb 2011 19:17:06 -0800 (PST) In-Reply-To: <4D4B6E54.9000703@joelhalpern.com> References: <4D4B6E54.9000703@joelhalpern.com> Date: Thu, 3 Feb 2011 22:17:06 -0500 Message-ID: Subject: Re: Hop-by-Hop Extension Header processed in Slow Path? From: Christopher Morrow To: "Joel M. Halpern" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org 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: , X-List-Received-Date: Fri, 04 Feb 2011 03:13:44 -0000 On Thu, Feb 3, 2011 at 10:11 PM, Joel M. Halpern wrot= e: > Lets be a little careful here: > 1) If we say "No Extension Headers for intermediate processing", and "No = Hop > By Hop Options", then we are saying that we do not want any extensions > intended to be processed in intermediate routers. =A0While I personally l= ike > that, I want to make really sure that we understand that is what we are > saying. My feeling is this: hop-by-hop processing will happen in slow-path (if you permit it to happen at all), you can't build a router today with an asic that'll know how to handle options which are created in the future :( This means that the gear in the network is subject to failure at relatively low packet rates (as compared to interface rates), it also means that the failure is likely not just at the interface level (the RP/RE/PRP/etc will be doing this processing), much of this box will fail. This is an unacceptable outcome. > 2) I have been told that many large rotuers have a setting that causes th= em > to ignore the hop by hop options field. =A0To the degree that is both tru= e and > turned on, then we need to allow for that in our think (both positive and > negative.) I've mostly seen the 'throw the packet away' option... I agree that if I can ignore these in all of my routers I don't care what you do with them before you see my router or after I pass this off to my friendly neighbor router. This means that if you expect all intermediate networks to do "something" for you with this option, you will not get it, your application and other things should never rely upon this being functional. if we get to that then... why are we making these exist anyways? -chris (I agree that being clear here is a good plan) > > Yours, > Joel > > On 2/3/2011 9:57 PM, Christopher Morrow wrote: >> >> On Thu, Feb 3, 2011 at 8:09 PM, Hing-Kam (Kam) Lam >> =A0wrote: >>> >>> The below white paper from Cisco asserts that most vendors including >>> Cisco process Hop-by-Hop extension headers in CPU (slow path). Is this >>> correct? >>> >>> >>> http://www.cisco.com/en/US/technologies/tk648/tk872/technologies_white_= paper0900aecd8054d37d.html >>> >>> If Yes, then we should not add support for more sub options with HBH >>> header. >> >> yes, see notes from me (in particular) about this from the last 2+ >> years... no more HBH header options pls... OR understand that these >> may/will get dropped (probably the whole packet actually) at some >> provider edges. >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list >> ipv6@ietf.org >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- >> > From manav.bhatia@alcatel-lucent.com Thu Feb 3 20:02:09 2011 Return-Path: X-Original-To: ipv6@core3.amsl.com Delivered-To: ipv6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 67D1D3A6A08 for ; Thu, 3 Feb 2011 20:02:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.339 X-Spam-Level: X-Spam-Status: No, score=-6.339 tagged_above=-999 required=5 tests=[AWL=0.260, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OjkQGlP99gW5 for ; Thu, 3 Feb 2011 20:02:08 -0800 (PST) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by core3.amsl.com (Postfix) with ESMTP id E76553A6407 for ; Thu, 3 Feb 2011 20:02:07 -0800 (PST) Received: from inbansmailrelay1.in.alcatel-lucent.com (h135-250-11-31.lucent.com [135.250.11.31]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id p1445PvI018042 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 3 Feb 2011 22:05:28 -0600 (CST) Received: from INBANSXCHHUB03.in.alcatel-lucent.com (inbansxchhub03.in.alcatel-lucent.com [135.250.12.80]) by inbansmailrelay1.in.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p1445PvB031829 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 4 Feb 2011 09:35:25 +0530 Received: from INBANSXCHMBSA1.in.alcatel-lucent.com ([135.250.12.56]) by INBANSXCHHUB03.in.alcatel-lucent.com ([135.250.12.80]) with mapi; Fri, 4 Feb 2011 09:35:24 +0530 From: "Bhatia, Manav (Manav)" To: "Joel M. Halpern" , Christopher Morrow Date: Fri, 4 Feb 2011 09:35:22 +0530 Subject: RE: Hop-by-Hop Extension Header processed in Slow Path? Thread-Topic: Hop-by-Hop Extension Header processed in Slow Path? Thread-Index: AcvEGTcbPA/1w6fFSJe+eaqnYCIQZQABuyaA Message-ID: <7C362EEF9C7896468B36C9B79200D8350CFB23E849@INBANSXCHMBSA1.in.alcatel-lucent.com> References: <4D4B6E54.9000703@joelhalpern.com> In-Reply-To: <4D4B6E54.9000703@joelhalpern.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 X-Scanned-By: MIMEDefang 2.64 on 135.250.11.31 Cc: "ipv6@ietf.org" X-BeenThere: ipv6@ietf.org 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: , X-List-Received-Date: Fri, 04 Feb 2011 04:02:09 -0000 If there are folks who ignore the hop by hop options field then it makes th= e entire discussion about not supporting http://tools.ietf.org/html/draft-i= etf-6man-exthdr-01 moot. Given this, it makes all the more sense to either = proceed with this draft as it is or change it to define a standard format f= or all IPv6 extension headers that get defined in future (which is precisel= y what it did in its first version). Cheers, Manav=20 > -----Original Message----- > From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On=20 > Behalf Of Joel M. Halpern > Sent: Friday, February 04, 2011 8.41 AM > To: Christopher Morrow > Cc: ipv6@ietf.org > Subject: Re: Hop-by-Hop Extension Header processed in Slow Path? >=20 > Lets be a little careful here: > 1) If we say "No Extension Headers for intermediate=20 > processing", and "No=20 > Hop By Hop Options", then we are saying that we do not want any=20 > extensions intended to be processed in intermediate routers. While I=20 > personally like that, I want to make really sure that we=20 > understand that=20 > is what we are saying. >=20 > 2) I have been told that many large rotuers have a setting=20 > that causes=20 > them to ignore the hop by hop options field. To the degree=20 > that is both=20 > true and turned on, then we need to allow for that in our think (both=20 > positive and negative.) >=20 > Yours, > Joel >=20 > On 2/3/2011 9:57 PM, Christopher Morrow wrote: > > On Thu, Feb 3, 2011 at 8:09 PM, Hing-Kam (Kam)=20 > Lam wrote: > >> The below white paper from Cisco asserts that most vendors=20 > including > >> Cisco process Hop-by-Hop extension headers in CPU (slow=20 > path). Is this > >> correct? > >> > >>=20 > http://www.cisco.com/en/US/technologies/tk648/tk872/technologi > es_white_paper0900aecd8054d37d.html > >> > >> If Yes, then we should not add support for more sub=20 > options with HBH header. > > > > yes, see notes from me (in particular) about this from the last 2+ > > years... no more HBH header options pls... OR understand that these > > may/will get dropped (probably the whole packet actually) at some > > provider edges. > > -------------------------------------------------------------------- > > 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 > -------------------------------------------------------------------- > = From vishwas.ietf@gmail.com Thu Feb 3 21:20:20 2011 Return-Path: X-Original-To: ipv6@core3.amsl.com Delivered-To: ipv6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 799533A6AAF for ; Thu, 3 Feb 2011 21:20:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.454 X-Spam-Level: X-Spam-Status: No, score=-3.454 tagged_above=-999 required=5 tests=[AWL=0.145, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6JcixRp+LK7D for ; Thu, 3 Feb 2011 21:20:19 -0800 (PST) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by core3.amsl.com (Postfix) with ESMTP id F36023A6853 for ; Thu, 3 Feb 2011 21:20:18 -0800 (PST) Received: by wwa36 with SMTP id 36so2087328wwa.13 for ; Thu, 03 Feb 2011 21:23:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=Au/G1elIQ8VtBswKHlO9tforpjNt9pF7pnmLGZ++FJg=; b=ThK8dA4Q7EW6EImfzOh3WaHeh2NA0zRi43pO6MEiWR3uEcwmZa9gEDRjS/8DilSNjx /pajs8PsL9KYwJphe0C5bAj6AqJX/SdBuAvWH7wo3N07YXEbwTarET0NEpPC2znTau97 n4QiDaTYI0ADIxtdN9YmgvRtfbdlJfjtbthQY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=fBbEXz8XTNyiP07Yiiennn3l9qckxe5VBEuPdUODdghv5vaIas/6ttC/3tfKfL38+a iYRAVozpowrRyFeDGXViLE2R/qM+ahi6R/v6Ihqev+dcSyUEqxlPMU3gWAh4cUPjdXfj pYfhM5laLEsNBOSF0B/gslWRYWqTEixw5yCn0= MIME-Version: 1.0 Received: by 10.216.71.209 with SMTP id r59mr295104wed.15.1296797022516; Thu, 03 Feb 2011 21:23:42 -0800 (PST) Received: by 10.216.151.100 with HTTP; Thu, 3 Feb 2011 21:23:42 -0800 (PST) In-Reply-To: <4D4B6E54.9000703@joelhalpern.com> References: <4D4B6E54.9000703@joelhalpern.com> Date: Thu, 3 Feb 2011 21:23:42 -0800 Message-ID: Subject: Re: Hop-by-Hop Extension Header processed in Slow Path? From: Vishwas Manral To: "Joel M. Halpern" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org 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: , X-List-Received-Date: Fri, 04 Feb 2011 05:20:20 -0000 Hi Joel, Options are really bad for fast path processing. To find an option, the entire list of TLV's needs to be parsed, which is really hard especially when you have a limited number of clock cycles. For end-to-end processing however options can be considered better (especially if the traffic is CPU bound and not BFD or some other application). Though there are issues even there. Assume a case where we need to prioritize OSPFv3 packets to the CPU, we need to put multiple such filters for the same, as the OSPFv3 header can come after a bunch of IPv6 headers. Thanks, Vishwas On Thu, Feb 3, 2011 at 7:11 PM, Joel M. Halpern wrote= : > Lets be a little careful here: > 1) If we say "No Extension Headers for intermediate processing", and "No = Hop > By Hop Options", then we are saying that we do not want any extensions > intended to be processed in intermediate routers. =A0While I personally l= ike > that, I want to make really sure that we understand that is what we are > saying. > > 2) I have been told that many large rotuers have a setting that causes th= em > to ignore the hop by hop options field. =A0To the degree that is both tru= e and > turned on, then we need to allow for that in our think (both positive and > negative.) > > Yours, > Joel > > On 2/3/2011 9:57 PM, Christopher Morrow wrote: >> >> On Thu, Feb 3, 2011 at 8:09 PM, Hing-Kam (Kam) Lam >> =A0wrote: >>> >>> The below white paper from Cisco asserts that most vendors including >>> Cisco process Hop-by-Hop extension headers in CPU (slow path). Is this >>> correct? >>> >>> >>> http://www.cisco.com/en/US/technologies/tk648/tk872/technologies_white_= paper0900aecd8054d37d.html >>> >>> If Yes, then we should not add support for more sub options with HBH >>> header. >> >> yes, see notes from me (in particular) about this from the last 2+ >> years... no more HBH header options pls... OR understand that these >> may/will get dropped (probably the whole packet actually) at some >> provider edges. >> -------------------------------------------------------------------- >> 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 > -------------------------------------------------------------------- > From shane@castlepoint.net Thu Feb 3 21:28:33 2011 Return-Path: X-Original-To: ipv6@core3.amsl.com Delivered-To: ipv6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2A4063A69CA for ; Thu, 3 Feb 2011 21:28:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UhN3M57EHRDL for ; Thu, 3 Feb 2011 21:28:31 -0800 (PST) Received: from dog.tcb.net (dog.tcb.net [64.78.150.133]) by core3.amsl.com (Postfix) with ESMTP id B62F93A67A2 for ; Thu, 3 Feb 2011 21:28:31 -0800 (PST) Received: by dog.tcb.net (Postfix, from userid 0) id 42F92268679; Thu, 3 Feb 2011 22:31:55 -0700 (MST) Received: from mbpw.castlepoint.net (65-101-254-35.hlrn.qwest.net [65.101.254.35]) (authenticated-user smtp) (TLSv1/SSLv3 AES128-SHA 128/128) by dog.tcb.net with SMTP; Thu, 03 Feb 2011 22:31:55 -0700 (MST) (envelope-from shane@castlepoint.net) X-Avenger: version=0.7.8; receiver=dog.tcb.net; client-ip=65.101.254.35; client-port=53275; syn-fingerprint=65535:56:1:64:M1452,N,W3,N,N,T,S; data-bytes=0 Subject: Re: Hop-by-Hop Extension Header processed in Slow Path? Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Shane Amante In-Reply-To: Date: Thu, 3 Feb 2011 22:31:38 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4D4B6E54.9000703@joelhalpern.com> To: Christopher Morrow X-Mailer: Apple Mail (2.1082) Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org 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: , X-List-Received-Date: Fri, 04 Feb 2011 05:28:33 -0000 Chris, I think we may want to be a little careful here. At a minimum, maybe = take a deep breath and think about this some, before making a final = decision. :-) See below. On Feb 3, 2011, at 20:17 MST, Christopher Morrow wrote: > On Thu, Feb 3, 2011 at 10:11 PM, Joel M. Halpern = wrote: >> Lets be a little careful here: >> 1) If we say "No Extension Headers for intermediate processing", and = "No Hop >> By Hop Options", then we are saying that we do not want any = extensions >> intended to be processed in intermediate routers. While I personally = like >> that, I want to make really sure that we understand that is what we = are >> saying. >=20 > My feeling is this: > hop-by-hop processing will happen in slow-path (if you permit it to > happen at all), you can't build a router today with an asic that'll > know how to handle options which are created in the future :( Agreed. > This means that the gear in the network is subject to failure at > relatively low packet rates (as compared to interface rates), it also > means that the failure is likely not just at the interface level (the > RP/RE/PRP/etc will be doing this processing), much of this box will > fail. >=20 > This is an unacceptable outcome. I agree that's an unacceptable outcome; however, we have come up with = solutions for this in the past. Namely, implement 'proper' = rate-limiting at the linecards, in order to prevent overwhelming the = RE/RP/PRP, etc. (think: ICMP rate-limiting). Of course, the key = constraint this would place on any "applications" that attempt to use = HbH options would be that it couldn't carry any user data traffic at any = meaningful bit-rate as it WILL, most definitely, get dropped. OTOH, if = we're talking about periodic/sporadic OAM protocols that are only used = on a best-effort basis, (probably by operators, not end-users), then = this "limitation" may be acceptable. >> 2) I have been told that many large rotuers have a setting that = causes them >> to ignore the hop by hop options field. To the degree that is both = true and >> turned on, then we need to allow for that in our think (both positive = and >> negative.) >=20 > I've mostly seen the 'throw the packet away' option... I agree that if > I can ignore these in all of my routers I don't care what you do with > them before you see my router or after I pass this off to my friendly > neighbor router. This means that if you expect all intermediate > networks to do "something" for you with this option, you will not get > it, your application and other things should never rely upon this > being functional. That's certainly another approach. > if we get to that then... why are we making these exist anyways? Actually, that latter part is probably the best question. It would = probably be a useful thought exercise to revisit why they were = originally created (anybody got pointers to source material?), whether = those applications still hold water in today's world and/or if there are = new, _practical_ (i.e.: could really get deployed) uses for them. Of course, there's always the argument that folks may want to use HbH = headers in a private network (Enterprise network?) context, but "good = luck" on getting them to be recognized or acted upon (at all) by SP = routers. However, it seems like too much work to document even that in = a BCP as the boilerplate would likely overwhelm the actual content of = said draft/RFC. (Or, at least I'm not volunteering to do so :) -shane > -chris > (I agree that being clear here is a good plan) >=20 >>=20 >> Yours, >> Joel >>=20 >> On 2/3/2011 9:57 PM, Christopher Morrow wrote: >>>=20 >>> On Thu, Feb 3, 2011 at 8:09 PM, Hing-Kam (Kam) = Lam >>> wrote: >>>>=20 >>>> The below white paper from Cisco asserts that most vendors = including >>>> Cisco process Hop-by-Hop extension headers in CPU (slow path). Is = this >>>> correct? >>>>=20 >>>>=20 >>>> = http://www.cisco.com/en/US/technologies/tk648/tk872/technologies_white_pap= er0900aecd8054d37d.html >>>>=20 >>>> If Yes, then we should not add support for more sub options with = HBH >>>> header. >>>=20 >>> yes, see notes from me (in particular) about this from the last 2+ >>> years... no more HBH header options pls... OR understand that these >>> may/will get dropped (probably the whole packet actually) at some >>> provider edges. >>> -------------------------------------------------------------------- >>> IETF IPv6 working group mailing list >>> ipv6@ietf.org >>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >>> -------------------------------------------------------------------- >>>=20 >>=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From fernando.gont.netbook.win@gmail.com Thu Feb 3 21:35:38 2011 Return-Path: X-Original-To: ipv6@core3.amsl.com Delivered-To: ipv6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 91A3C3A67D4 for ; Thu, 3 Feb 2011 21:35:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ILqdiN-NkTWY for ; Thu, 3 Feb 2011 21:35:34 -0800 (PST) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by core3.amsl.com (Postfix) with ESMTP id 1A7573A67A2 for ; Thu, 3 Feb 2011 21:35:34 -0800 (PST) Received: by gxk27 with SMTP id 27so889496gxk.31 for ; Thu, 03 Feb 2011 21:38:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:sender:message-id:date:from:user-agent :mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:openpgp:content-type:content-transfer-encoding; bh=nCKu9xvvpdNspMQmMcSagM5tvp7L/vMbNYAhP4Ew/Lc=; b=xOSt3a3hb59OiRi3v1cnKzWoQnVbXJMrKAhQsN3y+GjF0Jxwemcb8llhHdJ3QD/Z2M OkpPQSlAWFP1b+jkWYiFluxRBLqQCtIqeHwm2tvGVePw23hO+gspvpY1WaSTNG5fyJzo wwoH36tdQ4B9lNdVfSxMlNlaJu1yv86Xjohl8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:openpgp:content-type :content-transfer-encoding; b=qGY9Tz05QwnMLQ11hWO3JquXLJgoHByXDbt/dNt7LBFb1fp6wigXXzW9wnvQKaCqXz pfYOoCKZbC+zG5qHWtk1fZJz1MI9e5fE0jWW7rfR/mR5hdyljRDL10maHpfi/kmHrplk pXibm+p+sHAe7Gav75uIFlp54fWeiaJD4Za6s= Received: by 10.150.212.8 with SMTP id k8mr14312039ybg.60.1296797069276; Thu, 03 Feb 2011 21:24:29 -0800 (PST) Received: from [192.168.2.3] ([190.246.229.147]) by mx.google.com with ESMTPS id p32sm843668ybk.20.2011.02.03.21.24.21 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 03 Feb 2011 21:24:27 -0800 (PST) Sender: Fernando Gont Message-ID: <4D4B8D73.4090000@gont.com.ar> Date: Fri, 04 Feb 2011 02:24:03 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2 MIME-Version: 1.0 To: "Bhatia, Manav (Manav)" Subject: Re: Hop-by-Hop Extension Header processed in Slow Path? References: <4D4B6E54.9000703@joelhalpern.com> <7C362EEF9C7896468B36C9B79200D8350CFB23E849@INBANSXCHMBSA1.in.alcatel-lucent.com> In-Reply-To: <7C362EEF9C7896468B36C9B79200D8350CFB23E849@INBANSXCHMBSA1.in.alcatel-lucent.com> X-Enigmail-Version: 1.1.1 OpenPGP: id=D076FFF1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "ipv6@ietf.org" X-BeenThere: ipv6@ietf.org 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: , X-List-Received-Date: Fri, 04 Feb 2011 05:35:38 -0000 Manav, On 04/02/2011 01:05 a.m., Bhatia, Manav (Manav) wrote: > If there are folks who ignore the hop by hop options field then it > makes the entire discussion about not supporting > http://tools.ietf.org/html/draft-ietf-6man-exthdr-01 moot. Given > this, it makes all the more sense to either proceed with this draft > as it is or change it to define a standard format for all IPv6 > extension headers that get defined in future (which is precisely what > it did in its first version). Huh? I don't follow. Could you please explain how the current discussion on Hop-by-Hop extensions relate to the aforementioned I-D? Thanks, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 From christopher.morrow@gmail.com Thu Feb 3 21:58:15 2011 Return-Path: X-Original-To: ipv6@core3.amsl.com Delivered-To: ipv6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7F4243A6867 for ; Thu, 3 Feb 2011 21:58:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dd1HL7Q53AYW for ; Thu, 3 Feb 2011 21:58:13 -0800 (PST) Received: from mail-ew0-f44.google.com (mail-ew0-f44.google.com [209.85.215.44]) by core3.amsl.com (Postfix) with ESMTP id 636B33A6778 for ; Thu, 3 Feb 2011 21:58:13 -0800 (PST) Received: by ewy8 with SMTP id 8so1190743ewy.31 for ; Thu, 03 Feb 2011 22:01:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=PGRClM4z4trAIiqGWwWetiPfrS+zkBnl6qh3iwEW2xA=; b=vTHMVMJc8qSTE65A1QfAVpRM/jNOcnPTPyNPrKBrqUI+nUTB2/2weCzkiwrAgLDnTy C/kD5mvCyNbku4DaF57vYM3l/PdpBkH8iJfw4f3mlZW0o546k91MFOdZh8nCEESUfcA0 84n+eFgIcEGvo2KDZs/SrzPJVENaVJHdCGH+k= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=cOAJ153IUpD+/NjJcSXqzVB3wBOLQowJXqINeh8R7jotHl4KF7Bx41hGemoCEAxi7A fbLbeLFbXWmCvDGGDY6rklHR5hRXkvOXXP3WnetbBOxhudGDKkmDW3KyGG20MXxjffzS qlihpkphWAwejzaxo5qkzWxkeHQ96IdTiFMRQ= MIME-Version: 1.0 Received: by 10.213.35.3 with SMTP id n3mr4748592ebd.36.1296799296885; Thu, 03 Feb 2011 22:01:36 -0800 (PST) Received: by 10.213.113.6 with HTTP; Thu, 3 Feb 2011 22:01:36 -0800 (PST) In-Reply-To: References: <4D4B6E54.9000703@joelhalpern.com> Date: Fri, 4 Feb 2011 01:01:36 -0500 Message-ID: Subject: Re: Hop-by-Hop Extension Header processed in Slow Path? From: Christopher Morrow To: Shane Amante Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org 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: , X-List-Received-Date: Fri, 04 Feb 2011 05:58:15 -0000 On Fri, Feb 4, 2011 at 12:31 AM, Shane Amante wrote= : > Chris, > > I think we may want to be a little careful here. =A0At a minimum, maybe t= ake a deep breath and think about this some, before making a final decision= . =A0:-) =A0See below. > I don't disagree with being careful. > On Feb 3, 2011, at 20:17 MST, Christopher Morrow wrote: >> On Thu, Feb 3, 2011 at 10:11 PM, Joel M. Halpern w= rote: >>> Lets be a little careful here: >>> 1) If we say "No Extension Headers for intermediate processing", and "N= o Hop >>> By Hop Options", then we are saying that we do not want any extensions >>> intended to be processed in intermediate routers. =A0While I personally= like >>> that, I want to make really sure that we understand that is what we are >>> saying. >> >> My feeling is this: >> hop-by-hop processing will happen in slow-path (if you permit it to >> happen at all), you can't build a router today with an asic that'll >> know how to handle options which are created in the future :( > > Agreed. > > >> This means that the gear in the network is subject to failure at >> relatively low packet rates (as compared to interface rates), it also >> means that the failure is likely not just at the interface level (the >> RP/RE/PRP/etc will be doing this processing), much of this box will >> fail. >> >> This is an unacceptable outcome. > > I agree that's an unacceptable outcome; however, we have come up with sol= utions for this in the past. =A0Namely, implement 'proper' rate-limiting at= the linecards, in order to prevent overwhelming the RE/RP/PRP, etc. (think= : ICMP rate-limiting). =A0Of course, the key constraint this would place on= any "applications" that attempt to use HbH options would be that it couldn= 't carry any user data traffic at any meaningful bit-rate as it WILL, most = definitely, get dropped. =A0OTOH, if we're talking about periodic/sporadic = OAM protocols that are only used on a best-effort basis, (probably by opera= tors, not end-users), then this "limitation" may be acceptable. > You probably also want this to be rate-limited separately from your example ICMP rate-limit, correct? Do you want to lose functionality or features because hop-by-hop is over-running the limiter? ICMP limits (error limits) are often there, because generate of unreachables happens in hardware in many platforms, to protect OtherPeoplesNetworks not your device. Limits set against transit traffic (icmp echo/echo-reply rate-limits) generally require a filter on the interface (or interface level configuration), that too is sub-optimal. I could see a limiter for HBH, in a cisco example, at or before the linecard-CPU (from interface -> LC-CPU -> RP for the example here) that is built into the hardware and is different from what exists today for COPP. Again, this is something that will impact transit traffic, so how reliable is it going to be? how reliable is it expected to be? >>> 2) I have been told that many large rotuers have a setting that causes = them >>> to ignore the hop by hop options field. =A0To the degree that is both t= rue and >>> turned on, then we need to allow for that in our think (both positive a= nd >>> negative.) >> >> I've mostly seen the 'throw the packet away' option... I agree that if >> I can ignore these in all of my routers I don't care what =A0you do with >> them before you see my router or after I pass this off to my friendly >> neighbor router. This means that if you expect all intermediate >> networks to do "something" for you with this option, you will not get >> it, your application and other things should never rely upon this >> being functional. > > That's certainly another approach. > > >> if we get to that then... why are we making these exist anyways? > > Actually, that latter part is probably the best question. =A0It would pro= bably be a useful thought exercise to revisit why they were originally crea= ted (anybody got pointers to source material?), whether those applications = still hold water in today's world and/or if there are new, _practical_ (i.e= .: could really get deployed) uses for them. I'd also be interested in the purpose of these... > > Of course, there's always the argument that folks may want to use HbH hea= ders in a private network (Enterprise network?) context, but "good luck" on= getting them to be recognized or acted upon (at all) by SP routers. =A0How= ever, it seems like too much work to document even that in a BCP as the boi= lerplate would likely overwhelm the actual content of said draft/RFC. =A0(O= r, at least I'm not volunteering to do so :) > Yup, the 'but these are only supposed to be used in private networks' worked well for .. NetBios :( or many, many other protocols. Hoping that this 'bad thing' will only be used on the 'inside' has a horrible track record. -chris > -shane > > > >> -chris >> (I agree that being clear here is a good plan) >> >>> >>> Yours, >>> Joel >>> >>> On 2/3/2011 9:57 PM, Christopher Morrow wrote: >>>> >>>> On Thu, Feb 3, 2011 at 8:09 PM, Hing-Kam (Kam) Lam >>>> =A0wrote: >>>>> >>>>> The below white paper from Cisco asserts that most vendors including >>>>> Cisco process Hop-by-Hop extension headers in CPU (slow path). Is thi= s >>>>> correct? >>>>> >>>>> >>>>> http://www.cisco.com/en/US/technologies/tk648/tk872/technologies_whit= e_paper0900aecd8054d37d.html >>>>> >>>>> If Yes, then we should not add support for more sub options with HBH >>>>> header. >>>> >>>> yes, see notes from me (in particular) about this from the last 2+ >>>> years... no more HBH header options pls... OR understand that these >>>> may/will get dropped (probably the whole packet actually) at some >>>> provider edges. >>>> -------------------------------------------------------------------- >>>> 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 >> -------------------------------------------------------------------- > > From manav.bhatia@alcatel-lucent.com Thu Feb 3 22:50:47 2011 Return-Path: X-Original-To: ipv6@core3.amsl.com Delivered-To: ipv6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C13D23A6B2A for ; Thu, 3 Feb 2011 22:50:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.342 X-Spam-Level: X-Spam-Status: No, score=-6.342 tagged_above=-999 required=5 tests=[AWL=0.257, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G+UFhszR2QAH for ; Thu, 3 Feb 2011 22:50:45 -0800 (PST) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by core3.amsl.com (Postfix) with ESMTP id 46A1C3A6884 for ; Thu, 3 Feb 2011 22:50:44 -0800 (PST) Received: from inbansmailrelay1.in.alcatel-lucent.com (h135-250-11-31.lucent.com [135.250.11.31]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id p146rxpx011084 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 4 Feb 2011 00:54:02 -0600 (CST) Received: from INBANSXCHHUB03.in.alcatel-lucent.com (inbansxchhub03.in.alcatel-lucent.com [135.250.12.80]) by inbansmailrelay1.in.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p146rv4Y014952 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 4 Feb 2011 12:23:58 +0530 Received: from INBANSXCHMBSA1.in.alcatel-lucent.com ([135.250.12.56]) by INBANSXCHHUB03.in.alcatel-lucent.com ([135.250.12.80]) with mapi; Fri, 4 Feb 2011 12:23:57 +0530 From: "Bhatia, Manav (Manav)" To: Fernando Gont Date: Fri, 4 Feb 2011 12:23:56 +0530 Subject: RE: Hop-by-Hop Extension Header processed in Slow Path? Thread-Topic: Hop-by-Hop Extension Header processed in Slow Path? Thread-Index: AcvELeV314zHuDkNQzWN8cTSmBlu5wACLydQ Message-ID: <7C362EEF9C7896468B36C9B79200D8350CFB23E904@INBANSXCHMBSA1.in.alcatel-lucent.com> References: <4D4B6E54.9000703@joelhalpern.com> <7C362EEF9C7896468B36C9B79200D8350CFB23E849@INBANSXCHMBSA1.in.alcatel-lucent.com> <4D4B8D73.4090000@gont.com.ar> In-Reply-To: <4D4B8D73.4090000@gont.com.ar> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 X-Scanned-By: MIMEDefang 2.64 on 135.250.11.31 Cc: "ipv6@ietf.org" X-BeenThere: ipv6@ietf.org 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: , X-List-Received-Date: Fri, 04 Feb 2011 06:50:47 -0000 Fernando, One of the major reasons given for not accepting this was that no new exten= sion headers need to be *ever* defined in future because you MUST either us= e hop-by-hop ext header or the destination options ext header. Cheers, Manav > -----Original Message----- > From: Fernando Gont=20 > [mailto:fernando.gont.netbook.win@gmail.com] On Behalf Of=20 > Fernando Gont > Sent: Friday, February 04, 2011 10.54 AM > To: Bhatia, Manav (Manav) > Cc: Joel M. Halpern; Christopher Morrow; ipv6@ietf.org > Subject: Re: Hop-by-Hop Extension Header processed in Slow Path? >=20 > Manav, >=20 > On 04/02/2011 01:05 a.m., Bhatia, Manav (Manav) wrote: > > If there are folks who ignore the hop by hop options field then it > > makes the entire discussion about not supporting > > http://tools.ietf.org/html/draft-ietf-6man-exthdr-01 moot. Given > > this, it makes all the more sense to either proceed with this draft > > as it is or change it to define a standard format for all IPv6 > > extension headers that get defined in future (which is=20 > precisely what > > it did in its first version). >=20 > Huh? I don't follow. >=20 > Could you please explain how the current discussion on Hop-by-Hop > extensions relate to the aforementioned I-D? >=20 > Thanks, > --=20 > Fernando Gont > e-mail: fernando@gont.com.ar || fgont@acm.org > PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 >=20 >=20 >=20 >=20 > = From fernando.gont.netbook.win@gmail.com Thu Feb 3 22:58:41 2011 Return-Path: X-Original-To: ipv6@core3.amsl.com Delivered-To: ipv6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4C4B03A6B62 for ; Thu, 3 Feb 2011 22:58:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.525 X-Spam-Level: X-Spam-Status: No, score=-3.525 tagged_above=-999 required=5 tests=[AWL=0.074, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZVO8kylOJJGE for ; Thu, 3 Feb 2011 22:58:36 -0800 (PST) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by core3.amsl.com (Postfix) with ESMTP id B768F3A6B63 for ; Thu, 3 Feb 2011 22:58:35 -0800 (PST) Received: by ywk9 with SMTP id 9so916285ywk.31 for ; Thu, 03 Feb 2011 23:01:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:sender:message-id:date:from:user-agent :mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:openpgp:content-type:content-transfer-encoding; bh=K7McBW/aK8BoFCrn/1QFhk0uqvVp7BAiG6m3RbKEiiw=; b=ttlrbRFIujFUf6tFzzlsiJVgxZLsZUqv62QbZENbeOJnVI+JxIpJoTjraOSyd0+CHe DKfH8G72o01u+e50v/XWN9GG20bIO1N66qSoHD6zyxffRV288DBw5/6Il9QTfC9WEODQ i0f0qWru8+O0KmYeta7MVrC+MzXg0ftE4XJhc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:openpgp:content-type :content-transfer-encoding; b=H4GyRvOav7HKPudHkqvlPF9xyjn9xo7I5d2GCIoGWy2+Uf5HFa4fcn2YqLmBTO5PDa 65n3se/q5+ktgb1ozojg64kq1Zd/2SFUIoyOAErweCPbR/K+RvY4M0GsALtzCMXMuJYt 49LJClHiOVhtZiNPeBXPy4XScw8flwLrcqOK4= Received: by 10.91.182.17 with SMTP id j17mr14882234agp.105.1296802919645; Thu, 03 Feb 2011 23:01:59 -0800 (PST) Received: from [192.168.0.134] (61-128-17-190.fibertel.com.ar [190.17.128.61]) by mx.google.com with ESMTPS id x31sm550437ana.9.2011.02.03.23.01.48 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 03 Feb 2011 23:01:57 -0800 (PST) Sender: Fernando Gont Message-ID: <4D4BA446.3070801@gont.com.ar> Date: Fri, 04 Feb 2011 04:01:26 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2 MIME-Version: 1.0 To: "Joel M. Halpern" Subject: Re: Hop-by-Hop Extension Header processed in Slow Path? References: <4D4B6E54.9000703@joelhalpern.com> In-Reply-To: <4D4B6E54.9000703@joelhalpern.com> X-Enigmail-Version: 1.1.1 OpenPGP: id=D076FFF1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org 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: , X-List-Received-Date: Fri, 04 Feb 2011 06:58:42 -0000 Hi, Joel, On 04/02/2011 12:11 a.m., Joel M. Halpern wrote: > Lets be a little careful here: > 1) If we say "No Extension Headers for intermediate processing", and "No > Hop By Hop Options", then we are saying that we do not want any > extensions intended to be processed in intermediate routers. While I > personally like that, I want to make really sure that we understand that > is what we are saying. This is the case with v4 already, and there's no reason to expect the v6-equivalent case to be any different. > 2) I have been told that many large rotuers have a setting that causes > them to ignore the hop by hop options field. Yes. Some event drop packets with options in v4. So, again, there's no reason to expect the v6 equivalent to be any different. Thanks, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 From fernando.gont.netbook.win@gmail.com Thu Feb 3 23:05:48 2011 Return-Path: X-Original-To: ipv6@core3.amsl.com Delivered-To: ipv6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7279E3A6B39 for ; Thu, 3 Feb 2011 23:05:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.527 X-Spam-Level: X-Spam-Status: No, score=-3.527 tagged_above=-999 required=5 tests=[AWL=0.072, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PpvYR0xexXQS for ; Thu, 3 Feb 2011 23:05:47 -0800 (PST) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by core3.amsl.com (Postfix) with ESMTP id EB8AF3A6B1F for ; Thu, 3 Feb 2011 23:05:46 -0800 (PST) Received: by gyd12 with SMTP id 12so912288gyd.31 for ; Thu, 03 Feb 2011 23:09:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:sender:message-id:date:from:user-agent :mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:openpgp:content-type:content-transfer-encoding; bh=cDrLEgzevqqa0R7a/FnLDc5B0hKikIAGvI38g4T9akg=; b=Erh/V4VkmqymeePNZsQ+ktM0XjJHbh4URxR7oPw0awkhJkZHbpKLNgy9jz1qe5MevN Kbd5G4HmnHzSl0TpKQTd4t0xFCMllzMZtkGv4qLU9K6qJpV7z8uRlAZRZ5MVYFtNlhvL qU/EAHe+sC8bqqLZFl8/tI1De2AzByc5j/LVE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:openpgp:content-type :content-transfer-encoding; b=Ws028urGyOe9nAh+rqduPQ8l17VR0+IyLW/szZ85x1iklG/dOPrykYZ1YfIWG+f9jF GkxsytLDKdeY/WUAEzkTwM3+bBQ31wvGE0I/jR0tfkbPidEHZNJCr/fUfN1pG2yKAhza p9HmrNfZB8+OwYXTacoXz1vuI79uuQTj3uX0Q= Received: by 10.90.75.18 with SMTP id x18mr15162017aga.5.1296803350774; Thu, 03 Feb 2011 23:09:10 -0800 (PST) Received: from [192.168.0.134] (61-128-17-190.fibertel.com.ar [190.17.128.61]) by mx.google.com with ESMTPS id e24sm559518ana.2.2011.02.03.23.08.57 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 03 Feb 2011 23:09:09 -0800 (PST) Sender: Fernando Gont Message-ID: <4D4BA5FC.2050207@gont.com.ar> Date: Fri, 04 Feb 2011 04:08:44 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2 MIME-Version: 1.0 To: "Bhatia, Manav (Manav)" Subject: Re: Hop-by-Hop Extension Header processed in Slow Path? References: <4D4B6E54.9000703@joelhalpern.com> <7C362EEF9C7896468B36C9B79200D8350CFB23E849@INBANSXCHMBSA1.in.alcatel-lucent.com> <4D4B8D73.4090000@gont.com.ar> <7C362EEF9C7896468B36C9B79200D8350CFB23E904@INBANSXCHMBSA1.in.alcatel-lucent.com> In-Reply-To: <7C362EEF9C7896468B36C9B79200D8350CFB23E904@INBANSXCHMBSA1.in.alcatel-lucent.com> X-Enigmail-Version: 1.1.1 OpenPGP: id=D076FFF1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "ipv6@ietf.org" X-BeenThere: ipv6@ietf.org 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: , X-List-Received-Date: Fri, 04 Feb 2011 07:05:48 -0000 Manav, On 04/02/2011 03:53 a.m., Bhatia, Manav (Manav) wrote: > One of the major reasons given for not accepting this was that no new > extension headers need to be *ever* defined in future because you > MUST either use hop-by-hop ext header or the destination options ext > header. What type of options are you envisioning that would not fit in any of the existing extension headers? -- That was the main argument against the publication of the aforementioned I-D. Thanks, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 From manav.bhatia@alcatel-lucent.com Thu Feb 3 23:20:50 2011 Return-Path: X-Original-To: ipv6@core3.amsl.com Delivered-To: ipv6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 04E9A3A68DF for ; Thu, 3 Feb 2011 23:20:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.345 X-Spam-Level: X-Spam-Status: No, score=-6.345 tagged_above=-999 required=5 tests=[AWL=0.254, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tr5xuiF6yvOC for ; Thu, 3 Feb 2011 23:20:49 -0800 (PST) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by core3.amsl.com (Postfix) with ESMTP id 0AAC03A677C for ; Thu, 3 Feb 2011 23:20:45 -0800 (PST) Received: from inbansmailrelay2.in.alcatel-lucent.com (h135-250-11-33.lucent.com [135.250.11.33]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id p147O21d015216 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 4 Feb 2011 01:24:05 -0600 (CST) Received: from INBANSXCHHUB02.in.alcatel-lucent.com (inbansxchhub02.in.alcatel-lucent.com [135.250.12.35]) by inbansmailrelay2.in.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p147O04r026840 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 4 Feb 2011 12:54:01 +0530 Received: from INBANSXCHMBSA1.in.alcatel-lucent.com ([135.250.12.56]) by INBANSXCHHUB02.in.alcatel-lucent.com ([135.250.12.35]) with mapi; Fri, 4 Feb 2011 12:54:00 +0530 From: "Bhatia, Manav (Manav)" To: Fernando Gont Date: Fri, 4 Feb 2011 12:53:59 +0530 Subject: RE: Hop-by-Hop Extension Header processed in Slow Path? Thread-Topic: Hop-by-Hop Extension Header processed in Slow Path? Thread-Index: AcvEOnOURby2xycCSCCGNDeXYfI/MQAAcxoA Message-ID: <7C362EEF9C7896468B36C9B79200D8350CFB23E92A@INBANSXCHMBSA1.in.alcatel-lucent.com> References: <4D4B6E54.9000703@joelhalpern.com> <7C362EEF9C7896468B36C9B79200D8350CFB23E849@INBANSXCHMBSA1.in.alcatel-lucent.com> <4D4B8D73.4090000@gont.com.ar> <7C362EEF9C7896468B36C9B79200D8350CFB23E904@INBANSXCHMBSA1.in.alcatel-lucent.com> <4D4BA5FC.2050207@gont.com.ar> In-Reply-To: <4D4BA5FC.2050207@gont.com.ar> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 X-Scanned-By: MIMEDefang 2.64 on 135.250.11.33 Cc: "ipv6@ietf.org" X-BeenThere: ipv6@ietf.org 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: , X-List-Received-Date: Fri, 04 Feb 2011 07:20:50 -0000 Fernando, If you deprecate HbH then if you need an extension that requires such a beh= avior then you would need a new header. Routers that don't implement that w= ill skip over it, while the ones that understand that will process it. This= is different from bundling everything inside HbH where all routers will ha= ve to process this packet in slow path. Cheers, Manav=20 > -----Original Message----- > From: Fernando Gont=20 > [mailto:fernando.gont.netbook.win@gmail.com] On Behalf Of=20 > Fernando Gont > Sent: Friday, February 04, 2011 12.39 PM > To: Bhatia, Manav (Manav) > Cc: Joel M. Halpern; Christopher Morrow; ipv6@ietf.org > Subject: Re: Hop-by-Hop Extension Header processed in Slow Path? >=20 > Manav, >=20 > On 04/02/2011 03:53 a.m., Bhatia, Manav (Manav) wrote: > > One of the major reasons given for not accepting this was=20 > that no new > > extension headers need to be *ever* defined in future because you > > MUST either use hop-by-hop ext header or the destination options ext > > header. >=20 > What type of options are you envisioning that would not fit in any of > the existing extension headers? -- That was the main argument against > the publication of the aforementioned I-D. >=20 > Thanks, > --=20 > Fernando Gont > e-mail: fernando@gont.com.ar || fgont@acm.org > PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 >=20 >=20 >=20 >=20 > = From roland.bless@kit.edu Fri Feb 4 04:18:06 2011 Return-Path: X-Original-To: ipv6@core3.amsl.com Delivered-To: ipv6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ABDF23A68F5 for ; Fri, 4 Feb 2011 04:18:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.173 X-Spam-Level: X-Spam-Status: No, score=-6.173 tagged_above=-999 required=5 tests=[AWL=0.076, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4QLJnuM2Wk39 for ; Fri, 4 Feb 2011 04:18:06 -0800 (PST) Received: from iramx2.ira.uni-karlsruhe.de (iramx2.ira.uni-karlsruhe.de [141.3.10.81]) by core3.amsl.com (Postfix) with ESMTP id A7AED3A6907 for ; Fri, 4 Feb 2011 04:18:04 -0800 (PST) Received: from irams1.ira.uni-karlsruhe.de ([141.3.10.5]) by iramx2.ira.uni-karlsruhe.de with esmtps port 25 id 1PlKfC-0002dm-PU for ; Fri, 04 Feb 2011 13:21:28 +0100 Received: from i72ms.tm.uni-karlsruhe.de ([141.3.70.5] helo=smtp.ipv6.tm.uni-karlsruhe.de) by irams1.ira.uni-karlsruhe.de with esmtps port 25 for id 1PlKfC-0002FG-Kc; Fri, 04 Feb 2011 13:21:22 +0100 Received: from vorta.tm.kit.edu (i72vorta.tm.uni-karlsruhe.de [IPv6:2001:638:204:6:21b:fcff:fe96:fe02]) by smtp.ipv6.tm.uni-karlsruhe.de (Postfix) with ESMTP id 8D2B92FC024 for ; Fri, 4 Feb 2011 13:21:22 +0100 (CET) Received: from [IPv6:::1] (ip6-localhost [IPv6:::1]) by vorta.tm.kit.edu (Postfix) with ESMTPS id 6F1F612A0 for ; Fri, 4 Feb 2011 13:21:22 +0100 (CET) Message-ID: <4D4BEF42.5060106@kit.edu> Date: Fri, 04 Feb 2011 13:21:22 +0100 From: Roland Bless Organization: Institute of Telematics, Karlsruhe Institute of Technology User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.13) Gecko/20101208 Thunderbird/3.1.7 MIME-Version: 1.0 To: ipv6@ietf.org Subject: Re: Hop-by-Hop Extension Header processed in Slow Path? X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit X-ATIS-AV: ClamAV (irams1.ira.uni-karlsruhe.de) X-ATIS-AV: ClamAV (iramx2.ira.uni-karlsruhe.de) X-ATIS-AV: Kaspersky (iramx2.ira.uni-karlsruhe.de) X-ATIS-Timestamp: iramx2.ira.uni-karlsruhe.de 1296822088.673178000 X-BeenThere: ipv6@ietf.org 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: , X-List-Received-Date: Fri, 04 Feb 2011 12:18:06 -0000 Hi, Christopher Morrow wrote: > My feeling is this: > hop-by-hop processing will happen in slow-path (if you permit it to > happen at all), you can't build a router today with an asic that'll > know how to handle options which are created in the future :( while the latter is surely true, I don't think that this argument precludes to implement fast path processing of at least _some_ HbH options. I think that the current implemented strategy to simply pass all HbH options to the slow path CPU is broken. I'm not sure whether it is feasible, but couldn't the Fast Path (ASIC) at least check for: - known options to be processed in the fast path, e.g., some CONEX info field - known options to be processed in the control plane, i.e., punt packet to control path (slow path CPU), e.g., some to intercept packets with a specific router alert option - bypassing unknown options (depending on the specified actions) in the fast-path So some (not all) _basic_ header extension processing code should be down in the fast path (like forwarding of non-supported or "non-interesting" hop-by-hop options) while more complex processing can surely stay up in the slow path. I have the impression that we will sacrifice the possibility of future useful IPv6 extensions due to some existing implementation limitations. Regards, Roland From narten@us.ibm.com Fri Feb 4 05:32:17 2011 Return-Path: X-Original-To: ipv6@core3.amsl.com Delivered-To: ipv6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DECDA3A6956 for ; Fri, 4 Feb 2011 05:32:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.123 X-Spam-Level: X-Spam-Status: No, score=-106.123 tagged_above=-999 required=5 tests=[AWL=0.476, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GQvtAA6bOWRX for ; Fri, 4 Feb 2011 05:32:17 -0800 (PST) Received: from e35.co.us.ibm.com (e35.co.us.ibm.com [32.97.110.153]) by core3.amsl.com (Postfix) with ESMTP id 08CEA3A68F6 for ; Fri, 4 Feb 2011 05:32:16 -0800 (PST) Received: from d03relay05.boulder.ibm.com (d03relay05.boulder.ibm.com [9.17.195.107]) by e35.co.us.ibm.com (8.14.4/8.13.1) with ESMTP id p14DLWTS014878 for ; Fri, 4 Feb 2011 06:21:32 -0700 Received: from d03av06.boulder.ibm.com (d03av06.boulder.ibm.com [9.17.195.245]) by d03relay05.boulder.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id p14DZX58109328 for ; Fri, 4 Feb 2011 06:35:33 -0700 Received: from d03av06.boulder.ibm.com (loopback [127.0.0.1]) by d03av06.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id p14De9Zm009715 for ; Fri, 4 Feb 2011 06:40:09 -0700 Received: from cichlid.raleigh.ibm.com (sig-9-65-206-115.mts.ibm.com [9.65.206.115]) by d03av06.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id p14De7uK009632 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 4 Feb 2011 06:40:08 -0700 Received: from cichlid.raleigh.ibm.com (localhost.localdomain [127.0.0.1]) by cichlid.raleigh.ibm.com (8.14.4/8.12.5) with ESMTP id p14DZVUd017501 for ; Fri, 4 Feb 2011 08:35:31 -0500 Message-Id: <201102041335.p14DZVUd017501@cichlid.raleigh.ibm.com> To: ipv6@ietf.org Subject: Re: Hop-by-Hop Extension Header processed in Slow Path? In-reply-to: References: Comments: In-reply-to "Hing-Kam (Kam) Lam" message dated "Fri, 04 Feb 2011 06:39:51 +0530." Date: Fri, 04 Feb 2011 08:35:31 -0500 From: Thomas Narten X-BeenThere: ipv6@ietf.org 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: , X-List-Received-Date: Fri, 04 Feb 2011 13:32:18 -0000 Gawd, I love these sorts of discussions. Remind me. How many HBH options has the IETF approved in the last ten years? How many proposed HBH options are in the pipeline for approval? Could we please skip this silly discussion until such a time as someone actually proposes a HBH option that makes sense, and for which alternate approaches to solving the problem (that don't use HBH) are worse? And when we have such a compelling proposal, discuss the pros/cons of whether it can be deployed, whether routers will actually implement it, etc.? These entirely theoretical discussions are mostly a complete waste of time. And to be clear, I suspect we will not be approving any HBH options any time soon. We know they are generally a bad idea. It is unlikely that the reasons that HBH are a last resort approach will change anytime soon. But can we please just leave things alone as they are now? The possibility that a HBH may be defined in the future is not something that is causing us problems today and needs fixing. Thomas From jmh@joelhalpern.com Fri Feb 4 05:56:45 2011 Return-Path: X-Original-To: ipv6@core3.amsl.com Delivered-To: ipv6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DB53C3A6941 for ; Fri, 4 Feb 2011 05:56:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.595 X-Spam-Level: X-Spam-Status: No, score=-102.595 tagged_above=-999 required=5 tests=[AWL=0.004, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8OB-ematFOr6 for ; Fri, 4 Feb 2011 05:56:45 -0800 (PST) Received: from hermes.out.tigertech.net (hermes.out.tigertech.net [74.114.88.72]) by core3.amsl.com (Postfix) with ESMTP id 0FF2C3A6923 for ; Fri, 4 Feb 2011 05:56:45 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 68372430045; Fri, 4 Feb 2011 06:00:10 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at hermes.tigertech.net Received: from [10.10.10.102] (pool-71-161-50-121.clppva.btas.verizon.net [71.161.50.121]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by hermes.tigertech.net (Postfix) with ESMTPSA id A93D34300A2; Fri, 4 Feb 2011 06:00:09 -0800 (PST) Message-ID: <4D4C066A.5030707@joelhalpern.com> Date: Fri, 04 Feb 2011 09:00:10 -0500 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.13) Gecko/20101207 Lightning/1.0b2 Thunderbird/3.1.7 MIME-Version: 1.0 To: "Bhatia, Manav (Manav)" Subject: Re: Hop-by-Hop Extension Header processed in Slow Path? References: <4D4B6E54.9000703@joelhalpern.com> <7C362EEF9C7896468B36C9B79200D8350CFB23E849@INBANSXCHMBSA1.in.alcatel-lucent.com> <4D4B8D73.4090000@gont.com.ar> <7C362EEF9C7896468B36C9B79200D8350CFB23E904@INBANSXCHMBSA1.in.alcatel-lucent.com> <4D4BA5FC.2050207@gont.com.ar> <7C362EEF9C7896468B36C9B79200D8350CFB23E92A@INBANSXCHMBSA1.in.alcatel-lucent.com> In-Reply-To: <7C362EEF9C7896468B36C9B79200D8350CFB23E92A@INBANSXCHMBSA1.in.alcatel-lucent.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "ipv6@ietf.org" X-BeenThere: ipv6@ietf.org 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: , X-List-Received-Date: Fri, 04 Feb 2011 13:56:45 -0000 Your reasoning does not follow, Manav. Given what we know about packet processing, any extension that believes it will be processed by every router along the path is probably fooling itself. Therefore, documenting something that claims to provide that functionality is probably a mistake. At that point, we go to the question of whether, for those packets that want hop-by-hop processing by some routers distinct from the end point to which the packet is addressed, how should we do it. 1) Don't. 2) Extensions: Note that our underlying documents specifically say not to do that, for very good reasons. Even the new document on extension headers was only describing extension headers for end-to-end processing. 3) Use HbH anyway. There is hardware that can ignore it. There is hardware that can parse it. We coudl certainly couple that with discouraging all such use. My own preference is (1). We have found, repeatedly, that pretending we can direct packets to every router along a path is just not a good idea. Note that even our OAM fanatics (MPLS-TP) have given up on trying that trick. That of course would bring us back to discussing where extensions with end-to-end semantics should go. I am still unclear why the end-to-end options header is not sufficient for those cases. However, if the WG things it can not or should not ban end-to-end extension headers, then having a document giving them a more regular format still seems worth while to me. Yours, Joel On 2/4/2011 2:23 AM, Bhatia, Manav (Manav) wrote: > Fernando, > > If you deprecate HbH then if you need an extension that requires such a behavior then you would need a new header. Routers that don't implement that will skip over it, while the ones that understand that will process it. This is different from bundling everything inside HbH where all routers will have to process this packet in slow path. > > Cheers, Manav > >> -----Original Message----- >> From: Fernando Gont >> [mailto:fernando.gont.netbook.win@gmail.com] On Behalf Of >> Fernando Gont >> Sent: Friday, February 04, 2011 12.39 PM >> To: Bhatia, Manav (Manav) >> Cc: Joel M. Halpern; Christopher Morrow; ipv6@ietf.org >> Subject: Re: Hop-by-Hop Extension Header processed in Slow Path? >> >> Manav, >> >> On 04/02/2011 03:53 a.m., Bhatia, Manav (Manav) wrote: >>> One of the major reasons given for not accepting this was >> that no new >>> extension headers need to be *ever* defined in future because you >>> MUST either use hop-by-hop ext header or the destination options ext >>> header. >> >> What type of options are you envisioning that would not fit in any of >> the existing extension headers? -- That was the main argument against >> the publication of the aforementioned I-D. >> >> Thanks, >> -- >> Fernando Gont >> e-mail: fernando@gont.com.ar || fgont@acm.org >> PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 >> >> >> >> >> From narten@us.ibm.com Fri Feb 4 05:59:01 2011 Return-Path: X-Original-To: ipv6@core3.amsl.com Delivered-To: ipv6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 92BE33A6965 for ; Fri, 4 Feb 2011 05:59:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.15 X-Spam-Level: X-Spam-Status: No, score=-106.15 tagged_above=-999 required=5 tests=[AWL=0.449, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5L67VsmM3UVh for ; Fri, 4 Feb 2011 05:59:00 -0800 (PST) Received: from e2.ny.us.ibm.com (e2.ny.us.ibm.com [32.97.182.142]) by core3.amsl.com (Postfix) with ESMTP id 3DF123A6923 for ; Fri, 4 Feb 2011 05:58:59 -0800 (PST) Received: from d01dlp02.pok.ibm.com (d01dlp02.pok.ibm.com [9.56.224.85]) by e2.ny.us.ibm.com (8.14.4/8.13.1) with ESMTP id p14DiKUX015588 for ; Fri, 4 Feb 2011 08:44:37 -0500 Received: from d01relay05.pok.ibm.com (d01relay05.pok.ibm.com [9.56.227.237]) by d01dlp02.pok.ibm.com (Postfix) with ESMTP id 8A7584DE8041 for ; Fri, 4 Feb 2011 09:01:44 -0500 (EST) Received: from d01av03.pok.ibm.com (d01av03.pok.ibm.com [9.56.224.217]) by d01relay05.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id p14E2NVD167806 for ; Fri, 4 Feb 2011 09:02:23 -0500 Received: from d01av03.pok.ibm.com (loopback [127.0.0.1]) by d01av03.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id p14E2LRq028577 for ; Fri, 4 Feb 2011 12:02:22 -0200 Received: from cichlid.raleigh.ibm.com (sig-9-65-206-115.mts.ibm.com [9.65.206.115]) by d01av03.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id p14E2FH5027974 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 4 Feb 2011 12:02:16 -0200 Received: from cichlid.raleigh.ibm.com (localhost.localdomain [127.0.0.1]) by cichlid.raleigh.ibm.com (8.14.4/8.12.5) with ESMTP id p14E2Cdq017725; Fri, 4 Feb 2011 09:02:12 -0500 Message-Id: <201102041402.p14E2Cdq017725@cichlid.raleigh.ibm.com> To: Brian E Carpenter Subject: Re: RFC3697bis Open Issue 5 In-reply-to: <4D4B6C8A.2060306@gmail.com> References: <4D46315C.3050806@gmail.com> <05834D09-0E37-497D-B1E6-3F008E98AECB@nsn.com> <201102040136.p141apKn011527@cichlid.raleigh.ibm.com> <4D4B6C8A.2060306@gmail.com> Comments: In-reply-to Brian E Carpenter message dated "Fri, 04 Feb 2011 16:03:38 +1300." Date: Fri, 04 Feb 2011 09:02:12 -0500 From: Thomas Narten X-Content-Scanned: Fidelis XPS MAILER Cc: 6man X-BeenThere: ipv6@ietf.org 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: , X-List-Received-Date: Fri, 04 Feb 2011 13:59:01 -0000 Brian E Carpenter writes: > OK, something like > Although the flow label is defined as immutable once it has > been set to a non-zero value, implementers should be aware > that it is an unprotected field that could have been accidentally > or intentionally changed en route. Implementations MUST > take appropriate steps to protect themselves from being > vulnerable to denial of service and other types of attack that > could result. This sounds about right. To put this in perspective, routers can't assume the source or destination address in a packet has not been modified since leaving the originator. But that doesn't cause us all to Freak Out! :-) Thomas From christopher.morrow@gmail.com Fri Feb 4 07:20:19 2011 Return-Path: X-Original-To: ipv6@core3.amsl.com Delivered-To: ipv6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 681833A69B7 for ; Fri, 4 Feb 2011 07:20:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9chqBGEmbQiR for ; Fri, 4 Feb 2011 07:20:13 -0800 (PST) Received: from mail-ew0-f44.google.com (mail-ew0-f44.google.com [209.85.215.44]) by core3.amsl.com (Postfix) with ESMTP id F04533A6992 for ; Fri, 4 Feb 2011 07:20:12 -0800 (PST) Received: by ewy8 with SMTP id 8so1393733ewy.31 for ; Fri, 04 Feb 2011 07:23:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=ZbMtOeEPMZLD6n+ZBCqRInyn3Ysq1qvVgMaFw9v6PAQ=; b=mlsXf9cntcqxixoM+yl7FSX6IHBpWcl8LZMlUxLIdxRssD+xBm2t9PLDKl75p9Tn4F PNY7iRFIoftM+xoUgNMHnzIaipjbrbmhCAwci1k5XjG3uAu8G2U45W7DAHHjwndLT5m9 sPIeLVZ/lFIY9O0XMYe2ZTyz8ad74uXQ7mODY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=KgLaFe+Pn8XOSEx8MBYjHIDL0ctoh4oJKR9MB8QpZxCazhviQHiDiO1xKAPSd9W/Lt sZ+0vCZlDs/kZfms15R5tHsV8MIrm8D7D8PuZoo3245+iRuD1SmPW9vVN2YIrzoohODA CH0nNood2D6OOg8as/lyNoUcXTsF/UTS2ESEw= MIME-Version: 1.0 Received: by 10.213.29.210 with SMTP id r18mr2809823ebc.62.1296833012630; Fri, 04 Feb 2011 07:23:32 -0800 (PST) Received: by 10.213.113.6 with HTTP; Fri, 4 Feb 2011 07:23:32 -0800 (PST) In-Reply-To: <201102041335.p14DZVUd017501@cichlid.raleigh.ibm.com> References: <201102041335.p14DZVUd017501@cichlid.raleigh.ibm.com> Date: Fri, 4 Feb 2011 10:23:32 -0500 Message-ID: Subject: Re: Hop-by-Hop Extension Header processed in Slow Path? From: Christopher Morrow To: Thomas Narten Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org 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: , X-List-Received-Date: Fri, 04 Feb 2011 15:20:20 -0000 On Fri, Feb 4, 2011 at 8:35 AM, Thomas Narten wrote: > Gawd, I love these sorts of discussions. > > And to be clear, I suspect we will not be approving any HBH options > any time soon. We know they are generally a bad idea. It is unlikely > that the reasons that HBH are a last resort approach will change > anytime soon. =A0But can we please just leave things alone as they are > now? The possibility that a HBH may be defined in the future is not > something that is causing us problems today and needs fixing. fair enough, though having some documented (at least in email) reasoning that "Oh, a new HBH will be cool!" is bad, certainly isn't bad, right? From christopher.morrow@gmail.com Fri Feb 4 07:24:08 2011 Return-Path: X-Original-To: ipv6@core3.amsl.com Delivered-To: ipv6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5DE673A699C for ; Fri, 4 Feb 2011 07:24:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4hytEutbH1v1 for ; Fri, 4 Feb 2011 07:24:07 -0800 (PST) Received: from mail-ew0-f44.google.com (mail-ew0-f44.google.com [209.85.215.44]) by core3.amsl.com (Postfix) with ESMTP id 25E133A6997 for ; Fri, 4 Feb 2011 07:24:06 -0800 (PST) Received: by ewy8 with SMTP id 8so1396840ewy.31 for ; Fri, 04 Feb 2011 07:27:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=oibrDoDhNgdX38Vo9yT5kwJiJT/R1x+WnkRtYe1ViUg=; b=vZ4FbDOrgNjYcUtiucWvqVKJP/wT9xPEW7YuUmlfb2kmbaWCKIpgyuEH8M8NImb7U9 nflLqKHfQ1F1IG7vR0KzxUxJS9F8e41Pn1SDCt/6F9Qv7Sk5j/djViZ1MhWwswk6fWum jCYYwBjrQeS3Tbl0NxC8BC6WQEmptki57lMWQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=OddV9nUrv30/S+vsLHgFL31Q5lWwD8gfVEgrjw6f651ZzdNVpV92z2X9V7A/lUOnw7 +ALXBF5FPWfgl8d17kK9ZNzRbkffv0LomGxO8RhpLFjz4xhlu4ZrQXpJcTQL78jKnLJT 02uVhijEIEXNfLObSD8jEwtXtRZC18FJLA2yg= MIME-Version: 1.0 Received: by 10.213.29.210 with SMTP id r18mr2816320ebc.62.1296833251866; Fri, 04 Feb 2011 07:27:31 -0800 (PST) Received: by 10.213.113.6 with HTTP; Fri, 4 Feb 2011 07:27:31 -0800 (PST) In-Reply-To: <4D4BEF42.5060106@kit.edu> References: <4D4BEF42.5060106@kit.edu> Date: Fri, 4 Feb 2011 10:27:31 -0500 Message-ID: Subject: Re: Hop-by-Hop Extension Header processed in Slow Path? From: Christopher Morrow To: Roland Bless Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org 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: , X-List-Received-Date: Fri, 04 Feb 2011 15:24:08 -0000 On Fri, Feb 4, 2011 at 7:21 AM, Roland Bless wrote: > Hi, > > Christopher Morrow wrote: >> My feeling is this: >> hop-by-hop processing will happen in slow-path (if you permit it to >> happen at all), you can't build a router today with an asic that'll >> know how to handle options which are created in the future :( > > while the latter is surely true, I don't think that this > argument precludes to implement fast path processing > of at least _some_ HbH options. I think that the current > implemented strategy to simply pass all HbH options > to the slow path CPU is broken. > > I'm not sure whether it is feasible, but couldn't the > Fast Path (ASIC) at least check for: > - known options to be processed in the fast path, e.g., > =A0some CONEX info field which options? how often would you expect this list to update? routers live in the network for ~7 years or so, in large networks. ASIC updates mean very expensive (equipment, personnel, sla) changes are required. > - known options to be processed in the control plane, > =A0i.e., punt packet to control path (slow path CPU), > =A0e.g., some to intercept packets with a specific > =A0router alert option > - bypassing unknown options (depending on the specified > =A0actions) in the fast-path and hopefully with a consistent decision on which goes where here? I'd hate for (for example) Cisco to turn left while Juniper turns right... this also seems complex. Again, just providing a knob (and accepting that it will happen) that the HBH options may just be ignored in the public network may terminate this discussion completely. -chris From narten@us.ibm.com Fri Feb 4 07:26:27 2011 Return-Path: X-Original-To: ipv6@core3.amsl.com Delivered-To: ipv6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 278273A6BAE for ; Fri, 4 Feb 2011 07:26:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.162 X-Spam-Level: X-Spam-Status: No, score=-106.162 tagged_above=-999 required=5 tests=[AWL=0.437, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ReJPk9yFlH1N for ; Fri, 4 Feb 2011 07:26:26 -0800 (PST) Received: from e8.ny.us.ibm.com (e8.ny.us.ibm.com [32.97.182.138]) by core3.amsl.com (Postfix) with ESMTP id 4413A3A6BAD for ; Fri, 4 Feb 2011 07:26:26 -0800 (PST) Received: from d01dlp02.pok.ibm.com (d01dlp02.pok.ibm.com [9.56.224.85]) by e8.ny.us.ibm.com (8.14.4/8.13.1) with ESMTP id p14BBrjh001149 for ; Fri, 4 Feb 2011 06:11:53 -0500 Received: from d01relay07.pok.ibm.com (d01relay07.pok.ibm.com [9.56.227.147]) by d01dlp02.pok.ibm.com (Postfix) with ESMTP id 292C54DE803E for ; Fri, 4 Feb 2011 10:29:11 -0500 (EST) Received: from d01av01.pok.ibm.com (d01av01.pok.ibm.com [9.56.224.215]) by d01relay07.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id p14FTnWV2105428 for ; Fri, 4 Feb 2011 10:29:49 -0500 Received: from d01av01.pok.ibm.com (loopback [127.0.0.1]) by d01av01.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id p14FTmqY025596 for ; Fri, 4 Feb 2011 10:29:48 -0500 Received: from cichlid.raleigh.ibm.com (sig-9-65-206-115.mts.ibm.com [9.65.206.115]) by d01av01.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id p14FTki1025446 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 4 Feb 2011 10:29:47 -0500 Received: from cichlid.raleigh.ibm.com (localhost.localdomain [127.0.0.1]) by cichlid.raleigh.ibm.com (8.14.4/8.12.5) with ESMTP id p14FTjeh018595; Fri, 4 Feb 2011 10:29:46 -0500 Message-Id: <201102041529.p14FTjeh018595@cichlid.raleigh.ibm.com> To: Christopher Morrow Subject: Re: Hop-by-Hop Extension Header processed in Slow Path? In-reply-to: References: <201102041335.p14DZVUd017501@cichlid.raleigh.ibm.com> Comments: In-reply-to Christopher Morrow message dated "Fri, 04 Feb 2011 10:23:32 -0500." Date: Fri, 04 Feb 2011 10:29:45 -0500 From: Thomas Narten X-Content-Scanned: Fidelis XPS MAILER Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org 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: , X-List-Received-Date: Fri, 04 Feb 2011 15:26:27 -0000 > fair enough, though having some documented (at least in email) > reasoning that "Oh, a new HBH will be cool!" is bad, certainly isn't > bad, right? Well, it's been documented before in email, and I have little hope that documenting it again in email will be remembered six months from now. :) Perhaps we should take: The case against Hop-by-Hop options draft-krishnan-ipv6-hopbyhop-05 And turn it into (if it doesn't do this enough already) a list of all the reasons why HBH is problematical, and then suggest that anyone proposing a HBH in the future include a checklist of how the HBH approach is still compelling given all the issues listed in the doc. But I don't think we need a protocol statement banning HBH. The reasons they are problematical should speak for themselves. Thomas From suresh.krishnan@ericsson.com Fri Feb 4 08:14:22 2011 Return-Path: X-Original-To: ipv6@core3.amsl.com Delivered-To: ipv6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 07D593A69DE for ; Fri, 4 Feb 2011 08:14:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.546 X-Spam-Level: X-Spam-Status: No, score=-102.546 tagged_above=-999 required=5 tests=[AWL=0.053, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sFKBGbgnpSBU for ; Fri, 4 Feb 2011 08:14:21 -0800 (PST) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.8]) by core3.amsl.com (Postfix) with ESMTP id 04D6A3A69D4 for ; Fri, 4 Feb 2011 08:14:20 -0800 (PST) Received: from eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id p14H0WKF016897; Fri, 4 Feb 2011 11:00:33 -0600 Received: from [142.133.10.107] (147.117.20.213) by eusaamw0711.eamcs.ericsson.se (147.117.20.179) with Microsoft SMTP Server id 8.2.234.1; Fri, 4 Feb 2011 11:17:38 -0500 Message-ID: <4D4C266E.9000305@ericsson.com> Date: Fri, 4 Feb 2011 11:16:46 -0500 From: Suresh Krishnan User-Agent: Thunderbird 2.0.0.24 (X11/20101027) MIME-Version: 1.0 To: Thomas Narten Subject: Re: Hop-by-Hop Extension Header processed in Slow Path? References: <201102041335.p14DZVUd017501@cichlid.raleigh.ibm.com> <201102041529.p14FTjeh018595@cichlid.raleigh.ibm.com> In-Reply-To: <201102041529.p14FTjeh018595@cichlid.raleigh.ibm.com> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit Cc: "ipv6@ietf.org" X-BeenThere: ipv6@ietf.org 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: , X-List-Received-Date: Fri, 04 Feb 2011 16:14:22 -0000 Hi Thomas, On 11-02-04 10:29 AM, Thomas Narten wrote: >> fair enough, though having some documented (at least in email) >> reasoning that "Oh, a new HBH will be cool!" is bad, certainly isn't >> bad, right? > > Well, it's been documented before in email, and I have little hope > that documenting it again in email will be remembered six months from > now. :) > > Perhaps we should take: > > The case against Hop-by-Hop options > draft-krishnan-ipv6-hopbyhop-05 > > And turn it into (if it doesn't do this enough already) a list of all > the reasons why HBH is problematical, and then suggest that anyone > proposing a HBH in the future include a checklist of how the HBH > approach is still compelling given all the issues listed in the doc. I wrote this because of a frustrating implementation experience I had. I periodically republish this draft to serve as a reminder to people but I have not put any real effort into this for a few years. I would appreciate any help you and Chris could give to set a more positive direction for this. > > But I don't think we need a protocol statement banning HBH. The > reasons they are problematical should speak for themselves. +1. Thanks Suresh From manav.bhatia@alcatel-lucent.com Fri Feb 4 08:39:39 2011 Return-Path: X-Original-To: ipv6@core3.amsl.com Delivered-To: ipv6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D50353A69D2 for ; Fri, 4 Feb 2011 08:39:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.372 X-Spam-Level: X-Spam-Status: No, score=-6.372 tagged_above=-999 required=5 tests=[AWL=0.227, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4cB45C-abs3D for ; Fri, 4 Feb 2011 08:39:39 -0800 (PST) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by core3.amsl.com (Postfix) with ESMTP id 01D933A69CD for ; Fri, 4 Feb 2011 08:39:38 -0800 (PST) Received: from inbansmailrelay2.in.alcatel-lucent.com (h135-250-11-33.lucent.com [135.250.11.33]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id p14Gh0SO024216 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 4 Feb 2011 10:43:03 -0600 (CST) Received: from INBANSXCHHUB03.in.alcatel-lucent.com (inbansxchhub03.in.alcatel-lucent.com [135.250.12.80]) by inbansmailrelay2.in.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p14GgvTm030016 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 4 Feb 2011 22:13:00 +0530 Received: from INBANSXCHMBSA1.in.alcatel-lucent.com ([135.250.12.56]) by INBANSXCHHUB03.in.alcatel-lucent.com ([135.250.12.80]) with mapi; Fri, 4 Feb 2011 22:12:57 +0530 From: "Bhatia, Manav (Manav)" To: "Joel M. Halpern" Date: Fri, 4 Feb 2011 22:12:55 +0530 Subject: RE: Hop-by-Hop Extension Header processed in Slow Path? Thread-Topic: Hop-by-Hop Extension Header processed in Slow Path? Thread-Index: AcvEc+ODK8bLn1/NSuihc4pD6bgEXAAFh/cA Message-ID: <7C362EEF9C7896468B36C9B79200D8350CFB23EA9A@INBANSXCHMBSA1.in.alcatel-lucent.com> References: <4D4B6E54.9000703@joelhalpern.com> <7C362EEF9C7896468B36C9B79200D8350CFB23E849@INBANSXCHMBSA1.in.alcatel-lucent.com> <4D4B8D73.4090000@gont.com.ar> <7C362EEF9C7896468B36C9B79200D8350CFB23E904@INBANSXCHMBSA1.in.alcatel-lucent.com> <4D4BA5FC.2050207@gont.com.ar> <7C362EEF9C7896468B36C9B79200D8350CFB23E92A@INBANSXCHMBSA1.in.alcatel-lucent.com> <4D4C066A.5030707@joelhalpern.com> In-Reply-To: <4D4C066A.5030707@joelhalpern.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 X-Scanned-By: MIMEDefang 2.64 on 135.250.11.33 Cc: "ipv6@ietf.org" X-BeenThere: ipv6@ietf.org 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: , X-List-Received-Date: Fri, 04 Feb 2011 16:39:39 -0000 > options header is not sufficient for those cases. However, if the WG=20 > things it can not or should not ban end-to-end extension=20 > headers, then=20 > having a document giving them a more regular format still seems worth=20 > while to me. Which is more or less what that draft does. If you require a draft to docum= ent a regular standardized format then that means that you are open to the = idea of defining new extension headers in the future. If that's the case th= en why not use GIEH? Cheers, Manav >=20 From marcelo@it.uc3m.es Fri Feb 4 09:41:46 2011 Return-Path: X-Original-To: ipv6@core3.amsl.com Delivered-To: ipv6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3C4723A69FA for ; Fri, 4 Feb 2011 09:41:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.564 X-Spam-Level: X-Spam-Status: No, score=-106.564 tagged_above=-999 required=5 tests=[AWL=0.035, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ogdlUmEWPLZt for ; Fri, 4 Feb 2011 09:41:45 -0800 (PST) Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.176.131]) by core3.amsl.com (Postfix) with ESMTP id 5C37E3A69E3 for ; Fri, 4 Feb 2011 09:41:45 -0800 (PST) X-uc3m-safe: yes Received: from marcelo-bagnulos-macbook-pro-2.local (227.31.18.95.dynamic.jazztel.es [95.18.31.227]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by smtp01.uc3m.es (Postfix) with ESMTP id C18C2BF621F for ; Fri, 4 Feb 2011 18:45:09 +0100 (CET) Message-ID: <4D4C3B25.40006@it.uc3m.es> Date: Fri, 04 Feb 2011 18:45:09 +0100 From: marcelo bagnulo braun User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; es-ES; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: ipv6@ietf.org Subject: Re: Hop-by-Hop Extension Header processed in Slow Path? References: <201102041335.p14DZVUd017501@cichlid.raleigh.ibm.com> In-Reply-To: <201102041335.p14DZVUd017501@cichlid.raleigh.ibm.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-TM-AS-Product-Ver: IMSS-7.0.0.3116-6.5.0.1024-17936.000 X-BeenThere: ipv6@ietf.org 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: , X-List-Received-Date: Fri, 04 Feb 2011 17:41:46 -0000 Hi Thomas, I would like to hear your take on how we should encode conex information in IPv6 packets (http://datatracker.ietf.org/wg/conex/charter/) This is critical for conex and we are not clear on how we could do this in a way that could be deployed. Thanks in advance for any opinions you can provide on this to us. Regards, marcelo El 04/02/11 14:35, Thomas Narten escribió: > Gawd, I love these sorts of discussions. > > Remind me. How many HBH options has the IETF approved in the last ten > years? > > How many proposed HBH options are in the pipeline for approval? > > Could we please skip this silly discussion until such a time as > someone actually proposes a HBH option that makes sense, and for which > alternate approaches to solving the problem (that don't use HBH) are > worse? And when we have such a compelling proposal, discuss the > pros/cons of whether it can be deployed, whether routers will actually > implement it, etc.? > > These entirely theoretical discussions are mostly a complete waste of > time. > > And to be clear, I suspect we will not be approving any HBH options > any time soon. We know they are generally a bad idea. It is unlikely > that the reasons that HBH are a last resort approach will change > anytime soon. But can we please just leave things alone as they are > now? The possibility that a HBH may be defined in the future is not > something that is causing us problems today and needs fixing. > > Thomas > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > From vishwas.ietf@gmail.com Fri Feb 4 09:50:23 2011 Return-Path: X-Original-To: ipv6@core3.amsl.com Delivered-To: ipv6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6D2A53A6ACD for ; Fri, 4 Feb 2011 09:50:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.457 X-Spam-Level: X-Spam-Status: No, score=-3.457 tagged_above=-999 required=5 tests=[AWL=0.142, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GLaz0Mii0LGm for ; Fri, 4 Feb 2011 09:50:21 -0800 (PST) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by core3.amsl.com (Postfix) with ESMTP id 668E83A6A36 for ; Fri, 4 Feb 2011 09:50:21 -0800 (PST) Received: by wwa36 with SMTP id 36so2780157wwa.13 for ; Fri, 04 Feb 2011 09:53:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=GFDCl6VaSgIfDY9UPR08rBImg0E9IXoemvUWGSDFQvM=; b=bk4zBg9x96mOGFIHOO6zeMWNWhqWGjsiDZBRqiMhrZbkncBySUgtO7iWJM6dqhHyAz NNGgRi4pUlofHRU3WFYnM8QS/GotMCktgwwF0tQ+f2E0uMLniwNxiFDPx54XLUiJfEnh B8DpOHsWpOEpWGG7oicdAN/bcPkUmTWRtnsp4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=iBAuretjKNF4/RDVZ9ZXvWNCBEZOkmp4ecoapwqaiavKe6HzHurDbFciTkd39HX8yE P8GcX8XrsRzCSRc1f72x/9S72HTc+DR1uRv1WAygLFEb7+5HU65QDts5rhqhNIi8ANYV e6dKWV2gw47nS+reKz02HUmy0ToSjeDamWRzU= MIME-Version: 1.0 Received: by 10.216.169.202 with SMTP id n52mr6491988wel.15.1296842026092; Fri, 04 Feb 2011 09:53:46 -0800 (PST) Received: by 10.216.151.100 with HTTP; Fri, 4 Feb 2011 09:53:46 -0800 (PST) In-Reply-To: <4D4BEF42.5060106@kit.edu> References: <4D4BEF42.5060106@kit.edu> Date: Fri, 4 Feb 2011 09:53:46 -0800 Message-ID: Subject: Re: Hop-by-Hop Extension Header processed in Slow Path? From: Vishwas Manral To: Roland Bless Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org 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: , X-List-Received-Date: Fri, 04 Feb 2011 17:50:23 -0000 Hi Roland, The problem is not just about known options here, like I mentioned earlier. A structure where there is a list which needs to be walked serially and no fixed place for an information, it is bad for the fast path. I have mentioned cases for how bad it can get for IPv6. One good thing IPv6 does is it defined the order of options. If we want to process connex or some particular option, we could process it. However there may need to be some assumptions like, the option is the first in the list of options or any such thing. Thanks, Vishwas On Fri, Feb 4, 2011 at 4:21 AM, Roland Bless wrote: > Hi, > > Christopher Morrow wrote: >> My feeling is this: >> hop-by-hop processing will happen in slow-path (if you permit it to >> happen at all), you can't build a router today with an asic that'll >> know how to handle options which are created in the future :( > > while the latter is surely true, I don't think that this > argument precludes to implement fast path processing > of at least _some_ HbH options. I think that the current > implemented strategy to simply pass all HbH options > to the slow path CPU is broken. > > I'm not sure whether it is feasible, but couldn't the > Fast Path (ASIC) at least check for: > - known options to be processed in the fast path, e.g., > =A0some CONEX info field > - known options to be processed in the control plane, > =A0i.e., punt packet to control path (slow path CPU), > =A0e.g., some to intercept packets with a specific > =A0router alert option > - bypassing unknown options (depending on the specified > =A0actions) in the fast-path > > So some (not all) _basic_ header extension processing code > should be down in the fast path (like forwarding of non-supported > or "non-interesting" hop-by-hop options) while more complex > processing can surely stay up in the slow path. > I have the impression that we will sacrifice the possibility of > future useful IPv6 extensions due to some existing > implementation limitations. > > Regards, > =A0Roland > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > From narten@us.ibm.com Fri Feb 4 10:02:04 2011 Return-Path: X-Original-To: ipv6@core3.amsl.com Delivered-To: ipv6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6C5693A69AF for ; Fri, 4 Feb 2011 10:02:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.174 X-Spam-Level: X-Spam-Status: No, score=-106.174 tagged_above=-999 required=5 tests=[AWL=0.425, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tyes7SrPtED4 for ; Fri, 4 Feb 2011 10:02:02 -0800 (PST) Received: from e3.ny.us.ibm.com (e3.ny.us.ibm.com [32.97.182.143]) by core3.amsl.com (Postfix) with ESMTP id 4E88E3A686E for ; Fri, 4 Feb 2011 10:02:02 -0800 (PST) Received: from d01dlp02.pok.ibm.com (d01dlp02.pok.ibm.com [9.56.224.85]) by e3.ny.us.ibm.com (8.14.4/8.13.1) with ESMTP id p14Hjix1005523 for ; Fri, 4 Feb 2011 12:46:02 -0500 Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by d01dlp02.pok.ibm.com (Postfix) with ESMTP id 661484DE803B for ; Fri, 4 Feb 2011 13:04:47 -0500 (EST) Received: from d03av01.boulder.ibm.com (d03av01.boulder.ibm.com [9.17.195.167]) by d01relay04.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id p14I5Quq173306 for ; Fri, 4 Feb 2011 13:05:26 -0500 Received: from d03av01.boulder.ibm.com (loopback [127.0.0.1]) by d03av01.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id p14I5P0o032079 for ; Fri, 4 Feb 2011 11:05:25 -0700 Received: from cichlid.raleigh.ibm.com (sig-9-65-206-115.mts.ibm.com [9.65.206.115]) by d03av01.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id p14I5OgG032027 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 4 Feb 2011 11:05:25 -0700 Received: from cichlid.raleigh.ibm.com (localhost.localdomain [127.0.0.1]) by cichlid.raleigh.ibm.com (8.14.4/8.12.5) with ESMTP id p14I5NhQ020319; Fri, 4 Feb 2011 13:05:23 -0500 Message-Id: <201102041805.p14I5NhQ020319@cichlid.raleigh.ibm.com> To: marcelo bagnulo braun Subject: Re: Hop-by-Hop Extension Header processed in Slow Path? In-reply-to: <4D4C3B25.40006@it.uc3m.es> References: <201102041335.p14DZVUd017501@cichlid.raleigh.ibm.com> <4D4C3B25.40006@it.uc3m.es> Comments: In-reply-to marcelo bagnulo braun message dated "Fri, 04 Feb 2011 18:45:09 +0100." Date: Fri, 04 Feb 2011 13:05:23 -0500 From: Thomas Narten X-Content-Scanned: Fidelis XPS MAILER Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org 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: , X-List-Received-Date: Fri, 04 Feb 2011 18:02:05 -0000 Marcelo, Right off, I don't have enough understanding of what kind of architecture conex envisions to have any useful thoughts, but if you are thinking of using HBH options, the effort is certainly faces significant challenges. But rather than saying "don't use HBH" I'll suggest that you make the case for why HBH is the least worse way of designing conex. Understanding that use of HBH for anything implies serious questions about whether anyone will actually implement/deploy it. Thomas > I would like to hear your take on how we should encode conex information > in IPv6 packets > (http://datatracker.ietf.org/wg/conex/charter/) > This is critical for conex and we are not clear on how we could do this > in a way that could be deployed. > Thanks in advance for any opinions you can provide on this to us. > Regards, marcelo > El 04/02/11 14:35, Thomas Narten escribió: > > Gawd, I love these sorts of discussions. > > > > Remind me. How many HBH options has the IETF approved in the last ten > > years? > > > > How many proposed HBH options are in the pipeline for approval? > > > > Could we please skip this silly discussion until such a time as > > someone actually proposes a HBH option that makes sense, and for which > > alternate approaches to solving the problem (that don't use HBH) are > > worse? And when we have such a compelling proposal, discuss the > > pros/cons of whether it can be deployed, whether routers will actually > > implement it, etc.? > > > > These entirely theoretical discussions are mostly a complete waste of > > time. > > > > And to be clear, I suspect we will not be approving any HBH options > > any time soon. We know they are generally a bad idea. It is unlikely > > that the reasons that HBH are a last resort approach will change > > anytime soon. But can we please just leave things alone as they are > > now? The possibility that a HBH may be defined in the future is not > > something that is causing us problems today and needs fixing. > > > > Thomas > > -------------------------------------------------------------------- > > 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 > -------------------------------------------------------------------- From brian.e.carpenter@gmail.com Fri Feb 4 11:31:40 2011 Return-Path: X-Original-To: ipv6@core3.amsl.com Delivered-To: ipv6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 200083A6952 for ; Fri, 4 Feb 2011 11:31:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.483 X-Spam-Level: X-Spam-Status: No, score=-103.483 tagged_above=-999 required=5 tests=[AWL=0.116, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PH34ZoLL1l1q for ; Fri, 4 Feb 2011 11:31:39 -0800 (PST) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id E6AED3A68FC for ; Fri, 4 Feb 2011 11:31:38 -0800 (PST) Received: by fxm9 with SMTP id 9so2931813fxm.31 for ; Fri, 04 Feb 2011 11:35:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:organization:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=BpvIyNIM86eJUvhbkV/kIV5Z54+XRdKaRSi2qCQA/Kc=; b=GBFQObBQPOQgfFCi+f0Idj1krZr62xXt/oEyDLGh+FMtrSQVke0/D2amFUpVaBfYzR GIwfF2DYuYQX3EPfiaU9S3JnIhDar98KbSTHMt2Wgcbq6neBpuDsPkdtTHxsOXZ8atFL /1vYam1/HBri9zZO5rc3i8rN1HRW53rGdPMCM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; b=A0TAHUtwH+NSU5mUNFQ6gh3Mh2fJZhO++3WnH0rXtLydQq3uLRnphzfJBfWtXRGLtd GAnI+9ScKYkYQ2h3gOy4pawigT3IcOc95JXWIEDKCU1v3Fz61GdkNGSwYJ2uxWK/1613 Atd81uNMLJw9VadsN5oQj4Ki84GBWC8SzSFXg= Received: by 10.223.103.12 with SMTP id i12mr1344876fao.43.1296848103881; Fri, 04 Feb 2011 11:35:03 -0800 (PST) Received: from [10.1.1.4] ([121.98.190.33]) by mx.google.com with ESMTPS id c11sm393393fav.26.2011.02.04.11.35.00 (version=SSLv3 cipher=RC4-MD5); Fri, 04 Feb 2011 11:35:02 -0800 (PST) Message-ID: <4D4C54DD.1080208@gmail.com> Date: Sat, 05 Feb 2011 08:34:53 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Thomas Narten Subject: Re: RFC3697bis Open Issue 5 References: <4D46315C.3050806@gmail.com> <05834D09-0E37-497D-B1E6-3F008E98AECB@nsn.com> <201102040136.p141apKn011527@cichlid.raleigh.ibm.com> <4D4B6C8A.2060306@gmail.com> <201102041402.p14E2Cdq017725@cichlid.raleigh.ibm.com> In-Reply-To: <201102041402.p14E2Cdq017725@cichlid.raleigh.ibm.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: 6man X-BeenThere: ipv6@ietf.org 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: , X-List-Received-Date: Fri, 04 Feb 2011 19:31:40 -0000 On 2011-02-05 03:02, Thomas Narten wrote: > Brian E Carpenter writes: > >> OK, something like > >> Although the flow label is defined as immutable once it has >> been set to a non-zero value, implementers should be aware >> that it is an unprotected field that could have been accidentally >> or intentionally changed en route. Implementations MUST >> take appropriate steps to protect themselves from being >> vulnerable to denial of service and other types of attack that >> could result. > > This sounds about right. > > To put this in perspective, routers can't assume the source or > destination address in a packet has not been modified since leaving > the originator. But that doesn't cause us all to Freak Out! :-) Correct. There's a subtle difference though - if the flow label alone has been changed, the packet has in fact been delivered to the correct place and any reply packet will be sent to the correct place. So the attacks and side-effects are a bit different than if one (or both) addresses were changed. Brian From christopher.morrow@gmail.com Fri Feb 4 14:11:28 2011 Return-Path: X-Original-To: ipv6@core3.amsl.com Delivered-To: ipv6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9A8233A69D7 for ; Fri, 4 Feb 2011 14:11:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YpkCO1+HtkK9 for ; Fri, 4 Feb 2011 14:11:21 -0800 (PST) Received: from mail-ew0-f44.google.com (mail-ew0-f44.google.com [209.85.215.44]) by core3.amsl.com (Postfix) with ESMTP id 3218A3A68FC for ; Fri, 4 Feb 2011 14:11:20 -0800 (PST) Received: by ewy8 with SMTP id 8so1660044ewy.31 for ; Fri, 04 Feb 2011 14:14:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=kELzm3YMy66XfX4Bf0oy2fA3VC+wpVp/4sFPaL4AEwA=; b=H18mElU6/XUqmYWCk5FKBOWQ7Y9fd2ZXxFrjwfqcqtWwlkmAa7ZntKLNvYm5lZK3FW NnfdcQ2YMtmrgknJQqEgG3jLUtryaLAjTINmAiP1313U6SHG1EJ3PQNtYPKUCqF3Ogrw fu6JIkrAzdDWMixqyVSuJgD5Bk2UMsN795/XA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=IpPtHiNifNNS17uzbgTIufj/vZowsbpu3V5V5Y8x9kdbeD60UXg0ktSkGmPhwtzikj AwjgxRLVxB1K0qgSiLQhwhG8KXEf9htfFN03qwbq+i+qDB89Rj4DJAOaRcP26mdjPVWm OugxDAAg4SyRAMqNoQ0Sb4RAAJPyUJTtSRx0w= MIME-Version: 1.0 Received: by 10.213.35.3 with SMTP id n3mr6005542ebd.36.1296857685300; Fri, 04 Feb 2011 14:14:45 -0800 (PST) Received: by 10.213.113.6 with HTTP; Fri, 4 Feb 2011 14:14:45 -0800 (PST) In-Reply-To: References: <4D4BEF42.5060106@kit.edu> Date: Fri, 4 Feb 2011 17:14:45 -0500 Message-ID: Subject: Re: Hop-by-Hop Extension Header processed in Slow Path? From: Christopher Morrow To: Roland Bless Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org 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: , X-List-Received-Date: Fri, 04 Feb 2011 22:11:29 -0000 On Fri, Feb 4, 2011 at 10:27 AM, Christopher Morrow wrote: > On Fri, Feb 4, 2011 at 7:21 AM, Roland Bless wrote= : >> Hi, >> >> Christopher Morrow wrote: >>> My feeling is this: >>> hop-by-hop processing will happen in slow-path (if you permit it to >>> happen at all), you can't build a router today with an asic that'll >>> know how to handle options which are created in the future :( >> >> while the latter is surely true, I don't think that this >> argument precludes to implement fast path processing >> of at least _some_ HbH options. I think that the current >> implemented strategy to simply pass all HbH options >> to the slow path CPU is broken. >> >> I'm not sure whether it is feasible, but couldn't the >> Fast Path (ASIC) at least check for: >> - known options to be processed in the fast path, e.g., >> =A0some CONEX info field > > which options? how often would you expect this list to update? routers > live in the network for ~7 years or so, in large networks. ASIC > updates mean very expensive (equipment, personnel, sla) changes are > required. > Someone reminded me off-list to be clear about what the problem is... Any packet that requires hop-by-hop behavior is a problem. If a backbone router has to attempt to stream packets off a production interface and into the RE/RP/PRP, the router will fall over. So, the operator(s) are left with 2 real options: 1) drop all packets NOT icmpv6, tcp, udp (drop all other extension header= s) 2) ignore any extension header NOT icmpv6, udp, tcp It would be grand if router vendors (Juniper, Cisco, Force10, Extreme, Foundry, Huawei, etc) would provide a knob on all of their platforms that said: hbh-options [ignore|drop] This would allow all network operators (enterprise, datacenter, backbone) to decide how to handle traffic with hbh options. I'm sure someone at the vendor of your choice could also add in options to drop/ignore by type of option, though that seems more brittle. (I hope this is more clear :) ) -Chris From suresh.krishnan@ericsson.com Fri Feb 4 14:37:37 2011 Return-Path: X-Original-To: ipv6@core3.amsl.com Delivered-To: ipv6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2CD653A69D4 for ; Fri, 4 Feb 2011 14:37:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.546 X-Spam-Level: X-Spam-Status: No, score=-102.546 tagged_above=-999 required=5 tests=[AWL=0.053, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r4+7BAS1E7+b for ; Fri, 4 Feb 2011 14:37:36 -0800 (PST) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.8]) by core3.amsl.com (Postfix) with ESMTP id 318093A6998 for ; Fri, 4 Feb 2011 14:37:35 -0800 (PST) Received: from eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id p14NNpek013698; Fri, 4 Feb 2011 17:23:53 -0600 Received: from [142.133.10.107] (147.117.20.213) by eusaamw0707.eamcs.ericsson.se (147.117.20.92) with Microsoft SMTP Server id 8.2.234.1; Fri, 4 Feb 2011 17:40:53 -0500 Message-ID: <4D4C8042.2010909@ericsson.com> Date: Fri, 4 Feb 2011 17:40:02 -0500 From: Suresh Krishnan User-Agent: Thunderbird 2.0.0.24 (X11/20101027) MIME-Version: 1.0 To: Christopher Morrow Subject: Re: Hop-by-Hop Extension Header processed in Slow Path? References: <4D4BEF42.5060106@kit.edu> In-Reply-To: Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: 7bit Cc: "ipv6@ietf.org" X-BeenThere: ipv6@ietf.org 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: , X-List-Received-Date: Fri, 04 Feb 2011 22:37:37 -0000 Hi Chris, On 11-02-04 05:14 PM, Christopher Morrow wrote: > On Fri, Feb 4, 2011 at 10:27 AM, Christopher Morrow > wrote: >> On Fri, Feb 4, 2011 at 7:21 AM, Roland Bless wrote: >>> Hi, >>> >>> Christopher Morrow wrote: >>>> My feeling is this: >>>> hop-by-hop processing will happen in slow-path (if you permit it to >>>> happen at all), you can't build a router today with an asic that'll >>>> know how to handle options which are created in the future :( >>> while the latter is surely true, I don't think that this >>> argument precludes to implement fast path processing >>> of at least _some_ HbH options. I think that the current >>> implemented strategy to simply pass all HbH options >>> to the slow path CPU is broken. >>> >>> I'm not sure whether it is feasible, but couldn't the >>> Fast Path (ASIC) at least check for: >>> - known options to be processed in the fast path, e.g., >>> some CONEX info field >> which options? how often would you expect this list to update? routers >> live in the network for ~7 years or so, in large networks. ASIC >> updates mean very expensive (equipment, personnel, sla) changes are >> required. >> > > Someone reminded me off-list to be clear about what the problem is... > Any packet that requires hop-by-hop behavior is a problem. If a > backbone router has to attempt to stream packets off a production > interface and into the RE/RP/PRP, the router will fall over. I fully agree with you. > > So, the operator(s) are left with 2 real options: > 1) drop all packets NOT icmpv6, tcp, udp (drop all other extension headers) > 2) ignore any extension header NOT icmpv6, udp, tcp > > It would be grand if router vendors (Juniper, Cisco, Force10, Extreme, > Foundry, Huawei, etc) would provide a knob on all of their platforms > that said: > > hbh-options [ignore|drop] The ignore option was what I proposed in Section 3.2 of http://tools.ietf.org/html/draft-krishnan-ipv6-hopbyhop-05 but dropping should be something that an operator should be able to enable as well. Cheers Suresh From suresh.krishnan@ericsson.com Fri Feb 4 14:49:27 2011 Return-Path: X-Original-To: ipv6@core3.amsl.com Delivered-To: ipv6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 06A9D3A6A13 for ; Fri, 4 Feb 2011 14:49:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.547 X-Spam-Level: X-Spam-Status: No, score=-102.547 tagged_above=-999 required=5 tests=[AWL=0.052, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DnLTtMXdCQK2 for ; Fri, 4 Feb 2011 14:49:26 -0800 (PST) Received: from imr3.ericy.com (imr3.ericy.com [198.24.6.13]) by core3.amsl.com (Postfix) with ESMTP id 069873A6A0D for ; Fri, 4 Feb 2011 14:49:25 -0800 (PST) Received: from eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) by imr3.ericy.com (8.13.8/8.13.8) with ESMTP id p14MqZLx026818 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 4 Feb 2011 16:52:36 -0600 Received: from [142.133.10.107] (147.117.20.213) by eusaamw0707.eamcs.ericsson.se (147.117.20.92) with Microsoft SMTP Server id 8.2.234.1; Fri, 4 Feb 2011 17:52:35 -0500 Message-ID: <4D4C8300.3070102@ericsson.com> Date: Fri, 4 Feb 2011 17:51:44 -0500 From: Suresh Krishnan User-Agent: Thunderbird 2.0.0.24 (X11/20101027) MIME-Version: 1.0 To: Thomas Narten Subject: Conex(was Re: Hop-by-Hop Extension Header processed in Slow Path?) References: <201102041335.p14DZVUd017501@cichlid.raleigh.ibm.com> <4D4C3B25.40006@it.uc3m.es> <201102041805.p14I5NhQ020319@cichlid.raleigh.ibm.com> In-Reply-To: <201102041805.p14I5NhQ020319@cichlid.raleigh.ibm.com> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit Cc: marcelo bagnulo braun , Nandita Dukkipati , Bob Briscoe , IETF IPv6 Mailing List X-BeenThere: ipv6@ietf.org 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: , X-List-Received-Date: Fri, 04 Feb 2011 22:49:27 -0000 Hi Thomas, On 11-02-04 01:05 PM, Thomas Narten wrote: > Marcelo, > > Right off, I don't have enough understanding of what kind of > architecture conex envisions to have any useful thoughts, but if you > are thinking of using HBH options, the effort is certainly faces > significant challenges. > > But rather than saying "don't use HBH" I'll suggest that you make the > case for why HBH is the least worse way of designing > conex. Understanding that use of HBH for anything implies serious > questions about whether anyone will actually implement/deploy it. Fully agree with you. Hop-by-hop options are not really suitable for conex at all, just like you said. Before the last IETF, we went through the alternatives for performing conex markings on IPv6 datagrams. These were the requirements we were working with R1: The information needs to be visible to all interested nodes on the path. R2: The information needs to be able to traverse nodes that do not understand the markings. R3: The presence of the marking mechanism should not significantly alter the processing of the packet. There were no real suitable mechanisms for IPv6 that met these requirements other than using some free bits in the header. We would greatly appreciate any hints you can provide us in this regard. Thanks Suresh From rja.lists@gmail.com Fri Feb 4 15:04:58 2011 Return-Path: X-Original-To: ipv6@core3.amsl.com Delivered-To: ipv6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8FF703A69FA for ; Fri, 4 Feb 2011 15:04:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.383 X-Spam-Level: X-Spam-Status: No, score=-3.383 tagged_above=-999 required=5 tests=[AWL=0.216, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E6ZMIPTrTc8U for ; Fri, 4 Feb 2011 15:04:57 -0800 (PST) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by core3.amsl.com (Postfix) with ESMTP id 140663A69CD for ; Fri, 4 Feb 2011 15:04:57 -0800 (PST) Received: by gyd12 with SMTP id 12so1260573gyd.31 for ; Fri, 04 Feb 2011 15:08:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:from:content-type:content-transfer-encoding :subject:date:message-id:to:mime-version:x-mailer; bh=BR2xFGhGr4oyMn6k8B1WyPGUPjOLV6NX4FCNOMjz+nw=; b=wxQwQgCC0yMbrklx+dqSaHNBi4NWGsSfoBy4Gce1z3rbrNGxKiBuCaZpJmmOhJHDTK ws8M8vGeOgYFGXB4uujreXWHbGkxHGU4y1246LdKNWZ+a5aK9F8l+sGjFAjmtaV5khbT n8aIhArKR+QJlu0PBHRGjat3qy99wdavy8KlQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:content-type:content-transfer-encoding:subject:date:message-id :to:mime-version:x-mailer; b=YLc1kMIv8oIq/kSJuhYicld1koIJe1EiS18G8+fKgw9ySzrRp/CmA11wRxOciYImmo nDbToCRJFZJA3pNHdn/tfHxHbIK5+r8NaQOGmvGbgPnWn7UUlojsXxahTwtcGe1bOacm 99GGtwUYdEeYhMskCF4w8VBvmeGHfT4me72h4= Received: by 10.151.79.13 with SMTP id g13mr15759394ybl.51.1296860902821; Fri, 04 Feb 2011 15:08:22 -0800 (PST) Received: from [10.30.20.7] (pool-96-225-170-25.nrflva.fios.verizon.net [96.225.170.25]) by mx.google.com with ESMTPS id r41sm1352243yba.4.2011.02.04.15.08.21 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 04 Feb 2011 15:08:22 -0800 (PST) From: RJ Atkinson Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: Re: Hop-by-Hop Extension Header processed in Slow Path ? Date: Fri, 4 Feb 2011 18:08:20 -0500 Message-Id: <3F3FD6DA-3F9C-43A7-99B7-DB3323C722FC@gmail.com> To: ipv6@ietf.org Mime-Version: 1.0 (Apple Message framework v1082) X-Mailer: Apple Mail (2.1082) X-BeenThere: ipv6@ietf.org 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: , X-List-Received-Date: Fri, 04 Feb 2011 23:04:58 -0000 On 4th February 2011 at 09:00:15 -0500, Joel Halpern wrote: > Given what we know about packet processing, any extension that = believes=20 > it will be processed by every router along the path is probably = fooling itself. >=20 > Therefore, documenting something that claims to provide > that functionality is probably a mistake. >=20 > At that point, we go to the question of whether, for those packets > that want hop-by-hop processing by some routers distinct from the > end point to which the packet is addressed, how should we do it. >=20 > 1) Don't. >=20 > 2) Extensions: Note that our underlying documents specifically > say not to do that, for very good reasons. Even the new document > on extension headers was only describing extension headers > for end-to-end processing. >=20 > 3) Use HbH anyway. There is hardware that can ignore it. > There is hardware that can parse it. We coudl certainly > couple that with discouraging all such use. +1 to everything above. To me, (3) -- including advice explaining why the hop-by-hop behaviour is problematic -- seems like a sensible approach. =20 Trying to say that IPv6 options with hop-by-hop behaviour=20 can't be created at all is actually less effective than a=20 document explaining why hop-by-hop *behaviours* can be=20 problematic and requiring IESG Approval before any new=20 IPv6 options with hop-by-hop behaviour are specified. > We have found, repeatedly, that pretending we can direct packets > to every router along a path is just not a good idea. Note that > even our OAM fanatics (MPLS-TP) have given up on trying that trick. +1 to that also. > That of course would bring us back to discussing where extensions=20 > with end-to-end semantics should go. I am still unclear why the=20 > end-to-end options header is not sufficient for those cases. Agreed. Moreover, worked examples already exist showing that the IPv6 Destination Options Header can be used as-is to support=20 new end-to-end IPv6 options not envisioned back in 1995. Further, we know that some existing widely deployed commercial=20 IPv6 routers can parse-past the Destination Options Header=20 at wire speed if appropriate (e.g. to look at transport-layer=20 protocol and transport-layer port numbers as part of an=20 ACL decision). Yours, Ran rja.lists@gmail.com From huitema@microsoft.com Fri Feb 4 15:41:41 2011 Return-Path: X-Original-To: ipv6@core3.amsl.com Delivered-To: ipv6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D65873A69A5 for ; Fri, 4 Feb 2011 15:41:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.462 X-Spam-Level: X-Spam-Status: No, score=-10.462 tagged_above=-999 required=5 tests=[AWL=0.137, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WhLSFhIP4-lJ for ; Fri, 4 Feb 2011 15:41:41 -0800 (PST) Received: from smtp.microsoft.com (mailb.microsoft.com [131.107.115.215]) by core3.amsl.com (Postfix) with ESMTP id 1DECD3A69A1 for ; Fri, 4 Feb 2011 15:41:41 -0800 (PST) Received: from TK5EX14HUBC101.redmond.corp.microsoft.com (157.54.7.153) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.2.176.0; Fri, 4 Feb 2011 15:45:05 -0800 Received: from TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com (157.54.71.68) by TK5EX14HUBC101.redmond.corp.microsoft.com (157.54.7.153) with Microsoft SMTP Server (TLS) id 14.1.270.2; Fri, 4 Feb 2011 15:45:05 -0800 Received: from TK5EX14MBXW651.wingroup.windeploy.ntdev.microsoft.com ([169.254.1.204]) by TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com ([157.54.71.68]) with mapi; Fri, 4 Feb 2011 15:45:03 -0800 From: Christian Huitema To: RJ Atkinson , "IETF IPv6 Mailing List (ipv6@ietf.org)" Subject: RE: Hop-by-Hop Extension Header processed in Slow Path ? Thread-Topic: Hop-by-Hop Extension Header processed in Slow Path ? Thread-Index: AQHLxMB+mXZUZJv6M0yQ1MGFWsKUIJPyACRw Date: Fri, 4 Feb 2011 23:45:03 +0000 Message-ID: References: <3F3FD6DA-3F9C-43A7-99B7-DB3323C722FC@gmail.com> In-Reply-To: <3F3FD6DA-3F9C-43A7-99B7-DB3323C722FC@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-BeenThere: ipv6@ietf.org 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: , X-List-Received-Date: Fri, 04 Feb 2011 23:41:41 -0000 >> 3) Use HbH anyway. There is hardware that can ignore it. >> There is hardware that can parse it. We coudl certainly >> couple that with discouraging all such use. > > +1 to everything above. > > To me, (3) -- including advice explaining why the hop-by-hop behaviour is= problematic -- seems like a sensible approach. =20 There is actually an advantage to having a single "hop by hop" option. It m= eans that by default everything else is end-to-end. Routers can thus "just = forward it" without violating any IETF recommendation. That's much simpler = than having to maintain a table of which payload require intermediate proce= ssing and which don't. -- Christian Huitema From john@jlc.net Fri Feb 4 15:45:46 2011 Return-Path: X-Original-To: ipv6@core3.amsl.com Delivered-To: ipv6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 311653A6A5E for ; Fri, 4 Feb 2011 15:45:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.055 X-Spam-Level: X-Spam-Status: No, score=-106.055 tagged_above=-999 required=5 tests=[AWL=-0.056, BAYES_00=-2.599, J_CHICKENPOX_53=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I4Iiz0cjexjC for ; Fri, 4 Feb 2011 15:45:45 -0800 (PST) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by core3.amsl.com (Postfix) with ESMTP id 43C493A69DC for ; Fri, 4 Feb 2011 15:45:44 -0800 (PST) Received: by mailhost.jlc.net (Postfix, from userid 104) id C389C33C3A; Fri, 4 Feb 2011 18:49:10 -0500 (EST) Date: Fri, 4 Feb 2011 18:49:10 -0500 From: John Leslie To: Suresh Krishnan Subject: Re: Conex(was Re: Hop-by-Hop Extension Header processed in Slow Path?) Message-ID: <20110204234910.GC41896@verdi> References: <201102041335.p14DZVUd017501@cichlid.raleigh.ibm.com> <4D4C3B25.40006@it.uc3m.es> <201102041805.p14I5NhQ020319@cichlid.raleigh.ibm.com> <4D4C8300.3070102@ericsson.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4D4C8300.3070102@ericsson.com> User-Agent: Mutt/1.4.1i Cc: IETF IPv6 Mailing List X-BeenThere: ipv6@ietf.org 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: , X-List-Received-Date: Fri, 04 Feb 2011 23:45:46 -0000 Suresh Krishnan wrote: > On 11-02-04 01:05 PM, Thomas Narten wrote: > >> Right off, I don't have enough understanding of what kind of >> architecture conex envisions to have any useful thoughts, but if you >> are thinking of using HBH options, the effort is certainly faces >> significant challenges. I don't believe anyone on the ConEx list _likes_ the idea of using hop-by-hop options -- it's just hard to grok the alternatives. >> But rather than saying "don't use HBH" I'll suggest that you make the >> case for why HBH is the least worse way of designing conex. IMHO, that's a null case. ;^) >> Understanding that use of HBH for anything implies serious >> questions about whether anyone will actually implement/deploy it. We don't even rise to the level of discussing implementation in routers. > Fully agree with you. Hop-by-hop options are not really suitable for > conex at all, just like you said. Before the last IETF, we went through > the alternatives for performing conex markings on IPv6 datagrams. These > were the requirements we were working with > > R1: The information needs to be visible to all interested nodes on the > path. > R2: The information needs to be able to traverse nodes that do not > understand the markings. > R3: The presence of the marking mechanism should not significantly alter > the processing of the packet. That's pretty much where we stand. Hop-by-hop is pretty-much ruled out. Destination-Options is _so_ confusing that we hestitate to mention it. To add to the confusion, our primary algorithm talks of piggy-backing on the ECN bits, and the most serious proposal so far (developed for IPv4-land) talks of sort-of-redefining one of the four values of ECN to show what I'll call "congestion-predicted" and adding one additional bit to make sure all cases are covered. (I don't think it would help at this stage to go into more detail of that proposal: there clearly are other ways we could cover-the-cases, and actually it's premature to say we wouldn't want more than one-bit precision on "congestion-predicted" -- however that proposal _does_ seem adequate for useful experiments. We are, after all, chartered to produce an Experimental spec.) > There were no real suitable mechanisms for IPv6 that met these > requirements other than using some free bits in the header. We would > greatly appreciate any hints you can provide us in this regard. It's early enough in the ConEx process that we're open to some quite fundamentally different approaches. For example, we have discussed how to expose congestion (along the path, at the IP layer) in cases where ECN isn't deployed. We're exploring the possible -- and not really expecting to like what we find. ;^) -- John Leslie From ran.atkinson@gmail.com Fri Feb 4 16:19:00 2011 Return-Path: X-Original-To: ipv6@core3.amsl.com Delivered-To: ipv6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BA1363A6802 for ; Fri, 4 Feb 2011 16:19:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.333 X-Spam-Level: X-Spam-Status: No, score=-3.333 tagged_above=-999 required=5 tests=[AWL=0.266, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u43bpEXnsbMd for ; Fri, 4 Feb 2011 16:18:59 -0800 (PST) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by core3.amsl.com (Postfix) with ESMTP id 9F0683A67D1 for ; Fri, 4 Feb 2011 16:18:59 -0800 (PST) Received: by qwi2 with SMTP id 2so2363830qwi.31 for ; Fri, 04 Feb 2011 16:22:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:from:content-type:content-transfer-encoding :subject:date:message-id:to:mime-version:x-mailer; bh=JDrTnUvrKh+zfWWEvKsfyDAzszuWksuk+4+b3odjMsc=; b=JMdRTTB+RZc96Chs3CQlNKTZC7xb3kjnZkGzjkO6ApxYQsUyKxcdlETT2riJFNcC/v 4j3EFDdOCNzGm84vziAC6HdodCeq+Cez8hHO1V/aOIz5xKMDI5XDzpR1WERmPSD60qqU VWYM4bZG1vZaSSJlA9JJG6h0CDb4voxoMko2Y= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:content-type:content-transfer-encoding:subject:date:message-id :to:mime-version:x-mailer; b=fK1hRrt91YWhUQ1GRfp6Wal7jSyIM4HUae2oWcXLJIkL6qr6IwK7lrw+KEGhiRq8pL aRxG1wLgVId6H8T7Yrmu7H2Jh4Bw+i5QGyKL4gIksUHhgklH5dB2/vr36VcIgNC70oFf s8UkALpeRpuMCbMnU+1QdI/uGIeRLz9PyfRBI= Received: by 10.229.217.11 with SMTP id hk11mr5223440qcb.248.1296865345309; Fri, 04 Feb 2011 16:22:25 -0800 (PST) Received: from [10.30.20.7] (pool-96-225-170-25.nrflva.fios.verizon.net [96.225.170.25]) by mx.google.com with ESMTPS id g32sm858817qck.34.2011.02.04.16.22.23 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 04 Feb 2011 16:22:24 -0800 (PST) From: Ran Atkinson Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: Hop-by-Hop Extension Header processed in Slow Path? Date: Fri, 4 Feb 2011 19:22:22 -0500 Message-Id: To: ipv6@ietf.org Mime-Version: 1.0 (Apple Message framework v1082) X-Mailer: Apple Mail (2.1082) X-Mailman-Approved-At: Fri, 04 Feb 2011 17:30:35 -0800 X-BeenThere: ipv6@ietf.org 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: , X-List-Received-Date: Sat, 05 Feb 2011 00:19:00 -0000 On Friday 4th February 2011, at 06:39:51 +0530, Hing-Kam Lam wrote: > The below white paper from Cisco asserts that most vendors including > Cisco process Hop-by-Hop extension headers in CPU (slow path). > Is this correct? In general, it is not wise to trust any vendor X when they are talking about some different vendor Y's products or implementations. Business pressures can impede clear and complete communications in that situation. Of course, it is quite reasonable to trust vendor X when talking about their own products/implementations. I know of vendors that have shipped (and customers have deployed) IPv6-capable routers with silicon (not necessarily an NP, think about Verilog/gates) that can process existing IPv6 hop-by-hop options in silicon (again, not necessarily an NP, think Verilog/gates). It appears that the author of the document you mention might not be aware of those other implementations. ANY (optional header or option) that has a **hop-by-hop behaviour** clearly can be problematic in some very common circumstances (e.g. transit routers within the global Internet that neither ignore such options nor process such options at line-rate). RFC-5570 demonstrates that in some very unusual circumstances, an IPv6 Hop-by-Hop Header can be both useful and sensible to deploy. Some network operators on this list have indicated that their IPv6 routers at present simply drop packets containing hop-by-hop headers (and possibly some other optional headers). There are credible reports that in some other deployments, IPv6 routers are configured to *ignore* the presence of IPv6 Hop-by-Hop options when forwarding IPv6 packets. The net result of this is that EVEN IF someone specified a new (optional header or option) with hop-by-hop behaviour, THEN the actual real-world public Internet behaviour likely would be different than the option designer expected, at least within "public" segments of the global Internet. There is substantial evidence that the IESG already believes that adding more options with hop-by-hop behaviour ought not be allowed except in special, very limited, circumstances. [RFC-5570, Page 1, "IESG Note"] Yours, Ran From hingkam16@gmail.com Fri Feb 4 23:00:20 2011 Return-Path: X-Original-To: ipv6@core3.amsl.com Delivered-To: ipv6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1A92E3A6B08 for ; Fri, 4 Feb 2011 23:00:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.325 X-Spam-Level: X-Spam-Status: No, score=-3.325 tagged_above=-999 required=5 tests=[AWL=0.274, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LEFIyfjXHDTB for ; Fri, 4 Feb 2011 23:00:18 -0800 (PST) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id B8BC43A6981 for ; Fri, 4 Feb 2011 23:00:16 -0800 (PST) Received: by iwc10 with SMTP id 10so3176848iwc.31 for ; Fri, 04 Feb 2011 23:03:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=PVmOFCurXZ0qJE6aWXtuhO2zeURFcN6nfaYjPcE+xBU=; b=KUFPDBHy/056cNSi1g1WsS47OGd56xuHdEH+FJs7e2gFoI0q+w2uUFLtJ+m4htk3hg 7eEV/owulfLGlzbjKpIfUdy6zDUco2lA3nMwG8gbUaNVptBfbSKwdcEfMm9Lca3vUnCX MS8ghADsvxf7Q34zxHh25Hj5+DlF97SMcBVSc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=E6H6ng9540adNSrJF35yIAsuyfodq84xQSACwJwMpm3Pl1M7/8VZBJNGfhENTtNTxw aRd1cBbjF4O4rUyT8ckgkRT/7uZdg968t75Cdnh+Vpk9J4mIH2SqStVpzZpL/b2xrJzC RHsfSnBc0GCsgtSAy+vkHU/tYHlOZDNAOM/3w= MIME-Version: 1.0 Received: by 10.231.85.137 with SMTP id o9mr58146ibl.27.1296889423457; Fri, 04 Feb 2011 23:03:43 -0800 (PST) Received: by 10.231.207.11 with HTTP; Fri, 4 Feb 2011 23:03:43 -0800 (PST) In-Reply-To: References: Date: Sat, 5 Feb 2011 12:33:43 +0530 Message-ID: Subject: Re: Hop-by-Hop Extension Header processed in Slow Path? From: "Hing-Kam (Kam) Lam" To: Ran Atkinson Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org 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: , X-List-Received-Date: Sat, 05 Feb 2011 07:00:20 -0000 >> The below white paper from Cisco asserts that most vendors including >> Cisco process Hop-by-Hop extension headers in CPU (slow path). >> Is this correct? > > In general, it is not wise to trust any vendor X when they are > talking about some different vendor Y's products or implementations. > Business pressures can impede clear and complete communications > in that situation. =A0Of course, it is quite reasonable to trust > vendor X when talking about their own products/implementations. This article also includes Cisco's behavior for their products and implementations. Kam From rja.lists@gmail.com Sat Feb 5 08:49:51 2011 Return-Path: X-Original-To: ipv6@core3.amsl.com Delivered-To: ipv6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 55F253A6923 for ; Sat, 5 Feb 2011 08:49:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.39 X-Spam-Level: X-Spam-Status: No, score=-3.39 tagged_above=-999 required=5 tests=[AWL=0.209, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SZ24XhDEp7eg for ; Sat, 5 Feb 2011 08:49:50 -0800 (PST) Received: from mail-qy0-f179.google.com (mail-qy0-f179.google.com [209.85.216.179]) by core3.amsl.com (Postfix) with ESMTP id 810B83A6902 for ; Sat, 5 Feb 2011 08:49:50 -0800 (PST) Received: by qyj19 with SMTP id 19so2671659qyj.10 for ; Sat, 05 Feb 2011 08:53:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:content-type:mime-version:subject:from :in-reply-to:date:content-transfer-encoding:message-id:references:to :x-mailer; bh=Z2pp1hVv+W5BbSumTyZgDXm3OG6X4glaZIzfXAAxbk8=; b=Mh+bng3oTbDbnsyjW3ZetRGcdqdgW3QcVU0RoJtpKSm7uD56Pou2d8mYU3jXkpOc7w RE4Jrx9UP2mRE7J1jSV5bPQT0CtCnWrGtJRiNm0nTvncHnAceUSgwhqfHvANFZuJzCsN On/tZphBriaUz1S+9E8AMOVDNOqvZSbPf9YBs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=content-type:mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to:x-mailer; b=w5g4LDcO0TcHd+KuKT4aW6g+vKp3n4u07b7FUl10JjP9/6AMzEeaTOwq1Hl9+H9GvM rD9dysH0B5y9Nwa0Pv79eUSmdZJrVVGAYYdLL2ndnATQL5feXEr/y/fce8buSuH4TmxC OQWAxQdqluiIdw2txrw7fABTSzHNOieBeh7wA= Received: by 10.229.81.65 with SMTP id w1mr11514740qck.9.1296924798074; Sat, 05 Feb 2011 08:53:18 -0800 (PST) Received: from [10.30.20.7] (pool-96-225-170-25.nrflva.fios.verizon.net [96.225.170.25]) by mx.google.com with ESMTPS id s21sm1110857qct.44.2011.02.05.08.53.16 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sat, 05 Feb 2011 08:53:16 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1082) Subject: Re: Hop-by-Hop Extension Header processed in Slow Path? From: RJ Atkinson In-Reply-To: Date: Sat, 5 Feb 2011 11:53:14 -0500 Content-Transfer-Encoding: 7bit Message-Id: <4275709A-EA7E-4D9A-83C6-A0EA3D2026E1@gmail.com> References: To: ipv6@ietf.org X-Mailer: Apple Mail (2.1082) X-BeenThere: ipv6@ietf.org 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: , X-List-Received-Date: Sat, 05 Feb 2011 16:49:51 -0000 On 05 Feb 2011, at 02:03 , Hing-Kam (Kam) Lam wrote: > This article also includes Cisco's behavior > for their products and implementations. Yes. I read the article. Thank you for posting the full URL. I do not doubt the article's description of cisco products was accurate -- as of the date it was written. However, the article says explicitly that it is over 4 years old (towards the top of the web page): "Last updated: October 2006" So the article does not claim to cover all of cisco's current router products. It only claims to cover their products as of October 2006, which is over 4 years ago. Please don't misunderstand. The document you cited was interesting, and having the full URL made it easy to find. Unfortunately, it is a bit out of date by now, which limits its value for this WG. Separately, information from some other vendors contradicts the claims the Cisco page makes about other vendors' products and implementations. Cheers, Ran From roland.bless@kit.edu Mon Feb 7 01:32:40 2011 Return-Path: X-Original-To: ipv6@core3.amsl.com Delivered-To: ipv6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B5F3A3A6D6C for ; Mon, 7 Feb 2011 01:32:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f4rJEVHpFELr for ; Mon, 7 Feb 2011 01:32:39 -0800 (PST) Received: from iramx2.ira.uni-karlsruhe.de (iramx2.ira.uni-karlsruhe.de [141.3.10.81]) by core3.amsl.com (Postfix) with ESMTP id 999CE3A6D6A for ; Mon, 7 Feb 2011 01:32:10 -0800 (PST) Received: from irams1.ira.uni-karlsruhe.de ([141.3.10.5]) by iramx2.ira.uni-karlsruhe.de with esmtps port 25 id 1PmNRt-0003Nh-QI; Mon, 07 Feb 2011 10:32:03 +0100 Received: from i72ms.tm.uni-karlsruhe.de ([141.3.70.5] helo=smtp.ipv6.tm.uni-karlsruhe.de) by irams1.ira.uni-karlsruhe.de with esmtps port 25 id 1PmNRt-0001W2-Lf; Mon, 07 Feb 2011 10:31:57 +0100 Received: from vorta.tm.kit.edu (i72vorta.tm.uni-karlsruhe.de [IPv6:2001:638:204:6:21b:fcff:fe96:fe02]) by smtp.ipv6.tm.uni-karlsruhe.de (Postfix) with ESMTP id 9C1DB2FC025; Mon, 7 Feb 2011 10:31:57 +0100 (CET) Received: from [IPv6:::1] (ip6-localhost [IPv6:::1]) by vorta.tm.kit.edu (Postfix) with ESMTPS id 7C972148; Mon, 7 Feb 2011 10:31:57 +0100 (CET) Message-ID: <4D4FBC0D.3060706@kit.edu> Date: Mon, 07 Feb 2011 10:31:57 +0100 From: Roland Bless Organization: Institute of Telematics, Karlsruhe Institute of Technology User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.13) Gecko/20101208 Thunderbird/3.1.7 MIME-Version: 1.0 To: Christopher Morrow Subject: Re: Hop-by-Hop Extension Header processed in Slow Path? References: <4D4BEF42.5060106@kit.edu> In-Reply-To: X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-ATIS-AV: ClamAV (irams1.ira.uni-karlsruhe.de) X-ATIS-AV: ClamAV (iramx2.ira.uni-karlsruhe.de) X-ATIS-AV: Kaspersky (iramx2.ira.uni-karlsruhe.de) X-ATIS-Timestamp: iramx2.ira.uni-karlsruhe.de 1297071123.983968000 Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org 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: , X-List-Received-Date: Mon, 07 Feb 2011 09:32:40 -0000 Hi Chris, Am 04.02.2011 16:27, schrieb Christopher Morrow: > which options? how often would you expect this list to update? routers > live in the network for ~7 years or so, in large networks. ASIC > updates mean very expensive (equipment, personnel, sla) changes are > required. Which options depends on the supported or configured options. I didn't mean to hard code the list into the ASIC, but the list should be configurable, so no need to update the ASIC once the basic mechanisms for HBH options are available. For example if only some router alert option values are of interest, those should be configured in the aforementioned list, everything else would be bypassed in the fast path. >> - known options to be processed in the control plane, >> i.e., punt packet to control path (slow path CPU), >> e.g., some to intercept packets with a specific >> router alert option >> - bypassing unknown options (depending on the specified >> actions) in the fast-path > > and hopefully with a consistent decision on which goes where here? I'd > hate for (for example) Cisco to turn left while Juniper turns right... > this also seems complex. Again, just providing a knob (and accepting I guess that's the problem of earlier specs that provide too little guidance for implementers, IMHO that's at least the case for the Router Alert Option. > that it will happen) that the HBH options may just be ignored in the > public network may terminate this discussion completely. Yes, maybe. Regards, Roland From roland.bless@kit.edu Mon Feb 7 02:44:47 2011 Return-Path: X-Original-To: ipv6@core3.amsl.com Delivered-To: ipv6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EC3C93A6D95 for ; Mon, 7 Feb 2011 02:44:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZcbD1r5jnCvU for ; Mon, 7 Feb 2011 02:44:47 -0800 (PST) Received: from iramx2.ira.uni-karlsruhe.de (iramx2.ira.uni-karlsruhe.de [141.3.10.81]) by core3.amsl.com (Postfix) with ESMTP id A9D1E3A6D97 for ; Mon, 7 Feb 2011 02:44:44 -0800 (PST) Received: from irams1.ira.uni-karlsruhe.de ([141.3.10.5]) by iramx2.ira.uni-karlsruhe.de with esmtps port 25 id 1PmOaI-0007RE-9z; Mon, 07 Feb 2011 11:44:47 +0100 Received: from i72ms.tm.uni-karlsruhe.de ([141.3.70.5] helo=smtp.ipv6.tm.uni-karlsruhe.de) by irams1.ira.uni-karlsruhe.de with esmtps port 25 id 1PmOaI-0000hL-6I; Mon, 07 Feb 2011 11:44:42 +0100 Received: from vorta.tm.kit.edu (roland.tm.uni-karlsruhe.de [IPv6:2001:638:204:6:21b:fcff:fe96:fe02]) by smtp.ipv6.tm.uni-karlsruhe.de (Postfix) with ESMTP id 24C862FC025; Mon, 7 Feb 2011 11:44:42 +0100 (CET) Received: from [IPv6:::1] (ip6-localhost [IPv6:::1]) by vorta.tm.kit.edu (Postfix) with ESMTPS id 01E29B09; Mon, 7 Feb 2011 11:44:41 +0100 (CET) Message-ID: <4D4FCD19.1010509@kit.edu> Date: Mon, 07 Feb 2011 11:44:41 +0100 From: Roland Bless Organization: Institute of Telematics, Karlsruhe Institute of Technology User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.13) Gecko/20101208 Thunderbird/3.1.7 MIME-Version: 1.0 To: Vishwas Manral Subject: Re: Hop-by-Hop Extension Header processed in Slow Path? References: <4D4BEF42.5060106@kit.edu> In-Reply-To: X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-ATIS-AV: ClamAV (irams1.ira.uni-karlsruhe.de) X-ATIS-AV: ClamAV (iramx2.ira.uni-karlsruhe.de) X-ATIS-AV: Kaspersky (iramx2.ira.uni-karlsruhe.de) X-ATIS-Timestamp: iramx2.ira.uni-karlsruhe.de 1297075487.750239000 Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org 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: , X-List-Received-Date: Mon, 07 Feb 2011 10:44:48 -0000 Hi Vishwas, Am 04.02.2011 18:53, schrieb Vishwas Manral: > The problem is not just about known options here, like I mentioned > earlier. A structure where there is a list which needs to be walked > serially and no fixed place for an information, it is bad for the fast > path. I see. > I have mentioned cases for how bad it can get for IPv6. One good thing > IPv6 does is it defined the order of options. > > If we want to process connex or some particular option, we could > process it. However there may need to be some assumptions like, the > option is the first in the list of options or any such thing. Personally, I'm not looking for a new option, but I was wondering about Conex trying to redefine/claim common IPv6 header bits for their purpose, which is IMHO worse than using some HbH option. In NSIS we suffered a lot from the Router Alert Option problems... If the current extension mechanisms of IPv6 need some fixes to allow for fast path processing and to be useful in the future at least, someone may consider working on this out... Regards, Roland From john@jlc.net Mon Feb 7 04:33:53 2011 Return-Path: X-Original-To: ipv6@core3.amsl.com Delivered-To: ipv6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9B0753A6D83 for ; Mon, 7 Feb 2011 04:33:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oEleQiJiIZjG for ; Mon, 7 Feb 2011 04:33:52 -0800 (PST) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by core3.amsl.com (Postfix) with ESMTP id 3F06E3A6D6B for ; Mon, 7 Feb 2011 04:33:52 -0800 (PST) Received: by mailhost.jlc.net (Postfix, from userid 104) id 0B2E333C27; Mon, 7 Feb 2011 07:33:46 -0500 (EST) Date: Mon, 7 Feb 2011 07:33:45 -0500 From: John Leslie To: Roland Bless Subject: ConEx use of Flow Label? Message-ID: <20110207123345.GA44291@verdi> References: <4D4BEF42.5060106@kit.edu> <4D4FCD19.1010509@kit.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4D4FCD19.1010509@kit.edu> User-Agent: Mutt/1.4.1i Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org 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: , X-List-Received-Date: Mon, 07 Feb 2011 12:33:53 -0000 Roland Bless wrote: > Am 04.02.2011 18:53, schrieb Vishwas Manral: > >> If we want to process connex or some particular option, we could >> process it. However there may need to be some assumptions like, the >> option is the first in the list of options or any such thing. > > Personally, I'm not looking for a new option, but I was wondering > about Conex trying to redefine/claim common IPv6 header bits for > their purpose, which is IMHO worse than using some HbH option... Disclaimer: I am a co-author of one of the ConEx drafts; but I make no claim to speak for anyone else -- least of all my co-authors! I _think_ we're looking at the Flow Label field. Let me outline my understanding of that field -- RFC 2460 states that the Flow Label field is to be set by the source: ] ] 6. Flow Labels ] ] The 20-bit Flow Label field in the IPv6 header may be used by a ] source to label sequences of packets for which it requests special ] handling by the IPv6 routers, such as non-default quality of service ] or "real-time" service. This aspect of IPv6 is, at the time of ] writing, still experimental and subject to change as the requirements ] for flow support in the Internet become clearer. Hosts or routers ] that do not support the functions of the Flow Label field are ] required to set the field to zero when originating a packet, pass the ] field on unchanged when forwarding a packet, and ignore the field ] when receiving a packet. ] ] Appendix A describes the current intended semantics and usage of the ] Flow Label field. Note Appendix A is "current intended semantics" and is clearly subject to change. Appendix A "currently" calls for: ] ] A flow label is assigned to a flow by the flow's source node. New ] flow labels must be chosen (pseudo-)randomly and uniformly from the ] range 1 to FFFFF hex. The purpose of the random allocation is to ] make any set of bits within the Flow Label field suitable for use as ] a hash key by routers, for looking up the state associated with the ] flow. Since Appendix A calls for "pseudo-random" and section 6 insists that "most" routers must ignore the field and pass it unchanged, at first blush ConEx-aware senders could put something there and expect it to survive the trip through a number of not-ConEx-aware routers. ;^) Note that RFC 1883, which suggested that routers "opportunistically" "set up flow handling state" is now quite obsolete (the field doesn't even match!); and even 1883 made no suggestion that a router might legitimately _change_ the flow label. (I suppose technically a NAT might play with flow-label, since the definition calls for a flow to be ] ] uniquely identified by the combination of a source address and a ] non-zero flow label but I have no reason to believe any existing IPv6 NAT does such a thing.) IMHO, Appendix A of RFC 2460 was pining-for-the-fjords when RFC 2460 was published in 1998. However, we need to consider RFC 3697, published in 2004. (It is standards-track, but I don't know of any implementations.) RFC 3697 specifies: - The Flow Label value set by the source MUST be delivered unchanged to the destination node(s) - IPv6 nodes MUST NOT assume any mathematical or other properties of the Flow Label values assigned by source nodes. - Router performance SHOULD NOT be dependent on the distribution of the Flow Label values. Especially, the Flow Label bits alone make poor material for a hash key. ==== Thus it would seem that ConEx-aware senders could put a value in Flow label, reserving several bits that could be changed by ConEx-aware routers (and more importantly by ConEx policers) without changing the flow _identity_ as seen by ConEx-aware devices. I'd like to see some discussion of this. IMHO, 6man is a better place for the discussion than ConEx, since ConEx is concerned with the meaning of bits more than transport of them. -- John Leslie From jhw@apple.com Mon Feb 7 11:04:31 2011 Return-Path: X-Original-To: ipv6@core3.amsl.com Delivered-To: ipv6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1DE473A6E75 for ; Mon, 7 Feb 2011 11:04:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iOrugg1xnGoO for ; Mon, 7 Feb 2011 11:04:30 -0800 (PST) Received: from mail-out3.apple.com (mail-out.apple.com [17.254.13.22]) by core3.amsl.com (Postfix) with ESMTP id 4054D3A6985 for ; Mon, 7 Feb 2011 11:04:30 -0800 (PST) Received: from relay12.apple.com (relay12.apple.com [17.128.113.53]) by mail-out3.apple.com (Postfix) with ESMTP id 52835CD25A4A for ; Mon, 7 Feb 2011 11:04:35 -0800 (PST) X-AuditID: 11807135-b7cf8ae0000007ed-82-4d50424320d2 Received: from gertie.apple.com (gertie.apple.com [17.151.62.15]) by relay12.apple.com (Apple SCV relay) with SMTP id 72.32.02029.342405D4; Mon, 7 Feb 2011 11:04:35 -0800 (PST) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=us-ascii Received: from il0602f-dhcp196.apple.com (il0602f-dhcp196.apple.com [17.206.50.196]) by gertie.apple.com (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008; 32bit)) with ESMTPSA id <0LG900MSSGZMKGB0@gertie.apple.com> for ipv6@ietf.org; Mon, 07 Feb 2011 11:04:35 -0800 (PST) Subject: Re: Hop-by-Hop Extension Header processed in Slow Path? From: james woodyatt In-reply-to: <4D4BA5FC.2050207@gont.com.ar> Date: Mon, 07 Feb 2011 11:04:34 -0800 Message-id: <3B9C110C-A7F0-4E73-B1C3-ADCE64C806CA@apple.com> References: <4D4B6E54.9000703@joelhalpern.com> <7C362EEF9C7896468B36C9B79200D8350CFB23E849@INBANSXCHMBSA1.in.alcatel-lucent.com> <4D4B8D73.4090000@gont.com.ar> <7C362EEF9C7896468B36C9B79200D8350CFB23E904@INBANSXCHMBSA1.in.alcatel-lucent.com> <4D4BA5FC.2050207@gont.com.ar> To: 6man Group X-Mailer: Apple Mail (2.1082) X-Brightmail-Tracker: AAAAAA== X-BeenThere: ipv6@ietf.org 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: , X-List-Received-Date: Mon, 07 Feb 2011 19:04:31 -0000 On Feb 3, 2011, at 23:08, Fernando Gont wrote: > On 04/02/2011 03:53 a.m., Bhatia, Manav (Manav) wrote: >> One of the major reasons given for not accepting this was that no new >> extension headers need to be *ever* defined in future because you >> MUST either use hop-by-hop ext header or the destination options ext >> header. > > What type of options are you envisioning that would not fit in any of > the existing extension headers? -- That was the main argument against > the publication of the aforementioned I-D. Once again, I will repeat that I-D.woodyatt-ald envisioned a profile of ICMPv6 messages that need to be processed by firewall devices. I would have preferred to specify a new class of header extension that is neither hop-by-hop nor destination oriented that would include a new Firewall Alert option. I suppose a HBH extension would suffice, but it would mean passing a lot of packets through the HBH path in routers that are not also firewalls. Another option would be to expect firewalls to snoop all the ICMPv6 traffic looking for ALD packets, but that would have negative performance effects as well. What to do what to do what to do... In any case, there isn't currently a class of extension headers intended for processing only at some middleboxes and not all routers. I appreciate that IETF would like to keep the middleboxes from getting too uppity, but that goal is in conflict with IETF recommendations to implement security functions in packet filters integrated with routers, c.f. RFC 6092. It would be helpful if more participants would bear this in mind, so that we don't have to keep having discussions in which we pretend that the conflict isn't happening when it clearly is an ongoing problem. -- james woodyatt member of technical staff, communications engineering From brian.e.carpenter@gmail.com Mon Feb 7 13:02:26 2011 Return-Path: X-Original-To: ipv6@core3.amsl.com Delivered-To: ipv6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 505E03A6E70 for ; Mon, 7 Feb 2011 13:02:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PEUTuk4L-VRU for ; Mon, 7 Feb 2011 13:02:25 -0800 (PST) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by core3.amsl.com (Postfix) with ESMTP id 67D2C3A6EBE for ; Mon, 7 Feb 2011 13:02:24 -0800 (PST) Received: by bwz12 with SMTP id 12so5948239bwz.31 for ; Mon, 07 Feb 2011 13:02:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:organization:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=PSHtOTdRwpyndJNYspyWiKFKMOReqMpm266f5IPVmzM=; b=NKxsLi78lOudnxRcvwl5bJKJMw7A8slxlR0KbJ8L1EOMwR5cakfQeMh6SL8FbPufOT vdHC785c++DPaUsTFvkJIWjuV260nw+/CbTUK6yDPlS+v2WZPmGUZON+Xvi8v9JT9XFC 9YLZ/P1lUH60QOz5F8FDoQwURadU1kfCGfjfA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; b=v9Gq3Cx+ql5XpSAiqqhqxfgjjksKhJvw16mgvOx88igPOvDtcAxkQKTv7W/9lvrQjV zpv6TCvuIUQ8WOPnTwGzNGyAiAkC4IoN0Htm3nShQOAz5iSUiL5JtMs2dIDOstVwBhE3 yC+2/ZqQq94d5i1SQh2RQbjDLOhLXoc6otksY= Received: by 10.204.68.9 with SMTP id t9mr5586550bki.173.1297112417645; Mon, 07 Feb 2011 13:00:17 -0800 (PST) Received: from [130.216.38.124] (stf-brian.sfac.auckland.ac.nz [130.216.38.124]) by mx.google.com with ESMTPS id u23sm2314863bkw.9.2011.02.07.13.00.12 (version=SSLv3 cipher=RC4-MD5); Mon, 07 Feb 2011 13:00:14 -0800 (PST) Message-ID: <4D505D58.8010504@gmail.com> Date: Tue, 08 Feb 2011 10:00:08 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: John Leslie Subject: Re: ConEx use of Flow Label? References: <4D4BEF42.5060106@kit.edu> <4D4FCD19.1010509@kit.edu> <20110207123345.GA44291@verdi> In-Reply-To: <20110207123345.GA44291@verdi> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org 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: , X-List-Received-Date: Mon, 07 Feb 2011 21:02:26 -0000 Hi John, First off, forget what the Appendix of RFC 2460 says. It's not normative. So, the current rules are in RFC 3697. They certainly don't allow any kind of semantics in the bits of the flow label (in the absence of a signalling mechanism): > IPv6 nodes MUST NOT assume any mathematical or other properties of > the Flow Label values assigned by source nodes. Then: >> reserving several bits that could be changed by ConEx-aware >> routers Changing any bits is forbidden by RFC 3697. We are discussing draft-ietf-6man-flow-3697bis-00.txt, which will (if approved) replace RFC 3697. It doesn't allow encoding any kind of semantics either, or mutability, but of course it's open for debate in the WG. I suggest reading that draft as the next step. Regards Brian Carpenter On 2011-02-08 01:33, John Leslie wrote: > Roland Bless wrote: >> Am 04.02.2011 18:53, schrieb Vishwas Manral: >> >>> If we want to process connex or some particular option, we could >>> process it. However there may need to be some assumptions like, the >>> option is the first in the list of options or any such thing. >> Personally, I'm not looking for a new option, but I was wondering >> about Conex trying to redefine/claim common IPv6 header bits for >> their purpose, which is IMHO worse than using some HbH option... > > Disclaimer: I am a co-author of one of the ConEx drafts; but I make no > claim to speak for anyone else -- least of all my co-authors! > > I _think_ we're looking at the Flow Label field. Let me outline my > understanding of that field -- > > RFC 2460 states that the Flow Label field is to be set by the source: > ] > ] 6. Flow Labels > ] > ] The 20-bit Flow Label field in the IPv6 header may be used by a > ] source to label sequences of packets for which it requests special > ] handling by the IPv6 routers, such as non-default quality of service > ] or "real-time" service. This aspect of IPv6 is, at the time of > ] writing, still experimental and subject to change as the requirements > ] for flow support in the Internet become clearer. Hosts or routers > ] that do not support the functions of the Flow Label field are > ] required to set the field to zero when originating a packet, pass the > ] field on unchanged when forwarding a packet, and ignore the field > ] when receiving a packet. > ] > ] Appendix A describes the current intended semantics and usage of the > ] Flow Label field. > > Note Appendix A is "current intended semantics" and is clearly subject > to change. > > Appendix A "currently" calls for: > ] > ] A flow label is assigned to a flow by the flow's source node. New > ] flow labels must be chosen (pseudo-)randomly and uniformly from the > ] range 1 to FFFFF hex. The purpose of the random allocation is to > ] make any set of bits within the Flow Label field suitable for use as > ] a hash key by routers, for looking up the state associated with the > ] flow. > > Since Appendix A calls for "pseudo-random" and section 6 insists that > "most" routers must ignore the field and pass it unchanged, at first blush > ConEx-aware senders could put something there and expect it to survive > the trip through a number of not-ConEx-aware routers. ;^) > > Note that RFC 1883, which suggested that routers "opportunistically" > "set up flow handling state" is now quite obsolete (the field doesn't > even match!); and even 1883 made no suggestion that a router might > legitimately _change_ the flow label. > > (I suppose technically a NAT might play with flow-label, since the > definition calls for a flow to be > ] > ] uniquely identified by the combination of a source address and a > ] non-zero flow label > > but I have no reason to believe any existing IPv6 NAT does such a thing.) > > IMHO, Appendix A of RFC 2460 was pining-for-the-fjords when RFC 2460 > was published in 1998. However, we need to consider RFC 3697, published > in 2004. (It is standards-track, but I don't know of any implementations.) > > RFC 3697 specifies: > > - The Flow Label value set by the source MUST be delivered unchanged > to the destination node(s) > > - IPv6 nodes MUST NOT assume any mathematical or other properties of > the Flow Label values assigned by source nodes. > > - Router performance SHOULD NOT be dependent on the distribution of the > Flow Label values. Especially, the Flow Label bits alone make poor > material for a hash key. > > ==== > > Thus it would seem that ConEx-aware senders could put a value in > Flow label, reserving several bits that could be changed by ConEx-aware > routers (and more importantly by ConEx policers) without changing the > flow _identity_ as seen by ConEx-aware devices. > > I'd like to see some discussion of this. IMHO, 6man is a better place > for the discussion than ConEx, since ConEx is concerned with the meaning > of bits more than transport of them. > > -- > John Leslie > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > From Internet-Drafts@ietf.org Tue Feb 8 14:30:18 2011 Return-Path: X-Original-To: ipv6@core3.amsl.com Delivered-To: ipv6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8D8153A6857; Tue, 8 Feb 2011 14:30:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xrgWbbhTq6-P; Tue, 8 Feb 2011 14:30:04 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3F5BF3A683C; Tue, 8 Feb 2011 14:30:02 -0800 (PST) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Subject: I-D Action:draft-ietf-6man-rpl-option-02.txt X-Test-IDTracker: no X-IETF-IDTracker: 3.12 Message-ID: <20110208223002.18671.83197.idtracker@localhost> Date: Tue, 08 Feb 2011 14:30:02 -0800 Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org 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: , X-List-Received-Date: Tue, 08 Feb 2011 22:30:18 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPv6 Maintenance Working Group of the IETF. Title : RPL Option for Carrying RPL Information in Data-Plane Datagrams Author(s) : J. Hui, J. Vasseur Filename : draft-ietf-6man-rpl-option-02.txt Pages : 14 Date : 2011-02-08 The RPL protocol requires data-plane datagrams to carry RPL routing information that is processed by RPL routers when forwarding those datagrams. This document describes the RPL option for use within a RPL domain. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-6man-rpl-option-02.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-6man-rpl-option-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-02-08142513.I-D@ietf.org> --NextPart-- From iljitsch@muada.com Wed Feb 9 02:53:07 2011 Return-Path: X-Original-To: ipv6@core3.amsl.com Delivered-To: ipv6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C6FAA3A6902 for ; Wed, 9 Feb 2011 02:53:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NgvOTe6wkm0f for ; Wed, 9 Feb 2011 02:53:06 -0800 (PST) Received: from sequoia.muada.com (unknown [IPv6:2001:1af8:2:5::2]) by core3.amsl.com (Postfix) with ESMTP id CA9833A67DF for ; Wed, 9 Feb 2011 02:53:05 -0800 (PST) Received: from claw.it.uc3m.es ([163.117.139.233]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id p19AqWcY015314 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Wed, 9 Feb 2011 11:52:33 +0100 (CET) (envelope-from iljitsch@muada.com) From: Iljitsch van Beijnum Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: Source for ICMP on link-local-only interface? Date: Wed, 9 Feb 2011 11:52:33 +0100 Message-Id: To: 6man 6man Mime-Version: 1.0 (Apple Message framework v1082) X-Mailer: Apple Mail (2.1082) X-BeenThere: ipv6@ietf.org 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: , X-List-Received-Date: Wed, 09 Feb 2011 10:53:07 -0000 I've been telling people for years that with IPv6, you don't need a = global scope address on an interface. The routing protocols use link = locals, so they don't care. And should an ICMP message need to be = generated, the source address is filled in with a global scope address = borrowed from another interface that does have one. However, I can't find any documentation for this behavior. Is there an = RFC that specifies this as part of normal IPv6 router behavior? Thanks, Iljitsch= From ichiroumakino@gmail.com Wed Feb 9 02:58:18 2011 Return-Path: X-Original-To: ipv6@core3.amsl.com Delivered-To: ipv6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3AA863A6971 for ; Wed, 9 Feb 2011 02:58:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QHfRnQ1ZXRhC for ; Wed, 9 Feb 2011 02:58:17 -0800 (PST) Received: from mail-ew0-f44.google.com (mail-ew0-f44.google.com [209.85.215.44]) by core3.amsl.com (Postfix) with ESMTP id E94053A67DF for ; Wed, 9 Feb 2011 02:58:16 -0800 (PST) Received: by ewy8 with SMTP id 8so9884ewy.31 for ; Wed, 09 Feb 2011 02:58:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:sender:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to:x-mailer; bh=JT1c1MyVSV/4MAUrdYRmVaAsCfsLmT88lP2/o6JybQ8=; b=BwCzG1bKU0iT6TZOaJwCC686WZvy7gh7aW9Uwt4KhzbcNrPf3b6/CDcD6QdW+qVgQE vmgSSUfIRvpXuvh2gkzZem+1zoIOlDfJc07xtfxIGNtD3/5KE8M0JXnRGbxxzTNVtBSW zX2EJAfENIzP4bjdDsHhL+AGRfPG/o/svloG0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=GIU3DSChUkvVFFy08vvkuAIYM9EmgDk3LOtKfyA/RrjDWNNW5l9cL+pm6H58yPXXko fOgZ+VQeVpJBAVBFiXo1R57phvbMDtR5FPYL9bXQ4q5GPN+TdHg24/fN5wBzJiE9nG1H Qa2iO5OM17bgphUtsccYhBBgZtTXUeoMe5p18= Received: by 10.213.28.69 with SMTP id l5mr1632360ebc.13.1297249105507; Wed, 09 Feb 2011 02:58:25 -0800 (PST) Received: from ams3-vpn-dhcp4226.cisco.com (64-103-25-233.cisco.com [64.103.25.233]) by mx.google.com with ESMTPS id x54sm128904eeh.17.2011.02.09.02.58.24 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 09 Feb 2011 02:58:24 -0800 (PST) Sender: Ole Troan Subject: Re: Source for ICMP on link-local-only interface? Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Ole Troan In-Reply-To: Date: Wed, 9 Feb 2011 11:58:22 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <7FA68862-18F8-4257-B37C-3C0A49B53923@employees.org> References: To: Iljitsch van Beijnum X-Mailer: Apple Mail (2.1082) Cc: 6man 6man X-BeenThere: ipv6@ietf.org 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: , X-List-Received-Date: Wed, 09 Feb 2011 10:58:18 -0000 > I've been telling people for years that with IPv6, you don't need a = global scope address on an interface. The routing protocols use link = locals, so they don't care. And should an ICMP message need to be = generated, the source address is filled in with a global scope address = borrowed from another interface that does have one. >=20 > However, I can't find any documentation for this behavior. Is there an = RFC that specifies this as part of normal IPv6 router behavior? weak host model. RFC1122. cheers, Ole From ray@oneunified.net Wed Feb 9 02:58:28 2011 Return-Path: X-Original-To: ipv6@core3.amsl.com Delivered-To: ipv6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C12473A697E for ; Wed, 9 Feb 2011 02:58:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.299 X-Spam-Level: X-Spam-Status: No, score=-1.299 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G8MGU0CKqAwy for ; Wed, 9 Feb 2011 02:58:28 -0800 (PST) Received: from mail1.oneunified.net (mail1.oneunified.net [63.85.42.215]) by core3.amsl.com (Postfix) with ESMTP id BE2263A6984 for ; Wed, 9 Feb 2011 02:58:27 -0800 (PST) X-OneUnified-MailScanner-Watermark: 1297853909.32196@bYrtZehft3fFHfIoPyhdBw X-OneUnified-MailScanner-From: ray@oneunified.net X-OneUnified-MailScanner-SpamScore: sss X-OneUnified-MailScanner: Found to be clean X-OneUnified-MailScanner-ID: p19AwRn5030494 X-OneUnified-MailScanner-Information: Please contact the ISP for more information Received: from z800 (mail1.oneunified.net [63.85.42.215] (may be forged)) by mail1.oneunified.net (8.14.3/8.14.3/Debian-5) with ESMTP id p19AwRn5030494 for ; Wed, 9 Feb 2011 05:58:28 -0500 From: "Raymond Burkholder" To: "'6man 6man'" References: In-Reply-To: Subject: RE: Source for ICMP on link-local-only interface? Date: Wed, 9 Feb 2011 06:58:24 -0400 Message-ID: <055101cbc848$46a12ec0$d3e38c40$@oneunified.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQKm1pm0ozJzx0+G84XgTDcSh4nn/ZJC4oqA Content-Language: en-us X-BeenThere: ipv6@ietf.org 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: , X-List-Received-Date: Wed, 09 Feb 2011 10:58:28 -0000 > I've been telling people for years that with IPv6, you don't need a global > scope address on an interface. The routing protocols use link locals, so they > don't care. And should an ICMP message need to be generated, the source > address is filled in with a global scope address borrowed from another > interface that does have one. > One useful aspect of ICMP is in tracerouting, where you get an ip address of a particular interface, and then through a reverse dns lookup, you get a human readable name for the interface. Very useful for troubleshooting where errant packets are going. Not very useful if you get a device loop-back, resulting in some information being lost. Or is there an alternate mechanism for providing this level of detail in IPv6 traceroutes? Raymond -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. From mohacsi@niif.hu Wed Feb 9 03:05:09 2011 Return-Path: X-Original-To: ipv6@core3.amsl.com Delivered-To: ipv6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 886053A6980 for ; Wed, 9 Feb 2011 03:05:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.108 X-Spam-Level: X-Spam-Status: No, score=0.108 tagged_above=-999 required=5 tests=[AWL=0.113, BAYES_00=-2.599, HELO_EQ_HU=1.35, HOST_EQ_HU=1.245] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iY+IMTJRpLww for ; Wed, 9 Feb 2011 03:05:08 -0800 (PST) Received: from mail.ki.iif.hu (mail.ki.iif.hu [IPv6:2001:738:0:411::241]) by core3.amsl.com (Postfix) with ESMTP id 665F43A6981 for ; Wed, 9 Feb 2011 03:05:08 -0800 (PST) Received: from bolha.lvs.iif.hu (bolha.lvs.iif.hu [193.225.14.181]) by mail.ki.iif.hu (Postfix) with ESMTP id F07D486BD0; Wed, 9 Feb 2011 12:05:16 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at bolha.lvs.iif.hu Received: from mail.ki.iif.hu ([IPv6:::ffff:193.6.222.241]) by bolha.lvs.iif.hu (bolha.lvs.iif.hu [::ffff:193.225.14.72]) (amavisd-new, port 10024) with ESMTP id lJoaD5VNd4PA; Wed, 9 Feb 2011 12:05:01 +0100 (CET) Received: by mail.ki.iif.hu (Postfix, from userid 9002) id 85B8886C0F; Wed, 9 Feb 2011 12:05:01 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by mail.ki.iif.hu (Postfix) with ESMTP id 8431686C07; Wed, 9 Feb 2011 12:05:01 +0100 (CET) Date: Wed, 9 Feb 2011 12:05:01 +0100 (CET) From: Mohacsi Janos X-X-Sender: mohacsi@mignon.ki.iif.hu To: Iljitsch van Beijnum Subject: Re: Source for ICMP on link-local-only interface? In-Reply-To: Message-ID: References: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: 6man 6man X-BeenThere: ipv6@ietf.org 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: , X-List-Received-Date: Wed, 09 Feb 2011 11:05:09 -0000 On Wed, 9 Feb 2011, Iljitsch van Beijnum wrote: > I've been telling people for years that with IPv6, you don't need a > global scope address on an interface. The routing protocols use link > locals, so they don't care. And should an ICMP message need to be > generated, the source address is filled in with a global scope address > borrowed from another interface that does have one. I think it is part of source address selection: destination is global scope, then the source should be global scope as well. > > However, I can't find any documentation for this behavior. Is there an RFC that specifies this as part of normal IPv6 router behavior? I think this behaviour is not the router behaviour, but the router as a host. ICMP messages are generated by the host software. Which interface's global address is selected is depend probably on router software. e.g. first interface index with global address. You can make it consistent with Cisco e.g.: ipv6 unnumbered Best Regards, Janos Mohacsi Head of HBONE+ project Network Engineer, Deputy Director of Network Planning and Projects NIIF/HUNGARNET, HUNGARY Key 70EF9882: DEC2 C685 1ED4 C95A 145F 4300 6F64 7B00 70EF 9882 > > Thanks, > > Iljitsch > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > From iljitsch@muada.com Wed Feb 9 03:15:09 2011 Return-Path: X-Original-To: ipv6@core3.amsl.com Delivered-To: ipv6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3A7A43A697C for ; Wed, 9 Feb 2011 03:15:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ueTbGahWPdno for ; Wed, 9 Feb 2011 03:15:08 -0800 (PST) Received: from sequoia.muada.com (unknown [IPv6:2001:1af8:2:5::2]) by core3.amsl.com (Postfix) with ESMTP id 40BDB3A697A for ; Wed, 9 Feb 2011 03:15:08 -0800 (PST) Received: from [IPv6:2001:720:410:100f:223:32ff:fec4:ba94] ([IPv6:2001:720:410:100f:223:32ff:fec4:ba94]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id p19BEWlh015484 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 9 Feb 2011 12:14:36 +0100 (CET) (envelope-from iljitsch@muada.com) Subject: Re: Source for ICMP on link-local-only interface? Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Iljitsch van Beijnum In-Reply-To: <7FA68862-18F8-4257-B37C-3C0A49B53923@employees.org> Date: Wed, 9 Feb 2011 12:15:09 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <1B32D387-9828-4440-AE04-5E73D8DE733D@muada.com> References: <7FA68862-18F8-4257-B37C-3C0A49B53923@employees.org> To: Ole Troan X-Mailer: Apple Mail (2.1082) Cc: 6man 6man X-BeenThere: ipv6@ietf.org 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: , X-List-Received-Date: Wed, 09 Feb 2011 11:15:09 -0000 On 9 feb 2011, at 11:58, Ole Troan wrote: >> However, I can't find any documentation for this behavior. Is there = an RFC that specifies this as part of normal IPv6 router behavior? > weak host model. RFC1122. Hah, this RFC talks about "weak ES" and "strong ES" models. I'm not sure = if that's politically correct considering what happened regarding CLNP = and IPv6 only a few years after 1122 was published. However, it doesn't say anything about this. Neither does RFC 4294, IPv6 = Node Requirements, unless it's without using the words "source address", = "interface" or "global" and under a very non-obvious heading. Same thing = for 2460 - 2464, 3484, 3513.= From tore.anderson@redpill-linpro.com Wed Feb 9 03:15:50 2011 Return-Path: X-Original-To: ipv6@core3.amsl.com Delivered-To: ipv6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E49EA3A697A for ; Wed, 9 Feb 2011 03:15:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.538 X-Spam-Level: X-Spam-Status: No, score=-2.538 tagged_above=-999 required=5 tests=[AWL=0.062, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jU0psDAxQx+y for ; Wed, 9 Feb 2011 03:15:49 -0800 (PST) Received: from mailhub.linpro.no (mailhub.linpro.no [87.238.49.141]) by core3.amsl.com (Postfix) with ESMTP id B7BAA3A6971 for ; Wed, 9 Feb 2011 03:15:49 -0800 (PST) Received: from localhost (mailhub.linpro.no [87.238.49.141]) by mailhub.linpro.no (Postfix) with ESMTP id 6E096C470D; Wed, 9 Feb 2011 12:15:58 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at mailhub.linpro.no Received: from mailhub.linpro.no ([87.238.49.141]) by localhost (mailhub.linpro.no [87.238.49.141]) (amavisd-new, port 10024) with ESMTP id zVcpzi3GK-Xe; Wed, 9 Feb 2011 12:15:50 +0100 (CET) Received: from zimbra.redpill-linpro.com (claudius.linpro.no [87.238.49.234]) by mailhub.linpro.no (Postfix) with ESMTP; Wed, 9 Feb 2011 12:15:50 +0100 (CET) Received: from localhost (localhost.localdomain [127.0.0.1]) by zimbra.redpill-linpro.com (Postfix) with ESMTP id D2865170C00C; Wed, 9 Feb 2011 12:15:50 +0100 (CET) X-Virus-Scanned: amavisd-new at claudius.linpro.no Received: from zimbra.redpill-linpro.com ([127.0.0.1]) by localhost (zimbra.redpill-linpro.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tg8vCGoNW3eM; Wed, 9 Feb 2011 12:15:50 +0100 (CET) Received: from envy.fud.no (stat.linpro.no [87.238.42.2]) by zimbra.redpill-linpro.com (Postfix) with ESMTPSA id 3388D170C00A; Wed, 9 Feb 2011 12:15:50 +0100 (CET) Message-ID: <4D527765.2080202@redpill-linpro.com> Date: Wed, 09 Feb 2011 12:15:49 +0100 From: Tore Anderson Organization: Redpill Linpro AS User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.13) Gecko/20101209 Fedora/3.1.7-0.35.b3pre.fc14 Thunderbird/3.1.7 MIME-Version: 1.0 To: Iljitsch van Beijnum Subject: Re: Source for ICMP on link-local-only interface? References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: 6man 6man X-BeenThere: ipv6@ietf.org 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: , X-List-Received-Date: Wed, 09 Feb 2011 11:15:51 -0000 * Iljitsch van Beijnum > The routing protocols use link locals, so they don't care. BGP cannot possibly resolve a link-local next-hop, can it? Best regards, -- Tore Anderson Redpill Linpro AS - http://www.redpill-linpro.com/ Tel: +47 21 54 41 27 From iljitsch@muada.com Wed Feb 9 03:30:36 2011 Return-Path: X-Original-To: ipv6@core3.amsl.com Delivered-To: ipv6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9F2653A698E for ; Wed, 9 Feb 2011 03:30:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ytlf5DguxMOc for ; Wed, 9 Feb 2011 03:30:36 -0800 (PST) Received: from sequoia.muada.com (unknown [IPv6:2001:1af8:2:5::2]) by core3.amsl.com (Postfix) with ESMTP id 7EB703A695E for ; Wed, 9 Feb 2011 03:30:35 -0800 (PST) Received: from claw.it.uc3m.es ([163.117.139.233]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id p19BU2AB015606 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 9 Feb 2011 12:30:03 +0100 (CET) (envelope-from iljitsch@muada.com) Subject: Re: Source for ICMP on link-local-only interface? Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Iljitsch van Beijnum In-Reply-To: <4D527765.2080202@redpill-linpro.com> Date: Wed, 9 Feb 2011 12:30:04 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4D527765.2080202@redpill-linpro.com> To: Tore Anderson X-Mailer: Apple Mail (2.1082) Cc: 6man 6man X-BeenThere: ipv6@ietf.org 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: , X-List-Received-Date: Wed, 09 Feb 2011 11:30:36 -0000 On 9 feb 2011, at 12:15, Tore Anderson wrote: >> The routing protocols use link locals, so they don't care. > BGP cannot possibly resolve a link-local next-hop, can it? Not sure what you mean. IPv6 BGP does in fact carry gloal and link local next hop addresses. Of course most people will want to configure BGP using a shared prefix = between the two routers because that's the easiest way to do it. But = using loopback addresses isn't unheard of, because that way you can load = balance across multiple interfaces without having to have a BGP session = for each interface.= From tore.anderson@redpill-linpro.com Wed Feb 9 03:40:24 2011 Return-Path: X-Original-To: ipv6@core3.amsl.com Delivered-To: ipv6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9E8C13A69A4 for ; Wed, 9 Feb 2011 03:40:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.548 X-Spam-Level: X-Spam-Status: No, score=-2.548 tagged_above=-999 required=5 tests=[AWL=0.051, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n9Y0WL-wqaGQ for ; Wed, 9 Feb 2011 03:40:23 -0800 (PST) Received: from mailhub.linpro.no (mailhub.linpro.no [87.238.49.141]) by core3.amsl.com (Postfix) with ESMTP id 1ADB73A699F for ; Wed, 9 Feb 2011 03:40:23 -0800 (PST) Received: from localhost (mailhub.linpro.no [87.238.49.141]) by mailhub.linpro.no (Postfix) with ESMTP id C50531DE536; Wed, 9 Feb 2011 12:40:31 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at mailhub.linpro.no Received: from mailhub.linpro.no ([87.238.49.141]) by localhost (mailhub.linpro.no [87.238.49.141]) (amavisd-new, port 10024) with ESMTP id uE1WhmUKz49i; Wed, 9 Feb 2011 12:40:23 +0100 (CET) Received: from zimbra.redpill-linpro.com (claudius.linpro.no [87.238.49.234]) by mailhub.linpro.no (Postfix) with ESMTP; Wed, 9 Feb 2011 12:40:23 +0100 (CET) Received: from localhost (localhost.localdomain [127.0.0.1]) by zimbra.redpill-linpro.com (Postfix) with ESMTP id D4854170C00C; Wed, 9 Feb 2011 12:40:23 +0100 (CET) X-Virus-Scanned: amavisd-new at claudius.linpro.no Received: from zimbra.redpill-linpro.com ([127.0.0.1]) by localhost (zimbra.redpill-linpro.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RwCZOM55qODs; Wed, 9 Feb 2011 12:40:23 +0100 (CET) Received: from envy.fud.no (stat.linpro.no [87.238.42.2]) by zimbra.redpill-linpro.com (Postfix) with ESMTPSA id 2D5E2170C00A; Wed, 9 Feb 2011 12:40:23 +0100 (CET) Message-ID: <4D527D26.4010500@redpill-linpro.com> Date: Wed, 09 Feb 2011 12:40:22 +0100 From: Tore Anderson Organization: Redpill Linpro AS User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.13) Gecko/20101209 Fedora/3.1.7-0.35.b3pre.fc14 Thunderbird/3.1.7 MIME-Version: 1.0 To: Iljitsch van Beijnum Subject: Re: Source for ICMP on link-local-only interface? References: <4D527765.2080202@redpill-linpro.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Cc: 6man 6man X-BeenThere: ipv6@ietf.org 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: , X-List-Received-Date: Wed, 09 Feb 2011 11:40:24 -0000 * Iljitsch van Beijnum > IPv6 BGP does in fact carry gloal and link local next hop addresses. Yes, but my point is that if you don't configure a global (at least non-link-local) prefix on the router interconnections, there's no global address that can be announced as the BGP next-hop. With no global address, the immediate link-local next-hop cannot be resolved in the IGP, and the route is discarded. Or am I missing something? For example, here's my BGP route to your e-mail domain. The key item here is «Protocol next hop: 2a02:228:81:100::», which is the remote router in the link-net to AS3292. If this link was numbered with link-local addresses only, I don't see how this route could possibly be used, unless you start mangling the BGP next-hop? tore@cr2> show route 2001:1af8:2:5::2 active-path extensive inet6.0: 4377 destinations, 8940 routes (4376 active, 0 holddown, 1 hidden) 2001:1af8::/32 (3 entries, 1 announced) TSI: KRT in-kernel 2001:1af8::/32 -> {indirect(1048574)} *BGP Preference: 170/-51 Next hop type: Indirect Next-hop reference count: 5286 Source: 2a02:c0:1000::2 Next hop type: Router, Next hop index: 614 Next hop: fe80::221:59ff:fe0e:9295 via xe-1/0/0.0, selected Protocol next hop: 2a02:228:81:100:: Indirect next hop: 11355ac8 1048574 State: Local AS: 39029 Peer AS: 39029 Age: 3:58:10 Metric: 20 Metric2: 2 MED-plus-IGP: 22 Task: BGP_39029.2a02:c0:1000::2+179 Announcement bits (2): 0-KRT 6-Resolve tree 4 AS path: 3292 16265 I AS path: Recorded Communities: 3292:1110 3292:24601 Accepted Localpref: 50 Router ID: 87.238.32.5 Indirect next hops: 1 Protocol next hop: 2a02:228:81:100:: Metric: 2 Indirect next hop: 11355ac8 1048574 Indirect path forwarding next hops: 1 Next hop type: Router Next hop: fe80::221:59ff:fe0e:9295 via xe-1/0/0.0 2a02:228:81:100::/127 Originating RIB: inet6.0 Metric: 2 Node path count: 1 Forwarding nexthops: 1 Nexthop: fe80::221:59ff:fe0e:9295 via xe-1/0/0.0 -- Tore Anderson Redpill Linpro AS - http://www.redpill-linpro.com/ Tel: +47 21 54 41 27 From mohacsi@niif.hu Wed Feb 9 03:46:13 2011 Return-Path: X-Original-To: ipv6@core3.amsl.com Delivered-To: ipv6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 91B5E3A697C for ; Wed, 9 Feb 2011 03:46:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.086 X-Spam-Level: X-Spam-Status: No, score=0.086 tagged_above=-999 required=5 tests=[AWL=0.090, BAYES_00=-2.599, HELO_EQ_HU=1.35, HOST_EQ_HU=1.245] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G1BEkj4qCfXX for ; Wed, 9 Feb 2011 03:46:12 -0800 (PST) Received: from mail.ki.iif.hu (mail.ki.iif.hu [IPv6:2001:738:0:411::241]) by core3.amsl.com (Postfix) with ESMTP id 57B6A3A694F for ; Wed, 9 Feb 2011 03:46:12 -0800 (PST) Received: from cirkusz.lvs.iif.hu (cirkusz.lvs.iif.hu [193.225.14.182]) by mail.ki.iif.hu (Postfix) with ESMTP id 2E29E8471F; Wed, 9 Feb 2011 12:46:20 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at cirkusz.lvs.iif.hu Received: from mail.ki.iif.hu ([IPv6:::ffff:193.6.222.241]) by cirkusz.lvs.iif.hu (cirkusz.lvs.iif.hu [::ffff:193.225.14.72]) (amavisd-new, port 10024) with ESMTP id JYPyIRyXSA0y; Wed, 9 Feb 2011 12:46:04 +0100 (CET) Received: by mail.ki.iif.hu (Postfix, from userid 9002) id AD20B86C16; Wed, 9 Feb 2011 12:46:04 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by mail.ki.iif.hu (Postfix) with ESMTP id AB4CE86C0F; Wed, 9 Feb 2011 12:46:04 +0100 (CET) Date: Wed, 9 Feb 2011 12:46:04 +0100 (CET) From: Mohacsi Janos X-X-Sender: mohacsi@mignon.ki.iif.hu To: Tore Anderson Subject: Re: Source for ICMP on link-local-only interface? In-Reply-To: <4D527D26.4010500@redpill-linpro.com> Message-ID: References: <4D527765.2080202@redpill-linpro.com> <4D527D26.4010500@redpill-linpro.com> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Iljitsch van Beijnum , 6man 6man X-BeenThere: ipv6@ietf.org 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: , X-List-Received-Date: Wed, 09 Feb 2011 11:46:13 -0000 On Wed, 9 Feb 2011, Tore Anderson wrote: > * Iljitsch van Beijnum > >> IPv6 BGP does in fact carry gloal and link local next hop addresses. > > Yes, but my point is that if you don't configure a global (at least > non-link-local) prefix on the router interconnections, there's no global > address that can be announced as the BGP next-hop. With no global > address, the immediate link-local next-hop cannot be resolved in the > IGP, and the route is discarded. Or am I missing something? > > For example, here's my BGP route to your e-mail domain. The key item > here is ?Protocol next hop: 2a02:228:81:100::?, which is the remote > router in the link-net to AS3292. If this link was numbered with > link-local addresses only, I don't see how this route could possibly be > used, unless you start mangling the BGP next-hop? > With C vendor there is a built in knob for mangling next-hop. In this case I don't like the idea of BGP with link-local: http://www.cisco.com/en/US/docs/ios/ipv6/configuration/guide/ip6-mptcl_bgp.html#wp1037072 > -- > Tore Anderson > Redpill Linpro AS - http://www.redpill-linpro.com/ > Tel: +47 21 54 41 27 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > From iljitsch@muada.com Wed Feb 9 03:46:41 2011 Return-Path: X-Original-To: ipv6@core3.amsl.com Delivered-To: ipv6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2E47D3A695E for ; Wed, 9 Feb 2011 03:46:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eq2VDQ4glLio for ; Wed, 9 Feb 2011 03:46:40 -0800 (PST) Received: from sequoia.muada.com (unknown [IPv6:2001:1af8:2:5::2]) by core3.amsl.com (Postfix) with ESMTP id BECE73A69AA for ; Wed, 9 Feb 2011 03:46:33 -0800 (PST) Received: from [IPv6:2001:720:410:100f:223:32ff:fec4:ba94] ([IPv6:2001:720:410:100f:223:32ff:fec4:ba94]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id p19Bk4mV015732 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 9 Feb 2011 12:46:04 +0100 (CET) (envelope-from iljitsch@muada.com) Subject: Re: Source for ICMP on link-local-only interface? Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Iljitsch van Beijnum In-Reply-To: <4D527D26.4010500@redpill-linpro.com> Date: Wed, 9 Feb 2011 12:46:40 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <700D0AE5-7236-4F76-A20A-B39FE0F93E7C@muada.com> References: <4D527765.2080202@redpill-linpro.com> <4D527D26.4010500@redpill-linpro.com> To: Tore Anderson X-Mailer: Apple Mail (2.1082) Cc: 6man 6man X-BeenThere: ipv6@ietf.org 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: , X-List-Received-Date: Wed, 09 Feb 2011 11:46:41 -0000 On 9 feb 2011, at 12:40, Tore Anderson wrote: >> IPv6 BGP does in fact carry gloal and link local next hop addresses. >=20 > Yes, but my point is that if you don't configure a global (at least > non-link-local) prefix on the router interconnections, there's no = global > address that can be announced as the BGP next-hop. With no global > address, the immediate link-local next-hop cannot be resolved in the > IGP, and the route is discarded. Or am I missing something? Right. Of course I was speaking about protocols like OSPF, which require that = the routers to share a prefix for them to find each other with IPv4, but = with IPv6 they don't because the routers communicate using link-locals. I'm not sure if BGP implementations reject link locals as the mail BGP = next hop address, or if they are smart enough to know that it can work = across one hop but not more than one. It's still possible to make = everything work by rewriting the next hop address (such as configuring = next-hop-self). One situation where this could be useful is if you want = to avoid providing a DoS target by running BGP over unroutable address = space.= From pekkas@netcore.fi Wed Feb 9 04:12:35 2011 Return-Path: X-Original-To: ipv6@core3.amsl.com Delivered-To: ipv6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 40EC43A69A4 for ; Wed, 9 Feb 2011 04:12:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PcobCO+1LwYt for ; Wed, 9 Feb 2011 04:12:34 -0800 (PST) Received: from netcore.fi (eunet-gw.ipv6.netcore.fi [IPv6:2001:670:86:3001::1]) by core3.amsl.com (Postfix) with ESMTP id 26BAC3A6984 for ; Wed, 9 Feb 2011 04:12:33 -0800 (PST) Received: from netcore.fi (localhost [127.0.0.1]) by netcore.fi (8.13.8/8.13.8) with ESMTP id p19CCZuL017547 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 9 Feb 2011 14:12:35 +0200 Received: from localhost (pekkas@localhost) by netcore.fi (8.13.8/8.13.8/Submit) with ESMTP id p19CCZn2017544; Wed, 9 Feb 2011 14:12:35 +0200 Date: Wed, 9 Feb 2011 14:12:35 +0200 (EET) From: Pekka Savola To: Tore Anderson Subject: Re: Source for ICMP on link-local-only interface? In-Reply-To: <4D527D26.4010500@redpill-linpro.com> Message-ID: References: <4D527765.2080202@redpill-linpro.com> <4D527D26.4010500@redpill-linpro.com> User-Agent: Alpine 2.02 (LRH 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: clamav-milter 0.96.5 at otso.netcore.fi X-Virus-Status: Clean Cc: Iljitsch van Beijnum , 6man 6man X-BeenThere: ipv6@ietf.org 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: , X-List-Received-Date: Wed, 09 Feb 2011 12:12:35 -0000 On Wed, 9 Feb 2011, Tore Anderson wrote: > Yes, but my point is that if you don't configure a global (at least > non-link-local) prefix on the router interconnections, there's no global > address that can be announced as the BGP next-hop. With no global > address, the immediate link-local next-hop cannot be resolved in the > IGP, and the route is discarded. Or am I missing something? FWIW, not that it would address your issue -- but about 9 years ago there existed draft-kato-bgp-ipv6-link-local-00, which proposed some mods to BGP in Section 3. I vaguely recall that at least Juniper claims to support this. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From simon.perreault@viagenie.ca Wed Feb 9 06:25:20 2011 Return-Path: X-Original-To: ipv6@core3.amsl.com Delivered-To: ipv6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A596D3A69CA for ; Wed, 9 Feb 2011 06:25:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WnafjhfihkE0 for ; Wed, 9 Feb 2011 06:25:19 -0800 (PST) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by core3.amsl.com (Postfix) with ESMTP id 77D063A69C2 for ; Wed, 9 Feb 2011 06:25:19 -0800 (PST) Received: from ringo.viagenie.ca (ringo.viagenie.ca [206.123.31.67]) by jazz.viagenie.ca (Postfix) with ESMTPSA id E088B20F55; Wed, 9 Feb 2011 09:25:27 -0500 (EST) Message-ID: <4D52A3D7.8050005@viagenie.ca> Date: Wed, 09 Feb 2011 09:25:27 -0500 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.13) Gecko/20101209 Fedora/3.1.7-0.35.b3pre.fc14 Thunderbird/3.1.7 MIME-Version: 1.0 To: Tore Anderson Subject: Re: Source for ICMP on link-local-only interface? References: <4D527765.2080202@redpill-linpro.com> In-Reply-To: <4D527765.2080202@redpill-linpro.com> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Iljitsch van Beijnum , 6man 6man X-BeenThere: ipv6@ietf.org 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: , X-List-Received-Date: Wed, 09 Feb 2011 14:25:20 -0000 On 2011-02-09 06:15, Tore Anderson wrote: > BGP cannot possibly resolve a link-local next-hop, can it? Here's how to do it on Cisco: http://www.cisco.com/en/US/docs/ios/ipv6/configuration/guide/ip6-mptcl_bgp.html#wp1037072 It's "officially approved". ;) Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From Francis.Dupont@fdupont.fr Wed Feb 9 09:14:53 2011 Return-Path: X-Original-To: ipv6@core3.amsl.com Delivered-To: ipv6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5A0C93A67EE for ; Wed, 9 Feb 2011 09:14:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w6zv6GXfM19z for ; Wed, 9 Feb 2011 09:14:52 -0800 (PST) Received: from givry.fdupont.fr (givry.fdupont.fr [91.121.26.85]) by core3.amsl.com (Postfix) with ESMTP id 5F3DD3A67C2 for ; Wed, 9 Feb 2011 09:14:52 -0800 (PST) Received: from givry.fdupont.fr (localhost [127.0.0.1]) by givry.fdupont.fr (8.14.3/8.14.3) with ESMTP id p19HF0Qq094875; Wed, 9 Feb 2011 18:15:01 +0100 (CET) (envelope-from dupont@givry.fdupont.fr) Message-Id: <201102091715.p19HF0Qq094875@givry.fdupont.fr> From: Francis Dupont To: Tore Anderson Subject: Re: Source for ICMP on link-local-only interface? In-reply-to: Your message of Wed, 09 Feb 2011 12:15:49 +0100. <4D527765.2080202@redpill-linpro.com> Date: Wed, 09 Feb 2011 18:15:00 +0100 Sender: Francis.Dupont@fdupont.fr Cc: Iljitsch van Beijnum , 6man 6man X-BeenThere: ipv6@ietf.org 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: , X-List-Received-Date: Wed, 09 Feb 2011 17:14:53 -0000 In your previous mail you wrote: * Iljitsch van Beijnum > The routing protocols use link locals, so they don't care. BGP cannot possibly resolve a link-local next-hop, can it? => the issue was addressed years ago but this carefully wording: The link-local address shall be included in the Next Hop field if and only if the BGP speaker shares a common subnet with the entity identified by the global IPv6 address carried in the Network Address of Next Hop field and the peer the route is being advertised to. Regards Francis.Dupont@fdupont.fr PS: this happened in the early days of both BGP v4 and IPv6: the issue was considered to be hairy and particular to IPv6 so we asked for a dedicated document which was published later as the RFC 2545. PPS: if you like it, please ask for a promotion to the Draft Standard status... From Internet-Drafts@ietf.org Wed Feb 9 12:30:02 2011 Return-Path: X-Original-To: ipv6@core3.amsl.com Delivered-To: ipv6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 243D83A67FA; Wed, 9 Feb 2011 12:30:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.535 X-Spam-Level: X-Spam-Status: No, score=-102.535 tagged_above=-999 required=5 tests=[AWL=0.064, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yspJE4ex3oM5; Wed, 9 Feb 2011 12:30:01 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 79A803A67E3; Wed, 9 Feb 2011 12:30:01 -0800 (PST) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Subject: I-D Action:draft-ietf-6man-flow-ecmp-01.txt X-Test-IDTracker: no X-IETF-IDTracker: 3.12 Message-ID: <20110209203001.4502.59832.idtracker@localhost> Date: Wed, 09 Feb 2011 12:30:01 -0800 Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org 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: , X-List-Received-Date: Wed, 09 Feb 2011 20:30:02 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPv6 Maintenance Working Group of the IETF. Title : Using the IPv6 flow label for equal cost multipath routing and link aggregation in tunnels Author(s) : B. Carpenter, S. Amante Filename : draft-ietf-6man-flow-ecmp-01.txt Pages : 10 Date : 2011-02-09 The IPv6 flow label has certain restrictions on its use. This document describes how those restrictions apply when using the flow label for load balancing by equal cost multipath routing, and for link aggregation, particularly for IP-in-IPv6 tunneled traffic. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-6man-flow-ecmp-01.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-6man-flow-ecmp-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-02-09121847.I-D@ietf.org> --NextPart-- From brian.e.carpenter@gmail.com Wed Feb 9 12:42:42 2011 Return-Path: X-Original-To: ipv6@core3.amsl.com Delivered-To: ipv6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 245BA3A67AE for ; Wed, 9 Feb 2011 12:42:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.59 X-Spam-Level: X-Spam-Status: No, score=-103.59 tagged_above=-999 required=5 tests=[AWL=0.009, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B5QTw99O7a9i for ; Wed, 9 Feb 2011 12:42:40 -0800 (PST) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id EA1003A67AA for ; Wed, 9 Feb 2011 12:42:39 -0800 (PST) Received: by fxm9 with SMTP id 9so645573fxm.31 for ; Wed, 09 Feb 2011 12:42:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:organization:user-agent :mime-version:to:subject:content-type:content-transfer-encoding; bh=93cjM2RVoflLHB+KfCJKYa1SE0Ztya37sU2f/tJKhts=; b=YgQjPD6y5dL/kt0pXqI3Bn0Mowk6TacCXH4rcYIOhS1XBA1xTz6CE8ybUMA857gfgB 0RS5uFuIn1bolRTYwEhGWIFEHvgOSCKkCFHu3OkBPGJBLq6NR+kpElj9x0Vxd+GsbpIQ uz0+/XdUgpbwS0HDq7knjVecBMylNFMyaebHY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to :subject:content-type:content-transfer-encoding; b=tNarMClT4djOMfeoxYHj2dyDzC7AqEnPcTKOa1QevRUHlsrhGePgxTA9tXUlIBzyp/ VK8/VCmaz56XlRolZ0Lg3C4BdTmcZ9QI8Slf9s5eylp8UARdATaO1FJveFM8h3R/4TtN iNNyO+3WzVJ9a9pFK/asP8zfLlbBvFYMxZ3FA= Received: by 10.223.112.1 with SMTP id u1mr6981466fap.109.1297284167979; Wed, 09 Feb 2011 12:42:47 -0800 (PST) Received: from [130.216.38.124] (stf-brian.sfac.auckland.ac.nz [130.216.38.124]) by mx.google.com with ESMTPS id 11sm373897faw.20.2011.02.09.12.42.45 (version=SSLv3 cipher=RC4-MD5); Wed, 09 Feb 2011 12:42:47 -0800 (PST) Message-ID: <4D52FC43.90203@gmail.com> Date: Thu, 10 Feb 2011 09:42:43 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: 6man Subject: [Fwd: I-D Action:draft-ietf-6man-flow-ecmp-01.txt] Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-BeenThere: ipv6@ietf.org 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: , X-List-Received-Date: Wed, 09 Feb 2011 20:42:42 -0000 Hi, This version is intended to respond to the comments made during WG Last Call. Brian + Shane -------- Original Message -------- Subject: I-D Action:draft-ietf-6man-flow-ecmp-01.txt Date: Wed, 09 Feb 2011 12:30:01 -0800 From: Internet-Drafts@ietf.org Reply-To: internet-drafts@ietf.org To: i-d-announce@ietf.org CC: ipv6@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPv6 Maintenance Working Group of the IETF. Title : Using the IPv6 flow label for equal cost multipath routing and link aggregation in tunnels Author(s) : B. Carpenter, S. Amante Filename : draft-ietf-6man-flow-ecmp-01.txt Pages : 10 Date : 2011-02-09 The IPv6 flow label has certain restrictions on its use. This document describes how those restrictions apply when using the flow label for load balancing by equal cost multipath routing, and for link aggregation, particularly for IP-in-IPv6 tunneled traffic. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-6man-flow-ecmp-01.txt From brian.e.carpenter@gmail.com Wed Feb 9 16:21:18 2011 Return-Path: X-Original-To: ipv6@core3.amsl.com Delivered-To: ipv6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7E6EC3A67F3 for ; Wed, 9 Feb 2011 16:21:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.071 X-Spam-Level: X-Spam-Status: No, score=-103.071 tagged_above=-999 required=5 tests=[AWL=-0.472, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u01W4jVCqADI for ; Wed, 9 Feb 2011 16:21:17 -0800 (PST) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by core3.amsl.com (Postfix) with ESMTP id 788E03A67AD for ; Wed, 9 Feb 2011 16:21:17 -0800 (PST) Received: by vxi40 with SMTP id 40so406519vxi.31 for ; Wed, 09 Feb 2011 16:21:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:organization:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=yzXWTk48Vr5BVBhep4gEOt5wXqkgS8Bx30vEAXY/8Tg=; b=D3EzgDDBygzI4EQ0uY0MpwBejTCn3mSPulQ6PgHZhPO+M3zXSwyJrQ5ujXkkK469aZ FW1JEvnBZUkITdIo/hGTHRon0WID0Gbs6JdKal2q7Vc6gBFKLBq+2ot0+6qMWaG9pu4u FJ9xxYVCOfl8m5vRKuq1sJPtY/2PgSRhXv3X4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; b=dQ8BWRMRaF/Jv2tP0FDMawww6lqsuL2XRwyPNgB5Evkv98h2IukYrvDJqrv4To0cXw I9DTw7Prk/c6YyDuHw8R48gqck7rYEj8J8ZKknYM6cFwkF++K+gFwpIDySBKFHYQ/4xw 3cSVxogBe4oJjEmdufPUGzpic3R/86zSBYaoU= Received: by 10.220.177.5 with SMTP id bg5mr1319333vcb.14.1297297287464; Wed, 09 Feb 2011 16:21:27 -0800 (PST) Received: from [130.216.38.124] (stf-brian.sfac.auckland.ac.nz [130.216.38.124]) by mx.google.com with ESMTPS id o13sm356731vch.40.2011.02.09.16.21.25 (version=SSLv3 cipher=RC4-MD5); Wed, 09 Feb 2011 16:21:26 -0800 (PST) Message-ID: <4D532F7F.7060408@gmail.com> Date: Thu, 10 Feb 2011 13:21:19 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Lucy yong Subject: Re: [Fwd: I-D Action:draft-ietf-6man-flow-ecmp-01.txt] References: <4D52FC43.90203@gmail.com> <2691CE0099834E4A9C5044EEC662BB9D2A08BF@DFWEML501-MBX.china.huawei.com> In-Reply-To: <2691CE0099834E4A9C5044EEC662BB9D2A08BF@DFWEML501-MBX.china.huawei.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: 6man X-BeenThere: ipv6@ietf.org 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: , X-List-Received-Date: Thu, 10 Feb 2011 00:21:18 -0000 On 2011-02-10 12:16, Lucy yong wrote: > Hi Brian, > > There is some conflict between these goals: for example, strictly > avoiding idle time could cause a small packet sent on an idle path to > overtake a bigger packet from the same flow, causing out-of-order > delivery. > > I don't understand this. Do you mean the small packet and a bigger packet takes different paths? Exactly, if the goal is to keep both paths busy, this could happen, > If they take the same path, it should not cause out-of-order delivery. Thus, the method must ensure that all packets from the same user flow do take the same path. brian > Thanks, > Lucy > > >> -----Original Message----- >> From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of >> Brian E Carpenter >> Sent: Wednesday, February 09, 2011 2:43 PM >> To: 6man >> Subject: [Fwd: I-D Action:draft-ietf-6man-flow-ecmp-01.txt] >> >> Hi, >> >> This version is intended to respond to the comments made during WG Last >> Call. >> >> Brian + Shane >> >> >> -------- Original Message -------- >> Subject: I-D Action:draft-ietf-6man-flow-ecmp-01.txt >> Date: Wed, 09 Feb 2011 12:30:01 -0800 >> From: Internet-Drafts@ietf.org >> Reply-To: internet-drafts@ietf.org >> To: i-d-announce@ietf.org >> CC: ipv6@ietf.org >> >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> This draft is a work item of the IPv6 Maintenance Working Group of the >> IETF. >> >> >> Title : Using the IPv6 flow label for equal cost multipath >> routing and link aggregation in tunnels >> Author(s) : B. Carpenter, S. Amante >> Filename : draft-ietf-6man-flow-ecmp-01.txt >> Pages : 10 >> Date : 2011-02-09 >> >> The IPv6 flow label has certain restrictions on its use. This >> document describes how those restrictions apply when using the flow >> label for load balancing by equal cost multipath routing, and for >> link aggregation, particularly for IP-in-IPv6 tunneled traffic. >> >> A URL for this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-ietf-6man-flow-ecmp-01.txt >> >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list >> ipv6@ietf.org >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- > From scott.brim@gmail.com Tue Feb 15 11:00:18 2011 Return-Path: X-Original-To: ipv6@core3.amsl.com Delivered-To: ipv6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D017D3A6D4B; Tue, 15 Feb 2011 11:00:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.598 X-Spam-Level: X-Spam-Status: No, score=-103.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x1aMZX0pCjpr; Tue, 15 Feb 2011 11:00:17 -0800 (PST) Received: from mail-px0-f172.google.com (mail-px0-f172.google.com [209.85.212.172]) by core3.amsl.com (Postfix) with ESMTP id BE6663A6CA2; Tue, 15 Feb 2011 11:00:17 -0800 (PST) Received: by pxi6 with SMTP id 6so87947pxi.31 for ; Tue, 15 Feb 2011 11:00:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:date:message-id:subject:from:to :content-type; bh=gBFgXBNekflplCNCYTkVyRcagylyeALWZDRecRrQO6Y=; b=cyGhCQeaTz+8WT/MAhuwUDucF9ATrg2qQAPqPv7IccktR5n5ATqUwFnL7u0nq3fY90 IesdMrfylEPhciTDv24/tr728Q9zpDk6fA5801KyQ/z+KVOdFyQL3FZAaA4adU07ZX9N kzXUPLR5sW+YjZBLQ00pLVmWKZfveXvbE82OM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=YkIGMTxIgHPExtv0T9H2atN51Bze6D67oLd5+ffzg5awOKohs9vn9tjyyo8p1mBtAR +TsO+P+gc5BCaMq/sZYs09jNmAb0EPX4OHS7wUxufEf55EZzmo3owLgM6TUD6eY1duz5 2IReFcq3hBIo0TikjRTgGanynQBhJDbvyoK7A= MIME-Version: 1.0 Received: by 10.142.232.19 with SMTP id e19mr4439087wfh.48.1297796443651; Tue, 15 Feb 2011 11:00:43 -0800 (PST) Received: by 10.142.188.12 with HTTP; Tue, 15 Feb 2011 11:00:43 -0800 (PST) Date: Tue, 15 Feb 2011 14:00:43 -0500 Message-ID: Subject: gen-art review of draft-ietf-6man-prefixlen-p2p-01 From: Scott W Brim To: gen-art , draft-ietf-6man-prefixlen-p2p , ipv6 Content-Type: multipart/alternative; boundary=000e0cd29daa03c06c049c56c8c8 X-BeenThere: ipv6@ietf.org 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: , X-List-Received-Date: Tue, 15 Feb 2011 19:00:18 -0000 --000e0cd29daa03c06c049c56c8c8 Content-Type: text/plain; charset=ISO-8859-1 I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at . Please resolve these comments along with any other Last Call comments you may receive. Document: draft-ietf-6man-prefixlen-p2p Reviewer: Scott Brim Review Date: 15 Feb 2011 IETF LC End Date: 17 Feb 2011 IESG Telechat date: Summary: This document is ready for publication as a Standards Track RFC Major issues: None Minor issues: Note Lars's comment on SHOULD -> MUST in Section 6. Nits/editorial comments: Well done. --000e0cd29daa03c06c049c56c8c8 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at
<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq&= gt;.

Please resolve these comments along with any other Last Call comments
you may receive.

Document: draft-ietf-6man-prefixlen-p2p
Reviewer: Scott Brim
Review Date: =A0 =A0 =A0=A0 15 Feb 2011
IETF LC End Date: =A0 17 Feb 2011
IESG Telechat date:

Summary: This document is ready for publication as a Standards Track RFC
Major issues: None

Minor issues: Note Lars's comment on SHOULD -> MUST in Section 6.
Nits/editorial comments: Well done.

--000e0cd29daa03c06c049c56c8c8-- From pekkas@netcore.fi Fri Feb 18 00:54:59 2011 Return-Path: X-Original-To: ipv6@core3.amsl.com Delivered-To: ipv6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 67A7A3A6EEC for ; Fri, 18 Feb 2011 00:54:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.589 X-Spam-Level: X-Spam-Status: No, score=-102.589 tagged_above=-999 required=5 tests=[AWL=0.010, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3R27xQ6o6iwP for ; Fri, 18 Feb 2011 00:54:58 -0800 (PST) Received: from netcore.fi (eunet-gw.ipv6.netcore.fi [IPv6:2001:670:86:3001::1]) by core3.amsl.com (Postfix) with ESMTP id 7E8553A6ECD for ; Fri, 18 Feb 2011 00:54:57 -0800 (PST) Received: from netcore.fi (localhost [127.0.0.1]) by netcore.fi (8.13.8/8.13.8) with ESMTP id p1I8tJJl004006 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 18 Feb 2011 10:55:19 +0200 Received: from localhost (pekkas@localhost) by netcore.fi (8.13.8/8.13.8/Submit) with ESMTP id p1I8tIsZ003999; Fri, 18 Feb 2011 10:55:19 +0200 Date: Fri, 18 Feb 2011 10:55:18 +0200 (EET) From: Pekka Savola To: Thomas Narten Subject: Re: 6MAN WG Last Call: In-Reply-To: <201101171932.p0HJWU58003756@cichlid.raleigh.ibm.com> Message-ID: References: <7B63F7B6-D788-4A05-9722-C1CAAA42B754@gmail.com> <201101171932.p0HJWU58003756@cichlid.raleigh.ibm.com> User-Agent: Alpine 2.02 (LRH 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: clamav-milter 0.96.5 at otso.netcore.fi X-Virus-Status: Clean Cc: 6man Mailing List X-BeenThere: ipv6@ietf.org 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: , X-List-Received-Date: Fri, 18 Feb 2011 08:54:59 -0000 On Mon, 17 Jan 2011, Thomas Narten wrote: >> This message starts a 6MAN Working Group Last Call on advancing: > >> Title : IPv6 Node Requirements RFC 4294-bis >> Author(s) : E. Jankiewicz, et al. >> Filename : draft-ietf-6man-node-req-bis-07.txt >> Pages : 26 >> Date : 2010-12-16 >> >> http://tools.ietf.org/html/draft-ietf-6man-node-req-bis-07 > >> as an Informational RFC. Substantive comments and statements of >> support for advancing this document should be directed to the >> mailing list. Editorial suggestions can be sent to the authors. >> This last call will end on January 6, 2011. I have reviewed this document. The most important omission is that RFC4294 changelog is not up-to-date. This gives a good overview on what has changed and it needs to convey accurate information. At the same time, I'd also add (or check from WG) if some of the RFCs not listed should be included. Some requirement levels have also changed, and explicit support from WG would be good on these. With an updated RFC4294 changelog, rough consensus on the result could be evaluated. I think a brief WGLC should be warranted after document update. The document should be IETF last called. WG should explicitly request feedback from at least IPSECME WG. substantial ----------- General: Section 21 describes Changes from RFC 4294. This is not up-to-date. Specifically, at least S 17-20 describe changes between draft versions that are not incorporated in S 21. As "changes between drafts" sections are removed upon publication, it is important that the changes from the previous RFC are complete. The updated RFC references are of medium importance (there are significant changes e.g. in the requirements imposed by ICMP specification versons), but changes in requirement level seem like a high importance issue. As such the former could be addressed with a short list. This is a very important section for a document like this as just by looking at it you should be able to see the major new requirements or changes in requirements. Therefore, updating this should be the first priority. Then I would suggest another Last Call, just to make sure there's rough consensus on these higher level bits. Specific not in text: --------------------- I think this document should also discuss APIs we have defined and that relate to the protocols described in the document. A separate section should be added on this. Specifically I'm thinking of the following: - RFC5014 (IPv6 Socket API for Source Address Selection) - a MAY? - RFC4584 (Extension to Sockets API for Mobile IPv6) - a MAY, or not listed - RFC3678 (Socket Interface Extensions for Multicast Source Filters) - SHOULD - RFC3542 (Advanced Sockets Application Program Interface (API) for IPv6) - SHOULD - RFC3493 (Basic Socket Interface Extensions for IPv6) - SHOULD/MUST RFC4191 (Default Router Preferences and More-Specific Routes) should be discussed. Is this a MAY? Quite a few host implementations already support it. In the context of autoconfiguration, RFC5453 (Reserved IPv6 Interface Identifiers) should probably be discussed. My quick (re-)read of it seems to say that every host should avoid the designated IIDs. Is host support needed for this? Should Node Information Queries be mentioned (RFC4620)? It would be a MAY. I'm fine with leaving it out. S 5.8.2 could refer to RFC4429 (Optimistic DAD) with a MAY support. The document is silent on Flow Label (as Brian mentioned). Rather than silence, I might be tempted to say something at least from the current perspective. The key point here is, "are hosts expected to randomize or otherwise by default set a flow label"? Specific on text: ----------------- S 5.2 no longer requires support for DAD but this is actually done in S 5.8.2. A pointer might be helpful (though not necessary). Text on redirects is also new, but probably not very controversial. S 5.5.1 does not make any (uppercase) recommendation on PMTUD like the previous version did, just quoting RFC2460. Suggest substituting the first line with: "Path MTU Discovery [RFC1981] SHOULD be Supported. From [RFC2460]:" S 5.8.3 has watered down the privacy addresses text: In such situations, RFC4941 SHOULD be implemented. In other cases, such as with dedicated servers in a data center, RFC4941 provides limited or no benefit. .. this is not acceptable. Per previous RFC, we should say: RFC4941 SHOULD be supported. We could also add (or make specific recommendations): This document does not make a generic recommendation on the default behaviour. I note that previous version of the doc also suggested privacy be configurable on per-connection basis, etc. -- this text has been removed now. (I did not dig deeper whether it has been incorporated in RFC4941 revisions etc.) In S 5.9, A reference should be added (MAY support) to RFC 5790, "Lightweight Internet Group Management Protocol Version 3 (IGMPv3) and Multicast Listener Discovery Version 2 (MLDv2) Protocols" In S 7.3: Implementations SHOULD implement the DNS RA option [RFC6106]. .. is this too strong? DHCP is (only) a conditional SHOULD. I'm OK with this as it is, but I would also be fine with a MAY. In S 10, Certain Mobile IP-specific SHOULDs have been downgraded to a general MAY. I'm fine with this but I would have been OK with retaining those specific SHOULDs. In S 11, IPsec and IKE have been downgraded to a SHOULD. I'm fine with this. (None of the changes I've mentioned are listed in the changelog.) editorial: ---------- - Transmission of IPv6 over IPv4 Domains without Explicit Tunnels [RFC2529] ... even as an example, this is a bad one. It is not used and there exists probably about one implementation. I suggest replacing this with RFC4213 (an existing reference). 5.9. Multicast Listener Discovery (MLD) for IPv6 - RFC 2710 .. take out the RFC number from the title as you're actually addressing two different MLD versions in this subsection. The following two MIBs SHOULD be supported by nodes that support an SNMP agent. .. s/MIBs/MIB modules/ :P -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From john@jlc.net Fri Feb 18 06:42:31 2011 Return-Path: X-Original-To: ipv6@core3.amsl.com Delivered-To: ipv6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A6BF83A6F12 for ; Fri, 18 Feb 2011 06:42:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.81 X-Spam-Level: X-Spam-Status: No, score=-106.81 tagged_above=-999 required=5 tests=[AWL=-0.211, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aIgBoYAnBxdA for ; Fri, 18 Feb 2011 06:42:31 -0800 (PST) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by core3.amsl.com (Postfix) with ESMTP id D7F543A6DC6 for ; Fri, 18 Feb 2011 06:42:30 -0800 (PST) Received: by mailhost.jlc.net (Postfix, from userid 104) id 74F8733C34; Fri, 18 Feb 2011 09:42:44 -0500 (EST) Date: Fri, 18 Feb 2011 09:42:44 -0500 From: John Leslie To: 6man Mailing List Subject: Re: 6MAN WG Last Call: Message-ID: <20110218144244.GA15397@verdi> References: <7B63F7B6-D788-4A05-9722-C1CAAA42B754@gmail.com> <201101171932.p0HJWU58003756@cichlid.raleigh.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i X-BeenThere: ipv6@ietf.org 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: , X-List-Received-Date: Fri, 18 Feb 2011 14:42:31 -0000 Pekka Savola wrote: > On Mon, 17 Jan 2011, Thomas Narten wrote: >>>This message starts a 6MAN Working Group Last Call on advancing: >> >>> Title : IPv6 Node Requirements RFC 4294-bis >>> Author(s) : E. Jankiewicz, et al. >>> Filename : draft-ietf-6man-node-req-bis-07.txt > > I have reviewed this document. > > The most important omission is that RFC4294 changelog is not up-to-date. > This gives a good overview on what has changed and it needs to convey > accurate information. Comparing bis-07 to RFC 4294, the number of changes begins to boggle... I strongly concur with Pekka that this document needs a single "changes from 4294" section. And, seeing as 4294 will be five years old by the time 4294-bis is published, I'd suggest adding to that section a note on where to look for "pending" changes over the next five years. ;^) (BTW, I remain confused on what happened to 5.2.1 of 4294 "Managed Address Configuration". Hopefully that will become clearer with a single "changes since 4294" section.) (I suppose this means I volunteer to help draft such a section, but to tell truth I'm not sure where to start!) -- John Leslie From narten@us.ibm.com Fri Feb 18 09:46:52 2011 Return-Path: X-Original-To: ipv6@core3.amsl.com Delivered-To: ipv6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BBBC13A6DAD for ; Fri, 18 Feb 2011 09:46:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IzQOaEYqlS8z for ; Fri, 18 Feb 2011 09:46:52 -0800 (PST) Received: from e7.ny.us.ibm.com (e7.ny.us.ibm.com [32.97.182.137]) by core3.amsl.com (Postfix) with ESMTP id DFD533A6CF3 for ; Fri, 18 Feb 2011 09:46:51 -0800 (PST) Received: from d01dlp01.pok.ibm.com (d01dlp01.pok.ibm.com [9.56.224.56]) by e7.ny.us.ibm.com (8.14.4/8.13.1) with ESMTP id p1IGlN0E005008 for ; Fri, 18 Feb 2011 11:48:53 -0500 Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234]) by d01dlp01.pok.ibm.com (Postfix) with ESMTP id 7B31038CB760 for ; Fri, 18 Feb 2011 10:38:02 -0500 (EST) Received: from d03av06.boulder.ibm.com (d03av06.boulder.ibm.com [9.17.195.245]) by d01relay02.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id p1IFaj2c353240 for ; Fri, 18 Feb 2011 10:36:46 -0500 Received: from d03av06.boulder.ibm.com (loopback [127.0.0.1]) by d03av06.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id p1IFfM5d021459 for ; Fri, 18 Feb 2011 08:41:22 -0700 Received: from cichlid.raleigh.ibm.com (sig-9-76-150-6.mts.ibm.com [9.76.150.6]) by d03av06.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id p1IFfL2h021426 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 18 Feb 2011 08:41:22 -0700 Received: from cichlid.raleigh.ibm.com (localhost.localdomain [127.0.0.1]) by cichlid.raleigh.ibm.com (8.14.4/8.12.5) with ESMTP id p1IFahUr026300; Fri, 18 Feb 2011 10:36:43 -0500 Message-Id: <201102181536.p1IFahUr026300@cichlid.raleigh.ibm.com> To: Pekka Savola Subject: Re: 6MAN WG Last Call: In-reply-to: References: <7B63F7B6-D788-4A05-9722-C1CAAA42B754@gmail.com> <201101171932.p0HJWU58003756@cichlid.raleigh.ibm.com> Comments: In-reply-to Pekka Savola message dated "Fri, 18 Feb 2011 10:55:18 +0200." Date: Fri, 18 Feb 2011 10:36:43 -0500 From: Thomas Narten X-Content-Scanned: Fidelis XPS MAILER Cc: 6man Mailing List X-BeenThere: ipv6@ietf.org 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: , X-List-Received-Date: Fri, 18 Feb 2011 17:46:52 -0000 Hi Pekka. Thanks for the review! Let me note that I agreee with a bunch of your comments. It is also the case that some of the changes you mention/questions have been discussed by the WG. I will respond in more detail and dig up pointers to the previous threads. The authors will take a pass at revising the document and respond to your comments in detail. Thanks again for the review! Thomas From brian.e.carpenter@gmail.com Fri Feb 18 11:33:12 2011 Return-Path: X-Original-To: ipv6@core3.amsl.com Delivered-To: ipv6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3228D3A6F05 for ; Fri, 18 Feb 2011 11:33:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.481 X-Spam-Level: X-Spam-Status: No, score=-103.481 tagged_above=-999 required=5 tests=[AWL=0.118, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id blvde0kVkDsc for ; Fri, 18 Feb 2011 11:33:11 -0800 (PST) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id 2F1503A6D16 for ; Fri, 18 Feb 2011 11:33:11 -0800 (PST) Received: by fxm15 with SMTP id 15so481263fxm.31 for ; Fri, 18 Feb 2011 11:33:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:organization:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=x8Po22VtZHa2NyM9vyV+2RnL/95vtfyZoRN8eQDYC/8=; b=QihgjC/1BcnTSbkv+/DZrIulzbqkhGECKEYJgKiL7scBOV9W/OijcfJcskWc80dcgl WeA7UMfs8Kztu9ARGgMMdhgV5ponFbMTNiIdBaDkWdDZCQUwSqTouYHUBBK6cAwBcAk9 AXxPqdEy1z4PWB85VaRAata645iSN5qJMYXuc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; b=BD1ZRX/o3DGo46QE+Os/rH1RY9DdhtnzhxZ7ekyCS5gW4NaueiF56QptdavXx9KURz jccsQ2ZoGKWY6hpGvjbm4o4Prpxwsou5ILjgVUyp4rJyPILXDjvxJBPC2HYItL8rHEAH 4893/b993tTqo76gAf70fx2RcMu1SohyIxA9Y= Received: by 10.223.48.194 with SMTP id s2mr15240faf.129.1298057578010; Fri, 18 Feb 2011 11:32:58 -0800 (PST) Received: from [10.1.1.4] ([121.98.190.33]) by mx.google.com with ESMTPS id y3sm1260946fai.38.2011.02.18.11.32.53 (version=SSLv3 cipher=OTHER); Fri, 18 Feb 2011 11:32:56 -0800 (PST) Message-ID: <4D5EC960.9080202@gmail.com> Date: Sat, 19 Feb 2011 08:32:48 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Pekka Savola Subject: Re: 6MAN WG Last Call: References: <7B63F7B6-D788-4A05-9722-C1CAAA42B754@gmail.com> <201101171932.p0HJWU58003756@cichlid.raleigh.ibm.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Thomas Narten , 6man Mailing List X-BeenThere: ipv6@ietf.org 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: , X-List-Received-Date: Fri, 18 Feb 2011 19:33:12 -0000 On 2011-02-18 21:55, Pekka Savola wrote: ... > > I think this document should also discuss APIs we have defined and that > relate to the protocols described in the document. A separate section > should be added on this. I'm not convinced. If the goal is to specify a working set of features to make a node interoperable on the wire, APIs are out of scope. ... > > The document is silent on Flow Label (as Brian mentioned). Rather than > silence, I might be tempted to say something at least from the current > perspective. The key point here is, "are hosts expected to randomize or > otherwise by default set a flow label"? Until we have settled on 3697bis, there is no answer to that question. I think it would be misleading to mention it. Brian From john.loughney@nokia.com Fri Feb 18 17:06:32 2011 Return-Path: X-Original-To: ipv6@core3.amsl.com Delivered-To: ipv6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5DE903A6EDA for ; Fri, 18 Feb 2011 17:06:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j7B6s0Pm-+Vl for ; Fri, 18 Feb 2011 17:06:31 -0800 (PST) Received: from mgw-da01.nokia.com (smtp.nokia.com [147.243.128.24]) by core3.amsl.com (Postfix) with ESMTP id 4B18E3A6D9C for ; Fri, 18 Feb 2011 17:06:31 -0800 (PST) Received: from vaebh106.NOE.Nokia.com (vaebh106.europe.nokia.com [10.160.244.32]) by mgw-da01.nokia.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id p1J170SN018413; Sat, 19 Feb 2011 03:07:01 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.8]) by vaebh106.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Sat, 19 Feb 2011 03:06:55 +0200 Received: from 008-AM1MMR1-001.mgdnok.nokia.com (65.54.30.56) by NOK-AM1MHUB-04.mgdnok.nokia.com (65.54.30.8) with Microsoft SMTP Server (TLS) id 8.2.255.0; Sat, 19 Feb 2011 02:06:55 +0100 Received: from 008-AM1MPN1-003.mgdnok.nokia.com ([169.254.3.47]) by 008-AM1MMR1-001.mgdnok.nokia.com ([65.54.30.56]) with mapi id 14.01.0270.002; Sat, 19 Feb 2011 02:06:54 +0100 From: To: , Subject: RE: 6MAN WG Last Call: Thread-Topic: 6MAN WG Last Call: Thread-Index: AQHLz0m/o6x1NYPu/EuuWf8RPYnxIJQHlegAgABuHLI= Date: Sat, 19 Feb 2011 01:06:53 +0000 Message-ID: <4qnQNBtvskfq@MttKmSdp> References: <7B63F7B6-D788-4A05-9722-C1CAAA42B754@gmail.com> <201101171932.p0HJWU58003756@cichlid.raleigh.ibm.com> , <4D5EC960.9080202@gmail.com> In-Reply-To: <4D5EC960.9080202@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 19 Feb 2011 01:06:55.0401 (UTC) FILETIME=[4CD01190:01CBCFD1] X-Nokia-AV: Clean Cc: narten@us.ibm.com, ipv6@ietf.org X-BeenThere: ipv6@ietf.org 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: , X-List-Received-Date: Sat, 19 Feb 2011 01:06:32 -0000 I agree with Brian on both points. -----Original Message----- From: ext Brian E Carpenter Sent: 02/18/2011, 11:34 AM To: Pekka Savola Cc: Thomas Narten; 6man Mailing List Subject: Re: 6MAN WG Last Call: On 2011-02-18 21:55, Pekka Savola wrote: ... > > I think this document should also discuss APIs we have defined and that > relate to the protocols described in the document. A separate section > should be added on this. I'm not convinced. If the goal is to specify a working set of features to make a node interoperable on the wire, APIs are out of scope. ... > > The document is silent on Flow Label (as Brian mentioned). Rather than > silence, I might be tempted to say something at least from the current > perspective. The key point here is, "are hosts expected to randomize or > otherwise by default set a flow label"? Until we have settled on 3697bis, there is no answer to that question. I think it would be misleading to mention it. Brian -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipng@69706e6720323030352d30312d31340a.nosense.org Fri Feb 18 17:44:08 2011 Return-Path: X-Original-To: ipv6@core3.amsl.com Delivered-To: ipv6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 898FD3A6D31 for ; Fri, 18 Feb 2011 17:44:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.895 X-Spam-Level: X-Spam-Status: No, score=-1.895 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QvmylSDyKd6y for ; Fri, 18 Feb 2011 17:44:07 -0800 (PST) Received: from smtp4.adam.net.au (smtp4.adam.net.au [202.136.110.247]) by core3.amsl.com (Postfix) with ESMTP id 404193A6C77 for ; Fri, 18 Feb 2011 17:44:07 -0800 (PST) Received: from 219-90-145-108.ip.adam.com.au ([219.90.145.108] helo=opy.nosense.org) by smtp4.adam.net.au with esmtp (Exim 4.63) (envelope-from ) id 1PqbsB-00056r-WC; Sat, 19 Feb 2011 12:14:36 +1030 Received: from opy.nosense.org (localhost.localdomain [IPv6:::1]) by opy.nosense.org (Postfix) with ESMTP id A8A883B337; Sat, 19 Feb 2011 12:14:33 +1030 (CST) Date: Sat, 19 Feb 2011 12:14:33 +1030 From: Mark Smith To: Pekka Savola Subject: Re: 6MAN WG Last Call: Message-ID: <20110219121433.490f3fe3@opy.nosense.org> In-Reply-To: References: <7B63F7B6-D788-4A05-9722-C1CAAA42B754@gmail.com> <201101171932.p0HJWU58003756@cichlid.raleigh.ibm.com> X-Mailer: Claws Mail 3.7.8 (GTK+ 2.22.1; x86_64-unknown-linux-gnu) X-Location: Lower Mitcham, South Australia, 5062 Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: Thomas Narten , 6man Mailing List X-BeenThere: ipv6@ietf.org 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: , X-List-Received-Date: Sat, 19 Feb 2011 01:44:08 -0000 On Fri, 18 Feb 2011 10:55:18 +0200 (EET) Pekka Savola wrote: > On Mon, 17 Jan 2011, Thomas Narten wrote: > >> This message starts a 6MAN Working Group Last Call on advancing: > > > >> Title : IPv6 Node Requirements RFC 4294-bis > >> Author(s) : E. Jankiewicz, et al. > >> Filename : draft-ietf-6man-node-req-bis-07.txt > >> Pages : 26 > >> Date : 2010-12-16 > >> > >> http://tools.ietf.org/html/draft-ietf-6man-node-req-bis-07 > > > >> as an Informational RFC. Substantive comments and statements of > >> support for advancing this document should be directed to the > >> mailing list. Editorial suggestions can be sent to the authors. > >> This last call will end on January 6, 2011. > > > RFC4191 (Default Router Preferences and More-Specific Routes) should be > discussed. Is this a MAY? Quite a few host implementations already support > it. > I think this should be a MUST, or at least a SHOULD, as the simple CPE draft relies on this capability to support routing between internal subnets if the WAN link is down - http://tools.ietf.org/html/draft-ietf-v6ops-ipv6-cpe-router-09 G-5: By default if the IPv6 CE router is an advertising router and loses its IPv6 default router(s) on the WAN interface, it MUST explicitly invalidate itself as an IPv6 default router on each of its advertising interfaces by immediately transmitting one or more Router Advertisement messages with the "Router Lifetime" field set to zero [RFC4861]. and L-3: An IPv6 CE router MUST advertise itself as a router for the delegated prefix(es) (and ULA prefix if configured to provide ULA addressing) using the "Route Information Option" specified in section 2.3 of [RFC4191]. This advertisement is independent of having IPv6 connectivity on the WAN interface or not. Regards, Mark. From jhw@apple.com Fri Feb 18 18:09:57 2011 Return-Path: X-Original-To: ipv6@core3.amsl.com Delivered-To: ipv6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4225E3A6CA1 for ; Fri, 18 Feb 2011 18:09:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0MGa5hz6yBOo for ; Fri, 18 Feb 2011 18:09:56 -0800 (PST) Received: from mail-out3.apple.com (mail-out.apple.com [17.254.13.22]) by core3.amsl.com (Postfix) with ESMTP id 88F213A6D6D for ; Fri, 18 Feb 2011 18:09:56 -0800 (PST) Received: from relay16.apple.com (relay16.apple.com [17.128.113.55]) by mail-out3.apple.com (Postfix) with ESMTP id ABD03D04AC19 for ; Fri, 18 Feb 2011 18:10:31 -0800 (PST) X-AuditID: 11807137-b7baaae000007a67-de-4d5f2697d531 Received: from et.apple.com (et.apple.com [17.151.62.12]) by relay16.apple.com (Apple SCV relay) with SMTP id 87.03.31335.7962F5D4; Fri, 18 Feb 2011 18:10:31 -0800 (PST) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=us-ascii Received: from [10.5.254.151] ([72.254.56.197]) by et.apple.com (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008; 32bit)) with ESMTPSA id <0LGU005IAE138I70@et.apple.com> for ipv6@ietf.org; Fri, 18 Feb 2011 18:10:31 -0800 (PST) Subject: Re: 6MAN WG Last Call: From: james woodyatt In-reply-to: <20110219121433.490f3fe3@opy.nosense.org> Date: Fri, 18 Feb 2011 18:05:06 -0800 Message-id: <9703B608-48AC-4A36-81A9-02BC699E4158@apple.com> References: <7B63F7B6-D788-4A05-9722-C1CAAA42B754@gmail.com> <201101171932.p0HJWU58003756@cichlid.raleigh.ibm.com> <20110219121433.490f3fe3@opy.nosense.org> To: 6man Mailing List X-Mailer: Apple Mail (2.1084) X-Brightmail-Tracker: AAAAAA== X-BeenThere: ipv6@ietf.org 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: , X-List-Received-Date: Sat, 19 Feb 2011 02:09:57 -0000 On Feb 18, 2011, at 17:44, Mark Smith wrote: > On Fri, 18 Feb 2011 10:55:18 +0200 (EET) Pekka Savola wrote: >> >> RFC4191 (Default Router Preferences and More-Specific Routes) should be >> discussed. Is this a MAY? Quite a few host implementations already support >> it. > > I think this should be a MUST, or at least a SHOULD, as the simple CPE > draft relies on this capability to support routing between internal > subnets if the WAN link is down Which host implementations support the More-specific Routes option? I'm aware of at least one major family of implementations that does not support it, i.e. Mac OS X and iOS. -- james woodyatt member of technical staff, core os networking From ipng@69706e6720323030352d30312d31340a.nosense.org Fri Feb 18 18:38:37 2011 Return-Path: X-Original-To: ipv6@core3.amsl.com Delivered-To: ipv6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C90903A6F4A for ; Fri, 18 Feb 2011 18:38:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.895 X-Spam-Level: X-Spam-Status: No, score=-1.895 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3OH5nRX9SSkv for ; Fri, 18 Feb 2011 18:38:36 -0800 (PST) Received: from smtp4.adam.net.au (smtp4.adam.net.au [202.136.110.247]) by core3.amsl.com (Postfix) with ESMTP id B9B553A6F10 for ; Fri, 18 Feb 2011 18:38:36 -0800 (PST) Received: from 219-90-145-108.ip.adam.com.au ([219.90.145.108] helo=opy.nosense.org) by smtp4.adam.net.au with esmtp (Exim 4.63) (envelope-from ) id 1Pqcj1-0006uv-0h; Sat, 19 Feb 2011 13:09:11 +1030 Received: from opy.nosense.org (localhost.localdomain [IPv6:::1]) by opy.nosense.org (Postfix) with ESMTP id 2F8A63B337; Sat, 19 Feb 2011 13:09:10 +1030 (CST) Date: Sat, 19 Feb 2011 13:09:09 +1030 From: Mark Smith To: james woodyatt Subject: Re: 6MAN WG Last Call: Message-ID: <20110219130909.6fd131b5@opy.nosense.org> In-Reply-To: <9703B608-48AC-4A36-81A9-02BC699E4158@apple.com> References: <7B63F7B6-D788-4A05-9722-C1CAAA42B754@gmail.com> <201101171932.p0HJWU58003756@cichlid.raleigh.ibm.com> <20110219121433.490f3fe3@opy.nosense.org> <9703B608-48AC-4A36-81A9-02BC699E4158@apple.com> X-Mailer: Claws Mail 3.7.8 (GTK+ 2.22.1; x86_64-unknown-linux-gnu) X-Location: Lower Mitcham, South Australia, 5062 Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: 6man Mailing List X-BeenThere: ipv6@ietf.org 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: , X-List-Received-Date: Sat, 19 Feb 2011 02:38:37 -0000 Hi James, On Fri, 18 Feb 2011 18:05:06 -0800 james woodyatt wrote: > On Feb 18, 2011, at 17:44, Mark Smith wrote: > > On Fri, 18 Feb 2011 10:55:18 +0200 (EET) Pekka Savola wrote: > >> > >> RFC4191 (Default Router Preferences and More-Specific Routes) should be > >> discussed. Is this a MAY? Quite a few host implementations already support > >> it. > > > > I think this should be a MUST, or at least a SHOULD, as the simple CPE > > draft relies on this capability to support routing between internal > > subnets if the WAN link is down > > Which host implementations support the More-specific Routes option? I'm aware of at least one major family of implementations that does not support it, i.e. Mac OS X and iOS. > Linux does since kernel 2.6.17 (Jun 17 2006), although it defaults to ignoring anything but the default zero length prefix (i.e. ::/0), apparently because of a bit of dependency confusion between router preferences and the route information option. The default should probably be changed to accepting /64s. According to the following, "Windows Vista, Windows XP, Windows Server 2008, and Windows Server 2003 supports RFC 4191." Presumably Windows 7 does too. http://technet.microsoft.com/en-us/library/bb726956.aspx Regards, Mark. From pekkas@netcore.fi Sat Feb 19 03:59:10 2011 Return-Path: X-Original-To: ipv6@core3.amsl.com Delivered-To: ipv6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BE0113A7005 for ; Sat, 19 Feb 2011 03:59:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.59 X-Spam-Level: X-Spam-Status: No, score=-102.59 tagged_above=-999 required=5 tests=[AWL=0.009, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vIa5eBZwLRyd for ; Sat, 19 Feb 2011 03:59:09 -0800 (PST) Received: from netcore.fi (eunet-gw.ipv6.netcore.fi [IPv6:2001:670:86:3001::1]) by core3.amsl.com (Postfix) with ESMTP id 5FCDB3A7003 for ; Sat, 19 Feb 2011 03:59:09 -0800 (PST) Received: from netcore.fi (localhost [127.0.0.1]) by netcore.fi (8.13.8/8.13.8) with ESMTP id p1JBxaK1006468 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 19 Feb 2011 13:59:37 +0200 Received: from localhost (pekkas@localhost) by netcore.fi (8.13.8/8.13.8/Submit) with ESMTP id p1JBxaJh006465; Sat, 19 Feb 2011 13:59:36 +0200 Date: Sat, 19 Feb 2011 13:59:36 +0200 (EET) From: Pekka Savola To: james woodyatt Subject: Re: 6MAN WG Last Call: In-Reply-To: <9703B608-48AC-4A36-81A9-02BC699E4158@apple.com> Message-ID: References: <7B63F7B6-D788-4A05-9722-C1CAAA42B754@gmail.com> <201101171932.p0HJWU58003756@cichlid.raleigh.ibm.com> <20110219121433.490f3fe3@opy.nosense.org> <9703B608-48AC-4A36-81A9-02BC699E4158@apple.com> User-Agent: Alpine 2.02 (LRH 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: clamav-milter 0.96.5 at otso.netcore.fi X-Virus-Status: Clean Cc: 6man Mailing List X-BeenThere: ipv6@ietf.org 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: , X-List-Received-Date: Sat, 19 Feb 2011 11:59:11 -0000 On Fri, 18 Feb 2011, james woodyatt wrote: > On Feb 18, 2011, at 17:44, Mark Smith wrote: >> On Fri, 18 Feb 2011 10:55:18 +0200 (EET) Pekka Savola wrote: >>> >>> RFC4191 (Default Router Preferences and More-Specific Routes) should be >>> discussed. Is this a MAY? Quite a few host implementations already support >>> it. >> >> I think this should be a MUST, or at least a SHOULD, as the simple CPE >> draft relies on this capability to support routing between internal >> subnets if the WAN link is down > > Which host implementations support the More-specific Routes option? I'm aware of at least one major family of implementations that does not support it, i.e. Mac OS X and iOS. It's my understanding that Linux and Windows both support both the prefererence and more-specific route options. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From pekkas@netcore.fi Sun Feb 20 22:06:07 2011 Return-Path: X-Original-To: ipv6@core3.amsl.com Delivered-To: ipv6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AC0393A6F4E for ; Sun, 20 Feb 2011 22:06:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.59 X-Spam-Level: X-Spam-Status: No, score=-102.59 tagged_above=-999 required=5 tests=[AWL=0.009, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b61+HdpLh2id for ; Sun, 20 Feb 2011 22:06:06 -0800 (PST) Received: from netcore.fi (eunet-gw.ipv6.netcore.fi [IPv6:2001:670:86:3001::1]) by core3.amsl.com (Postfix) with ESMTP id 4F44C3A6F05 for ; Sun, 20 Feb 2011 22:06:06 -0800 (PST) Received: from netcore.fi (localhost [127.0.0.1]) by netcore.fi (8.13.8/8.13.8) with ESMTP id p1L66ZFR024674 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 21 Feb 2011 08:06:35 +0200 Received: from localhost (pekkas@localhost) by netcore.fi (8.13.8/8.13.8/Submit) with ESMTP id p1L66YtI024671; Mon, 21 Feb 2011 08:06:34 +0200 Date: Mon, 21 Feb 2011 08:06:34 +0200 (EET) From: Pekka Savola To: Brian E Carpenter Subject: Re: 6MAN WG Last Call: In-Reply-To: <4D5EC960.9080202@gmail.com> Message-ID: References: <7B63F7B6-D788-4A05-9722-C1CAAA42B754@gmail.com> <201101171932.p0HJWU58003756@cichlid.raleigh.ibm.com> <4D5EC960.9080202@gmail.com> User-Agent: Alpine 2.02 (LRH 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: clamav-milter 0.96.5 at otso.netcore.fi X-Virus-Status: Clean Cc: Thomas Narten , 6man Mailing List X-BeenThere: ipv6@ietf.org 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: , X-List-Received-Date: Mon, 21 Feb 2011 06:06:07 -0000 On Sat, 19 Feb 2011, Brian E Carpenter wrote: > On 2011-02-18 21:55, Pekka Savola wrote: >> I think this document should also discuss APIs we have defined and that >> relate to the protocols described in the document. A separate section >> should be added on this. > > I'm not convinced. If the goal is to specify a working set of features > to make a node interoperable on the wire, APIs are out of scope. I think I understand your reasoning for that kind of scoping, but the document does not restrict itself to just making a node interoperable on the wire. FWIW, RFC1122 and 1812 do not make similar scoping restriction. >> The document is silent on Flow Label (as Brian mentioned). Rather than >> silence, I might be tempted to say something at least from the current >> perspective. The key point here is, "are hosts expected to randomize or >> otherwise by default set a flow label"? > > Until we have settled on 3697bis, there is no answer to that question. > I think it would be misleading to mention it. Section S 5.1 already has a MUST requirement for supporting RFC2460. RFC2460 main body and appendix describe the behaviour for assigning flows at the originating node. This was made more specific in RFC3697 that updated 2460. Given the situation we already have, I think it would be best to address this point by describing what we currently have already specified and the document requires. A warning "This behaviour is being revised." would be sufficient to address upgrade path issues. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From asaeda@sfc.wide.ad.jp Mon Feb 21 00:59:56 2011 Return-Path: X-Original-To: ipv6@core3.amsl.com Delivered-To: ipv6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 999243A6FEC for ; Mon, 21 Feb 2011 00:59:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.096 X-Spam-Level: X-Spam-Status: No, score=-99.096 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RELAY_IS_203=0.994, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lJ6gfC9Xzstd for ; Mon, 21 Feb 2011 00:59:56 -0800 (PST) Received: from mail.sfc.wide.ad.jp (mail.sfc.wide.ad.jp [203.178.142.146]) by core3.amsl.com (Postfix) with ESMTP id E04803A6FBE for ; Mon, 21 Feb 2011 00:59:55 -0800 (PST) Received: from localhost (64.137.dhcp.conference.apricot.net [169.223.137.64]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id A103A27808D for ; Mon, 21 Feb 2011 18:00:34 +0900 (JST) Date: Mon, 21 Feb 2011 17:00:33 +0800 (HKT) Message-Id: <20110221.170033.54555648.asaeda@sfc.wide.ad.jp> To: ipv6@ietf.org Subject: MLD version for node req. draft From: Hitoshi Asaeda X-Mailer: Mew version 6.2.51 on Emacs 22.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-BeenThere: ipv6@ietf.org 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: , X-List-Received-Date: Mon, 21 Feb 2011 08:59:56 -0000 Hi, I have a comment about the description of MLD version in the node requirement draft; http://tools.ietf.org/html/draft-ietf-6man-node-req-bis-07 In MBONED WG, the Lightweight MLDv2 [RFC5790] that simplifies the protocol spec of MLDv2 is published as the proposed standard RFC. Hence I recommend to change two sentences in the section 5.9 of this draft as follows; "Nodes that need to join multicast groups SHOULD also implement MLDv2 [RFC3810]." to "Nodes that need to join multicast groups SHOULD also implement either MLDv2 [RFC3810] or Lightweight MLDv2 [RFC5790]." and "if the node has applications that need support for Source-Specific Multicast [RFC3569], the node MUST support MLDv2 as defined in [RFC3810], [RFC4604] and [RFC4607]." to "if the node has applications that need support for Source-Specific Multicast [RFC3569], the node MUST support either MLDv2 as defined in [RFC3810], [RFC4604] and [RFC4607] or Lightweight MLDv2 [RFC5790]." Regards, -- Hitoshi Asaeda From kauer@biplane.com.au Mon Feb 21 01:25:48 2011 Return-Path: X-Original-To: ipv6@core3.amsl.com Delivered-To: ipv6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 730763A706C for ; Mon, 21 Feb 2011 01:25:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y42XGERyUNAq for ; Mon, 21 Feb 2011 01:25:46 -0800 (PST) Received: from syd-srv03.ezyreg.com (syd-srv03.ezyreg.com [117.58.251.4]) by core3.amsl.com (Postfix) with ESMTP id 770FE3A706A for ; Mon, 21 Feb 2011 01:25:46 -0800 (PST) Received: from igw.biplane.com.au ([203.26.128.2] helo=[192.168.1.200]) by syd-srv03.ezyreg.com with esmtpsa (SSLv3:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1PrS2D-00040b-PS for ipv6@ietf.org; Mon, 21 Feb 2011 04:26:25 -0500 Subject: RFC2526 - actually honoured? From: Karl Auer To: IETF IPv6 Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-k2HZVqbngbYq+Hs4Wqr5" Date: Mon, 21 Feb 2011 20:29:54 +1100 Message-ID: <1298280594.14158.51.camel@karl> Mime-Version: 1.0 X-Mailer: Evolution 2.30.3 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - syd-srv03.ezyreg.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - biplane.com.au X-Source: X-Source-Args: X-Source-Dir: X-BeenThere: ipv6@ietf.org 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: , X-List-Received-Date: Mon, 21 Feb 2011 09:25:48 -0000 --=-k2HZVqbngbYq+Hs4Wqr5 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Does anyone know if (and if so in what way) RFC2526 is honoured in the real world? It's standards track, dating from 1999, but I'm not sure I've seen anyone avoiding the stipulated reserved addresses. Addresses generated by SLAAC from a MAC address may well have some of the last seven bits set, for example. "The construction of a reserved subnet anycast address depends on the type of IPv6 addresses used within the subnet, as indicated by the format prefix in the addresses. In particular, for IPv6 address types required to have 64-bit interface identifiers in EUI-64 format, the universal/local bit MUST be set to 0 (local) in all reserved subnet anycast addresses, to indicate that the interface identifier in the address is not globally unique. IPv6 addresses of this type are currently specified to be those having format prefixes 001 through 111, except for Multicast Addresses (1111 1111) [3]." Just interested to know if these supposedly reserved anycast addresses are something one should actually be avoiding in practice or not. Regards, K. --=20 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Karl Auer (kauer@biplane.com.au) +61-2-64957160 (h) http://www.biplane.com.au/kauer/ +61-428-957160 (mob) GPG fingerprint: DA41 51B1 1481 16E1 F7E2 B2E9 3007 14ED 5736 F687 Old fingerprint: B386 7819 B227 2961 8301 C5A9 2EBC 754B CD97 0156 --=-k2HZVqbngbYq+Hs4Wqr5 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iEYEABECAAYFAk1iMIsACgkQMAcU7Vc29odqtgCfVqEOTKmMCQjEmFw3bDpeuV+T Hr4An3kZbqxvn2Gkx1qQ1NOHwJSCICFO =6MI4 -----END PGP SIGNATURE----- --=-k2HZVqbngbYq+Hs4Wqr5-- From ipng@69706e6720323030352d30312d31340a.nosense.org Mon Feb 21 02:00:39 2011 Return-Path: X-Original-To: ipv6@core3.amsl.com Delivered-To: ipv6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D749D3A7074 for ; Mon, 21 Feb 2011 02:00:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.895 X-Spam-Level: X-Spam-Status: No, score=-1.895 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d7AqFnKggRE6 for ; Mon, 21 Feb 2011 02:00:39 -0800 (PST) Received: from smtp4.adam.net.au (smtp4.adam.net.au [202.136.110.247]) by core3.amsl.com (Postfix) with ESMTP id C82093A6E93 for ; Mon, 21 Feb 2011 02:00:37 -0800 (PST) Received: from 219-90-145-108.ip.adam.com.au ([219.90.145.108] helo=opy.nosense.org) by smtp4.adam.net.au with esmtp (Exim 4.63) (envelope-from ) id 1PrSZw-0000oo-Uw; Mon, 21 Feb 2011 20:31:17 +1030 Received: from opy.nosense.org (localhost.localdomain [IPv6:::1]) by opy.nosense.org (Postfix) with ESMTP id 230E03B336; Mon, 21 Feb 2011 20:31:16 +1030 (CST) Date: Mon, 21 Feb 2011 20:31:15 +1030 From: Mark Smith To: Karl Auer Subject: Re: RFC2526 - actually honoured? Message-ID: <20110221203115.6388f4bb@opy.nosense.org> In-Reply-To: <1298280594.14158.51.camel@karl> References: <1298280594.14158.51.camel@karl> X-Mailer: Claws Mail 3.7.8 (GTK+ 2.22.1; x86_64-unknown-linux-gnu) X-Location: Lower Mitcham, South Australia, 5062 Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: IETF IPv6 X-BeenThere: ipv6@ietf.org 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: , X-List-Received-Date: Mon, 21 Feb 2011 10:00:40 -0000 Hi Karl, On Mon, 21 Feb 2011 20:29:54 +1100 Karl Auer wrote: > Does anyone know if (and if so in what way) RFC2526 is honoured in the > real world? > > It's standards track, dating from 1999, but I'm not sure I've seen > anyone avoiding the stipulated reserved addresses. Addresses generated > by SLAAC from a MAC address may well have some of the last seven bits > set, for example. > > "The construction of a reserved subnet anycast address depends on the > type of IPv6 addresses used within the subnet, as indicated by the > format prefix in the addresses. In particular, for IPv6 address > types required to have 64-bit interface identifiers in EUI-64 format, > the universal/local bit MUST be set to 0 (local) in all reserved > subnet anycast addresses, to indicate that the interface identifier > in the address is not globally unique. IPv6 addresses of this type > are currently specified to be those having format prefixes 001 > through 111, except for Multicast Addresses (1111 1111) [3]." > > Just interested to know if these supposedly reserved anycast addresses > are something one should actually be avoiding in practice or not. > Reading through the above text and the subsequent text in the RFC a few times, I don't think it is saying that the subnet anycast address is derived from the EUI-64 identifier i.e. your MAC address with SLAAC. I think the word "format" after "EUI-64" means it isn't talking about a node's EUI-64 identifiers, rather I think all it is saying that if you require reserved subnet anycast addresses with 64 bit Interface Identifiers, then the format is - | 64 bits | 57 bits | 7 bits | +---------------------------------+------------------+------------+ | subnet prefix | 1111110111...111 | anycast ID | +---------------------------------+------------------+------------+ | interface identifier field | where the 71st bit is switched off (i.e. 6 on bits, 1 off bit, then 50 on bits for the 57 bits portion). (It's a bit scary thinking about the code changes to be deployed if EUI-64 a.k.a. MAC address end-octets needed to be zeroed before use in SLAAC!). Regards, Mark. From kauer@biplane.com.au Mon Feb 21 02:25:52 2011 Return-Path: X-Original-To: ipv6@core3.amsl.com Delivered-To: ipv6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 144DF3A6FF3 for ; Mon, 21 Feb 2011 02:25:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SItO+tl1A-VQ for ; Mon, 21 Feb 2011 02:25:49 -0800 (PST) Received: from syd-srv03.ezyreg.com (syd-srv03.ezyreg.com [117.58.251.4]) by core3.amsl.com (Postfix) with ESMTP id 0E3933A6E99 for ; Mon, 21 Feb 2011 02:25:47 -0800 (PST) Received: from igw.biplane.com.au ([203.26.128.2] helo=[192.168.1.200]) by syd-srv03.ezyreg.com with esmtpsa (SSLv3:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1PrSyI-0003yU-B7 for ipv6@ietf.org; Mon, 21 Feb 2011 05:26:26 -0500 Subject: Re: RFC2526 - actually honoured? From: Karl Auer To: IETF IPv6 In-Reply-To: <20110221203115.6388f4bb@opy.nosense.org> References: <1298280594.14158.51.camel@karl> <20110221203115.6388f4bb@opy.nosense.org> Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-YF427kTtedEKAddqWHeC" Date: Mon, 21 Feb 2011 21:29:51 +1100 Message-ID: <1298284191.14158.78.camel@karl> Mime-Version: 1.0 X-Mailer: Evolution 2.30.3 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - syd-srv03.ezyreg.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - biplane.com.au X-Source: X-Source-Args: X-Source-Dir: X-BeenThere: ipv6@ietf.org 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: , X-List-Received-Date: Mon, 21 Feb 2011 10:25:52 -0000 --=-YF427kTtedEKAddqWHeC Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, 2011-02-21 at 20:31 +1030, Mark Smith wrote: > Karl Auer wrote: > > Does anyone know if (and if so in what way) RFC2526 is honoured in the > > real world? > >=20 > > "The construction of a reserved subnet anycast address depends on th= e > > type of IPv6 addresses used within the subnet, as indicated by the > > format prefix in the addresses. In particular, for IPv6 address > > types required to have 64-bit interface identifiers in EUI-64 format= , > > the universal/local bit MUST be set to 0 (local) in all reserved > > subnet anycast addresses, to indicate that the interface identifier > > in the address is not globally unique. IPv6 addresses of this type > > are currently specified to be those having format prefixes 001 > > through 111, except for Multicast Addresses (1111 1111) [3]." > > Reading through the above text and the subsequent text in the RFC a > few times, I don't think it is saying that the subnet anycast address is > derived from the EUI-64 identifier i.e. your MAC address with SLAAC. I think it is saying that the last seven bits of every 64-bit interface ID where the seventh bit is zero are reserved for anycast addresses! On the face of it, that conflicts directly with SLAAC. The only exceptions are multicast addresses and addresses beginning with (binary) 000. That seems to be what the actual RFC is saying. What interests me, though, is not so much what exactly it says but whether anyone actually (i.e., in practice) *cares* what it says :-) Regards, K. --=20 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Karl Auer (kauer@biplane.com.au) +61-2-64957160 (h) http://www.biplane.com.au/kauer/ +61-428-957160 (mob) GPG fingerprint: DA41 51B1 1481 16E1 F7E2 B2E9 3007 14ED 5736 F687 Old fingerprint: B386 7819 B227 2961 8301 C5A9 2EBC 754B CD97 0156 --=-YF427kTtedEKAddqWHeC Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iEYEABECAAYFAk1iPp8ACgkQMAcU7Vc29oc/+gCfVKJEk8lC61kwDvT1eP+7K/c8 6zYAoK5e53vlGgR2wBHyUIUlUtTJFTC8 =cHVH -----END PGP SIGNATURE----- --=-YF427kTtedEKAddqWHeC-- From john@jlc.net Mon Feb 21 04:28:06 2011 Return-Path: X-Original-To: ipv6@core3.amsl.com Delivered-To: ipv6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 490EB3A70EA for ; Mon, 21 Feb 2011 04:28:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.747 X-Spam-Level: X-Spam-Status: No, score=-106.747 tagged_above=-999 required=5 tests=[AWL=-0.148, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hK9VaHgU-Yy9 for ; Mon, 21 Feb 2011 04:28:05 -0800 (PST) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by core3.amsl.com (Postfix) with ESMTP id 277123A70D5 for ; Mon, 21 Feb 2011 04:28:05 -0800 (PST) Received: by mailhost.jlc.net (Postfix, from userid 104) id 29AC733C31; Mon, 21 Feb 2011 07:28:43 -0500 (EST) Date: Mon, 21 Feb 2011 07:28:43 -0500 From: John Leslie To: Pekka Savola Subject: Re: 6MAN WG Last Call: Message-ID: <20110221122843.GB5152@verdi> References: <7B63F7B6-D788-4A05-9722-C1CAAA42B754@gmail.com> <201101171932.p0HJWU58003756@cichlid.raleigh.ibm.com> <4D5EC960.9080202@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i Cc: 6man Mailing List X-BeenThere: ipv6@ietf.org 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: , X-List-Received-Date: Mon, 21 Feb 2011 12:28:06 -0000 Pekka Savola wrote: > On Sat, 19 Feb 2011, Brian E Carpenter wrote: >>On 2011-02-18 21:55, Pekka Savola wrote: >> >>> The document is silent on Flow Label (as Brian mentioned). Rather than >>> silence, I might be tempted to say something at least from the current >>> perspective. The key point here is, "are hosts expected to randomize or >>> otherwise by default set a flow label"? This document is not the place to say that: it says _where_to_look_ for such specifications. >> Until we have settled on 3697bis, there is no answer to that question. >> I think it would be misleading to mention it. ... but it probably is reasonable to mention 3697bis as work in progress. > Section S 5.1 already has a MUST requirement for supporting RFC2460. > RFC2460 main body and appendix describe the behaviour for assigning > flows at the originating node. This was made more specific in RFC3697 > that updated 2460. Saying just-that is reasonable. > Given the situation we already have, I think it would be best to > address this point by describing what we currently have already > specified and the document requires. A warning "This behaviour is > being revised." would be sufficient to address upgrade path issues. This document should not try to be authoritative on Flow Label. We could be more specific on where-to-look, but I'm not convinced that will be helpful: where-to-look, IMHO, is 3697bis. ;^) -- John Leslie From narten@us.ibm.com Mon Feb 21 07:29:43 2011 Return-Path: X-Original-To: ipv6@core3.amsl.com Delivered-To: ipv6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0502E3A6DD8 for ; Mon, 21 Feb 2011 07:29:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B5RF4jMSNuDT for ; Mon, 21 Feb 2011 07:29:42 -0800 (PST) Received: from e4.ny.us.ibm.com (e4.ny.us.ibm.com [32.97.182.144]) by core3.amsl.com (Postfix) with ESMTP id 045BC3A6D03 for ; Mon, 21 Feb 2011 07:29:41 -0800 (PST) Received: from d01relay06.pok.ibm.com (d01relay06.pok.ibm.com [9.56.227.116]) by e4.ny.us.ibm.com (8.14.4/8.13.1) with ESMTP id p1LFBMeZ025714 for ; Mon, 21 Feb 2011 10:11:22 -0500 Received: from d01av03.pok.ibm.com (d01av03.pok.ibm.com [9.56.224.217]) by d01relay06.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id p1LFUCEj1867850 for ; Mon, 21 Feb 2011 10:30:12 -0500 Received: from d01av03.pok.ibm.com (loopback [127.0.0.1]) by d01av03.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id p1LFUBMA008292 for ; Mon, 21 Feb 2011 12:30:11 -0300 Received: from cichlid.raleigh.ibm.com (sig-9-65-217-194.mts.ibm.com [9.65.217.194]) by d01av03.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id p1LFUAFR008215 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 21 Feb 2011 12:30:11 -0300 Received: from cichlid.raleigh.ibm.com (localhost.localdomain [127.0.0.1]) by cichlid.raleigh.ibm.com (8.14.4/8.12.5) with ESMTP id p1LFU3NA009245; Mon, 21 Feb 2011 10:30:04 -0500 Message-Id: <201102211530.p1LFU3NA009245@cichlid.raleigh.ibm.com> To: Hitoshi Asaeda Subject: Re: MLD version for node req. draft In-reply-to: <20110221.170033.54555648.asaeda@sfc.wide.ad.jp> References: <20110221.170033.54555648.asaeda@sfc.wide.ad.jp> Comments: In-reply-to Hitoshi Asaeda message dated "Mon, 21 Feb 2011 17:00:33 +0800." Date: Mon, 21 Feb 2011 10:30:03 -0500 From: Thomas Narten Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org 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: , X-List-Received-Date: Mon, 21 Feb 2011 15:29:43 -0000 > "Nodes that need to join multicast groups SHOULD also implement either > MLDv2 [RFC3810] or Lightweight MLDv2 [RFC5790]." Is there a short (less than one page) description of the difference between RFCs 3810 and 5790? One that actually explains what the implementation differences are? Thomas From brian@innovationslab.net Mon Feb 21 08:21:10 2011 Return-Path: X-Original-To: ipv6@core3.amsl.com Delivered-To: ipv6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 33BD83A6FE4 for ; Mon, 21 Feb 2011 08:21:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.299 X-Spam-Level: X-Spam-Status: No, score=-102.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X6aiQBMf1gFc for ; Mon, 21 Feb 2011 08:21:09 -0800 (PST) Received: from uillean.fuaim.com (uillean.fuaim.com [206.197.161.140]) by core3.amsl.com (Postfix) with ESMTP id 856493A6F29 for ; Mon, 21 Feb 2011 08:21:08 -0800 (PST) Received: from clairseach.fuaim.com (clairseach.fuaim.com [206.197.161.141]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by uillean.fuaim.com (Postfix) with ESMTP id 22EA588249 for ; Mon, 21 Feb 2011 08:21:50 -0800 (PST) Received: from tigers.jhuapl.edu (tigers.jhuapl.edu [128.244.119.70]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by clairseach.fuaim.com (Postfix) with ESMTP id 028F0136955B for ; Mon, 21 Feb 2011 08:21:48 -0800 (PST) Message-ID: <4D629117.9060303@innovationslab.net> Date: Mon, 21 Feb 2011 11:21:43 -0500 From: Brian Haberman User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.4; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: ipv6@ietf.org Subject: Re: Agenda requests for IETF 80 References: <4D25CB80.8060104@innovationslab.net> In-Reply-To: <4D25CB80.8060104@innovationslab.net> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: ipv6@ietf.org 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: , X-List-Received-Date: Mon, 21 Feb 2011 16:21:10 -0000 All, The WG chairs' deadline for agenda requests passed two weeks ago. We received one exactly one request for time and that request was conditioned on the state of ongoing discussions. We will accept any additional requests for an agenda slot (conforming to the guidelines below) until COB on Monday, February 28th. Regards, Brian & Bob On 1/6/11 9:02 AM, Brian Haberman wrote: > All, > Scheduling and registration have opened for the 80th IETF meeting > in Prague. The chairs are now soliciting requests for agenda time > during the 6MAN WG slot. If you wish to present, please send the chairs: > > - Topic > - Presenter > - Time requested > - draft name > > As with previous meetings, we will give preference to WG work items, > topics actively discussed on the mailing list, and then new topics. > Please have these requests to the chairs NO LATER THAN 9:00pm GMT on > February 4, 2011. > > Regards, > Brian& Bob > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From brian.e.carpenter@gmail.com Mon Feb 21 13:08:54 2011 Return-Path: X-Original-To: ipv6@core3.amsl.com Delivered-To: ipv6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 12AA53A7132 for ; Mon, 21 Feb 2011 13:08:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.437 X-Spam-Level: X-Spam-Status: No, score=-103.437 tagged_above=-999 required=5 tests=[AWL=0.162, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lBJYTG44nLbD for ; Mon, 21 Feb 2011 13:08:53 -0800 (PST) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id D5BD83A7127 for ; Mon, 21 Feb 2011 13:08:50 -0800 (PST) Received: by fxm15 with SMTP id 15so2937985fxm.31 for ; Mon, 21 Feb 2011 13:09:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:organization:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=Ce9nQyfC5jPoApycr1TktrOwvEeMHIUOdBEw4/0pE6M=; b=lOhAukb4cCFJXfquej41hzAZJ0I6YhJxGfe2c+4K0Zzgk13OJgoliHqdExMq7zYz/D wR/92VgZ9FM0m+JiZqk3f4MRHtkk/HPI2SUGg1C61MloNnhT1Wn7Sg2AmgeBWvS/3UCv 4G9THENhatydo7UEmAbcJBsvSHPykprqUMWgE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; b=BgMpftaU9ec/sj9FgvuEWpy2iKBEn0PMdUtj91nBJmHnei23H4uqdSw+++uDJZiSIV GKIWaXKieeudcEzysM/l0247asCOTAOELOKF0c4t3bQufQ7oEB4G80lSMUQkbND2O2lY QhWVHWw/eThUhpxNhKGB25nOFVhxZe6l8zQvs= Received: by 10.223.83.142 with SMTP id f14mr2368046fal.0.1298322445471; Mon, 21 Feb 2011 13:07:25 -0800 (PST) Received: from [130.216.38.124] (stf-brian.sfac.auckland.ac.nz [130.216.38.124]) by mx.google.com with ESMTPS id e17sm30528fak.10.2011.02.21.13.07.21 (version=SSLv3 cipher=OTHER); Mon, 21 Feb 2011 13:07:24 -0800 (PST) Message-ID: <4D62D407.9050307@gmail.com> Date: Tue, 22 Feb 2011 10:07:19 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: John Leslie Subject: Re: 6MAN WG Last Call: References: <7B63F7B6-D788-4A05-9722-C1CAAA42B754@gmail.com> <201101171932.p0HJWU58003756@cichlid.raleigh.ibm.com> <4D5EC960.9080202@gmail.com> <20110221122843.GB5152@verdi> In-Reply-To: <20110221122843.GB5152@verdi> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: 6man Mailing List , Pekka Savola X-BeenThere: ipv6@ietf.org 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: , X-List-Received-Date: Mon, 21 Feb 2011 21:08:54 -0000 On 2011-02-22 01:28, John Leslie wrote: > Pekka Savola wrote: >> On Sat, 19 Feb 2011, Brian E Carpenter wrote: >>> On 2011-02-18 21:55, Pekka Savola wrote: >>> >>>> The document is silent on Flow Label (as Brian mentioned). Rather than >>>> silence, I might be tempted to say something at least from the current >>>> perspective. The key point here is, "are hosts expected to randomize or >>>> otherwise by default set a flow label"? > > This document is not the place to say that: it says _where_to_look_ > for such specifications. > >>> Until we have settled on 3697bis, there is no answer to that question. >>> I think it would be misleading to mention it. > > ... but it probably is reasonable to mention 3697bis as work in > progress. > >> Section S 5.1 already has a MUST requirement for supporting RFC2460. >> RFC2460 main body and appendix describe the behaviour for assigning >> flows at the originating node. This was made more specific in RFC3697 >> that updated 2460. > > Saying just-that is reasonable. Well, I object to drawing anyone's attention to the Appendix of 2460, which is explicitly not part of the standard. And I think that the main text in 2460 is underspecified, whereas RFC 3697 has proved to be plain confusing. And we don't yet have clear consenus on 3697bis. Does all this belong in a requirements list? Brian > >> Given the situation we already have, I think it would be best to >> address this point by describing what we currently have already >> specified and the document requires. A warning "This behaviour is >> being revised." would be sufficient to address upgrade path issues. > > This document should not try to be authoritative on Flow Label. > We could be more specific on where-to-look, but I'm not convinced > that will be helpful: where-to-look, IMHO, is 3697bis. ;^) > > -- > John Leslie > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > From john@jlc.net Mon Feb 21 14:50:38 2011 Return-Path: X-Original-To: ipv6@core3.amsl.com Delivered-To: ipv6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 68BBF3A719F for ; Mon, 21 Feb 2011 14:50:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.733 X-Spam-Level: X-Spam-Status: No, score=-106.733 tagged_above=-999 required=5 tests=[AWL=-0.134, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7jASb2TSnVcC for ; Mon, 21 Feb 2011 14:50:37 -0800 (PST) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by core3.amsl.com (Postfix) with ESMTP id DC43F3A7195 for ; Mon, 21 Feb 2011 14:50:36 -0800 (PST) Received: by mailhost.jlc.net (Postfix, from userid 104) id 6296C33C2E; Mon, 21 Feb 2011 17:51:09 -0500 (EST) Date: Mon, 21 Feb 2011 17:51:09 -0500 From: John Leslie To: Brian E Carpenter Subject: Re: 6MAN WG Last Call: Message-ID: <20110221225109.GD5152@verdi> References: <7B63F7B6-D788-4A05-9722-C1CAAA42B754@gmail.com> <201101171932.p0HJWU58003756@cichlid.raleigh.ibm.com> <4D5EC960.9080202@gmail.com> <20110221122843.GB5152@verdi> <4D62D407.9050307@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4D62D407.9050307@gmail.com> User-Agent: Mutt/1.4.1i Cc: 6man Mailing List , Pekka Savola X-BeenThere: ipv6@ietf.org 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: , X-List-Received-Date: Mon, 21 Feb 2011 22:50:38 -0000 Brian E Carpenter wrote: > On 2011-02-22 01:28, John Leslie wrote: >> Pekka Savola wrote: >> >>> Section S 5.1 already has a MUST requirement for supporting RFC2460. >>> RFC2460 main body and appendix describe the behaviour for assigning >>> flows at the originating node. This was made more specific in RFC3697 >>> that updated 2460. >> >> Saying just-that is reasonable. > > Well, I object to drawing anyone's attention to the Appendix of > 2460, which is explicitly not part of the standard. I agree with Brian there: the Appendix of 2460 never was normative, and has been thoroughly superseded. > And I think that the main text in 2460 is underspecified, I won't disagree, but the MUST in 5.1 is still appropriate. > whereas RFC 3697 has proved to be plain confusing. I agree, but it's an normative as we've got. > And we don't yet have clear consenus on 3697bis. Does all this belong > in a requirements list? IMHO, pointing out RFC 3697 _is_ appropriate; but the readers would be better served by pointing out that 3697 will probably be superseded soon. I don't actually object to not mentioning Flow Labels, since it's less than clear what is "required" at the current time. Nonetheless, I would hope we could tell folks where to look. Ignoring something that central to IPv6 feels wrong... -- John Leslie From asaeda@sfc.wide.ad.jp Mon Feb 21 19:01:22 2011 Return-Path: X-Original-To: ipv6@core3.amsl.com Delivered-To: ipv6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8F9753A67FA for ; Mon, 21 Feb 2011 19:01:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.096 X-Spam-Level: X-Spam-Status: No, score=-99.096 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RELAY_IS_203=0.994, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7gGLhpUPgODT for ; Mon, 21 Feb 2011 19:01:21 -0800 (PST) Received: from mail.sfc.wide.ad.jp (mail.sfc.wide.ad.jp [203.178.142.146]) by core3.amsl.com (Postfix) with ESMTP id 6C0B63A67F8 for ; Mon, 21 Feb 2011 19:01:21 -0800 (PST) Received: from localhost (unknown [IPv6:2001:df9:101:0:226:8ff:feec:a255]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id 5DA0C278066; Tue, 22 Feb 2011 12:02:01 +0900 (JST) Date: Tue, 22 Feb 2011 11:02:00 +0800 (HKT) Message-Id: <20110222.110200.109949015.asaeda@sfc.wide.ad.jp> To: narten@us.ibm.com Subject: Re: MLD version for node req. draft From: Hitoshi Asaeda In-Reply-To: <201102211530.p1LFU3NA009245@cichlid.raleigh.ibm.com> References: <20110221.170033.54555648.asaeda@sfc.wide.ad.jp> <201102211530.p1LFU3NA009245@cichlid.raleigh.ibm.com> X-Mailer: Mew version 6.2.51 on Emacs 22.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org 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: , X-List-Received-Date: Tue, 22 Feb 2011 03:01:22 -0000 >> "Nodes that need to join multicast groups SHOULD also implement either >> MLDv2 [RFC3810] or Lightweight MLDv2 [RFC5790]." > > Is there a short (less than one page) description of the difference > between RFCs 3810 and 5790? One that actually explains what the > implementation differences are? To start listening a multicast session/channel, an MLDv2 host specifies either 1) multicast address or 2) source and multicast addresses. When the host specifies only multicast address, multicast packets sent from any source are forwarded to the host. This is ASM. When the host specifies source address(es) as well as multicast address, it MUST also specify the "filter mode", which is either INCLUDE or EXCLUDE. When the host wants to "receive" the multicast packets sent from the specified source(es), INCLUDE is chosen as the filter mode. When the host wants to "block" the multicast packets sent from the specified source(es), EXCLUDE is chosen as the filter mode. The former case, INCLUDE (S,G) join, is known as SSM. The latter case, noted by EXCLUDE (S,G) join, is not SSM, rather ASM with an additional function; to establish EXCLUDE (S,G) state, routers need to maintain ASM state, because the routers need to forward every source data to their downstreams "except" the excluded S. In fact, there are no major applications that require EXCLUDE (S,G) join/leave. It is only useful to filter out bogus sources in ASM communications, but if you want to block unwanted source, say Sx, you'd specify other sources to join the session such as INCLUDE ({S1,S2,S3},G) (without including Sx). According to such consideration, talking abour the host-side implementation, the LW-MLDv2 spec (5790) supports both ASM and SSM communications, but eliminates EXCLUDE (S,G) join/leave operations. In fact, implementing both INCLUDE and EXCLUDE mode operations requires complex state machine in kernel; therefore LW-MLDv2 gives the chance for simpler kernel implementation. This is very positive condition, and it is sure according to my experience of both IGMPv3 and LW-IGMPv3 host-side kernel implementations in NetBSD. (I also have implemented MLDv2 kernel but no LW-MLDv2.) IMO, it is hence advantageous especially for mobile terminals or tiny OSes. Of course, LW-MLDv2 supports interoerability with any MLD versions; it works either with MLDv1, MLDv2, or LW-MLDv2 routers. I hope this helps. Regards, -- Hitoshi Asaeda From pekkas@netcore.fi Mon Feb 21 22:24:30 2011 Return-Path: X-Original-To: ipv6@core3.amsl.com Delivered-To: ipv6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C99963A67A4 for ; Mon, 21 Feb 2011 22:24:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.591 X-Spam-Level: X-Spam-Status: No, score=-102.591 tagged_above=-999 required=5 tests=[AWL=0.008, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bNBDfGonjy7u for ; Mon, 21 Feb 2011 22:24:28 -0800 (PST) Received: from netcore.fi (eunet-gw.ipv6.netcore.fi [IPv6:2001:670:86:3001::1]) by core3.amsl.com (Postfix) with ESMTP id 9C1CA3A67B2 for ; Mon, 21 Feb 2011 22:24:26 -0800 (PST) Received: from netcore.fi (localhost [127.0.0.1]) by netcore.fi (8.13.8/8.13.8) with ESMTP id p1M6OsPX001384 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 22 Feb 2011 08:24:54 +0200 Received: from localhost (pekkas@localhost) by netcore.fi (8.13.8/8.13.8/Submit) with ESMTP id p1M6OrHn001381; Tue, 22 Feb 2011 08:24:53 +0200 Date: Tue, 22 Feb 2011 08:24:53 +0200 (EET) From: Pekka Savola To: Brian E Carpenter Subject: Re: 6MAN WG Last Call: In-Reply-To: <4D62D407.9050307@gmail.com> Message-ID: References: <7B63F7B6-D788-4A05-9722-C1CAAA42B754@gmail.com> <201101171932.p0HJWU58003756@cichlid.raleigh.ibm.com> <4D5EC960.9080202@gmail.com> <20110221122843.GB5152@verdi> <4D62D407.9050307@gmail.com> User-Agent: Alpine 2.02 (LRH 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: clamav-milter 0.96.5 at otso.netcore.fi X-Virus-Status: Clean Cc: 6man Mailing List X-BeenThere: ipv6@ietf.org 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: , X-List-Received-Date: Tue, 22 Feb 2011 06:24:30 -0000 On Tue, 22 Feb 2011, Brian E Carpenter wrote: > Well, I object to drawing anyone's attention to the Appendix of > 2460, which is explicitly not part of the standard. And I think > that the main text in 2460 is underspecified, whereas RFC 3697 > has proved to be plain confusing. And we don't yet have clear > consenus on 3697bis. Does all this belong in a requirements list? Which part of 3697 that is relevant to this document is plain confusing? Those that pertain to this spec are IMHO in Section 3 which seems clear enough to me (copied below). 3. Flow Labeling Requirements To enable Flow Label based classification, source nodes SHOULD assign each unrelated transport connection and application data stream to a new flow. The source node MAY also take part in flow state establishment methods that result in assigning certain packets to specific flows. A source node which does not assign traffic to flows MUST set the Flow Label to zero. To enable applications and transport protocols to define what packets constitute a flow, the source node MUST provide means for the applications and transport protocols to specify the Flow Label values to be used with their flows. The use of the means to specify Flow Label values is subject to appropriate privileges (see section 5.1). The source node SHOULD be able to select unused Flow Label values for flows not requesting a specific value to be used. A source node MUST ensure that it does not unintentionally reuse Flow Label values it is currently using or has recently used when creating new flows. Flow Label values previously used with a specific pair of source and destination addresses MUST NOT be assigned to new flows with the same address pair within 120 seconds of the termination of the previous flow. The source node SHOULD provide the means for the applications and transport protocols to specify quarantine periods longer than the default 120 seconds for individual flows. To avoid accidental Flow Label value reuse, the source node SHOULD select new Flow Label values in a well-defined sequence (e.g., sequential or pseudo-random) and use an initial value that avoids reuse of recently used Flow Label values each time the system restarts. The initial value SHOULD be derived from a previous value stored in non-volatile memory, or in the absence of such history, a randomly generated initial value using techniques that produce good randomness properties [RND] SHOULD be used. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From iesg-secretary@ietf.org Tue Feb 22 12:22:58 2011 Return-Path: X-Original-To: ipv6@core3.amsl.com Delivered-To: ipv6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A2B303A68E7; Tue, 22 Feb 2011 12:22:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 111Wit56TpEL; Tue, 22 Feb 2011 12:22:57 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 251363A6905; Tue, 22 Feb 2011 12:22:57 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce Subject: Protocol Action: 'Using 127-bit IPv6 Prefixes on Inter-Router Links' to Proposed Standard (draft-ietf-6man-prefixlen-p2p-01.txt) X-Test-IDTracker: no X-IETF-IDTracker: 3.12 Message-ID: <20110222202257.29008.63827.idtracker@localhost> Date: Tue, 22 Feb 2011 12:22:57 -0800 Cc: 6man chair <6man-chairs@tools.ietf.org>, Internet Architecture Board , 6man mailing list , RFC Editor X-BeenThere: ipv6@ietf.org 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: , X-List-Received-Date: Tue, 22 Feb 2011 20:22:58 -0000 The IESG has approved the following document: - 'Using 127-bit IPv6 Prefixes on Inter-Router Links' (draft-ietf-6man-prefixlen-p2p-01.txt) as a Proposed Standard This document is the product of the IPv6 Maintenance Working Group. The IESG contact persons are Jari Arkko and Ralph Droms. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-6man-prefixlen-p2p/ Technical Summary This document defines the use of 127-bit IPv6 prefixes on inter-router point-to-point links. This is similar to current practice in IPv4 of using 31-bit prefixes as defined in RFC3021. This document specifies the reasons and motivation to use 127-bit IPv6 prefixes on inter-router point-to-point links, and requires that routers must support the assignment of /127 prefixes on point-to-point inter-router links. Working Group Summary The working group reviewed and discussed this document several times. The draft has significantly improved from earlier versions and there is a consensus to move the document forward in it's current form. Document Quality This document has been reviewed by key members of the 6MAN working group and the chairs, and corresponds to widely used practice on the Internet. Personnel Bob Hinden is the Document Shepherd and Jari Arkko is the responsible Area Director. From brian.e.carpenter@gmail.com Tue Feb 22 13:14:08 2011 Return-Path: X-Original-To: ipv6@core3.amsl.com Delivered-To: ipv6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 542F33A6938 for ; Tue, 22 Feb 2011 13:14:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.441 X-Spam-Level: X-Spam-Status: No, score=-103.441 tagged_above=-999 required=5 tests=[AWL=0.158, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jn8rGHIVhpOK for ; Tue, 22 Feb 2011 13:14:07 -0800 (PST) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id 14BB23A6905 for ; Tue, 22 Feb 2011 13:14:04 -0800 (PST) Received: by fxm15 with SMTP id 15so4146743fxm.31 for ; Tue, 22 Feb 2011 13:14:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:organization:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=uQRO0n/TkzCysc0O5ddJQA2+PF6DrVZGHzptfTMRAts=; b=qM5t3kDswJpZZEbpGvDV73e2jojHKIp6/DeXVjpgi8/4+9TPeJsK5iu6yEiIukYJaI WRPwkKCgVFg+0GOeJNcc8hWL0g/y7PnGh5skiuz5kT/RV7idqrAx/B/+YbPIIbVL2dSC z7+CZW34vWBcFmLR7RX/X42rgAFJzwdN7WwF4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; b=PkhIBogMVMGjQs56npZ6tYzNSCALpIS65mnMkh+2oeM0mglKQYgPJzDmK4vXLvMIRD bxKSUjcAh9LtGOyLT6xRG8HQOrYw50iYnuAfO+Rv01NNORvo64NsXm9U8ngCPqV3P20y VSSpatEuL3h6YW/WSMCef2x0IkaHWhVj7W0YI= Received: by 10.223.83.8 with SMTP id d8mr3997266fal.94.1298409255165; Tue, 22 Feb 2011 13:14:15 -0800 (PST) Received: from [130.216.38.124] (stf-brian.sfac.auckland.ac.nz [130.216.38.124]) by mx.google.com with ESMTPS id 11sm768568faw.44.2011.02.22.13.14.11 (version=SSLv3 cipher=OTHER); Tue, 22 Feb 2011 13:14:14 -0800 (PST) Message-ID: <4D642721.2010603@gmail.com> Date: Wed, 23 Feb 2011 10:14:09 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Pekka Savola Subject: Re: 6MAN WG Last Call: References: <7B63F7B6-D788-4A05-9722-C1CAAA42B754@gmail.com> <201101171932.p0HJWU58003756@cichlid.raleigh.ibm.com> <4D5EC960.9080202@gmail.com> <20110221122843.GB5152@verdi> <4D62D407.9050307@gmail.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: 6man Mailing List X-BeenThere: ipv6@ietf.org 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: , X-List-Received-Date: Tue, 22 Feb 2011 21:14:08 -0000 On 2011-02-22 19:24, Pekka Savola wrote: > On Tue, 22 Feb 2011, Brian E Carpenter wrote: >> Well, I object to drawing anyone's attention to the Appendix of >> 2460, which is explicitly not part of the standard. And I think >> that the main text in 2460 is underspecified, whereas RFC 3697 >> has proved to be plain confusing. And we don't yet have clear >> consenus on 3697bis. Does all this belong in a requirements list? > > Which part of 3697 that is relevant to this document is plain > confusing? Those that pertain to this spec are IMHO in Section 3 which > seems clear enough to me (copied below). But this text will be completely different in 3697bis. I really wouldn't want to set people off coding according to something that we already know will change. Brian > > 3. Flow Labeling Requirements > > To enable Flow Label based classification, source nodes SHOULD assign > each unrelated transport connection and application data stream to a > new flow. The source node MAY also take part in flow state > establishment methods that result in assigning certain packets to > specific flows. A source node which does not assign traffic to flows > MUST set the Flow Label to zero. > > To enable applications and transport protocols to define what packets > constitute a flow, the source node MUST provide means for the > applications and transport protocols to specify the Flow Label values > to be used with their flows. The use of the means to specify Flow > Label values is subject to appropriate privileges (see section 5.1). > The source node SHOULD be able to select unused Flow Label values for > flows not requesting a specific value to be used. > > A source node MUST ensure that it does not unintentionally reuse Flow > Label values it is currently using or has recently used when creating > new flows. Flow Label values previously used with a specific pair of > source and destination addresses MUST NOT be assigned to new flows > with the same address pair within 120 seconds of the termination of > the previous flow. The source node SHOULD provide the means for the > applications and transport protocols to specify quarantine periods > longer than the default 120 seconds for individual flows. > > To avoid accidental Flow Label value reuse, the source node SHOULD > select new Flow Label values in a well-defined sequence (e.g., > sequential or pseudo-random) and use an initial value that avoids > reuse of recently used Flow Label values each time the system > restarts. The initial value SHOULD be derived from a previous value > stored in non-volatile memory, or in the absence of such history, a > randomly generated initial value using techniques that produce good > randomness properties [RND] SHOULD be used. > From pekkas@netcore.fi Tue Feb 22 13:17:55 2011 Return-Path: X-Original-To: ipv6@core3.amsl.com Delivered-To: ipv6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6F3B33A6905 for ; Tue, 22 Feb 2011 13:17:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.592 X-Spam-Level: X-Spam-Status: No, score=-102.592 tagged_above=-999 required=5 tests=[AWL=0.008, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gzGUQkEgeZw9 for ; Tue, 22 Feb 2011 13:17:54 -0800 (PST) Received: from netcore.fi (eunet-gw.ipv6.netcore.fi [IPv6:2001:670:86:3001::1]) by core3.amsl.com (Postfix) with ESMTP id 3A2603A67F1 for ; Tue, 22 Feb 2011 13:17:53 -0800 (PST) Received: from netcore.fi (localhost [127.0.0.1]) by netcore.fi (8.13.8/8.13.8) with ESMTP id p1MLIXR0021445 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 22 Feb 2011 23:18:33 +0200 Received: from localhost (pekkas@localhost) by netcore.fi (8.13.8/8.13.8/Submit) with ESMTP id p1MLIXBI021442; Tue, 22 Feb 2011 23:18:33 +0200 Date: Tue, 22 Feb 2011 23:18:33 +0200 (EET) From: Pekka Savola To: Brian E Carpenter Subject: Re: 6MAN WG Last Call: In-Reply-To: <4D642721.2010603@gmail.com> Message-ID: References: <7B63F7B6-D788-4A05-9722-C1CAAA42B754@gmail.com> <201101171932.p0HJWU58003756@cichlid.raleigh.ibm.com> <4D5EC960.9080202@gmail.com> <20110221122843.GB5152@verdi> <4D62D407.9050307@gmail.com> <4D642721.2010603@gmail.com> User-Agent: Alpine 2.02 (LRH 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: clamav-milter 0.96.5 at otso.netcore.fi X-Virus-Status: Clean Cc: 6man Mailing List X-BeenThere: ipv6@ietf.org 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: , X-List-Received-Date: Tue, 22 Feb 2011 21:17:55 -0000 On Wed, 23 Feb 2011, Brian E Carpenter wrote: > But this text will be completely different in 3697bis. I really > wouldn't want to set people off coding according to something that > we already know will change. Ok, you're not saying that the text is plain confusing, but rather that requirements are expected to be different and what we have so far specified will be irrelevant or incorrect with the new spec. I could see that argument, but in 3697bis we will already need to deal with backward-compatibility with those implementations that behave according to current standards, so I'm not sure how compelling it is. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From john@jlc.net Tue Feb 22 13:22:44 2011 Return-Path: X-Original-To: ipv6@core3.amsl.com Delivered-To: ipv6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 793793A6916 for ; Tue, 22 Feb 2011 13:22:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.722 X-Spam-Level: X-Spam-Status: No, score=-106.722 tagged_above=-999 required=5 tests=[AWL=-0.123, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pkGPovN6nuka for ; Tue, 22 Feb 2011 13:22:43 -0800 (PST) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by core3.amsl.com (Postfix) with ESMTP id 8310D3A67F1 for ; Tue, 22 Feb 2011 13:22:43 -0800 (PST) Received: by mailhost.jlc.net (Postfix, from userid 104) id C2D2633C2A; Tue, 22 Feb 2011 16:23:24 -0500 (EST) Date: Tue, 22 Feb 2011 16:23:24 -0500 From: John Leslie To: Brian E Carpenter Subject: Re: 6MAN WG Last Call: Message-ID: <20110222212324.GI5152@verdi> References: <7B63F7B6-D788-4A05-9722-C1CAAA42B754@gmail.com> <201101171932.p0HJWU58003756@cichlid.raleigh.ibm.com> <4D5EC960.9080202@gmail.com> <20110221122843.GB5152@verdi> <4D62D407.9050307@gmail.com> <4D642721.2010603@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4D642721.2010603@gmail.com> User-Agent: Mutt/1.4.1i Cc: 6man Mailing List , Pekka Savola X-BeenThere: ipv6@ietf.org 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: , X-List-Received-Date: Tue, 22 Feb 2011 21:22:44 -0000 Brian E Carpenter wrote: > On 2011-02-22 19:24, Pekka Savola wrote: >> >> Which part of 3697 that is relevant to this document is plain >> confusing? Those that pertain to this spec are IMHO in Section 3 which >> seems clear enough to me (copied below). > > But this text will be completely different in 3697bis. I really > wouldn't want to set people off coding according to something that > we already know will change. All the more reason this document should mention both 3697 _and_ that we expect it to change. -- John Leslie From brian.e.carpenter@gmail.com Tue Feb 22 13:28:01 2011 Return-Path: X-Original-To: ipv6@core3.amsl.com Delivered-To: ipv6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 533C33A6973 for ; Tue, 22 Feb 2011 13:28:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.445 X-Spam-Level: X-Spam-Status: No, score=-103.445 tagged_above=-999 required=5 tests=[AWL=0.154, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jPMpCPpnWayM for ; Tue, 22 Feb 2011 13:28:00 -0800 (PST) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id 3F1303A6916 for ; Tue, 22 Feb 2011 13:28:00 -0800 (PST) Received: by fxm15 with SMTP id 15so4161230fxm.31 for ; Tue, 22 Feb 2011 13:28:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:organization:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=QmtxeahsRUkgQjBsjye7fJy8loWqy/Unt9fe7F94wQ0=; b=EXi5G5NCF+YlGdl/KXmiKDTcWJiQdivoCTC02AQMGDGCdWLTvN2e78xGSGl3Cz3bik W7p9Kds9XGRPt2h2OXqW4KDIaVuIuL0wQ0fZUID4zvBiTN2LAg6e+8+fzXln/R5u+ElS /3Ii5dN4XMyi+qDJtG3D+uT2SCTvKlH0Ke/tg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; b=gfLUFQZtIK1sa0S8E2f6tFCs7kdK7e4yBo1SVsWnybiKmGcrBUQl+ujj1fLTXwVbfo Jgp8fj4uvXr2xkZL2EBx/TnD0SujUMulooekXh8PGIbRDQVwGY7HrvhkdYGzN5YUlUxB ZNKh80mecFnHVLZ3b74YtCaJTUO5Rmr9RBT3s= Received: by 10.223.62.12 with SMTP id v12mr2182699fah.9.1298410044765; Tue, 22 Feb 2011 13:27:24 -0800 (PST) Received: from [130.216.38.124] (stf-brian.sfac.auckland.ac.nz [130.216.38.124]) by mx.google.com with ESMTPS id n15sm316539fam.12.2011.02.22.13.27.22 (version=SSLv3 cipher=OTHER); Tue, 22 Feb 2011 13:27:24 -0800 (PST) Message-ID: <4D642A32.9040406@gmail.com> Date: Wed, 23 Feb 2011 10:27:14 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Pekka Savola Subject: Re: 6MAN WG Last Call: References: <7B63F7B6-D788-4A05-9722-C1CAAA42B754@gmail.com> <201101171932.p0HJWU58003756@cichlid.raleigh.ibm.com> <4D5EC960.9080202@gmail.com> <20110221122843.GB5152@verdi> <4D62D407.9050307@gmail.com> <4D642721.2010603@gmail.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: 6man Mailing List X-BeenThere: ipv6@ietf.org 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: , X-List-Received-Date: Tue, 22 Feb 2011 21:28:01 -0000 On 2011-02-23 10:18, Pekka Savola wrote: > On Wed, 23 Feb 2011, Brian E Carpenter wrote: >> But this text will be completely different in 3697bis. I really >> wouldn't want to set people off coding according to something that >> we already know will change. > > Ok, you're not saying that the text is plain confusing, but rather that > requirements are expected to be different and what we have so far > specified will be irrelevant or incorrect with the new spec. Well, there is text that's confusing, but that discussion belongs on a flow label thread. > > I could see that argument, but in 3697bis we will already need to deal > with backward-compatibility with those implementations that behave > according to current standards, so I'm not sure how compelling it is. To all intents and purposes, there is no backwards compatibility problem because there are no implementations. But again, that belongs on another thread. Brian From brian.e.carpenter@gmail.com Tue Feb 22 13:29:33 2011 Return-Path: X-Original-To: ipv6@core3.amsl.com Delivered-To: ipv6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E5D863A6916 for ; Tue, 22 Feb 2011 13:29:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.448 X-Spam-Level: X-Spam-Status: No, score=-103.448 tagged_above=-999 required=5 tests=[AWL=0.151, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wb5nS6FkrhIr for ; Tue, 22 Feb 2011 13:29:33 -0800 (PST) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id E9BB53A6973 for ; Tue, 22 Feb 2011 13:29:32 -0800 (PST) Received: by fxm15 with SMTP id 15so4162777fxm.31 for ; Tue, 22 Feb 2011 13:30:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:organization:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=rwxgE3sRtAJWbICqlxMTMuFaQRq9CPkUNKeba6jk5Fw=; b=M/2HMgHTHuKL5pVep+I1N6/Wg3wcHt2arHAU4AjUGBCk+j+LyDAu2wYbInhdKTH+3w Xel+Q2WMfG//cIZzHgPOi7U8u6hLo1gKto3GOtcJ1psbdvarUSxBW14OmEVdQpoubQRj Buax0xcpI9YFvuv17mYOaP/DlKWfm5cvX7GQQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; b=t10Lh5aR/QcdXeqy/CLIYfMsbz6hNrI98rwovtrgNKGEM25CzgGrf23m2ZOvBk+CXA AhB+TWESw/kH7Glw2cknuPlx7iTwbqM/roR8lX2we+JXbby4ZiOKqhzxEHiIrGSmAMaW b0T7Zf9HLqgCyJx40DglNQzshshQNKO40CpD8= Received: by 10.223.36.220 with SMTP id u28mr28762fad.11.1298410212896; Tue, 22 Feb 2011 13:30:12 -0800 (PST) Received: from [130.216.38.124] (stf-brian.sfac.auckland.ac.nz [130.216.38.124]) by mx.google.com with ESMTPS id y1sm3299644fak.39.2011.02.22.13.30.09 (version=SSLv3 cipher=OTHER); Tue, 22 Feb 2011 13:30:12 -0800 (PST) Message-ID: <4D642ADE.6070006@gmail.com> Date: Wed, 23 Feb 2011 10:30:06 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: John Leslie Subject: Re: 6MAN WG Last Call: References: <7B63F7B6-D788-4A05-9722-C1CAAA42B754@gmail.com> <201101171932.p0HJWU58003756@cichlid.raleigh.ibm.com> <4D5EC960.9080202@gmail.com> <20110221122843.GB5152@verdi> <4D62D407.9050307@gmail.com> <4D642721.2010603@gmail.com> <20110222212324.GI5152@verdi> In-Reply-To: <20110222212324.GI5152@verdi> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: 6man Mailing List , Pekka Savola X-BeenThere: ipv6@ietf.org 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: , X-List-Received-Date: Tue, 22 Feb 2011 21:29:34 -0000 On 2011-02-23 10:23, John Leslie wrote: > Brian E Carpenter wrote: >> On 2011-02-22 19:24, Pekka Savola wrote: >>> Which part of 3697 that is relevant to this document is plain >>> confusing? Those that pertain to this spec are IMHO in Section 3 which >>> seems clear enough to me (copied below). >> But this text will be completely different in 3697bis. I really >> wouldn't want to set people off coding according to something that >> we already know will change. > > All the more reason this document should mention both 3697 _and_ that > we expect it to change. That would do no harm. Brian From pekkas@netcore.fi Tue Feb 22 13:35:47 2011 Return-Path: X-Original-To: ipv6@core3.amsl.com Delivered-To: ipv6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8FD573A6968 for ; Tue, 22 Feb 2011 13:35:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.592 X-Spam-Level: X-Spam-Status: No, score=-102.592 tagged_above=-999 required=5 tests=[AWL=0.007, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jNkfO7E7beTH for ; Tue, 22 Feb 2011 13:35:46 -0800 (PST) Received: from netcore.fi (eunet-gw.ipv6.netcore.fi [IPv6:2001:670:86:3001::1]) by core3.amsl.com (Postfix) with ESMTP id 37A0E3A6938 for ; Tue, 22 Feb 2011 13:35:44 -0800 (PST) Received: from netcore.fi (localhost [127.0.0.1]) by netcore.fi (8.13.8/8.13.8) with ESMTP id p1MLaJun021840 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 22 Feb 2011 23:36:19 +0200 Received: from localhost (pekkas@localhost) by netcore.fi (8.13.8/8.13.8/Submit) with ESMTP id p1MLaJsK021837; Tue, 22 Feb 2011 23:36:19 +0200 Date: Tue, 22 Feb 2011 23:36:19 +0200 (EET) From: Pekka Savola To: Brian E Carpenter Subject: Re: 6MAN WG Last Call: In-Reply-To: <4D642A32.9040406@gmail.com> Message-ID: References: <7B63F7B6-D788-4A05-9722-C1CAAA42B754@gmail.com> <201101171932.p0HJWU58003756@cichlid.raleigh.ibm.com> <4D5EC960.9080202@gmail.com> <20110221122843.GB5152@verdi> <4D62D407.9050307@gmail.com> <4D642721.2010603@gmail.com> <4D642A32.9040406@gmail.com> User-Agent: Alpine 2.02 (LRH 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: clamav-milter 0.96.5 at otso.netcore.fi X-Virus-Status: Clean Cc: 6man Mailing List X-BeenThere: ipv6@ietf.org 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: , X-List-Received-Date: Tue, 22 Feb 2011 21:35:47 -0000 On Wed, 23 Feb 2011, Brian E Carpenter wrote: > To all intents and purposes, there is no backwards compatibility > problem because there are no implementations. But again, that > belongs on another thread. You must have some other definition of "implementation" than I do. 39% of hosts in a study set a non-zero flow label. http://www.maths.tcd.ie/~dwmalone/p/ec2nd05.pdf -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From brian.e.carpenter@gmail.com Tue Feb 22 17:46:53 2011 Return-Path: X-Original-To: ipv6@core3.amsl.com Delivered-To: ipv6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ABD263A6984 for ; Tue, 22 Feb 2011 17:46:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.452 X-Spam-Level: X-Spam-Status: No, score=-103.452 tagged_above=-999 required=5 tests=[AWL=0.147, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w-vt9nv9Iqaj for ; Tue, 22 Feb 2011 17:46:52 -0800 (PST) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by core3.amsl.com (Postfix) with ESMTP id 7A8893A6981 for ; Tue, 22 Feb 2011 17:46:52 -0800 (PST) Received: by eye13 with SMTP id 13so897746eye.31 for ; Tue, 22 Feb 2011 17:47:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:organization:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=+yI19eNOfecg+yFLUYeaJLYucJTXV7xtg6W86aSHMaE=; b=xPIKLga9B+TY74yEo4tigmxkQnY5LOika15P1OQt47p1+N06bMwAmACpupB9fEIQfy 9Ct8xJKk65Y/ZycfbzmJ4NyCTrYenRZDwd+hqXC1rDkdscWXb6fLgt9At25g4IbUnL6H QwFIbemTSKqwqrq3Z/zq1wh2XoGWqZChwEIrs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; b=cNyYectK12zJy6Xsp+nDoD1asPOG1/TvG8DDoTOvhXjm0MyhQwxafUSGt3gG6RKrP5 QyrPCbvAN8rzr85PlZsi83kSBP+69CtHi/rPDZRebrpQJ9+WgtC0539vTRgGOE6faa22 L5zGuoUM3x57RGpw0d1rWO9V5iFAruMSmuBw0= Received: by 10.213.30.3 with SMTP id s3mr3779283ebc.22.1298425656910; Tue, 22 Feb 2011 17:47:36 -0800 (PST) Received: from [130.216.38.124] (stf-brian.sfac.auckland.ac.nz [130.216.38.124]) by mx.google.com with ESMTPS id x54sm6570955eeh.17.2011.02.22.17.47.33 (version=SSLv3 cipher=OTHER); Tue, 22 Feb 2011 17:47:36 -0800 (PST) Message-ID: <4D646742.9050506@gmail.com> Date: Wed, 23 Feb 2011 14:47:46 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Pekka Savola Subject: Flow label prevalence [6MAN WG Last Call: ] References: <7B63F7B6-D788-4A05-9722-C1CAAA42B754@gmail.com> <201101171932.p0HJWU58003756@cichlid.raleigh.ibm.com> <4D5EC960.9080202@gmail.com> <20110221122843.GB5152@verdi> <4D62D407.9050307@gmail.com> <4D642721.2010603@gmail.com> <4D642A32.9040406@gmail.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: 6man Mailing List X-BeenThere: ipv6@ietf.org 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: , X-List-Received-Date: Wed, 23 Feb 2011 01:46:53 -0000 Pekka, Thanks for the reference. Most people who have analysed traces have seen nothing but zero flow labels, but boring data like that don't get published. This study was reported in 2005. The hosts involved were non-representative; the paper says that only 84 hosts (out of 1104) set the label *consistently* per flow, and those were all "patched FreeBSD or Solaris". The ones that set it inconsistently were FreeBSD or NetBSD. That may be a significant fraction of hosts on a university network, but they are negligible in the network as a whole. However, we should cite the reference. Actually it doesn't matter so much. The worst effect of legacy hosts setting the flow label under RFC2460 or RFC3697 rules is that the label values are not uniformly distributed across the 2^20 possible values. The way we're writing 3697bis and draft-ietf-6man-flow-ecmp will tolerate this, even if it is not the recommended behaviour. Brian On 2011-02-23 10:36, Pekka Savola wrote: > On Wed, 23 Feb 2011, Brian E Carpenter wrote: >> To all intents and purposes, there is no backwards compatibility >> problem because there are no implementations. But again, that >> belongs on another thread. > > You must have some other definition of "implementation" than I do. > > 39% of hosts in a study set a non-zero flow label. > > http://www.maths.tcd.ie/~dwmalone/p/ec2nd05.pdf > From yhb810501@gmail.com Thu Feb 24 06:17:32 2011 Return-Path: X-Original-To: ipv6@core3.amsl.com Delivered-To: ipv6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5C2E93A68DF for ; Thu, 24 Feb 2011 06:17:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.998 X-Spam-Level: X-Spam-Status: No, score=-2.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_39=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vesuqoPxUnVt for ; Thu, 24 Feb 2011 06:17:31 -0800 (PST) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by core3.amsl.com (Postfix) with ESMTP id 8EA0C3A6812 for ; Thu, 24 Feb 2011 06:17:31 -0800 (PST) Received: by pzk30 with SMTP id 30so116600pzk.31 for ; Thu, 24 Feb 2011 06:18:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:from:to:cc:subject:date:mime-version :content-type:x-priority:x-msmail-priority:importance:x-mailer :x-mimeole; bh=g7y6DMuC8uuspaZD4xRwOtwZfaS1nQLaNHvE2REMI0s=; b=eR/iQxweRZuq6Y9CUhIX8fDmcvHQZF0TZ+G7P9SWzgi0Bv31nV2sCJiaf1kvXYi21k c1LKUR7Je85vdxfmgi1NTqOHTkfCiaBA6RIffkqfNhjvZHkpLwrJOmBMPaqZ6RtX3obN u9f0qCSnJqQ8tnJ6ZITKtArzmPkQYN1USghus= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:from:to:cc:subject:date:mime-version:content-type :x-priority:x-msmail-priority:importance:x-mailer:x-mimeole; b=voi7u3Fbu1xNT2GvCU4Of/+L/EZ4PhMNVuXdLbNmylliFVId7WV/VbJ5rM6M0EYydc ICEmzb5fCkZSF4pMqgAWC0tvSw+oH5h8wX4p3VUwGgnuTKw2T2sRmZQW9YHDhwYHJmK1 2N/WrVqDWyhqD0M9SqV0xv2EngeNpVnpCn5sY= Received: by 10.143.37.20 with SMTP id p20mr678182wfj.338.1298557100947; Thu, 24 Feb 2011 06:18:20 -0800 (PST) Received: from yhbPC ([220.200.0.167]) by mx.google.com with ESMTPS id n4sm11769075wfl.2.2011.02.24.06.18.16 (version=SSLv3 cipher=OTHER); Thu, 24 Feb 2011 06:18:19 -0800 (PST) Message-ID: From: "Yu Hua bing" To: Subject: draft-yhb-6man-nd-improvement-00 Date: Thu, 24 Feb 2011 22:18:04 +0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0009_01CBD470.B4CF20D0" X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 14.0.8089.726 X-MimeOLE: Produced By Microsoft MimeOLE V14.0.8089.726 X-Mailman-Approved-At: Thu, 24 Feb 2011 06:42:57 -0800 Cc: =?gb2312?B?0+Agu6qx+A==?= X-BeenThere: ipv6@ietf.org 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: , X-List-Received-Date: Thu, 24 Feb 2011 14:20:33 -0000 ÕâÊÇÒ»·â MIME ¸ñʽµÄ¶à·½Óʼþ¡£ ------=_NextPart_000_0009_01CBD470.B4CF20D0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: quoted-printable Hello, what do you think of this draft? http://datatracker.ietf.org/doc/draft-yhb-6man-nd-improvement/ Abstract This document describes the improvement to neighbor discovery. When an IPv6 address is deleted on a node, the node will send a neighbor=20 advertisement with a "Deleted" flag set to all link-local nodes. If the IPv6 address has been configured on another node, and it is in duplicate state, it will perform DAD(Duplicate Address Detection) again. If DAD succeeds, the IPv6 address will be assigned to the =20 node. If the IPv6 address exists in the neighbor cache on the other nodes, when the neighbor advertisement with deleted flag set arrived, they=20 know the neighbor is unreachable and delete the neighbor cache entry. ------=_NextPart_000_0009_01CBD470.B4CF20D0 Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable
Hello, what do you think of this = draft?
 
 
h= ttp://datatracker.ietf.org/doc/draft-yhb-6man-nd-improvement/<= /DIV>
Abstract

   This = document=20 describes the improvement to neighbor discovery. When
   an = IPv6=20 address is deleted on a node, the node will send a neighbor =
  =20 advertisement with a "Deleted" flag set to all link-local = nodes.
  =20 If the IPv6 address has been configured on another node, and it=20 is
   in duplicate state, it will perform DAD(Duplicate = Address=20 Detection)
   again. If DAD succeeds, the IPv6 address will = be=20 assigned to the 
   node.
   If the IPv6 = address=20 exists in the neighbor cache on the other nodes,
   when = the=20 neighbor advertisement with deleted flag set arrived, they =
   know=20 the neighbor is unreachable and delete the neighbor cache=20 entry.

------=_NextPart_000_0009_01CBD470.B4CF20D0-- From yhb810501@gmail.com Thu Feb 24 06:19:20 2011 Return-Path: X-Original-To: ipv6@core3.amsl.com Delivered-To: ipv6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4305D3A6889 for ; Thu, 24 Feb 2011 06:19:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_53=0.6, J_CHICKENPOX_72=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cD3WNV0ufASY for ; Thu, 24 Feb 2011 06:19:19 -0800 (PST) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by core3.amsl.com (Postfix) with ESMTP id 356B43A6812 for ; Thu, 24 Feb 2011 06:19:19 -0800 (PST) Received: by wyb42 with SMTP id 42so608868wyb.31 for ; Thu, 24 Feb 2011 06:20:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:from:to:cc:subject:date:mime-version :content-type:x-priority:x-msmail-priority:importance:x-mailer :x-mimeole; bh=YNbksriGdP/trOxCbtD7N7WC31ev2Bk1YMFbj2fj5bg=; b=dr8/33i8s/F4D6cCQ9mnP5xAF1SSOLiLxgePsp8mEuEtQbOR7Kn0wJy9ZqeWnzJvr8 MvJ0BURqgf74Hx7C0+7ppNmR/1hItQK3LTcEP1JFfwj4rARW7OMPt5B+thCBVFYc5C2U NxguOVN0BtX3gQOpJ48vjurfRirsSaKv8gS7Q= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:from:to:cc:subject:date:mime-version:content-type :x-priority:x-msmail-priority:importance:x-mailer:x-mimeole; b=qOCry4Qgh6+dBgcFpJFIerj0EElaliGN2w3FLxhejhzDJr9FQ5JLN6a8O/91t4pFfM 2q17Ia7Prn5hdgcTEfQwL+MAtSzBhqHUmQTjjVqiJSGCnL1jd55olN2eoiRMlXbTXzvo 4ZEbeDS+jO+VdEzjyPwCzP3h4xseUkWy7ZOWY= Received: by 10.227.10.84 with SMTP id o20mr856613wbo.140.1298557208228; Thu, 24 Feb 2011 06:20:08 -0800 (PST) Received: from yhbPC ([220.200.0.167]) by mx.google.com with ESMTPS id w25sm750297wbd.17.2011.02.24.06.20.01 (version=SSLv3 cipher=OTHER); Thu, 24 Feb 2011 06:20:05 -0800 (PST) Message-ID: <1F1C22A18D2A45B39CFF1015DFCD3BA5@yhbPC> From: "Yu Hua bing" To: Subject: draft-yhb-6man-ra-privacy-flag-00 Date: Thu, 24 Feb 2011 22:19:49 +0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_000F_01CBD470.F3387420" X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 14.0.8089.726 X-MimeOLE: Produced By Microsoft MimeOLE V14.0.8089.726 X-Mailman-Approved-At: Thu, 24 Feb 2011 06:42:57 -0800 Cc: =?gb2312?B?0+Agu6qx+A==?= X-BeenThere: ipv6@ietf.org 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: , X-List-Received-Date: Thu, 24 Feb 2011 14:20:38 -0000 ÕâÊÇÒ»·â MIME ¸ñʽµÄ¶à·½Óʼþ¡£ ------=_NextPart_000_000F_01CBD470.F3387420 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: quoted-printable Hello, what do you think of this draft? http://datatracker.ietf.org/doc/draft-yhb-6man-ra-privacy-flag/ Abstract The temporary addresses described by RFC4941 makes it more difficult for eavesdroppers and other information collectors to track the=20 hosts,but also bring trouble to the network administrators:"when the=20 network is in trouble,it is difficult to find out which host is=20 attacking the other hosts."So some network administrators don't hope that the hosts use the temporary addresses. This document provides a=20 solution to these network administrators,and they can specify whether the prefixes can be used to generate the temporary addresses. ------=_NextPart_000_000F_01CBD470.F3387420 Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable
Hello, what do you think of this = draft?
 
= http://datatracker.ietf.org/doc/draft-yhb-6man-ra-privacy-flag/
 
Abstract

   The = temporary=20 addresses described by RFC4941 makes it more difficult
   = for=20 eavesdroppers and other information collectors to track the =
  =20 hosts,but also bring trouble to the network administrators:"when the=20
   network is in trouble,it is difficult to find out which = host is=20
   attacking the other hosts."So some network = administrators don't=20 hope
   that the hosts use the temporary addresses. This = document=20 provides a
   solution to these network administrators,and = they=20 can specify whether
   the prefixes can be used to generate = the=20 temporary addresses.

------=_NextPart_000_000F_01CBD470.F3387420-- From jhw@apple.com Thu Feb 24 09:34:23 2011 Return-Path: X-Original-To: ipv6@core3.amsl.com Delivered-To: ipv6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6D8753A6803 for ; Thu, 24 Feb 2011 09:34:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ti+bH+JDwjTF for ; Thu, 24 Feb 2011 09:34:22 -0800 (PST) Received: from mail-out4.apple.com (mail-out4.apple.com [17.254.13.23]) by core3.amsl.com (Postfix) with ESMTP id B9B733A6800 for ; Thu, 24 Feb 2011 09:34:22 -0800 (PST) Received: from relay14.apple.com (relay14.apple.com [17.128.113.52]) by mail-out4.apple.com (Postfix) with ESMTP id F4105D43B38A for ; Thu, 24 Feb 2011 09:35:12 -0800 (PST) X-AuditID: 11807134-b7c40ae000006cb9-e1-4d6696d09e74 Received: from elliott.apple.com (elliott.apple.com [17.151.62.13]) by relay14.apple.com (Apple SCV relay) with SMTP id 34.06.27833.0D6966D4; Thu, 24 Feb 2011 09:35:12 -0800 (PST) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=us-ascii Received: from [172.16.1.20] ([75.101.54.88]) by elliott.apple.com (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008; 32bit)) with ESMTPSA id <0LH400HJTU6OMX30@elliott.apple.com> for ipv6@ietf.org; Thu, 24 Feb 2011 09:35:12 -0800 (PST) Subject: Re: draft-yhb-6man-ra-privacy-flag-00 From: james woodyatt X-Priority: 3 In-reply-to: <1F1C22A18D2A45B39CFF1015DFCD3BA5@yhbPC> Date: Thu, 24 Feb 2011 09:35:12 -0800 Message-id: <35600041-1CD0-4F46-9738-51B4D47B7D11@apple.com> References: <1F1C22A18D2A45B39CFF1015DFCD3BA5@yhbPC> To: ipv6@ietf.org X-Mailer: Apple Mail (2.1082) X-Brightmail-Tracker: AAAAAA== X-BeenThere: ipv6@ietf.org 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: , X-List-Received-Date: Thu, 24 Feb 2011 17:34:23 -0000 On Feb 24, 2011, at 6:19 AM, Yu Hua bing wrote: > > Hello, what do you think of this draft? > I don't see why using A=0 in the PIO is insufficient for this purpose. That said, I also think a huge flaw in the draft is that existing hosts interpret the currently unused and reserved bit in the reverse sense, i.e. that privacy addresses are allowed when the value is zero. If you want to propose a flag that expressly allows SLAAC without RFC 4941 privacy addresses, then the sense of the bit needs to be reversed. For example, the conceptual variable would be DisablePrivacyAddrs, and the bit in the PIO would be named the NoPrivacy flag. -- james woodyatt member of technical staff, core os networking From remi@remlab.net Thu Feb 24 09:44:01 2011 Return-Path: X-Original-To: ipv6@core3.amsl.com Delivered-To: ipv6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 00FC23A6817 for ; Thu, 24 Feb 2011 09:44:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id giWmIGhpDrA3 for ; Thu, 24 Feb 2011 09:44:00 -0800 (PST) Received: from yop.chewa.net (yop.chewa.net [91.121.105.214]) by core3.amsl.com (Postfix) with ESMTP id 142533A67EF for ; Thu, 24 Feb 2011 09:44:00 -0800 (PST) Received: from basile.remlab.net (cs27069010.pp.htv.fi [89.27.69.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: remi) by yop.chewa.net (Postfix) with ESMTPSA id 9409C177B; Thu, 24 Feb 2011 18:44:47 +0100 (CET) From: "=?iso-8859-15?q?R=E9mi?= Denis-Courmont" Organization: Remlab.net To: ipv6@ietf.org Subject: Re: draft-yhb-6man-nd-improvement-00 Date: Thu, 24 Feb 2011 19:44:45 +0200 User-Agent: KMail/1.13.5 (Linux/2.6.37.1; KDE/4.4.5; i686; ; ) References: In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: quoted-printable Message-Id: <201102241944.45964.remi@remlab.net> Cc: =?utf-8?q?=E4=BD=99_=E5=8D=8E=E5=85=B5?= , Yu Hua bing X-BeenThere: ipv6@ietf.org 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: , X-List-Received-Date: Thu, 24 Feb 2011 17:44:01 -0000 Le jeudi 24 f=E9vrier 2011 16:18:04 Yu Hua bing, vous avez =E9crit : > Hello, what do you think of this draft? It is far too easy for a node of the subnet to hijack an address by spoofin= g=20 the deleted flag... Besides, nodes often learn that they're going off-link too late to send the= =20 deletion notice anyway. =2D-=20 R=E9mi Denis-Courmont http://www.remlab.info/ http://fi.linkedin.com/in/remidenis From rja.lists@gmail.com Thu Feb 24 11:02:43 2011 Return-Path: X-Original-To: ipv6@core3.amsl.com Delivered-To: ipv6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ED6C03A6807 for ; Thu, 24 Feb 2011 11:02:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.424 X-Spam-Level: X-Spam-Status: No, score=-3.424 tagged_above=-999 required=5 tests=[AWL=0.175, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AsgRXb3grJ2h for ; Thu, 24 Feb 2011 11:02:42 -0800 (PST) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by core3.amsl.com (Postfix) with ESMTP id A9A573A67DA for ; Thu, 24 Feb 2011 11:02:42 -0800 (PST) Received: by qwh6 with SMTP id 6so768402qwh.31 for ; Thu, 24 Feb 2011 11:03:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:from:content-type:content-transfer-encoding :subject:date:message-id:to:mime-version:x-mailer; bh=0YS5jV3lsFeR7n+cx2dWtj6rkMzLQi9ory8QRrlWvPo=; b=rE0EhZofH/FZ3aYUy/HjlrQcTk8NLKaxclh7dGQKgPNeAPCufDHjCoQVHe3a0EbiNv eglCeC5SPmulYc/2tav2nUXX/7B5CAYGNKVnm3Awz2RLGd8U/jyeOF4m7qk88EKiVHgE AscH2C9IXHfEVTlCiCoJZDwCOYksGC/UE49WQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:content-type:content-transfer-encoding:subject:date:message-id :to:mime-version:x-mailer; b=bPUZf0UdrS7uIkvFdo9rmP5mFHUdCftp2EhevLhoVpxUq5AiLv4D08J4xBVP84+v+c rzPv3tPMTrMVrWHhGHWlrPcXtaeIFBPlyOcQSvkomzgw3XEO0OkabkT9deRI42zMBgnC UAXMr9cd71gQGzReCekHL+nvAdiDV/cYlBFxA= Received: by 10.224.11.129 with SMTP id t1mr1137249qat.382.1298574212610; Thu, 24 Feb 2011 11:03:32 -0800 (PST) Received: from [10.30.20.7] (pool-96-225-170-25.nrflva.fios.verizon.net [96.225.170.25]) by mx.google.com with ESMTPS id t7sm6626780qcs.16.2011.02.24.11.03.31 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 24 Feb 2011 11:03:31 -0800 (PST) From: RJ Atkinson Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: Re: draft-yhb-6man-ra-privacy-flag-00 Date: Thu, 24 Feb 2011 14:03:29 -0500 Message-Id: To: ipv6@ietf.org Mime-Version: 1.0 (Apple Message framework v1082) X-Mailer: Apple Mail (2.1082) X-BeenThere: ipv6@ietf.org 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: , X-List-Received-Date: Thu, 24 Feb 2011 19:02:44 -0000 On 24 Feb 2011 at 09:35:12 -0800, James Woodyatt wrote: >> On Feb 24, 2011, at 6:19 AM, Yu Hua bing wrote: >> Hello, what do you think of this draft?=20 >> http://datatracker.ietf.org/doc/draft-yhb-6man-ra-privacy-flag/ >=20 >=20 > I don't see why using A=3D0 in the PIO is insufficient for this = purpose. User sites have a very wide range of deployment models. The best way to deploy IPv6 is to enable users to deploy in a manner suitable to their own local needs, rather than restrict them = arbitrarily. There exist a number of sites that want to enable SLAAC, but do NOT = enable/ permit deployment of the (psuedo-)privacy extension. A common reason is=20= to reduce operating costs (e.g. eliminate DHCP server/ops costs, reduce capital costs, reduce troubleshooting costs, reduce auditing costs). There are also sites that want to enable SLAAC and also enable the (pseudo-)privacy extension. =20 (Not relevant here, but there are also sites that want SLAAC with DHCP=20= available for extra info, DHCP and NOT SLAAC, and so on. :-) The existing "A=3D0" bit is not sufficient for all cases,=20 as you seem to acknowledge later on, no matter how one interprets it. > That said, I also think a huge flaw in the draft is that existing = hosts > interpret the currently unused and reserved bit in the reverse sense, > i.e. that privacy addresses are allowed when the value is zero. Interesting. Examples of such hosts using a reserved bit=20 for that specific meaning ? > If you want to propose a flag that expressly allows SLAAC without RFC = 4941 > privacy addresses, then the sense of the bit needs to be reversed. = For example, > the conceptual variable would be DisablePrivacyAddrs, and the bit in = the PIO > would be named the NoPrivacy flag. It is equally valid to have a conceptual variable EnablePrivacyAddrs, with the bit being named the Privacy flag. Yours, Ran Atkinson From vishwas.ietf@gmail.com Thu Feb 24 21:49:12 2011 Return-Path: X-Original-To: ipv6@core3.amsl.com Delivered-To: ipv6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EFADF3A691E for ; Thu, 24 Feb 2011 21:49:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.649 X-Spam-Level: X-Spam-Status: No, score=-2.649 tagged_above=-999 required=5 tests=[AWL=0.350, BAYES_00=-2.599, J_CHICKENPOX_39=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yg2evRrLjT3m for ; Thu, 24 Feb 2011 21:49:10 -0800 (PST) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by core3.amsl.com (Postfix) with ESMTP id 8905B3A68A0 for ; Thu, 24 Feb 2011 21:49:10 -0800 (PST) Received: by wyb42 with SMTP id 42so1371783wyb.31 for ; Thu, 24 Feb 2011 21:50:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=a7IJ1eD4wlda0+VgRnP0IGIEqss5szVdNDRB7AUPnVA=; b=O7+Z0wWaLOUZ9Av1ddGZgN0vm/VMHzQMy2uyAECiN23hwOGYIbbXz/vwfsSWpZqHnt VevzbqhtyyuEJZPiKX4GfOHeCk87BZOWBLKXr+NjjTncIAwBHFv6bYlciED/chGY0HET GD4uIOgBbIGVcNNlKfXByp1Wt0JQTajkyv0QQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=IrgqqWEiGepeBx5D7QCwgc/duh/6OQgW83JlnqyOeHe5MdVMuDTNuMu4W6MiIE8mGl RvEhozcvsZqJOOG0FiIjDIe/GwRXQXbT76awQ9WiVmNhoMMIlbpow3pxFjI/mCXucgFe 0uAko+QROx0lENHVh9A7wTOJM4PqzTFWY/8t8= MIME-Version: 1.0 Received: by 10.216.205.213 with SMTP id j63mr6425333weo.60.1298613001151; Thu, 24 Feb 2011 21:50:01 -0800 (PST) Received: by 10.216.47.81 with HTTP; Thu, 24 Feb 2011 21:50:00 -0800 (PST) In-Reply-To: References: Date: Thu, 24 Feb 2011 21:50:00 -0800 Message-ID: Subject: Re: draft-yhb-6man-nd-improvement-00 From: Vishwas Manral To: Yu Hua bing Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: =?GB2312?B?0+Agu6qx+A==?= , ipv6@ietf.org X-BeenThere: ipv6@ietf.org 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: , X-List-Received-Date: Fri, 25 Feb 2011 05:49:12 -0000 Hi Yu, Sounds like a good small optimization to me. Thanks, Vishwas 2011/2/24 Yu Hua bing : > Hello, what do you think of this draft? > > > http://datatracker.ietf.org/doc/draft-yhb-6man-nd-improvement/ > Abstract > > =A0=A0 This document describes the improvement to neighbor discovery. Whe= n > =A0=A0 an IPv6 address is deleted on a node, the node will send a neighbo= r > =A0=A0 advertisement with a "Deleted" flag set to all link-local nodes. > =A0=A0 If the IPv6 address has been configured on another node, and it is > =A0=A0 in duplicate state, it will perform DAD(Duplicate Address Detectio= n) > =A0=A0 again. If DAD succeeds, the IPv6 address will be assigned to the > =A0=A0 node. > =A0=A0 If the IPv6 address exists in the neighbor cache on the other node= s, > =A0=A0 when the neighbor advertisement with deleted flag set arrived, the= y > =A0=A0 know the neighbor is unreachable and delete the neighbor cache ent= ry. > > From yhb810501@gmail.com Fri Feb 25 04:52:05 2011 Return-Path: X-Original-To: ipv6@core3.amsl.com Delivered-To: ipv6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A66CC3A69A7 for ; Fri, 25 Feb 2011 04:52:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.913 X-Spam-Level: X-Spam-Status: No, score=-2.913 tagged_above=-999 required=5 tests=[AWL=0.085, BAYES_00=-2.599, J_CHICKENPOX_39=0.6, RCVD_IN_DNSWL_LOW=-1, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bE+jYtSMtUSh for ; Fri, 25 Feb 2011 04:52:04 -0800 (PST) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id A8F8C3A69AD for ; Fri, 25 Feb 2011 04:52:04 -0800 (PST) Received: by iwl42 with SMTP id 42so1196907iwl.31 for ; Fri, 25 Feb 2011 04:52:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:from:to:cc:references:in-reply-to :subject:date:mime-version:content-type:content-transfer-encoding :x-priority:x-msmail-priority:importance:x-mailer:x-mimeole; bh=+8Ij67mAFjSazclT7CSA3jr0oN9XYcF/o7M/frRygBc=; b=Mso8Y3VUdq6M8UlRwsPjEBwMg2Ie0yEw0dG4rR8IMau5lcni0nptmOmEwDRHu+CnM0 a5355z/9r4UgS7o8TT9fwaRXHzf29SIVihOF9EEJg0aM7WluEAnN/7MgZ//7jnoJi8f5 J4fx8wvbR3NZMta8Yo9B/YckL+q6X/Oddor2M= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:from:to:cc:references:in-reply-to:subject:date :mime-version:content-type:content-transfer-encoding:x-priority :x-msmail-priority:importance:x-mailer:x-mimeole; b=Ndfh6SyvaVOyZsweMpYM6WGX1IGH1TBRwLZ6/cJ6qyXm7clOWV+40CcZBYzBXVdy9v vo+vgmeNKh2Wk9Lcpb49kh/rNOac5x839esQWVujqJFIq+mLnLYznRTVVKslvz99tdLt u2Tzo29hKTrFUJP/nbQWU2h4e6hIDgzMRAIqE= Received: by 10.42.173.65 with SMTP id q1mr696157icz.391.1298638374988; Fri, 25 Feb 2011 04:52:54 -0800 (PST) Received: from yhbPC ([220.200.0.167]) by mx.google.com with ESMTPS id i2sm423521icv.15.2011.02.25.04.52.50 (version=SSLv3 cipher=OTHER); Fri, 25 Feb 2011 04:52:53 -0800 (PST) Message-ID: From: "Yu Hua bing" To: "Vishwas Manral" References: In-Reply-To: Subject: Re: draft-yhb-6man-nd-improvement-00 Date: Fri, 25 Feb 2011 20:52:38 +0800 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="ISO-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 14.0.8089.726 X-MimeOLE: Produced By Microsoft MimeOLE V14.0.8089.726 X-Mailman-Approved-At: Fri, 25 Feb 2011 06:33:59 -0800 Cc: ? ?? , ipv6@ietf.org X-BeenThere: ipv6@ietf.org 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: , X-List-Received-Date: Fri, 25 Feb 2011 12:52:05 -0000 Thank you for your support. -------------------------------------------------- From: "Vishwas Manral" Sent: Friday, February 25, 2011 1:50 PM To: "Yu Hua bing" Cc: ; "? ??" Subject: Re: draft-yhb-6man-nd-improvement-00 > Hi Yu, > > Sounds like a good small optimization to me. > > Thanks, > Vishwas > > 2011/2/24 Yu Hua bing : >> Hello, what do you think of this draft? >> >> >> http://datatracker.ietf.org/doc/draft-yhb-6man-nd-improvement/ >> Abstract >> >> This document describes the improvement to neighbor discovery. When >> an IPv6 address is deleted on a node, the node will send a neighbor >> advertisement with a "Deleted" flag set to all link-local nodes. >> If the IPv6 address has been configured on another node, and it is >> in duplicate state, it will perform DAD(Duplicate Address Detection) >> again. If DAD succeeds, the IPv6 address will be assigned to the >> node. >> If the IPv6 address exists in the neighbor cache on the other nodes, >> when the neighbor advertisement with deleted flag set arrived, they >> know the neighbor is unreachable and delete the neighbor cache entry. >> >> > From Internet-Drafts@ietf.org Fri Feb 25 13:30:04 2011 Return-Path: X-Original-To: ipv6@core3.amsl.com Delivered-To: ipv6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2FA693A6A57; Fri, 25 Feb 2011 13:30:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.562 X-Spam-Level: X-Spam-Status: No, score=-102.562 tagged_above=-999 required=5 tests=[AWL=0.037, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id evfNGXgJM3Zl; Fri, 25 Feb 2011 13:30:02 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 37EC73A6A44; Fri, 25 Feb 2011 13:30:02 -0800 (PST) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Subject: I-D Action:draft-ietf-6man-flow-3697bis-01.txt X-Test-IDTracker: no X-IETF-IDTracker: 3.12 Message-ID: <20110225213002.24059.13909.idtracker@localhost> Date: Fri, 25 Feb 2011 13:30:02 -0800 Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org 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: , X-List-Received-Date: Fri, 25 Feb 2011 21:30:04 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPv6 Maintenance Working Group of the IETF. Title : IPv6 Flow Label Specification Author(s) : S. Amante, et al. Filename : draft-ietf-6man-flow-3697bis-01.txt Pages : 14 Date : 2011-02-25 This document specifies the IPv6 Flow Label field and the minimum requirements for IPv6 nodes labeling flows, IPv6 nodes forwarding labeled packets, and flow state establishment methods. Even when mentioned as examples of possible uses of the flow labeling, more detailed requirements for specific use cases are out of scope for this document. The usage of the Flow Label field enables efficient IPv6 flow classification based only on IPv6 main header fields in fixed positions. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-6man-flow-3697bis-01.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-6man-flow-3697bis-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-02-25132744.I-D@ietf.org> --NextPart-- From Internet-Drafts@ietf.org Fri Feb 25 13:30:05 2011 Return-Path: X-Original-To: ipv6@core3.amsl.com Delivered-To: ipv6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E9BB03A6A43; Fri, 25 Feb 2011 13:30:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.563 X-Spam-Level: X-Spam-Status: No, score=-102.563 tagged_above=-999 required=5 tests=[AWL=0.036, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id POptKHCTf4Dz; Fri, 25 Feb 2011 13:30:03 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7A7CD3A6A48; Fri, 25 Feb 2011 13:30:03 -0800 (PST) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Subject: I-D Action:draft-ietf-6man-flow-update-03.txt X-Test-IDTracker: no X-IETF-IDTracker: 3.12 Message-ID: <20110225213003.24059.68593.idtracker@localhost> Date: Fri, 25 Feb 2011 13:30:03 -0800 Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org 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: , X-List-Received-Date: Fri, 25 Feb 2011 21:30:05 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPv6 Maintenance Working Group of the IETF. Title : Rationale for update to the IPv6 flow label specification Author(s) : S. Amante, et al. Filename : draft-ietf-6man-flow-update-03.txt Pages : 12 Date : 2011-02-25 Various published proposals for use of the IPv6 flow label are incompatible with its original specification in RFC 3697. Furthermore, very little practical use is made of the flow label, partly due to some uncertainties about the correct interpretation of the specification. This document discusses and motivates changes to the specification in order to clarify it, and to introduce some additional flexibility. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-6man-flow-update-03.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-6man-flow-update-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-02-25132758.I-D@ietf.org> --NextPart-- From brian.e.carpenter@gmail.com Fri Feb 25 13:41:19 2011 Return-Path: X-Original-To: ipv6@core3.amsl.com Delivered-To: ipv6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 586333A6A44 for ; Fri, 25 Feb 2011 13:41:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.495 X-Spam-Level: X-Spam-Status: No, score=-103.495 tagged_above=-999 required=5 tests=[AWL=0.104, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pAa532+qrWNG for ; Fri, 25 Feb 2011 13:41:17 -0800 (PST) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by core3.amsl.com (Postfix) with ESMTP id 9DC0B3A6A4E for ; Fri, 25 Feb 2011 13:41:16 -0800 (PST) Received: by wwb22 with SMTP id 22so727722wwb.13 for ; Fri, 25 Feb 2011 13:42:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:organization:user-agent :mime-version:to:subject:content-type; bh=0hPIEPWEOxCNYQ9EHhhmAg0VRHr7hHgVdqE1rqazOBQ=; b=RG2BHEZMWSwh7V9mYKXOdplYJEeNXrCsavwAQc11HYF/ow+mbl3ABQ8BcNhK+lKbJ/ GpFeAiZnBlUtneX9PDyGsmjfbDAGr+f046muhJFvATf8I+SUn58oGYnecnrpLJL/gpcF 54E0g8vvFdmFCfqvnllXX1okzgU/vIULynYd0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to :subject:content-type; b=XRpoRprxvmf8rc1Wu+zKTNZlULqtWSUTKcPBTYO6bz8l1KvzOV6A5YWFMp9PulhhYk jgxo4xzDgpJSAsK6XMcwJtMixoeU7rThrgoYK/Ha0hXGTkmHrxxYXsOX7wmfJ/LFwVHo /kgWt8lZPcXRpFSK8ui0fFaWy2FMvq6TAYP6c= Received: by 10.227.136.79 with SMTP id q15mr2595718wbt.146.1298670129259; Fri, 25 Feb 2011 13:42:09 -0800 (PST) Received: from [10.1.1.4] ([121.98.190.33]) by mx.google.com with ESMTPS id y29sm906826wbd.10.2011.02.25.13.42.05 (version=SSLv3 cipher=OTHER); Fri, 25 Feb 2011 13:42:08 -0800 (PST) Message-ID: <4D682228.7020304@gmail.com> Date: Sat, 26 Feb 2011 10:42:00 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: 6man Subject: Flow label drafts - updates, main open issue Content-Type: multipart/mixed; boundary="------------020109030406030608080006" X-BeenThere: ipv6@ietf.org 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: , X-List-Received-Date: Fri, 25 Feb 2011 21:41:19 -0000 This is a multi-part message in MIME format. --------------020109030406030608080006 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Hi, There are three updated flow label drafts: 1. http://www.ietf.org/internet-drafts/draft-ietf-6man-flow-3697bis-01.txt This is the draft of the updated proposed standard for the flow label. The open issues discussed for the previous draft have been closed according to comments received - see the attached file for details. The authors believe that there is one big issue remaining: Should we delete most of the text concerning stateful methods of handling the flow label? Basically that would mean deleting Section 4 (and corresponding parts of the Security Considerations) and making minor text adjustments elsewhere. This would not mean that stateful methods are excluded for ever - it would just recognise that we are only sure of the stateless approach today. 2. http://www.ietf.org/internet-drafts/draft-ietf-6man-flow-update-03.txt This draft is background rationale for the previous one, with minor updates to keep it in synch. 3. http://www.ietf.org/internet-drafts/draft-ietf-6man-flow-ecmp-01.txt This is the ECMP/LAG draft updated according to WG Last Call comments. Brian + co-authors --------------020109030406030608080006 Content-Type: text/plain; name="flowIssues-res.txt" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="flowIssues-res.txt" VGhpcyBub3RlIGV4cGxhaW5zIGhvdyB0aGUgb3BlbiBpc3N1ZXMgbm90ZWQgZm9yIGRyYWZ0 LWlldGYtNm1hbi1mbG93LTM2OTdiaXMtMDANCmhhdmUgYmVlbiByZXNvbHZlZCBpbiBkcmFm dC1pZXRmLTZtYW4tZmxvdy0zNjk3YmlzLTAxLg0KDQotLS0tLS0tLS0tLS0tLQ0KSVNTVUUg MS4gQSBiYXNpYyBhc3N1bXB0aW9uIGluIFJGQyAzNjk3IGlzIHRoYXQgZmxvdyBsYWJlbGxp bmcgbWVjaGFuaXNtcyB3aWxsDQpiZSBzdGF0ZWZ1bCBhbmQgbWF5IG5lZWQgc2lnbmFsaW5n LiBUaGUgY2hhbmdlcyBkaXNjdXNzZWQgaW4gdGhlIFdHIGNsZWFybHkNCmFkZHJlc3MgYSBz dGF0ZWxlc3MgYXBwcm9hY2ggdGhhdCBuZWVkcyBubyBzaWduYWxpbmcuDQoNClFVRVNUSU9O OiBkbyB3ZSBrZWVwIHRoZSB0ZXh0IGFib3V0IGZsb3cgZXN0YWJsaXNobWVudCBtZXRob2Rz LCBvciBkbyB3ZSBzaW1wbHkNCnJlbW92ZSBpdCBhcyBiZWluZyByZWR1bmRhbnQ/IChUaGlz IGFmZmVjdHMgcXVpdGUgYSBsb3Qgb2YgdGV4dCBpbiB0aGUgZHJhZnQsDQphbmQgdGhlcmUg d2lsbCBiZSBzZXZlcmFsIHNlY29uZGFyeSBpc3N1ZXMgdG8gZGlzY3VzcyBpZiB3ZSBrZWVw IHRoaXMgdGV4dC4pDQoNClBST1BPU0VEIFJFU09MVVRJT046IENsYXJpZnkgdGhhdCB0aGVy ZSBhcmUgdHdvIGF4ZXM6IHN0YXRlbGVzcyB2ZXJzdXMgc3RhdGVmdWwNCmZsb3cgbGFiZWwg YXNzaWdubWVudCBtZWNoYW5pc21zLCBhbmQgbm9uLXNpZ25hbGVkIG9yIHNpZ25hbGVkIGZs b3cgbGFiZWwgdXNhZ2UgbWV0aG9kcy4NCkluZGljYXRlIHRoYXQgc3RhdGVsZXNzLCBub24t c2lnbmFsZWQgaXMgdGhlIGRlZmF1bHQgc29sdXRpb24uIFJlcXVpcmUgYW55IG5vZGUgdGhh dCB1c2VzIA0Kc3RhdGVmdWwgZmxvdyBsYWJlbCBhc3NpZ25tZW50IHRvIHNldCBhbGwgRmxv dyBMYWJlbHMgcHJvcGVybHksIG9yIGF0IGEgbWluaW11bSBub3QgdG8gDQpzZW5kIG91dCBG bG93IExhYmVsIHZhbHVlcyB0aGF0IGFyZSB6ZXJvLiBUaGlzIHJlcXVpcmVzIGEgbmV3IE1V U1QgZm9yIHN1Y2ggbm9kZXM6DQoNCiAgIEhvd2V2ZXIsIGFueSBub2RlIHRoYXQgc2V0cyBm bG93IGxhYmVsIHZhbHVlcyBhY2NvcmRpbmcgdG8gYSBzdGF0ZWZ1bA0KICAgc2NoZW1lIE1V U1QgZW5zdXJlIHRoYXQgcGFja2V0cyBjb25mb3JtIHRvIHRoZSBwcmVzZW50IHNwZWNpZmlj YXRpb24gaWYNCiAgIHRoZXkgYXJlIHNlbnQgb3V0c2lkZSB0aGUgbmV0d29yayBkb21haW4g dXNpbmcgdGhlIHN0YXRlZnVsIHNjaGVtZS4gDQoNCkFkZGl0aW9uYWxseSwgdGhpcyBsZWFk cyB0byBzb21lIHJlb3JkZXJpbmcgb2YgbWF0ZXJpYWwgdG8gc2ltcGxpZnkgdGhlIGxvZ2lj IGZsb3cuDQpBbHNvIG5vdGUgdGhhdCB0aGUgc3RhdGVmdWwgbW9kZWwgaXMgcmVzcG9uc2li bGUgZm9yIGEgY29uc2lkZXJhYmxlIGFtb3VudCBvZg0KdGhlIHRleHQgb24gcG9zc2libGUg dGhlZnQgb2Ygc2VydmljZSBhdHRhY2tzIGluIHRoZSBTZWN1cml0eSBDb25zaWRlcmF0aW9u cy4NCiANCi0tLS0tLS0tLS0tLS0tDQpJU1NVRSAyLiBSRkMgMzY5NyBzdGF0ZXMgdGhhdCBm bG93IGxhYmVsIHZhbHVlcyBtdXN0IGJlIHVuaXF1ZSAoZm9yIGEgZ2l2ZW4gYWRkcmVzcw0K cGFpciBhbmQgd2l0aGluIGEgY2VydGFpbiB0aW1lc2NhbGUpLiBUaGlzIHJlcXVpcmVzIHRo ZSBub2RlIHRoYXQgc2V0cyB0aGUgbGFiZWwNCnRvIGtlZXAgYSBsaXN0IG9mIGxhYmVscyBj dXJyZW50bHkgaW4gdXNlLiBUaGF0IGlzIGEgc2lnbmlmaWNhbnQgY29tcGxpY2F0aW9uDQpm b3IgYSAic3RhdGVsZXNzIiBpbXBsZW1lbnRhdGlvbi4gSWYgdGhlIG1haW4gdXNlIG9mIHRo ZSBmbG93IGxhYmVsIGlzIGZvcg0KbG9hZCBkaXN0cmlidXRpb24sIG92ZXIgYSB2ZXJ5IGxh cmdlIG51bWJlciBvZiBmbG93cywgc3RyaWN0IHVuaXF1ZW5lc3MNCmlzbid0IG5lZWRlZCAt IGEgJ2JpcnRoZGF5IHBhcmFkb3gnIGxldmVsIG9mIGxhYmVsIGNvbGxpc2lvbnMgaXMgbm90 IGEgcHJvYmxlbS4NCg0KUVVFU1RJT046IHNob3VsZCB0aGlzIHN0cmljdCB1bmlxdWVuZXNz IHJlcXVpcmVtZW50IGJlIHJlbGF4ZWQgdG8gJ3VuaXF1ZSB3aXRoIGhpZ2gNCnByb2JhYmls aXR5Jy4NCg0KUFJPUE9TRUQgUkVTT0xVVElPTjogQWxsb3cgdGhlIHVuaXF1ZW5lc3MgcmVx dWlyZW1lbnQgZm9yIHN0YXRlZnVsIGZsb3cgbGFiZWwNCmFzc2lnbm1lbnQgbWVjaGFuaXNt cywgcmVsYXggaXQgZm9yIHN0YXRlbGVzcyBtZWNoYW5pc21zLg0KDQotLS0tLS0tLS0tLS0t LQ0KSVNTVUUgMy4gMzY5N2JpcyBSRUNPTU1FTkRTIHBzZXVkby1yYW5kb20gZmxvdyBsYWJl bCB2YWx1ZXMuIFRoZSBnb2FsIGlzIGJlIGFibGUgdG8gDQp1c2UganVzdCB0aGUgMy10dXBs ZSB7ZGVzdCBhZGRyLCBzb3VyY2UgYWRkciwgbGFiZWx9IGFzIGlucHV0IHRvIGxvYWQNCmRp c3RyaWJ1dGlvbiBoYXNoZXMuIFRoZXJlIGhhdmUgYmVlbiBhIGNvdXBsZSBvZiBvYmplY3Rp b25zIHRvIHRoaXM6DQogLSBUaGlzIHByb3BlcnR5IGlzIG5vdCByZXF1aXJlZCBmb3IgZWZm ZWN0aXZlIGhhc2hlcyBmb3IgbG9hZCBkaXN0cmlidXRpb247DQogLSBOb3QgYWxsIGxvYWQg ZGlzdHJpYnV0aW9uIG1ldGhvZHMgYXJlIHN0YXRpc3RpY2FsLCBzbyB0aGVyZSBtYXkgYmUg c29tZSBuZWVkIGZvcg0KICAgZGV0ZXJtaW5pc3RpYyBmbG93IGxhYmVsIHZhbHVlcy4NCk9u IHRoZSBvdGhlciBoYW5kLCB0aGUgYXJndW1lbnRzIGZvciBmb3JtYWxseSByZWNvbW1lbmRp bmcgcHNldWRvLXJhbmRvbSBsYWJlbHMgYXJlDQp0aGF0DQogLSBwc2V1ZG8tcmFuZG9tbmVz cyBoYXMgc2VjdXJpdHkgdmFsdWUgKGRyYWZ0LWdvbnQtNm1hbi1mbG93bGFiZWwtc2VjdXJp dHkpOw0KIC0gcHNldWRvLXJhbmRvbW5lc3MgZG9lcyBoYXZlIHZhbHVlIGFzIGlucHV0IHRv IGhhc2hlczsNCiAtIGEgTUFZIHdvdWxkIG5vdCBoYXZlIG11Y2ggaW1wYWN0IG9uIGltcGxl bWVudGVycywgc28gbm90aGluZyB3b3VsZCBjaGFuZ2UuDQoNClFVRVNUSU9OOiBkbyB3ZSBj aGFuZ2UgdGhlIHJlY29tbWVuZGF0aW9uIHRvIHNldCBwc2V1ZG8tcmFuZG9tIGZsb3cgbGFi ZWwgdmFsdWVzPw0KDQpQUk9QT1NFRCBSRVNPTFVUSU9OOiBLZWVwIHRoZSByZWNvbW1lbmRh dGlvbiB0byBzZXQgcHNldWRvLXJhbmRvbSB2YWx1ZXMsIGJ1dA0KYWxzbyBzZWUgSVNTVUUg OSAtIGEgdW5pZm9ybSBkaXN0cmlidXRpb24gb2YgdmFsdWVzIGlzIHRoZSBrZXkgcG9pbnQs IGluIGZhY3QuDQpWYXJpb3VzIHRleHQgYWRqdXN0bWVudHMgdG8gZm9jdXMgbW9yZSBvbiB0 aGUgdW5pZm9ybSBkaXN0cmlidXRpb24uDQoNCi0tLS0tLS0tLS0tLS0tDQpJU1NVRSA0LiBU aGUgSW50cm9kdWN0aW9uIHByZXZpb3VzbHkgaW5jbHVkZWQ6DQoNCiAgIERvaW5nIHRoaXMg W3NldHRpbmcgdGhlIGZsb3cgbGFiZWxdDQogICBlbmFibGVzIGxvYWQgc3ByZWFkaW5nIGFu ZCByZWNlaXZlciBvcmllbnRlZCByZXNvdXJjZSBhbGxvY2F0aW9uLCBmb3INCiAgIGV4YW1w bGUuICANCg0KVGhlIHBocmFzZSAicmVjZWl2ZXIgb3JpZW50ZWQgcmVzb3VyY2UgYWxsb2Nh dGlvbiIgaGFzIGJlZW4gZGVsZXRlZCBiZWNhdXNlDQp3ZSBkb24ndCBrbm93IHdoYXQgaXQg bWVhbnMuDQoNClFVRVNUSU9OOiBJcyB0aGlzIGRlbGV0aW9uIE9LPw0KDQpQUk9QT1NFRCBS RVNPTFVUSU9OOiBZZXMsIGRlbGV0ZSBpdC4NCg0KLS0tLS0tLS0tLS0tLS0NCklTU1VFIDUu IFNlY3Rpb24gMiBzYXlzOg0KDQogICBJUHY2IG5vZGVzIE1VU1QgTk9UIGFzc3VtZSB0aGF0 IHRoZSBGbG93IExhYmVsIHZhbHVlIGluIGEgaW5jb21pbmcNCiAgIHBhY2tldCBpcyBpZGVu dGljYWwgdG8gdGhlIHZhbHVlIHNldCBieSB0aGUgc291cmNlIG5vZGUuDQoNClFVRVNUSU9O OiBUaGlzIG5lZWRzIHRvIGJlIHJlY29uY2lsZWQgd2l0aCB0aGUgc2VjdXJpdHkgdXNhZ2Ug bWVudGlvbmVkIGluIA0KZHJhZnQtZ29udC0uIFdvdWxkIFNIT1VMRCBOT1QgYmUgYWNjZXB0 YWJsZT8NCg0KUFJPUE9TRUQgUkVTT0xVVElPTjogUmVwbGFjZSBieToNCiAgIEltcGxlbWVu dGVycyBzaG91bGQgYmUgYXdhcmUgdGhhdCB0aGUgZmxvdyBsYWJlbA0KICAgaXMgYW4gdW5w cm90ZWN0ZWQgZmllbGQgdGhhdCBjb3VsZCBoYXZlIGJlZW4gYWNjaWRlbnRhbGx5DQogICBv ciBpbnRlbnRpb25hbGx5IGNoYW5nZWQgZW4gcm91dGUuIEltcGxlbWVudGF0aW9ucyBNVVNU DQogICB0YWtlIGFwcHJvcHJpYXRlIHN0ZXBzIHRvIHByb3RlY3QgdGhlbXNlbHZlcyBmcm9t IGJlaW5nDQogICB2dWxuZXJhYmxlIHRvIGRlbmlhbCBvZiBzZXJ2aWNlIGFuZCBvdGhlciB0 eXBlcyBvZiBhdHRhY2sgdGhhdA0KICAgY291bGQgcmVzdWx0Lg0KDQogICBBbHNvIGFkZGVk IHNvbWUgcmVsYXRlZCB0ZXh0IGluIHRoZSBTZWN1cml0eSBDb25zaWRlcmF0aW9ucy4NCg0K LS0tLS0tLS0tLS0tLS0NCklTU1VFIDYuIEFzIG5vdGVkIGluIFNlY3Rpb24gMzoNCg0KUVVF U1RJT046IFNob3VsZCB3ZSBpbmNvcnBvcmF0ZSBkcmFmdC1nb250LSBoZXJlLCBvciBsZWF2 ZSBpdCBzZXBhcmF0ZT8NCg0KUFJPUE9TRUQgUkVTT0xVVElPTjogTm8gY29tbWVudHMgcmVj ZWl2ZWQuIFdlIGNhbiBsZWF2ZSBpdCBzZXBhcmF0ZSwgYW5kIG1heQ0KaGF2ZSB0byBkcm9w IGl0IGlmIGl0IHNob3dzIG5vIHNpZ24gb2YgZ2V0dGluZyBvbiB0aGUgc3RhbmRhcmRzIHRy YWNrLg0KDQotLS0tLS0tLS0tLS0tLQ0KSVNTVUUgNy4gU2VjdGlvbiA1IHNheXM6DQoNCiAg IFRvIGVuYWJsZSBhcHBsaWNhdGlvbnMgYW5kIHRyYW5zcG9ydCBwcm90b2NvbHMgdG8gZGVm aW5lIHdoYXQgcGFja2V0cw0KICAgY29uc3RpdHV0ZSBhIGZsb3csIHRoZSBzb3VyY2Ugbm9k ZSBNVVNUIHByb3ZpZGUgbWVhbnMgZm9yIHRoZQ0KICAgYXBwbGljYXRpb25zIGFuZCB0cmFu c3BvcnQgcHJvdG9jb2xzIHRvIHNwZWNpZnkgdGhlIEZsb3cgTGFiZWwgdmFsdWVzDQogICB0 byBiZSB1c2VkIHdpdGggdGhlaXIgZmxvd3MuICBUaGUgdXNlIG9mIHRoZSBtZWFucyB0byBz cGVjaWZ5IEZsb3cNCiAgIExhYmVsIHZhbHVlcyBpcyBzdWJqZWN0IHRvIGFwcHJvcHJpYXRl IHByaXZpbGVnZXMgKHNlZSBTZWN0aW9uIDYuMSkuDQogICBUaGUgc291cmNlIG5vZGUgU0hP VUxEIGJlIGFibGUgdG8gc2VsZWN0IHVudXNlZCBGbG93IExhYmVsIHZhbHVlcyBmb3INCiAg IGZsb3dzIG5vdCByZXF1ZXN0aW5nIGEgc3BlY2lmaWMgdmFsdWUgdG8gYmUgdXNlZC4NCg0K QXMgbm90ZWQgYWJvdmUsIGluIHN0YXRlbGVzcyBsb2FkIGRpc3RyaWJ1dGlvbiwgb2NjYXNp b25hbCBkdXBsaWNhdGUgbGFiZWxzDQpzdXJlbHkgZG9uJ3QgbWF0dGVyLiBBbHNvLCBleHBl cmllbmNlIHN1Z2dlc3RzIHRoYXQgYXBwbGljYXRpb25zIGFuZA0KdHJhbnNwb3J0IHByb3Rv Y29scyBhcmUgdW5saWtlbHkgdG8gZG8gYW55IG9mIHRoaXMsIGFuZCBpdCBpc24ndA0KYSBw cm90b2NvbCBkZXNpZ24gaXNzdWUgYW55d2F5Lg0KDQpRVUVTVElPTjogU2hvdWxkIHdlIHJl ZHVjZSB0aGlzIHdob2xlIHBhcmFncmFwaCB0byBhIFNIT1VMRCBvciBNQVksIG9yIGV2ZW4N CnJlbW92ZSBpdCBhcyBvdXQgb2Ygc2NvcGUgaW4gYSBwcm90b2NvbCBzcGVjPw0KDQpQUk9Q T1NFRCBSRVNPTFVUSU9OOiBEcm9wIGl0Lg0KDQotLS0tLS0tLS0tLS0tLQ0KSVNTVUUgOC4g U2VjdGlvbiA2LjEgc2F5czoNCg0KICAgT25seSBhcHBsaWNhdGlvbnMgd2l0aCBhbiBhcHBy b3ByaWF0ZSBwcml2aWxlZ2UgaW4gYSBzZW5kaW5nIGhvc3QNCiAgIHdpbGwgYmUgZW50aXRs ZWQgdG8gc2V0IGEgbm9uLXplcm8gRmxvdyBMYWJlbC4gIE1lY2hhbmlzbXMgZm9yIHRoaXMN CiAgIGFyZSBvcGVyYXRpbmcgc3lzdGVtIGRlcGVuZGVudC4gIFJlbGF0ZWQgcG9saWN5IGFu ZCBhdXRob3JpemF0aW9uDQogICBtZWNoYW5pc21zIG1heSBhbHNvIGJlIHJlcXVpcmVkOyBm b3IgZXhhbXBsZSwgaW4gYSBtdWx0aS11c2VyIGhvc3QsDQogICBvbmx5IHNvbWUgdXNlcnMg bWF5IGJlIGVudGl0bGVkIHRvIHNldCB0aGUgRmxvdyBMYWJlbC4gIFN1Y2gNCiAgIGF1dGhv cml6YXRpb24gaXNzdWVzIGFyZSBvdXRzaWRlIHRoZSBzY29wZSBvZiB0aGlzIHNwZWNpZmlj YXRpb24uDQoNClFVRVNUSU9OOiBTaG91bGQgdGhpcyBiZSByZW1vdmVkIGFzIHNwZWN1bGF0 aXZlIGFuZCBvdXQgb2Ygc2NvcGUgaW4gYSANCnByb3RvY29sIHNwZWM/DQoNClBST1BPU0VE IFJFU09MVVRJT046IERyb3AgaXQuDQoNCi0tLS0tLS0tLS0tLS0tDQpJU1NVRSA5LiBUaGUg Y2hhbmdlcyB0byBzZWN0aW9uIDIgaW5jbHVkZSB0aGlzIHBhcmFncmFwaC4gUGxlYXNlIHJl YWQgYWxsDQpvZiBpdCwgc2luY2UgdGhlIGZpcnN0IHNlbnRlbmNlIG91dCBvZiBjb250ZXh0 IGNhdXNlcyBjb25mdXNpb246DQoNCiAgIDIuICBUbyBlbmFibGUgc3RhdGVsZXNzIGxvYWQg ZGlzdHJpYnV0aW9uIGF0IGFueSBwb2ludCBpbiB0aGUNCiAgICAgICBJbnRlcm5ldCwgYSBu ZXR3b3JrIGRvbWFpbiBNVVNUIE5PVCBmb3J3YXJkIHBhY2tldHMgb3V0c2lkZSB0aGUNCiAg ICAgICBkb21haW4gd2hvc2UgZmxvdyBsYWJlbCB2YWx1ZXMgYXJlIG90aGVyIHRoYW4gemVy byBvciBwc2V1ZG8tDQogICAgICAgcmFuZG9tLiAgTmVpdGhlciBkb21haW4gYm9yZGVyIGVn cmVzcyByb3V0ZXJzIG5vciBpbnRlcm1lZGlhdGUNCiAgICAgICByb3V0ZXJzL2RldmljZXMg KHVzaW5nIGEgZmxvdy1sYWJlbCwgZm9yIGV4YW1wbGUsIGFzIGEgcGFydCBvZiBhbg0KICAg ICAgIGlucHV0LWtleSBmb3IgYSBsb2FkLWRpc3RyaWJ1dGlvbiBoYXNoKSBjYW4gZGV0ZXJt aW5lIGJ5DQogICAgICAgaW5zcGVjdGlvbiB0aGF0IGEgdmFsdWUgaXMgbm90IHBzZXVkby1y YW5kb20uICBUaGVyZWZvcmUsIGlmDQogICAgICAgbm9kZXMgd2l0aGluIGEgZG9tYWluIGln bm9yZSB0aGUgYWJvdmUgcmVjb21tZW5kYXRpb25zIHRvIHNldA0KICAgICAgIHplcm8gb3Ig cHNldWRvLXJhbmRvbSBmbG93IGxhYmVsIHZhbHVlcywgYW5kIHN1Y2ggcGFja2V0cyBhcmUN CiAgICAgICBmb3J3YXJkZWQgb3V0c2lkZSB0aGUgZG9tYWluLCB0aGlzIHdvdWxkIGxpa2Vs eSByZXN1bHQgaW4NCiAgICAgICB1bmRlc2lyYWJsZSBvcGVyYXRpb25hbCBpbXBsaWNhdGlv bnMgKGUuZy4sIGNvbmdlc3Rpb24sDQogICAgICAgcmVvcmRlcmluZykgZm9yIG5vdCBvbmx5 IHRoZSBpbmFwcHJvcHJpYXRlbHkgZmxvdy1sYWJlbGxlZA0KICAgICAgIHBhY2tldHMsIGJ1 dCBhbHNvIHdlbGwtYmVoYXZlZCBmbG93LWxhYmVsbGVkIHBhY2tldHMsIGR1cmluZw0KICAg ICAgIGZvcndhcmRpbmcgYXQgdmFyaW91cyBpbnRlcm1lZGlhdGUgZGV2aWNlcy4gIFRodXMs IGEgZG9tYWluIG11c3QNCiAgICAgICBwcm90ZWN0IGl0cyBwZWVycyBieSBuZXZlciBleHBv cnRpbmcgaW5hcHByb3ByaWF0ZWx5IGxhYmVsbGVkDQogICAgICAgcGFja2V0cy4gIFRoaXMg ZG9jdW1lbnQgZG9lcyBub3Qgc3BlY2lmeSB0aGUgbWV0aG9kIGZvciBlbmZvcmNpbmcNCiAg ICAgICB0aGlzIHJ1bGUuICBUaGUgc3VnZ2VzdGVkIHdheSB0byBlbmZvcmNlIGl0IGlzIHRo YXQgbm9kZXMgd2l0aGluDQogICAgICAgYSBkb21haW4gTVVTVCBOT1Qgc2V0IHRoZSBmbG93 IGxhYmVsIHRvIGEgbm9uLXplcm8gYW5kIG5vbi0NCiAgICAgICBwc2V1ZG8tcmFuZG9tIG51 bWJlciBpZiB0aGUgcGFja2V0IHdpbGwgbGVhdmUgdGhlIGRvbWFpbi4gIElmDQogICAgICAg dGhpcyBpcyBub3Qga25vd24gdG8gYmUgdGhlIGNhc2UsIHRoZSBib3JkZXIgcm91dGVyIHdp bGwgbmVlZCB0bw0KICAgICAgIGNoYW5nZSBvdXRnb2luZyBmbG93IGxhYmVscy4NCg0KV2Un dmUgZGViYXRlZCBhbmQgdHVuZWQgdGhpcyBvdmVyIHNldmVyYWwgdmVyc2lvbnMgb2YgdGhl IHByZWRlY2Vzc29yDQpkcmFmdC4gQnV0IHRoZXJlIGFyZSBzdGlsbCBvYmplY3Rpb25zLCBz dWNoIGFzOg0KIC0gTVVTVCBpcyB0b28gc3Ryb25nLCBpZiB0aGUgZG93bnN0cmVhbSBvcGVy YXRvciBkb2Vzbid0IGNhcmUgYWJvdXQNCiAgIHRoZSBmbG93IGxhYmVsOw0KIC0gV2UgZG9u J3QgZnVsbHkgc3BlY2lmeSB3aGF0IHRoZSBib3JkZXIgcm91dGVycyBtdXN0IGRvOw0KIC0g V2Ugc2hvdWxkIG1vcmUgZnVsbHkgc3BlY2lmeSB3aGF0IHRoYXQgaG9zdHMgbXVzdCBkby4N ClRoZSBhcmd1bWVudCBmb3IgTVVTVCBpcyB0aGF0IHdlIHNob3Vkbid0IGFsbG93IGFuIG9w ZXJhdG9yDQp0byBzZW5kIHBhY2tldHMgaW50byB0aGUgb3BlbiBJbnRlcm5ldCB3aXRoIGJh ZGx5IGZvcm1lZCBmbG93IGxhYmVscy4NCkZyb20gdGhlIEludGVybmV0J3Mgdmlld3BvaW50 LCB3ZSBkb24ndCBjYXJlIHdoZXRoZXIgdGhlIGJvcmRlciByb3V0ZXINCmRpc2NhcmRzIHBh Y2tldHMsIGNsZWFycyB0aGUgbGFiZWwgdG8gemVybywgb3IgY2xhc3NpZmllcyBwYWNrZXRz IGFuZA0Kc2V0cyBhIG5ldyBwc2V1ZG8tcmFuZG9tIGxhYmVsLiBBbmQgaWYgYSBob3N0IGRv ZXNuJ3QgZG8gd2hhdCBpcyBhbHJlYWR5DQpyZWNvbW1lbmRlZCwgd2UgZG9uJ3QgY2FyZSB3 aGF0IGl0IGRvZXM7IHRoZSBib3JkZXIgcm91dGVyIGhhcyB0bw0KaGlkZSBpdC4NCg0KUVVF U1RJT046IFNob3VsZCB3ZSwgYW5kIGNhbiB3ZSwgZnVydGhlciBpbXByb3ZlIHRoaXMgdGV4 dD8NCg0KQ09NTUVOVDogVGhlcmUgaGF2ZSBiZWVuIHZhcmlvdXMgY29udHJhZGljdG9yeSBv cGluaW9ucy4gVGhlIG1vc3QgdGVsbGluZyBwb2ludA0Kd2FzIHRoYXQgZXZlbiBpZiBhIG5l dHdvcmsgc3Bld3Mgbm9uLWNvbmZvcm1pbmcgcGFja2V0cywgdGhlIG9ubHkgcmVhbCBpbXBh Y3QgaXMNCnRvIGRlcHJpdmUgdGhhdCBuZXR3b3JrJ3MgdHJhZmZpYyBvZiB0aGUgZnVsbCBi ZW5lZml0IG9mIGxvYWQgYmFsYW5jaW5nLg0KU28gbWF5YmUgd2UgYXJlIHdvcnJ5aW5nIHRv byBtdWNoLCBlc3BlY2lhbGx5IGFib3V0IHN0cmljdCBwc2V1ZG8tcmFuZG9tbmVzcy4gDQpB bm90aGVyIHBvaW50IGlzIHRoYXQgdGhlIHRleHQgd2FzIGludGVuZGVkIHRvIGFwcGx5IHRv IG9yaWdpbiBkb21haW5zLCBub3QgdHJhbnNpdA0KZG9tYWlucywgYW5kIHRoYXQgd2Fzbid0 IGNsZWFyLiBBbHNvIG5vdGUgdGhhdCB0aGUgbmV3IE1VU1QgYWRkZWQgZHVlIHRvIElzc3Vl IDENCmRvZXMgc2ltcGxpZnkgdGhpcyBwb2ludDsgaXQgaXMgaW4gZmFjdCBhIHN1ZmZpY2ll bnQgY29uZGl0aW9uDQpzbyB3ZSBkb24ndCBuZWVkIG5vcm1hdGl2ZSBrZXl3b3JkcyBoZXJl Lg0KDQpQUk9QT1NFRCBSRVNPTFVUSU9OOiBZZXQgYW5vdGhlciByZXdyaXRlICgqICogbWFy a3MgY2hhbmdlZCB0ZXh0KToNCg0KICAgMi4gIFRvIGVuYWJsZSBzdGF0ZWxlc3MgbG9hZCBk aXN0cmlidXRpb24gYXQgYW55IHBvaW50IGluIHRoZQ0KICAgICAgIEludGVybmV0LCBhIG5l dHdvcmsgZG9tYWluICpzaG91bGQgbmV2ZXIgZXhwb3J0IHBhY2tldHMgb3JpZ2luYXRpbmcg d2l0aGluIHRoZSBkb21haW4qDQogICAgICAgd2hvc2UgZmxvdyBsYWJlbCB2YWx1ZXMgYXJl IG90aGVyIHRoYW4gemVybyBvciAqdW5pZm9ybWx5IGRpc3RyaWJ1dGVkLioNCiAgICAgICAq SG93ZXZlciwqIG5laXRoZXIgZG9tYWluIGJvcmRlciBlZ3Jlc3Mgcm91dGVycyBub3IgaW50 ZXJtZWRpYXRlDQogICAgICAgcm91dGVycy9kZXZpY2VzICh1c2luZyBhIGZsb3ctbGFiZWws IGZvciBleGFtcGxlLCBhcyBhIHBhcnQgb2YgYW4NCiAgICAgICBpbnB1dC1rZXkgZm9yIGEg bG9hZC1kaXN0cmlidXRpb24gaGFzaCkgY2FuIGRldGVybWluZSBieQ0KICAgICAgIGluc3Bl Y3Rpb24gdGhhdCBhIHZhbHVlIGlzIG5vdCAqcGFydCBvZiBhIHVuaWZvcm0gZGlzdHJpYnV0 aW9uKi4gIFRoZXJlZm9yZSwgaWYNCiAgICAgICBub2RlcyB3aXRoaW4gYSBkb21haW4gaWdu b3JlIHRoZSBhYm92ZSByZWNvbW1lbmRhdGlvbnMgdG8gc2V0DQogICAgICAgemVybyBvciBw c2V1ZG8tcmFuZG9tIGZsb3cgbGFiZWwgdmFsdWVzLCBhbmQgc3VjaCBwYWNrZXRzIGFyZQ0K ICAgICAgIGZvcndhcmRlZCBvdXRzaWRlIHRoZSBkb21haW4sIHRoaXMgKm1pZ2h0KiByZXN1 bHQgaW4NCiAgICAgICB1bmRlc2lyYWJsZSBvcGVyYXRpb25hbCBpbXBsaWNhdGlvbnMgKGUu Zy4sIGNvbmdlc3Rpb24sDQogICAgICAgcmVvcmRlcmluZykgZm9yIG5vdCBvbmx5IHRoZSBp bmFwcHJvcHJpYXRlbHkgZmxvdy1sYWJlbGxlZA0KICAgICAgIHBhY2tldHMsIGJ1dCBhbHNv IHdlbGwtYmVoYXZlZCBmbG93LWxhYmVsbGVkIHBhY2tldHMsIGR1cmluZw0KICAgICAgIGZv cndhcmRpbmcgYXQgdmFyaW91cyBpbnRlcm1lZGlhdGUgZGV2aWNlcy4gIFRodXMsIGEgZG9t YWluIG11c3QNCiAgICAgICBwcm90ZWN0IGl0cyBwZWVycyBieSBuZXZlciBleHBvcnRpbmcg aW5hcHByb3ByaWF0ZWx5IGxhYmVsbGVkDQogICAgICAgcGFja2V0cyAqb3JpZ2luYXRpbmcg d2l0aGluIHRoZSBkb21haW4qLiAgKlRoaXMgaXMgd2h5IG5vZGVzIHVzaW5nDQogICAgICAg YSBzdGF0ZWZ1bCBzY2hlbWUgbXVzdCBub3Qgc2V0IHRoZSBmbG93IGxhYmVsIHRvIGEgbm9u LXplcm8gYW5kDQogICAgICAgbm9uLXVuaWZvcm1seSBkaXN0cmlidXRlZCB2YWx1ZSogaWYg dGhlIHBhY2tldCB3aWxsIGxlYXZlIHRoZWlyIGRvbWFpbi4NCiAgICAgICAqSWYgaXQgaXMg a25vd24gdG8gYSBib3JkZXIgcm91dGVyIHRoYXQgZmxvdyBsYWJlbHMgb3JpZ2luYXRlZCB3 aXRoaW4gdGhlDQogICAgICAgZG9tYWluIGFyZSBub3QgdW5pZm9ybWx5IGRpc3RyaWJ1dGVk LCBpdCB3aWxsIG5lZWQgdG8NCiAgICAgICBzZXQgb3V0Z29pbmcgZmxvdyBsYWJlbHMgaW4g dGhlIHNhbWUgbWFubmVyIGFzIGRlc2NyaWJlZA0KICAgICAgIGZvciBmb3J3YXJkaW5nIG5v ZGVzIGluIFNlY3Rpb24gMy4qDQoNCg0KLS0tLS0tLS0tLS0tLS0NCklTU1VFIDEwLiBTZWN0 aW9uIDIgYWxzbyBzYXlzOg0KDQogICBGb3J3YXJkaW5nIG5vZGVzIHN1Y2ggYXMgcm91dGVy cyBhbmQgbG9hZCBiYWxhbmNlcnMgTVVTVCBOT1QgZGVwZW5kDQogICBvbmx5IG9uIEZsb3cg TGFiZWwgdmFsdWVzIGJlaW5nIHJhbmRvbWx5IGRpc3RyaWJ1dGVkLiAgSW4gYW55IHVzYWdl DQogICBzdWNoIGFzIGEgaGFzaCBrZXkgZm9yIGxvYWQgYmFsYW5jaW5nLCB0aGUgRmxvdyBM YWJlbCBiaXRzIE1VU1QgYmUNCiAgIGNvbWJpbmVkIHdpdGggYml0cyBmcm9tIG90aGVyIHNv dXJjZXMgd2l0aGluIHRoZSBwYWNrZXQsIHNvIGFzIHRvDQogICBwcm9kdWNlIGEgc3VpdGFi bGUgZGlzdHJpYnV0aW9uIG9mIGhhc2ggdmFsdWVzLg0KDQpXaHkgaXMgaXQgcmVzdHJpY3Rl ZCB0byAid2l0aGluIHRoZSBwYWNrZXQiPyBDb3VsZG4ndCB0aGUgbG9hZCBiYWxhbmNlcg0K dXNlIHNvbWV0aGluZyBlbHNlIHRvbywgZXNwZWNpYWxseSBmb3IgYSBzdGF0ZWZ1bCBtZWNo YW5pc20/DQoNClFVRVNUSU9OOiBTaG91bGQgIndpdGhpbiB0aGUgcGFja2V0IiBiZSBkZWxl dGVkPw0KDQpQUk9QT1NFRCBSRVNPTFVUSU9OOiBBcyBKYXJubyBzYWlkLCB0aGUgc3RhdGVt ZW50IGlzIG5vdCBleGNsdXNpdmUuIFdlIGNhbiBjbGFyaWZ5IHRoaXMNCmJ5IHdyaXRpbmc6 DQoNCiAgIC4uLnRoZSBGbG93IExhYmVsIGJpdHMgTVVTVCBiZQ0KICAgY29tYmluZWQgYXQg bGVhc3Qgd2l0aCBiaXRzIGZyb20gb3RoZXIgc291cmNlcyB3aXRoaW4gdGhlIHBhY2tldCwg Li4uDQoNCg0KLS0tLS0tLS0tLS0tLS0NCklTU1VFIDExLiBJbiBzZWN0aW9uIDM6DQoNCiAg IEEgbm9kZSB0aGF0IGZvcndhcmRzIGEgZmxvdyB3aG9zZSBmbG93IGxhYmVsIHZhbHVlIGlu IGFycml2aW5nDQogICBwYWNrZXRzIGlzIHplcm8gTUFZIHNldCB0aGUgZmxvdyBsYWJlbCB2 YWx1ZS4gIEluIHRoYXQgY2FzZSwgaXQgaXMNCiAgIFJFQ09NTUVOREVEIHRoYXQgdGhlIGZv cndhcmRpbmcgbm9kZSBzZXRzIHRoZSBmbG93IGxhYmVsIGZpZWxkIGZvciBhDQogICBmbG93 IHRvIGEgcHNldWRvLXJhbmRvbSB2YWx1ZS4NCg0KUVVFU1RJT046IFNob3VsZCB3ZSBzdWdn ZXN0IGhvdyB0aGUgZm9yd2FyZGluZyBub2RlIGlkZW50aWZpZXMgcGFja2V0cyBiZWxvbmdp bmcNCnRvIHRoZSBzYW1lIGZsb3c/IChkcmFmdC1pZXRmLTZtYW4tZmxvdy1lY21wIHRhbGtz IGFib3V0IHRoaXMuKQ0KDQpQUk9QT1NFRCBSRVNPTFVUSU9OOiBNYWtlIGl0IGNsZWFyIHRo YXQgdGhpcyB3aWxsIG5vcm1hbGx5IGJlIGRvbmUgcGVyIDUtdHVwbGUuDQpBY3R1YWxseSB3 ZSBzaG91bGQgYWxzbyBtYWtlIHRoYXQgY2xlYXIgYXMgdGhlIG5vcm1hbCBjYXNlIGZvciBs YWJlbGluZyBieSBzb3VyY2Ugbm9kZXMgdG9vLg0KDQotLQ0KDQoNCg0KDQoNCg0K --------------020109030406030608080006-- From yhb810501@gmail.com Sat Feb 26 06:07:43 2011 Return-Path: X-Original-To: ipv6@core3.amsl.com Delivered-To: ipv6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2831D3A6929 for ; Sat, 26 Feb 2011 06:07:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.238 X-Spam-Level: X-Spam-Status: No, score=-3.238 tagged_above=-999 required=5 tests=[AWL=0.360, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fKZRRGN4zuwh for ; Sat, 26 Feb 2011 06:07:42 -0800 (PST) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id 4F02C3A67CC for ; Sat, 26 Feb 2011 06:07:42 -0800 (PST) Received: by iwl42 with SMTP id 42so2092964iwl.31 for ; Sat, 26 Feb 2011 06:08:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:from:to:subject:date:mime-version :content-type:x-priority:x-msmail-priority:importance:x-mailer :x-mimeole; bh=MMejUprIVyfhiSVdUciDKg0fYEntl3HOvAarZaRXUfI=; b=Okz9ze4xUxEYDy2mVrQs1wlBP2xFas1jdeIpsKIQ2qkshGQhxIabRyehr0WxC3sHQq cRLIzNKoZ4GLhL8cptSogfvTdSF39FMTwAq2rKA70Zzkx9dbrCNetEkJfsAg3uF8pNQn qbf+6UGXurF2W3SanE/HmpCfWGnDCylcHoDpU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:from:to:subject:date:mime-version:content-type :x-priority:x-msmail-priority:importance:x-mailer:x-mimeole; b=ehI6vWAD2guh+/qw4lxOX30PlTky8FH90/Hv8cFps2POcvg+vKinUURYUF6Hn/tkNw LMcHzDYto3lOAkdPs4wixbA9G7aU3xoicWDVBKCkz/96n793E60q/YCmuFYx+nsrNSwD 6GThfdJNXr+uQJCRANG4rHwo1AGCAacrywbns= Received: by 10.42.221.200 with SMTP id id8mr2247818icb.409.1298729317264; Sat, 26 Feb 2011 06:08:37 -0800 (PST) Received: from yhbPC ([220.200.0.167]) by mx.google.com with ESMTPS id u9sm2031540ibe.2.2011.02.26.06.08.34 (version=SSLv3 cipher=OTHER); Sat, 26 Feb 2011 06:08:36 -0800 (PST) Message-ID: <951CF8F9720E42B79C9450176EE59AD3@yhbPC> From: "Yu Hua bing" To: Subject: Re:draft-yhb-6man-ra-privacy-flag-00 Date: Sat, 26 Feb 2011 22:08:19 +0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0055_01CBD601.AD1EF670" X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 14.0.8089.726 X-MimeOLE: Produced By Microsoft MimeOLE V14.0.8089.726 X-BeenThere: ipv6@ietf.org 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: , X-List-Received-Date: Sat, 26 Feb 2011 14:07:43 -0000 ÕâÊÇÒ»·â MIME ¸ñʽµÄ¶à·½Óʼþ¡£ ------=_NextPart_000_0055_01CBD601.AD1EF670 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: quoted-printable > That said, I also think a huge flaw in the draft is that existing = hosts > interpret the currently unused and reserved bit in the reverse sense, > i.e. that privacy addresses are allowed when the value is zero. I think that the bit should be named the DisablePrivacy flag.There are = two cases: (1)If the host supports this flag and the gateway doesn't support, the = DisablePrivacy flag is always zero for the host,=20 and the host can generate the privacy addresses. (2)If the host doesn't support this flag and the gateway supports, the = host SHOULD ignore this flag. ------=_NextPart_000_0055_01CBD601.AD1EF670 Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable
> That said, I also think a huge flaw in = the draft is=20 that existing hosts
> interpret the currently unused and reserved = bit in=20 the reverse sense,
> i.e. that privacy addresses are allowed when = the=20 value is zero.

I think that the bit should be named the = DisablePrivacy flag.There are two cases:
 
(1)If the host supports this flag and the = gateway=20 doesn't support, the DisablePrivacy flag is always zero for the host,=20
and the host can generate the privacy=20 addresses.
(2)If the host doesn't support this flag and = the gateway=20 supports, the host SHOULD ignore this flag.
 

------=_NextPart_000_0055_01CBD601.AD1EF670-- From yhb810501@gmail.com Sat Feb 26 23:35:12 2011 Return-Path: X-Original-To: ipv6@core3.amsl.com Delivered-To: ipv6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 443D83A6918 for ; Sat, 26 Feb 2011 23:35:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.533 X-Spam-Level: X-Spam-Status: No, score=-2.533 tagged_above=-999 required=5 tests=[AWL=-0.435, BAYES_00=-2.599, J_CHICKENPOX_33=0.6, J_CHICKENPOX_74=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 11OeYHhIyelZ for ; Sat, 26 Feb 2011 23:35:11 -0800 (PST) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id 35EE73A691D for ; Sat, 26 Feb 2011 23:35:11 -0800 (PST) Received: by iwl42 with SMTP id 42so2514494iwl.31 for ; Sat, 26 Feb 2011 23:36:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:from:to:cc:references:in-reply-to :subject:date:mime-version:content-type:content-transfer-encoding :x-priority:x-msmail-priority:importance:x-mailer:x-mimeole; bh=OU1xVGjBXq9FrxP12lA1fls2G9po2GvWTIMCVMoSPXw=; b=WKc6QM9XCZzYjxQCEwVr8VuBGhFhxSArXc2Z8+fNzyohRBS+8XV/0OJahOcirSZ+YB Dg4+0vLV1eLoGoplSqNhWv2IyI3M0yJZaVZG5fivaWHQGcUy+pEcC0IfN1WcVTN/KvWp bXGt68eB7pfjXjx1MzAGw7qDMonrX2luLGHm8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:from:to:cc:references:in-reply-to:subject:date :mime-version:content-type:content-transfer-encoding:x-priority :x-msmail-priority:importance:x-mailer:x-mimeole; b=szQ8lawc9WPBifMWYE0YCHTyew73Bza0uK2KLMgLKJK3/y4yt5ssZ7Y/QEub0Vzinj cdA6XSsaT5G2+CxifwufGTcjgsVDLUwBBqoNGJ3n8/X2FcpQQubJr9ZQKY8blSU1EiNc c7jffMWyCAEMZ8QH8qG+qrNIzeSR1Gf2GEFfg= Received: by 10.231.10.200 with SMTP id q8mr4341207ibq.122.1298792167907; Sat, 26 Feb 2011 23:36:07 -0800 (PST) Received: from yhbPC ([220.200.0.167]) by mx.google.com with ESMTPS id z4sm2986662ibg.7.2011.02.26.23.36.04 (version=SSLv3 cipher=OTHER); Sat, 26 Feb 2011 23:36:07 -0800 (PST) Message-ID: From: "Yu Hua bing" To: =?iso-8859-15?Q?R=E9mi_Denis-Courmont?= , References: <201102241944.45964.remi@remlab.net> In-Reply-To: <201102241944.45964.remi@remlab.net> Subject: Re: draft-yhb-6man-nd-improvement-00 Date: Sun, 27 Feb 2011 15:35:58 +0800 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-15"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 14.0.8089.726 X-MimeOLE: Produced By Microsoft MimeOLE V14.0.8089.726 Cc: ? ?? X-BeenThere: ipv6@ietf.org 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: , X-List-Received-Date: Sun, 27 Feb 2011 07:35:12 -0000 > It is far too easy for a node of the subnet to hijack an address by > spoofing > the deleted flag... Suppose host c sends a neighbor advertisement with flag D set to cheat all other nodes that IPv6 address A assigned to host A is deleted,when host B receives the neighbor advertisement,do as follows: (1)If the target address is a unicast address in duplicate state on the receiving interface, host B SHOULD set the state of the unicast address to tentative and perform DAD.DAD will fail. (2)If the source address is not the unspecified address, the neighbor cache will be searched for the target's entry. If appropriate neighbor cache entry has been located, because the neighbor is unreachable, host B SHOULD delete the neighbor cache immediately.Host B can re-learn the MAC address of host A via neighbor discovery protocol when it needs to communicate with host A. > Besides, nodes often learn that they're going off-link too late to send > the > deletion notice anyway. In some cases, for example, unplugging the network cables, nodes can't send the deletion notice.But in other cases, it is helpful.