From brian.e.carpenter@gmail.com Sat Jan 1 20:11: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 D7C473A697D for ; Sat, 1 Jan 2011 20:10:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.407 X-Spam-Level: X-Spam-Status: No, score=-103.407 tagged_above=-999 required=5 tests=[AWL=0.192, 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 yQHT26Wo73ly for ; Sat, 1 Jan 2011 20:10:56 -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 ED0993A6981 for ; Sat, 1 Jan 2011 20:10:54 -0800 (PST) Received: by gyd12 with SMTP id 12so5528312gyd.31 for ; Sat, 01 Jan 2011 20:13:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :organization:user-agent:mime-version:to:cc:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=XLOySxDNMuZcCfcvPO+lotbijlzlnsgtwfy9PxIdepM=; b=N6E2WqxKTnD32oahq/XsWY9PBIV++daB+OUvqxy+ZrqYJ1NrRLTJdGzsg8ykxBkpdq 13TPoJeiUzmUAL/zWhWPPLt00/QLUs37LOxrEyv58d+Q5lEQn7BgAGkP1DkNAGjFIC8i VNTkLMDN/hxTl4pc9BFgp2bF7hjL6tQl9TUZo= 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=H81Rw3C95glSG46Ju26Nys+RmVK3q4BOFTo4KcAPgY6OR+lbqik7Z/T6mdMhJknm+s /PszjjeQZeUvK8sf1036xCnFYlZo1iaJdQ3/jCOyEOtsY1yyiI354VyPplweOy6xkMD0 xVbTSFSZAwOalgvwjmherUXZ5L9dFcEk/rQ4g= Received: by 10.236.95.144 with SMTP id p16mr20625390yhf.11.1293941581374; Sat, 01 Jan 2011 20:13:01 -0800 (PST) Received: from [10.1.1.4] ([121.98.190.33]) by mx.google.com with ESMTPS id g58sm5955673yhd.18.2011.01.01.20.12.57 (version=SSLv3 cipher=RC4-MD5); Sat, 01 Jan 2011 20:13:00 -0800 (PST) Message-ID: <4D1FFB3D.2030804@gmail.com> Date: Sun, 02 Jan 2011 17:12:45 +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: 6MAN WG Last Call: References: <7B63F7B6-D788-4A05-9722-C1CAAA42B754@gmail.com> In-Reply-To: <7B63F7B6-D788-4A05-9722-C1CAAA42B754@gmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Brian Haberman , 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: Sun, 02 Jan 2011 04:11:04 -0000 I would be happy to see this published as-is, but I did notice a few points. I think the Introduction needs a general warning something like: This document reflects the state of IPv6 standards at a particular moment. Subsequent standards work and operational experience may require changes to the recommendations in this document. Also in the Introduction: > As it is not always possible for an implementer to know the exact > usage of IPv6 in a node, an overriding requirement for IPv6 nodes is > that they should adhere to Jon Postel's Robustness Principle: > > Be conservative in what you do, be liberal in what you accept from > others [RFC0793]. Note that this is also present in RFC 1958, by which time Jon had reformulated it slightly as: > Be strict when sending and tolerant when receiving. In 4. Sub-IP Layer > In addition to traditional physical link-layers, it is also possible > to tunnel IPv6 over other protocols. Examples include: Should we mention that basic v6/v4 tunnels are specified in [RFC4213]? And the examples > - Teredo: Tunneling IPv6 over UDP through Network Address > Translations (NATs) [RFC4380] > - Transmission of IPv6 over IPv4 Domains without Explicit Tunnels > [RFC2529] may not be so well chosen. Teredo is not loved by operators, and RFC 2529 is essentially unused today. Maybe 6rd (RFC 5969)and hub-and-spoke (RFC 5571) would be better examples. Two topics are not mentioned. 1. The flow label and RFC 3697. I think that is probably wise until we produce 3697bis. 2. DNSSEC. I don't recall whether we discussed that. If we did, I'm sorry to raise it again. However, I suspect we will get pushback in security review if it is not mentioned. Nit: there should be a Replaces: 4294 header. Brian From pekkas@netcore.fi Mon Jan 3 01:49: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 8F6B428C105 for ; Mon, 3 Jan 2011 01:49: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=[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 nA4UY+J5D-IF for ; Mon, 3 Jan 2011 01:49: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 1AEE628C103 for ; Mon, 3 Jan 2011 01:49:33 -0800 (PST) Received: from netcore.fi (localhost [127.0.0.1]) by netcore.fi (8.13.8/8.13.8) with ESMTP id p039pckd023835 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 3 Jan 2011 11:51:38 +0200 Received: from localhost (pekkas@localhost) by netcore.fi (8.13.8/8.13.8/Submit) with ESMTP id p039pcue023831 for ; Mon, 3 Jan 2011 11:51:38 +0200 Date: Mon, 3 Jan 2011 11:51:38 +0200 (EET) From: Pekka Savola To: ipv6@ietf.org Subject: addrsel: privacy addresses within/out of a site Message-ID: 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 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, 03 Jan 2011 09:49:35 -0000 Hi, Operational input: when discussing the use of RFC4941 (privacy) addresses with our LAN/workstation admins, it seemed as if there would be great benefit from being able to specify an RFC3484 rule which would in essence say: "do not use privacy addresses when communicating inside the site [a set of designated destination prefixes], use it by default otherwise" I don't think this is possible today because rfc3484 policy table only allows matching by prefixes, not by address type. Has this come up in discussions / has anyone else thought about this? Btw: in draft-ietf-6man-rfc3484-revise-01, "fec::/16" should be "fec0::/10". fec:: would mean 0fec:: and the prefix length is also wrong. -- 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 ipng@69706e6720323030352d30312d31340a.nosense.org Mon Jan 3 02:08: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 94B4628C10E for ; Mon, 3 Jan 2011 02:08:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.515 X-Spam-Level: X-Spam-Status: No, score=-1.515 tagged_above=-999 required=5 tests=[AWL=0.380, 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 vmbJoAuvvOWU for ; Mon, 3 Jan 2011 02:08:27 -0800 (PST) Received: from smtp4.adam.net.au (smtp4.adam.net.au [202.136.110.247]) by core3.amsl.com (Postfix) with ESMTP id BCAC028C0FE for ; Mon, 3 Jan 2011 02:08:27 -0800 (PST) Received: from 182-239-157-145.ip.adam.com.au ([182.239.157.145] helo=opy.nosense.org) by smtp4.adam.net.au with esmtp (Exim 4.63) (envelope-from ) id 1PZhN2-0005Hp-Ny; Mon, 03 Jan 2011 20:40:32 +1030 Received: from opy.nosense.org (localhost.localdomain [IPv6:::1]) by opy.nosense.org (Postfix) with ESMTP id 0AED83B335; Mon, 3 Jan 2011 20:40:32 +1030 (CST) Date: Mon, 3 Jan 2011 20:40:31 +1030 From: Mark Smith To: Pekka Savola Subject: Re: addrsel: privacy addresses within/out of a site Message-ID: <20110103204031.0c3589b7@opy.nosense.org> In-Reply-To: References: 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: 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, 03 Jan 2011 10:08:28 -0000 Hi Pekka, On Mon, 3 Jan 2011 11:51:38 +0200 (EET) Pekka Savola wrote: > Hi, > > Operational input: when discussing the use of RFC4941 (privacy) addresses with > our LAN/workstation admins, it seemed as if there would be great benefit from > being able to specify an RFC3484 rule which would in essence say: > > "do not use privacy addresses when communicating inside the site [a set of > designated destination prefixes], use it by default otherwise" > I'd be curious what the benefits are. The only reason I could think of as to why to do this is to be able to associate internal application access logs with internal hosts. At face value that sounds useful, however if you really care about auditing application access and use, it isn't the hosts you need to worry about, but the people behind them - and they can usually easily change hosts. So I think those applications should be using proper AAA to identify the user, rather than using IPv6 host identifiers as very poor substitutes for user identities. > I don't think this is possible today because rfc3484 policy table only allows > matching by prefixes, not by address type. > > Has this come up in discussions / has anyone else thought about this? > Regards, Mark. From pekkas@netcore.fi Mon Jan 3 02:19: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 0697B28C118 for ; Mon, 3 Jan 2011 02:19:57 -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, J_CHICKENPOX_55=0.6, 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 9IbRleUtN+P5 for ; Mon, 3 Jan 2011 02:19:56 -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 DB1EC28C10C for ; Mon, 3 Jan 2011 02:19:55 -0800 (PST) Received: from netcore.fi (localhost [127.0.0.1]) by netcore.fi (8.13.8/8.13.8) with ESMTP id p03ALhhc024722 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 3 Jan 2011 12:21:43 +0200 Received: from localhost (pekkas@localhost) by netcore.fi (8.13.8/8.13.8/Submit) with ESMTP id p03ALfcn024719; Mon, 3 Jan 2011 12:21:42 +0200 Date: Mon, 3 Jan 2011 12:21:41 +0200 (EET) From: Pekka Savola To: Mark Smith Subject: Re: addrsel: privacy addresses within/out of a site In-Reply-To: <20110103204031.0c3589b7@opy.nosense.org> Message-ID: References: <20110103204031.0c3589b7@opy.nosense.org> 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: 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, 03 Jan 2011 10:19:57 -0000 On Mon, 3 Jan 2011, Mark Smith wrote: >> "do not use privacy addresses when communicating inside the site [a set of >> designated destination prefixes], use it by default otherwise" >> > > I'd be curious what the benefits are. > > The only reason I could think of as to why to do this is to be able to > associate internal application access logs with internal hosts. At face > value that sounds useful, however if you really care about auditing > application access and use, it isn't the hosts you need to worry about, > but the people behind them - and they can usually easily change hosts. > So I think those applications should be using proper AAA to identify the > user, rather than using IPv6 host identifiers as very poor substitutes > for user identities. One use case is administrators running ssh, vnc or some such remote management to the client OS. The conclusion from looking at various similar cases was that systems need to have a well-known (non-privacy) IP where they can be reached and run TCP services at, or the privacy IP needs to be stored in DNS (not much point in that..). Also, many site-internal access control mechanisms (for example, hosts.allow for ssh, some others for e.g. web browsing) use host-specific IPs in addition to other checks. In some cases these could be substituted with stronger upper-layer identities e.g with certificates. On the other hand, user identification due to static EU64 is a little bit of concern e.g. with web surfing, but this also applies to other applications so the issue does not go away with application-specific tuning. -- 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 suresh.krishnan@ericsson.com Mon Jan 3 05:21: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 A7C0428C102 for ; Mon, 3 Jan 2011 05:21:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.572 X-Spam-Level: X-Spam-Status: No, score=-102.572 tagged_above=-999 required=5 tests=[AWL=0.027, 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 bbbn8FCl9q9l for ; Mon, 3 Jan 2011 05:21:25 -0800 (PST) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.8]) by core3.amsl.com (Postfix) with ESMTP id 274FC3A695E for ; Mon, 3 Jan 2011 05:21:24 -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 p03Dx4xl023393 for ; Mon, 3 Jan 2011 07:59:05 -0600 Received: from [142.133.10.113] (147.117.20.213) by eusaamw0711.eamcs.ericsson.se (147.117.20.179) with Microsoft SMTP Server id 8.2.234.1; Mon, 3 Jan 2011 08:23:25 -0500 Message-ID: <4D21CD00.1030906@ericsson.com> Date: Mon, 3 Jan 2011 08:20:00 -0500 From: Suresh Krishnan User-Agent: Thunderbird 2.0.0.24 (X11/20101027) MIME-Version: 1.0 To: IETF IPv6 Mailing List Subject: Need your input on draft-ietf-6man-exthdr 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, 03 Jan 2011 13:21:26 -0000 Hi Folks, As some recent mails indicated there does not seem to be consensus on some parts of this draft. I would like to see what the wg feels (now) before proceeding any further with this draft. The draft contains three independent components a) Specifying a uniform format for all future IPv6 extension headers to make them easier to parse/process. b) Requesting a single IP protocol number codepoint for all future extension headers and multiplexing them using a Specific Type field inside the generic header. c) Specifying error-handling and drop behavior for dealing with unknown extension headers. From what I have seen there seems to be no opposition to a) but there is for b) and c). I will try to (loosely) summarize the viewpoints on b) and c) and see if we can agree on what to do about them. b) was added due to wg feedback =============================== Pros: 1) Allows middleboxes to differentiate between unknown extension headers and unknown transport protocols 2) Reduces the strain on the protocol number space Cons: 1) Uses up one protocol number even if no now extension headers are ever defined 2) Any new extension header (including this one) will break existing silicon. c) was added due to the decision reached at the IETF79 wg meeting ================================================================= Pros: 1) Allows flexible handling behavior for dealing with unknown headers Cons: 1) Violates RFC2460 2) Duplicates the functionality provided by Destination options 3) Unnecessary META-question ============= RFC2460 allows the use of both extension headers and options to convey optional information, I would like to add some text into this draft suggesting that destination options are the preferred mechanism of doing so (since they offer better backward compatibility). Something like "RFC2460 allows the use of both extension headers and destination options in order to encode optional destination information in an IPv6 packet. The use of destination options to encode this information, provides more flexible handling characteristics and better backward compatibility than using extension headers. Because of this, implementations SHOULD use destination options as the preferred mechanism for encoding optional destination information, and use a new extension header only if destination options do not satisfy their needs. The request for allocation of a Specific Type value MUST be accompanied by an specific explanation of why destination options could not be used to convey this information." Would this be an acceptable thing to add here? I would appreciate the WG's opinion on these issues/questions before going forward with this draft. Thanks Suresh From brian.e.carpenter@gmail.com Mon Jan 3 11:28: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 0A6453A6B13 for ; Mon, 3 Jan 2011 11:28:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.123 X-Spam-Level: X-Spam-Status: No, score=-103.123 tagged_above=-999 required=5 tests=[AWL=-0.124, BAYES_00=-2.599, J_CHICKENPOX_55=0.6, 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 mvD7QdCMODqq for ; Mon, 3 Jan 2011 11:28: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 DC2283A6B12 for ; Mon, 3 Jan 2011 11:28:38 -0800 (PST) Received: by fxm9 with SMTP id 9so13323408fxm.31 for ; Mon, 03 Jan 2011 11:30:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :organization:user-agent:mime-version:to:cc:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=aCpEh/OCKhMLPS8eX1FV1OS9S93Ow1QbqRkLq5pmDRA=; b=vMj6uGuqYXzJnZA4dDoFsJi7TOYvD/X8d07dlf/k4sr2Vqz9xSk/5dlq1pRl4Didje xZXxmzlXLyW0sqboHeerOGest5jX/WGTonJ5/pTtHePQEgfR2pShj6x9n0h0Uk+9BZfh qKzsQNMpOFdcTIK9Rncrt8iIDxGzVDTUQMDXA= 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=DLPgv3OyX12ID+s5Pn5LDAjhGT0qDm7+Eo1rnBlNEGDL3pWnjRYnTv2I/4n8eiUocT EfWnUJEcAG1UF3iZkpjzruwZdA8YF/B+vbBpCK06414A30rDXkUFdHfVrYaG3ko7rAs3 I+hG3ciwKnnL5T73tjtWGgxlRY1PABR9oid/g= Received: by 10.223.87.14 with SMTP id u14mr5039359fal.116.1294083045369; Mon, 03 Jan 2011 11:30:45 -0800 (PST) Received: from [10.1.1.4] ([121.98.190.33]) by mx.google.com with ESMTPS id 5sm4892063fak.23.2011.01.03.11.30.41 (version=SSLv3 cipher=RC4-MD5); Mon, 03 Jan 2011 11:30:44 -0800 (PST) Message-ID: <4D2223DB.1000708@gmail.com> Date: Tue, 04 Jan 2011 08:30:35 +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: addrsel: privacy addresses within/out of a site References: <20110103204031.0c3589b7@opy.nosense.org> In-Reply-To: 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, 03 Jan 2011 19:28:40 -0000 Pekka, Wouldn't the rule "Use ULA prefix inside the site and PA prefix (with privacy addresses if desired) otherwise" be simpler? And, by default, it would prevent the "inside" address being exported by mistake. Regards Brian On 2011-01-03 23:21, Pekka Savola wrote: > On Mon, 3 Jan 2011, Mark Smith wrote: >>> "do not use privacy addresses when communicating inside the site [a >>> set of >>> designated destination prefixes], use it by default otherwise" >>> >> >> I'd be curious what the benefits are. >> >> The only reason I could think of as to why to do this is to be able to >> associate internal application access logs with internal hosts. At face >> value that sounds useful, however if you really care about auditing >> application access and use, it isn't the hosts you need to worry about, >> but the people behind them - and they can usually easily change hosts. >> So I think those applications should be using proper AAA to identify the >> user, rather than using IPv6 host identifiers as very poor substitutes >> for user identities. > > One use case is administrators running ssh, vnc or some such remote > management to the client OS. The conclusion from looking at various > similar cases was that systems need to have a well-known (non-privacy) > IP where they can be reached and run TCP services at, or the privacy IP > needs to be stored in DNS (not much point in that..). > > Also, many site-internal access control mechanisms (for example, > hosts.allow for ssh, some others for e.g. web browsing) use > host-specific IPs in addition to other checks. In some cases these > could be substituted with stronger upper-layer identities e.g with > certificates. > > On the other hand, user identification due to static EU64 is a little > bit of concern e.g. with web surfing, but this also applies to other > applications so the issue does not go away with application-specific > tuning. > From narten@us.ibm.com Mon Jan 3 12:38: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 DE6A63A6BB4 for ; Mon, 3 Jan 2011 12:38:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.889 X-Spam-Level: X-Spam-Status: No, score=-105.889 tagged_above=-999 required=5 tests=[AWL=0.710, 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 PKpH6PeyQ06x for ; Mon, 3 Jan 2011 12:38:16 -0800 (PST) Received: from e32.co.us.ibm.com (e32.co.us.ibm.com [32.97.110.150]) by core3.amsl.com (Postfix) with ESMTP id C43CA3A6BB0 for ; Mon, 3 Jan 2011 12:38:16 -0800 (PST) Received: from d03relay05.boulder.ibm.com (d03relay05.boulder.ibm.com [9.17.195.107]) by e32.co.us.ibm.com (8.14.4/8.13.1) with ESMTP id p03KURD8031330 for ; Mon, 3 Jan 2011 13:30:27 -0700 Received: from d03av05.boulder.ibm.com (d03av05.boulder.ibm.com [9.17.195.85]) by d03relay05.boulder.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id p03KeHqn081196 for ; Mon, 3 Jan 2011 13:40:17 -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 p03KeHFB025782 for ; Mon, 3 Jan 2011 13:40:17 -0700 Received: from cichlid.raleigh.ibm.com (sig-9-48-32-3.mts.ibm.com [9.48.32.3]) by d03av05.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id p03KeFke025771 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 3 Jan 2011 13:40:16 -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 p03KeE86005244; Mon, 3 Jan 2011 15:40:15 -0500 Message-Id: <201101032040.p03KeE86005244@cichlid.raleigh.ibm.com> To: Suresh Krishnan Subject: Re: I-D Action:draft-ietf-6man-exthdr-01.txt In-reply-to: <4D113364.3050105@ericsson.com> References: <20101217234501.11691.81147.idtracker@localhost> <63416880-97B6-4CE4-864A-1402DA977B5F@tony.li> <4D113364.3050105@ericsson.com> Comments: In-reply-to Suresh Krishnan message dated "Tue, 21 Dec 2010 18:08:20 -0500." Date: Mon, 03 Jan 2011 15:40:14 -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, 03 Jan 2011 20:38:18 -0000 FWIW, I'm sympathetic to Tony's basic sense that it is unclear that we need to do this work/document. I'm still not clear on exactly what *real* problem it solves. Suresh Krishnan writes: > Since RFC2460 came out, four new extension headers have been defined. > 135 - Mobility header > 139 - HIP > 140 - Shim6 > 141 - WESP 2 of the above code points are used by IPv4, so having a generic extension header mechanism for IPv6 would have saved only 2 code points. No need to panic folks... > The idea of burning one protocol number right now was suggested by the > WG in order to limit further exhaustion of the protocol number space. > Would it be more acceptable to you, if we do not ask for an IANA > allocation for a protocol number at this point, and wait till the first > "Specific Type" request comes up? My general sense is that this work is mostly just good common sense advice to someone who has a need to define a new extension type. But until we see such a concrete proposal, I am not convinced (yet) that we should define anything new that suggests people go change implementations or allocate code points. Both are premature. As one concrete example, RFC 5175 defines extensions for adding future RA flags. But, none have been defined yet, so the work really isn't needed yet and implementations certainly don't need to do anything yet. However, that has not stopped NIST and DoD from citing these documents recommendations to implement. Upleveling a bit, and thinking about routing headers and destination options, my general sense is about such options is: 1) Destination options are the preferred route. Any other kind of option will be extremely hard to deploy, has all kinds of barriers, etc. (This proposal will have no impact on future destination options. Right?) 2) The routing header is essentially deprecated, and we probably won't define any more. We've already deprecated RHO. RH1 was never used, is now deprecated, and arguably shouldn't even count as ever having been defined. RH2 is the MIP routing header. RH2 was originally a regular type 0 option, but was changed because of the fear that firewalls would block packets with such options by default, preventing MIPv6 from being deployed. If we had to do it all over again, MIPv6 arguably should have used a destination option, since by definition RH2 is only processed if the two addresses in the routing header are on the same node, which is much more in line with the intention behind destination options. Which leads me to ask, exactly what kinds of future options do we think will take advantage of this new format? Note, my bias on this general topic is based on experience that unless we have something concrete driving this sort of work, we risk getting it wrong. So, I'm still trying to be convinced we need to do this sort of work *now*. If there was an actual proposal for a new option that solved some sort of real problem, things might be different. Thomas From brian.e.carpenter@gmail.com Mon Jan 3 13:23: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 E42123A6C42 for ; Mon, 3 Jan 2011 13:23:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.421 X-Spam-Level: X-Spam-Status: No, score=-103.421 tagged_above=-999 required=5 tests=[AWL=0.178, 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 rp7J2sVPeTyL for ; Mon, 3 Jan 2011 13:23:22 -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 C5C413A6C41 for ; Mon, 3 Jan 2011 13:23:21 -0800 (PST) Received: by eyd10 with SMTP id 10so5878443eyd.31 for ; Mon, 03 Jan 2011 13:25:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :organization:user-agent:mime-version:to:cc:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=tM/VsmoIxMhqwkuqV8juyeoXjxhP9Xw5D9P7kKdysDA=; b=a3TNJv5bcpFtFzH70NnUW+xfz7IlaCKPCxt4MtFIQHbuNb7wZQWxlpyUGpFmZr0wvm 9UaJYnas7Ri1CClypaO/uTVn6pvgwSD8Dez1DUn/39Ij/r5ih9BJzZlX5DDp0rpjAW33 aa/A0SdKFW1r+Kbz6l+0RI08CyawjinttYuTQ= 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=Lf5APlZipVddF/PJE1KDS/gd3MV+vkhNaW9DprzBejoYqLcplf9f4qewPgHQ6KZlGH j3MjLNUCRlfQYbaqw+MGua1CrUcAXCFaKMpz+ryxEMGRTS4uM+P5SgXrvDeVZMwS2/ZE 2TkkqlZqU+///lAyoe3xfsdIQMjStFeLh74lU= Received: by 10.213.26.74 with SMTP id d10mr17360110ebc.61.1294089928306; Mon, 03 Jan 2011 13:25:28 -0800 (PST) Received: from [10.1.1.4] ([121.98.190.33]) by mx.google.com with ESMTPS id x54sm15109515eeh.17.2011.01.03.13.25.24 (version=SSLv3 cipher=RC4-MD5); Mon, 03 Jan 2011 13:25:27 -0800 (PST) Message-ID: <4D223EC0.7020906@gmail.com> Date: Tue, 04 Jan 2011 10:25:20 +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: I-D Action:draft-ietf-6man-exthdr-01.txt References: <20101217234501.11691.81147.idtracker@localhost> <63416880-97B6-4CE4-864A-1402DA977B5F@tony.li> <4D113364.3050105@ericsson.com> <201101032040.p03KeE86005244@cichlid.raleigh.ibm.com> In-Reply-To: <201101032040.p03KeE86005244@cichlid.raleigh.ibm.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "ipv6@ietf.org" , Suresh Krishnan 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, 03 Jan 2011 21:23:23 -0000 > 2) The routing header is essentially deprecated, and we probably won't > define any more. The proposal for RH4, i.e. draft-ietf-6man-rpl-routing-header, is active. However, isn't the real question whether we want to change the implied intention that adding a new extension header should be hard? Section 4 of RFC 2460 makes this intention pretty clear: unknown extension headers should lead to packet discard and ICMP Parameter Problem, so this is intended for consenting adults only. Skipping over unknown extension headers was definitely not intended to work. The basic motivation for the present draft is clear: > However, > some intermediate nodes such as firewalls, may need to look at the > transport layer header fields in order to make a decision to allow or > deny the packet. That is, help middleboxes to violate e2e transparency and, furthermore, allow unknown headers to cross those middleboxes. If I was a paranoid security person, I would definitely not be happy with this. On the contrary - if I saw an unknown IP header in a packet, I would want to discard it. A legacy firewall wouldn't recognize the Next Header value for draft-ietf-6man-exthdr, so would discard the packet. If my firewall had been updated, and saw a draft-ietf-6man-exthdr, header, it would need to look at the embedded "Specific Type" and then decide whether to discard it. Just a bit more deep packet inspection. So the one thing this proposal will *not* do is allow new extension headers to cross the Internet transparently. All it might do is cause the firewalls to dig one layer deeper before discarding the packet. Regards Brian From fernando.gont.netbook.win@gmail.com Mon Jan 3 13:41: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 A38D63A6C7B for ; Mon, 3 Jan 2011 13:41:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.532 X-Spam-Level: X-Spam-Status: No, score=-3.532 tagged_above=-999 required=5 tests=[AWL=0.067, 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 XPmnA9CyA+oD for ; Mon, 3 Jan 2011 13:41:30 -0800 (PST) Received: from mail-yw0-f66.google.com (mail-yw0-f66.google.com [209.85.213.66]) by core3.amsl.com (Postfix) with ESMTP id 74FAA3A6C7A for ; Mon, 3 Jan 2011 13:41:30 -0800 (PST) Received: by ywi6 with SMTP id 6so3287897ywi.1 for ; Mon, 03 Jan 2011 13:43:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received: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=lpU+lhTObosu9CZcVOu/MOY0S9nk3v/f10PG4XUAwyM=; b=WXXIsH+sXkZQFv4a7coLXYjT6HIdt69jCWrMeOdNbYzcLZMYyW+TC0+v+ps2WmuKMR OGSVDvYCXsIs1vd+fH38cZkDjLsKkv6bMVcW/tMQDjfW4ow4QZcE4Co0znTbm+e91VFb i3X1d9/JIemAUh0z3Jrl6gAMRURSiJKhKR7YA= 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=Qv7p9bpL4Ktj6xl2ZzD4h9PNr5bHiwQzcOlXkUfHRuq4MGqgr+YchpoEcpUGN/Traa viWrQzNR9KOc9rto+8QS6mekk7Zl1zKiZPSYXNZwsnfMCj+/SHzFVXREjUXHxSLkmOlJ 2u4pq6kQHmafbzS0ggQgqBKBpw4ijUSz47Zf0= Received: by 10.151.98.18 with SMTP id a18mr18690957ybm.203.1294091016945; Mon, 03 Jan 2011 13:43:36 -0800 (PST) Received: from [192.168.0.120] (61-128-17-190.fibertel.com.ar [190.17.128.61]) by mx.google.com with ESMTPS id u31sm10258307yba.21.2011.01.03.13.43.24 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 03 Jan 2011 13:43:36 -0800 (PST) Sender: Fernando Gont Message-ID: <4D2242E9.8040804@gont.com.ar> Date: Mon, 03 Jan 2011 18:43:05 -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: Brian E Carpenter Subject: Re: I-D Action:draft-ietf-6man-exthdr-01.txt References: <20101217234501.11691.81147.idtracker@localhost> <63416880-97B6-4CE4-864A-1402DA977B5F@tony.li> <4D113364.3050105@ericsson.com> <201101032040.p03KeE86005244@cichlid.raleigh.ibm.com> <4D223EC0.7020906@gmail.com> In-Reply-To: <4D223EC0.7020906@gmail.com> X-Enigmail-Version: 1.1.1 OpenPGP: id=D076FFF1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Thomas Narten , "ipv6@ietf.org" , Suresh Krishnan 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, 03 Jan 2011 21:41:31 -0000 On 03/01/2011 06:25 p.m., Brian E Carpenter wrote: > The basic motivation for the present draft is clear: > >> However, >> some intermediate nodes such as firewalls, may need to look at the >> transport layer header fields in order to make a decision to allow or >> deny the packet. > > That is, help middleboxes to violate e2e transparency and, furthermore, > allow unknown headers to cross those middleboxes. I don't think this I-D will make a difference. >From the POV of a firewall, unless it really wants a packet to pass-through, it will block it. So, whether the Extension Header is unknown, or whether draft-ietf-6man-exthdr-01.txt is implemented and the Specific type is unknown will lead to the same result: the packet will be discarded. This proposal would only be useful to firewalls that implement a "default allow", and that simply want to somehow ignore an unknown extension header and base their decision on the upper-layer protocol (only). -- But we all know that firewalls operate (or should operate) in "default deny" rather than "default allow". So IMHO this proposal won't be useful for such firewalls. 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 jmh@joelhalpern.com Mon Jan 3 13:51: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 7DC9E3A6C8E for ; Mon, 3 Jan 2011 13:51:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.36 X-Spam-Level: X-Spam-Status: No, score=-102.36 tagged_above=-999 required=5 tests=[AWL=-0.095, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, 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 AU-FTf8+t+-q for ; Mon, 3 Jan 2011 13:51:29 -0800 (PST) Received: from morbo.mail.tigertech.net (morbo.mail.tigertech.net [67.131.251.54]) by core3.amsl.com (Postfix) with ESMTP id 3AFB93A6C8D for ; Mon, 3 Jan 2011 13:51:29 -0800 (PST) Received: from hgblob.mail.tigertech.net (hgblob.mail.tigertech.net [64.62.209.71]) by morbo.tigertech.net (Postfix) with ESMTP id 16914A6F6F for ; Mon, 3 Jan 2011 13:53:36 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hgblob.tigertech.net (Postfix) with ESMTP id 065423228BE9 for ; Mon, 3 Jan 2011 13:53:26 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from [10.10.10.101] (pool-71-161-50-147.clppva.btas.verizon.net [71.161.50.147]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by hgblob.tigertech.net (Postfix) with ESMTPSA id 730543244781 for ; Mon, 3 Jan 2011 13:53:25 -0800 (PST) Message-ID: <4D224550.5080808@joelhalpern.com> Date: Mon, 03 Jan 2011 16:53:20 -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: "ipv6@ietf.org" Subject: Re: I-D Action:draft-ietf-6man-exthdr-01.txt References: <20101217234501.11691.81147.idtracker@localhost> <63416880-97B6-4CE4-864A-1402DA977B5F@tony.li> <4D113364.3050105@ericsson.com> <201101032040.p03KeE86005244@cichlid.raleigh.ibm.com> <4D223EC0.7020906@gmail.com> <4D2242E9.8040804@gont.com.ar> In-Reply-To: <4D2242E9.8040804@gont.com.ar> 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, 03 Jan 2011 21:51:31 -0000 If we take the view that a firewall will block anything it does not know, without question or limit, then 1) We have no way to extend our basic protocols that will pass through firewalls (we have to tunnel / encapsulate) 2) you are correct that this document does not help. Also, if we assume that no one will ever define any new extension headers, then this work does not matter. (If we want that prohibition to be the case, we should say so, and remove the hook for new extension headers that was left in 2460.) On the other hand, if we think that there will be new extension headers, and we think that firewalls block things if they can not find enough information to allow them through, then it can be helpful if the firewalls (and other devices) can parse pass these new extensions without knowing them. (Remember, these are for end-point consumption only.) It seems to me a disservice to simultaneously let people use new extension headers and not give them a way to use them that can be parsed past by the common devices that could easily want to do such parsing. My own preference would probably be to say that all end-to-end IP information should be in the destination options. But if we do not want to go there, then we should own up to the implications thereof. (In particular, there might be corner cases that can't use destination options. We should tell people to use destination options first. And tell them what to do if they can't.) Yours, Joel On 1/3/2011 4:43 PM, Fernando Gont wrote: > On 03/01/2011 06:25 p.m., Brian E Carpenter wrote: > >> The basic motivation for the present draft is clear: >> >>> However, >>> some intermediate nodes such as firewalls, may need to look at the >>> transport layer header fields in order to make a decision to allow or >>> deny the packet. >> >> That is, help middleboxes to violate e2e transparency and, furthermore, >> allow unknown headers to cross those middleboxes. > > I don't think this I-D will make a difference. > >> From the POV of a firewall, unless it really wants a packet to > pass-through, it will block it. > > So, whether the Extension Header is unknown, or whether > draft-ietf-6man-exthdr-01.txt is implemented and the Specific type is > unknown will lead to the same result: the packet will be discarded. > > This proposal would only be useful to firewalls that implement a > "default allow", and that simply want to somehow ignore an unknown > extension header and base their decision on the upper-layer protocol > (only). -- But we all know that firewalls operate (or should operate) in > "default deny" rather than "default allow". > > So IMHO this proposal won't be useful for such firewalls. > > Thanks, From yaroslav@arbor.net Mon Jan 3 16:46: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 127F03A677C for ; Mon, 3 Jan 2011 16:46:08 -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 RBZSlUFN2wgg for ; Mon, 3 Jan 2011 16:46:07 -0800 (PST) Received: from gateout02.mbox.net (gateout02.mbox.net [165.212.64.22]) by core3.amsl.com (Postfix) with ESMTP id EA7823A66B4 for ; Mon, 3 Jan 2011 16:46:06 -0800 (PST) Received: from gateout02.mbox.net (gwo2-lo [127.0.0.1]) by gateout02.mbox.net (Postfix) with ESMTP id A6F7A4BCA61 for ; Tue, 4 Jan 2011 00:48:13 +0000 (GMT) X-USANET-Received: from gateout02.mbox.net [127.0.0.1] by gateout02.mbox.net via mtad (C8.MAIN.3.71F) with ESMTP id 740PaDaWm9024Mo2; Tue, 04 Jan 2011 00:48:12 -0000 Received: from s1hub4.EXCHPROD.USA.NET [165.212.120.254] by gateout02.mbox.net via smtad (C8.MAIN.3.68M) with ESMTPS id XID457PaDaWm5652Xo2; Tue, 04 Jan 2011 00:48:12 -0000 X-USANET-Source: 165.212.120.254 IN yaroslav@arbor.net s1hub4.EXCHPROD.USA.NET X-USANET-MsgId: XID457PaDaWm5652Xo2 Received: from MBX14.EXCHPROD.USA.NET ([10.120.221.141]) by s1hub4.EXCHPROD.USA.NET ([10.120.220.34]) with mapi; Tue, 4 Jan 2011 00:48:06 +0000 From: "Rosomakho, Yaroslav" To: "ipv6@ietf.org" Date: Tue, 4 Jan 2011 00:48:04 +0000 Subject: Re: I-D Action:draft-ietf-6man-exthdr-01.txt Thread-Topic: I-D Action:draft-ietf-6man-exthdr-01.txt Thread-Index: AcurqQzV25+AinSPRtmonafpNc+A2A== Message-ID: In-Reply-To: <4D2242E9.8040804@gont.com.ar> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.0.101115 acceptlanguage: en-US 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: Tue, 04 Jan 2011 00:46:08 -0000 Generally I support the draft, but I also agree with comments about firewalls. To make this idea work, I would suggest changing word "must" to word "SHOULD" in definition of Hdr Options parameters. Designers of these additional headers have to acknowledge the fact that there is no guarantee of delivery of unknown headers over firewalls in any case. I also have concern about mandatory "ICMP Parameter problem" message required by second bit in the Hdr Options. While generally this is a nice idea, it could be abused to start a reflection attack. Obviously in real life this will be mitigated by control plane policing and other traditional security measures, but draft does not permit that. Replacing "must" with a "SHOULD" will fix this problem as well. Have you considered an option to allow a device that does not understand extension header to remove just the unknown header and continue processing the packet? =20 Best Regards, Yaroslav On 4/1/11 12:43 AM, "Fernando Gont" wrote: >On 03/01/2011 06:25 p.m., Brian E Carpenter wrote: > >> The basic motivation for the present draft is clear: >>=20 >>> However, >>> some intermediate nodes such as firewalls, may need to look at the >>> transport layer header fields in order to make a decision to allow >>>or >>> deny the packet. >>=20 >> That is, help middleboxes to violate e2e transparency and, furthermore, >> allow unknown headers to cross those middleboxes. > >I don't think this I-D will make a difference. > >From the POV of a firewall, unless it really wants a packet to >pass-through, it will block it. > >So, whether the Extension Header is unknown, or whether >draft-ietf-6man-exthdr-01.txt is implemented and the Specific type is >unknown will lead to the same result: the packet will be discarded. > >This proposal would only be useful to firewalls that implement a >"default allow", and that simply want to somehow ignore an unknown >extension header and base their decision on the upper-layer protocol >(only). -- But we all know that firewalls operate (or should operate) in >"default deny" rather than "default allow". > >So IMHO this proposal won't be useful for such firewalls. > >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 > > > > >-------------------------------------------------------------------- >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 Mon Jan 3 21:22:16 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 068283A6A5E for ; Mon, 3 Jan 2011 21:22:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.539 X-Spam-Level: X-Spam-Status: No, score=-1.539 tagged_above=-999 required=5 tests=[AWL=-0.738, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, RCVD_IN_NJABL_PROXY=1.643, RCVD_IN_SORBS_HTTP=0.001, RCVD_IN_SORBS_MISC=0.353, RCVD_IN_SORBS_SOCKS=0.801] 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 vPCXNKUOcaiI for ; Mon, 3 Jan 2011 21:22:15 -0800 (PST) Received: from mail-gw0-f66.google.com (mail-gw0-f66.google.com [74.125.83.66]) by core3.amsl.com (Postfix) with ESMTP id 1D8973A6A77 for ; Mon, 3 Jan 2011 21:22:15 -0800 (PST) Received: by gwj18 with SMTP id 18so3320305gwj.1 for ; Mon, 03 Jan 2011 21:24:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received: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=LPelRhNhMq7VPkxozI+VdO47YiykUsd/Va7Mj+vOpuo=; b=oUIwmbIrvth+mb7DsDb8g8L5OnWNmKAdZbh/OjfZ/h8loQR5zsHscUGRfQ0fU3yj5q 5Lguu5Va7n4yz2TCpMFCDO6Pw9YCHcuKmVZ0teQbxRv0Uc8yjmWs3ymA7XyR6Ltp7W7C 7U468o6v9HydDqnajiYmKF140DZN4YwcPs9Fc= 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=j8xbDnCDarXKjkaxIqoHCjws1dsXlEf9TIteeEVT+WkbHd2HgxZFWNRnrrWENdgKE+ 3w1x4w6PPiWUjjBKXXXV1LN1NOsbqNrki1ExODNswXmohWrgvYMHuvpfaxGq8e4U/eUM WApuIdmHnmEIl2rFwso/IIYRbtranJ4YKTUf4= Received: by 10.150.49.10 with SMTP id w10mr20261072ybw.231.1294118661866; Mon, 03 Jan 2011 21:24:21 -0800 (PST) Received: from [192.168.123.101] ([190.48.198.63]) by mx.google.com with ESMTPS id 46sm12842143yhl.12.2011.01.03.21.24.18 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 03 Jan 2011 21:24:20 -0800 (PST) Sender: Fernando Gont Message-ID: <4D22AEFD.8010903@gont.com.ar> Date: Tue, 04 Jan 2011 02:24:13 -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: I-D Action:draft-ietf-6man-exthdr-01.txt References: <20101217234501.11691.81147.idtracker@localhost> <63416880-97B6-4CE4-864A-1402DA977B5F@tony.li> <4D113364.3050105@ericsson.com> <201101032040.p03KeE86005244@cichlid.raleigh.ibm.com> <4D223EC0.7020906@gmail.com> <4D2242E9.8040804@gont.com.ar> <4D224550.5080808@joelhalpern.com> In-Reply-To: <4D224550.5080808@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: Tue, 04 Jan 2011 05:22:16 -0000 Hi, Joel, On 03/01/2011 06:53 p.m., Joel M. Halpern wrote: > If we take the view that a firewall will block anything it does not > know, without question or limit, then > 1) We have no way to extend our basic protocols that will pass through > firewalls (we have to tunnel / encapsulate) > 2) you are correct that this document does not help. I think we're talking about different issues here. The goal of this document is to "help" firewalls such that they can get to the transport protocol (*assuming* that the firewalls do not care about extension headers). -- and my point is that you don't need to do this. -- if the extension header is unknown, the firewall should not allow the packet through (i.e., default deny). The fact that the firewall cannot *parse* the header is a secondary issue. -- And all this has little or nothing to do with our ability to extend our protocols. Now, you may argue that a "default" deny limits our ability to extend our protocols. Strictly speaking, it doesn't -- it limits our ability to *deploy* them. But then, there's no reason (security-wise) for which an admin should allow a protocol to be deployed in his network without his prior consent. Yep... usability vs. security.... > Also, if we assume that no one will ever define any new extension > headers, then this work does not matter. Even then, why not just mandate that new extension headers (if they ever need to be defined) should be TLV? -- why do we need the extra header, etc.? > On the other hand, if we think that there will be new extension headers, > and we think that firewalls block things if they can not find enough > information to allow them through, then it can be helpful if the > firewalls (and other devices) can parse pass these new extensions > without knowing them. Just mandating that future extension headers have a syntax of TLV would suffice. Anyway, the rationale is that a firewall will allow stuff that it *needs* to allow. -- Why should a firewall allow an extension header that has not been deemed as necessary? >(Remember, these are for end-point consumption only.) NIDS, firewalls, and other middle-boxes consume these things.. even when they are not meant for them.... > It seems to me a disservice to simultaneously let people use new > extension headers and not give them a way to use them that can be parsed > past by the common devices that could easily want to do such parsing. Just mandate TLV, and that's it -- actually, not sure why this is not part of RFC 2460 alreay... > My own preference would probably be to say that all end-to-end IP > information should be in the destination options. But if we do not want > to go there, then we should own up to the implications thereof. (In > particular, there might be corner cases that can't use destination > options. Such as? Thanks! Kind regards, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 From pekkas@netcore.fi Mon Jan 3 22:31: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 5D8E03A6B43 for ; Mon, 3 Jan 2011 22:31:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.576 X-Spam-Level: X-Spam-Status: No, score=-102.576 tagged_above=-999 required=5 tests=[AWL=0.023, 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 RHoQCZsZ7Qgy for ; Mon, 3 Jan 2011 22:31:16 -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 5B1453A6B42 for ; Mon, 3 Jan 2011 22:31:16 -0800 (PST) Received: from netcore.fi (localhost [127.0.0.1]) by netcore.fi (8.13.8/8.13.8) with ESMTP id p046XDCk012785 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 4 Jan 2011 08:33:13 +0200 Received: from localhost (pekkas@localhost) by netcore.fi (8.13.8/8.13.8/Submit) with ESMTP id p046XDPA012782; Tue, 4 Jan 2011 08:33:13 +0200 Date: Tue, 4 Jan 2011 08:33:13 +0200 (EET) From: Pekka Savola To: Brian E Carpenter Subject: Re: addrsel: privacy addresses within/out of a site In-Reply-To: <4D2223DB.1000708@gmail.com> Message-ID: References: <20110103204031.0c3589b7@opy.nosense.org> <4D2223DB.1000708@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: 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, 04 Jan 2011 06:31:18 -0000 On Tue, 4 Jan 2011, Brian E Carpenter wrote: > Wouldn't the rule "Use ULA prefix inside the site and PA prefix (with > privacy addresses if desired) otherwise" be simpler? And, by default, > it would prevent the "inside" address being exported by mistake. Two prefixes in access lists doesn't seem simpler, though I see it could be an option in some other contexts. In our case, we have 20+ subnets which are not behind a single big firewall, so there is no "inside" and "outside". Also for that reason, using only globals would be preferable. -- 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 remi.despres@free.fr Tue Jan 4 01:32:49 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 60E3C3A6B6E for ; Tue, 4 Jan 2011 01:32:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.426 X-Spam-Level: X-Spam-Status: No, score=-1.426 tagged_above=-999 required=5 tests=[AWL=0.523, BAYES_00=-2.599, HELO_EQ_FR=0.35, 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 8OG-uDq5PCZB for ; Tue, 4 Jan 2011 01:32:47 -0800 (PST) Received: from smtp22.services.sfr.fr (smtp22.services.sfr.fr [93.17.128.10]) by core3.amsl.com (Postfix) with ESMTP id 1F3993A6B6C for ; Tue, 4 Jan 2011 01:32:46 -0800 (PST) Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2204.sfr.fr (SMTP Server) with ESMTP id 4D00F7000094; Tue, 4 Jan 2011 10:34:53 +0100 (CET) Received: from [192.168.0.20] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by msfrf2204.sfr.fr (SMTP Server) with ESMTP id CEA3F700008F; Tue, 4 Jan 2011 10:34:52 +0100 (CET) X-SFR-UUID: 20110104093452846.CEA3F700008F@msfrf2204.sfr.fr Subject: Re: Need your input on draft-ietf-6man-exthdr Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: <4D21CD00.1030906@ericsson.com> Date: Tue, 4 Jan 2011 10:34:52 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4D21CD00.1030906@ericsson.com> To: Suresh Krishnan X-Mailer: Apple Mail (2.1082) 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: Tue, 04 Jan 2011 09:32:50 -0000 Le 3 janv. 2011 =E0 14:20, Suresh Krishnan a =E9crit : > Hi Folks, > As some recent mails indicated there does not seem to be consensus = on > some parts of this draft. I would like to see what the wg feels (now) > before proceeding any further with this draft. >=20 > The draft contains three independent components >=20 > a) Specifying a uniform format for all future IPv6 extension headers = to > make them easier to parse/process. > b) Requesting a single IP protocol number codepoint for all future > extension headers and multiplexing them using a Specific Type field > inside the generic header. > c) Specifying error-handling and drop behavior for dealing with = unknown > extension headers. > =46rom what I have seen there seems to be no opposition to a) No opposition AND positive support: Skipping unknown extension headers can be useful not only in FWs but = also in some other places (e.g. in some variants of load balancers)=20 As Fernando noted, FWs that do "default deny" shouldn't be concerned. However, not all FWs are necessarily default deny in the strict sense = (i.e. with all fields of accepted packets having to be described) It may be useful to say, for example, "accept all incoming connections = to address X and port 80" without concern for extension headers. Besides, someone, Mark Townsley I believe, described a FW behavior = where: - packets known to be good are accepted - packets known to be bad are discarded - unknown packets are rate limited This is IMHO an interesting possibility that differs from just "default = deny". Points b and c are more debatable. I don't find them necessary. The draft would IMHO be better without them, but I don't object. The proposed addition in the "Meta question" seems useful =3D> +1 (But the document remains acceptable without it.) Regards RD > but there > is for b) and c). I will try to (loosely) summarize the viewpoints on > b) and c) and see if we can agree on what to do about them. >=20 > b) was added due to wg feedback > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D >=20 > Pros: > 1) Allows middleboxes to differentiate between unknown extension = headers > and unknown transport protocols > 2) Reduces the strain on the protocol number space >=20 > Cons: > 1) Uses up one protocol number even if no now extension headers are = ever > defined > 2) Any new extension header (including this one) will break existing > silicon. >=20 > c) was added due to the decision reached at the IETF79 wg meeting > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > Pros: > 1) Allows flexible handling behavior for dealing with unknown headers >=20 > Cons: > 1) Violates RFC2460 > 2) Duplicates the functionality provided by Destination options > 3) Unnecessary >=20 > META-question > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > RFC2460 allows the use of both extension headers and options to convey > optional information, I would like to add some text into this draft > suggesting that destination options are the preferred mechanism of = doing > so (since they offer better backward compatibility). Something like >=20 > "RFC2460 allows the use of both extension headers and destination > options in order to encode optional destination information in an IPv6 > packet. The use of destination options to encode this information, > provides more flexible handling characteristics and better backward > compatibility than using extension headers. Because of this, > implementations SHOULD use destination options as the preferred > mechanism for encoding optional destination information, and use a new > extension header only if destination options do not satisfy their = needs. > The request for allocation of a Specific Type value MUST be = accompanied > by an specific explanation of why destination options could not be = used > to convey this information." >=20 > Would this be an acceptable thing to add here? >=20 > I would appreciate the WG's opinion on these issues/questions before > going forward with this draft. >=20 > Thanks > Suresh >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From narten@us.ibm.com Tue Jan 4 06:18: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 24C3C3A6AD9 for ; Tue, 4 Jan 2011 06:18:23 -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 9KfBZt1pk3ef for ; Tue, 4 Jan 2011 06:18:22 -0800 (PST) Received: from e9.ny.us.ibm.com (e9.ny.us.ibm.com [32.97.182.139]) by core3.amsl.com (Postfix) with ESMTP id 0502A3A6BAF for ; Tue, 4 Jan 2011 06:18:21 -0800 (PST) Received: from d01dlp02.pok.ibm.com (d01dlp02.pok.ibm.com [9.56.224.85]) by e9.ny.us.ibm.com (8.14.4/8.13.1) with ESMTP id p04DuWXe019841 for ; Tue, 4 Jan 2011 08:56:46 -0500 Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by d01dlp02.pok.ibm.com (Postfix) with ESMTP id 611654DE803E for ; Tue, 4 Jan 2011 09:17:41 -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 p04EKReK166458 for ; Tue, 4 Jan 2011 09:20:28 -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 p04EKRxe011436 for ; Tue, 4 Jan 2011 07:20:27 -0700 Received: from cichlid.raleigh.ibm.com (sig-9-49-150-65.mts.ibm.com [9.49.150.65]) by d03av01.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id p04EKP42011388 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 4 Jan 2011 07:20:26 -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 p04EKOmT006328; Tue, 4 Jan 2011 09:20:25 -0500 Message-Id: <201101041420.p04EKOmT006328@cichlid.raleigh.ibm.com> To: Brian E Carpenter Subject: Re: I-D Action:draft-ietf-6man-exthdr-01.txt In-reply-to: <4D223EC0.7020906@gmail.com> References: <20101217234501.11691.81147.idtracker@localhost> <63416880-97B6-4CE4-864A-1402DA977B5F@tony.li> <4D113364.3050105@ericsson.com> <201101032040.p03KeE86005244@cichlid.raleigh.ibm.com> <4D223EC0.7020906@gmail.com> Comments: In-reply-to Brian E Carpenter message dated "Tue, 04 Jan 2011 10:25:20 +1300." Date: Tue, 04 Jan 2011 09:20:24 -0500 From: Thomas Narten X-Content-Scanned: Fidelis XPS MAILER Cc: "ipv6@ietf.org" , Suresh Krishnan 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, 04 Jan 2011 14:18:23 -0000 Brian E Carpenter writes: > > 2) The routing header is essentially deprecated, and we probably won't > > define any more. > The proposal for RH4, i.e. draft-ietf-6man-rpl-routing-header, > is active. Oh, right. But I view that as (essentially) an L2 usage. It will be used within one RPL domain, which is essentially its own link layer. Within an RPL, all IPv6 datagrams that come from outside the domain are encapsulated within a new IPv6 packet, so the outer IPv6 packet (with the RH4 header) is like a link-layer encapsulation. > However, isn't the real question whether we want to change the > implied intention that adding a new extension header should be > hard? Section 4 of RFC 2460 makes this intention pretty clear: > unknown extension headers should lead to packet discard and > ICMP Parameter Problem, so this is intended for consenting adults > only. Skipping over unknown extension headers was definitely > not intended to work. I don't think it's right to say 2460 intends to make defining new options "hard". Or more to the point, this document doesn't make defining new options any easier (from what I can see). The text in Section 4 is about how the intended recipient of an option is supposed to process it. If the intended recipient doesn't understand an option, that's arguably a bad situation. And the various 2460 definitions provide a way for the sender to get predictable (and reasonable) behavior in such situations. The alleged purpose of this document is to provide a way for devices that are NOT the intended recipient of an option to do "sensible things" with on option they don't understand, which is a sort of oxymoron. > The basic motivation for the present draft is clear: > > However, > > some intermediate nodes such as firewalls, may need to look at the > > transport layer header fields in order to make a decision to allow or > > deny the packet. > That is, help middleboxes to violate e2e transparency and, furthermore, > allow unknown headers to cross those middleboxes. If I was a paranoid > security person, I would definitely not be happy with this. On the > contrary - if I saw an unknown IP header in a packet, I would want > to discard it. A legacy firewall wouldn't recognize the Next Header > value for draft-ietf-6man-exthdr, so would discard the packet. If my > firewall had been updated, and saw a draft-ietf-6man-exthdr, header, > it would need to look at the embedded "Specific Type" and then decide > whether to discard it. Just a bit more deep packet inspection. But it is a very open question whether any middlebox will bother to do this. > So the one thing this proposal will *not* do is allow new extension headers > to cross the Internet transparently. All it might do is cause the firewalls > to dig one layer deeper before discarding the packet. This is at best poorly phrased. :-) If the firewall will just dig one layer deeper and then discard anyway, what is the point? Thomas From narten@us.ibm.com Tue Jan 4 06:27: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 64F263A6BA7 for ; Tue, 4 Jan 2011 06:27:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.599 X-Spam-Level: X-Spam-Status: No, score=-104.599 tagged_above=-999 required=5 tests=[AWL=2.000, 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 fRAMxcB-Nnei for ; Tue, 4 Jan 2011 06:27:06 -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 F41DC3A6855 for ; Tue, 4 Jan 2011 06:27:05 -0800 (PST) Received: from d01dlp01.pok.ibm.com (d01dlp01.pok.ibm.com [9.56.224.56]) by e4.ny.us.ibm.com (8.14.4/8.13.1) with ESMTP id p04EBOWZ021114 for ; Tue, 4 Jan 2011 09:11:31 -0500 Received: from d01relay05.pok.ibm.com (d01relay05.pok.ibm.com [9.56.227.237]) by d01dlp01.pok.ibm.com (Postfix) with ESMTP id ED7DC728075 for ; Tue, 4 Jan 2011 09:29:11 -0500 (EST) Received: from d01av02.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by d01relay05.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id p04ETBef160980 for ; Tue, 4 Jan 2011 09:29:11 -0500 Received: from d01av02.pok.ibm.com (loopback [127.0.0.1]) by d01av02.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id p04ETA65003564 for ; Tue, 4 Jan 2011 12:29:11 -0200 Received: from cichlid.raleigh.ibm.com (sig-9-49-150-65.mts.ibm.com [9.49.150.65]) by d01av02.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id p04ET9cV003489 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 4 Jan 2011 12:29:10 -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 p04ET81p006364; Tue, 4 Jan 2011 09:29:08 -0500 Message-Id: <201101041429.p04ET81p006364@cichlid.raleigh.ibm.com> To: Fernando Gont Subject: Re: I-D Action:draft-ietf-6man-exthdr-01.txt In-reply-to: <4D2242E9.8040804@gont.com.ar> References: <20101217234501.11691.81147.idtracker@localhost> <63416880-97B6-4CE4-864A-1402DA977B5F@tony.li> <4D113364.3050105@ericsson.com> <201101032040.p03KeE86005244@cichlid.raleigh.ibm.com> <4D223EC0.7020906@gmail.com> <4D2242E9.8040804@gont.com.ar> Comments: In-reply-to Fernando Gont message dated "Mon, 03 Jan 2011 18:43:05 -0300." Date: Tue, 04 Jan 2011 09:29:08 -0500 From: Thomas Narten X-Content-Scanned: Fidelis XPS MAILER Cc: "ipv6@ietf.org" , Brian E Carpenter , Suresh Krishnan 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, 04 Jan 2011 14:27:08 -0000 Fernando Gont writes: > On 03/01/2011 06:25 p.m., Brian E Carpenter wrote: > > The basic motivation for the present draft is clear: > > > >> However, > >> some intermediate nodes such as firewalls, may need to look at the > >> transport layer header fields in order to make a decision to allow or > >> deny the packet. > > > > That is, help middleboxes to violate e2e transparency and, furthermore, > > allow unknown headers to cross those middleboxes. > I don't think this I-D will make a difference. > From the POV of a firewall, unless it really wants a packet to > pass-through, it will block it. I think this is the crux of the problem. firewalls, by default, discard stuff. They don't like the idea of allowing unknown or "uncommon" things through. Defining new options and expecting firewalls to give them a blank check to go through I suspect is wishful thinking. And look at this from the perspective of someone who wants to deploy a new option. If 80% of the firewalls allow the new option through, will this be good enough for deployment? Doubtful. What about 98% cooperation from firewalls? Again, quite possibly not. Unless this document is widely implemented in practice, it's far from clear it is useful. We've seen time and time again that deploying something new is a non-starter if there are key parts of the infrastructure that don't support or allow it. I remain skeptical that this draft solves a real problem in a meaningful way. Thomas From rja.lists@gmail.com Tue Jan 4 07:15:49 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 50AC23A6C2F for ; Tue, 4 Jan 2011 07:15:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.224 X-Spam-Level: X-Spam-Status: No, score=-3.224 tagged_above=-999 required=5 tests=[AWL=0.375, 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 jC8K7fGoieBO for ; Tue, 4 Jan 2011 07:15:48 -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 495713A6C19 for ; Tue, 4 Jan 2011 07:15:48 -0800 (PST) Received: by qwg5 with SMTP id 5so15346844qwg.31 for ; Tue, 04 Jan 2011 07:17:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:content-type :content-transfer-encoding:subject:date:message-id:to:mime-version :x-mailer; bh=jgHUrXP8Y+UtJDGhWAVpy57vdbot2cX2N2tYxPG8tJw=; b=BOVZfzQmb/syysRKM3KBqqsqR5+KuZief6kdcrGg1BgG8QpTFI2kNOIN+dSs2WOOnP xTjWr1REuDwF83oSD7kz81KTAgeWaKev4Ru4KyOsc0fT4FbkSIcEYwKjdxmvKvTVCvBx 6k7Tq/tQxQH60D420YeBNwqAvUE0DKF9c3WKc= 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=ebaCBCx+zHyNYypeLMnGEvHoL3zqKfQVzTveJWuHa/x7DH7l3MIHew3Ou6f+5ZCrbw FV2+YqKmBaxtUHfeglgmFj2FOw4YiPSD3WJqOA19876gaDx5STBZCOdvTj524bG1PX5G y7EBK5SRGnYg4u9JK2+BfAghhje5cvHEMerS8= Received: by 10.224.80.203 with SMTP id u11mr20559903qak.221.1294154274443; Tue, 04 Jan 2011 07:17:54 -0800 (PST) Received: from vi-mhowell55.leclairryan.com ([38.103.42.150]) by mx.google.com with ESMTPS id h20sm12825280qck.24.2011.01.04.07.17.52 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 04 Jan 2011 07:17:53 -0800 (PST) From: RJ Atkinson Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: I-D Action:draft-ietf-6man-exthdr-01.txt Date: Tue, 4 Jan 2011 10:17:51 -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: Tue, 04 Jan 2011 15:15:49 -0000 All, I have very strong sympathy with the thoughts expressed by Thomas Narten in this note, especially: (A) the root question (not yet clearly answered, although it has been asked more than once) of what problem this I-D is trying to solve && (B) the observation about how RFC-5175 has been handled by various "IPv6 Profile" organisations: I also agree with Brian Carpenter's observation: % So the one thing this proposal will *not* do is allow % new extension headers to cross the Internet transparently. Indeed, the BEST chance for a new IPv6-specific extension to be deployable is to be specified to be carried within an IPv6 Destination Options header. Further, I believe that if a future proposal could be carried in an IPv6 Destination Option, then it ought to be REQUIRED to be carried in an IPv6 Destination Option. This maximises backwards compatibility, and is consistent with the clear intent of RFC-2460. Existing deployed silicon (think Verilog & logic gates, not NP or CPU) from multiple vendors know how to parse past such an IPv6 Destination Options header in order to locate the actual transport-layer protocol and transport-layer port-numbers (e.g. to apply QoS or ACLs). This proposed new IPv6 Extension Header will *break* this *deployed* capability. I know that it is deployed today in multiple large multi- continent ISPs to parse past an optional headers. There are also site-border-router/firewall boxes that have this capability, used to allow certain applications (based upon examining the transport-layer protocol and transport-layer port numbers that are located *after* the optional header) and/or to permit authorised traffic even when an optional header is present between the IPv6 header and the transport-layer protocol. I have a strong desire to avoid breaking this deployed and important operational capability. I also support these 2 specific comments from Joel Halpern, particularly these 2 ideas: I) removing "the hook for new extension headers that was left in RFC-2460" (extension headers are only allowed in narrow circumstances at present) && II) "to say that all end-to-end IP information" MUST "be in the destination options". His precise words that I agree with are: > (If we want that prohibition to be the case, we should say so, > and remove the hook for new extension headers that was left in 2460.) and separately: > My own preference would probably be to say that all end-to-end > IP information should be in the destination options. I believe there would be broad support within the IPv6 WG to have a small clarification to RFC-2460 that required the use of Destination Options in all cases where they can be made to work (in essence, this is Joel's I and II above). However, that could be done in a 1-page (plus boilerplate) draft. Since Suresh has been driving this issue, perhaps Suresh could create such a 1-page (plus boilerplate) draft for the IPv6 WG to review ? (:-) Yours, Ran From slblake@petri-meat.com Tue Jan 4 07:18: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 A887D3A69F2 for ; Tue, 4 Jan 2011 07:18:41 -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 sm500bEu4F0f for ; Tue, 4 Jan 2011 07:18:40 -0800 (PST) Received: from elom.tchmachines.com (elom.tchmachines.com [208.76.80.198]) by core3.amsl.com (Postfix) with ESMTP id DA06E3A69E7 for ; Tue, 4 Jan 2011 07:18:40 -0800 (PST) Received: from cpe-174-097-227-047.nc.res.rr.com ([174.97.227.47]) by elom.tchmachines.com with esmtpa (Exim 4.69) (envelope-from ) id 1Pa8gm-0003yT-7B for ipv6@ietf.org; Tue, 04 Jan 2011 10:20:44 -0500 Subject: Re: I-D Action:draft-ietf-6man-exthdr-01.txt From: Steven Blake To: "ipv6@ietf.org" In-Reply-To: <201101041420.p04EKOmT006328@cichlid.raleigh.ibm.com> References: <20101217234501.11691.81147.idtracker@localhost> <63416880-97B6-4CE4-864A-1402DA977B5F@tony.li> <4D113364.3050105@ericsson.com> <201101032040.p03KeE86005244@cichlid.raleigh.ibm.com> <4D223EC0.7020906@gmail.com> <201101041420.p04EKOmT006328@cichlid.raleigh.ibm.com> Content-Type: text/plain; charset="UTF-8" Date: Tue, 04 Jan 2011 10:20:46 -0500 Message-ID: <1294154446.3814.9.camel@tachyon> Mime-Version: 1.0 X-Mailer: Evolution 2.28.3 (2.28.3-1.fc12) Content-Transfer-Encoding: 7bit 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 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, 04 Jan 2011 15:18:41 -0000 On Tue, 2011-01-04 at 09:20 -0500, Thomas Narten wrote: > This is at best poorly phrased. :-) > > If the firewall will just dig one layer deeper and then discard > anyway, what is the point? +1 I still don't understand what this draft solves that couldn't be solved more easily by just encoding future header extensions as either Destination options or Hop-by-Hop options? Both of these are easy to parse and have well defined rules for how to handle unknown options. Regards, // Steve From d.sturek@att.net Wed Dec 29 10:03:12 2010 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 1D17428C10C for ; Wed, 29 Dec 2010 10:03:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.438 X-Spam-Level: X-Spam-Status: No, score=0.438 tagged_above=-999 required=5 tests=[AWL=-1.614, BAYES_50=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_33=0.6, MSGID_MULTIPLE_AT=1.449, UNPARSEABLE_RELAY=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 GoF0V4u3WzXg for ; Wed, 29 Dec 2010 10:03:02 -0800 (PST) Received: from nm25-vm0.bullet.mail.ne1.yahoo.com (nm25-vm0.bullet.mail.ne1.yahoo.com [98.138.91.73]) by core3.amsl.com (Postfix) with SMTP id 093F33A6866 for ; Wed, 29 Dec 2010 10:03:01 -0800 (PST) Received: from [98.138.90.51] by nm25.bullet.mail.ne1.yahoo.com with NNFMP; 29 Dec 2010 18:05:04 -0000 Received: from [98.138.89.173] by tm4.bullet.mail.ne1.yahoo.com with NNFMP; 29 Dec 2010 18:05:04 -0000 Received: from [127.0.0.1] by omp1029.mail.ne1.yahoo.com with NNFMP; 29 Dec 2010 18:05:04 -0000 X-Yahoo-Newman-Id: 552366.77147.bm@omp1029.mail.ne1.yahoo.com Received: (qmail 71330 invoked from network); 29 Dec 2010 18:05:04 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=att.net; s=s1024; t=1293645904; bh=eRzqmr1C2g4+gSafmje6XS9gmfrYom5DZ7fP82wKBZw=; h=Received:X-Yahoo-SMTP:X-YMail-OSG:X-Yahoo-Newman-Property:Reply-To:From:To:References:In-Reply-To:Subject:Date:Message-ID:MIME-Version:Content-Type:X-Mailer:Thread-Index:Content-Language; b=vBBlzqMo/ZIrrscVI8l24xhM+o3tKj5FNhUFVNxpsY4UIjBc+T33AcGXIHnWu+pRdT9JutGOzwOGkwFbVSHMHRZ0ncRQoem67hQQ7W6N4fy7XJSnNDXHhDmeEPEgpH/zSdEfagwxE7xnk8EwEzulM1LzVvDqqEpfcyp1TO8Yb1Y= Received: from Studio (d.sturek@69.224.191.84 with login) by smtp105.sbc.mail.ne1.yahoo.com with SMTP; 29 Dec 2010 10:04:57 -0800 PST X-Yahoo-SMTP: fvjol_aswBAraSJvMLe2r1XTzhBhbFxY8q8c3jo- X-YMail-OSG: .c0pScEVM1nsCSHXDP6ds0Cq9H5xDmwZIYWGanqmKxjZ2Rv N5OTGxv16hdY4.hfAaiSkMuk6DumrYGu9BTrpPCyQCWrbHROVlCM.BaRI1pj MWd66XdPmKJheSNI.bMM3qPK49JoXIllMchV8zRILqCB9Tp7K3.t4FVCKF5l eWdXav8WTGkjDiasNgP76_4KKa17TgTFfzMXkTwM_f.HAr0JXyqrFkbhB.uf IAOs11Rd83admXEszduFtL59vyq6TpQuQO656OwYwUGyuvZIj6eC0Z2T.5hm rA35cuIVdUoJewGEkEA9oWA1Uk2KENqRzGBa4aEwYTKFbQF649TSLFBz2AIK QUlsx X-Yahoo-Newman-Property: ymail-3 From: "Don Sturek" To: "'Brian Haberman'" , "'IPv6 WG Mailing List'" References: <4D0A19C0.4020409@innovationslab.net> In-Reply-To: <4D0A19C0.4020409@innovationslab.net> Subject: RE: Lack of responses on WG Last Calls Date: Wed, 29 Dec 2010 10:04:50 -0800 Message-ID: <009401cba782$e3c8dd10$ab5a9730$@sturek@att.net> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0095_01CBA73F.D5A59D10" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcudKJL1mR04nIDBQa+KRdZ8obH6ewKWQ12g Content-Language: en-us X-Mailman-Approved-At: Tue, 04 Jan 2011 08:04:47 -0800 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: d.sturek@att.net List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Dec 2010 18:03:12 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0095_01CBA73F.D5A59D10 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Brian, Sorry for the delay in getting this to you. Attached are the results of the ZigBee Alliance testing using the RPL-related drafts draft-ietf-6man-rpl-option and draft-ietf-6man-rpl-routing-header. Here are the relevant attachments: 1) Test spec we are using. We are testing PANA, EAP-TLS, ROLL-RPL as well as the two drafts so the relevant parts are the ones where you find RH4 (near the bottom since the higher test cases are around joining and authentication) 2) Test results. Company names were removed per the engagement rules in the ZigBee Alliance. Here is the only relevant comment we had to the drafts: "Use latest rpl-routing-header option draft; in our topologies, typically comprI will be set to 0x0e; and comprE can be 0x0e or 0x00 ( usecase for comprE = 0 is not clear ); but node should be able to receive and process any value". Our only question is what comprE=0 is used for. Sorry for the format of these. I know this is not typical for IETF but I ran out of time to format these. Let me know if the format is a problem. Don Sturek Chair, ZigBee Alliance Core Stack Working Group (responsible for "ZigBee IP" profile to define an interoperable IEEE 802.15.4 based solution with IPv6). -----Original Message----- From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of Brian Haberman Sent: Thursday, December 16, 2010 5:53 AM To: IPv6 WG Mailing List Subject: Lack of responses on WG Last Calls All, Working group last calls ended 10 days ago for the two RPL-related drafts (draft-ietf-6man-rpl-option and draft-ietf-6man-rpl-routing-header). By my count, each draft received *1* comment. The chairs cannot and will not advance a draft to the IESG with so little feedback. We request that WG participants review these drafts and provide their feedback on them. Regards, Brian & Bob -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- ------=_NextPart_000_0095_01CBA73F.D5A59D10 Content-Type: text/html; name="TestSpecContent.html" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="TestSpecContent.html"

1.1 Host Join - 1 Hop

Initial Condition

channel: 0x14 for all devices
panId: 0x1AAA
linkLocal: fe80::/64
globalPrefix: fd01::/64

Topology

Host               BorderRouter

|                |
|   --------->   | 1. Beacon Request =
(broadcast)
|   <-----       | 2. Beacon =
Response
|                |

|                |
|   --------->   | 3. RS =
(multicast)
|   <-----       | 4. RA
|                |

|                |
|   ------>      | NS
|   <------      | NA
|                |

|                |
|   ------>      | ICMP Request
|   <------      | ICMP Reply
|                |

Sub Test Cases

A: Host =3D DUT
B: Border Router =3D DUT

Test Procedure

1. Beacon request is sent to initiate active scan
2. Beacon response is replied from all routers within radio = range
3. Router Solicitation (RS) is sent as muticast to discovery routers = within range
4. Router Advertisement (RA) is replied from all routers within radio = range, containing prefix and context information
Neighbor Advertisement (NA) is replied by parent router 
802.15.4
  source: Short address
  dest: Success? Short address : IEEE address
IP
  Hop limit: 255
  source: LL16 of parent router
  dest: Success ? GP16 : LL64
  Target: LL16 of parent router
ARO: EUI-64, no IP address, status
ICMP request is initiated to verify communication 
IP
  source: GP16=20
  dest: GP16
ICMPV6
  Type: 0x80
ICMP reply is replied by parent router 
802.15.4
  source: Short address
  dest: Success? Short address : IEEE address
IP
  Hop limit: 255
  source: LL16 of parent router
  dest: Success ? GP16 : LL64
  Target: LL16 of parent router
ARO: EUI-64, no IP address, status

Verification

  • All packets shall follow the formats described.
  • Communication via ping shall succeed.

    • 1.2 Host Join - 2 Hop

    Initial Condition

    channel: 0x14 for all devices
    panId: 0x1AAA
    linkLocal: fe80::/64
    globalPrefix: fd01::/64

    Topology

    Host               ParentRouter       BorderRouter

    |                |
|   --------->   | 1. Beacon Request =
(broadcast)
|   <-----       | 2. Beacon =
Response
|                |

    |                |
|   --------->   | 3. RS =
(multicast)
|   <-----       | 4. RA
|                |

    |                |
|   ------>      | NS
|                |   ------>       | DAR
|                |   <------       | DAC
|   <------      | NA
|                |

    |                |
|   ------>      | ICMP Request
|                |   ------>       | ICMP Request
|                |   <------       | ICMP Reply
|   <------      | ICMP Reply
|                |

    Sub Test Cases

    A: Host =3D DUT
    B: Parent/Relay Router =3D DUT
    C: Border Router =3D DUT

    Test Procedure

    1. Beacon request is sent to initiate active scan
    2. Beacon response is replied from all routers within radio = range
    3. Router Solicitation (RS) is sent as muticast to discovery routers = within range
    4. Router Advertisement (RA) is replied from all routers within radio = range, containing prefix and context information
    Neighbor Solicitation (NS) is initiated to discovery neighbor and = validate (short) address 
    802.15.4
  source: Short address (tentative)
  dest: Short address (Derived from SLLAO in RA)
IP
  Hop limit: 255
  source: GP16 (tentative)
  dest: LL16 of parent router
  Target: LL16 of parent router
SLLAO: Short address
ARO: EUI-64, no IP address, status=3D0
    Duplicate Address Request (DAR) is initiated from parent router 
    type	156
802.15.4
  source: Short address of parent router
  dest: Short address of next hop
IP
  Hop limit: [variable]
  source:	GP16 of parent router
  dest: GP16 of LBR
  Status: 0
  Registration lifetime: [variable]
  EUI-64: EUI-64 of registering node
  Registered Address: IP source of NS that contained ARO option
    Duplicate Address Confirmation (DAC) is forwarded to parent = router 
    type	157
802.15.4
  source: Short address of LBR
  dest: Short address of next hop
IP
  Hop limit: [variable]
  source: GP16 of LBR
  dest: GP16 of parent router
  Status: Draft-ietf-6lowpan-nd-14 Table 1
  Registration lifetime: [variable]
  EUI-64: EUI-64 of registering node
  Registered Address: Copied from the DAR
    Neighbor Advertisement (NA) is replied by parent router 
    802.15.4
  source: Short address
  dest: Success? Short address : IEEE address
IP
  Hop limit: 255
  source: LL16 of parent router
  dest: Success ? GP16 : LL64
  Target: LL16 of parent router
ARO: EUI-64, no IP address, status
    ICMP request is initiated to verify communication 
    IP
  source: GP16=20
  dest: GP16
ICMPV6
  Type: 0x80
    ICMP request is forwarded by parent router 
    IP
  source: GP16=20
  dest: GP16
ICMPV6
  Type: 0x80
    ICMP reply is forwarded to parent router 
    IP
  source: GP16=20
  dest: GP16
ICMPV6
  Type: 0x81
    ICMP reply is replied by parent router 
    802.15.4
  source: Short address
  dest: Success? Short address : IEEE address
IP
  Hop limit: 255
  source: LL16 of parent router
  dest: Success ? GP16 : LL64
  Target: LL16 of parent router
ARO: EUI-64, no IP address, status

    Verification

  • All packets shall follow the formats described.
  • Communication via ping shall succeed.

    • 1.3 Host Join - 3 Hop

    Initial Condition

    channel: 0x14 for all devices
    panId: 0x1AAA
    linkLocal: fe80::/64
    globalPrefix: fd01::/64

    Topology

    Host               ParentRouter       RelayRouter   =
    BorderRouter

    |                |
|   --------->   | 1. Beacon Request =
(broadcast)
|   <-----       | 2. Beacon =
Response
|                |

    |                |
|   --------->   | 3. RS =
(multicast)
|   <-----       | 4. RA
|                |

    |                |
|   ------>      | NS
|                |   ------>       | DAR
|                |                 |   ------>       | DAR
|                |                 |   <------       | DAC
|                |   <------       | DAC
|   <------      | NA
|                |

    |                |
|   ------>      | ICMP Request
|                |   ------>       | ICMP Request
|                |                 |   ------>       | ICMP Request
|                |                 |   <------       | ICMP Reply
|                |   <------       | ICMP Reply
|   <------      | ICMP Reply
|                |

    Sub Test Cases

    A: Host =3D DUT
    B: Parent Router =3D DUT
    C: Relay Router =3D DUT
    D: Border Router =3D DUT

    Test Procedure

    1. Beacon request is sent to initiate active scan
    2. Beacon response is replied from all routers within radio = range
    3. Router Solicitation (RS) is sent as muticast to discovery routers = within range
    4. Router Advertisement (RA) is replied from all routers within radio = range, containing prefix and context information
    Neighbor Solicitation (NS) is initiated to discovery neighbor and = validate (short) address 
    802.15.4
  source: Short address (tentative)
  dest: Short address (Derived from SLLAO in RA)
IP
  Hop limit: 255
  source: GP16 (tentative)
  dest: LL16 of parent router
  Target: LL16 of parent router
SLLAO: Short address
ARO: EUI-64, no IP address, status=3D0
    Duplicate Address Request (DAR) is initiated from parent router 
    type	156
802.15.4
  source: Short address of parent router
  dest: Short address of next hop
IP
  Hop limit: [variable]
  source:	GP16 of parent router
  dest: GP16 of LBR
  Status: 0
  Registration lifetime: [variable]
  EUI-64: EUI-64 of registering node
  Registered Address: IP source of NS that contained ARO option
    Duplicate Address Request (DAR) is forwarded by relay router 
    type	156
802.15.4
  source: Short address of parent router
  dest: Short address of next hop
IP
  Hop limit: [variable]
  source:	GP16 of parent router
  dest: GP16 of LBR
  Status: 0
  Registration lifetime: [variable]
  EUI-64: EUI-64 of registering node
  Registered Address: IP source of NS that contained ARO option
    Duplicate Address Confirmation (DAC) is responded by border = router 
    type	157
802.15.4
  source: Short address of LBR
  dest: Short address of next hop
IP
  Hop limit: [variable]
  source: GP16 of LBR
  dest: GP16 of parent router
  Status: Draft-ietf-6lowpan-nd-14 Table 1
  Registration lifetime: [variable]
  EUI-64: EUI-64 of registering node
  Registered Address: Copied from the DAR
    Duplicate Address Confirmation (DAC) is forwarded to parent = router 
    type	157
802.15.4
  source: Short address of LBR
  dest: Short address of next hop
IP
  Hop limit: [variable]
  source: GP16 of LBR
  dest: GP16 of parent router
  Status: Draft-ietf-6lowpan-nd-14 Table 1
  Registration lifetime: [variable]
  EUI-64: EUI-64 of registering node
  Registered Address: Copied from the DAR
    Neighbor Advertisement (NA) is replied by parent router 
    802.15.4
  source: Short address
  dest: Success? Short address : IEEE address
IP
  Hop limit: 255
  source: LL16 of parent router
  dest: Success ? GP16 : LL64
  Target: LL16 of parent router
ARO: EUI-64, no IP address, status
    ICMP request is initiated to verify communication 
    IP
  source: GP16=20
  dest: GP16
ICMPV6
  Type: 0x80
    ICMP request is forwarded by parent router 
    IP
  source: GP16=20
  dest: GP16
ICMPV6
  Type: 0x80
    ICMP request is forwarded by relay router 
    IP
  source: GP16=20
  dest: GP16
ICMPV6
  Type: 0x80
    ICMP reply is responded by border router 
    IP
  source: GP16=20
  dest: GP16
ICMPV6
  Type: 0x81
    ICMP reply is forwarded to parent router 
    IP
  source: GP16=20
  dest: GP16
ICMPV6
  Type: 0x81
    ICMP reply is replied by parent router 
    802.15.4
  source: Short address
  dest: Success? Short address : IEEE address
IP
  Hop limit: 255
  source: LL16 of parent router
  dest: Success ? GP16 : LL64
  Target: LL16 of parent router
ARO: EUI-64, no IP address, status

    Verification

  • All packets shall follow the formats described.
  • Communication via ping shall succeed.

    • 1.4 Router Join - 1 Hop

    Initial Condition

    channel: 0x14 for all devices
    panId: 0x1AAA
    linkLocal: fe80::/64
    globalPrefix: fd01::/64

    Topology

    Router             BorderRouter

    |                |
|   --------->   | 1. Beacon Request =
(broadcast)
|   <-----       | 2. Beacon =
Response
|                |

    |                |
|   --------->   | 3. RS =
(multicast)
|   <-----       | 4. RA
|                |

    |                |
|   ------>      | NS
|   <------      | NA
|                |

    |                |
|   --------->   | DIS (broadcast)
|   <-----       | DIO (from all routers in radio range)
|   ------>      | DIS (unicast)
|   <-----       | DIO (with prefix information)
|                |

    |                |
|   ------>      | DAO
|   <------      | DAO-ACK
|                |

    |                |
|   ------>      | ICMP Request
|   <------      | ICMP Reply
|                |

    Sub Test Cases

    A: Router =3D DUT
    B: Border Router =3D DUT

    Test Procedure

    1. Beacon request is sent to initiate active scan
    2. Beacon response is replied from all routers within radio = range
    3. Router Solicitation (RS) is sent as muticast to discovery routers = within range
    4. Router Advertisement (RA) is replied from all routers within radio = range, containing prefix and context information
    Neighbor Solicitation (NS) is initiated to discovery neighbor and = validate (short) address 
    802.15.4
  source: Short address (tentative)
  dest: Short address (Derived from SLLAO in RA)
IP
  Hop limit: 255
  source: GP16 (tentative)
  dest: LL16 of parent router
  Target: LL16 of parent router
SLLAO: Short address
ARO: EUI-64, no IP address, status=3D0
    Neighbor Advertisement (NA) is replied by parent router 
    802.15.4
  source: Short address
  dest: Success? Short address : IEEE address
IP
  Hop limit: 255
  source: LL16 of parent router
  dest: Success ? GP16 : LL64
  Target: LL16 of parent router
ARO: EUI-64, no IP address, status
    DODAG Information Solicitation (DIS) is sent as broadcast 
    IP
  source: LL16
  destination: FF02::1A
ICMPv6 DIS
  DIS Base
    2 bytes reserved
    No options
    2 bytes padding
    DODAG Information Object (DIO) is replied from all routers within = radio range 
    IP
  source: LL16
  dest: LL16 of DIS sender
ICMPv6 DIO=20
  DIO Base
    'G': 1 (grounded)
    MOP: binary 001
    PRF: 0
    DODAGID: GP16 of root
  Route Information Option
    Prefix Length: 64
    Route Lifetime: 0xFFFFFFFF
    Prefix: GP
  DODAG Configuration Option
    'A': 0
    DIOIntMIN  : 3
    DIOIntDoubl: 20
    DIORedun:    10
    MaxRankIncrease: 0
    MinHopRankIncrease: 256
  Prefix Information Option
    'R': 1
    Valid Lifetime: 0xFFFFFFFF
    Preferred Lifetime: 0xFFFFFFFF
    Prefix: GP16 of source
    DODAG Information Solicitation (DIS) is sent as unicast to parent = router 
    IP
  source: LL16
  destination: FF02::1A
ICMPv6 DIS
  DIS Base
    2 bytes reserved
    No options
    2 bytes padding
    DODAG Information Object (DIO) is replied from parent router with = prefix information 
    IP
  source: LL16
  dest: LL16 of DIS sender
ICMPv6 DIO=20
  DIO Base
    'G': 1 (grounded)
    MOP: binary 001
    PRF: 0
    DODAGID: GP16 of root
  Route Information Option
    Prefix Length: 64
    Route Lifetime: 0xFFFFFFFF
    Prefix: GP
  DODAG Configuration Option
    'A': 0
    DIOIntMIN  : 3
    DIOIntDoubl: 20
    DIORedun:    10
    MaxRankIncrease: 0
    MinHopRankIncrease: 256
  Prefix Information Option
    'R': 1
    Valid Lifetime: 0xFFFFFFFF
    Preferred Lifetime: 0xFFFFFFFF
    Prefix: GP16 of source
    Destination Advertisement Object (DAO) is initiated to establish = upward route 
    IP
  source: GP16
  dest: GP16 of root
ICMPv6 DAO
  DAO Base
    'K': 1
    'D': 0
  Target Option
    Prefix Length: 128
    Target Prefix: GP16
  Transit Option
    Path Control: 1
    Path Lifetime: 0xFFFFFFFF
    Parent Address: GP16 of parent
    Destination Advertisement Object Acknowledgement (DAO-ACK) is = forwarded by parent router 
    IP
  source: GP16 of root
  dest: GP16
  Routing Extension Header RH4 (if hop>1)
    Compr: 14
    Addresses: list of MAC short addresses
ICMPV6 DAO-ACK
  'D': 0
    ICMP request is initiated to verify communication 
    IP
  source: GP16=20
  dest: GP16
ICMPV6
  Type: 0x80
    ICMP reply is replied by parent router 
    802.15.4
  source: Short address
  dest: Success? Short address : IEEE address
IP
  Hop limit: 255
  source: LL16 of parent router
  dest: Success ? GP16 : LL64
  Target: LL16 of parent router
ARO: EUI-64, no IP address, status

    Verification

  • All packets shall follow the formats described.
  • Communication via ping shall succeed.

    • 1.5 Router Join - 2 Hop

    Initial Condition

    channel: 0x14 for all devices
    panId: 0x1AAA
    linkLocal: fe80::/64
    globalPrefix: fd01::/64

    Topology

    Router             ParentRouter       BorderRouter

    |                |
|   --------->   | 1. Beacon Request =
(broadcast)
|   <-----       | 2. Beacon =
Response
|                |

    |                |
|   --------->   | 3. RS =
(multicast)
|   <-----       | 4. RA
|                |

    |                |
|   ------>      | NS
|                |   ------>       | DAR
|                |   <------       | DAC
|   <------      | NA
|                |

    |                |
|   --------->   | DIS (broadcast)
|   <-----       | DIO (from all routers in radio range)
|   ------>      | DIS (unicast)
|   <-----       | DIO (with prefix information)
|                |

    |                |
|   ------>      | DAO
|                |   ------>       | DAO
|                |   <------       | DAO-ACK
|   <------      | DAO-ACK
|                |

    |                |
|   ------>      | ICMP Request
|                |   ------>       | ICMP Request
|                |   <------       | ICMP Reply
|   <------      | ICMP Reply
|                |

    Sub Test Cases

    A: Router =3D DUT
    B: Parent/Relay Router =3D DUT
    C: Border Router =3D DUT

    Test Procedure

    1. Beacon request is sent to initiate active scan
    2. Beacon response is replied from all routers within radio = range
    3. Router Solicitation (RS) is sent as muticast to discovery routers = within range
    4. Router Advertisement (RA) is replied from all routers within radio = range, containing prefix and context information
    Neighbor Solicitation (NS) is initiated to discovery neighbor and = validate (short) address 
    802.15.4
  source: Short address (tentative)
  dest: Short address (Derived from SLLAO in RA)
IP
  Hop limit: 255
  source: GP16 (tentative)
  dest: LL16 of parent router
  Target: LL16 of parent router
SLLAO: Short address
ARO: EUI-64, no IP address, status=3D0
    Duplicate Address Request (DAR) is initiated from parent router 
    type	156
802.15.4
  source: Short address of parent router
  dest: Short address of next hop
IP
  Hop limit: [variable]
  source:	GP16 of parent router
  dest: GP16 of LBR
  Status: 0
  Registration lifetime: [variable]
  EUI-64: EUI-64 of registering node
  Registered Address: IP source of NS that contained ARO option
    Duplicate Address Confirmation (DAC) is forwarded to parent = router 
    type	157
802.15.4
  source: Short address of LBR
  dest: Short address of next hop
IP
  Hop limit: [variable]
  source: GP16 of LBR
  dest: GP16 of parent router
  Status: Draft-ietf-6lowpan-nd-14 Table 1
  Registration lifetime: [variable]
  EUI-64: EUI-64 of registering node
  Registered Address: Copied from the DAR
    Neighbor Advertisement (NA) is replied by parent router 
    802.15.4
  source: Short address
  dest: Success? Short address : IEEE address
IP
  Hop limit: 255
  source: LL16 of parent router
  dest: Success ? GP16 : LL64
  Target: LL16 of parent router
ARO: EUI-64, no IP address, status
    DODAG Information Solicitation (DIS) is sent as broadcast 
    IP
  source: LL16
  destination: FF02::1A
ICMPv6 DIS
  DIS Base
    2 bytes reserved
    No options
    2 bytes padding
    DODAG Information Object (DIO) is replied from all routers within = radio range 
    IP
  source: LL16
  dest: LL16 of DIS sender
ICMPv6 DIO=20
  DIO Base
    'G': 1 (grounded)
    MOP: binary 001
    PRF: 0
    DODAGID: GP16 of root
  Route Information Option
    Prefix Length: 64
    Route Lifetime: 0xFFFFFFFF
    Prefix: GP
  DODAG Configuration Option
    'A': 0
    DIOIntMIN  : 3
    DIOIntDoubl: 20
    DIORedun:    10
    MaxRankIncrease: 0
    MinHopRankIncrease: 256
  Prefix Information Option
    'R': 1
    Valid Lifetime: 0xFFFFFFFF
    Preferred Lifetime: 0xFFFFFFFF
    Prefix: GP16 of source
    DODAG Information Solicitation (DIS) is sent as unicast to parent = router 
    IP
  source: LL16
  destination: FF02::1A
ICMPv6 DIS
  DIS Base
    2 bytes reserved
    No options
    2 bytes padding
    DODAG Information Object (DIO) is replied from parent router with = prefix information 
    IP
  source: LL16
  dest: LL16 of DIS sender
ICMPv6 DIO=20
  DIO Base
    'G': 1 (grounded)
    MOP: binary 001
    PRF: 0
    DODAGID: GP16 of root
  Route Information Option
    Prefix Length: 64
    Route Lifetime: 0xFFFFFFFF
    Prefix: GP
  DODAG Configuration Option
    'A': 0
    DIOIntMIN  : 3
    DIOIntDoubl: 20
    DIORedun:    10
    MaxRankIncrease: 0
    MinHopRankIncrease: 256
  Prefix Information Option
    'R': 1
    Valid Lifetime: 0xFFFFFFFF
    Preferred Lifetime: 0xFFFFFFFF
    Prefix: GP16 of source
    Destination Advertisement Object (DAO) is initiated to establish = upward route 
    IP
  source: GP16
  dest: GP16 of root
ICMPv6 DAO
  DAO Base
    'K': 1
    'D': 0
  Target Option
    Prefix Length: 128
    Target Prefix: GP16
  Transit Option
    Path Control: 1
    Path Lifetime: 0xFFFFFFFF
    Parent Address: GP16 of parent
    Destination Advertisement Object (DAO) is forwarded by parent = router 
    IP
  source: GP16
  dest: GP16 of root
ICMPv6 DAO
  DAO Base
    'K': 1
    'D': 0
  Target Option
    Prefix Length: 128
    Target Prefix: GP16
  Transit Option
    Path Control: 1
    Path Lifetime: 0xFFFFFFFF
    Parent Address: GP16 of parent
    Destination Advertisement Object Acknowledgement (DAO-ACK) is = forwarded to parent router 
    IP
  source: GP16 of root
  dest: GP16
  Routing Extension Header RH4 (if hop>1)
    Compr: 14
    Addresses: list of MAC short addresses
ICMPV6 DAO-ACK
  'D': 0
    Destination Advertisement Object Acknowledgement (DAO-ACK) is = forwarded by parent router 
    IP
  source: GP16 of root
  dest: GP16
  Routing Extension Header RH4 (if hop>1)
    Compr: 14
    Addresses: list of MAC short addresses
ICMPV6 DAO-ACK
  'D': 0
    ICMP request is initiated to verify communication 
    IP
  source: GP16=20
  dest: GP16
ICMPV6
  Type: 0x80
    ICMP request is forwarded by parent router 
    IP
  source: GP16=20
  dest: GP16
ICMPV6
  Type: 0x80
    ICMP reply is forwarded to parent router 
    IP
  source: GP16=20
  dest: GP16
ICMPV6
  Type: 0x81
    ICMP reply is replied by parent router 
    802.15.4
  source: Short address
  dest: Success? Short address : IEEE address
IP
  Hop limit: 255
  source: LL16 of parent router
  dest: Success ? GP16 : LL64
  Target: LL16 of parent router
ARO: EUI-64, no IP address, status

    Verification

  • All packets shall follow the formats described.
  • Communication via ping shall succeed.

    • 1.6 Router Join - 3 Hop

    Initial Condition

    channel: 0x14 for all devices
    panId: 0x1AAA
    linkLocal: fe80::/64
    globalPrefix: fd01::/64

    Topology

    Router             ParentRouter       RelayRouter   =
    BorderRouter

    |                |
|   --------->   | 1. Beacon Request =
(broadcast)
|   <-----       | 2. Beacon =
Response
|                |

    |                |
|   --------->   | 3. RS =
(multicast)
|   <-----       | 4. RA
|                |

    |                |
|   ------>      | NS
|                |   ------>       | DAR
|                |                 |   ------>       | DAR
|                |                 |   <------       | DAC
|                |   <------       | DAC
|   <------      | NA
|                |

    |                |
|   --------->   | DIS (broadcast)
|   <-----       | DIO (from all routers in radio range)
|   ------>      | DIS (unicast)
|   <-----       | DIO (with prefix information)
|                |

    |                |
|   ------>      | DAO
|                |   ------>       | DAO
|                |                 |   ------>       | DAO
|                |                 |   <------       | DAO-ACK
|                |   <------       | DAO-ACK
|   <------      | DAO-ACK
|                |

    |                |
|   ------>      | ICMP Request
|                |   ------>       | ICMP Request
|                |                 |   ------>       | ICMP Request
|                |                 |   <------       | ICMP Reply
|                |   <------       | ICMP Reply
|   <------      | ICMP Reply
|                |

    Sub Test Cases

    A: Router =3D DUT
    B: Parent Router =3D DUT
    C: Relay Router =3D DUT
    D: Border Router =3D DUT

    Test Procedure

    1. Beacon request is sent to initiate active scan
    2. Beacon response is replied from all routers within radio = range
    3. Router Solicitation (RS) is sent as muticast to discovery routers = within range
    4. Router Advertisement (RA) is replied from all routers within radio = range, containing prefix and context information
    Neighbor Solicitation (NS) is initiated to discovery neighbor and = validate (short) address 
    802.15.4
  source: Short address (tentative)
  dest: Short address (Derived from SLLAO in RA)
IP
  Hop limit: 255
  source: GP16 (tentative)
  dest: LL16 of parent router
  Target: LL16 of parent router
SLLAO: Short address
ARO: EUI-64, no IP address, status=3D0
    Duplicate Address Request (DAR) is initiated from parent router 
    type	156
802.15.4
  source: Short address of parent router
  dest: Short address of next hop
IP
  Hop limit: [variable]
  source:	GP16 of parent router
  dest: GP16 of LBR
  Status: 0
  Registration lifetime: [variable]
  EUI-64: EUI-64 of registering node
  Registered Address: IP source of NS that contained ARO option
    Duplicate Address Request (DAR) is forwarded by relay router 
    type	156
802.15.4
  source: Short address of parent router
  dest: Short address of next hop
IP
  Hop limit: [variable]
  source:	GP16 of parent router
  dest: GP16 of LBR
  Status: 0
  Registration lifetime: [variable]
  EUI-64: EUI-64 of registering node
  Registered Address: IP source of NS that contained ARO option
    Duplicate Address Confirmation (DAC) is responded by border = router 
    type	157
802.15.4
  source: Short address of LBR
  dest: Short address of next hop
IP
  Hop limit: [variable]
  source: GP16 of LBR
  dest: GP16 of parent router
  Status: Draft-ietf-6lowpan-nd-14 Table 1
  Registration lifetime: [variable]
  EUI-64: EUI-64 of registering node
  Registered Address: Copied from the DAR
    Duplicate Address Confirmation (DAC) is forwarded to parent = router 
    type	157
802.15.4
  source: Short address of LBR
  dest: Short address of next hop
IP
  Hop limit: [variable]
  source: GP16 of LBR
  dest: GP16 of parent router
  Status: Draft-ietf-6lowpan-nd-14 Table 1
  Registration lifetime: [variable]
  EUI-64: EUI-64 of registering node
  Registered Address: Copied from the DAR
    Neighbor Advertisement (NA) is replied by parent router 
    802.15.4
  source: Short address
  dest: Success? Short address : IEEE address
IP
  Hop limit: 255
  source: LL16 of parent router
  dest: Success ? GP16 : LL64
  Target: LL16 of parent router
ARO: EUI-64, no IP address, status
    DODAG Information Solicitation (DIS) is sent as broadcast 
    IP
  source: LL16
  destination: FF02::1A
ICMPv6 DIS
  DIS Base
    2 bytes reserved
    No options
    2 bytes padding
    DODAG Information Object (DIO) is replied from all routers within = radio range 
    IP
  source: LL16
  dest: LL16 of DIS sender
ICMPv6 DIO=20
  DIO Base
    'G': 1 (grounded)
    MOP: binary 001
    PRF: 0
    DODAGID: GP16 of root
  Route Information Option
    Prefix Length: 64
    Route Lifetime: 0xFFFFFFFF
    Prefix: GP
  DODAG Configuration Option
    'A': 0
    DIOIntMIN  : 3
    DIOIntDoubl: 20
    DIORedun:    10
    MaxRankIncrease: 0
    MinHopRankIncrease: 256
  Prefix Information Option
    'R': 1
    Valid Lifetime: 0xFFFFFFFF
    Preferred Lifetime: 0xFFFFFFFF
    Prefix: GP16 of source
    DODAG Information Solicitation (DIS) is sent as unicast to parent = router 
    IP
  source: LL16
  destination: FF02::1A
ICMPv6 DIS
  DIS Base
    2 bytes reserved
    No options
    2 bytes padding
    DODAG Information Object (DIO) is replied from parent router with = prefix information 
    IP
  source: LL16
  dest: LL16 of DIS sender
ICMPv6 DIO=20
  DIO Base
    'G': 1 (grounded)
    MOP: binary 001
    PRF: 0
    DODAGID: GP16 of root
  Route Information Option
    Prefix Length: 64
    Route Lifetime: 0xFFFFFFFF
    Prefix: GP
  DODAG Configuration Option
    'A': 0
    DIOIntMIN  : 3
    DIOIntDoubl: 20
    DIORedun:    10
    MaxRankIncrease: 0
    MinHopRankIncrease: 256
  Prefix Information Option
    'R': 1
    Valid Lifetime: 0xFFFFFFFF
    Preferred Lifetime: 0xFFFFFFFF
    Prefix: GP16 of source
    Destination Advertisement Object (DAO) is initiated to establish = upward route 
    IP
  source: GP16
  dest: GP16 of root
ICMPv6 DAO
  DAO Base
    'K': 1
    'D': 0
  Target Option
    Prefix Length: 128
    Target Prefix: GP16
  Transit Option
    Path Control: 1
    Path Lifetime: 0xFFFFFFFF
    Parent Address: GP16 of parent
    Destination Advertisement Object (DAO) is forwarded by parent = router 
    IP
  source: GP16
  dest: GP16 of root
ICMPv6 DAO
  DAO Base
    'K': 1
    'D': 0
  Target Option
    Prefix Length: 128
    Target Prefix: GP16
  Transit Option
    Path Control: 1
    Path Lifetime: 0xFFFFFFFF
    Parent Address: GP16 of parent
    Destination Advertisement Object (DAO) is forwarded by relay = router 
    IP
  source: GP16
  dest: GP16 of root
ICMPv6 DAO
  DAO Base
    'K': 1
    'D': 0
  Target Option
    Prefix Length: 128
    Target Prefix: GP16
  Transit Option
    Path Control: 1
    Path Lifetime: 0xFFFFFFFF
    Parent Address: GP16 of parent
    Destination Advertisement Object Acknowledgement (DAO-ACK) is = responded by border router 
    IP
  source: GP16 of root
  dest: GP16
  Routing Extension Header RH4 (if hop>1)
    Compr: 14
    Addresses: list of MAC short addresses
ICMPV6 DAO-ACK
  'D': 0
    Destination Advertisement Object Acknowledgement (DAO-ACK) is = forwarded to parent router 
    IP
  source: GP16 of root
  dest: GP16
  Routing Extension Header RH4 (if hop>1)
    Compr: 14
    Addresses: list of MAC short addresses
ICMPV6 DAO-ACK
  'D': 0
    Destination Advertisement Object Acknowledgement (DAO-ACK) is = forwarded by parent router 
    IP
  source: GP16 of root
  dest: GP16
  Routing Extension Header RH4 (if hop>1)
    Compr: 14
    Addresses: list of MAC short addresses
ICMPV6 DAO-ACK
  'D': 0
    ICMP request is initiated to verify communication 
    IP
  source: GP16=20
  dest: GP16
ICMPV6
  Type: 0x80
    ICMP request is forwarded by parent router 
    IP
  source: GP16=20
  dest: GP16
ICMPV6
  Type: 0x80
    ICMP request is forwarded by relay router 
    IP
  source: GP16=20
  dest: GP16
ICMPV6
  Type: 0x80
    ICMP reply is responded by border router 
    IP
  source: GP16=20
  dest: GP16
ICMPV6
  Type: 0x81
    ICMP reply is forwarded to parent router 
    IP
  source: GP16=20
  dest: GP16
ICMPV6
  Type: 0x81
    ICMP reply is replied by parent router 
    802.15.4
  source: Short address
  dest: Success? Short address : IEEE address
IP
  Hop limit: 255
  source: LL16 of parent router
  dest: Success ? GP16 : LL64
  Target: LL16 of parent router
ARO: EUI-64, no IP address, status

    Verification

  • All packets shall follow the formats described.
  • Communication via ping shall succeed.

    • 1.7 Host Join - 1 Hop, with = Authentication

    Initial Condition

    channel: 0x14 for all devices
    panId: 0x1AAA
    linkLocal: fe80::/64
    globalPrefix: fd01::/64
    CCM Parameters: MIC Length M =3D 8, Length length L =3D 3
    Test Pre-shared key (PSK) octet string: {0xcf, 0xce, 0xcd, 0xcc, 0xcb,=20 0xca, 0xc9, 0xc8, 0xc7, 0xc6, 0xc5, 0xc4, 0xc3, 0xc2, 0xc1, 0xc0}
    Test Network key octet string: {0xbf, 0xbe, 0xbd, 0xbc, 0xbb, 0xba, = 0xb9, 0xb8, 0xb7, 0xb6, 0xb5, 0xb4, 0xb3, 0xb2, 0xb1, 0xb0}
    Key length N =3D 16

    Topology

    Host               BorderRouter

    |                |
|   --------->   | Beacon Request (broadcast)
|   <-----       | Beacon Response
|                |

    |                |
|   --------->   | RS (multicast)
|   <-----       | RA
|                |

    |                |
|   ------>      | PCI
|   <------      | PAR
|   ------>      | PAN
|   <------      | PAR EAP Request
|   ------>      | PAN EAP Response
|   <------      | PAR TLS Start
|   ------>      | PAN TLS Client Hello
|   <------      | PAR TLS Server Hello, Server Hello Done
|   ------>      | PAN TLS Client Key Exchange, Change Cipher Spec, =
Finished
|   <------      | PAR TLS Change Cipher Spec, Finish, Network key
|   ------>      | PAN EAP Response
|   <------      | PAR EAP Success
|   ------>      | PAN Complete
|                |

    |                |
|   ------>      | NS
|   <------      | NA
|                |

    |                |
|   ------>      | ICMP Request
|   <------      | ICMP Reply
|                |

    Sub Test Cases

    A: Host =3D DUT
    B: Border Router =3D DUT

    Test Procedure

    Beacon request is sent to initiate active scan 
    802.15.4
  FrameControl: 0x0803
    FrameType: 0x03
    SecurityEnable: false
    FramePending: false
    AckRequired: false
    IntraPan: false
    Dest Addr Mode: 0x02
    Src Addr Mode: 0x00
  Dest PanId: 0xffff
  Short Dest Addr: 0xffff
802.15.4 command: 0x07
    Beacon response is replied from all routers within = radio range 
    802.15.4
  FrameControl: 0x8000
    FrameType: 0x00
    SecurityEnable: false
    FramePending: false
    AckRequired: false
    IntraPan: false
    Dest Addr Mode: 0x00
    Src Addr Mode: 0x02
  Source PanId: [variable]
  Short Source Addr: [variable]
Beacon Payload
  Protocal ID: 0x02
  Control Field
    Bit 0: Allow Join
    Bit 1-7: Reserved
  NetworkID
  AppInfo
    Router Solicitation (RS) is sent as muticast to = discovery routers within range 
    802.15.4
  source: IEEE address
  dest: Broadcast
IP
  Hop limit: 255
  source: LL64
  dest: All-routers multicast
SLLAO: IEEE address
    Router Advertisement (RA) is replied from all routers = within radio range, containing prefix and context information 
    802.15.4
  source: Short address
  dest: IEEE address
IP
  Hop limit: 255
  source: LL16
  dest: LL64
SLLAO: Short address
PIO: PAN-wide prefix (GP)
ABRO: 6LBR (GP16)
6CO: Context 0 (i.e. GP)
    PANA-Client-Initiation (PCI) is initiated by PANA = Client (PaC) to establish the authentication 
    PANA
  rsvd: 0
  length: 16
  flags: 0x0000
  type: 1
  session_id: 0
  seq_no: 0
    PANA-Auth-Request (PAR) is received by PANA = Client 
    PANA
  rsvd: 0
  length: 40
  flags: 0xC000
  type: 2
  session_id: paa_session_id
  seq_no: paa_seq_no
If PRF_HMAC_SHA2_256 is the only PRF, the following AVP may be optional
PANAAVP
  code: 6
  flags: 0
  length: 4
  rsvd: 0
  prf_algorithm: 5
If AUTH_HMAC_SHA2_256_128 is the only integrity algorithm, the following =
AVP may be optional
PANAAVP
  code: 3
  flags: 0
  length: 4
  rsvd: 0
  integrity_algorithm: 12
    PANA-Auth-Answer (PAN) is replied by PaC 
    PANA
  rsvd: 0
  length: 40
  flags: 0x4000
  type: 2
  session_id: paa_session_id
  seq_no: paa_seq_no
If PRF_HMAC_SHA2_256 is the only PRF, the following AVP may be optional
PANAAVP
  code: 6
  flags: 0
  length: 4
  rsvd: 0
  prf_algorithm: 5
If AUTH_HMAC_SHA2_256_128 is the only integrity algorithm, the following =
AVP may be optional
PANAAVP
  code: 3
  flags: 0
  length: 4
  rsvd: 0
  integrity_algorithm: 12
    PANA EAP Request is received by PANA Client 
    PANA
  rsvd: 0
  length: 56
  flags: 0x8000
  type: 2
  session_id: paa_session_id
  seq_no: paa_seq_no + 1
PANAAVP
  code: 5
  flags: 0
  length: 16
  rsvd: 0
  nonce: 16 bytes
PANAAVP - optional
  code: 2
  flags: 0
  length: 5
  rsvd: 0
  EAPReqUnfrag
    code: 1
    identifier: idseq
    length: 5
    type: 1
  AVPPad: 3 bytes
    PANA EAP Response is replied by PaC 
    PANA
  rsvd: 0
  length: 64
  flags: 0x0000
  type: 2
  session_id: paa_session_id
  seq_no: paa_seq_no + 1
PANAAVP
  code: 5
  flags: 0
  length: 16
  rsvd: 0
  nonce: 16 bytes
PANAAVP - optional
  code: 2
  flags: 0
  length: 14
  rsvd: 0
  EAPRespUnfrag
    code: 2
    identifier: idseq
    length: 14
    type: 1
    identity: "anonymous"
  AVPPad: 2 bytes
    PANA TLS Start is received by PANA Client 
    PANA
  rsvd: 0
  length: 32
  flags: 0x8000
  type: 2
  session_id: paa_session_id
  seq_no: paa_seq_no + 2
PANAAVP
  code: 2
  flags: 0
  length: 6
  rsvd: 0
  EAPReqUnfrag
    code: 1
    identifier: idseq + 1
    length: 6
    type: 21
    flags: 0x20
  AVPPad: 2 bytes
    PANA TLS Client Hello is replied by PaC 
    PANA
  rsvd: 0
  length: 80
  flags: 0x0000
  type: 2
  session_id: paa_session_id
  seq_no: paa_seq_no + 2
PANAAVP
  code: 2
  flags: 0
  length: 56
  rsvd: 0
  EAPRespUnfrag
    code: 2
    identifier: idseq + 1
    length: 56
    type: 21
    flags: 0x00
    TLSPlaintext
      type: 22
      version: 0x0303
      length: 45
      Handshake
        msg_type: 1
        length: 41
        ClientHello
          ProtocolVersion
            major: 0x03
            minor: 0x03
          Random
            gmt_unix_time
            random_bytes: 28 bytes
          SessionID<0..32>
            length: 0 (NULL)
          <2..2^16-2>
            length: 2
            CipherSuite=20
              bytes: {0x00, 0xC6}
          <1..2^8-2>
            length: 1
            compression_methods: {0}
          NOTE: extensions will be needed for public key cipher suite
            No extensions=20
    PANA TLS Server Hello, Server Hello Done is received = by PANA Client 
    PANA
  rsvd: 0
  length: 88
  flags: 0x8000
  type: 2
  session_id: paa_session_id
  seq_no: paa_seq_no + 3
PANAAVP
  code: 2
  flags: 0
  length: 61
  rsvd: 0
  EAPReqUnfrag
    code: 1
    identifier: idseq + 2
    length: 61
    type: 21
    flags: 0x00
    TLSPlaintext
      type: 22
      version: 0x0303
      length: 50
      Handshake
        msg_type: 2
        length: 42
        ServerHello
          ProtocolVersion
            major: 0x03
            minor: 0x03
          Random
            gmt_unix_time
            random_bytes: 28 bytes
          SessionID<0..32>
            length: 4
            bytes: 4
            CipherSuite=20
              bytes: {0x00, 0xC6}
            compression_methods: {0}
          NOTE: extensions will be needed for public key cipher suite
            No extensions=20
      Handshake
        msg_type: 14
        length: 0
        ServerHelloDone: Empty
  AVPPad: 3 bytes
    PANA TLS Client Key Exchange, Change Cipher Spec, = Finished is replied by PaC 
    PANA
  rsvd: 0
  length: 88
  flags: 0x0000
  type: 2
  session_id: paa_session_id
  seq_no: paa_seq_no + 3
PANAAVP
  code: 2
  flags: 0
  length: 62
  rsvd: 0
  EAPRespUnfrag
    code: 2
    identifier: idseq + 2
    length: 62
    type: 21
    flags: 0x00
    TLSPlaintext
      type: 22
      version: 0x0303
      length: 4
      Handshake
        msg_type: 16
        length: 4
        ClientKeyExchange
          <0..2^16-1>
            length: 2
            bytes: {0x30, 0x00}
    TLSPlaintext
      type: 20
      version: 0x0303
      length: 1
      ChangeCipherSpec
        type: 1
    TLSPlaintext
      type: 22
      version: 0x0303
      length: 32
      GenericAEADCipher
        CCMNonceExplicit
          seq_num
        CCMCipherText
          Handshake
            msg_type: 20
            length: 12
            Finished
              verify_data: 12 bytes
        MAC: Using AES_CCM_8
  AVPPad: 2 bytes
    PANA TLS Change Cipher Spec, Finish, Network key is = received by PANA Client 
    PANA
  rsvd: 0
  length: 134
  flags: 0x8000
  type: 2
  session_id: paa_session_id
  seq_no: paa_seq_no + 4
PANAAVP
  code: 2
  flags: 0
  length: 49
  rsvd: 0
  EAPReqUnfrag
    code: 1
    identifier: idseq + 3
    length: 112
    type: 21
    flags: 0x00
    TLSPlaintext
      type: 20
      version: 0x0303
      length: 1
      ChangeCipherSpec
        type: 1
    TLSPlaintext
      type: 22
      version: 0x0303
      length: 32
      GenericAEADCipher
        CCMNonceExplicit
          seq_num
        CCMCipherText
          Handshake
            msg_type: 20
            length: 12
            Finished
              verify_data: 12 bytes
        MAC: Using AES_CCM_8
    TLSPlaintext
      type: 23
      version: 0x0303
      length: 44
      GenericAEADCipher
        CCMNonceExplicit
          seq_num
        CCMCipherText
          EAPTTLSAVP
            avp_code: 1
            avp_flags: 0xC0
            length: 28
            vendor_id: 36743
            network key: 16 bytes
        MAC: Using AES_CCM_8
    PANA EAP Response is replied by PaC 
    PANA
  rsvd: 0
  length: 30
  flags: 0x0000
  type: 2
  session_id: paa_session_id
  seq_no: paa_seq_no + 4
PANAAVP
  code: 2
  flags: 0
  length: 6
  rsvd: 0
  nonce: 16 bytes
  EAPRespUnfrag
    code: 2
    identifier: idseq + 3
    length: 6
    type: 21
    flag: 0x20
  AVPPad: 2 bytes
    PANA EAP Success is received by PANA Client 
    PANA
  rsvd: 0
  length: 88
  flags: 0xA000
  type: 2
  session_id: paa_session_id
  seq_no: paa_seq_no + 5
PANAAVP
  code: 7
  flags: 0
  length: 4
  rsvd: 0
  result_code: 0
PANAAVP
  code: 2
  flags: 0
  length: 4
  rsvd: 0
  EAPSUCCESS
    code: 3
    identifier: idseq + 4
    length: 4
PANAAVP
  code: 4
  flags: 0
  length: 4
  rsvd: 0
  key_id: 0
PANAAVP
  code: 8
  flags: 0
  length: 4
  rsvd: 0
  sess_life: 0xFFFFFFFF
PANAAVP
  code: 1
  flags: 0
  length: 16
  rsvd: 0
  auth: 16 bytes
    PANA Complete is replied by PaC 
    PANA
  rsvd: 0
  length: 54
  flags: 0x2000
  type: 2
  session_id: paa_session_id
  seq_no: paa_seq_no + 5
PANAAVP
  code: 4
  flags: 0
  length: 4
  rsvd: 0
  key_id: 0
PANAAVP
  code: 1
  flags: 0
  length: 16
  rsvd: 0
  auth: 16 bytes
    Neighbor Solicitation (NS) is initiated to discovery = neighbor and validate (short) address 
    802.15.4
  source: Short address (tentative)
  dest: Short address (Derived from SLLAO in RA)
IP
  Hop limit: 255
  source: GP16 (tentative)
  dest: LL16 of parent router
  Target: LL16 of parent router
SLLAO: Short address
ARO: EUI-64, no IP address, status=3D0
    Neighbor Advertisement (NA) is replied by parent = router 
    802.15.4
  source: Short address
  dest: Success? Short address : IEEE address
IP
  Hop limit: 255
  source: LL16 of parent router
  dest: Success ? GP16 : LL64
  Target: LL16 of parent router
ARO: EUI-64, no IP address, status
    ICMP request is initiated to verify communication 
    IP
  source: GP16=20
  dest: GP16
ICMPV6
  Type: 0x80
    ICMP reply is replied by parent router 
    802.15.4
  source: Short address
  dest: Success? Short address : IEEE address
IP
  Hop limit: 255
  source: LL16 of parent router
  dest: Success ? GP16 : LL64
  Target: LL16 of parent router
ARO: EUI-64, no IP address, status

    Verification

  • All packets shall follow the formats = described.
  • Communication via ping shall succeed.

    •

    1.8 Host Join - 2 Hop, with = Authentication

    Initial Condition

    channel: 0x14 for all devices
    panId: 0x1AAA
    linkLocal: fe80::/64
    globalPrefix: fd01::/64
    CCM Parameters: MIC Length M =3D 8, Length length L =3D 3
    Test Pre-shared key (PSK) octet string: {0xcf, 0xce, 0xcd, 0xcc, 0xcb,=20 0xca, 0xc9, 0xc8, 0xc7, 0xc6, 0xc5, 0xc4, 0xc3, 0xc2, 0xc1, 0xc0}
    Test Network key octet string: {0xbf, 0xbe, 0xbd, 0xbc, 0xbb, 0xba, = 0xb9, 0xb8, 0xb7, 0xb6, 0xb5, 0xb4, 0xb3, 0xb2, 0xb1, 0xb0}
    Key length N =3D 16

    Topology

    Host               ParentRouter       BorderRouter

    |                |
|   --------->   | Beacon Request (broadcast)
|   <-----       | Beacon Response
|                |

    |                |
|   --------->   | RS (multicast)
|   <-----       | RA
|                |

    |                |
|   ------>      | PCI
|                |   ------>       | RLY(PCI)
|                |   <------       | RLY(PAR)
|   <------      | PAR
|   ------>      | PAN
|                |   ------>       | RLY(PAN)
|                |   <------       | RLY(PAR EAP Request)
|   <------      | PAR EAP Request
|   ------>      | PAN EAP Response
|                |   ------>       | RLY(PAN EAP Response)
|                |   <------       | RLY(PAR TLS Start)
|   <------      | PAR TLS Start
|   ------>      | PAN TLS Client Hello
|                |   ------>       | RLY(PAN TLS Client Hello)
|                |   <------       | RLY(PAR TLS Server Hello, Server =
Hello Done)
|   <------      | PAR TLS Server Hello, Server Hello Done
|   ------>      | PAN TLS Client Key Exchange, Change Cipher Spec, =
Finished
|                |   ------>       | RLY(PAN TLS Client Key Exchange, =
Change Cipher Spec, Finished)
|                |   <------       | RLY(PAR TLS Change Cipher Spec, =
Finish, Network key)
|   <------      | PAR TLS Change Cipher Spec, Finish, Network key
|   ------>      | PAN EAP Response
|                |   ------>       | RLY(PAN EAP Response)
|                |   <------       | RLY(PAR EAP Success)
|   <------      | PAR EAP Success
|   ------>      | PAN Complete
|                |   ------>       | RLY(PAN Complete)
|                |

    |                |
|   ------>      | NS
|                |   ------>       | DAR
|                |   <------       | DAC
|   <------      | NA
|                |

    |                |
|   ------>      | ICMP Request
|                |   ------>       | ICMP Request
|                |   <------       | ICMP Reply
|   <------      | ICMP Reply
|                |

    Sub Test Cases

    A: Host =3D DUT
    B: Parent/Relay Router =3D DUT
    C: Border Router =3D DUT

    Test Procedure

    Beacon request is sent to initiate active scan 
    802.15.4
  FrameControl: 0x0803
    FrameType: 0x03
    SecurityEnable: false
    FramePending: false
    AckRequired: false
    IntraPan: false
    Dest Addr Mode: 0x02
    Src Addr Mode: 0x00
  Dest PanId: 0xffff
  Short Dest Addr: 0xffff
802.15.4 command: 0x07
    Beacon response is replied from all routers within = radio range 
    802.15.4
  FrameControl: 0x8000
    FrameType: 0x00
    SecurityEnable: false
    FramePending: false
    AckRequired: false
    IntraPan: false
    Dest Addr Mode: 0x00
    Src Addr Mode: 0x02
  Source PanId: [variable]
  Short Source Addr: [variable]
Beacon Payload
  Protocal ID: 0x02
  Control Field
    Bit 0: Allow Join
    Bit 1-7: Reserved
  NetworkID
  AppInfo
    Router Solicitation (RS) is sent as muticast to = discovery routers within range 
    802.15.4
  source: IEEE address
  dest: Broadcast
IP
  Hop limit: 255
  source: LL64
  dest: All-routers multicast
SLLAO: IEEE address
    Router Advertisement (RA) is replied from all routers = within radio range, containing prefix and context information 
    802.15.4
  source: Short address
  dest: IEEE address
IP
  Hop limit: 255
  source: LL16
  dest: LL64
SLLAO: Short address
PIO: PAN-wide prefix (GP)
ABRO: 6LBR (GP16)
6CO: Context 0 (i.e. GP)
    PANA-Client-Initiation (PCI) is initiated by PANA = Client (PaC) to establish the authentication 
    PANA
  rsvd: 0
  length: 16
  flags: 0x0000
  type: 1
  session_id: 0
  seq_no: 0
    PANA-Client-Initiation (PCI) is forwarded by PANA = relay router 
    PANA
  rsvd: 0
  length: 16
  flags: 0x0000
  type: 1
  session_id: 0
  seq_no: 0
    PANA-Auth-Request (PAR) is forwarded by PANA relay = router 
    PANA
  rsvd: 0
  length: 40
  flags: 0xC000
  type: 2
  session_id: paa_session_id
  seq_no: paa_seq_no
If PRF_HMAC_SHA2_256 is the only PRF, the following AVP may be optional
PANAAVP
  code: 6
  flags: 0
  length: 4
  rsvd: 0
  prf_algorithm: 5
If AUTH_HMAC_SHA2_256_128 is the only integrity algorithm, the following =
AVP may be optional
PANAAVP
  code: 3
  flags: 0
  length: 4
  rsvd: 0
  integrity_algorithm: 12
    PANA-Auth-Request (PAR) is received by PANA = Client 
    PANA
  rsvd: 0
  length: 40
  flags: 0xC000
  type: 2
  session_id: paa_session_id
  seq_no: paa_seq_no
If PRF_HMAC_SHA2_256 is the only PRF, the following AVP may be optional
PANAAVP
  code: 6
  flags: 0
  length: 4
  rsvd: 0
  prf_algorithm: 5
If AUTH_HMAC_SHA2_256_128 is the only integrity algorithm, the following =
AVP may be optional
PANAAVP
  code: 3
  flags: 0
  length: 4
  rsvd: 0
  integrity_algorithm: 12
    PANA-Auth-Answer (PAN) is replied by PaC 
    PANA
  rsvd: 0
  length: 40
  flags: 0x4000
  type: 2
  session_id: paa_session_id
  seq_no: paa_seq_no
If PRF_HMAC_SHA2_256 is the only PRF, the following AVP may be optional
PANAAVP
  code: 6
  flags: 0
  length: 4
  rsvd: 0
  prf_algorithm: 5
If AUTH_HMAC_SHA2_256_128 is the only integrity algorithm, the following =
AVP may be optional
PANAAVP
  code: 3
  flags: 0
  length: 4
  rsvd: 0
  integrity_algorithm: 12
    PANA-Auth-Answer (PAN) is forwarded by PANA relay = router 
    PANA
  rsvd: 0
  length: 40
  flags: 0x4000
  type: 2
  session_id: paa_session_id
  seq_no: paa_seq_no
If PRF_HMAC_SHA2_256 is the only PRF, the following AVP may be optional
PANAAVP
  code: 6
  flags: 0
  length: 4
  rsvd: 0
  prf_algorithm: 5
If AUTH_HMAC_SHA2_256_128 is the only integrity algorithm, the following =
AVP may be optional
PANAAVP
  code: 3
  flags: 0
  length: 4
  rsvd: 0
  integrity_algorithm: 12
    PANA EAP Request is forwarded by PANA relay = router 
    PANA
  rsvd: 0
  length: 56
  flags: 0x8000
  type: 2
  session_id: paa_session_id
  seq_no: paa_seq_no + 1
PANAAVP
  code: 5
  flags: 0
  length: 16
  rsvd: 0
  nonce: 16 bytes
PANAAVP - optional
  code: 2
  flags: 0
  length: 5
  rsvd: 0
  EAPReqUnfrag
    code: 1
    identifier: idseq
    length: 5
    type: 1
  AVPPad: 3 bytes
    PANA EAP Request is received by PANA Client 
    PANA
  rsvd: 0
  length: 56
  flags: 0x8000
  type: 2
  session_id: paa_session_id
  seq_no: paa_seq_no + 1
PANAAVP
  code: 5
  flags: 0
  length: 16
  rsvd: 0
  nonce: 16 bytes
PANAAVP - optional
  code: 2
  flags: 0
  length: 5
  rsvd: 0
  EAPReqUnfrag
    code: 1
    identifier: idseq
    length: 5
    type: 1
  AVPPad: 3 bytes
    PANA EAP Response is replied by PaC 
    PANA
  rsvd: 0
  length: 64
  flags: 0x0000
  type: 2
  session_id: paa_session_id
  seq_no: paa_seq_no + 1
PANAAVP
  code: 5
  flags: 0
  length: 16
  rsvd: 0
  nonce: 16 bytes
PANAAVP - optional
  code: 2
  flags: 0
  length: 14
  rsvd: 0
  EAPRespUnfrag
    code: 2
    identifier: idseq
    length: 14
    type: 1
    identity: "anonymous"
  AVPPad: 2 bytes
    PANA EAP Response is forwarded by PANA relay = router 
    PANA
  rsvd: 0
  length: 64
  flags: 0x0000
  type: 2
  session_id: paa_session_id
  seq_no: paa_seq_no + 1
PANAAVP
  code: 5
  flags: 0
  length: 16
  rsvd: 0
  nonce: 16 bytes
PANAAVP - optional
  code: 2
  flags: 0
  length: 14
  rsvd: 0
  EAPRespUnfrag
    code: 2
    identifier: idseq
    length: 14
    type: 1
    identity: "anonymous"
  AVPPad: 2 bytes
    PANA TLS Start is forwarded by PANA relay router 
    PANA
  rsvd: 0
  length: 32
  flags: 0x8000
  type: 2
  session_id: paa_session_id
  seq_no: paa_seq_no + 2
PANAAVP
  code: 2
  flags: 0
  length: 6
  rsvd: 0
  EAPReqUnfrag
    code: 1
    identifier: idseq + 1
    length: 6
    type: 21
    flags: 0x20
  AVPPad: 2 bytes
    PANA TLS Start is received by PANA Client 
    PANA
  rsvd: 0
  length: 32
  flags: 0x8000
  type: 2
  session_id: paa_session_id
  seq_no: paa_seq_no + 2
PANAAVP
  code: 2
  flags: 0
  length: 6
  rsvd: 0
  EAPReqUnfrag
    code: 1
    identifier: idseq + 1
    length: 6
    type: 21
    flags: 0x20
  AVPPad: 2 bytes
    PANA TLS Client Hello is replied by PaC 
    PANA
  rsvd: 0
  length: 80
  flags: 0x0000
  type: 2
  session_id: paa_session_id
  seq_no: paa_seq_no + 2
PANAAVP
  code: 2
  flags: 0
  length: 56
  rsvd: 0
  EAPRespUnfrag
    code: 2
    identifier: idseq + 1
    length: 56
    type: 21
    flags: 0x00
    TLSPlaintext
      type: 22
      version: 0x0303
      length: 45
      Handshake
        msg_type: 1
        length: 41
        ClientHello
          ProtocolVersion
            major: 0x03
            minor: 0x03
          Random
            gmt_unix_time
            random_bytes: 28 bytes
          SessionID<0..32>
            length: 0 (NULL)
          <2..2^16-2>
            length: 2
            CipherSuite=20
              bytes: {0x00, 0xC6}
          <1..2^8-2>
            length: 1
            compression_methods: {0}
          NOTE: extensions will be needed for public key cipher suite
            No extensions=20
    PANA TLS Client Hello is forwarded by PANA relay = router 
    PANA
  rsvd: 0
  length: 80
  flags: 0x0000
  type: 2
  session_id: paa_session_id
  seq_no: paa_seq_no + 2
PANAAVP
  code: 2
  flags: 0
  length: 56
  rsvd: 0
  EAPRespUnfrag
    code: 2
    identifier: idseq + 1
    length: 56
    type: 21
    flags: 0x00
    TLSPlaintext
      type: 22
      version: 0x0303
      length: 45
      Handshake
        msg_type: 1
        length: 41
        ClientHello
          ProtocolVersion
            major: 0x03
            minor: 0x03
          Random
            gmt_unix_time
            random_bytes: 28 bytes
          SessionID<0..32>
            length: 0 (NULL)
          <2..2^16-2>
            length: 2
            CipherSuite=20
              bytes: {0x00, 0xC6}
          <1..2^8-2>
            length: 1
            compression_methods: {0}
          NOTE: extensions will be needed for public key cipher suite
            No extensions=20
    PANA TLS Server Hello, Server Hello Done is forwarded = by PANA relay router 
    PANA
  rsvd: 0
  length: 88
  flags: 0x8000
  type: 2
  session_id: paa_session_id
  seq_no: paa_seq_no + 3
PANAAVP
  code: 2
  flags: 0
  length: 61
  rsvd: 0
  EAPReqUnfrag
    code: 1
    identifier: idseq + 2
    length: 61
    type: 21
    flags: 0x00
    TLSPlaintext
      type: 22
      version: 0x0303
      length: 50
      Handshake
        msg_type: 2
        length: 42
        ServerHello
          ProtocolVersion
            major: 0x03
            minor: 0x03
          Random
            gmt_unix_time
            random_bytes: 28 bytes
          SessionID<0..32>
            length: 4
            bytes: 4
            CipherSuite=20
              bytes: {0x00, 0xC6}
            compression_methods: {0}
          NOTE: extensions will be needed for public key cipher suite
            No extensions=20
      Handshake
        msg_type: 14
        length: 0
        ServerHelloDone: Empty
  AVPPad: 3 bytes
    PANA TLS Server Hello, Server Hello Done is received = by PANA Client 
    PANA
  rsvd: 0
  length: 88
  flags: 0x8000
  type: 2
  session_id: paa_session_id
  seq_no: paa_seq_no + 3
PANAAVP
  code: 2
  flags: 0
  length: 61
  rsvd: 0
  EAPReqUnfrag
    code: 1
    identifier: idseq + 2
    length: 61
    type: 21
    flags: 0x00
    TLSPlaintext
      type: 22
      version: 0x0303
      length: 50
      Handshake
        msg_type: 2
        length: 42
        ServerHello
          ProtocolVersion
            major: 0x03
            minor: 0x03
          Random
            gmt_unix_time
            random_bytes: 28 bytes
          SessionID<0..32>
            length: 4
            bytes: 4
            CipherSuite=20
              bytes: {0x00, 0xC6}
            compression_methods: {0}
          NOTE: extensions will be needed for public key cipher suite
            No extensions=20
      Handshake
        msg_type: 14
        length: 0
        ServerHelloDone: Empty
  AVPPad: 3 bytes
    PANA TLS Client Key Exchange, Change Cipher Spec, = Finished is replied by PaC 
    PANA
  rsvd: 0
  length: 88
  flags: 0x0000
  type: 2
  session_id: paa_session_id
  seq_no: paa_seq_no + 3
PANAAVP
  code: 2
  flags: 0
  length: 62
  rsvd: 0
  EAPRespUnfrag
    code: 2
    identifier: idseq + 2
    length: 62
    type: 21
    flags: 0x00
    TLSPlaintext
      type: 22
      version: 0x0303
      length: 4
      Handshake
        msg_type: 16
        length: 4
        ClientKeyExchange
          <0..2^16-1>
            length: 2
            bytes: {0x30, 0x00}
    TLSPlaintext
      type: 20
      version: 0x0303
      length: 1
      ChangeCipherSpec
        type: 1
    TLSPlaintext
      type: 22
      version: 0x0303
      length: 32
      GenericAEADCipher
        CCMNonceExplicit
          seq_num
        CCMCipherText
          Handshake
            msg_type: 20
            length: 12
            Finished
              verify_data: 12 bytes
        MAC: Using AES_CCM_8
  AVPPad: 2 bytes
    PANA TLS Client Key Exchange, Change Cipher Spec, = Finished is forwarded by PANA relay router 
    PANA
  rsvd: 0
  length: 88
  flags: 0x0000
  type: 2
  session_id: paa_session_id
  seq_no: paa_seq_no + 3
PANAAVP
  code: 2
  flags: 0
  length: 62
  rsvd: 0
  EAPRespUnfrag
    code: 2
    identifier: idseq + 2
    length: 62
    type: 21
    flags: 0x00
    TLSPlaintext
      type: 22
      version: 0x0303
      length: 4
      Handshake
        msg_type: 16
        length: 4
        ClientKeyExchange
          <0..2^16-1>
            length: 2
            bytes: {0x30, 0x00}
    TLSPlaintext
      type: 20
      version: 0x0303
      length: 1
      ChangeCipherSpec
        type: 1
    TLSPlaintext
      type: 22
      version: 0x0303
      length: 32
      GenericAEADCipher
        CCMNonceExplicit
          seq_num
        CCMCipherText
          Handshake
            msg_type: 20
            length: 12
            Finished
              verify_data: 12 bytes
        MAC: Using AES_CCM_8
  AVPPad: 2 bytes
    PANA TLS Change Cipher Spec, Finish, Network key is = forwarded by PANA relay router 
    PANA
  rsvd: 0
  length: 134
  flags: 0x8000
  type: 2
  session_id: paa_session_id
  seq_no: paa_seq_no + 4
PANAAVP
  code: 2
  flags: 0
  length: 49
  rsvd: 0
  EAPReqUnfrag
    code: 1
    identifier: idseq + 3
    length: 112
    type: 21
    flags: 0x00
    TLSPlaintext
      type: 20
      version: 0x0303
      length: 1
      ChangeCipherSpec
        type: 1
    TLSPlaintext
      type: 22
      version: 0x0303
      length: 32
      GenericAEADCipher
        CCMNonceExplicit
          seq_num
        CCMCipherText
          Handshake
            msg_type: 20
            length: 12
            Finished
              verify_data: 12 bytes
        MAC: Using AES_CCM_8
    TLSPlaintext
      type: 23
      version: 0x0303
      length: 44
      GenericAEADCipher
        CCMNonceExplicit
          seq_num
        CCMCipherText
          EAPTTLSAVP
            avp_code: 1
            avp_flags: 0xC0
            length: 28
            vendor_id: 36743
            network key: 16 bytes
        MAC: Using AES_CCM_8
    PANA TLS Change Cipher Spec, Finish, Network key is = received by PANA Client 
    PANA
  rsvd: 0
  length: 134
  flags: 0x8000
  type: 2
  session_id: paa_session_id
  seq_no: paa_seq_no + 4
PANAAVP
  code: 2
  flags: 0
  length: 49
  rsvd: 0
  EAPReqUnfrag
    code: 1
    identifier: idseq + 3
    length: 112
    type: 21
    flags: 0x00
    TLSPlaintext
      type: 20
      version: 0x0303
      length: 1
      ChangeCipherSpec
        type: 1
    TLSPlaintext
      type: 22
      version: 0x0303
      length: 32
      GenericAEADCipher
        CCMNonceExplicit
          seq_num
        CCMCipherText
          Handshake
            msg_type: 20
            length: 12
            Finished
              verify_data: 12 bytes
        MAC: Using AES_CCM_8
    TLSPlaintext
      type: 23
      version: 0x0303
      length: 44
      GenericAEADCipher
        CCMNonceExplicit
          seq_num
        CCMCipherText
          EAPTTLSAVP
            avp_code: 1
            avp_flags: 0xC0
            length: 28
            vendor_id: 36743
            network key: 16 bytes
        MAC: Using AES_CCM_8
    PANA EAP Response is replied by PaC 
    PANA
  rsvd: 0
  length: 30
  flags: 0x0000
  type: 2
  session_id: paa_session_id
  seq_no: paa_seq_no + 4
PANAAVP
  code: 2
  flags: 0
  length: 6
  rsvd: 0
  nonce: 16 bytes
  EAPRespUnfrag
    code: 2
    identifier: idseq + 3
    length: 6
    type: 21
    flag: 0x20
  AVPPad: 2 bytes
    PANA EAP Response is forwarded by PANA relay = router 
    PANA
  rsvd: 0
  length: 30
  flags: 0x0000
  type: 2
  session_id: paa_session_id
  seq_no: paa_seq_no + 4
PANAAVP
  code: 2
  flags: 0
  length: 6
  rsvd: 0
  nonce: 16 bytes
  EAPRespUnfrag
    code: 2
    identifier: idseq + 3
    length: 6
    type: 21
    flag: 0x20
  AVPPad: 2 bytes
    PANA EAP Success is forwarded by PANA relay = router 
    PANA
  rsvd: 0
  length: 88
  flags: 0xA000
  type: 2
  session_id: paa_session_id
  seq_no: paa_seq_no + 5
PANAAVP
  code: 7
  flags: 0
  length: 4
  rsvd: 0
  result_code: 0
PANAAVP
  code: 2
  flags: 0
  length: 4
  rsvd: 0
  EAPSUCCESS
    code: 3
    identifier: idseq + 4
    length: 4
PANAAVP
  code: 4
  flags: 0
  length: 4
  rsvd: 0
  key_id: 0
PANAAVP
  code: 8
  flags: 0
  length: 4
  rsvd: 0
  sess_life: 0xFFFFFFFF
PANAAVP
  code: 1
  flags: 0
  length: 16
  rsvd: 0
  auth: 16 bytes
    PANA EAP Success is received by PANA Client 
    PANA
  rsvd: 0
  length: 88
  flags: 0xA000
  type: 2
  session_id: paa_session_id
  seq_no: paa_seq_no + 5
PANAAVP
  code: 7
  flags: 0
  length: 4
  rsvd: 0
  result_code: 0
PANAAVP
  code: 2
  flags: 0
  length: 4
  rsvd: 0
  EAPSUCCESS
    code: 3
    identifier: idseq + 4
    length: 4
PANAAVP
  code: 4
  flags: 0
  length: 4
  rsvd: 0
  key_id: 0
PANAAVP
  code: 8
  flags: 0
  length: 4
  rsvd: 0
  sess_life: 0xFFFFFFFF
PANAAVP
  code: 1
  flags: 0
  length: 16
  rsvd: 0
  auth: 16 bytes
    PANA Complete is replied by PaC 
    PANA
  rsvd: 0
  length: 54
  flags: 0x2000
  type: 2
  session_id: paa_session_id
  seq_no: paa_seq_no + 5
PANAAVP
  code: 4
  flags: 0
  length: 4
  rsvd: 0
  key_id: 0
PANAAVP
  code: 1
  flags: 0
  length: 16
  rsvd: 0
  auth: 16 bytes
    PANA Complete is forwarded by PANA relay router 
    PANA
  rsvd: 0
  length: 54
  flags: 0x2000
  type: 2
  session_id: paa_session_id
  seq_no: paa_seq_no + 5
PANAAVP
  code: 4
  flags: 0
  length: 4
  rsvd: 0
  key_id: 0
PANAAVP
  code: 1
  flags: 0
  length: 16
  rsvd: 0
  auth: 16 bytes
    Neighbor Solicitation (NS) is initiated to discovery = neighbor and validate (short) address 
    802.15.4
  source: Short address (tentative)
  dest: Short address (Derived from SLLAO in RA)
IP
  Hop limit: 255
  source: GP16 (tentative)
  dest: LL16 of parent router
  Target: LL16 of parent router
SLLAO: Short address
ARO: EUI-64, no IP address, status=3D0
    Duplicate Address Request (DAR) is initiated from = parent router 
    type	156
802.15.4
  source: Short address of parent router
  dest: Short address of next hop
IP
  Hop limit: [variable]
  source:	GP16 of parent router
  dest: GP16 of LBR
  Status: 0
  Registration lifetime: [variable]
  EUI-64: EUI-64 of registering node
  Registered Address: IP source of NS that contained ARO option
    Duplicate Address Confirmation (DAC) is forwarded to = parent router 
    type	157
802.15.4
  source: Short address of LBR
  dest: Short address of next hop
IP
  Hop limit: [variable]
  source: GP16 of LBR
  dest: GP16 of parent router
  Status: Draft-ietf-6lowpan-nd-14 Table 1
  Registration lifetime: [variable]
  EUI-64: EUI-64 of registering node
  Registered Address: Copied from the DAR
    Neighbor Advertisement (NA) is replied by parent = router 
    802.15.4
  source: Short address
  dest: Success? Short address : IEEE address
IP
  Hop limit: 255
  source: LL16 of parent router
  dest: Success ? GP16 : LL64
  Target: LL16 of parent router
ARO: EUI-64, no IP address, status
    ICMP request is initiated to verify communication 
    IP
  source: GP16=20
  dest: GP16
ICMPV6
  Type: 0x80
    ICMP request is forwarded by parent router 
    IP
  source: GP16=20
  dest: GP16
ICMPV6
  Type: 0x80
    ICMP reply is forwarded to parent router 
    IP
  source: GP16=20
  dest: GP16
ICMPV6
  Type: 0x81
    ICMP reply is replied by parent router 
    802.15.4
  source: Short address
  dest: Success? Short address : IEEE address
IP
  Hop limit: 255
  source: LL16 of parent router
  dest: Success ? GP16 : LL64
  Target: LL16 of parent router
ARO: EUI-64, no IP address, status

    Verification

  • All packets shall follow the formats = described.
  • Communication via ping shall succeed.

    •

    1.9 Host Join - 3 Hop, with = Authentication

    Initial Condition

    channel: 0x14 for all devices
    panId: 0x1AAA
    linkLocal: fe80::/64
    globalPrefix: fd01::/64
    CCM Parameters: MIC Length M =3D 8, Length length L =3D 3
    Test Pre-shared key (PSK) octet string: {0xcf, 0xce, 0xcd, 0xcc, 0xcb,=20 0xca, 0xc9, 0xc8, 0xc7, 0xc6, 0xc5, 0xc4, 0xc3, 0xc2, 0xc1, 0xc0}
    Test Network key octet string: {0xbf, 0xbe, 0xbd, 0xbc, 0xbb, 0xba, = 0xb9, 0xb8, 0xb7, 0xb6, 0xb5, 0xb4, 0xb3, 0xb2, 0xb1, 0xb0}
    Key length N =3D 16

    Topology

    Host               ParentRouter       RelayRouter   =
    BorderRouter

    |                |
|   --------->   | Beacon Request (broadcast)
|   <-----       | Beacon Response
|                |

    |                |
|   --------->   | RS (multicast)
|   <-----       | RA
|                |

    |                |
|   ------>      | PCI
|                |   ------>       | RLY(PCI)
|                |                 |   ------>       | RLY(PCI)
|                |                 |   <------       | RLY(PAR)
|                |   <------       | RLY(PAR)
|   <------      | PAR
|   ------>      | PAN
|                |   ------>       | RLY(PAN)
|                |                 |   ------>       | RLY(PAN)
|                |                 |   <------       | RLY(PAR EAP =
Request)
|                |   <------       | RLY(PAR EAP Request)
|   <------      | PAR EAP Request
|   ------>      | PAN EAP Response
|                |   ------>       | RLY(PAN EAP Response)
|                |                 |   ------>       | RLY(PAN EAP =
Response)
|                |                 |   <------       | RLY(PAR TLS =
Start)
|                |   <------       | RLY(PAR TLS Start)
|   <------      | PAR TLS Start
|   ------>      | PAN TLS Client Hello
|                |   ------>       | RLY(PAN TLS Client Hello)
|                |                 |   ------>       | RLY(PAN TLS =
Client Hello)
|                |                 |   <------       | RLY(PAR TLS =
Server Hello, Server Hello Done)
|                |   <------       | RLY(PAR TLS Server Hello, Server =
Hello Done)
|   <------      | PAR TLS Server Hello, Server Hello Done
|   ------>      | PAN TLS Client Key Exchange, Change Cipher Spec, =
Finished
|                |   ------>       | RLY(PAN TLS Client Key Exchange, =
Change Cipher Spec, Finished)
|                |                 |   ------>       | RLY(PAN TLS =
Client Key Exchange, Change Cipher Spec, Finished)
|                |                 |   <------       | RLY(PAR TLS =
Change Cipher Spec, Finish, Network key)
|                |   <------       | RLY(PAR TLS Change Cipher Spec, =
Finish, Network key)
|   <------      | PAR TLS Change Cipher Spec, Finish, Network key
|   ------>      | PAN EAP Response
|                |   ------>       | RLY(PAN EAP Response)
|                |                 |   ------>       | RLY(PAN EAP =
Response)
|                |                 |   <------       | RLY(PAR EAP =
Success)
|                |   <------       | RLY(PAR EAP Success)
|   <------      | PAR EAP Success
|   ------>      | PAN Complete
|                |   ------>       | RLY(PAN Complete)
|                |                 |   ------>       | RLY(PAN =
Complete)
|                |

    |                |
|   ------>      | NS
|                |   ------>       | DAR
|                |                 |   ------>       | DAR
|                |                 |   <------       | DAC
|                |   <------       | DAC
|   <------      | NA
|                |

    |                |
|   ------>      | ICMP Request
|                |   ------>       | ICMP Request
|                |                 |   ------>       | ICMP Request
|                |                 |   <------       | ICMP Reply
|                |   <------       | ICMP Reply
|   <------      | ICMP Reply
|                |

    Sub Test Cases

    A: Host =3D DUT
    B: Parent Router =3D DUT
    C: Relay Router =3D DUT
    D: Border Router =3D DUT

    Test Procedure

    Beacon request is sent to initiate active scan 
    802.15.4
  FrameControl: 0x0803
    FrameType: 0x03
    SecurityEnable: false
    FramePending: false
    AckRequired: false
    IntraPan: false
    Dest Addr Mode: 0x02
    Src Addr Mode: 0x00
  Dest PanId: 0xffff
  Short Dest Addr: 0xffff
802.15.4 command: 0x07
    Beacon response is replied from all routers within = radio range 
    802.15.4
  FrameControl: 0x8000
    FrameType: 0x00
    SecurityEnable: false
    FramePending: false
    AckRequired: false
    IntraPan: false
    Dest Addr Mode: 0x00
    Src Addr Mode: 0x02
  Source PanId: [variable]
  Short Source Addr: [variable]
Beacon Payload
  Protocal ID: 0x02
  Control Field
    Bit 0: Allow Join
    Bit 1-7: Reserved
  NetworkID
  AppInfo
    Router Solicitation (RS) is sent as muticast to = discovery routers within range 
    802.15.4
  source: IEEE address
  dest: Broadcast
IP
  Hop limit: 255
  source: LL64
  dest: All-routers multicast
SLLAO: IEEE address
    Router Advertisement (RA) is replied from all routers = within radio range, containing prefix and context information 
    802.15.4
  source: Short address
  dest: IEEE address
IP
  Hop limit: 255
  source: LL16
  dest: LL64
SLLAO: Short address
PIO: PAN-wide prefix (GP)
ABRO: 6LBR (GP16)
6CO: Context 0 (i.e. GP)
    PANA-Client-Initiation (PCI) is initiated by PANA = Client (PaC) to establish the authentication 
    PANA
  rsvd: 0
  length: 16
  flags: 0x0000
  type: 1
  session_id: 0
  seq_no: 0
    PANA-Client-Initiation (PCI) is forwarded by PANA = relay router 
    PANA
  rsvd: 0
  length: 16
  flags: 0x0000
  type: 1
  session_id: 0
  seq_no: 0
    PANA-Client-Initiation (PCI) is forwarded to PANA = Authentication Agent (PAA) 
    PANA
  rsvd: 0
  length: 16
  flags: 0x0000
  type: 1
  session_id: 0
  seq_no: 0
    PANA-Auth-Request (PAR) is responded by PANA = Authentication Agent (PAA) 
    PANA
  rsvd: 0
  length: 40
  flags: 0xC000
  type: 2
  session_id: paa_session_id
  seq_no: paa_seq_no
If PRF_HMAC_SHA2_256 is the only PRF, the following AVP may be optional
PANAAVP
  code: 6
  flags: 0
  length: 4
  rsvd: 0
  prf_algorithm: 5
If AUTH_HMAC_SHA2_256_128 is the only integrity algorithm, the following =
AVP may be optional
PANAAVP
  code: 3
  flags: 0
  length: 4
  rsvd: 0
  integrity_algorithm: 12
    PANA-Auth-Request (PAR) is forwarded by PANA relay = router 
    PANA
  rsvd: 0
  length: 40
  flags: 0xC000
  type: 2
  session_id: paa_session_id
  seq_no: paa_seq_no
If PRF_HMAC_SHA2_256 is the only PRF, the following AVP may be optional
PANAAVP
  code: 6
  flags: 0
  length: 4
  rsvd: 0
  prf_algorithm: 5
If AUTH_HMAC_SHA2_256_128 is the only integrity algorithm, the following =
AVP may be optional
PANAAVP
  code: 3
  flags: 0
  length: 4
  rsvd: 0
  integrity_algorithm: 12
    PANA-Auth-Request (PAR) is received by PANA = Client 
    PANA
  rsvd: 0
  length: 40
  flags: 0xC000
  type: 2
  session_id: paa_session_id
  seq_no: paa_seq_no
If PRF_HMAC_SHA2_256 is the only PRF, the following AVP may be optional
PANAAVP
  code: 6
  flags: 0
  length: 4
  rsvd: 0
  prf_algorithm: 5
If AUTH_HMAC_SHA2_256_128 is the only integrity algorithm, the following =
AVP may be optional
PANAAVP
  code: 3
  flags: 0
  length: 4
  rsvd: 0
  integrity_algorithm: 12
    PANA-Auth-Answer (PAN) is replied by PaC 
    PANA
  rsvd: 0
  length: 40
  flags: 0x4000
  type: 2
  session_id: paa_session_id
  seq_no: paa_seq_no
If PRF_HMAC_SHA2_256 is the only PRF, the following AVP may be optional
PANAAVP
  code: 6
  flags: 0
  length: 4
  rsvd: 0
  prf_algorithm: 5
If AUTH_HMAC_SHA2_256_128 is the only integrity algorithm, the following =
AVP may be optional
PANAAVP
  code: 3
  flags: 0
  length: 4
  rsvd: 0
  integrity_algorithm: 12
    PANA-Auth-Answer (PAN) is forwarded by PANA relay = router 
    PANA
  rsvd: 0
  length: 40
  flags: 0x4000
  type: 2
  session_id: paa_session_id
  seq_no: paa_seq_no
If PRF_HMAC_SHA2_256 is the only PRF, the following AVP may be optional
PANAAVP
  code: 6
  flags: 0
  length: 4
  rsvd: 0
  prf_algorithm: 5
If AUTH_HMAC_SHA2_256_128 is the only integrity algorithm, the following =
AVP may be optional
PANAAVP
  code: 3
  flags: 0
  length: 4
  rsvd: 0
  integrity_algorithm: 12
    PANA-Auth-Answer (PAN) is forwarded to PAA 
    PANA
  rsvd: 0
  length: 40
  flags: 0x4000
  type: 2
  session_id: paa_session_id
  seq_no: paa_seq_no
If PRF_HMAC_SHA2_256 is the only PRF, the following AVP may be optional
PANAAVP
  code: 6
  flags: 0
  length: 4
  rsvd: 0
  prf_algorithm: 5
If AUTH_HMAC_SHA2_256_128 is the only integrity algorithm, the following =
AVP may be optional
PANAAVP
  code: 3
  flags: 0
  length: 4
  rsvd: 0
  integrity_algorithm: 12
    PANA EAP Request is responded by PAA 
    PANA
  rsvd: 0
  length: 56
  flags: 0x8000
  type: 2
  session_id: paa_session_id
  seq_no: paa_seq_no + 1
PANAAVP
  code: 5
  flags: 0
  length: 16
  rsvd: 0
  nonce: 16 bytes
PANAAVP - optional
  code: 2
  flags: 0
  length: 5
  rsvd: 0
  EAPReqUnfrag
    code: 1
    identifier: idseq
    length: 5
    type: 1
  AVPPad: 3 bytes
    PANA EAP Request is forwarded by PANA relay = router 
    PANA
  rsvd: 0
  length: 56
  flags: 0x8000
  type: 2
  session_id: paa_session_id
  seq_no: paa_seq_no + 1
PANAAVP
  code: 5
  flags: 0
  length: 16
  rsvd: 0
  nonce: 16 bytes
PANAAVP - optional
  code: 2
  flags: 0
  length: 5
  rsvd: 0
  EAPReqUnfrag
    code: 1
    identifier: idseq
    length: 5
    type: 1
  AVPPad: 3 bytes
    PANA EAP Request is received by PANA Client 
    PANA
  rsvd: 0
  length: 56
  flags: 0x8000
  type: 2
  session_id: paa_session_id
  seq_no: paa_seq_no + 1
PANAAVP
  code: 5
  flags: 0
  length: 16
  rsvd: 0
  nonce: 16 bytes
PANAAVP - optional
  code: 2
  flags: 0
  length: 5
  rsvd: 0
  EAPReqUnfrag
    code: 1
    identifier: idseq
    length: 5
    type: 1
  AVPPad: 3 bytes
    PANA EAP Response is replied by PaC 
    PANA
  rsvd: 0
  length: 64
  flags: 0x0000
  type: 2
  session_id: paa_session_id
  seq_no: paa_seq_no + 1
PANAAVP
  code: 5
  flags: 0
  length: 16
  rsvd: 0
  nonce: 16 bytes
PANAAVP - optional
  code: 2
  flags: 0
  length: 14
  rsvd: 0
  EAPRespUnfrag
    code: 2
    identifier: idseq
    length: 14
    type: 1
    identity: "anonymous"
  AVPPad: 2 bytes
    PANA EAP Response is forwarded by PANA relay = router 
    PANA
  rsvd: 0
  length: 64
  flags: 0x0000
  type: 2
  session_id: paa_session_id
  seq_no: paa_seq_no + 1
PANAAVP
  code: 5
  flags: 0
  length: 16
  rsvd: 0
  nonce: 16 bytes
PANAAVP - optional
  code: 2
  flags: 0
  length: 14
  rsvd: 0
  EAPRespUnfrag
    code: 2
    identifier: idseq
    length: 14
    type: 1
    identity: "anonymous"
  AVPPad: 2 bytes
    PANA EAP Response is forwarded to PAA 
    PANA
  rsvd: 0
  length: 64
  flags: 0x0000
  type: 2
  session_id: paa_session_id
  seq_no: paa_seq_no + 1
PANAAVP
  code: 5
  flags: 0
  length: 16
  rsvd: 0
  nonce: 16 bytes
PANAAVP - optional
  code: 2
  flags: 0
  length: 14
  rsvd: 0
  EAPRespUnfrag
    code: 2
    identifier: idseq
    length: 14
    type: 1
    identity: "anonymous"
  AVPPad: 2 bytes
    PANA TLS Start is responded by PAA 
    PANA
  rsvd: 0
  length: 32
  flags: 0x8000
  type: 2
  session_id: paa_session_id
  seq_no: paa_seq_no + 2
PANAAVP
  code: 2
  flags: 0
  length: 6
  rsvd: 0
  EAPReqUnfrag
    code: 1
    identifier: idseq + 1
    length: 6
    type: 21
    flags: 0x20
  AVPPad: 2 bytes
    PANA TLS Start is forwarded by PANA relay router 
    PANA
  rsvd: 0
  length: 32
  flags: 0x8000
  type: 2
  session_id: paa_session_id
  seq_no: paa_seq_no + 2
PANAAVP
  code: 2
  flags: 0
  length: 6
  rsvd: 0
  EAPReqUnfrag
    code: 1
    identifier: idseq + 1
    length: 6
    type: 21
    flags: 0x20
  AVPPad: 2 bytes
    PANA TLS Start is received by PANA Client 
    PANA
  rsvd: 0
  length: 32
  flags: 0x8000
  type: 2
  session_id: paa_session_id
  seq_no: paa_seq_no + 2
PANAAVP
  code: 2
  flags: 0
  length: 6
  rsvd: 0
  EAPReqUnfrag
    code: 1
    identifier: idseq + 1
    length: 6
    type: 21
    flags: 0x20
  AVPPad: 2 bytes
    PANA TLS Client Hello is replied by PaC 
    PANA
  rsvd: 0
  length: 80
  flags: 0x0000
  type: 2
  session_id: paa_session_id
  seq_no: paa_seq_no + 2
PANAAVP
  code: 2
  flags: 0
  length: 56
  rsvd: 0
  EAPRespUnfrag
    code: 2
    identifier: idseq + 1
    length: 56
    type: 21
    flags: 0x00
    TLSPlaintext
      type: 22
      version: 0x0303
      length: 45
      Handshake
        msg_type: 1
        length: 41
        ClientHello
          ProtocolVersion
            major: 0x03
            minor: 0x03
          Random
            gmt_unix_time
            random_bytes: 28 bytes
          SessionID<0..32>
            length: 0 (NULL)
          <2..2^16-2>
            length: 2
            CipherSuite=20
              bytes: {0x00, 0xC6}
          <1..2^8-2>
            length: 1
            compression_methods: {0}
          NOTE: extensions will be needed for public key cipher suite
            No extensions=20
    PANA TLS Client Hello is forwarded by PANA relay = router 
    PANA
  rsvd: 0
  length: 80
  flags: 0x0000
  type: 2
  session_id: paa_session_id
  seq_no: paa_seq_no + 2
PANAAVP
  code: 2
  flags: 0
  length: 56
  rsvd: 0
  EAPRespUnfrag
    code: 2
    identifier: idseq + 1
    length: 56
    type: 21
    flags: 0x00
    TLSPlaintext
      type: 22
      version: 0x0303
      length: 45
      Handshake
        msg_type: 1
        length: 41
        ClientHello
          ProtocolVersion
            major: 0x03
            minor: 0x03
          Random
            gmt_unix_time
            random_bytes: 28 bytes
          SessionID<0..32>
            length: 0 (NULL)
          <2..2^16-2>
            length: 2
            CipherSuite=20
              bytes: {0x00, 0xC6}
          <1..2^8-2>
            length: 1
            compression_methods: {0}
          NOTE: extensions will be needed for public key cipher suite
            No extensions=20
    PANA TLS Client Hello is forwarded to PAA 
    PANA
  rsvd: 0
  length: 80
  flags: 0x0000
  type: 2
  session_id: paa_session_id
  seq_no: paa_seq_no + 2
PANAAVP
  code: 2
  flags: 0
  length: 56
  rsvd: 0
  EAPRespUnfrag
    code: 2
    identifier: idseq + 1
    length: 56
    type: 21
    flags: 0x00
    TLSPlaintext
      type: 22
      version: 0x0303
      length: 45
      Handshake
        msg_type: 1
        length: 41
        ClientHello
          ProtocolVersion
            major: 0x03
            minor: 0x03
          Random
            gmt_unix_time
            random_bytes: 28 bytes
          SessionID<0..32>
            length: 0 (NULL)
          <2..2^16-2>
            length: 2
            CipherSuite=20
              bytes: {0x00, 0xC6}
          <1..2^8-2>
            length: 1
            compression_methods: {0}
          NOTE: extensions will be needed for public key cipher suite
            No extensions=20
    PANA TLS Server Hello, Server Hello Done is responded = by PAA 
    PANA
  rsvd: 0
  length: 88
  flags: 0x8000
  type: 2
  session_id: paa_session_id
  seq_no: paa_seq_no + 3
PANAAVP
  code: 2
  flags: 0
  length: 61
  rsvd: 0
  EAPReqUnfrag
    code: 1
    identifier: idseq + 2
    length: 61
    type: 21
    flags: 0x00
    TLSPlaintext
      type: 22
      version: 0x0303
      length: 50
      Handshake
        msg_type: 2
        length: 42
        ServerHello
          ProtocolVersion
            major: 0x03
            minor: 0x03
          Random
            gmt_unix_time
            random_bytes: 28 bytes
          SessionID<0..32>
            length: 4
            bytes: 4
            CipherSuite=20
              bytes: {0x00, 0xC6}
            compression_methods: {0}
          NOTE: extensions will be needed for public key cipher suite
            No extensions=20
      Handshake
        msg_type: 14
        length: 0
        ServerHelloDone: Empty
  AVPPad: 3 bytes
    PANA TLS Server Hello, Server Hello Done is forwarded = by PANA relay router 
    PANA
  rsvd: 0
  length: 88
  flags: 0x8000
  type: 2
  session_id: paa_session_id
  seq_no: paa_seq_no + 3
PANAAVP
  code: 2
  flags: 0
  length: 61
  rsvd: 0
  EAPReqUnfrag
    code: 1
    identifier: idseq + 2
    length: 61
    type: 21
    flags: 0x00
    TLSPlaintext
      type: 22
      version: 0x0303
      length: 50
      Handshake
        msg_type: 2
        length: 42
        ServerHello
          ProtocolVersion
            major: 0x03
            minor: 0x03
          Random
            gmt_unix_time
            random_bytes: 28 bytes
          SessionID<0..32>
            length: 4
            bytes: 4
            CipherSuite=20
              bytes: {0x00, 0xC6}
            compression_methods: {0}
          NOTE: extensions will be needed for public key cipher suite
            No extensions=20
      Handshake
        msg_type: 14
        length: 0
        ServerHelloDone: Empty
  AVPPad: 3 bytes
    PANA TLS Server Hello, Server Hello Done is received = by PANA Client 
    PANA
  rsvd: 0
  length: 88
  flags: 0x8000
  type: 2
  session_id: paa_session_id
  seq_no: paa_seq_no + 3
PANAAVP
  code: 2
  flags: 0
  length: 61
  rsvd: 0
  EAPReqUnfrag
    code: 1
    identifier: idseq + 2
    length: 61
    type: 21
    flags: 0x00
    TLSPlaintext
      type: 22
      version: 0x0303
      length: 50
      Handshake
        msg_type: 2
        length: 42
        ServerHello
          ProtocolVersion
            major: 0x03
            minor: 0x03
          Random
            gmt_unix_time
            random_bytes: 28 bytes
          SessionID<0..32>
            length: 4
            bytes: 4
            CipherSuite=20
              bytes: {0x00, 0xC6}
            compression_methods: {0}
          NOTE: extensions will be needed for public key cipher suite
            No extensions=20
      Handshake
        msg_type: 14
        length: 0
        ServerHelloDone: Empty
  AVPPad: 3 bytes
    PANA TLS Client Key Exchange, Change Cipher Spec, = Finished is replied by PaC 
    PANA
  rsvd: 0
  length: 88
  flags: 0x0000
  type: 2
  session_id: paa_session_id
  seq_no: paa_seq_no + 3
PANAAVP
  code: 2
  flags: 0
  length: 62
  rsvd: 0
  EAPRespUnfrag
    code: 2
    identifier: idseq + 2
    length: 62
    type: 21
    flags: 0x00
    TLSPlaintext
      type: 22
      version: 0x0303
      length: 4
      Handshake
        msg_type: 16
        length: 4
        ClientKeyExchange
          <0..2^16-1>
            length: 2
            bytes: {0x30, 0x00}
    TLSPlaintext
      type: 20
      version: 0x0303
      length: 1
      ChangeCipherSpec
        type: 1
    TLSPlaintext
      type: 22
      version: 0x0303
      length: 32
      GenericAEADCipher
        CCMNonceExplicit
          seq_num
        CCMCipherText
          Handshake
            msg_type: 20
            length: 12
            Finished
              verify_data: 12 bytes
        MAC: Using AES_CCM_8
  AVPPad: 2 bytes
    PANA TLS Client Key Exchange, Change Cipher Spec, = Finished is forwarded by PANA relay router 
    PANA
  rsvd: 0
  length: 88
  flags: 0x0000
  type: 2
  session_id: paa_session_id
  seq_no: paa_seq_no + 3
PANAAVP
  code: 2
  flags: 0
  length: 62
  rsvd: 0
  EAPRespUnfrag
    code: 2
    identifier: idseq + 2
    length: 62
    type: 21
    flags: 0x00
    TLSPlaintext
      type: 22
      version: 0x0303
      length: 4
      Handshake
        msg_type: 16
        length: 4
        ClientKeyExchange
          <0..2^16-1>
            length: 2
            bytes: {0x30, 0x00}
    TLSPlaintext
      type: 20
      version: 0x0303
      length: 1
      ChangeCipherSpec
        type: 1
    TLSPlaintext
      type: 22
      version: 0x0303
      length: 32
      GenericAEADCipher
        CCMNonceExplicit
          seq_num
        CCMCipherText
          Handshake
            msg_type: 20
            length: 12
            Finished
              verify_data: 12 bytes
        MAC: Using AES_CCM_8
  AVPPad: 2 bytes
    PANA TLS Client Key Exchange, Change Cipher Spec, = Finished is forwarded to PAA 
    PANA
  rsvd: 0
  length: 88
  flags: 0x0000
  type: 2
  session_id: paa_session_id
  seq_no: paa_seq_no + 3
PANAAVP
  code: 2
  flags: 0
  length: 62
  rsvd: 0
  EAPRespUnfrag
    code: 2
    identifier: idseq + 2
    length: 62
    type: 21
    flags: 0x00
    TLSPlaintext
      type: 22
      version: 0x0303
      length: 4
      Handshake
        msg_type: 16
        length: 4
        ClientKeyExchange
          <0..2^16-1>
            length: 2
            bytes: {0x30, 0x00}
    TLSPlaintext
      type: 20
      version: 0x0303
      length: 1
      ChangeCipherSpec
        type: 1
    TLSPlaintext
      type: 22
      version: 0x0303
      length: 32
      GenericAEADCipher
        CCMNonceExplicit
          seq_num
        CCMCipherText
          Handshake
            msg_type: 20
            length: 12
            Finished
              verify_data: 12 bytes
        MAC: Using AES_CCM_8
  AVPPad: 2 bytes
    PANA TLS Change Cipher Spec, Finish, Network key is = responded by PAA 
    PANA
  rsvd: 0
  length: 134
  flags: 0x8000
  type: 2
  session_id: paa_session_id
  seq_no: paa_seq_no + 4
PANAAVP
  code: 2
  flags: 0
  length: 49
  rsvd: 0
  EAPReqUnfrag
    code: 1
    identifier: idseq + 3
    length: 112
    type: 21
    flags: 0x00
    TLSPlaintext
      type: 20
      version: 0x0303
      length: 1
      ChangeCipherSpec
        type: 1
    TLSPlaintext
      type: 22
      version: 0x0303
      length: 32
      GenericAEADCipher
        CCMNonceExplicit
          seq_num
        CCMCipherText
          Handshake
            msg_type: 20
            length: 12
            Finished
              verify_data: 12 bytes
        MAC: Using AES_CCM_8
    TLSPlaintext
      type: 23
      version: 0x0303
      length: 44
      GenericAEADCipher
        CCMNonceExplicit
          seq_num
        CCMCipherText
          EAPTTLSAVP
            avp_code: 1
            avp_flags: 0xC0
            length: 28
            vendor_id: 36743
            network key: 16 bytes
        MAC: Using AES_CCM_8
    PANA TLS Change Cipher Spec, Finish, Network key is = forwarded by PANA relay router 
    PANA
  rsvd: 0
  length: 134
  flags: 0x8000
  type: 2
  session_id: paa_session_id
  seq_no: paa_seq_no + 4
PANAAVP
  code: 2
  flags: 0
  length: 49
  rsvd: 0
  EAPReqUnfrag
    code: 1
    identifier: idseq + 3
    length: 112
    type: 21
    flags: 0x00
    TLSPlaintext
      type: 20
      version: 0x0303
      length: 1
      ChangeCipherSpec
        type: 1
    TLSPlaintext
      type: 22
      version: 0x0303
      length: 32
      GenericAEADCipher
        CCMNonceExplicit
          seq_num
        CCMCipherText
          Handshake
            msg_type: 20
            length: 12
            Finished
              verify_data: 12 bytes
        MAC: Using AES_CCM_8
    TLSPlaintext
      type: 23
      version: 0x0303
      length: 44
      GenericAEADCipher
        CCMNonceExplicit
          seq_num
        CCMCipherText
          EAPTTLSAVP
            avp_code: 1
            avp_flags: 0xC0
            length: 28
            vendor_id: 36743
            network key: 16 bytes
        MAC: Using AES_CCM_8
    PANA TLS Change Cipher Spec, Finish, Network key is = received by PANA Client 
    PANA
  rsvd: 0
  length: 134
  flags: 0x8000
  type: 2
  session_id: paa_session_id
  seq_no: paa_seq_no + 4
PANAAVP
  code: 2
  flags: 0
  length: 49
  rsvd: 0
  EAPReqUnfrag
    code: 1
    identifier: idseq + 3
    length: 112
    type: 21
    flags: 0x00
    TLSPlaintext
      type: 20
      version: 0x0303
      length: 1
      ChangeCipherSpec
        type: 1
    TLSPlaintext
      type: 22
      version: 0x0303
      length: 32
      GenericAEADCipher
        CCMNonceExplicit
          seq_num
        CCMCipherText
          Handshake
            msg_type: 20
            length: 12
            Finished
              verify_data: 12 bytes
        MAC: Using AES_CCM_8
    TLSPlaintext
      type: 23
      version: 0x0303
      length: 44
      GenericAEADCipher
        CCMNonceExplicit
          seq_num
        CCMCipherText
          EAPTTLSAVP
            avp_code: 1
            avp_flags: 0xC0
            length: 28
            vendor_id: 36743
            network key: 16 bytes
        MAC: Using AES_CCM_8
    PANA EAP Response is replied by PaC 
    PANA
  rsvd: 0
  length: 30
  flags: 0x0000
  type: 2
  session_id: paa_session_id
  seq_no: paa_seq_no + 4
PANAAVP
  code: 2
  flags: 0
  length: 6
  rsvd: 0
  nonce: 16 bytes
  EAPRespUnfrag
    code: 2
    identifier: idseq + 3
    length: 6
    type: 21
    flag: 0x20
  AVPPad: 2 bytes
    PANA EAP Response is forwarded by PANA relay = router 
    PANA
  rsvd: 0
  length: 30
  flags: 0x0000
  type: 2
  session_id: paa_session_id
  seq_no: paa_seq_no + 4
PANAAVP
  code: 2
  flags: 0
  length: 6
  rsvd: 0
  nonce: 16 bytes
  EAPRespUnfrag
    code: 2
    identifier: idseq + 3
    length: 6
    type: 21
    flag: 0x20
  AVPPad: 2 bytes
    PANA EAP Response is forwarded to PAA 
    PANA
  rsvd: 0
  length: 30
  flags: 0x0000
  type: 2
  session_id: paa_session_id
  seq_no: paa_seq_no + 4
PANAAVP
  code: 2
  flags: 0
  length: 6
  rsvd: 0
  nonce: 16 bytes
  EAPRespUnfrag
    code: 2
    identifier: idseq + 3
    length: 6
    type: 21
    flag: 0x20
  AVPPad: 2 bytes
    PANA EAP Success is responded by PAA 
    PANA
  rsvd: 0
  length: 88
  flags: 0xA000
  type: 2
  session_id: paa_session_id
  seq_no: paa_seq_no + 5
PANAAVP
  code: 7
  flags: 0
  length: 4
  rsvd: 0
  result_code: 0
PANAAVP
  code: 2
  flags: 0
  length: 4
  rsvd: 0
  EAPSUCCESS
    code: 3
    identifier: idseq + 4
    length: 4
PANAAVP
  code: 4
  flags: 0
  length: 4
  rsvd: 0
  key_id: 0
PANAAVP
  code: 8
  flags: 0
  length: 4
  rsvd: 0
  sess_life: 0xFFFFFFFF
PANAAVP
  code: 1
  flags: 0
  length: 16
  rsvd: 0
  auth: 16 bytes
    PANA EAP Success is forwarded by PANA relay = router 
    PANA
  rsvd: 0
  length: 88
  flags: 0xA000
  type: 2
  session_id: paa_session_id
  seq_no: paa_seq_no + 5
PANAAVP
  code: 7
  flags: 0
  length: 4
  rsvd: 0
  result_code: 0
PANAAVP
  code: 2
  flags: 0
  length: 4
  rsvd: 0
  EAPSUCCESS
    code: 3
    identifier: idseq + 4
    length: 4
PANAAVP
  code: 4
  flags: 0
  length: 4
  rsvd: 0
  key_id: 0
PANAAVP
  code: 8
  flags: 0
  length: 4
  rsvd: 0
  sess_life: 0xFFFFFFFF
PANAAVP
  code: 1
  flags: 0
  length: 16
  rsvd: 0
  auth: 16 bytes
    PANA EAP Success is received by PANA Client 
    PANA
  rsvd: 0
  length: 88
  flags: 0xA000
  type: 2
  session_id: paa_session_id
  seq_no: paa_seq_no + 5
PANAAVP
  code: 7
  flags: 0
  length: 4
  rsvd: 0
  result_code: 0
PANAAVP
  code: 2
  flags: 0
  length: 4
  rsvd: 0
  EAPSUCCESS
    code: 3
    identifier: idseq + 4
    length: 4
PANAAVP
  code: 4
  flags: 0
  length: 4
  rsvd: 0
  key_id: 0
PANAAVP
  code: 8
  flags: 0
  length: 4
  rsvd: 0
  sess_life: 0xFFFFFFFF
PANAAVP
  code: 1
  flags: 0
  length: 16
  rsvd: 0
  auth: 16 bytes
    PANA Complete is replied by PaC 
    PANA
  rsvd: 0
  length: 54
  flags: 0x2000
  type: 2
  session_id: paa_session_id
  seq_no: paa_seq_no + 5
PANAAVP
  code: 4
  flags: 0
  length: 4
  rsvd: 0
  key_id: 0
PANAAVP
  code: 1
  flags: 0
  length: 16
  rsvd: 0
  auth: 16 bytes
    PANA Complete is forwarded by PANA relay router 
    PANA
  rsvd: 0
  length: 54
  flags: 0x2000
  type: 2
  session_id: paa_session_id
  seq_no: paa_seq_no + 5
PANAAVP
  code: 4
  flags: 0
  length: 4
  rsvd: 0
  key_id: 0
PANAAVP
  code: 1
  flags: 0
  length: 16
  rsvd: 0
  auth: 16 bytes
    PANA Complete is forwarded to PAA 
    PANA
  rsvd: 0
  length: 54
  flags: 0x2000
  type: 2
  session_id: paa_session_id
  seq_no: paa_seq_no + 5
PANAAVP
  code: 4
  flags: 0
  length: 4
  rsvd: 0
  key_id: 0
PANAAVP
  code: 1
  flags: 0
  length: 16
  rsvd: 0
  auth: 16 bytes
    Neighbor Solicitation (NS) is initiated to discovery = neighbor and validate (short) address 
    802.15.4
  source: Short address (tentative)
  dest: Short address (Derived from SLLAO in RA)
IP
  Hop limit: 255
  source: GP16 (tentative)
  dest: LL16 of parent router
  Target: LL16 of parent router
SLLAO: Short address
ARO: EUI-64, no IP address, status=3D0
    Duplicate Address Request (DAR) is initiated from = parent router 
    type	156
802.15.4
  source: Short address of parent router
  dest: Short address of next hop
IP
  Hop limit: [variable]
  source:	GP16 of parent router
  dest: GP16 of LBR
  Status: 0
  Registration lifetime: [variable]
  EUI-64: EUI-64 of registering node
  Registered Address: IP source of NS that contained ARO option
    Duplicate Address Request (DAR) is forwarded by relay = router 
    type	156
802.15.4
  source: Short address of parent router
  dest: Short address of next hop
IP
  Hop limit: [variable]
  source:	GP16 of parent router
  dest: GP16 of LBR
  Status: 0
  Registration lifetime: [variable]
  EUI-64: EUI-64 of registering node
  Registered Address: IP source of NS that contained ARO option
    Duplicate Address Confirmation (DAC) is responded by = border router 
    type	157
802.15.4
  source: Short address of LBR
  dest: Short address of next hop
IP
  Hop limit: [variable]
  source: GP16 of LBR
  dest: GP16 of parent router
  Status: Draft-ietf-6lowpan-nd-14 Table 1
  Registration lifetime: [variable]
  EUI-64: EUI-64 of registering node
  Registered Address: Copied from the DAR
    Duplicate Address Confirmation (DAC) is forwarded to = parent router 
    type	157
802.15.4
  source: Short address of LBR
  dest: Short address of next hop
IP
  Hop limit: [variable]
  source: GP16 of LBR
  dest: GP16 of parent router
  Status: Draft-ietf-6lowpan-nd-14 Table 1
  Registration lifetime: [variable]
  EUI-64: EUI-64 of registering node
  Registered Address: Copied from the DAR
    Neighbor Advertisement (NA) is replied by parent = router 
    802.15.4
  source: Short address
  dest: Success? Short address : IEEE address
IP
  Hop limit: 255
  source: LL16 of parent router
  dest: Success ? GP16 : LL64
  Target: LL16 of parent router
ARO: EUI-64, no IP address, status
    ICMP request is initiated to verify communication 
    IP
  source: GP16=20
  dest: GP16
ICMPV6
  Type: 0x80
    ICMP request is forwarded by parent router 
    IP
  source: GP16=20
  dest: GP16
ICMPV6
  Type: 0x80
    ICMP request is forwarded by relay router 
    IP
  source: GP16=20
  dest: GP16
ICMPV6
  Type: 0x80
    ICMP reply is responded by border router 
    IP
  source: GP16=20
  dest: GP16
ICMPV6
  Type: 0x81
    ICMP reply is forwarded to parent router 
    IP
  source: GP16=20
  dest: GP16
ICMPV6
  Type: 0x81
    ICMP reply is replied by parent router 
    802.15.4
  source: Short address
  dest: Success? Short address : IEEE address
IP
  Hop limit: 255
  source: LL16 of parent router
  dest: Success ? GP16 : LL64
  Target: LL16 of parent router
ARO: EUI-64, no IP address, status

    Verification

  • All packets shall follow the formats = described.
  • Communication via ping shall succeed.

    •

    1.10 Router Join - 1 Hop, with = Authentication

    Initial Condition

    channel: 0x14 for all devices
    panId: 0x1AAA
    linkLocal: fe80::/64
    globalPrefix: fd01::/64
    CCM Parameters: MIC Length M =3D 8, Length length L =3D 3
    Test Pre-shared key (PSK) octet string: {0xcf, 0xce, 0xcd, 0xcc, 0xcb,=20 0xca, 0xc9, 0xc8, 0xc7, 0xc6, 0xc5, 0xc4, 0xc3, 0xc2, 0xc1, 0xc0}
    Test Network key octet string: {0xbf, 0xbe, 0xbd, 0xbc, 0xbb, 0xba, = 0xb9, 0xb8, 0xb7, 0xb6, 0xb5, 0xb4, 0xb3, 0xb2, 0xb1, 0xb0}
    Key length N =3D 16

    Topology

    Router             BorderRouter

    |                |
|   --------->   | Beacon Request (broadcast)
|   <-----       | Beacon Response
|                |

    |                |
|   --------->   | RS (multicast)
|   <-----       | RA
|                |

    |                |
|   ------>      | PCI
|   <------      | PAR
|   ------>      | PAN
|   <------      | PAR EAP Request
|   ------>      | PAN EAP Response
|   <------      | PAR TLS Start
|   ------>      | PAN TLS Client Hello
|   <------      | PAR TLS Server Hello, Server Hello Done
|   ------>      | PAN TLS Client Key Exchange, Change Cipher Spec, =
Finished
|   <------      | PAR TLS Change Cipher Spec, Finish, Network key
|   ------>      | PAN EAP Response
|   <------      | PAR EAP Success
|   ------>      | PAN Complete
|                |

    |                |
|   ------>      | NS
|   <------      | NA
|                |

    |                |
|   --------->   | DIS (broadcast)
|   <-----       | DIO (from all routers in radio range)
|   ------>      | DIS (unicast)
|   <-----       | DIO (with prefix information)
|                |

    |                |
|   ------>      | DAO
|   <------      | DAO-ACK
|                |

    |                |
|   ------>      | ICMP Request
|   <------      | ICMP Reply
|                |

    Sub Test Cases

    A: Router =3D DUT
    B: Border Router =3D DUT

    Test Procedure

    Beacon request is sent to initiate active scan 
    802.15.4
  FrameControl: 0x0803
    FrameType: 0x03
    SecurityEnable: false
    FramePending: false
    AckRequired: false
    IntraPan: false
    Dest Addr Mode: 0x02
    Src Addr Mode: 0x00
  Dest PanId: 0xffff
  Short Dest Addr: 0xffff
802.15.4 command: 0x07
    Beacon response is replied from all routers within = radio range 
    802.15.4
  FrameControl: 0x8000
    FrameType: 0x00
    SecurityEnable: false
    FramePending: false
    AckRequired: false
    IntraPan: false
    Dest Addr Mode: 0x00
    Src Addr Mode: 0x02
  Source PanId: [variable]
  Short Source Addr: [variable]
Beacon Payload
  Protocal ID: 0x02
  Control Field
    Bit 0: Allow Join
    Bit 1-7: Reserved
  NetworkID
  AppInfo
    Router Solicitation (RS) is sent as muticast to = discovery routers within range 
    802.15.4
  source: IEEE address
  dest: Broadcast
IP
  Hop limit: 255
  source: LL64
  dest: All-routers multicast
SLLAO: IEEE address
    Router Advertisement (RA) is replied from all = routers within radio range, containing prefix and context = information 
    802.15.4
  source: Short address
  dest: IEEE address
IP
  Hop limit: 255
  source: LL16
  dest: LL64
SLLAO: Short address
PIO: PAN-wide prefix (GP)
ABRO: 6LBR (GP16)
6CO: Context 0 (i.e. GP)
    PANA-Client-Initiation (PCI) is initiated by PANA = Client (PaC) to establish the authentication 
    PANA
  rsvd: 0
  length: 16
  flags: 0x0000
  type: 1
  session_id: 0
  seq_no: 0
    PANA-Auth-Request (PAR) is received by PANA = Client 
    PANA
  rsvd: 0
  length: 40
  flags: 0xC000
  type: 2
  session_id: paa_session_id
  seq_no: paa_seq_no
If PRF_HMAC_SHA2_256 is the only PRF, the following AVP may be optional
PANAAVP
  code: 6
  flags: 0
  length: 4
  rsvd: 0
  prf_algorithm: 5
If AUTH_HMAC_SHA2_256_128 is the only integrity algorithm, the following =
AVP may be optional
PANAAVP
  code: 3
  flags: 0
  length: 4
  rsvd: 0
  integrity_algorithm: 12
    PANA-Auth-Answer (PAN) is replied by PaC 
    PANA
  rsvd: 0
  length: 40
  flags: 0x4000
  type: 2
  session_id: paa_session_id
  seq_no: paa_seq_no
If PRF_HMAC_SHA2_256 is the only PRF, the following AVP may be optional
PANAAVP
  code: 6
  flags: 0
  length: 4
  rsvd: 0
  prf_algorithm: 5
If AUTH_HMAC_SHA2_256_128 is the only integrity algorithm, the following =
AVP may be optional
PANAAVP
  code: 3
  flags: 0
  length: 4
  rsvd: 0
  integrity_algorithm: 12
    PANA EAP Request is received by PANA Client 
    PANA
  rsvd: 0
  length: 56
  flags: 0x8000
  type: 2
  session_id: paa_session_id
  seq_no: paa_seq_no + 1
PANAAVP
  code: 5
  flags: 0
  length: 16
  rsvd: 0
  nonce: 16 bytes
PANAAVP - optional
  code: 2
  flags: 0
  length: 5
  rsvd: 0
  EAPReqUnfrag
    code: 1
    identifier: idseq
    length: 5
    type: 1
  AVPPad: 3 bytes
    PANA EAP Response is replied by PaC 
    PANA
  rsvd: 0
  length: 64
  flags: 0x0000
  type: 2
  session_id: paa_session_id
  seq_no: paa_seq_no + 1
PANAAVP
  code: 5
  flags: 0
  length: 16
  rsvd: 0
  nonce: 16 bytes
PANAAVP - optional
  code: 2
  flags: 0
  length: 14
  rsvd: 0
  EAPRespUnfrag
    code: 2
    identifier: idseq
    length: 14
    type: 1
    identity: "anonymous"
  AVPPad: 2 bytes
    PANA TLS Start is received by PANA Client 
    PANA
  rsvd: 0
  length: 32
  flags: 0x8000
  type: 2
  session_id: paa_session_id
  seq_no: paa_seq_no + 2
PANAAVP
  code: 2
  flags: 0
  length: 6
  rsvd: 0
  EAPReqUnfrag
    code: 1
    identifier: idseq + 1
    length: 6
    type: 21
    flags: 0x20
  AVPPad: 2 bytes
    PANA TLS Client Hello is replied by PaC 
    PANA
  rsvd: 0
  length: 80
  flags: 0x0000
  type: 2
  session_id: paa_session_id
  seq_no: paa_seq_no + 2
PANAAVP
  code: 2
  flags: 0
  length: 56
  rsvd: 0
  EAPRespUnfrag
    code: 2
    identifier: idseq + 1
    length: 56
    type: 21
    flags: 0x00
    TLSPlaintext
      type: 22
      version: 0x0303
      length: 45
      Handshake
        msg_type: 1
        length: 41
        ClientHello
          ProtocolVersion
            major: 0x03
            minor: 0x03
          Random
            gmt_unix_time
            random_bytes: 28 bytes
          SessionID<0..32>
            length: 0 (NULL)
          <2..2^16-2>
            length: 2
            CipherSuite=20
              bytes: {0x00, 0xC6}
          <1..2^8-2>
            length: 1
            compression_methods: {0}
          NOTE: extensions will be needed for public key cipher suite
            No extensions=20
    PANA TLS Server Hello, Server Hello Done is received = by PANA Client 
    PANA
  rsvd: 0
  length: 88
  flags: 0x8000
  type: 2
  session_id: paa_session_id
  seq_no: paa_seq_no + 3
PANAAVP
  code: 2
  flags: 0
  length: 61
  rsvd: 0
  EAPReqUnfrag
    code: 1
    identifier: idseq + 2
    length: 61
    type: 21
    flags: 0x00
    TLSPlaintext
      type: 22
      version: 0x0303
      length: 50
      Handshake
        msg_type: 2
        length: 42
        ServerHello
          ProtocolVersion
            major: 0x03
            minor: 0x03
          Random
            gmt_unix_time
            random_bytes: 28 bytes
          SessionID<0..32>
            length: 4
            bytes: 4
            CipherSuite=20
              bytes: {0x00, 0xC6}
            compression_methods: {0}
          NOTE: extensions will be needed for public key cipher suite
            No extensions=20
      Handshake
        msg_type: 14
        length: 0
        ServerHelloDone: Empty
  AVPPad: 3 bytes
    PANA TLS Client Key Exchange, Change Cipher Spec, = Finished is replied by PaC 
    PANA
  rsvd: 0
  length: 88
  flags: 0x0000
  type: 2
  session_id: paa_session_id
  seq_no: paa_seq_no + 3
PANAAVP
  code: 2
  flags: 0
  length: 62
  rsvd: 0
  EAPRespUnfrag
    code: 2
    identifier: idseq + 2
    length: 62
    type: 21
    flags: 0x00
    TLSPlaintext
      type: 22
      version: 0x0303
      length: 4
      Handshake
        msg_type: 16
        length: 4
        ClientKeyExchange
          <0..2^16-1>
            length: 2
            bytes: {0x30, 0x00}
    TLSPlaintext
      type: 20
      version: 0x0303
      length: 1
      ChangeCipherSpec
        type: 1
    TLSPlaintext
      type: 22
      version: 0x0303
      length: 32
      GenericAEADCipher
        CCMNonceExplicit
          seq_num
        CCMCipherText
          Handshake
            msg_type: 20
            length: 12
            Finished
              verify_data: 12 bytes
        MAC: Using AES_CCM_8
  AVPPad: 2 bytes
    PANA TLS Change Cipher Spec, Finish, Network key is = received by PANA Client 
    PANA
  rsvd: 0
  length: 134
  flags: 0x8000
  type: 2
  session_id: paa_session_id
  seq_no: paa_seq_no + 4
PANAAVP
  code: 2
  flags: 0
  length: 49
  rsvd: 0
  EAPReqUnfrag
    code: 1
    identifier: idseq + 3
    length: 112
    type: 21
    flags: 0x00
    TLSPlaintext
      type: 20
      version: 0x0303
      length: 1
      ChangeCipherSpec
        type: 1
    TLSPlaintext
      type: 22
      version: 0x0303
      length: 32
      GenericAEADCipher
        CCMNonceExplicit
          seq_num
        CCMCipherText
          Handshake
            msg_type: 20
            length: 12
            Finished
              verify_data: 12 bytes
        MAC: Using AES_CCM_8
    TLSPlaintext
      type: 23
      version: 0x0303
      length: 44
      GenericAEADCipher
        CCMNonceExplicit
          seq_num
        CCMCipherText
          EAPTTLSAVP
            avp_code: 1
            avp_flags: 0xC0
            length: 28
            vendor_id: 36743
            network key: 16 bytes
        MAC: Using AES_CCM_8
    PANA EAP Response is replied by PaC 
    PANA
  rsvd: 0
  length: 30
  flags: 0x0000
  type: 2
  session_id: paa_session_id
  seq_no: paa_seq_no + 4
PANAAVP
  code: 2
  flags: 0
  length: 6
  rsvd: 0
  nonce: 16 bytes
  EAPRespUnfrag
    code: 2
    identifier: idseq + 3
    length: 6
    type: 21
    flag: 0x20
  AVPPad: 2 bytes
    PANA EAP Success is received by PANA Client 
    PANA
  rsvd: 0
  length: 88
  flags: 0xA000
  type: 2
  session_id: paa_session_id
  seq_no: paa_seq_no + 5
PANAAVP
  code: 7
  flags: 0
  length: 4
  rsvd: 0
  result_code: 0
PANAAVP
  code: 2
  flags: 0
  length: 4
  rsvd: 0
  EAPSUCCESS
    code: 3
    identifier: idseq + 4
    length: 4
PANAAVP
  code: 4
  flags: 0
  length: 4
  rsvd: 0
  key_id: 0
PANAAVP
  code: 8
  flags: 0
  length: 4
  rsvd: 0
  sess_life: 0xFFFFFFFF
PANAAVP
  code: 1
  flags: 0
  length: 16
  rsvd: 0
  auth: 16 bytes
    PANA Complete is replied by PaC 
    PANA
  rsvd: 0
  length: 54
  flags: 0x2000
  type: 2
  session_id: paa_session_id
  seq_no: paa_seq_no + 5
PANAAVP
  code: 4
  flags: 0
  length: 4
  rsvd: 0
  key_id: 0
PANAAVP
  code: 1
  flags: 0
  length: 16
  rsvd: 0
  auth: 16 bytes
    Neighbor Solicitation (NS) is initiated to discovery = neighbor and validate (short) address 
    802.15.4
  source: Short address (tentative)
  dest: Short address (Derived from SLLAO in RA)
IP
  Hop limit: 255
  source: GP16 (tentative)
  dest: LL16 of parent router
  Target: LL16 of parent router
SLLAO: Short address
ARO: EUI-64, no IP address, status=3D0
    Neighbor Advertisement (NA) is replied by parent = router 
    802.15.4
  source: Short address
  dest: Success? Short address : IEEE address
IP
  Hop limit: 255
  source: LL16 of parent router
  dest: Success ? GP16 : LL64
  Target: LL16 of parent router
ARO: EUI-64, no IP address, status
    DODAG Information Solicitation (DIS) is sent as = broadcast 
    IP
  source: LL16
  destination: FF02::1A
ICMPv6 DIS
  DIS Base
    2 bytes reserved
    No options
    2 bytes padding
    DODAG Information Object (DIO) is replied from all = routers within radio range 
    IP
  source: LL16
  dest: LL16 of DIS sender
ICMPv6 DIO=20
  DIO Base
    'G': 1 (grounded)
    MOP: binary 001
    PRF: 0
    DODAGID: GP16 of root
  Route Information Option
    Prefix Length: 64
    Route Lifetime: 0xFFFFFFFF
    Prefix: GP
  DODAG Configuration Option
    'A': 0
    DIOIntMIN  : 3
    DIOIntDoubl: 20
    DIORedun:    10
    MaxRankIncrease: 0
    MinHopRankIncrease: 256
  Prefix Information Option
    'R': 1
    Valid Lifetime: 0xFFFFFFFF
    Preferred Lifetime: 0xFFFFFFFF
    Prefix: GP16 of source
    DODAG Information Solicitation (DIS) is sent as = unicast to parent router 
    IP
  source: LL16
  destination: FF02::1A
ICMPv6 DIS
  DIS Base
    2 bytes reserved
    No options
    2 bytes padding
    DODAG Information Object (DIO) is replied from = parent router with prefix information 
    IP
  source: LL16
  dest: LL16 of DIS sender
ICMPv6 DIO=20
  DIO Base
    'G': 1 (grounded)
    MOP: binary 001
    PRF: 0
    DODAGID: GP16 of root
  Route Information Option
    Prefix Length: 64
    Route Lifetime: 0xFFFFFFFF
    Prefix: GP
  DODAG Configuration Option
    'A': 0
    DIOIntMIN  : 3
    DIOIntDoubl: 20
    DIORedun:    10
    MaxRankIncrease: 0
    MinHopRankIncrease: 256
  Prefix Information Option
    'R': 1
    Valid Lifetime: 0xFFFFFFFF
    Preferred Lifetime: 0xFFFFFFFF
    Prefix: GP16 of source
    Destination Advertisement Object (DAO) is initiated = to establish upward route 
    IP
  source: GP16
  dest: GP16 of root
ICMPv6 DAO
  DAO Base
    'K': 1
    'D': 0
  Target Option
    Prefix Length: 128
    Target Prefix: GP16
  Transit Option
    Path Control: 1
    Path Lifetime: 0xFFFFFFFF
    Parent Address: GP16 of parent
    Destination Advertisement Object Acknowledgement = (DAO-ACK) is forwarded by parent router 
    IP
  source: GP16 of root
  dest: GP16
  Routing Extension Header RH4 (if hop>1)
    Compr: 14
    Addresses: list of MAC short addresses
ICMPV6 DAO-ACK
  'D': 0
    ICMP request is initiated to verify = communication 
    IP
  source: GP16=20
  dest: GP16
ICMPV6
  Type: 0x80
    ICMP reply is replied by parent router 
    802.15.4
  source: Short address
  dest: Success? Short address : IEEE address
IP
  Hop limit: 255
  source: LL16 of parent router
  dest: Success ? GP16 : LL64
  Target: LL16 of parent router
ARO: EUI-64, no IP address, status

    Verification

  • All packets shall follow the formats = described.
  • Communication via ping shall succeed.

    •

    1.11 Router Join - 2 Hop, with = Authentication

    Initial Condition

    channel: 0x14 for all devices
    panId: 0x1AAA
    linkLocal: fe80::/64
    globalPrefix: fd01::/64
    CCM Parameters: MIC Length M =3D 8, Length length L =3D 3
    Test Pre-shared key (PSK) octet string: {0xcf, 0xce, 0xcd, 0xcc, 0xcb,=20 0xca, 0xc9, 0xc8, 0xc7, 0xc6, 0xc5, 0xc4, 0xc3, 0xc2, 0xc1, 0xc0}
    Test Network key octet string: {0xbf, 0xbe, 0xbd, 0xbc, 0xbb, 0xba, = 0xb9, 0xb8, 0xb7, 0xb6, 0xb5, 0xb4, 0xb3, 0xb2, 0xb1, 0xb0}
    Key length N =3D 16

    Topology

    Router             ParentRouter       BorderRouter

    |                |
|   --------->   | Beacon Request (broadcast)
|   <-----       | Beacon Response
|                |

    |                |
|   --------->   | RS (multicast)
|   <-----       | RA
|                |

    |                |
|   ------>      | PCI
|                |   ------>       | RLY(PCI)
|                |   <------       | RLY(PAR)
|   <------      | PAR
|   ------>      | PAN
|                |   ------>       | RLY(PAN)
|                |   <------       | RLY(PAR EAP Request)
|   <------      | PAR EAP Request
|   ------>      | PAN EAP Response
|                |   ------>       | RLY(PAN EAP Response)
|                |   <------       | RLY(PAR TLS Start)
|   <------      | PAR TLS Start
|   ------>      | PAN TLS Client Hello
|                |   ------>       | RLY(PAN TLS Client Hello)
|                |   <------       | RLY(PAR TLS Server Hello, Server =
Hello Done)
|   <------      | PAR TLS Server Hello, Server Hello Done
|   ------>      | PAN TLS Client Key Exchange, Change Cipher Spec, =
Finished
|                |   ------>       | RLY(PAN TLS Client Key Exchange, =
Change Cipher Spec, Finished)
|                |   <------       | RLY(PAR TLS Change Cipher Spec, =
Finish, Network key)
|   <------      | PAR TLS Change Cipher Spec, Finish, Network key
|   ------>      | PAN EAP Response
|                |   ------>       | RLY(PAN EAP Response)
|                |   <------       | RLY(PAR EAP Success)
|   <------      | PAR EAP Success
|   ------>      | PAN Complete
|                |   ------>       | RLY(PAN Complete)
|                |

    |                |
|   ------>      | NS
|                |   ------>       | DAR
|                |   <------       | DAC
|   <------      | NA
|                |

    |                |
|   --------->   | DIS (broadcast)
|   <-----       | DIO (from all routers in radio range)
|   ------>      | DIS (unicast)
|   <-----       | DIO (with prefix information)
|                |

    |                |
|   ------>      | DAO
|                |   ------>       | DAO
|                |   <------       | DAO-ACK
|   <------      | DAO-ACK
|                |

    |                |
|   ------>      | ICMP Request
|                |   ------>       | ICMP Request
|                |   <------       | ICMP Reply
|   <------      | ICMP Reply
|                |

    Sub Test Cases

    A: Router =3D DUT
    B: Parent/Relay Router =3D DUT
    C: Border Router =3D DUT

    Test Procedure

    Beacon request is sent to initiate active scan 
    802.15.4
  FrameControl: 0x0803
    FrameType: 0x03
    SecurityEnable: false
    FramePending: false
    AckRequired: false
    IntraPan: false
    Dest Addr Mode: 0x02
    Src Addr Mode: 0x00
  Dest PanId: 0xffff
  Short Dest Addr: 0xffff
802.15.4 command: 0x07
    Beacon response is replied from all routers within = radio range 
    802.15.4
  FrameControl: 0x8000
    FrameType: 0x00
    SecurityEnable: false
    FramePending: false
    AckRequired: false
    IntraPan: false
    Dest Addr Mode: 0x00
    Src Addr Mode: 0x02
  Source PanId: [variable]
  Short Source Addr: [variable]
Beacon Payload
  Protocal ID: 0x02
  Control Field
    Bit 0: Allow Join
    Bit 1-7: Reserved
  NetworkID
  AppInfo
    Router Solicitation (RS) is sent as muticast to = discovery routers within range 
    802.15.4
  source: IEEE address
  dest: Broadcast
IP
  Hop limit: 255
  source: LL64
  dest: All-routers multicast
SLLAO: IEEE address
    Router Advertisement (RA) is replied from all = routers within radio range, containing prefix and context = information 
    802.15.4
  source: Short address
  dest: IEEE address
IP
  Hop limit: 255
  source: LL16
  dest: LL64
SLLAO: Short address
PIO: PAN-wide prefix (GP)
ABRO: 6LBR (GP16)
6CO: Context 0 (i.e. GP)
    PANA-Client-Initiation (PCI) is initiated by PANA = Client (PaC) to establish the authentication 
    PANA
  rsvd: 0
  length: 16
  flags: 0x0000
  type: 1
  session_id: 0
  seq_no: 0
    PANA-Client-Initiation (PCI) is forwarded by PANA = relay router 
    PANA
  rsvd: 0
  length: 16
  flags: 0x0000
  type: 1
  session_id: 0
  seq_no: 0
    PANA-Auth-Request (PAR) is forwarded by PANA relay = router 
    PANA
  rsvd: 0
  length: 40
  flags: 0xC000
  type: 2
  session_id: paa_session_id
  seq_no: paa_seq_no
If PRF_HMAC_SHA2_256 is the only PRF, the following AVP may be optional
PANAAVP
  code: 6
  flags: 0
  length: 4
  rsvd: 0
  prf_algorithm: 5
If AUTH_HMAC_SHA2_256_128 is the only integrity algorithm, the following =
AVP may be optional
PANAAVP
  code: 3
  flags: 0
  length: 4
  rsvd: 0
  integrity_algorithm: 12
    PANA-Auth-Request (PAR) is received by PANA = Client 
    PANA
  rsvd: 0
  length: 40
  flags: 0xC000
  type: 2
  session_id: paa_session_id
  seq_no: paa_seq_no
If PRF_HMAC_SHA2_256 is the only PRF, the following AVP may be optional
PANAAVP
  code: 6
  flags: 0
  length: 4
  rsvd: 0
  prf_algorithm: 5
If AUTH_HMAC_SHA2_256_128 is the only integrity algorithm, the following =
AVP may be optional
PANAAVP
  code: 3
  flags: 0
  length: 4
  rsvd: 0
  integrity_algorithm: 12
    PANA-Auth-Answer (PAN) is replied by PaC 
    PANA
  rsvd: 0
  length: 40
  flags: 0x4000
  type: 2
  session_id: paa_session_id
  seq_no: paa_seq_no
If PRF_HMAC_SHA2_256 is the only PRF, the following AVP may be optional
PANAAVP
  code: 6
  flags: 0
  length: 4
  rsvd: 0
  prf_algorithm: 5
If AUTH_HMAC_SHA2_256_128 is the only integrity algorithm, the following =
AVP may be optional
PANAAVP
  code: 3
  flags: 0
  length: 4
  rsvd: 0
  integrity_algorithm: 12
    PANA-Auth-Answer (PAN) is forwarded by PANA relay = router 
    PANA
  rsvd: 0
  length: 40
  flags: 0x4000
  type: 2
  session_id: paa_session_id
  seq_no: paa_seq_no
If PRF_HMAC_SHA2_256 is the only PRF, the following AVP may be optional
PANAAVP
  code: 6
  flags: 0
  length: 4
  rsvd: 0
  prf_algorithm: 5
If AUTH_HMAC_SHA2_256_128 is the only integrity algorithm, the following =
AVP may be optional
PANAAVP
  code: 3
  flags: 0
  length: 4
  rsvd: 0
  integrity_algorithm: 12
    PANA EAP Request is forwarded by PANA relay = router 
    PANA
  rsvd: 0
  length: 56
  flags: 0x8000
  type: 2
  session_id: paa_session_id
  seq_no: paa_seq_no + 1
PANAAVP
  code: 5
  flags: 0
  length: 16
  rsvd: 0
  nonce: 16 bytes
PANAAVP - optional
  code: 2
  flags: 0
  length: 5
  rsvd: 0
  EAPReqUnfrag
    code: 1
    identifier: idseq
    length: 5
    type: 1
  AVPPad: 3 bytes
    PANA EAP Request is received by PANA Client 
    PANA
  rsvd: 0
  length: 56
  flags: 0x8000
  type: 2
  session_id: paa_session_id
  seq_no: paa_seq_no + 1
PANAAVP
  code: 5
  flags: 0
  length: 16
  rsvd: 0
  nonce: 16 bytes
PANAAVP - optional
  code: 2
  flags: 0
  length: 5
  rsvd: 0
  EAPReqUnfrag
    code: 1
    identifier: idseq
    length: 5
    type: 1
  AVPPad: 3 bytes
    PANA EAP Response is replied by PaC 
    PANA
  rsvd: 0
  length: 64
  flags: 0x0000
  type: 2
  session_id: paa_session_id
  seq_no: paa_seq_no + 1
PANAAVP
  code: 5
  flags: 0
  length: 16
  rsvd: 0
  nonce: 16 bytes
PANAAVP - optional
  code: 2
  flags: 0
  length: 14
  rsvd: 0
  EAPRespUnfrag
    code: 2
    identifier: idseq
    length: 14
    type: 1
    identity: "anonymous"
  AVPPad: 2 bytes
    PANA EAP Response is forwarded by PANA relay = router 
    PANA
  rsvd: 0
  length: 64
  flags: 0x0000
  type: 2
  session_id: paa_session_id
  seq_no: paa_seq_no + 1
PANAAVP
  code: 5
  flags: 0
  length: 16
  rsvd: 0
  nonce: 16 bytes
PANAAVP - optional
  code: 2
  flags: 0
  length: 14
  rsvd: 0
  EAPRespUnfrag
    code: 2
    identifier: idseq
    length: 14
    type: 1
    identity: "anonymous"
  AVPPad: 2 bytes
    PANA TLS Start is forwarded by PANA relay router 
    PANA
  rsvd: 0
  length: 32
  flags: 0x8000
  type: 2
  session_id: paa_session_id
  seq_no: paa_seq_no + 2
PANAAVP
  code: 2
  flags: 0
  length: 6
  rsvd: 0
  EAPReqUnfrag
    code: 1
    identifier: idseq + 1
    length: 6
    type: 21
    flags: 0x20
  AVPPad: 2 bytes
    PANA TLS Start is received by PANA Client 
    PANA
  rsvd: 0
  length: 32
  flags: 0x8000
  type: 2
  session_id: paa_session_id
  seq_no: paa_seq_no + 2
PANAAVP
  code: 2
  flags: 0
  length: 6
  rsvd: 0
  EAPReqUnfrag
    code: 1
    identifier: idseq + 1
    length: 6
    type: 21
    flags: 0x20
  AVPPad: 2 bytes
    PANA TLS Client Hello is replied by PaC 
    PANA
  rsvd: 0
  length: 80
  flags: 0x0000
  type: 2
  session_id: paa_session_id
  seq_no: paa_seq_no + 2
PANAAVP
  code: 2
  flags: 0
  length: 56
  rsvd: 0
  EAPRespUnfrag
    code: 2
    identifier: idseq + 1
    length: 56
    type: 21
    flags: 0x00
    TLSPlaintext
      type: 22
      version: 0x0303
      length: 45
      Handshake
        msg_type: 1
        length: 41
        ClientHello
          ProtocolVersion
            major: 0x03
            minor: 0x03
          Random
            gmt_unix_time
            random_bytes: 28 bytes
          SessionID<0..32>
            length: 0 (NULL)
          <2..2^16-2>
            length: 2
            CipherSuite=20
              bytes: {0x00, 0xC6}
          <1..2^8-2>
            length: 1
            compression_methods: {0}
          NOTE: extensions will be needed for public key cipher suite
            No extensions=20
    PANA TLS Client Hello is forwarded by PANA relay = router 
    PANA
  rsvd: 0
  length: 80
  flags: 0x0000
  type: 2
  session_id: paa_session_id
  seq_no: paa_seq_no + 2
PANAAVP
  code: 2
  flags: 0
  length: 56
  rsvd: 0
  EAPRespUnfrag
    code: 2
    identifier: idseq + 1
    length: 56
    type: 21
    flags: 0x00
    TLSPlaintext
      type: 22
      version: 0x0303
      length: 45
      Handshake
        msg_type: 1
        length: 41
        ClientHello
          ProtocolVersion
            major: 0x03
            minor: 0x03
          Random
            gmt_unix_time
            random_bytes: 28 bytes
          SessionID<0..32>
            length: 0 (NULL)
          <2..2^16-2>
            length: 2
            CipherSuite=20
              bytes: {0x00, 0xC6}
          <1..2^8-2>
            length: 1
            compression_methods: {0}
          NOTE: extensions will be needed for public key cipher suite
            No extensions=20
    PANA TLS Server Hello, Server Hello Done is = forwarded by PANA relay router 
    PANA
  rsvd: 0
  length: 88
  flags: 0x8000
  type: 2
  session_id: paa_session_id
  seq_no: paa_seq_no + 3
PANAAVP
  code: 2
  flags: 0
  length: 61
  rsvd: 0
  EAPReqUnfrag
    code: 1
    identifier: idseq + 2
    length: 61
    type: 21
    flags: 0x00
    TLSPlaintext
      type: 22
      version: 0x0303
      length: 50
      Handshake
        msg_type: 2
        length: 42
        ServerHello
          ProtocolVersion
            major: 0x03
            minor: 0x03
          Random
            gmt_unix_time
            random_bytes: 28 bytes
          SessionID<0..32>
            length: 4
            bytes: 4
            CipherSuite=20
              bytes: {0x00, 0xC6}
            compression_methods: {0}
          NOTE: extensions will be needed for public key cipher suite
            No extensions=20
      Handshake
        msg_type: 14
        length: 0
        ServerHelloDone: Empty
  AVPPad: 3 bytes
    PANA TLS Server Hello, Server Hello Done is received = by PANA Client 
    PANA
  rsvd: 0
  length: 88
  flags: 0x8000
  type: 2
  session_id: paa_session_id
  seq_no: paa_seq_no + 3
PANAAVP
  code: 2
  flags: 0
  length: 61
  rsvd: 0
  EAPReqUnfrag
    code: 1
    identifier: idseq + 2
    length: 61
    type: 21
    flags: 0x00
    TLSPlaintext
      type: 22
      version: 0x0303
      length: 50
      Handshake
        msg_type: 2
        length: 42
        ServerHello
          ProtocolVersion
            major: 0x03
            minor: 0x03
          Random
            gmt_unix_time
            random_bytes: 28 bytes
          SessionID<0..32>
            length: 4
            bytes: 4
            CipherSuite=20
              bytes: {0x00, 0xC6}
            compression_methods: {0}
          NOTE: extensions will be needed for public key cipher suite
            No extensions=20
      Handshake
        msg_type: 14
        length: 0
        ServerHelloDone: Empty
  AVPPad: 3 bytes
    PANA TLS Client Key Exchange, Change Cipher Spec, = Finished is replied by PaC 
    PANA
  rsvd: 0
  length: 88
  flags: 0x0000
  type: 2
  session_id: paa_session_id
  seq_no: paa_seq_no + 3
PANAAVP
  code: 2
  flags: 0
  length: 62
  rsvd: 0
  EAPRespUnfrag
    code: 2
    identifier: idseq + 2
    length: 62
    type: 21
    flags: 0x00
    TLSPlaintext
      type: 22
      version: 0x0303
      length: 4
      Handshake
        msg_type: 16
        length: 4
        ClientKeyExchange
          <0..2^16-1>
            length: 2
            bytes: {0x30, 0x00}
    TLSPlaintext
      type: 20
      version: 0x0303
      length: 1
      ChangeCipherSpec
        type: 1
    TLSPlaintext
      type: 22
      version: 0x0303
      length: 32
      GenericAEADCipher
        CCMNonceExplicit
          seq_num
        CCMCipherText
          Handshake
            msg_type: 20
            length: 12
            Finished
              verify_data: 12 bytes
        MAC: Using AES_CCM_8
  AVPPad: 2 bytes
    PANA TLS Client Key Exchange, Change Cipher Spec, = Finished is forwarded by PANA relay router 
    PANA
  rsvd: 0
  length: 88
  flags: 0x0000
  type: 2
  session_id: paa_session_id
  seq_no: paa_seq_no + 3
PANAAVP
  code: 2
  flags: 0
  length: 62
  rsvd: 0
  EAPRespUnfrag
    code: 2
    identifier: idseq + 2
    length: 62
    type: 21
    flags: 0x00
    TLSPlaintext
      type: 22
      version: 0x0303
      length: 4
      Handshake
        msg_type: 16
        length: 4
        ClientKeyExchange
          <0..2^16-1>
            length: 2
            bytes: {0x30, 0x00}
    TLSPlaintext
      type: 20
      version: 0x0303
      length: 1
      ChangeCipherSpec
        type: 1
    TLSPlaintext
      type: 22
      version: 0x0303
      length: 32
      GenericAEADCipher
        CCMNonceExplicit
          seq_num
        CCMCipherText
          Handshake
            msg_type: 20
            length: 12
            Finished
              verify_data: 12 bytes
        MAC: Using AES_CCM_8
  AVPPad: 2 bytes
    PANA TLS Change Cipher Spec, Finish, Network key is = forwarded by PANA relay router 
    PANA
  rsvd: 0
  length: 134
  flags: 0x8000
  type: 2
  session_id: paa_session_id
  seq_no: paa_seq_no + 4
PANAAVP
  code: 2
  flags: 0
  length: 49
  rsvd: 0
  EAPReqUnfrag
    code: 1
    identifier: idseq + 3
    length: 112
    type: 21
    flags: 0x00
    TLSPlaintext
      type: 20
      version: 0x0303
      length: 1
      ChangeCipherSpec
        type: 1
    TLSPlaintext
      type: 22
      version: 0x0303
      length: 32
      GenericAEADCipher
        CCMNonceExplicit
          seq_num
        CCMCipherText
          Handshake
            msg_type: 20
            length: 12
            Finished
              verify_data: 12 bytes
        MAC: Using AES_CCM_8
    TLSPlaintext
      type: 23
      version: 0x0303
      length: 44
      GenericAEADCipher
        CCMNonceExplicit
          seq_num
        CCMCipherText
          EAPTTLSAVP
            avp_code: 1
            avp_flags: 0xC0
            length: 28
            vendor_id: 36743
            network key: 16 bytes
        MAC: Using AES_CCM_8
    PANA TLS Change Cipher Spec, Finish, Network key is = received by PANA Client 
    PANA
  rsvd: 0
  length: 134
  flags: 0x8000
  type: 2
  session_id: paa_session_id
  seq_no: paa_seq_no + 4
PANAAVP
  code: 2
  flags: 0
  length: 49
  rsvd: 0
  EAPReqUnfrag
    code: 1
    identifier: idseq + 3
    length: 112
    type: 21
    flags: 0x00
    TLSPlaintext
      type: 20
      version: 0x0303
      length: 1
      ChangeCipherSpec
        type: 1
    TLSPlaintext
      type: 22
      version: 0x0303
      length: 32
      GenericAEADCipher
        CCMNonceExplicit
          seq_num
        CCMCipherText
          Handshake
            msg_type: 20
            length: 12
            Finished
              verify_data: 12 bytes
        MAC: Using AES_CCM_8
    TLSPlaintext
      type: 23
      version: 0x0303
      length: 44
      GenericAEADCipher
        CCMNonceExplicit
          seq_num
        CCMCipherText
          EAPTTLSAVP
            avp_code: 1
            avp_flags: 0xC0
            length: 28
            vendor_id: 36743
            network key: 16 bytes
        MAC: Using AES_CCM_8
    PANA EAP Response is replied by PaC 
    PANA
  rsvd: 0
  length: 30
  flags: 0x0000
  type: 2
  session_id: paa_session_id
  seq_no: paa_seq_no + 4
PANAAVP
  code: 2
  flags: 0
  length: 6
  rsvd: 0
  nonce: 16 bytes
  EAPRespUnfrag
    code: 2
    identifier: idseq + 3
    length: 6
    type: 21
    flag: 0x20
  AVPPad: 2 bytes
    PANA EAP Response is forwarded by PANA relay = router 
    PANA
  rsvd: 0
  length: 30
  flags: 0x0000
  type: 2
  session_id: paa_session_id
  seq_no: paa_seq_no + 4
PANAAVP
  code: 2
  flags: 0
  length: 6
  rsvd: 0
  nonce: 16 bytes
  EAPRespUnfrag
    code: 2
    identifier: idseq + 3
    length: 6
    type: 21
    flag: 0x20
  AVPPad: 2 bytes
    PANA EAP Success is forwarded by PANA relay = router 
    PANA
  rsvd: 0
  length: 88
  flags: 0xA000
  type: 2
  session_id: paa_session_id
  seq_no: paa_seq_no + 5
PANAAVP
  code: 7
  flags: 0
  length: 4
  rsvd: 0
  result_code: 0
PANAAVP
  code: 2
  flags: 0
  length: 4
  rsvd: 0
  EAPSUCCESS
    code: 3
    identifier: idseq + 4
    length: 4
PANAAVP
  code: 4
  flags: 0
  length: 4
  rsvd: 0
  key_id: 0
PANAAVP
  code: 8
  flags: 0
  length: 4
  rsvd: 0
  sess_life: 0xFFFFFFFF
PANAAVP
  code: 1
  flags: 0
  length: 16
  rsvd: 0
  auth: 16 bytes
    PANA EAP Success is received by PANA Client 
    PANA
  rsvd: 0
  length: 88
  flags: 0xA000
  type: 2
  session_id: paa_session_id
  seq_no: paa_seq_no + 5
PANAAVP
  code: 7
  flags: 0
  length: 4
  rsvd: 0
  result_code: 0
PANAAVP
  code: 2
  flags: 0
  length: 4
  rsvd: 0
  EAPSUCCESS
    code: 3
    identifier: idseq + 4
    length: 4
PANAAVP
  code: 4
  flags: 0
  length: 4
  rsvd: 0
  key_id: 0
PANAAVP
  code: 8
  flags: 0
  length: 4
  rsvd: 0
  sess_life: 0xFFFFFFFF
PANAAVP
  code: 1
  flags: 0
  length: 16
  rsvd: 0
  auth: 16 bytes
    PANA Complete is replied by PaC 
    PANA
  rsvd: 0
  length: 54
  flags: 0x2000
  type: 2
  session_id: paa_session_id
  seq_no: paa_seq_no + 5
PANAAVP
  code: 4
  flags: 0
  length: 4
  rsvd: 0
  key_id: 0
PANAAVP
  code: 1
  flags: 0
  length: 16
  rsvd: 0
  auth: 16 bytes
    PANA Complete is forwarded by PANA relay router 
    PANA
  rsvd: 0
  length: 54
  flags: 0x2000
  type: 2
  session_id: paa_session_id
  seq_no: paa_seq_no + 5
PANAAVP
  code: 4
  flags: 0
  length: 4
  rsvd: 0
  key_id: 0
PANAAVP
  code: 1
  flags: 0
  length: 16
  rsvd: 0
  auth: 16 bytes
    Neighbor Solicitation (NS) is initiated to discovery = neighbor and validate (short) address 
    802.15.4
  source: Short address (tentative)
  dest: Short address (Derived from SLLAO in RA)
IP
  Hop limit: 255
  source: GP16 (tentative)
  dest: LL16 of parent router
  Target: LL16 of parent router
SLLAO: Short address
ARO: EUI-64, no IP address, status=3D0
    Duplicate Address Request (DAR) is initiated from = parent router 
    type	156
802.15.4
  source: Short address of parent router
  dest: Short address of next hop
IP
  Hop limit: [variable]
  source:	GP16 of parent router
  dest: GP16 of LBR
  Status: 0
  Registration lifetime: [variable]
  EUI-64: EUI-64 of registering node
  Registered Address: IP source of NS that contained ARO option
    Duplicate Address Confirmation (DAC) is forwarded to = parent router 
    type	157
802.15.4
  source: Short address of LBR
  dest: Short address of next hop
IP
  Hop limit: [variable]
  source: GP16 of LBR
  dest: GP16 of parent router
  Status: Draft-ietf-6lowpan-nd-14 Table 1
  Registration lifetime: [variable]
  EUI-64: EUI-64 of registering node
  Registered Address: Copied from the DAR
    Neighbor Advertisement (NA) is replied by parent = router 
    802.15.4
  source: Short address
  dest: Success? Short address : IEEE address
IP
  Hop limit: 255
  source: LL16 of parent router
  dest: Success ? GP16 : LL64
  Target: LL16 of parent router
ARO: EUI-64, no IP address, status
    DODAG Information Solicitation (DIS) is sent as = broadcast 
    IP
  source: LL16
  destination: FF02::1A
ICMPv6 DIS
  DIS Base
    2 bytes reserved
    No options
    2 bytes padding
    DODAG Information Object (DIO) is replied from all = routers within radio range 
    IP
  source: LL16
  dest: LL16 of DIS sender
ICMPv6 DIO=20
  DIO Base
    'G': 1 (grounded)
    MOP: binary 001
    PRF: 0
    DODAGID: GP16 of root
  Route Information Option
    Prefix Length: 64
    Route Lifetime: 0xFFFFFFFF
    Prefix: GP
  DODAG Configuration Option
    'A': 0
    DIOIntMIN  : 3
    DIOIntDoubl: 20
    DIORedun:    10
    MaxRankIncrease: 0
    MinHopRankIncrease: 256
  Prefix Information Option
    'R': 1
    Valid Lifetime: 0xFFFFFFFF
    Preferred Lifetime: 0xFFFFFFFF
    Prefix: GP16 of source
    DODAG Information Solicitation (DIS) is sent as = unicast to parent router 
    IP
  source: LL16
  destination: FF02::1A
ICMPv6 DIS
  DIS Base
    2 bytes reserved
    No options
    2 bytes padding
    DODAG Information Object (DIO) is replied from = parent router with prefix information 
    IP
  source: LL16
  dest: LL16 of DIS sender
ICMPv6 DIO=20
  DIO Base
    'G': 1 (grounded)
    MOP: binary 001
    PRF: 0
    DODAGID: GP16 of root
  Route Information Option
    Prefix Length: 64
    Route Lifetime: 0xFFFFFFFF
    Prefix: GP
  DODAG Configuration Option
    'A': 0
    DIOIntMIN  : 3
    DIOIntDoubl: 20
    DIORedun:    10
    MaxRankIncrease: 0
    MinHopRankIncrease: 256
  Prefix Information Option
    'R': 1
    Valid Lifetime: 0xFFFFFFFF
    Preferred Lifetime: 0xFFFFFFFF
    Prefix: GP16 of source
    Destination Advertisement Object (DAO) is initiated = to establish upward route 
    IP
  source: GP16
  dest: GP16 of root
ICMPv6 DAO
  DAO Base
    'K': 1
    'D': 0
  Target Option
    Prefix Length: 128
    Target Prefix: GP16
  Transit Option
    Path Control: 1
    Path Lifetime: 0xFFFFFFFF
    Parent Address: GP16 of parent
    Destination Advertisement Object (DAO) is forwarded = by parent router 
    IP
  source: GP16
  dest: GP16 of root
ICMPv6 DAO
  DAO Base
    'K': 1
    'D': 0
  Target Option
    Prefix Length: 128
    Target Prefix: GP16
  Transit Option
    Path Control: 1
    Path Lifetime: 0xFFFFFFFF
    Parent Address: GP16 of parent
    Destination Advertisement Object Acknowledgement = (DAO-ACK) is forwarded to parent router 
    IP
  source: GP16 of root
  dest: GP16
  Routing Extension Header RH4 (if hop>1)
    Compr: 14
    Addresses: list of MAC short addresses
ICMPV6 DAO-ACK
  'D': 0
    Destination Advertisement Object Acknowledgement = (DAO-ACK) is forwarded by parent router 
    IP
  source: GP16 of root
  dest: GP16
  Routing Extension Header RH4 (if hop>1)
    Compr: 14
    Addresses: list of MAC short addresses
ICMPV6 DAO-ACK
  'D': 0
    ICMP request is initiated to verify = communication 
    IP
  source: GP16=20
  dest: GP16
ICMPV6
  Type: 0x80
    ICMP request is forwarded by parent router 
    IP
  source: GP16=20
  dest: GP16
ICMPV6
  Type: 0x80
    ICMP reply is forwarded to parent router 
    IP
  source: GP16=20
  dest: GP16
ICMPV6
  Type: 0x81
    ICMP reply is replied by parent router 
    802.15.4
  source: Short address
  dest: Success? Short address : IEEE address
IP
  Hop limit: 255
  source: LL16 of parent router
  dest: Success ? GP16 : LL64
  Target: LL16 of parent router
ARO: EUI-64, no IP address, status

    Verification

  • All packets shall follow the formats = described.
  • Communication via ping shall succeed.

    •

    1.12 Router Join - 3 Hop, with = Authentication

    Initial Condition

    channel: 0x14 for all devices
    panId: 0x1AAA
    linkLocal: fe80::/64
    globalPrefix: fd01::/64
    CCM Parameters: MIC Length M =3D 8, Length length L =3D 3
    Test Pre-shared key (PSK) octet string: {0xcf, 0xce, 0xcd, 0xcc, 0xcb,=20 0xca, 0xc9, 0xc8, 0xc7, 0xc6, 0xc5, 0xc4, 0xc3, 0xc2, 0xc1, 0xc0}
    Test Network key octet string: {0xbf, 0xbe, 0xbd, 0xbc, 0xbb, 0xba, = 0xb9, 0xb8, 0xb7, 0xb6, 0xb5, 0xb4, 0xb3, 0xb2, 0xb1, 0xb0}
    Key length N =3D 16

    Topology

    Router             ParentRouter       RelayRouter  =
     BorderRouter

    |                |
|   --------->   | Beacon Request (broadcast)
|   <-----       | Beacon Response
|                |

    |                |
|   --------->   | RS (multicast)
|   <-----       | RA
|                |

    |                |
|   ------>      | PCI
|                |   ------>       | RLY(PCI)
|                |                 |   ------>       | RLY(PCI)
|                |                 |   <------       | RLY(PAR)
|                |   <------       | RLY(PAR)
|   <------      | PAR
|   ------>      | PAN
|                |   ------>       | RLY(PAN)
|                |                 |   ------>       | RLY(PAN)
|                |                 |   <------       | RLY(PAR EAP =
Request)
|                |   <------       | RLY(PAR EAP Request)
|   <------      | PAR EAP Request
|   ------>      | PAN EAP Response
|                |   ------>       | RLY(PAN EAP Response)
|                |                 |   ------>       | RLY(PAN EAP =
Response)
|                |                 |   <------       | RLY(PAR TLS =
Start)
|                |   <------       | RLY(PAR TLS Start)
|   <------      | PAR TLS Start
|   ------>      | PAN TLS Client Hello
|                |   ------>       | RLY(PAN TLS Client Hello)
|                |                 |   ------>       | RLY(PAN TLS =
Client Hello)
|                |                 |   <------       | RLY(PAR TLS =
Server Hello, Server Hello Done)
|                |   <------       | RLY(PAR TLS Server Hello, Server =
Hello Done)
|   <------      | PAR TLS Server Hello, Server Hello Done
|   ------>      | PAN TLS Client Key Exchange, Change Cipher Spec, =
Finished
|                |   ------>       | RLY(PAN TLS Client Key Exchange, =
Change Cipher Spec, Finished)
|                |                 |   ------>       | RLY(PAN TLS =
Client Key Exchange, Change Cipher Spec, Finished)
|                |                 |   <------       | RLY(PAR TLS =
Change Cipher Spec, Finish, Network key)
|                |   <------       | RLY(PAR TLS Change Cipher Spec, =
Finish, Network key)
|   <------      | PAR TLS Change Cipher Spec, Finish, Network key
|   ------>      | PAN EAP Response
|                |   ------>       | RLY(PAN EAP Response)
|                |                 |   ------>       | RLY(PAN EAP =
Response)
|                |                 |   <------       | RLY(PAR EAP =
Success)
|                |   <------       | RLY(PAR EAP Success)
|   <------      | PAR EAP Success
|   ------>      | PAN Complete
|                |   ------>       | RLY(PAN Complete)
|                |                 |   ------>       | RLY(PAN =
Complete)
|                |

    |                |
|   ------>      | NS
|                |   ------>       | DAR
|                |                 |   ------>       | DAR
|                |                 |   <------       | DAC
|                |   <------       | DAC
|   <------      | NA
|                |

    |                |
|   --------->   | DIS (broadcast)
|   <-----       | DIO (from all routers in radio range)
|   ------>      | DIS (unicast)
|   <-----       | DIO (with prefix information)
|                |

    |                |
|   ------>      | DAO
|                |   ------>       | DAO
|                |                 |   ------>       | DAO
|                |                 |   <------       | DAO-ACK
|                |   <------       | DAO-ACK
|   <------      | DAO-ACK
|                |

    |                |
|   ------>      | ICMP Request
|                |   ------>       | ICMP Request
|                |                 |   ------>       | ICMP Request
|                |                 |   <------       | ICMP Reply
|                |   <------       | ICMP Reply
|   <------      | ICMP Reply
|                |

    Sub Test Cases

    A: Router =3D DUT
    B: Parent Router =3D DUT
    C: Relay Router =3D DUT
    D: Border Router =3D DUT

    Test Procedure

    Beacon request is sent to initiate active scan 
    802.15.4
  FrameControl: 0x0803
    FrameType: 0x03
    SecurityEnable: false
    FramePending: false
    AckRequired: false
    IntraPan: false
    Dest Addr Mode: 0x02
    Src Addr Mode: 0x00
  Dest PanId: 0xffff
  Short Dest Addr: 0xffff
802.15.4 command: 0x07
    Beacon response is replied from all routers within = radio range 
    802.15.4
  FrameControl: 0x8000
    FrameType: 0x00
    SecurityEnable: false
    FramePending: false
    AckRequired: false
    IntraPan: false
    Dest Addr Mode: 0x00
    Src Addr Mode: 0x02
  Source PanId: [variable]
  Short Source Addr: [variable]
Beacon Payload
  Protocal ID: 0x02
  Control Field
    Bit 0: Allow Join
    Bit 1-7: Reserved
  NetworkID
  AppInfo
    Router Solicitation (RS) is sent as muticast to = discovery routers within range 
    802.15.4
  source: IEEE address
  dest: Broadcast
IP
  Hop limit: 255
  source: LL64
  dest: All-routers multicast
SLLAO: IEEE address
    Router Advertisement (RA) is replied from all = routers within radio range, containing prefix and context = information 
    802.15.4
  source: Short address
  dest: IEEE address
IP
  Hop limit: 255
  source: LL16
  dest: LL64
SLLAO: Short address
PIO: PAN-wide prefix (GP)
ABRO: 6LBR (GP16)
6CO: Context 0 (i.e. GP)
    PANA-Client-Initiation (PCI) is initiated by PANA = Client (PaC) to establish the authentication 
    PANA
  rsvd: 0
  length: 16
  flags: 0x0000
  type: 1
  session_id: 0
  seq_no: 0
    PANA-Client-Initiation (PCI) is forwarded by PANA = relay router 
    PANA
  rsvd: 0
  length: 16
  flags: 0x0000
  type: 1
  session_id: 0
  seq_no: 0
    PANA-Client-Initiation (PCI) is forwarded to PANA = Authentication Agent (PAA) 
    PANA
  rsvd: 0
  length: 16
  flags: 0x0000
  type: 1
  session_id: 0
  seq_no: 0
    PANA-Auth-Request (PAR) is responded by PANA = Authentication Agent (PAA) 
    PANA
  rsvd: 0
  length: 40
  flags: 0xC000
  type: 2
  session_id: paa_session_id
  seq_no: paa_seq_no
If PRF_HMAC_SHA2_256 is the only PRF, the following AVP may be optional
PANAAVP
  code: 6
  flags: 0
  length: 4
  rsvd: 0
  prf_algorithm: 5
If AUTH_HMAC_SHA2_256_128 is the only integrity algorithm, the following =
AVP may be optional
PANAAVP
  code: 3
  flags: 0
  length: 4
  rsvd: 0
  integrity_algorithm: 12
    PANA-Auth-Request (PAR) is forwarded by PANA relay = router 
    PANA
  rsvd: 0
  length: 40
  flags: 0xC000
  type: 2
  session_id: paa_session_id
  seq_no: paa_seq_no
If PRF_HMAC_SHA2_256 is the only PRF, the following AVP may be optional
PANAAVP
  code: 6
  flags: 0
  length: 4
  rsvd: 0
  prf_algorithm: 5
If AUTH_HMAC_SHA2_256_128 is the only integrity algorithm, the following =
AVP may be optional
PANAAVP
  code: 3
  flags: 0
  length: 4
  rsvd: 0
  integrity_algorithm: 12
    PANA-Auth-Request (PAR) is received by PANA = Client 
    PANA
  rsvd: 0
  length: 40
  flags: 0xC000
  type: 2
  session_id: paa_session_id
  seq_no: paa_seq_no
If PRF_HMAC_SHA2_256 is the only PRF, the following AVP may be optional
PANAAVP
  code: 6
  flags: 0
  length: 4
  rsvd: 0
  prf_algorithm: 5
If AUTH_HMAC_SHA2_256_128 is the only integrity algorithm, the following =
AVP may be optional
PANAAVP
  code: 3
  flags: 0
  length: 4
  rsvd: 0
  integrity_algorithm: 12
    PANA-Auth-Answer (PAN) is replied by PaC 
    PANA
  rsvd: 0
  length: 40
  flags: 0x4000
  type: 2
  session_id: paa_session_id
  seq_no: paa_seq_no
If PRF_HMAC_SHA2_256 is the only PRF, the following AVP may be optional
PANAAVP
  code: 6
  flags: 0
  length: 4
  rsvd: 0
  prf_algorithm: 5
If AUTH_HMAC_SHA2_256_128 is the only integrity algorithm, the following =
AVP may be optional
PANAAVP
  code: 3
  flags: 0
  length: 4
  rsvd: 0
  integrity_algorithm: 12
    PANA-Auth-Answer (PAN) is forwarded by PANA relay = router 
    PANA
  rsvd: 0
  length: 40
  flags: 0x4000
  type: 2
  session_id: paa_session_id
  seq_no: paa_seq_no
If PRF_HMAC_SHA2_256 is the only PRF, the following AVP may be optional
PANAAVP
  code: 6
  flags: 0
  length: 4
  rsvd: 0
  prf_algorithm: 5
If AUTH_HMAC_SHA2_256_128 is the only integrity algorithm, the following =
AVP may be optional
PANAAVP
  code: 3
  flags: 0
  length: 4
  rsvd: 0
  integrity_algorithm: 12
    PANA-Auth-Answer (PAN) is forwarded to PAA 
    PANA
  rsvd: 0
  length: 40
  flags: 0x4000
  type: 2
  session_id: paa_session_id
  seq_no: paa_seq_no
If PRF_HMAC_SHA2_256 is the only PRF, the following AVP may be optional
PANAAVP
  code: 6
  flags: 0
  length: 4
  rsvd: 0
  prf_algorithm: 5
If AUTH_HMAC_SHA2_256_128 is the only integrity algorithm, the following =
AVP may be optional
PANAAVP
  code: 3
  flags: 0
  length: 4
  rsvd: 0
  integrity_algorithm: 12
    PANA EAP Request is responded by PAA 
    PANA
  rsvd: 0
  length: 56
  flags: 0x8000
  type: 2
  session_id: paa_session_id
  seq_no: paa_seq_no + 1
PANAAVP
  code: 5
  flags: 0
  length: 16
  rsvd: 0
  nonce: 16 bytes
PANAAVP - optional
  code: 2
  flags: 0
  length: 5
  rsvd: 0
  EAPReqUnfrag
    code: 1
    identifier: idseq
    length: 5
    type: 1
  AVPPad: 3 bytes
    PANA EAP Request is forwarded by PANA relay = router 
    PANA
  rsvd: 0
  length: 56
  flags: 0x8000
  type: 2
  session_id: paa_session_id
  seq_no: paa_seq_no + 1
PANAAVP
  code: 5
  flags: 0
  length: 16
  rsvd: 0
  nonce: 16 bytes
PANAAVP - optional
  code: 2
  flags: 0
  length: 5
  rsvd: 0
  EAPReqUnfrag
    code: 1
    identifier: idseq
    length: 5
    type: 1
  AVPPad: 3 bytes
    PANA EAP Request is received by PANA Client 
    PANA
  rsvd: 0
  length: 56
  flags: 0x8000
  type: 2
  session_id: paa_session_id
  seq_no: paa_seq_no + 1
PANAAVP
  code: 5
  flags: 0
  length: 16
  rsvd: 0
  nonce: 16 bytes
PANAAVP - optional
  code: 2
  flags: 0
  length: 5
  rsvd: 0
  EAPReqUnfrag
    code: 1
    identifier: idseq
    length: 5
    type: 1
  AVPPad: 3 bytes
    PANA EAP Response is replied by PaC 
    PANA
  rsvd: 0
  length: 64
  flags: 0x0000
  type: 2
  session_id: paa_session_id
  seq_no: paa_seq_no + 1
PANAAVP
  code: 5
  flags: 0
  length: 16
  rsvd: 0
  nonce: 16 bytes
PANAAVP - optional
  code: 2
  flags: 0
  length: 14
  rsvd: 0
  EAPRespUnfrag
    code: 2
    identifier: idseq
    length: 14
    type: 1
    identity: "anonymous"
  AVPPad: 2 bytes
    PANA EAP Response is forwarded by PANA relay = router 
    PANA
  rsvd: 0
  length: 64
  flags: 0x0000
  type: 2
  session_id: paa_session_id
  seq_no: paa_seq_no + 1
PANAAVP
  code: 5
  flags: 0
  length: 16
  rsvd: 0
  nonce: 16 bytes
PANAAVP - optional
  code: 2
  flags: 0
  length: 14
  rsvd: 0
  EAPRespUnfrag
    code: 2
    identifier: idseq
    length: 14
    type: 1
    identity: "anonymous"
  AVPPad: 2 bytes
    PANA EAP Response is forwarded to PAA 
    PANA
  rsvd: 0
  length: 64
  flags: 0x0000
  type: 2
  session_id: paa_session_id
  seq_no: paa_seq_no + 1
PANAAVP
  code: 5
  flags: 0
  length: 16
  rsvd: 0
  nonce: 16 bytes
PANAAVP - optional
  code: 2
  flags: 0
  length: 14
  rsvd: 0
  EAPRespUnfrag
    code: 2
    identifier: idseq
    length: 14
    type: 1
    identity: "anonymous"
  AVPPad: 2 bytes
    PANA TLS Start is responded by PAA 
    PANA
  rsvd: 0
  length: 32
  flags: 0x8000
  type: 2
  session_id: paa_session_id
  seq_no: paa_seq_no + 2
PANAAVP
  code: 2
  flags: 0
  length: 6
  rsvd: 0
  EAPReqUnfrag
    code: 1
    identifier: idseq + 1
    length: 6
    type: 21
    flags: 0x20
  AVPPad: 2 bytes
    PANA TLS Start is forwarded by PANA relay router 
    PANA
  rsvd: 0
  length: 32
  flags: 0x8000
  type: 2
  session_id: paa_session_id
  seq_no: paa_seq_no + 2
PANAAVP
  code: 2
  flags: 0
  length: 6
  rsvd: 0
  EAPReqUnfrag
    code: 1
    identifier: idseq + 1
    length: 6
    type: 21
    flags: 0x20
  AVPPad: 2 bytes
    PANA TLS Start is received by PANA Client 
    PANA
  rsvd: 0
  length: 32
  flags: 0x8000
  type: 2
  session_id: paa_session_id
  seq_no: paa_seq_no + 2
PANAAVP
  code: 2
  flags: 0
  length: 6
  rsvd: 0
  EAPReqUnfrag
    code: 1
    identifier: idseq + 1
    length: 6
    type: 21
    flags: 0x20
  AVPPad: 2 bytes
    PANA TLS Client Hello is replied by PaC 
    PANA
  rsvd: 0
  length: 80
  flags: 0x0000
  type: 2
  session_id: paa_session_id
  seq_no: paa_seq_no + 2
PANAAVP
  code: 2
  flags: 0
  length: 56
  rsvd: 0
  EAPRespUnfrag
    code: 2
    identifier: idseq + 1
    length: 56
    type: 21
    flags: 0x00
    TLSPlaintext
      type: 22
      version: 0x0303
      length: 45
      Handshake
        msg_type: 1
        length: 41
        ClientHello
          ProtocolVersion
            major: 0x03
            minor: 0x03
          Random
            gmt_unix_time
            random_bytes: 28 bytes
          SessionID<0..32>
            length: 0 (NULL)
          <2..2^16-2>
            length: 2
            CipherSuite=20
              bytes: {0x00, 0xC6}
          <1..2^8-2>
            length: 1
            compression_methods: {0}
          NOTE: extensions will be needed for public key cipher suite
            No extensions=20
    PANA TLS Client Hello is forwarded by PANA relay = router 
    PANA
  rsvd: 0
  length: 80
  flags: 0x0000
  type: 2
  session_id: paa_session_id
  seq_no: paa_seq_no + 2
PANAAVP
  code: 2
  flags: 0
  length: 56
  rsvd: 0
  EAPRespUnfrag
    code: 2
    identifier: idseq + 1
    length: 56
    type: 21
    flags: 0x00
    TLSPlaintext
      type: 22
      version: 0x0303
      length: 45
      Handshake
        msg_type: 1
        length: 41
        ClientHello
          ProtocolVersion
            major: 0x03
            minor: 0x03
          Random
            gmt_unix_time
            random_bytes: 28 bytes
          SessionID<0..32>
            length: 0 (NULL)
          <2..2^16-2>
            length: 2
            CipherSuite=20
              bytes: {0x00, 0xC6}
          <1..2^8-2>
            length: 1
            compression_methods: {0}
          NOTE: extensions will be needed for public key cipher suite
            No extensions=20
    PANA TLS Client Hello is forwarded to PAA 
    PANA
  rsvd: 0
  length: 80
  flags: 0x0000
  type: 2
  session_id: paa_session_id
  seq_no: paa_seq_no + 2
PANAAVP
  code: 2
  flags: 0
  length: 56
  rsvd: 0
  EAPRespUnfrag
    code: 2
    identifier: idseq + 1
    length: 56
    type: 21
    flags: 0x00
    TLSPlaintext
      type: 22
      version: 0x0303
      length: 45
      Handshake
        msg_type: 1
        length: 41
        ClientHello
          ProtocolVersion
            major: 0x03
            minor: 0x03
          Random
            gmt_unix_time
            random_bytes: 28 bytes
          SessionID<0..32>
            length: 0 (NULL)
          <2..2^16-2>
            length: 2
            CipherSuite=20
              bytes: {0x00, 0xC6}
          <1..2^8-2>
            length: 1
            compression_methods: {0}
          NOTE: extensions will be needed for public key cipher suite
            No extensions=20
    PANA TLS Server Hello, Server Hello Done is = responded by PAA 
    PANA
  rsvd: 0
  length: 88
  flags: 0x8000
  type: 2
  session_id: paa_session_id
  seq_no: paa_seq_no + 3
PANAAVP
  code: 2
  flags: 0
  length: 61
  rsvd: 0
  EAPReqUnfrag
    code: 1
    identifier: idseq + 2
    length: 61
    type: 21
    flags: 0x00
    TLSPlaintext
      type: 22
      version: 0x0303
      length: 50
      Handshake
        msg_type: 2
        length: 42
        ServerHello
          ProtocolVersion
            major: 0x03
            minor: 0x03
          Random
            gmt_unix_time
            random_bytes: 28 bytes
          SessionID<0..32>
            length: 4
            bytes: 4
            CipherSuite=20
              bytes: {0x00, 0xC6}
            compression_methods: {0}
          NOTE: extensions will be needed for public key cipher suite
            No extensions=20
      Handshake
        msg_type: 14
        length: 0
        ServerHelloDone: Empty
  AVPPad: 3 bytes
    PANA TLS Server Hello, Server Hello Done is = forwarded by PANA relay router 
    PANA
  rsvd: 0
  length: 88
  flags: 0x8000
  type: 2
  session_id: paa_session_id
  seq_no: paa_seq_no + 3
PANAAVP
  code: 2
  flags: 0
  length: 61
  rsvd: 0
  EAPReqUnfrag
    code: 1
    identifier: idseq + 2
    length: 61
    type: 21
    flags: 0x00
    TLSPlaintext
      type: 22
      version: 0x0303
      length: 50
      Handshake
        msg_type: 2
        length: 42
        ServerHello
          ProtocolVersion
            major: 0x03
            minor: 0x03
          Random
            gmt_unix_time
            random_bytes: 28 bytes
          SessionID<0..32>
            length: 4
            bytes: 4
            CipherSuite=20
              bytes: {0x00, 0xC6}
            compression_methods: {0}
          NOTE: extensions will be needed for public key cipher suite
            No extensions=20
      Handshake
        msg_type: 14
        length: 0
        ServerHelloDone: Empty
  AVPPad: 3 bytes
    PANA TLS Server Hello, Server Hello Done is received = by PANA Client 
    PANA
  rsvd: 0
  length: 88
  flags: 0x8000
  type: 2
  session_id: paa_session_id
  seq_no: paa_seq_no + 3
PANAAVP
  code: 2
  flags: 0
  length: 61
  rsvd: 0
  EAPReqUnfrag
    code: 1
    identifier: idseq + 2
    length: 61
    type: 21
    flags: 0x00
    TLSPlaintext
      type: 22
      version: 0x0303
      length: 50
      Handshake
        msg_type: 2
        length: 42
        ServerHello
          ProtocolVersion
            major: 0x03
            minor: 0x03
          Random
            gmt_unix_time
            random_bytes: 28 bytes
          SessionID<0..32>
            length: 4
            bytes: 4
            CipherSuite=20
              bytes: {0x00, 0xC6}
            compression_methods: {0}
          NOTE: extensions will be needed for public key cipher suite
            No extensions=20
      Handshake
        msg_type: 14
        length: 0
        ServerHelloDone: Empty
  AVPPad: 3 bytes
    PANA TLS Client Key Exchange, Change Cipher Spec, = Finished is replied by PaC 
    PANA
  rsvd: 0
  length: 88
  flags: 0x0000
  type: 2
  session_id: paa_session_id
  seq_no: paa_seq_no + 3
PANAAVP
  code: 2
  flags: 0
  length: 62
  rsvd: 0
  EAPRespUnfrag
    code: 2
    identifier: idseq + 2
    length: 62
    type: 21
    flags: 0x00
    TLSPlaintext
      type: 22
      version: 0x0303
      length: 4
      Handshake
        msg_type: 16
        length: 4
        ClientKeyExchange
          <0..2^16-1>
            length: 2
            bytes: {0x30, 0x00}
    TLSPlaintext
      type: 20
      version: 0x0303
      length: 1
      ChangeCipherSpec
        type: 1
    TLSPlaintext
      type: 22
      version: 0x0303
      length: 32
      GenericAEADCipher
        CCMNonceExplicit
          seq_num
        CCMCipherText
          Handshake
            msg_type: 20
            length: 12
            Finished
              verify_data: 12 bytes
        MAC: Using AES_CCM_8
  AVPPad: 2 bytes
    PANA TLS Client Key Exchange, Change Cipher Spec, = Finished is forwarded by PANA relay router 
    PANA
  rsvd: 0
  length: 88
  flags: 0x0000
  type: 2
  session_id: paa_session_id
  seq_no: paa_seq_no + 3
PANAAVP
  code: 2
  flags: 0
  length: 62
  rsvd: 0
  EAPRespUnfrag
    code: 2
    identifier: idseq + 2
    length: 62
    type: 21
    flags: 0x00
    TLSPlaintext
      type: 22
      version: 0x0303
      length: 4
      Handshake
        msg_type: 16
        length: 4
        ClientKeyExchange
          <0..2^16-1>
            length: 2
            bytes: {0x30, 0x00}
    TLSPlaintext
      type: 20
      version: 0x0303
      length: 1
      ChangeCipherSpec
        type: 1
    TLSPlaintext
      type: 22
      version: 0x0303
      length: 32
      GenericAEADCipher
        CCMNonceExplicit
          seq_num
        CCMCipherText
          Handshake
            msg_type: 20
            length: 12
            Finished
              verify_data: 12 bytes
        MAC: Using AES_CCM_8
  AVPPad: 2 bytes
    PANA TLS Client Key Exchange, Change Cipher Spec, = Finished is forwarded to PAA 
    PANA
  rsvd: 0
  length: 88
  flags: 0x0000
  type: 2
  session_id: paa_session_id
  seq_no: paa_seq_no + 3
PANAAVP
  code: 2
  flags: 0
  length: 62
  rsvd: 0
  EAPRespUnfrag
    code: 2
    identifier: idseq + 2
    length: 62
    type: 21
    flags: 0x00
    TLSPlaintext
      type: 22
      version: 0x0303
      length: 4
      Handshake
        msg_type: 16
        length: 4
        ClientKeyExchange
          <0..2^16-1>
            length: 2
            bytes: {0x30, 0x00}
    TLSPlaintext
      type: 20
      version: 0x0303
      length: 1
      ChangeCipherSpec
        type: 1
    TLSPlaintext
      type: 22
      version: 0x0303
      length: 32
      GenericAEADCipher
        CCMNonceExplicit
          seq_num
        CCMCipherText
          Handshake
            msg_type: 20
            length: 12
            Finished
              verify_data: 12 bytes
        MAC: Using AES_CCM_8
  AVPPad: 2 bytes
    PANA TLS Change Cipher Spec, Finish, Network key is = responded by PAA 
    PANA
  rsvd: 0
  length: 134
  flags: 0x8000
  type: 2
  session_id: paa_session_id
  seq_no: paa_seq_no + 4
PANAAVP
  code: 2
  flags: 0
  length: 49
  rsvd: 0
  EAPReqUnfrag
    code: 1
    identifier: idseq + 3
    length: 112
    type: 21
    flags: 0x00
    TLSPlaintext
      type: 20
      version: 0x0303
      length: 1
      ChangeCipherSpec
        type: 1
    TLSPlaintext
      type: 22
      version: 0x0303
      length: 32
      GenericAEADCipher
        CCMNonceExplicit
          seq_num
        CCMCipherText
          Handshake
            msg_type: 20
            length: 12
            Finished
              verify_data: 12 bytes
        MAC: Using AES_CCM_8
    TLSPlaintext
      type: 23
      version: 0x0303
      length: 44
      GenericAEADCipher
        CCMNonceExplicit
          seq_num
        CCMCipherText
          EAPTTLSAVP
            avp_code: 1
            avp_flags: 0xC0
            length: 28
            vendor_id: 36743
            network key: 16 bytes
        MAC: Using AES_CCM_8
    PANA TLS Change Cipher Spec, Finish, Network key is = forwarded by PANA relay router 
    PANA
  rsvd: 0
  length: 134
  flags: 0x8000
  type: 2
  session_id: paa_session_id
  seq_no: paa_seq_no + 4
PANAAVP
  code: 2
  flags: 0
  length: 49
  rsvd: 0
  EAPReqUnfrag
    code: 1
    identifier: idseq + 3
    length: 112
    type: 21
    flags: 0x00
    TLSPlaintext
      type: 20
      version: 0x0303
      length: 1
      ChangeCipherSpec
        type: 1
    TLSPlaintext
      type: 22
      version: 0x0303
      length: 32
      GenericAEADCipher
        CCMNonceExplicit
          seq_num
        CCMCipherText
          Handshake
            msg_type: 20
            length: 12
            Finished
              verify_data: 12 bytes
        MAC: Using AES_CCM_8
    TLSPlaintext
      type: 23
      version: 0x0303
      length: 44
      GenericAEADCipher
        CCMNonceExplicit
          seq_num
        CCMCipherText
          EAPTTLSAVP
            avp_code: 1
            avp_flags: 0xC0
            length: 28
            vendor_id: 36743
            network key: 16 bytes
        MAC: Using AES_CCM_8
    PANA TLS Change Cipher Spec, Finish, Network key is = received by PANA Client 
    PANA
  rsvd: 0
  length: 134
  flags: 0x8000
  type: 2
  session_id: paa_session_id
  seq_no: paa_seq_no + 4
PANAAVP
  code: 2
  flags: 0
  length: 49
  rsvd: 0
  EAPReqUnfrag
    code: 1
    identifier: idseq + 3
    length: 112
    type: 21
    flags: 0x00
    TLSPlaintext
      type: 20
      version: 0x0303
      length: 1
      ChangeCipherSpec
        type: 1
    TLSPlaintext
      type: 22
      version: 0x0303
      length: 32
      GenericAEADCipher
        CCMNonceExplicit
          seq_num
        CCMCipherText
          Handshake
            msg_type: 20
            length: 12
            Finished
              verify_data: 12 bytes
        MAC: Using AES_CCM_8
    TLSPlaintext
      type: 23
      version: 0x0303
      length: 44
      GenericAEADCipher
        CCMNonceExplicit
          seq_num
        CCMCipherText
          EAPTTLSAVP
            avp_code: 1
            avp_flags: 0xC0
            length: 28
            vendor_id: 36743
            network key: 16 bytes
        MAC: Using AES_CCM_8
    PANA EAP Response is replied by PaC 
    PANA
  rsvd: 0
  length: 30
  flags: 0x0000
  type: 2
  session_id: paa_session_id
  seq_no: paa_seq_no + 4
PANAAVP
  code: 2
  flags: 0
  length: 6
  rsvd: 0
  nonce: 16 bytes
  EAPRespUnfrag
    code: 2
    identifier: idseq + 3
    length: 6
    type: 21
    flag: 0x20
  AVPPad: 2 bytes
    PANA EAP Response is forwarded by PANA relay = router 
    PANA
  rsvd: 0
  length: 30
  flags: 0x0000
  type: 2
  session_id: paa_session_id
  seq_no: paa_seq_no + 4
PANAAVP
  code: 2
  flags: 0
  length: 6
  rsvd: 0
  nonce: 16 bytes
  EAPRespUnfrag
    code: 2
    identifier: idseq + 3
    length: 6
    type: 21
    flag: 0x20
  AVPPad: 2 bytes
    PANA EAP Response is forwarded to PAA 
    PANA
  rsvd: 0
  length: 30
  flags: 0x0000
  type: 2
  session_id: paa_session_id
  seq_no: paa_seq_no + 4
PANAAVP
  code: 2
  flags: 0
  length: 6
  rsvd: 0
  nonce: 16 bytes
  EAPRespUnfrag
    code: 2
    identifier: idseq + 3
    length: 6
    type: 21
    flag: 0x20
  AVPPad: 2 bytes
    PANA EAP Success is responded by PAA 
    PANA
  rsvd: 0
  length: 88
  flags: 0xA000
  type: 2
  session_id: paa_session_id
  seq_no: paa_seq_no + 5
PANAAVP
  code: 7
  flags: 0
  length: 4
  rsvd: 0
  result_code: 0
PANAAVP
  code: 2
  flags: 0
  length: 4
  rsvd: 0
  EAPSUCCESS
    code: 3
    identifier: idseq + 4
    length: 4
PANAAVP
  code: 4
  flags: 0
  length: 4
  rsvd: 0
  key_id: 0
PANAAVP
  code: 8
  flags: 0
  length: 4
  rsvd: 0
  sess_life: 0xFFFFFFFF
PANAAVP
  code: 1
  flags: 0
  length: 16
  rsvd: 0
  auth: 16 bytes
    PANA EAP Success is forwarded by PANA relay = router 
    PANA
  rsvd: 0
  length: 88
  flags: 0xA000
  type: 2
  session_id: paa_session_id
  seq_no: paa_seq_no + 5
PANAAVP
  code: 7
  flags: 0
  length: 4
  rsvd: 0
  result_code: 0
PANAAVP
  code: 2
  flags: 0
  length: 4
  rsvd: 0
  EAPSUCCESS
    code: 3
    identifier: idseq + 4
    length: 4
PANAAVP
  code: 4
  flags: 0
  length: 4
  rsvd: 0
  key_id: 0
PANAAVP
  code: 8
  flags: 0
  length: 4
  rsvd: 0
  sess_life: 0xFFFFFFFF
PANAAVP
  code: 1
  flags: 0
  length: 16
  rsvd: 0
  auth: 16 bytes
    PANA EAP Success is received by PANA Client 
    PANA
  rsvd: 0
  length: 88
  flags: 0xA000
  type: 2
  session_id: paa_session_id
  seq_no: paa_seq_no + 5
PANAAVP
  code: 7
  flags: 0
  length: 4
  rsvd: 0
  result_code: 0
PANAAVP
  code: 2
  flags: 0
  length: 4
  rsvd: 0
  EAPSUCCESS
    code: 3
    identifier: idseq + 4
    length: 4
PANAAVP
  code: 4
  flags: 0
  length: 4
  rsvd: 0
  key_id: 0
PANAAVP
  code: 8
  flags: 0
  length: 4
  rsvd: 0
  sess_life: 0xFFFFFFFF
PANAAVP
  code: 1
  flags: 0
  length: 16
  rsvd: 0
  auth: 16 bytes
    PANA Complete is replied by PaC 
    PANA
  rsvd: 0
  length: 54
  flags: 0x2000
  type: 2
  session_id: paa_session_id
  seq_no: paa_seq_no + 5
PANAAVP
  code: 4
  flags: 0
  length: 4
  rsvd: 0
  key_id: 0
PANAAVP
  code: 1
  flags: 0
  length: 16
  rsvd: 0
  auth: 16 bytes
    PANA Complete is forwarded by PANA relay router 
    PANA
  rsvd: 0
  length: 54
  flags: 0x2000
  type: 2
  session_id: paa_session_id
  seq_no: paa_seq_no + 5
PANAAVP
  code: 4
  flags: 0
  length: 4
  rsvd: 0
  key_id: 0
PANAAVP
  code: 1
  flags: 0
  length: 16
  rsvd: 0
  auth: 16 bytes
    PANA Complete is forwarded to PAA 
    PANA
  rsvd: 0
  length: 54
  flags: 0x2000
  type: 2
  session_id: paa_session_id
  seq_no: paa_seq_no + 5
PANAAVP
  code: 4
  flags: 0
  length: 4
  rsvd: 0
  key_id: 0
PANAAVP
  code: 1
  flags: 0
  length: 16
  rsvd: 0
  auth: 16 bytes
    Neighbor Solicitation (NS) is initiated to discovery = neighbor and validate (short) address 
    802.15.4
  source: Short address (tentative)
  dest: Short address (Derived from SLLAO in RA)
IP
  Hop limit: 255
  source: GP16 (tentative)
  dest: LL16 of parent router
  Target: LL16 of parent router
SLLAO: Short address
ARO: EUI-64, no IP address, status=3D0
    Duplicate Address Request (DAR) is initiated from = parent router 
    type	156
802.15.4
  source: Short address of parent router
  dest: Short address of next hop
IP
  Hop limit: [variable]
  source:	GP16 of parent router
  dest: GP16 of LBR
  Status: 0
  Registration lifetime: [variable]
  EUI-64: EUI-64 of registering node
  Registered Address: IP source of NS that contained ARO option
    Duplicate Address Request (DAR) is forwarded by = relay router 
    type	156
802.15.4
  source: Short address of parent router
  dest: Short address of next hop
IP
  Hop limit: [variable]
  source:	GP16 of parent router
  dest: GP16 of LBR
  Status: 0
  Registration lifetime: [variable]
  EUI-64: EUI-64 of registering node
  Registered Address: IP source of NS that contained ARO option
    Duplicate Address Confirmation (DAC) is responded by = border router 
    type	157
802.15.4
  source: Short address of LBR
  dest: Short address of next hop
IP
  Hop limit: [variable]
  source: GP16 of LBR
  dest: GP16 of parent router
  Status: Draft-ietf-6lowpan-nd-14 Table 1
  Registration lifetime: [variable]
  EUI-64: EUI-64 of registering node
  Registered Address: Copied from the DAR
    Duplicate Address Confirmation (DAC) is forwarded to = parent router 
    type	157
802.15.4
  source: Short address of LBR
  dest: Short address of next hop
IP
  Hop limit: [variable]
  source: GP16 of LBR
  dest: GP16 of parent router
  Status: Draft-ietf-6lowpan-nd-14 Table 1
  Registration lifetime: [variable]
  EUI-64: EUI-64 of registering node
  Registered Address: Copied from the DAR
    Neighbor Advertisement (NA) is replied by parent = router 
    802.15.4
  source: Short address
  dest: Success? Short address : IEEE address
IP
  Hop limit: 255
  source: LL16 of parent router
  dest: Success ? GP16 : LL64
  Target: LL16 of parent router
ARO: EUI-64, no IP address, status
    DODAG Information Solicitation (DIS) is sent as = broadcast 
    IP
  source: LL16
  destination: FF02::1A
ICMPv6 DIS
  DIS Base
    2 bytes reserved
    No options
    2 bytes padding
    DODAG Information Object (DIO) is replied from all = routers within radio range 
    IP
  source: LL16
  dest: LL16 of DIS sender
ICMPv6 DIO=20
  DIO Base
    'G': 1 (grounded)
    MOP: binary 001
    PRF: 0
    DODAGID: GP16 of root
  Route Information Option
    Prefix Length: 64
    Route Lifetime: 0xFFFFFFFF
    Prefix: GP
  DODAG Configuration Option
    'A': 0
    DIOIntMIN  : 3
    DIOIntDoubl: 20
    DIORedun:    10
    MaxRankIncrease: 0
    MinHopRankIncrease: 256
  Prefix Information Option
    'R': 1
    Valid Lifetime: 0xFFFFFFFF
    Preferred Lifetime: 0xFFFFFFFF
    Prefix: GP16 of source
    DODAG Information Solicitation (DIS) is sent as = unicast to parent router 
    IP
  source: LL16
  destination: FF02::1A
ICMPv6 DIS
  DIS Base
    2 bytes reserved
    No options
    2 bytes padding
    DODAG Information Object (DIO) is replied from = parent router with prefix information 
    IP
  source: LL16
  dest: LL16 of DIS sender
ICMPv6 DIO=20
  DIO Base
    'G': 1 (grounded)
    MOP: binary 001
    PRF: 0
    DODAGID: GP16 of root
  Route Information Option
    Prefix Length: 64
    Route Lifetime: 0xFFFFFFFF
    Prefix: GP
  DODAG Configuration Option
    'A': 0
    DIOIntMIN  : 3
    DIOIntDoubl: 20
    DIORedun:    10
    MaxRankIncrease: 0
    MinHopRankIncrease: 256
  Prefix Information Option
    'R': 1
    Valid Lifetime: 0xFFFFFFFF
    Preferred Lifetime: 0xFFFFFFFF
    Prefix: GP16 of source
    Destination Advertisement Object (DAO) is initiated = to establish upward route 
    IP
  source: GP16
  dest: GP16 of root
ICMPv6 DAO
  DAO Base
    'K': 1
    'D': 0
  Target Option
    Prefix Length: 128
    Target Prefix: GP16
  Transit Option
    Path Control: 1
    Path Lifetime: 0xFFFFFFFF
    Parent Address: GP16 of parent
    Destination Advertisement Object (DAO) is forwarded = by parent router 
    IP
  source: GP16
  dest: GP16 of root
ICMPv6 DAO
  DAO Base
    'K': 1
    'D': 0
  Target Option
    Prefix Length: 128
    Target Prefix: GP16
  Transit Option
    Path Control: 1
    Path Lifetime: 0xFFFFFFFF
    Parent Address: GP16 of parent
    Destination Advertisement Object (DAO) is forwarded = by relay router 
    IP
  source: GP16
  dest: GP16 of root
ICMPv6 DAO
  DAO Base
    'K': 1
    'D': 0
  Target Option
    Prefix Length: 128
    Target Prefix: GP16
  Transit Option
    Path Control: 1
    Path Lifetime: 0xFFFFFFFF
    Parent Address: GP16 of parent
    Destination Advertisement Object Acknowledgement = (DAO-ACK) is responded by border router 
    IP
  source: GP16 of root
  dest: GP16
  Routing Extension Header RH4 (if hop>1)
    Compr: 14
    Addresses: list of MAC short addresses
ICMPV6 DAO-ACK
  'D': 0
    Destination Advertisement Object Acknowledgement = (DAO-ACK) is forwarded to parent router 
    IP
  source: GP16 of root
  dest: GP16
  Routing Extension Header RH4 (if hop>1)
    Compr: 14
    Addresses: list of MAC short addresses
ICMPV6 DAO-ACK
  'D': 0
    Destination Advertisement Object Acknowledgement = (DAO-ACK) is forwarded by parent router 
    IP
  source: GP16 of root
  dest: GP16
  Routing Extension Header RH4 (if hop>1)
    Compr: 14
    Addresses: list of MAC short addresses
ICMPV6 DAO-ACK
  'D': 0
    ICMP request is initiated to verify = communication 
    IP
  source: GP16=20
  dest: GP16
ICMPV6
  Type: 0x80
    ICMP request is forwarded by parent router 
    IP
  source: GP16=20
  dest: GP16
ICMPV6
  Type: 0x80
    ICMP request is forwarded by relay router 
    IP
  source: GP16=20
  dest: GP16
ICMPV6
  Type: 0x80
    ICMP reply is responded by border router 
    IP
  source: GP16=20
  dest: GP16
ICMPV6
  Type: 0x81
    ICMP reply is forwarded to parent router 
    IP
  source: GP16=20
  dest: GP16
ICMPV6
  Type: 0x81
    ICMP reply is replied by parent router 
    802.15.4
  source: Short address
  dest: Success? Short address : IEEE address
IP
  Hop limit: 255
  source: LL16 of parent router
  dest: Success ? GP16 : LL64
  Target: LL16 of parent router
ARO: EUI-64, no IP address, status

    Verification

  • All packets shall follow the formats = described.
  • Communication via ping shall succeed.

    • Frames

    Beacon request is sent to initiate active = scan 
    802.15.4
  FrameControl: 0x0803
    FrameType: 0x03
    SecurityEnable: false
    FramePending: false
    AckRequired: false
    IntraPan: false
    Dest Addr Mode: 0x02
    Src Addr Mode: 0x00
  Dest PanId: 0xffff
  Short Dest Addr: 0xffff
802.15.4 command: 0x07
    Beacon response is replied from all = routers within radio range 
    802.15.4
  FrameControl: 0x8000
    FrameType: 0x00
    SecurityEnable: false
    FramePending: false
    AckRequired: false
    IntraPan: false
    Dest Addr Mode: 0x00
    Src Addr Mode: 0x02
  Source PanId: [variable]
  Short Source Addr: [variable]
Beacon Payload
  Protocal ID: 0x02
  Control Field
    Bit 0: Allow Join
    Bit 1-7: Reserved
  NetworkID
  AppInfo
    Router Solicitation (RS) is = sent as muticast to discovery routers within range 
    802.15.4
  source: IEEE address
  dest: Broadcast
IP
  Hop limit: 255
  source: LL64
  dest: All-routers multicast
SLLAO: IEEE address
    Router Advertisement (RA) is = replied from all routers within radio range, containing prefix and = context information 
    802.15.4
  source: Short address
  dest: IEEE address
IP
  Hop limit: 255
  source: LL16
  dest: LL64
SLLAO: Short address
PIO: PAN-wide prefix (GP)
ABRO: 6LBR (GP16)
6CO: Context 0 (i.e. GP)
    ------=_NextPart_000_0095_01CBA73F.D5A59D10 Content-Type: application/vnd.openxmlformats-officedocument.spreadsheetml.sheet; name="106164r00ZB_IP-Stack-Interop-9-results.xlsx" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="106164r00ZB_IP-Stack-Interop-9-results.xlsx" UEsDBBQABgAIAAAAIQCM6YyMfgEAAIwFAAATANwBW0NvbnRlbnRfVHlwZXNdLnhtbCCi2AEooAAC AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAArFTJbsIwEL1X6j9EvlaJgUNVVQQOXY4tEvQDTDwQi8S2PAOFv+8kKahUaSQa Lomy+G1+4/F0XxbRDgIaZ1MxTAYiAps5bew6FR+L1/hBREjKalU4C6k4AIrp5PZmvDh4wIhXW0xF TuQfpcQsh1Jh4jxY/rJyoVTEj2Etvco2ag1yNBjcy8xZAksxVRhiMn6GldoWFL3s+XWjZGmsiJ6a /yqqVCjvC5MpYqFyZ/UvktitViYD7bJtydAJ+gBKYw5AZZH4YJgxzIGIjaGQk/E7mw5GQzRTgd5U yQxyX0hiB9Bchwl76CWiBrurUP4mRDoUgL2pzv02oEfmlngDFHiZte8NTHhlvQeYG48dDN3ZdWfy 6cJm6dzm2qlUbUhKZexRd1sJuEKz4DxKLlxvAVA1WoOOPUNCIAOnzNq4uYCV97q2KOvbqLeG82qc 8LsyaNHRfxr+pwNzFUDPiSd4ffUx+YndlcepE5kLcPmGHGenWt3SBFmfpZMvAAAA//8DAFBLAwQU AAYACAAAACEAtVUwI/UAAABMAgAACwDOAV9yZWxzLy5yZWxzIKLKASigAAIAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAjJLPTsMwDMbvSLxD5Pvq bkgIoaW7TEi7IVQewCTuH7WNoyRA9/aEA4JKY9vR9ufPP1ve7uZpVB8cYi9Ow7ooQbEzYnvXanit n1YPoGIiZ2kUxxqOHGFX3d5sX3iklJti1/uosouLGrqU/CNiNB1PFAvx7HKlkTBRymFo0ZMZqGXc lOU9hr8eUC081cFqCAd7B6o++jz5src0TW94L+Z9YpdOjECeEzvLduVDZgupz9uomkLLSYMV85zT Ecn7ImMDnibaXE/0/7Y4cSJLidBI4PM834pzQOvrgS6faKn4vc484qeE4U1k+GHBxQ9UXwAAAP// AwBQSwMEFAAGAAgAAAAhAEqppmH6AAAARwMAABoACAF4bC9fcmVscy93b3JrYm9vay54bWwucmVs cyCiBAEooAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAALySzWrEMAyE74W+g9G9cZL+UMo6 eymFvbbbBzCxEodNbGOpP3n7mpTuNrCkl9CjJDTzMcxm+zn04h0jdd4pKLIcBLram861Cl73T1f3 IIi1M7r3DhWMSLCtLi82z9hrTk9ku0AiqThSYJnDg5RUWxw0ZT6gS5fGx0FzGmMrg64PukVZ5vmd jL81oJppip1REHfmGsR+DMn5b23fNF2Nj75+G9DxGQvJiQuToI4tsoJp/F4WWQIFeZ6hXJPhw8cD WUQ+cRxXJKdLuQRT/DPMYjK3a8KQ1RHNC8dUPjqlM1svJXOzKgyPfer6sSs0zT/2clb/6gsAAP// AwBQSwMEFAAGAAgAAAAhANj/Vh9eAQAAUQIAAA8AAAB4bC93b3JrYm9vay54bWyMUsFuwjAMvU/a P0S5j5ZCASFapGmbxgVNE4NzaFwakSZVklL4+zmpGHDbKbH98uz3nMXyXEtyAmOFVhkdDmJKQBWa C3XI6M/m42VGiXVMcSa1goxewNJl/vy06LQ57rU+EiRQNqOVc808imxRQc3sQDegsFJqUzOHoTlE tjHAuK0AXC2jJI4nUc2Eoj3D3PyHQ5elKOBNF20NyvUkBiRzOL6tRGNpviiFhG2viLCmWbMa5z5L SiSz7p0LBzyjYwx1Bw8J0zavrZC+msYTGuV/Ir8M4VCyVroNyruyo1/JOEkC0luxFdDZ2yMfkvNO KK47D0VrLw9RF0o7wV2F9XQ4Sinpc58gDpXL6Gw6wVescOIEG7ZHlJ8qumsW7MSm4SQqaP0Gi5Na XJz3eoV6cIlmLvBiVjxQ3MPX2uFSb+DRHTgJ/a5NCiYLtMIfnnWYpNMkDYjrb8h/AQAA//8DAFBL AwQUAAYACAAAACEAmLJNWogCAAD8CQAADQAAAHhsL3N0eWxlcy54bWzcVltr2zAUfh/sPwi9r07S NHTDdikFw2Arg6awVzmWHYEuRpIze79+R7JjO23Setm6h70k50g+3/l0blJ4UwuOdlQbpmSE5xcz jKjcqIzJIsKP6+TDNUbGEpkRriSNcEMNvonfvwuNbTh92FJqEUBIE+GtteWnIDCbLRXEXKiSStjJ lRbEgqqLwJSaksw4I8GDxWy2CgRhEsdhrqQ1aKMqaSO86hbi0PxEO8KB1wwHcSiJoK1+qxnhbilw hq35uV9fT4FOwderZHIiGG9ahotn7A4g/PaR87wM0TOYH3K+I5ylmrnFUwA+UAb2Ged9oJcu0LAQ hyWxlmqZgII6ed2UkG8JWW+P4r975etCk2a+uJpuYBRnmWNR3CmuNGIyozXN9hlPny6vlh57RNfV wBRqpz35YD7zdOnrIjjmyTuEWKZKZ9A5+7KdwznapTjkNLeQDc2Krfu3qoTfVFmrBAgZI4WShIMY 7C06AWA3lPMH113f8wPsOkeyEomwnyE+0Keu9PciRKATW7xWcfhjtBZ7DOs4/z4uqvPewSnrSyDY sVpgNGbVWyNSlrxJ4BiQb9xpYOM0oH4KeflmyC6oxyP5hPMtZ4UUtCUeh9B+rYp+aFKuae0P5KJf 5292jjZef4XJKFcQgsm5Ot/38uNQvldTg35fiZTqxN8no4I5KJ/zKY0a6r9l9EJTQf/tSx+qYXIJ JF27/mkx/vuCgDePZRv3uIDhjI82rp+dMC1HI/lgIPejFbmbPML3rjQ5HmZFWjFumexn5TCMATOr h/HunzeWpPCicoO/9wJFmdGcVNyu+80ID/JXmrFKQDN1X31jO2U9RIQH+Yu7heYrf3MOz7b4FwAA AP//AwBQSwMEFAAGAAgAAAAhABPELBPCAAAAQgEAACMAAAB4bC93b3Jrc2hlZXRzL19yZWxzL3No ZWV0Mi54bWwucmVsc4SPwWrDMBBE74X8g9h7JDuHUIolX0oh1yb9AEVe26L2Smi3Jfn76NiEQo7D Y94wXX9ZF/WLhWMiC61uQCGFNESaLHydPravoFg8DX5JhBauyNC7zUv3iYuXWuI5ZlbVQmxhFslv xnCYcfWsU0aqZExl9VJjmUz24dtPaHZNszflrwPcnVMdBgvlMLSgTtdcl5+70zjGgO8p/KxI8s+E ySWSYDmiSD3IVe3LhGJB60f2mHf6HAmM68zdc3cDAAD//wMAUEsDBBQABgAIAAAAIQA7bTJLwQAA AEIBAAAjAAAAeGwvd29ya3NoZWV0cy9fcmVscy9zaGVldDEueG1sLnJlbHOEj8GKwjAURfcD/kN4 e5PWhQxDUzciuFXnA2L62gbbl5D3FP17sxxlwOXlcM/lNpv7PKkbZg6RLNS6AoXkYxdosPB72i2/ QbE46twUCS08kGHTLr6aA05OSonHkFgVC7GFUST9GMN+xNmxjgmpkD7m2UmJeTDJ+Ysb0Kyqam3y Xwe0L0617yzkfVeDOj1SWf7sjn0fPG6jv85I8s+ESTmQYD6iSDnIRe3ygGJB63f2nmt9DgSmbczL 8/YJAAD//wMAUEsDBBQABgAIAAAAIQAnBrk1agMAAH0KAAAYAAAAeGwvd29ya3NoZWV0cy9zaGVl dDIueG1sjFbJbtswEL0X6D8QvNfabCcxLAdZEDSHAkXTNmdGoiwikqhKtN38fWdIbZRkoxdbGg7f rG8029u/eUaOvKqFLELqLVxKeBHJWBT7kP76+fTlmpJasSJmmSx4SD94TW93nz9tT7J6r1POFQGE og5pqlS5cZw6SnnO6oUseQEniaxypuC12jt1WXEW60t55viuu3ZyJgpqEDbV/2DIJBERf5TRIeeF MiAVz5gC/+tUlDXdbWMBZxgQqXgS0jtvc+8H1Nlttenfgp/qwTNR7O2FZzxSPIYMUIKRvUn5jorP IHIBstYKCMkiJY78gWcZIvuQnT+NFR9NOJ2N4XNr70ln43tFYp6wQ6Z+yNNXLvapAsMrvB7JDHTh l+QC60FJzv4ar0SsUngKFv71ylut/RUW5iODmqwpiQ61kvlro9MgGQxwUWPA/6k5d4PuLjxduAun +i78N3eX64H96U3HBKCT8MgU220reSJQWYikLhn2ibfxIaERCu9RGlIduQOKnTamtdcmmJ8Ay6Bv 3eEp4ECrghwLftzdbJ0jJDxqgY3K1UAj8DoVyxSmojfVmkCpNoE10a4aCbChsxms5hGXFuLYeTy1 kY3E8nU5j4wln/qKUhvRSIaIyzOI0DoziCi1EY3kSnf4sFBgY3B/HCueapw+ad51F5rJq9EZ+uqf 8RUn0TR6lNq+GskQ0bvqjFq1v7EQx97jqY1sJEPkwJ1HxuYcODuG1sc2diMagvtnGsybJdOdFo9A DcEs0PUZjy9zTk+6EfiUZP6ZRHvzLNPiEajhmeXxGeZ6NtFa6mrxCLSlGA7oYfvC0L1Ypo5afQP7 fpe/ZoZN2Racy7FNt0lXTHnntcTrHQh6B+xYIGeXWg6PR2kxomGug6CLzgafJ583ZV8jmo4Kb4Zt N/1Q18favz5UfzwsGqWhx34/+i2PfZuB7RjX4pBO3fNnSXWvxbP6Nl86/JYU41aDDWRYnk6/7fdO 32wQ5uNZprB0KRHBxpDIQuE2Avjqo4SvfiEfZNFsbjiXS7bn31i1F0VNMp7AZ8pdXEFvVma/MC9K lpBjSt6kgn1BP6awk3H4GLsLUE6kVO1Lg/nC1aEkshKwb+k1K6SlrFTFhALwjQCfqufYQxcM1JPG ICwT++JVqLRxChcpDLJbHHf/AAAA//8DAFBLAwQUAAYACAAAACEA6aYluIIGAABTGwAAEwAAAHhs L3RoZW1lL3RoZW1lMS54bWzsWU9v2zYUvw/YdyB0b20nthsHdYrYsZutTRvEboceaZmWWFOiQNJJ fRva44ABw7phlwG77TBsK9ACu3SfJluHrQP6FfZISrIYy0vSBhvW1YdEIn98/9/jI3X12oOIoUMi JOVx26tdrnqIxD4f0zhoe3eG/UsbHpIKx2PMeEza3pxI79rW++9dxZsqJBFBsD6Wm7jthUolm5WK 9GEYy8s8ITHMTbiIsIJXEVTGAh8B3YhV1qrVZiXCNPZQjCMge3syoT5BQ03S28qI9xi8xkrqAZ+J gSZNnBUGO57WNELOZZcJdIhZ2wM+Y340JA+UhxiWCibaXtX8vMrW1QreTBcxtWJtYV3f/NJ16YLx dM3wFMEoZ1rr11tXdnL6BsDUMq7X63V7tZyeAWDfB02tLEWa9f5GrZPRLIDs4zLtbrVRrbv4Av31 JZlbnU6n0UplsUQNyD7Wl/Ab1WZ9e83BG5DFN5bw9c52t9t08AZk8c0lfP9Kq1l38QYUMhpPl9Da of1+Sj2HTDjbLYVvAHyjmsIXKIiGPLo0iwmP1apYi/B9LvoA0ECGFY2Rmidkgn2I4i6ORoJizQBv ElyYsUO+XBrSvJD0BU1U2/swwZARC3qvnn//6vlT9Or5k+OHz44f/nT86NHxwx8tLWfhLo6D4sKX 337259cfoz+efvPy8RfleFnE//rDJ7/8/Hk5EDJoIdGLL5/89uzJi68+/f27xyXwbYFHRfiQRkSi W+QIHfAIdDOGcSUnI3G+FcMQU2cFDoF2CemeCh3grTlmZbgOcY13V0DxKANen913ZB2EYqZoCecb YeQA9zhnHS5KDXBD8ypYeDiLg3LmYlbEHWB8WMa7i2PHtb1ZAlUzC0rH9t2QOGLuMxwrHJCYKKTn +JSQEu3uUerYdY/6gks+UegeRR1MS00ypCMnkBaLdmkEfpmX6Qyudmyzdxd1OCvTeoccukhICMxK hB8S5pjxOp4pHJWRHOKIFQ1+E6uwTMjBXPhFXE8q8HRAGEe9MZGybM1tAfoWnH4DQ70qdfsem0cu Uig6LaN5E3NeRO7waTfEUVKGHdA4LGI/kFMIUYz2uSqD73E3Q/Q7+AHHK919lxLH3acXgjs0cERa BIiemQntSyjUTv2NaPx3xZhRqMY2Bt4V47a3DVtTWUrsnijBq3D/wcK7g2fxPoFYX9543tXdd3XX e+vr7qpcPmu1XRRYqL26ebB9semSo5VN8oQyNlBzRm5K0ydL2CzGfRjU68wBkeSHpiSEx7S4O7hA YLMGCa4+oiochDiBHrvmaSKBTEkHEiVcwtnODJfS1njo05U9GTb0mcHWA4nVHh/b4XU9nB0NcjJm ywnM+TNjtK4JnJXZ+pWUKKj9OsxqWqgzc6sZ0Uypc7jlKoMPl1WDwdya0IUg6F3Ayk04omvWcDbB jIy13e0GnLnFeOEiXSRDPCapj7Teyz6qGSdlsWIuAyB2Snykz3mnWK3AraXJvgG3szipyK6+gl3m vTfxUhbBCy/pvD2RjiwuJieL0VHbazXWGh7ycdL2JnCshccoAa9L3fhhFsDdkK+EDftTk9lk+cKb rUwxNwlqcFNh7b6ksFMHEiHVDpahDQ0zlYYAizUnK/9aA8x6UQrYSH8NKdY3IBj+NSnAjq5ryWRC fFV0dmFE286+pqWUzxQRg3B8hEZsJg4wuF+HKugzphJuJ0xF0C9wlaatbabc4pwmXfECy+DsOGZJ iNNyq1M0y2QLN3mcy2DeCuKBbqWyG+XOr4pJ+QtSpRjG/zNV9H4C1wXrY+0BH25yBUY6X9seFyrk UIWSkPp9AY2DqR0QLXAdC9MQVHCfbP4Lcqj/25yzNExaw6lPHdAACQr7kQoFIftQlkz0nUKslu5d liRLCZmIKogrEyv2iBwSNtQ1sKn3dg+FEOqmmqRlwOBOxp/7nmbQKNBNTjHfnBqS7702B/7pzscm Myjl1mHT0GT2z0Us2VXterM823uLiuiJRZtVz7ICmBW2glaa9q8pwjm3WluxljRea2TCgReXNYbB vCFK4NIH6T+w/1HhM/txQm+oQ34AtRXBtwZNDMIGovqSbTyQLpB2cASNkx20waRJWdOmrZO2WrZZ X3Cnm/M9YWwt2Vn8fU5j582Zy87JxYs0dmphx9Z2bKWpwbMnUxSGJtlBxjjGfNUqfnjio/vg6B24 4p8xJU0wwWclgaH1HJg8gOS3HM3Srb8AAAD//wMAUEsDBBQABgAIAAAAIQDZYEAO1wUAAGkNAAAU AAAAeGwvc2hhcmVkU3RyaW5ncy54bWycV9tuGzcQfQ+QfxjoKQmsi9M0LRJbhmLZqdPEECIHQftG 7460rHfJDS+W9fc9w9UloYWirQHfhuRw5syZM9TJ2UNT0z07r6057R0PRj1iU9hSm+Vp78vNZf/X HvmgTKlqa/i0t2bfOxs/fXLifSCcNf60V4XQvhkOfVFxo/zAtmywsrCuUQH/uuXQt45V6Svm0NTD l6PR62GjtOlRYaMJuHf0ukfR6G+RzzvLq5974xOvxydhPDkZhvHJUP7pDO9yw3lumOaGi9xwmRve 54bfcsNVbvg8+5ib/tTLd8x0NaMrE9jZli7u2YQj+mg9TcySa/ZHNOWCm1t29Lp/fHxEL0fHo9zR bHI9oaLWOEx/WW3oGZFHUWqmCl6fH9yvYqhwQBcqoJzk2aGyOPm/D1IT66D/64V3vKbglPGtdSEL VDjzxreqAJdAihRib/x9tg7g6Hsm8ZIdHv+RG8LKgkPGcxGDHAq1pwps9ZW6Y2rYe7VkT41a0y3L TkCjDAcuCZgCLfKq6Y7hXuvK/AKJ7JCNHNdwCicvAc8/7/jpwI7W35EupVhhTaVFjMYGMozATKxr AnkabVIdc+efpCaF8jm04w/5zpuPc+KHwEa6myq0IOigu6scf4va4bpgBZpUC3BtBQJRFMLQbP47 FbqtIA5RB35LtzFQJF/ZWJdyRt2CjTiul8Y6Jh1IL9JPv3WXB1TZVZdsKvhkDi+VQtnSrTi/qT0K Jg439JdI2QePcikj/gv8kiLj9jP6yh1qEocp6lgipAo5BhyRLFChRQzRcR5LAl0YkOhaKUSPU1va ApgUmaJaLzhokOSMbsSx1AgbE2qFRYPtuSSeYluqINQrEKLXzeNrabUJOYEgPXtEF5MZfQLeyqxT 6gZAId3QBbcNSiLsahOE6Gf02UJFUDQNxmwulowkd/ItF1gJVcIjC+NwG16DLMQiWJ7kKzs0/sp8 R3ZBH1CA41/gGeDOKrZGPzx98uIFpYS6xkB5fow9bdhRlzAdVsrJmEkLzfR6TkPCz/58Ssl0cz6D 5ct01iVhbIkmsTF4tA1SYqrtqkUg6OaVdXfdIUgyLZSuUW/QxLPPUyjtDn6UsFCYWclZCh37U6ec 0TRtkxkV8J127MVVB3ST9NZ+f2KGVKeFV920NTdA8WD7Ro/QQRGUyLV13yEloNDfdKdtk3SXTi3C W8HXRgeytba2Sy2zI6xbNH9dr6FmTeuuuuKjGz0HYeXoYYRWFfjT+kXqFiyLnayT3yOMBEQh+Egd thtPabQVh6Jm5eh51/KC/IGu3+q0XNU6WwA7oS/dqzrmzXaYbnNh6E77hK96gckhtFdbKSi3Ir6l 8kaxvYiCKaA60ALb9m/XfRlTG/gqte3QUvsCPEOPwquwBqMZws1uQPNOyHQ4e0T0HyMrauUkMqgU PDhkCSD1UuQZ6KEfVDcn+yLKu3ibKE3IQAfL3SACMxouNYqP8glucGdIlemP3SZhEBrQ11raA3mb EmqAm4wNg5zPX8WD5GVielEgGs9LIZ+XYuLNBspg+bwjSyrOtpjwh8kYMGoEHHCKnukBD9L+bqPg aKzMOr5Xgjbcr1AfaATOlCUGOIDeaGfiGwxcPk/JITKc2I+LbkxgciB3Ka9u5XWTZ3SYKlD5jSOI ZwPoRGMVYttTE/yPLcmDAHAZEReS3oJoCNKq9rZTdNkR2+/Xc0wv07zYTZDNxdK3oka7R4VTiQ3d VCqaliD5dkATuQnQiq5sOFdE55Aqposu7jC1EKr0PCKrIWLbPFB3x2kANRhyDOUGyKFyeE+i+Isk BJhDuaQdBqwTx/5KxDI94hI380x/eKltRgurti/jJd8LBiVa5fbLaArRLFXjKZMtHo7tHu1kI4gj GphU+lEDXk+h/SLmz7ZamRTRP3747kcK3rnottSfKH33ioSI/auQdkMeH0LwEOhaamqnk/fyaFzo ZUS15RG1EZg9qzeyi883HhjIi6hrnf21Q3xUGv8NAAD//wMAUEsDBBQABgAIAAAAIQCigU5O5gYA AEUlAAAYAAAAeGwvd29ya3NoZWV0cy9zaGVldDEueG1sjJrbcuI4EIbvt2rfweX7BWwgpwqZqhjL lk+1tae59oATXAOYtZ1k5u1H8gEk/Q7WTQif/26p1bLpBj1++XHYG+9ZWeXFcWVak5lpZMdNsc2P ryvz33/IH3emUdXpcZvui2O2Mn9mlfnl6fffHj+K8nu1y7LaYB6O1crc1fXpYTqtNrvskFaT4pQd 2ZWXojykNXtbvk6rU5ml28bosJ/as9nN9JDmR7P18FDq+CheXvJNti42b4fsWLdOymyf1mz+1S4/ VebT4zZn13hARpm9rMxn+yGZ2+b06bEZ+r88+6iE/w0eybei+M4v0O3KnDEXVbbPNtynkbKX98zJ 9nvuac5W4//O65y7nJ59iv/3/kkT/Z+lsc1e0rd9/Vfx4Wf5665mS21Pbpfcw6bYMzn7axxyngLT OKQ/mtePfFvvVubdZGEvb+8se2kam7eqLg5f2wtWZ94a2p0he+0M5/cTazG74XZV/XPPssemf8UD u9oMzV47D/ZisrydzceGXnSGbK90htZscmvN7ucsxIERp23MzdKt0zp9eiyLD4Pln829OqV8N9kP FvPKF8peTpYsIxt+/ZkLViZzyi7wVL8/WbPH6Ttb+00ncVpJmxzm9uybr4Lom/lha90uR5unBjS5 WfLc9GNyw5XJZnMec6GO2UrYyGfJ/F6e1holihMXFZbsg6DClhUeKuaywkfFQlZQVCxlRYCKG1kR ouJWVkSouJMVMSrsSzBTMbU3cmr7ncAx3/P8JuO7Z60CVwVEBZ4KfBVQFQQqCFUQqSBWQSIAKdLb 4Ug5liJVgasCogJPBb4KqAoCFYQqiFQQqyARgBQp/9wRbtf+ZuS4eY6d7zRLuUucXnJOewvuhbvT UvarOy4h4xJvXOKPS+i4JGgll50djttE45J4XJIII0vpYqs7lC6OlXQpjyynl5zT1QL295JiNV3j EjIu8cYl/riEjkuCVnJJVzRuE49LEsGtlAuLFXEDyXAaLj0mgLhACBAPiA+EAgmAhEAiIDGQRCRy 2OzjfCDsZ4tzZRNePkiaTwbnrDnvwo6wNf58G2poiIbG09D4GhraaS4bLQASAomAxB25FnsiWslp UIq4/slt9YWZsKBKkeScNZc0tFbXpuKCFenINStPQ+NraCiMHgAJgURA4o5cm3MiWsmLzhuTgY9L i3N579tK3emcNZdFb62uTcUFK9KRa1aehsbX0FAYPQASAomAxEASkchLzDqAgSV2eJ/SLPFl+VTi goYA8YD4QCiQAEgIJAISA0lEIofNy/ChndWW52ynXJ6PSifhWKiZK1X+utNc2zWuhoZoaDwNja+h oZ1GfM72kfabIARNpOE51tAkomc5VbxrGEpV300IqVJaOsfqNX0A645cT0xrdU1DNPx4GhpfQ0M7 jZgYNa5Qw0+koYk1NIk4HzlVvO3BVDmW0A61PSsQFwgB4gHxgVAgAZAQSAQkBpKIRA6btw8Y9rPV txWXHbqAEg01c+VLhXXn59p+dM9j9TudaFh5GhpfQ0Nh9ABIqOEnAqtYwyoRreTEsCUbSIxjcS63 DCpxQUOAeEB8IBRIACQEEgGJgSQikcK2hzul54bLZdNC7VuHNMpXEetOc3U/amiIhsbT0PgaGqqh CTrN5TkbalhFGppYQ5OIo8vpHO4AHbvvAPtbfg3EBUKAeEB8IBRIACQEEgGJgSQikcMe7rgcu++4 LmGrxAUNAeIB8YFQIAGQEEgEJAaSiEQOe7jncZofaaRnFhAXCAHiAfGBUCABkBBIBCQGkohEDvuT PsRWu441EBcIAeIB8YFQIAGQEEgEJAaSiEQOe7gPcZpft+Rsq7W4CxoCxAPiA6FAAiAhkAhIDCQR iRw2r1+xYnJsta5dA3GBECAeEB8IBRIACYFEQGIgiUjksD+pj22oj4G4QAgQD4gPhAIJgIRAIiAx kEQkctjD9bFj97Xv5UmuEhc0BIgHxAdCgQRAQiARkBhIIhI57E+qT1utNddAXCAEiAfEB0KBBEBC IBGQGEgiEins+XD16TRceqQBcYEQIB4QHwgFEgAJgURAYiCJSOSwP6nS5lClAXGBECAeEB8IBRIA CYFEQGIgiUjksD+p0tjRFKXFAuICIUA8ID4QCiQAEgKJgMRA+AGbcxRt2O3JmPZ4x2nHDg/V+Yad hHkpjjU/ZcP09c8TO5NyLJzi2J1A4j/Vn9LXLE7L1/xYGfvshX27yM6SsI/0sj03076pi1NzWuNb UbPzMO3BDXa2KGO/8s/YcRE2SlH3bzqff2f128koypydG2qOC63MU1HWZZrXzPlDzuZU0m1zpmbX uCKNDyPd56/Hr3m96ybFDwgxl9PzAainXwAAAP//AwBQSwMEFAAGAAgAAAAhAKdoyeVvBgAATDYA ACcAAAB4bC9wcmludGVyU2V0dGluZ3MvcHJpbnRlclNldHRpbmdzMi5iaW7sWk+P20QUf9uWqkJC XeCCxCUSAiRUqmTZXRYWgbyO02SbP26c3a5gUTRrTxJTx2PZ4262p3KoEF8B9RPAF0Di0iMfoEcQ EifoiSO35b2JZ+tN+k+CirbriWae33vjNzO/92Y89mQXdiEBARHE4EMIEvkmOFDFbEIZluDRaeEM nP0FohXnEE4twALce1mc85Cehx3F75w6jQaawNGyxDJ+tLkn0i5ktYieomstyOSa2N3G9u9lzf13 9A1lavFd+gFQztLZu+f05SwlFCjdvrAIu5dPw8g8MxVgSbjNpj9vnfkxj/2D6tA9+s5DOJw1ccTT vfd/R+Li4nlE4CyA0+ptUtcX4a+X6mBDCecXw1lMs2tTzbQSrEEFVnD+lnAek9zHMkHORh6gk8oo lRt+CEYqBTiSRQFvCpdJX4TQFiEHI5A8DpnkTS7xqs6ZBzUWJBzqts0iHjv+DW40W6YIExkzP5QJ WO3tfqUMm2azyxMRpMraarnsRT4JayyRqIBenHLiLW/Ie4LKqcgUQYANZs1sdvOmkatXbRZLnwWw 2a1XG9gsCwLuKa4zGCjaFnJeUbfRsohbwuPQ6rQ7Zr3baVn9Vqdq4WB2Ws2aH/CtBE2NInetslJO Lk7GAao2xZ7huiINpR8Oie9sGKbZ6yva7qGkE/s8lF0hsd+VtXLW9R6fSCPZCJh7TQ8GIbF65kj4 bjZYGr8rQjGmXk2BtWNE8UrKAl8eXIpFGoF9RdF+BWw25IQ4TN2h+C4fkrtQxDzsoAISGiF61gmE hPdwSDURj3sxO+ixvQAHzz2f9Q4i9C65vZqi1ydTd9ftqnC3Gs5WY+oLdHI4tFmSyBH2ZDjS0jYa rfqDQc2PE0mdyo+JImPIrYnLI3J9QrgiSJ/b1vL+GC+OaxshxtWAISDOSOwf181Vbop9K/QeIt7m 8ZwGTHGdxxgMHGMGUdK+mob4Mc4WMUWwBNsxAn8YjtGluutNh7puOw6Pr6Pvkn6VE2Wh56RRFPg8 wckjUwzq7hZFkzPGGK2ne/1OGPgh4T0MRSJ9VwoRzNciI9g6mpMIM/ooGQmhom3Wnh0LL3XlmIUY IPOGzBF3rw1E7MU+DjuNPAzI+Vqd2ONxknV8rsvkhjHHYqq5P+iOcifYcUiD7TuNan9peam/QfTD cr+OtLKyslTJjR/jkGc1Vz/Iaq6qmkurK1jPCikiu8ZVJ0JgaHqpVYGmapikYx6baSLFWK00WoUR iihEtLakscurTDK0ZLI9clabjSnWFP7TwHbQasAprnAeaxs5fcfzjilt9JPjxn4kddvZlDta9jab VugKmmuw1aut/R+Pj9sXABpbdv01eFU1v4Al7S2I6qT3GsTTc5/2Y1SLSsq0Z3qSHdl0NwdwmEt0 Pz6C/lUiG5Q0nXLzZQm+wB2pwMzhy3l1IXnBESj8/4I7+DHDM9S+lUHwmHqF+sVEYBmHZWdD08+K O3fuKImmmVoRqkPZywvV9c3P5kQ5gbatRedQgB8vjqUZ9piuYE4iAp+AASl+0xIwxrdviW/YLnx6 EoE40WOmdeFBmUDJy/Mg5dcSun4rq6vrzOrz8vPEZBXy17oOUS3XNK/r/vQKLONXSspFKhDQCNDz 7nQ+8LSioAUCBQInEgFaDi7htxf6/hLjHieAElhwXXEHuMtmcIASW72l0ckhnR8OTyRSxaAJAXrv ophpqb1wjDtjOlkeYGSUoIN0oORcRdEEd8v8GX2zr2Z7eornEmxlJ2sJrMM1GMH7sI8/idIuXEVZ E+dECc/KfZTROdsEOZoTAr7K6PrRefo6WgtVTY5o0dmcVO8OdDZHtTiiYqna21gu4fldGU/yZtM6 4hZhH/p4l4flDbQ4hD28myNHbyMh5iFyY8w0M9ehBw28I1A6A1sh9BPVqrY1RK1AKzTP+6oM8D6t nW9ptlcFXyBQIKARoDMWOjaxdkyredHasTLFAtKnnfV738Oo7iPRBeqMTjfhJl2SyISP8Z9A03Vs qJ7+YyhBDVeaQK0cu49d5Xdxza/hr4G2LPw3QgXtWbCjuCZcVNcaFWq1SM8uAvkgeXZ7WfTs6SPQ sA2z2r1adS4ZPdOwG2+u/1D7ZvkP6+u7v629fmX98lwP/O9+vfXO39a3b9/76PvFyc+2vVE3rK49 V68QFAgUCBQIFAgUCBQIFAgUCBQIFAgUCBQIPDcI/AMAAP//AwBQSwMEFAAGAAgAAAAhAN8vsdFV AwAAPDAAACcAAAB4bC9wcmludGVyU2V0dGluZ3MvcHJpbnRlclNldHRpbmdzMS5iaW7sWc1OU0EY PS1oiIkBdWPipolRN4hIMEFrNLW9QEON1yLQxJpapZRqoaRFAVe4IMZXMDyBvoCJmy5c+AAuNSau lCdwV883vdMOLX+JkgB3ZjLzzXfmm7kzZ37u3DtppFFBCQsoo4B5LFJPYBwxhij6MYCdXaAzeOwb Hl8ZryEYQAAbJ0pd05TdSCk9FexgBQnkWPMi4/LO1e0pN+BZiQxKWgMeroWbjE/+7Nfa/5NnVVU9 l8QDErT7rJqjNVMKC+LWe3uQHuvAbLSzDjAW3lrd77XOjyb3W9lIGV2yhlprFQ1dyjZ9A7aJQ8DA ei8Qn3BHT+OUaq2Mt8wlPe4C6rklaRlnWX+CSixBJuVeVmB99QI1w0n54wz/4qQOcVrWtfY4hIfc gUoMOTxqz7bIEWfAjv8RH+BduhdRZ5AsirvY2eyjycAgu+V6XdPvimq1qhAtvWwlxEbCtAmq9Ort NsgAdN0a6iLAw+om16JuyrOKHxm4iQhe8BumhDlkKQt4ilt+JMLXfZZ9YasgpJi4SZK5l0j6vGer bVrzTbxbFM/ATGsbkRrX0sxLfjqJwS6oYOI27W8G5H3XYU48f9Nhe28Z8D0Dsh2M8N+L/H8p84xT RAgOXipthafsLFaIuI0/xfK/OO971vxLgHx3yZy5q87CZZ6M5SZhhmfjEO5Rzig8p2bRMk/LuQP6 ZR/zzvQyn0OYYC9k/lcQxnPM4jKW6BepJzFFLME1EeLdSIGY3JksU5M1UcIzT4Yb9yeSyrHnjkIm GQ/wTqUfQ6ynyDuXJWS4goos+0Stt4yKW/9/NG0rXIUZvOJT8yyRo8+or5F5lstTm2OQO5ydSjTb JLU123TNKLW5TWIXZv+n2ZNZPnvBv1Pe9twysCUDcsci1yZOKuok+pyU41kFKPc76O++7aTZ4IA0 RrtVrEpSoChu8Oa3vo/luZtluZeEMMzVXuSeUmHebrt8mnv+MH2cdTm4Sp+mTCktgT6V1qzIU607 uAyYk+TgttK2bP8ZiLuRaCw5FRsfiTyIRtz4ufCH4TeDv5zXX38MnbkfHmtrQeHd97WLf5y3Fzau v+9Z/uK6d0YjTtJts7OAZcAyYBmwDFgGLAOWAcuAZcAyYBmwDBwaBv4CAAD//wMAUEsDBBQABgAI AAAAIQBYb1xaSwEAAFsCAAARAAgBZG9jUHJvcHMvY29yZS54bWwgogQBKKAAAQAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAB8ktFqgzAUhu8HewfJvcZo6dqgFrbSqxUG7djYXUhOW6lJJEln+/aL 2jlHxy7j/+fzO4dki7Osgk8wttQqRySKUQCKa1GqfY5et6twhgLrmBKs0gpydAGLFsX9XcZryrWB F6NrMK4EG3iSspTXOTo4V1OMLT+AZDbyDeXDnTaSOX80e1wzfmR7wEkcT7EExwRzDLfAsB6I6IoU fEDWJ1N1AMExVCBBOYtJRPBP14GR9s8LXTJqytJdaj/TVXfMFrwPh/bZlkOxaZqoSTsN70/w+/p5 040alqrdFQdUZIJTboA5bYoMjw9+cRWzbu13vCtBPF6KpVbBxp0MHDN8m3pSJ97jQARehfbi38lb +rTcrlBB5vNpSOKQTLZJStOUJrOP9ue/7rdq/Qd5VfiHmMQtLgmT+ZY8UDKjZDIifgP8hDfPofgC AAD//wMAUEsDBBQABgAIAAAAIQBlZDYbjAEAACwDAAAQAAgBZG9jUHJvcHMvYXBwLnhtbCCiBAEo oAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAJySTW/bMAyG7wP2HwzdG7nBMAyBrKJIN/Sw j2BJu7Mq07FQWRJExkj260fbyNd6GDCfSL4vXj+mqe72nS96yOhiqMTtrBQFBBtrF7aVeNp8ufkk CiQTauNjgEocAMWdfv9OrXJMkMkBFhwRsBItUVpIibaFzuCM5cBKE3NniNu8lbFpnIWHaHcdBJLz svwoYU8Qaqhv0ilQTImLnv43tI524MPnzSExsFb3KXlnDfFX6m/O5oixoeLz3oJX8lJUTLcGu8uO DrpU8rJVa2s8LDlYN8YjKHkeqEcww9JWxmXUqqdFD5ZiLtD95rXNRfFiEAacSvQmOxOIsQbb1Iy1 T0hZ/4r5FVsAQiXZMA3H8tJ7WbsPej4auLg2DgETCAvXiBtHHvBHszKZ/kU8Mky8E85PwJ2/Bjyh fo8Eb9HHbTDEX69dxi6ZcGDhVH114RWf0iY+GILjpq+Hat2aDDX/nKN+HqhHXnL2Q8iyNWEL9dHz Vhju4nk6fn07n5X8jOdwnCl5PnP9BwAA//8DAFBLAQItABQABgAIAAAAIQCM6YyMfgEAAIwFAAAT AAAAAAAAAAAAAAAAAAAAAABbQ29udGVudF9UeXBlc10ueG1sUEsBAi0AFAAGAAgAAAAhALVVMCP1 AAAATAIAAAsAAAAAAAAAAAAAAAAAiwMAAF9yZWxzLy5yZWxzUEsBAi0AFAAGAAgAAAAhAEqppmH6 AAAARwMAABoAAAAAAAAAAAAAAAAAdwYAAHhsL19yZWxzL3dvcmtib29rLnhtbC5yZWxzUEsBAi0A FAAGAAgAAAAhANj/Vh9eAQAAUQIAAA8AAAAAAAAAAAAAAAAAsQgAAHhsL3dvcmtib29rLnhtbFBL AQItABQABgAIAAAAIQCYsk1aiAIAAPwJAAANAAAAAAAAAAAAAAAAADwKAAB4bC9zdHlsZXMueG1s UEsBAi0AFAAGAAgAAAAhABPELBPCAAAAQgEAACMAAAAAAAAAAAAAAAAA7wwAAHhsL3dvcmtzaGVl dHMvX3JlbHMvc2hlZXQyLnhtbC5yZWxzUEsBAi0AFAAGAAgAAAAhADttMkvBAAAAQgEAACMAAAAA AAAAAAAAAAAA8g0AAHhsL3dvcmtzaGVldHMvX3JlbHMvc2hlZXQxLnhtbC5yZWxzUEsBAi0AFAAG AAgAAAAhACcGuTVqAwAAfQoAABgAAAAAAAAAAAAAAAAA9A4AAHhsL3dvcmtzaGVldHMvc2hlZXQy LnhtbFBLAQItABQABgAIAAAAIQDppiW4ggYAAFMbAAATAAAAAAAAAAAAAAAAAJQSAAB4bC90aGVt ZS90aGVtZTEueG1sUEsBAi0AFAAGAAgAAAAhANlgQA7XBQAAaQ0AABQAAAAAAAAAAAAAAAAARxkA AHhsL3NoYXJlZFN0cmluZ3MueG1sUEsBAi0AFAAGAAgAAAAhAKKBTk7mBgAARSUAABgAAAAAAAAA AAAAAAAAUB8AAHhsL3dvcmtzaGVldHMvc2hlZXQxLnhtbFBLAQItABQABgAIAAAAIQCnaMnlbwYA AEw2AAAnAAAAAAAAAAAAAAAAAGwmAAB4bC9wcmludGVyU2V0dGluZ3MvcHJpbnRlclNldHRpbmdz Mi5iaW5QSwECLQAUAAYACAAAACEA3y+x0VUDAAA8MAAAJwAAAAAAAAAAAAAAAAAgLQAAeGwvcHJp bnRlclNldHRpbmdzL3ByaW50ZXJTZXR0aW5nczEuYmluUEsBAi0AFAAGAAgAAAAhAFhvXFpLAQAA WwIAABEAAAAAAAAAAAAAAAAAujAAAGRvY1Byb3BzL2NvcmUueG1sUEsBAi0AFAAGAAgAAAAhAGVk NhuMAQAALAMAABAAAAAAAAAAAAAAAAAAPDMAAGRvY1Byb3BzL2FwcC54bWxQSwUGAAAAAA8ADwAS BAAA/jUAAAAA ------=_NextPart_000_0095_01CBA73F.D5A59D10-- From fernando.gont.netbook.win@gmail.com Tue Jan 4 09:16: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 9D9193A6C75 for ; Tue, 4 Jan 2011 09:16:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.536 X-Spam-Level: X-Spam-Status: No, score=-3.536 tagged_above=-999 required=5 tests=[AWL=0.063, 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 3nKbOz5oy4D9 for ; Tue, 4 Jan 2011 09:16:18 -0800 (PST) Received: from mail-gy0-f194.google.com (mail-gy0-f194.google.com [209.85.160.194]) by core3.amsl.com (Postfix) with ESMTP id B13643A6BE0 for ; Tue, 4 Jan 2011 09:16:18 -0800 (PST) Received: by gyf1 with SMTP id 1so3336992gyf.1 for ; Tue, 04 Jan 2011 09:18:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received: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=7CVq/h0XWgqQ0iic1DCnzJcF90FKCxOtn7CMRqhNqyA=; b=PJzrh5LMzi6ApVJwt26a88fQD+HnoUedEER5VlYlI9KPUkIdno7ZbQAmWqJlmsSRHl 5XYkVM5mMEcj0hvchP55cec6gJmHthStQgFdXf5HPq2KOmpgj0HDJSg0lKZecBES7FhR vd33gFC7axovGJbH0q1Xky21mNs5pRslFpOiA= 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=c4wuQ+Dlymc6ZPAslmJQmM5x4qySIwuM799peCcaPy+f6kvBo3JZgbN9m+jSlyQ+MT hIK/RpH92UlvtYIMkz9Tz81BvMkliBWLQapVVrw0yhPo/eMBBxbkPX9aqgp9VhIsDVkF ql1dNR56ExnADC8KNUKOO0q2z2TB/YKifg12Q= Received: by 10.147.33.10 with SMTP id l10mr30777000yaj.29.1294161505621; Tue, 04 Jan 2011 09:18:25 -0800 (PST) Received: from [192.168.0.120] (61-128-17-190.fibertel.com.ar [190.17.128.61]) by mx.google.com with ESMTPS id f73sm13159574yhc.4.2011.01.04.09.18.07 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 04 Jan 2011 09:18:24 -0800 (PST) Sender: Fernando Gont Message-ID: <4D23563E.7000108@gont.com.ar> Date: Tue, 04 Jan 2011 14:17:50 -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: Thomas Narten Subject: Re: I-D Action:draft-ietf-6man-exthdr-01.txt References: <20101217234501.11691.81147.idtracker@localhost> <63416880-97B6-4CE4-864A-1402DA977B5F@tony.li> <4D113364.3050105@ericsson.com> <201101032040.p03KeE86005244@cichlid.raleigh.ibm.com> <4D223EC0.7020906@gmail.com> <4D2242E9.8040804@gont.com.ar> <201101041429.p04ET81p006364@cichlid.raleigh.ibm.com> In-Reply-To: <201101041429.p04ET81p006364@cichlid.raleigh.ibm.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" , Brian E Carpenter , Suresh Krishnan 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, 04 Jan 2011 17:16:19 -0000 Hi, Thomas, On 04/01/2011 11:29 a.m., Thomas Narten wrote: >> From the POV of a firewall, unless it really wants a packet to >> pass-through, it will block it. > > I think this is the crux of the problem. firewalls, by default, > discard stuff. They don't like the idea of allowing unknown or > "uncommon" things through. Defining new options and expecting > firewalls to give them a blank check to go through I suspect is > wishful thinking. > > And look at this from the perspective of someone who wants to deploy a > new option. If 80% of the firewalls allow the new option through, will > this be good enough for deployment? Doubtful. What about 98% > cooperation from firewalls? Again, quite possibly not. I fully agree with you. > Unless this document is widely implemented in practice, it's far from > clear it is useful. Whether it's widely deployed is, IMHO, irrelevant. Two cases: * The I-D is not deployed (firewalls can't go past new extension headers). -- but the very presence of the unknown headers is what causes the fw to block the packets. * The I-D is deployed. The presence of an "uncommon" extension header causes the fw to block the packet (even when it could, *if* it wanted go past the "uncommon" extension header). As you correctly stated it, the crux of the problem is that this document assumes that firewalls are willing to allow stuff that they don't understand. -- but they aren't. They are meant to only allow stuff that is needed. 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 jmh@joelhalpern.com Tue Jan 4 09:24: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 3E4103A6BE0 for ; Tue, 4 Jan 2011 09:24:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.524 X-Spam-Level: X-Spam-Status: No, score=-102.524 tagged_above=-999 required=5 tests=[AWL=0.075, 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 fn9+aYKLhWTH for ; Tue, 4 Jan 2011 09:24:28 -0800 (PST) Received: from hgblob.mail.tigertech.net (hgblob.mail.tigertech.net [64.62.209.71]) by core3.amsl.com (Postfix) with ESMTP id 5C4E03A6CE0 for ; Tue, 4 Jan 2011 09:24:28 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hgblob.tigertech.net (Postfix) with ESMTP id B60D43245E97; Tue, 4 Jan 2011 09:26:35 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from [10.10.10.101] (pool-71-161-50-147.clppva.btas.verizon.net [71.161.50.147]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by hgblob.tigertech.net (Postfix) with ESMTPSA id D2A483245057; Tue, 4 Jan 2011 09:26:34 -0800 (PST) Message-ID: <4D235845.6040409@joelhalpern.com> Date: Tue, 04 Jan 2011 12:26:29 -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: Fernando Gont Subject: Re: I-D Action:draft-ietf-6man-exthdr-01.txt References: <20101217234501.11691.81147.idtracker@localhost> <63416880-97B6-4CE4-864A-1402DA977B5F@tony.li> <4D113364.3050105@ericsson.com> <201101032040.p03KeE86005244@cichlid.raleigh.ibm.com> <4D223EC0.7020906@gmail.com> <4D2242E9.8040804@gont.com.ar> <201101041429.p04ET81p006364@cichlid.raleigh.ibm.com> <4D23563E.7000108@gont.com.ar> In-Reply-To: <4D23563E.7000108@gont.com.ar> 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: Tue, 04 Jan 2011 17:24:29 -0000 Then what about if we forget firewalls for the moment? A lot of routers look for the TCP/UDP Port numbers for LAG/ECMP computation. Many of them can cope with having a destination options extension, and therefore that is clearly the better way to handle such information. And anything we do should make that strong preference clear. Nothing we can do can change the way routers with silicon already deployed handle unknown extension headers. Given that, one option is to just say that new extension headers should not be used. If we think that there will be some new extension headers, that we want to support, designed for the general Internet, then it would seem to make sense to try to get new behavior defined, supported, and then used, that will allow for such extensions. In that case, requiring and documenting the requirement for new extension headers to use TLV encoding would seem to have applicability and utility. Yours, Joel On 1/4/2011 12:17 PM, Fernando Gont wrote: > Hi, Thomas, > > On 04/01/2011 11:29 a.m., Thomas Narten wrote: >>> From the POV of a firewall, unless it really wants a packet to >>> pass-through, it will block it. >> >> I think this is the crux of the problem. firewalls, by default, >> discard stuff. They don't like the idea of allowing unknown or >> "uncommon" things through. Defining new options and expecting >> firewalls to give them a blank check to go through I suspect is >> wishful thinking. >> >> And look at this from the perspective of someone who wants to deploy a >> new option. If 80% of the firewalls allow the new option through, will >> this be good enough for deployment? Doubtful. What about 98% >> cooperation from firewalls? Again, quite possibly not. > > I fully agree with you. > > > >> Unless this document is widely implemented in practice, it's far from >> clear it is useful. > > Whether it's widely deployed is, IMHO, irrelevant. Two cases: > > * The I-D is not deployed (firewalls can't go past new extension > headers). -- but the very presence of the unknown headers is what causes > the fw to block the packets. > * The I-D is deployed. The presence of an "uncommon" extension header > causes the fw to block the packet (even when it could, *if* it wanted go > past the "uncommon" extension header). > > As you correctly stated it, the crux of the problem is that this > document assumes that firewalls are willing to allow stuff that they > don't understand. -- but they aren't. They are meant to only allow stuff > that is needed. > > Thanks, From remi.despres@free.fr Tue Jan 4 09:34: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 780AB3A6D05 for ; Tue, 4 Jan 2011 09:34:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.431 X-Spam-Level: X-Spam-Status: No, score=-1.431 tagged_above=-999 required=5 tests=[AWL=0.518, BAYES_00=-2.599, HELO_EQ_FR=0.35, 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 dTdyvXerLPq4 for ; Tue, 4 Jan 2011 09:34:09 -0800 (PST) Received: from smtp24.services.sfr.fr (smtp24.services.sfr.fr [93.17.128.81]) by core3.amsl.com (Postfix) with ESMTP id 68FF73A6CE0 for ; Tue, 4 Jan 2011 09:34:09 -0800 (PST) Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2403.sfr.fr (SMTP Server) with ESMTP id D7810700008F; Tue, 4 Jan 2011 18:36:15 +0100 (CET) Received: from [192.168.0.20] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by msfrf2403.sfr.fr (SMTP Server) with ESMTP id 2DC127000085; Tue, 4 Jan 2011 18:36:13 +0100 (CET) X-SFR-UUID: 20110104173615187.2DC127000085@msfrf2403.sfr.fr Subject: Re: I-D Action:draft-ietf-6man-exthdr-01.txt Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: <1294154446.3814.9.camel@tachyon> Date: Tue, 4 Jan 2011 18:36:09 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <52EFA963-A065-4F9C-958B-7F1C282B0DD1@free.fr> References: <20101217234501.11691.81147.idtracker@localhost> <63416880-97B6-4CE4-864A-1402DA977B5F@tony.li> <4D113364.3050105@ericsson.com> <201101032040.p03KeE86005244@cichlid.raleigh.ibm.com> <4D223EC0.7020906@gmail.com> <201101041420.p04EKOmT006328@cichlid.raleigh.ibm.com> <1294154446.3814.9.camel@tachyon> To: Thomas Narten , Steven Blake 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: Tue, 04 Jan 2011 17:34:10 -0000 Le 4 janv. 2011 =E0 16:20, Steven Blake a =E9crit : > On Tue, 2011-01-04 at 09:20 -0500, Thomas Narten wrote: >>=20 >> If the firewall will just dig one layer deeper and then discard >> anyway, what is the point? >=20 > +1 >=20 > I still don't understand what this draft solves that couldn't be = solved > more easily by just encoding future header extensions as either > Destination options or Hop-by-Hop options? 1. let's assume a new routing extension is found useful. Without a skippable extension format, it won't ever be deployable: - All FWs will have no option but rejecting all packets having it. With this extension format, FWs can first be upgraded to support it, = i.e. so that they ignore unknown extensions marked as "to be ignored if = unknown". Then it becomes realistic to create, for example, a new routing option. 2. Attached is a copy of a previous mail, still relevant I believe. Regards, RD > Le 3 janv. 2011 =E0 14:20, Suresh Krishnan a =E9crit : >> ... >> The draft contains three independent components >>=20 >> a) Specifying a uniform format for all future IPv6 extension headers = to >> make them easier to parse/process. >> b) Requesting a single IP protocol number codepoint for all future >> extension headers and multiplexing them using a Specific Type field >> inside the generic header. >> c) Specifying error-handling and drop behavior for dealing with = unknown >> extension headers. >=20 >> =46rom what I have seen there seems to be no opposition to a) >=20 > No opposition AND positive support: >=20 > Skipping unknown extension headers can be useful not only in FWs but = also in some other places (e.g. in some variants of load balancers)=20 >=20 > As Fernando noted, FWs that do "default deny" shouldn't be concerned. > However, not all FWs are necessarily default deny in the strict sense = (i.e. with all fields of accepted packets having to be described) > It may be useful to say, for example, "accept all incoming connections = to address X and port 80" without concern for extension headers. >=20 > Besides, someone, Mark Townsley I believe, described a FW behavior = where: > - packets known to be good are accepted > - packets known to be bad are discarded > - unknown packets are rate limited > This is IMHO an interesting possibility that differs from just = "default deny". >=20 > Points b and c are more debatable. > I don't find them necessary. > The draft would IMHO be better without them, but I don't object. >=20 > The proposed addition in the "Meta question" seems useful =3D> +1 > (But the document remains acceptable without it.) From rja.lists@gmail.com Tue Jan 4 10:40: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 CE9583A6CF5 for ; Tue, 4 Jan 2011 10:40:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[AWL=0.300, 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 NDUb7tS7ZWfZ for ; Tue, 4 Jan 2011 10:40:29 -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 D721E3A6A32 for ; Tue, 4 Jan 2011 10:40:28 -0800 (PST) Received: by vws7 with SMTP id 7so6010230vws.31 for ; Tue, 04 Jan 2011 10:42:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:content-type :content-transfer-encoding:subject:date:message-id:to:mime-version :x-mailer; bh=D3a25yz7vMEJ2TcTu0FKn+ZcnBQgMPmHqCmEecDsEo8=; b=YzlnN3/dZhmli47BMnmSm3YEiaxXmj0bmkYpJfBxmQ1BPJCXin93BLB93RKxTqDuAR EqMi3GrzztvyICBiBsUZqT7vIz4COSg3lKsOMUnV+U8Nl8Bt04JN5WE2FeDTd9yqFKd+ pwrlNUbyiguHiLf3TzDA9Nr4uGxif+uN1tIYs= 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=wRtn0gwTRK6A7jOEnNDovJgUU57G/5sCtATX+N0ZumQJSqItgDEs+9tBmHP4lNGk1i LsjwZyQIvSUoy6fX/PUWXJw8EEIqhYrdao9QJIq5mKOs0+vcO7+K6wJNUdfGsAN7C0JC WWlxMZsTqmiIc7POIg5ikMVsrCOY4CrA5E1F8= Received: by 10.220.182.76 with SMTP id cb12mr32384vcb.271.1294166555596; Tue, 04 Jan 2011 10:42:35 -0800 (PST) Received: from vi-mhowell55.leclairryan.com ([38.103.42.150]) by mx.google.com with ESMTPS id b6sm4607366vci.0.2011.01.04.10.42.33 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 04 Jan 2011 10:42:34 -0800 (PST) From: RJ Atkinson Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: Re: I-D Action:draft-ietf-6man-exthdr-01.txt Date: Tue, 4 Jan 2011 13:42:32 -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: Tue, 04 Jan 2011 18:40:29 -0000 Earlier, Remi Depres wrote: > 1. let's assume a new routing extension is found useful. > Without a skippable extension format, it won't ever be deployable: > - All FWs will have no option but rejecting all packets having = it. In reality, such an extension would use the existing IPv6 Routing Header (RFC-2460, Section 4.4), and would define a new "Routing Type" value. =20 The IPv6 Routing Header already begins with these 3 fields: - Next Header - Length of this Routing Header - Routing Type So the IPv6 Routing Header *already* can be skipped if desired. =20 More importantly, several existing deployed routers (from multiple=20 vendors) that are deployed in the operational public Internet can already parse past the Routing Header (if desired), for example=20 in order to examine the transport-layer protocol and transport-layer=20 port-number information -- and can do this today *at wire-speed for high-speed backbone links*. > With this extension format, FWs can first be upgraded to support = it,=20 > i.e. so that they ignore unknown extensions marked as "to be = ignored if unknown". > Then it becomes realistic to create, for example, a new routing = option. As Fernando Gont and others have observed repeatedly, firewalls=20 are intentionally designed to drop packets containing unrecognised options/extensions -- regardless of what "action bits" might suggest. =20= In short, your assumption that significant numbers of deployed IPv6-capable firewalls would in fact "ignore unknown extensions/options"=20= is not a valid assumption. If one wants to create a new routing option, the BEST chance of that new routing idea being deployable is to re-use the existing=20 IPv6 Routing Header and define a new Routing Type value. (I consider it unlikely that anyone would create such a routing enhancement proposal, but if someone did, then reusing the=20 existing IPv6 Routing Header would be the BEST chance for deployment.) Yours, Ran From ipng@69706e6720323030352d30312d31340a.nosense.org Tue Jan 4 13:45: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 1B4203A6BB4 for ; Tue, 4 Jan 2011 13:45:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[AWL=0.017, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, J_CHICKENPOX_55=0.6] 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 wfnxlmGmPsEI for ; Tue, 4 Jan 2011 13:45:12 -0800 (PST) Received: from smtp4.adam.net.au (smtp4.adam.net.au [202.136.110.247]) by core3.amsl.com (Postfix) with ESMTP id DE4883A6AB4 for ; Tue, 4 Jan 2011 13:45:11 -0800 (PST) Received: from 182-239-157-145.ip.adam.com.au ([182.239.157.145] helo=opy.nosense.org) by smtp4.adam.net.au with esmtp (Exim 4.63) (envelope-from ) id 1PaEiq-0004Vu-Rg; Wed, 05 Jan 2011 08:17:16 +1030 Received: from opy.nosense.org (localhost.localdomain [IPv6:::1]) by opy.nosense.org (Postfix) with ESMTP id 704D93B31E; Wed, 5 Jan 2011 08:17:16 +1030 (CST) Date: Wed, 5 Jan 2011 08:17:16 +1030 From: Mark Smith To: Pekka Savola Subject: Re: addrsel: privacy addresses within/out of a site Message-ID: <20110105081716.3b4f8526@opy.nosense.org> In-Reply-To: References: <20110103204031.0c3589b7@opy.nosense.org> 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: 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, 04 Jan 2011 21:45:13 -0000 On Mon, 3 Jan 2011 12:21:41 +0200 (EET) Pekka Savola wrote: > On Mon, 3 Jan 2011, Mark Smith wrote: > >> "do not use privacy addresses when communicating inside the site [a set of > >> designated destination prefixes], use it by default otherwise" > >> > > > > I'd be curious what the benefits are. > > > > The only reason I could think of as to why to do this is to be able to > > associate internal application access logs with internal hosts. At face > > value that sounds useful, however if you really care about auditing > > application access and use, it isn't the hosts you need to worry about, > > but the people behind them - and they can usually easily change hosts. > > So I think those applications should be using proper AAA to identify the > > user, rather than using IPv6 host identifiers as very poor substitutes > > for user identities. > > One use case is administrators running ssh, vnc or some such remote > management to the client OS. The conclusion from looking at various > similar cases was that systems need to have a well-known (non-privacy) > IP where they can be reached and run TCP services at, or the privacy > IP needs to be stored in DNS (not much point in that..). > I think that could be achieved by using another address/prefix for that purpose, which has a preferred lifetime of 0 and an ordinary valid lifetime, although RFC3484 needs to be updated to use the largest preferred lifetime as a tie-breaker when multiple valid addresses remain as candidate sources. As the addresses have a zero preferred lifetime, they wouldn't be used for outbound connections, but they're still valid for inbound ones. > Also, many site-internal access control mechanisms (for example, > hosts.allow for ssh, some others for e.g. web browsing) use > host-specific IPs in addition to other checks. In some cases these > could be substituted with stronger upper-layer identities e.g with > certificates. > I think it is inevitable that some of IPv6's more advanced and dynamic addressing mechanisms and properties are going to make traditional IPv4 addressing related security methods obsolete. When ever a function is to be achieved in IPv6 that is being achieved in IPv4, I think it is better not to assume that the IPv4 method is directly translatable, and to see if there are methods which don't constrain some of IPv6's new addressing mechanisms or possibly takes advantage of them. > On the other hand, user identification due to static EU64 is a little > bit of concern e.g. with web surfing, but this also applies to other > applications so the issue does not go away with application-specific > tuning. > Regards, Mark. From suresh.krishnan@ericsson.com Tue Jan 4 23:13: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 C7E0B3A6BAD for ; Tue, 4 Jan 2011 23:13:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.573 X-Spam-Level: X-Spam-Status: No, score=-102.573 tagged_above=-999 required=5 tests=[AWL=0.026, 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 KyH+GkibY8-8 for ; Tue, 4 Jan 2011 23:13:52 -0800 (PST) Received: from imr3.ericy.com (imr3.ericy.com [198.24.6.13]) by core3.amsl.com (Postfix) with ESMTP id AAE8F3A6B73 for ; Tue, 4 Jan 2011 23:13:52 -0800 (PST) Received: from eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) by imr3.ericy.com (8.13.8/8.13.8) with ESMTP id p057Fw66004089 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 5 Jan 2011 01:15:59 -0600 Received: from EUSAACMS0703.eamcs.ericsson.se ([169.254.1.66]) by eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) with mapi; Wed, 5 Jan 2011 02:15:58 -0500 From: Suresh Krishnan To: Thomas Narten Date: Wed, 5 Jan 2011 02:15:55 -0500 Subject: RE: I-D Action:draft-ietf-6man-exthdr-01.txt Thread-Topic: I-D Action:draft-ietf-6man-exthdr-01.txt Thread-Index: AcurhnuzOYpkhjqtRyKeji6dVEK9+wA+zE/w Message-ID: <4FD1E7CD248BF84F86BD4814EDDDBCC150E9C6484B@EUSAACMS0703.eamcs.ericsson.se> References: <20101217234501.11691.81147.idtracker@localhost> <63416880-97B6-4CE4-864A-1402DA977B5F@tony.li> <4D113364.3050105@ericsson.com> <201101032040.p03KeE86005244@cichlid.raleigh.ibm.com> In-Reply-To: <201101032040.p03KeE86005244@cichlid.raleigh.ibm.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 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, 05 Jan 2011 07:13:53 -0000 Hi Thomas, Please see responses inline.=20 > -----Original Message----- > From: Thomas Narten [mailto:narten@us.ibm.com]=20 > Sent: Monday, January 03, 2011 3:40 PM > To: Suresh Krishnan > Cc: Tony Li; ipv6@ietf.org > Subject: Re: I-D Action:draft-ietf-6man-exthdr-01.txt >=20 > FWIW, I'm sympathetic to Tony's basic sense that it is=20 > unclear that we need to do this work/document. >=20 > I'm still not clear on exactly what *real* problem it solves. >=20 > Suresh Krishnan writes: >=20 > > Since RFC2460 came out, four new extension headers have=20 > been defined. >=20 > > 135 - Mobility header > > 139 - HIP > > 140 - Shim6 > > 141 - WESP >=20 > 2 of the above code points are used by IPv4, so having a=20 > generic extension header mechanism for IPv6 would have saved=20 > only 2 code points. No need to panic folks... >=20 > > The idea of burning one protocol number right now was=20 > suggested by the=20 > > WG in order to limit further exhaustion of the protocol=20 > number space. > > Would it be more acceptable to you, if we do not ask for an IANA=20 > > allocation for a protocol number at this point, and wait till the=20 > > first "Specific Type" request comes up? >=20 > My general sense is that this work is mostly just good common=20 > sense advice to someone who has a need to define a new=20 > extension type. But until we see such a concrete proposal, I=20 > am not convinced (yet) that we should define anything new=20 > that suggests people go change implementations or allocate=20 > code points. Both are premature. OK. >=20 > As one concrete example, RFC 5175 defines extensions for=20 > adding future RA flags. But, none have been defined yet, so=20 > the work really isn't needed yet and implementations=20 > certainly don't need to do anything yet. However, that has=20 > not stopped NIST and DoD from citing these documents=20 > recommendations to implement. >=20 > Upleveling a bit, and thinking about routing headers and=20 > destination options, my general sense is about such options is: >=20 > 1) Destination options are the preferred route. Any other=20 > kind of option will be extremely hard to deploy, has all=20 > kinds of barriers, etc. (This proposal will have no impact on=20 > future destination options. Right?) Correct. And I proposed adding the following text to this draft=20 to state this fact. "RFC2460 allows the use of both extension headers and destination options in order to encode optional destination information in an IPv6 packet. The use of destination options to encode this information, provides more flexible handling characteristics and better backward compatibility than using extension headers. Because of this, implementations SHOULD use destination options as the preferred mechanism for encoding optional destination information, and use a new extension header only if destination options do not satisfy their needs. The request for allocation of a Specific Type value MUST be accompanied by an specific explanation of why destination options could not be used to convey this information." http://www.ietf.org/mail-archive/web/ipv6/current/msg13207.html >=20 > 2) The routing header is essentially deprecated, and we=20 > probably won't define any more. We've already deprecated RHO.=20 > RH1 was never used, is now deprecated, and arguably shouldn't=20 > even count as ever having been defined. RH2 is the MIP=20 > routing header. RH2 was originally a regular type 0 option,=20 > but was changed because of the fear that firewalls would=20 > block packets with such options by default, preventing MIPv6=20 > from being deployed. If we had to do it all over again, MIPv6=20 > arguably should have used a destination option, since by=20 > definition RH2 is only processed if the two addresses in the=20 > routing header are on the same node, which is much more in=20 > line with the intention behind destination options. >=20 > Which leads me to ask, exactly what kinds of future options=20 > do we think will take advantage of this new format? Not sure. The goal is to make sure that other wgs that define ipv6 specific optional information do so in a consistent way. I think the burden would be on them to prove that destination options do not fit their need. >=20 > Note, my bias on this general topic is based on experience=20 > that unless we have something concrete driving this sort of=20 > work, we risk getting it wrong. So, I'm still trying to be=20 > convinced we need to do this sort of work *now*. If there was=20 > an actual proposal for a new option that solved some sort of=20 > real problem, things might be different. The "concrete" thing was the need for firewalls to differentiate between unknown extension headers and unknown transport=20 protocols. There were two firewall vendors who spoke up for this at a 6man wg meeting. It is possible that they no longer care. That is why I am trying to see if there is any reason to continue with the draft, and if so what it should contain. I would=20 Appreciate your comments on this mail. http://www.ietf.org/mail-archive/web/ipv6/current/msg13207.html Thanks Suresh From suresh.krishnan@ericsson.com Tue Jan 4 23:25:49 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 905DF3A6B83 for ; Tue, 4 Jan 2011 23:25:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.573 X-Spam-Level: X-Spam-Status: No, score=-102.573 tagged_above=-999 required=5 tests=[AWL=0.026, 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 T2sshjdDbBns for ; Tue, 4 Jan 2011 23:25:48 -0800 (PST) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.8]) by core3.amsl.com (Postfix) with ESMTP id 8F2A23A6B73 for ; Tue, 4 Jan 2011 23:25:48 -0800 (PST) Received: from eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id p0582xGM021186; Wed, 5 Jan 2011 02:03:52 -0600 Received: from EUSAACMS0703.eamcs.ericsson.se ([169.254.1.66]) by eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) with mapi; Wed, 5 Jan 2011 02:27:14 -0500 From: Suresh Krishnan To: Brian E Carpenter , Thomas Narten Date: Wed, 5 Jan 2011 02:27:12 -0500 Subject: RE: I-D Action:draft-ietf-6man-exthdr-01.txt Thread-Topic: I-D Action:draft-ietf-6man-exthdr-01.txt Thread-Index: AcurjMWZGK0VFDr1SueHNVYVtwGjrQBG88zg Message-ID: <4FD1E7CD248BF84F86BD4814EDDDBCC150E9C64851@EUSAACMS0703.eamcs.ericsson.se> References: <20101217234501.11691.81147.idtracker@localhost> <63416880-97B6-4CE4-864A-1402DA977B5F@tony.li> <4D113364.3050105@ericsson.com> <201101032040.p03KeE86005244@cichlid.raleigh.ibm.com> <4D223EC0.7020906@gmail.com> In-Reply-To: <4D223EC0.7020906@gmail.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 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, 05 Jan 2011 07:25:49 -0000 Hi Brian,=20 Please see response inline. > -----Original Message----- > From: Brian E Carpenter [mailto:brian.e.carpenter@gmail.com]=20 > Sent: Monday, January 03, 2011 4:25 PM > To: Thomas Narten > Cc: Suresh Krishnan; ipv6@ietf.org > Subject: Re: I-D Action:draft-ietf-6man-exthdr-01.txt >=20 > > 2) The routing header is essentially deprecated, and we=20 > probably won't=20 > > define any more. >=20 > The proposal for RH4, i.e. draft-ietf-6man-rpl-routing-header, > is active. >=20 > However, isn't the real question whether we want to change=20 > the implied intention that adding a new extension header=20 > should be hard? Section 4 of RFC 2460 makes this intention=20 > pretty clear: > unknown extension headers should lead to packet discard and=20 > ICMP Parameter Problem, so this is intended for consenting=20 > adults only. Skipping over unknown extension headers was=20 > definitely not intended to work. >=20 > The basic motivation for the present draft is clear: >=20 > > However, > > some intermediate nodes such as firewalls, may need to=20 > look at the > > transport layer header fields in order to make a=20 > decision to allow or > > deny the packet. =20 >=20 > That is, help middleboxes to violate e2e transparency and,=20 > furthermore, allow unknown headers to cross those=20 > middleboxes. If I was a paranoid security person, I would=20 > definitely not be happy with this. On the contrary - if I saw=20 > an unknown IP header in a packet, I would want to discard it.=20 > A legacy firewall wouldn't recognize the Next Header value=20 > for draft-ietf-6man-exthdr, so would discard the packet. If=20 > my firewall had been updated, and saw a=20 > draft-ietf-6man-exthdr, header, it would need to look at the=20 > embedded "Specific Type" and then decide whether to discard=20 > it. Just a bit more deep packet inspection. >=20 > So the one thing this proposal will *not* do is allow new=20 > extension headers to cross the Internet transparently. All it=20 > might do is cause the firewalls to dig one layer deeper=20 > before discarding the packet. Correct. But the reason that this part got added to the draft=20 was that firewall vendors wanted to differentiate between=20 unknown extension headers and unknown transport protocols and possibly treat them in a different way. E.g. Section 3.2.2 of http://tools.ietf.org/html/draft-ietf-v6ops-cpe-simple-security-16 Specifies one such need. Thanks Suresh= From suresh.krishnan@ericsson.com Tue Jan 4 23:33: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 7FA853A6B9D for ; Tue, 4 Jan 2011 23:33:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.574 X-Spam-Level: X-Spam-Status: No, score=-102.574 tagged_above=-999 required=5 tests=[AWL=0.025, 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 Zf9UMHcbFQbd for ; Tue, 4 Jan 2011 23:33:20 -0800 (PST) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.8]) by core3.amsl.com (Postfix) with ESMTP id 73A2A3A6A2C for ; Tue, 4 Jan 2011 23:33:20 -0800 (PST) Received: from eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id p058Apb6021298; Wed, 5 Jan 2011 02:10:52 -0600 Received: from EUSAACMS0703.eamcs.ericsson.se ([169.254.1.66]) by eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) with mapi; Wed, 5 Jan 2011 02:34:48 -0500 From: Suresh Krishnan To: Fernando Gont , Brian E Carpenter Date: Wed, 5 Jan 2011 02:34:46 -0500 Subject: RE: I-D Action:draft-ietf-6man-exthdr-01.txt Thread-Topic: I-D Action:draft-ietf-6man-exthdr-01.txt Thread-Index: Acurj0lc6YYmKH76SNey+636QKZq5ABGrtOw Message-ID: <4FD1E7CD248BF84F86BD4814EDDDBCC150E9C64854@EUSAACMS0703.eamcs.ericsson.se> References: <20101217234501.11691.81147.idtracker@localhost> <63416880-97B6-4CE4-864A-1402DA977B5F@tony.li> <4D113364.3050105@ericsson.com> <201101032040.p03KeE86005244@cichlid.raleigh.ibm.com> <4D223EC0.7020906@gmail.com> <4D2242E9.8040804@gont.com.ar> In-Reply-To: <4D2242E9.8040804@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 Cc: Thomas Narten , "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, 05 Jan 2011 07:33:21 -0000 Hi Fernando, Please see response inline. > -----Original Message----- > From: Fernando Gont=20 > [mailto:fernando.gont.netbook.win@gmail.com] On Behalf Of=20 > Fernando Gont > Sent: Monday, January 03, 2011 4:43 PM > To: Brian E Carpenter > Cc: Thomas Narten; ipv6@ietf.org; Suresh Krishnan > Subject: Re: I-D Action:draft-ietf-6man-exthdr-01.txt >=20 > On 03/01/2011 06:25 p.m., Brian E Carpenter wrote: >=20 > > The basic motivation for the present draft is clear: > >=20 > >> However, > >> some intermediate nodes such as firewalls, may need to=20 > look at the > >> transport layer header fields in order to make a=20 > decision to allow or > >> deny the packet. =20 > >=20 > > That is, help middleboxes to violate e2e transparency and,=20 > > furthermore, allow unknown headers to cross those middleboxes. >=20 > I don't think this I-D will make a difference. >=20 > From the POV of a firewall, unless it really wants a packet=20 > to pass-through, it will block it. >=20 > So, whether the Extension Header is unknown, or whether=20 > draft-ietf-6man-exthdr-01.txt is implemented and the Specific=20 > type is unknown will lead to the same result: the packet will=20 > be discarded. >=20 > This proposal would only be useful to firewalls that=20 > implement a "default allow", and that simply want to somehow=20 > ignore an unknown extension header and base their decision on=20 > the upper-layer protocol (only). -- But we all know that=20 > firewalls operate (or should operate) in "default deny"=20 > rather than "default allow". >=20 > So IMHO this proposal won't be useful for such firewalls. Yes. You are correct. This proposal will not be useful for such firewalls. On the other hand=20 http://tools.ietf.org/html/draft-ietf-v6ops-cpe-simple-security-16 allows a class of firewalls that can put application transparency over strict filtering (see REC-11). In such case differentiating=20 an unknown transport layer protocol from an unknown extension=20 header would be useful. Whether or not such firewall would exist in the wild is an interesting question, but I do not see how to=20 answer that conclusively. Thanks Suresh= From suresh.krishnan@ericsson.com Wed Jan 5 02:06:16 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 1FBA03A6A1A for ; Wed, 5 Jan 2011 02:06:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.574 X-Spam-Level: X-Spam-Status: No, score=-102.574 tagged_above=-999 required=5 tests=[AWL=0.025, 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 PWfWrsjasFdG for ; Wed, 5 Jan 2011 02:06:13 -0800 (PST) Received: from imr3.ericy.com (imr3.ericy.com [198.24.6.13]) by core3.amsl.com (Postfix) with ESMTP id 173963A6D17 for ; Wed, 5 Jan 2011 02:06:12 -0800 (PST) Received: from eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) by imr3.ericy.com (8.13.8/8.13.8) with ESMTP id p05A8Jtf006912 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 5 Jan 2011 04:08:19 -0600 Received: from EUSAACMS0703.eamcs.ericsson.se ([169.254.1.66]) by eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) with mapi; Wed, 5 Jan 2011 05:08:18 -0500 From: Suresh Krishnan To: Steven Blake , "ipv6@ietf.org" Date: Wed, 5 Jan 2011 05:08:16 -0500 Subject: RE: I-D Action:draft-ietf-6man-exthdr-01.txt Thread-Topic: I-D Action:draft-ietf-6man-exthdr-01.txt Thread-Index: AcusIwNj8X9yfCOiRKulb82BaWahIQAnTZNg Message-ID: <4FD1E7CD248BF84F86BD4814EDDDBCC150E9C6485E@EUSAACMS0703.eamcs.ericsson.se> References: <20101217234501.11691.81147.idtracker@localhost> <63416880-97B6-4CE4-864A-1402DA977B5F@tony.li> <4D113364.3050105@ericsson.com> <201101032040.p03KeE86005244@cichlid.raleigh.ibm.com> <4D223EC0.7020906@gmail.com> <201101041420.p04EKOmT006328@cichlid.raleigh.ibm.com> <1294154446.3814.9.camel@tachyon> In-Reply-To: <1294154446.3814.9.camel@tachyon> 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-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, 05 Jan 2011 10:06:16 -0000 Hi Steve,=20 > -----Original Message----- > From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On=20 > Behalf Of Steven Blake > Sent: Tuesday, January 04, 2011 10:21 AM > To: ipv6@ietf.org > Subject: Re: I-D Action:draft-ietf-6man-exthdr-01.txt >=20 > On Tue, 2011-01-04 at 09:20 -0500, Thomas Narten wrote: >=20 > > This is at best poorly phrased. :-) > >=20 > > If the firewall will just dig one layer deeper and then discard=20 > > anyway, what is the point? >=20 > +1 >=20 > I still don't understand what this draft solves that couldn't=20 > be solved more easily by just encoding future header=20 > extensions as either Destination options or Hop-by-Hop=20 > options? Both of these are easy to parse and have well=20 > defined rules for how to handle unknown options. One of the drivers of the draft was that firewall vendors wanted to differe= ntiate between unknown extension headers and unknown transport protocols an= d possibly treat them in a different way. E.g. Section 3.2.2 of http://tools.ietf.org/html/draft-ietf-v6ops-cpe-simple-security-16 specifies one such need. Thanks Suresh= From suresh.krishnan@ericsson.com Wed Jan 5 02:11:03 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 8B7223A6DCF for ; Wed, 5 Jan 2011 02:11:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.574 X-Spam-Level: X-Spam-Status: No, score=-102.574 tagged_above=-999 required=5 tests=[AWL=0.025, 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 8X0LhUQBFlep for ; Wed, 5 Jan 2011 02:10:58 -0800 (PST) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.8]) by core3.amsl.com (Postfix) with ESMTP id 6F4F13A6DCD for ; Wed, 5 Jan 2011 02:10:58 -0800 (PST) Received: from eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id p05An2Kr024089; Wed, 5 Jan 2011 04:49:03 -0600 Received: from EUSAACMS0703.eamcs.ericsson.se ([169.254.1.66]) by eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) with mapi; Wed, 5 Jan 2011 05:12:57 -0500 From: Suresh Krishnan To: RJ Atkinson , "ipv6@ietf.org" Date: Wed, 5 Jan 2011 05:12:55 -0500 Subject: RE: I-D Action:draft-ietf-6man-exthdr-01.txt Thread-Topic: I-D Action:draft-ietf-6man-exthdr-01.txt Thread-Index: AcusIpv/gzHrAkZ3TNuKipEmY0X3CgAnev/Q Message-ID: <4FD1E7CD248BF84F86BD4814EDDDBCC150E9C6485F@EUSAACMS0703.eamcs.ericsson.se> References: In-Reply-To: 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-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, 05 Jan 2011 10:11:03 -0000 Hi Ran, =20 > I believe there would be broad support within the IPv6 WG to=20 > have a small clarification to RFC-2460 that required the use=20 > of Destination Options in all cases where they can be made to=20 > work (in essence, this is Joel's I and II above). >=20 > However, that could be done in a 1-page (plus boilerplate) draft. >=20 > Since Suresh has been driving this issue, perhaps Suresh=20 > could create such a 1-page (plus boilerplate) draft for the=20 > IPv6 WG to review ? (:-) I'm up for it :-). In fact I already suggested the meat in http://www.ietf.org/mail-archive/web/ipv6/current/msg13207.html "RFC2460 allows the use of both extension headers and destination options i= n order to encode optional destination information in an IPv6 packet. The u= se of destination options to encode this information, provides more flexibl= e handling characteristics and better backward compatibility than using ext= ension headers. Because of this, implementations SHOULD use destination opt= ions as the preferred mechanism for encoding optional destination informati= on, and use a new extension header only if destination options do not satis= fy their needs. The request for allocation of a Specific Type value MUST be accompanied by = an specific explanation of why destination options could not be used to con= vey this information." Let's see how that is received by the WG. I would appreciate your responses= to that specific mail. Cheers Suresh From suresh.krishnan@ericsson.com Wed Jan 5 02:18: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 361A43A6DD6 for ; Wed, 5 Jan 2011 02:18:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.575 X-Spam-Level: X-Spam-Status: No, score=-102.575 tagged_above=-999 required=5 tests=[AWL=0.024, 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 dqVK2pMfdHMj for ; Wed, 5 Jan 2011 02:18:47 -0800 (PST) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.8]) by core3.amsl.com (Postfix) with ESMTP id 5D3D53A6B6F for ; Wed, 5 Jan 2011 02:18:46 -0800 (PST) Received: from eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id p05AuoQE024295; Wed, 5 Jan 2011 04:56:52 -0600 Received: from EUSAACMS0703.eamcs.ericsson.se ([169.254.1.66]) by eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) with mapi; Wed, 5 Jan 2011 05:20:45 -0500 From: Suresh Krishnan To: Pekka Savola , "ipv6@ietf.org" Date: Wed, 5 Jan 2011 05:20:43 -0500 Subject: RE: addrsel: privacy addresses within/out of a site Thread-Topic: addrsel: privacy addresses within/out of a site Thread-Index: AcurK9pZDSI68n2DQyGiE0abRhY/KgBlf0Qg Message-ID: <4FD1E7CD248BF84F86BD4814EDDDBCC150E9C64860@EUSAACMS0703.eamcs.ericsson.se> References: In-Reply-To: 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-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, 05 Jan 2011 10:18:48 -0000 Hi Pekka, > Operational input: when discussing the use of RFC4941=20 > (privacy) addresses with our LAN/workstation admins, it=20 > seemed as if there would be great benefit from being able to=20 > specify an RFC3484 rule which would in essence say: >=20 > "do not use privacy addresses when communicating inside the=20 > site [a set of designated destination prefixes], use it by=20 > default otherwise" >=20 > I don't think this is possible today because rfc3484 policy=20 > table only allows matching by prefixes, not by address type. I agree with you that this would be useful. >=20 > Has this come up in discussions / has anyone else thought about this? Not exactly this point, but the ability to add specific prefixes into the p= olicy table dynamically has been discussed several times before (e.g. in UL= A scenarios) and will hopefully be solved soon. On a side note, if you control the application you could use the IPV6_PREFE= R_SRC_PUBLIC flag defined in RFC5014 to effect such behavior. Thanks Suresh From suresh.krishnan@ericsson.com Wed Jan 5 02:23: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 2046F3A6DD8 for ; Wed, 5 Jan 2011 02:23:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.575 X-Spam-Level: X-Spam-Status: No, score=-102.575 tagged_above=-999 required=5 tests=[AWL=0.024, 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 wUhu1tBo90mp for ; Wed, 5 Jan 2011 02:23:08 -0800 (PST) Received: from imr3.ericy.com (imr3.ericy.com [198.24.6.13]) by core3.amsl.com (Postfix) with ESMTP id 335253A6A1A for ; Wed, 5 Jan 2011 02:23:08 -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 p05AP5cH007286 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 5 Jan 2011 04:25:09 -0600 Received: from EUSAACMS0703.eamcs.ericsson.se ([169.254.1.66]) by eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) with mapi; Wed, 5 Jan 2011 05:25:05 -0500 From: Suresh Krishnan To: "Joel M. Halpern" , Fernando Gont Date: Wed, 5 Jan 2011 05:25:04 -0500 Subject: RE: I-D Action:draft-ietf-6man-exthdr-01.txt Thread-Topic: I-D Action:draft-ietf-6man-exthdr-01.txt Thread-Index: AcusNJBqFRGmPHu7Rr2Zi02PYt01zgAjbasw Message-ID: <4FD1E7CD248BF84F86BD4814EDDDBCC150E9C64861@EUSAACMS0703.eamcs.ericsson.se> References: <20101217234501.11691.81147.idtracker@localhost> <63416880-97B6-4CE4-864A-1402DA977B5F@tony.li> <4D113364.3050105@ericsson.com> <201101032040.p03KeE86005244@cichlid.raleigh.ibm.com> <4D223EC0.7020906@gmail.com> <4D2242E9.8040804@gont.com.ar> <201101041429.p04ET81p006364@cichlid.raleigh.ibm.com> <4D23563E.7000108@gont.com.ar> <4D235845.6040409@joelhalpern.com> In-Reply-To: <4D235845.6040409@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 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, 05 Jan 2011 10:23:09 -0000 Hi Joel,=20 > -----Original Message----- > From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On=20 > Behalf Of Joel M. Halpern > Sent: Tuesday, January 04, 2011 12:26 PM > To: Fernando Gont > Cc: ipv6@ietf.org > Subject: Re: I-D Action:draft-ietf-6man-exthdr-01.txt >=20 > Then what about if we forget firewalls for the moment? >=20 > A lot of routers look for the TCP/UDP Port numbers for=20 > LAG/ECMP computation. > Many of them can cope with having a destination options=20 > extension, and therefore that is clearly the better way to=20 > handle such information.=20 > And anything we do should make that strong preference clear. >=20 > Nothing we can do can change the way routers with silicon=20 > already deployed handle unknown extension headers. >=20 > Given that, one option is to just say that new extension=20 > headers should not be used. >=20 > If we think that there will be some new extension headers,=20 > that we want to support, designed for the general Internet,=20 > then it would seem to make sense to try to get new behavior=20 > defined, supported, and then used, that will allow for such=20 > extensions. In that case, requiring and documenting the=20 > requirement for new extension headers to use TLV encoding=20 > would seem to have applicability and utility. I agree with you completely. This seems to be the very least we need to do.= I would appreciate your response to=20 http://www.ietf.org/mail-archive/web/ipv6/current/msg13207.html Thanks Suresh= From jmh@joelhalpern.com Wed Jan 5 04:42: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 CAD3A3A6B92 for ; Wed, 5 Jan 2011 04:42:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.529 X-Spam-Level: X-Spam-Status: No, score=-102.529 tagged_above=-999 required=5 tests=[AWL=0.070, 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 0GiwIVUS42j4 for ; Wed, 5 Jan 2011 04:42:39 -0800 (PST) Received: from hgblob.mail.tigertech.net (hgblob.mail.tigertech.net [64.62.209.71]) by core3.amsl.com (Postfix) with ESMTP id 20E803A6B6B for ; Wed, 5 Jan 2011 04:42:39 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hgblob.tigertech.net (Postfix) with ESMTP id 3944A32459AC; Wed, 5 Jan 2011 04:44:46 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from [10.10.10.101] (pool-71-161-51-19.clppva.btas.verizon.net [71.161.51.19]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by hgblob.tigertech.net (Postfix) with ESMTPSA id A5C193228BE3; Wed, 5 Jan 2011 04:44:45 -0800 (PST) Message-ID: <4D2467B8.3090306@joelhalpern.com> Date: Wed, 05 Jan 2011 07:44:40 -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: Suresh Krishnan Subject: Re: I-D Action:draft-ietf-6man-exthdr-01.txt References: <20101217234501.11691.81147.idtracker@localhost> <63416880-97B6-4CE4-864A-1402DA977B5F@tony.li> <4D113364.3050105@ericsson.com> <201101032040.p03KeE86005244@cichlid.raleigh.ibm.com> <4D223EC0.7020906@gmail.com> <4D2242E9.8040804@gont.com.ar> <201101041429.p04ET81p006364@cichlid.raleigh.ibm.com> <4D23563E.7000108@gont.com.ar> <4D235845.6040409@joelhalpern.com> <4FD1E7CD248BF84F86BD4814EDDDBCC150E9C64861@EUSAACMS0703.eamcs.ericsson.se> In-Reply-To: <4FD1E7CD248BF84F86BD4814EDDDBCC150E9C64861@EUSAACMS0703.eamcs.ericsson.se> 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: Wed, 05 Jan 2011 12:42:39 -0000 For clarity, in terms of the pieces of your original note: I consider (a), specifying the format at least to the level of requiring TLV encoding, to be a good idea. I do not see any particular advantage in (b), allocating a code point, but I can live with it if the WG wants it. And (c), changing the RFC 2460 mandate on error and drop handling, and replacing it with the details used in destination option bothers me. It seems to me we should have a strong reason for changing what was agreed. Also, any usage of such bits will have to allow for existing destinations, which will ignore such bits. Still, if we want to make using the extension headers easy, we should add the flag bits. But I don't know that we want to make it easy. Just possible, if we really, badly, need to do it. Yours, Joel On 1/5/2011 5:25 AM, Suresh Krishnan wrote: ... > I would appreciate your response to > > http://www.ietf.org/mail-archive/web/ipv6/current/msg13207.html > > Thanks > Suresh From manav.bhatia@alcatel-lucent.com Wed Jan 5 04:55: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 CCEF83A6E1D for ; Wed, 5 Jan 2011 04:55:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.173 X-Spam-Level: X-Spam-Status: No, score=-5.173 tagged_above=-999 required=5 tests=[AWL=1.426, 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 3yKBUv0uKxGJ for ; Wed, 5 Jan 2011 04:55:01 -0800 (PST) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by core3.amsl.com (Postfix) with ESMTP id F3A9E3A6B6B for ; Wed, 5 Jan 2011 04:55:00 -0800 (PST) Received: from inbansmailrelay2.in.alcatel-lucent.com (h135-250-11-33.lucent.com [135.250.11.33]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id p05Cv0S0008298 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 5 Jan 2011 06:57:04 -0600 (CST) Received: from INBANSXCHHUB01.in.alcatel-lucent.com (inbansxchhub01.in.alcatel-lucent.com [135.250.12.32]) by inbansmailrelay2.in.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p05CuvRZ009568 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 5 Jan 2011 18:26:58 +0530 Received: from INBANSXCHMBSA1.in.alcatel-lucent.com ([135.250.12.56]) by INBANSXCHHUB01.in.alcatel-lucent.com ([135.250.12.32]) with mapi; Wed, 5 Jan 2011 18:26:57 +0530 From: "Bhatia, Manav (Manav)" To: "Joel M. Halpern" , Suresh Krishnan Date: Wed, 5 Jan 2011 18:26:56 +0530 Subject: RE: I-D Action:draft-ietf-6man-exthdr-01.txt Thread-Topic: I-D Action:draft-ietf-6man-exthdr-01.txt Thread-Index: Acus1mdij77lhbH7Rz2NYPnXm1yaAAAAXm2Q Message-ID: <7C362EEF9C7896468B36C9B79200D8350CFAF7FEF0@INBANSXCHMBSA1.in.alcatel-lucent.com> References: <20101217234501.11691.81147.idtracker@localhost> <63416880-97B6-4CE4-864A-1402DA977B5F@tony.li> <4D113364.3050105@ericsson.com> <201101032040.p03KeE86005244@cichlid.raleigh.ibm.com> <4D223EC0.7020906@gmail.com> <4D2242E9.8040804@gont.com.ar> <201101041429.p04ET81p006364@cichlid.raleigh.ibm.com> <4D23563E.7000108@gont.com.ar> <4D235845.6040409@joelhalpern.com> <4FD1E7CD248BF84F86BD4814EDDDBCC150E9C64861@EUSAACMS0703.eamcs.ericsson.se> <4D2467B8.3090306@joelhalpern.com> In-Reply-To: <4D2467B8.3090306@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.35 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: Wed, 05 Jan 2011 12:55:01 -0000 =20 >=20 > For clarity, in terms of the pieces of your original note: >=20 > I consider (a), specifying the format at least to the level=20 > of requiring=20 > TLV encoding, to be a good idea. I agree to this. I think there is value in specifying a format that all subsequent extension= headers MUST use. Cheers, Manav >=20 > I do not see any particular advantage in (b), allocating a=20 > code point,=20 > but I can live with it if the WG wants it. >=20 > And (c), changing the RFC 2460 mandate on error and drop=20 > handling, and=20 > replacing it with the details used in destination option=20 > bothers me. It=20 > seems to me we should have a strong reason for changing what=20 > was agreed.=20 > Also, any usage of such bits will have to allow for existing=20 > destinations, which will ignore such bits. Still, if we want to make=20 > using the extension headers easy, we should add the flag bits. But I=20 > don't know that we want to make it easy. Just possible, if=20 > we really,=20 > badly, need to do it. >=20 > Yours, > Joel >=20 > On 1/5/2011 5:25 AM, Suresh Krishnan wrote: > ... > > I would appreciate your response to > > > > http://www.ietf.org/mail-archive/web/ipv6/current/msg13207.html > > > > Thanks > > Suresh > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > = From manav.bhatia@alcatel-lucent.com Wed Jan 5 05:03: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 926F03A6E29 for ; Wed, 5 Jan 2011 05:03:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.283 X-Spam-Level: X-Spam-Status: No, score=-5.283 tagged_above=-999 required=5 tests=[AWL=1.316, 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 aN4dREM4y-jJ for ; Wed, 5 Jan 2011 05:03:01 -0800 (PST) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by core3.amsl.com (Postfix) with ESMTP id 8FD4F3A6DDC for ; Wed, 5 Jan 2011 05:03:01 -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 p05D4udF004915 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 5 Jan 2011 07:05:00 -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 p05D4suK010057 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 5 Jan 2011 18:34:55 +0530 Received: from INBANSXCHMBSA1.in.alcatel-lucent.com ([135.250.12.56]) by INBANSXCHHUB03.in.alcatel-lucent.com ([135.250.12.80]) with mapi; Wed, 5 Jan 2011 18:34:54 +0530 From: "Bhatia, Manav (Manav)" To: Fernando Gont , Brian E Carpenter Date: Wed, 5 Jan 2011 18:34:53 +0530 Subject: RE: I-D Action:draft-ietf-6man-exthdr-01.txt Thread-Topic: I-D Action:draft-ietf-6man-exthdr-01.txt Thread-Index: Acurj1A0Vq33CGsTQvqfIRC4OVKkmQBSQwWA Message-ID: <7C362EEF9C7896468B36C9B79200D8350CFAF7FEF6@INBANSXCHMBSA1.in.alcatel-lucent.com> References: <20101217234501.11691.81147.idtracker@localhost> <63416880-97B6-4CE4-864A-1402DA977B5F@tony.li> <4D113364.3050105@ericsson.com> <201101032040.p03KeE86005244@cichlid.raleigh.ibm.com> <4D223EC0.7020906@gmail.com> <4D2242E9.8040804@gont.com.ar> In-Reply-To: <4D2242E9.8040804@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: Thomas Narten , Suresh, "ipv6@ietf.org" , Krishnan 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, 05 Jan 2011 13:03:02 -0000 I see another application of this extension. Assume you are the end host th= at wants to prioritize certain packets or wants to implement Access control= lists (ACLs). In the absence of this extension a router cannot apply ACLs = as it will never know how to parse the packet in case it comes across an un= known extension header. It can, if it supports this extension. ALso note th= at the default action of an ACL may not necessarily be "deny all". Cheers, Manav > -----Original Message----- > From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On=20 > Behalf Of Fernando Gont > Sent: Tuesday, January 04, 2011 3.13 AM > To: Brian E Carpenter > Cc: Thomas Narten; ipv6@ietf.org; Suresh Krishnan > Subject: Re: I-D Action:draft-ietf-6man-exthdr-01.txt >=20 > On 03/01/2011 06:25 p.m., Brian E Carpenter wrote: >=20 > > The basic motivation for the present draft is clear: > >=20 > >> However, > >> some intermediate nodes such as firewalls, may need to=20 > look at the > >> transport layer header fields in order to make a=20 > decision to allow or > >> deny the packet. =20 > >=20 > > That is, help middleboxes to violate e2e transparency and,=20 > furthermore, > > allow unknown headers to cross those middleboxes.=20 >=20 > I don't think this I-D will make a difference. >=20 > From the POV of a firewall, unless it really wants a packet to > pass-through, it will block it. >=20 > So, whether the Extension Header is unknown, or whether > draft-ietf-6man-exthdr-01.txt is implemented and the Specific type is > unknown will lead to the same result: the packet will be discarded. >=20 > This proposal would only be useful to firewalls that implement a > "default allow", and that simply want to somehow ignore an unknown > extension header and base their decision on the upper-layer protocol > (only). -- But we all know that firewalls operate (or should=20 > operate) in > "default deny" rather than "default allow". >=20 > So IMHO this proposal won't be useful for such firewalls. >=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 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > = From rja.lists@gmail.com Wed Jan 5 05:13: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 4E7D13A6E37 for ; Wed, 5 Jan 2011 05:13:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.384 X-Spam-Level: X-Spam-Status: No, score=-3.384 tagged_above=-999 required=5 tests=[AWL=0.215, 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 cAr3rl55cH6J for ; Wed, 5 Jan 2011 05:13:17 -0800 (PST) Received: from mail-qy0-f172.google.com (mail-qy0-f172.google.com [209.85.216.172]) by core3.amsl.com (Postfix) with ESMTP id 3ED663A6C05 for ; Wed, 5 Jan 2011 05:13:17 -0800 (PST) Received: by qyk34 with SMTP id 34so17399027qyk.10 for ; Wed, 05 Jan 2011 05:15:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:subject:mime-version :content-type:from:in-reply-to:date:cc:content-transfer-encoding :message-id:references:to:x-mailer; bh=oIkx+5j1AKj7ZvOqH3vOOIum48+D+r5LEV8MczlwfDY=; b=hP80bDxP1MRuex8XZSHjjWh/QQzKilefhrq7PyiYf0n4OnSN0ckHrlqEHTyYrAG5Gz QrGFKVHWuIK3+HZxHrTHZlKfHdJFXF36pkD0F9YJIiT+AnqIm4JUF5TYdj9GgowpgXC6 rpXWf/xhmME/LM1/agmnITxVrykWUWQtgdyYM= 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=rxgRL4F0MRvSGuhJEQt+sqrtX7SenjnKbMCRAPFjo8bJrRScm+dlo3NY23oEaPMjOD B1d7/YVdfaVMwcIVY7a44dbfiParwd7/nkH6fIesfKRgh7Q6h/J6P33iJfmSdLVtYQNp +fqweAnWQbjsUNt0D4pa3F/ZIbHL58TJrc92s= Received: by 10.224.135.208 with SMTP id o16mr15538378qat.252.1294233322482; Wed, 05 Jan 2011 05:15: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 p13sm13552224qcu.17.2011.01.05.05.15.21 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 05 Jan 2011 05:15:21 -0800 (PST) Subject: Re: I-D Action:draft-ietf-6man-exthdr-01.txt Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: RJ Atkinson In-Reply-To: <4FD1E7CD248BF84F86BD4814EDDDBCC150E9C6485F@EUSAACMS0703.eamcs.ericsson.se> Date: Wed, 5 Jan 2011 08:15:18 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <5741B0CD-4A89-4DEE-A34D-D7513EEF64C9@gmail.com> References: <4FD1E7CD248BF84F86BD4814EDDDBCC150E9C6485F@EUSAACMS0703.eamcs.ericsson.se> To: Suresh Krishnan 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: Wed, 05 Jan 2011 13:13:18 -0000 On 05 Jan 2011, at 05:12 , Suresh Krishnan wrote: > I'm up for it :-). In fact I already suggested the meat in >=20 > http://www.ietf.org/mail-archive/web/ipv6/current/msg13207.html >=20 > "RFC2460 allows the use of both extension headers and destination = options in order to encode optional destination information in an IPv6 = packet. The use of destination options to encode this information, = provides more flexible handling characteristics and better backward = compatibility than using extension headers. Because of this, = implementations SHOULD use destination options as the preferred = mechanism for encoding optional destination information, and use a new = extension header only if destination options do not satisfy their needs. I apologise that I was not clear enough in my note yesterday. I was looking for something different from the text above. Specifically, I'm suggesting a 1 page (plus boilerplate) draft that has both less text and slightly different text. Here are the 3 key points that I'd like to see: A) Prohibiting new IPv6 Extension Headers outright,=20 as Joel has repeatedly suggested. This removes the narrow case where RFC-2460 allows Extension Headers, so the I-D would be an Update to RFC-2460. B) Mandating use of existing IPv6 headers instead in all cases. Obviously, the Destination Options Header is preferred=20 as it has the least impact on the transit infrastructure. (Remi gave an example yesterday that probably belongs as a new "Routing Type" for the existing IPv6 Routing Header.) C) No definition of any new IPv6 Extension Header, as per (A). Yours, Ran From rja.lists@gmail.com Wed Jan 5 06:48: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 869643A6C4F for ; Wed, 5 Jan 2011 06:48:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.349 X-Spam-Level: X-Spam-Status: No, score=-3.349 tagged_above=-999 required=5 tests=[AWL=0.250, 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 fHNVOB6jnp+K for ; Wed, 5 Jan 2011 06:48:07 -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 697613A6C48 for ; Wed, 5 Jan 2011 06:48:07 -0800 (PST) Received: by vws7 with SMTP id 7so6238619vws.31 for ; Wed, 05 Jan 2011 06:50:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:content-type :content-transfer-encoding:subject:date:message-id:to:mime-version :x-mailer; bh=zG8W48ecMtCdLGxBIAu0pCxwvFaJsAcVMknv1Vqo9CI=; b=ChIQCOj2SWx59JafLaH+scIiR1IqSRa4x+BQ7dQYbQchcqTK2IVc330qJhCPdVhbkC JQhqXcF722ZujMMKVi4nduXICTgumAILnhHG0V6ZHQ+wtT4gqZCnbp1xNR1PU8LOkYj/ Ixa/eJRTNKn3BiR9TrX7pYnCA5TbBY88PraA0= 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=KHkAdnHEoo8HfgLWZjQmfft7MbkE3Th/j+HihhQEEeAjBbRp3iJQo8j7EFYMFZbo1R Z5rJT0zuVlaZVAjLRRgSSHQlbB0ied62mRGA/PT7u04Omw5eijL+dkwfiS4ZVQiDb77B ohfW3soleP8V5EJK9BHF9mS9tkT0ig57+A+50= Received: by 10.220.186.132 with SMTP id cs4mr6910431vcb.196.1294239014128; Wed, 05 Jan 2011 06:50:14 -0800 (PST) Received: from vi-mhowell55.leclairryan.com ([38.103.42.150]) by mx.google.com with ESMTPS id u4sm4910565vch.12.2011.01.05.06.50.11 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 05 Jan 2011 06:50:13 -0800 (PST) From: RJ Atkinson Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: RE: I-D Action:draft-ietf-6man-exthdr-01.txt Date: Wed, 5 Jan 2011 09:50:08 -0500 Message-Id: <809C0AA6-B15C-44E0-8BB6-CFF10D94622E@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: Wed, 05 Jan 2011 14:48:08 -0000 Earlier, Manav wrote: > Assume you are the end host that wants to prioritize certain packets > or wants to implement Access control lists (ACLs). In the absence > of this extension a router cannot apply ACLs as it will never know how > to parse the packet in case it comes across an unknown extension header. Banning new extension headers and instead requiring use of existing *already supported by multiple routers* IPv6 headers is a much better, much more complete solution to the situation postulated above. It is practical to use the existing IPv6 headers. The existing headers are well designed and widely supported in deployed nodes today. I've specified enhancements using the existing headers twice so far. RFC-5570 is one example, while draft-rja-ilnp-nonce is another example. By contrast, specifying this new extension header both encourages new extensions (which is undesirable, as Joel H keeps observing) and more importantly *breaks* existing IPv6 deployments that use commercial routers that already can parse past the existing IPv6 extension headers to view transport-layer information (e.g. protocol and port numbers). Yours, Ran From brian.e.carpenter@gmail.com Wed Jan 5 12:13: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 9B9E83A6CBB for ; Wed, 5 Jan 2011 12:13:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.375 X-Spam-Level: X-Spam-Status: No, score=-103.375 tagged_above=-999 required=5 tests=[AWL=0.224, 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 f-ipo0XRUgVk for ; Wed, 5 Jan 2011 12:13:31 -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 84FB93A6C78 for ; Wed, 5 Jan 2011 12:13:31 -0800 (PST) Received: by fxm9 with SMTP id 9so15444263fxm.31 for ; Wed, 05 Jan 2011 12:15:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :organization:user-agent:mime-version:to:cc:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=PHhfbIF6NS/pm3ggyUs79/zlSuQc3qotRteN6eNyQiI=; b=cDzf58Q0pHukND3os20ap7Rk6N/4nye4SfVCYLJ6Rq1NMGsMkl4Zhn3lMaVk9Woznn Lyu3JPMd+147Eumy2dSOSt+zJesuVSRvY29WxjsIuL8kdMRLfA4CJd1A+mHRPiG9TvmR heJ0GyRQFLqitOoqzODl+6CHg8qAlEEowF/CE= 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=IMJVMZg9lxHsqblNG6Et5rw64LHZPyrDNTgzcvuPdyaHp+kZoVcUfPeLphgw0vobdA 3SLCmOej9vEus0JDu4lQG2ME3uyAc5Lj3fP9ZA7HZ8b7EcKpz+LTNjhG1X8ltBoQyorh ZH3SKS0gApOUh0FHleu+iRC2HLaNPdcveNbv4= Received: by 10.223.95.203 with SMTP id e11mr1548812fan.60.1294258537827; Wed, 05 Jan 2011 12:15:37 -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 n3sm5628862fax.7.2011.01.05.12.15.33 (version=SSLv3 cipher=RC4-MD5); Wed, 05 Jan 2011 12:15:35 -0800 (PST) Message-ID: <4D24D162.3040805@gmail.com> Date: Thu, 06 Jan 2011 09:15:30 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: RJ Atkinson Subject: Re: I-D Action:draft-ietf-6man-exthdr-01.txt References: <4FD1E7CD248BF84F86BD4814EDDDBCC150E9C6485F@EUSAACMS0703.eamcs.ericsson.se> <5741B0CD-4A89-4DEE-A34D-D7513EEF64C9@gmail.com> In-Reply-To: <5741B0CD-4A89-4DEE-A34D-D7513EEF64C9@gmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "ipv6@ietf.org" , Suresh Krishnan 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, 05 Jan 2011 20:13:32 -0000 On 2011-01-06 02:15, RJ Atkinson wrote: ... > A) Prohibiting new IPv6 Extension Headers outright, > as Joel has repeatedly suggested. This removes the > narrow case where RFC-2460 allows Extension Headers, > so the I-D would be an Update to RFC-2460. My reaction is that this is going too far, and isn't actually necessary. We have words in 2460 that already make it quite hard to define a new header. We have running code proof (in the form of non-existent IPv4 options) that it's in practice impractical to deploy such things, for exactly the reasons we've been discussing (routers are not forward-compatible, and firewalls block unknowns by default, both being partially embedded in silicon). But who knows what the future may bring, in 20 or 40 years from now? So I am more inclined to a SHOULD NOT approach; I think I'm agreeing with a somewhat stronger version of Suresh's proposed paragraph. At least, add ...accompanied by ... and a convincing explanation of a successful progressive deployment model for the proposed new header. Brian From rja.lists@gmail.com Wed Jan 5 13:54: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 A7A343A6D1C for ; Wed, 5 Jan 2011 13:54:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.385 X-Spam-Level: X-Spam-Status: No, score=-3.385 tagged_above=-999 required=5 tests=[AWL=0.214, 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 UV5aWti9BMzs for ; Wed, 5 Jan 2011 13:54:53 -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 B59D33A6D18 for ; Wed, 5 Jan 2011 13:54:53 -0800 (PST) Received: by qyj19 with SMTP id 19so17107250qyj.10 for ; Wed, 05 Jan 2011 13:57:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:content-type:mime-version :subject:from:in-reply-to:date:content-transfer-encoding:message-id :references:to:x-mailer; bh=atgiHmXXGlsh2+MHYLxF9d1Ka9kbtC6m3CtBN7YHPl0=; b=DkcHtEDXKVOwiVWDPxc2hHDROpIEtAOc3PgH3i59jufgYNZWd4mojs6hEU5spmqt91 iGjyII2a+Ss/OgOFXI/59Qfhn/Vf2Khg3FKH6nCbwjCaEdG2g0DuBCRd/14ItghBNz8/ KWOINPkg0T4CQgKNz1g0V/9bkFJ7ohPSV1EYE= 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=dEqEbi7+Cfqy7RvftK/pIuNt6C5Fmuln+J1GepWFjoldU3KsX8OMQrpn4KH7XkRISd F97nSUQJccGA3OVT+EtRWb1pwmJ8kq6Qa9fCFcLcf9AOflSD9ug4/y2sNOzrXSf5RNK0 ldt1J3PRBppG2ml1j9zJPr7k+64xNXhhNWvEs= Received: by 10.224.54.65 with SMTP id p1mr21826679qag.241.1294264620257; Wed, 05 Jan 2011 13:57:00 -0800 (PST) Received: from vi-mhowell55.leclairryan.com ([38.103.42.150]) by mx.google.com with ESMTPS id m14sm13865631qcu.20.2011.01.05.13.56.58 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 05 Jan 2011 13:56:59 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1082) Subject: Re: I-D Action:draft-ietf-6man-exthdr-01.txt From: RJ Atkinson In-Reply-To: <4D24D162.3040805@gmail.com> Date: Wed, 5 Jan 2011 16:56:57 -0500 Content-Transfer-Encoding: 7bit Message-Id: <0459FF2F-B20A-4AE6-9EEF-E78A734DD8E7@gmail.com> References: <4FD1E7CD248BF84F86BD4814EDDDBCC150E9C6485F@EUSAACMS0703.eamcs.ericsson.se> <5741B0CD-4A89-4DEE-A34D-D7513EEF64C9@gmail.com> <4D24D162.3040805@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: Wed, 05 Jan 2011 21:54:54 -0000 On 05 Jan 2011, at 15:15 , Brian E Carpenter wrote: > On 2011-01-06 02:15, RJ Atkinson wrote: > ... >> A) Prohibiting new IPv6 Extension Headers outright, >> as Joel has repeatedly suggested. This removes the >> narrow case where RFC-2460 allows Extension Headers, >> so the I-D would be an Update to RFC-2460. > > My reaction is that this is going too far, and isn't actually > necessary. We have words in 2460 that already make it quite hard > to define a new header. We have running code proof (in the form of > non-existent IPv4 options) that it's in practice impractical to > deploy such things, for exactly the reasons we've been discussing > (routers are not forward-compatible, and firewalls block unknowns > by default, both being partially embedded in silicon). > > But who knows what the future may bring, in 20 or 40 years from now? There is a kind of procedural elegance lurking here that is worth highlighting. While you probably realise this due to your IESG experience, perhaps others on the list haven't considered the implications resulting from IETF processes. If some future instance of the IETF really believes they need to change things away from an outright prohibition on new IPv6 related extension headers, then revising the prohibition (e.g. to allow for some hypothetical legitimate need) is precisely the same process (i.e. standards action) as Suresh's proposed restraint upon creating IPv6 enhancements using a new header. Put another way, no current IETF action can really prohibit the future IETF from undertaking something that the future IETF really thinks ought to be undertaken. The practical difference is that the IETF will think VERY carefully about reversing a previous decision, whereas it might not apply the same level of thought about allowing a new enhancement where the standards-track documents explicitly allow that. Some of us think it would be valuable to have maximum thought before allowing any new IPv6 headers to be created. Cheers, Ran From remi.despres@free.fr Thu Jan 6 05:18: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 BC6A43A6E28 for ; Thu, 6 Jan 2011 05:18:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.138 X-Spam-Level: X-Spam-Status: No, score=-0.138 tagged_above=-999 required=5 tests=[AWL=-0.789, BAYES_50=0.001, HELO_EQ_FR=0.35, 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 RKSNkvhBpdxb for ; Thu, 6 Jan 2011 05:18:06 -0800 (PST) Received: from smtp23.services.sfr.fr (smtp23.services.sfr.fr [93.17.128.19]) by core3.amsl.com (Postfix) with ESMTP id 5D77F3A6CAA for ; Thu, 6 Jan 2011 05:18:06 -0800 (PST) Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2319.sfr.fr (SMTP Server) with ESMTP id 56C657000099; Thu, 6 Jan 2011 14:20:12 +0100 (CET) Received: from [192.168.0.20] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by msfrf2319.sfr.fr (SMTP Server) with ESMTP id C60DB7000098; Thu, 6 Jan 2011 14:20:11 +0100 (CET) X-SFR-UUID: 20110106132011811.C60DB7000098@msfrf2319.sfr.fr Subject: Re: I-D Action:draft-ietf-6man-exthdr-01.txt Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: <4D2467B8.3090306@joelhalpern.com> Date: Thu, 6 Jan 2011 14:20:09 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <77491E21-F783-4858-A6C2-099AAA0A3E3A@free.fr> References: <20101217234501.11691.81147.idtracker@localhost> <63416880-97B6-4CE4-864A-1402DA977B5F@tony.li> <4D113364.3050105@ericsson.com> <201101032040.p03KeE86005244@cichlid.raleigh.ibm.com> <4D223EC0.7020906@gmail.com> <4D2242E9.8040804@gont.com.ar> <201101041429.p04ET81p006364@cichlid.raleigh.ibm.com> <4D23563E.7000108@gont.com.ar> <4D235845.6040409@joelhalpern.com> <4FD1E7CD248BF84F86BD4814EDDDBCC150E9C64861@EUSAACMS0703.eamcs.ericsson.se> <4D2467B8.3090306@joelhalpern.com> To: Suresh Krishnan 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: Thu, 06 Jan 2011 13:18:07 -0000 Le 5 janv. 2011 =E0 13:44, Joel M. Halpern a =E9crit : > ... > I consider (a), specifying the format at least to the level of = requiring TLV encoding, to be a good idea. +1 From remi.despres@free.fr Thu Jan 6 05:24: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 CF7C03A6E3C for ; Thu, 6 Jan 2011 05:24:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.501 X-Spam-Level: X-Spam-Status: No, score=-0.501 tagged_above=-999 required=5 tests=[AWL=-0.411, BAYES_20=-0.74, HELO_EQ_FR=0.35, 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 VWq3I5YTVRTn for ; Thu, 6 Jan 2011 05:24:30 -0800 (PST) Received: from smtp23.services.sfr.fr (smtp23.services.sfr.fr [93.17.128.19]) by core3.amsl.com (Postfix) with ESMTP id AB68A3A6E28 for ; Thu, 6 Jan 2011 05:24:30 -0800 (PST) Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2319.sfr.fr (SMTP Server) with ESMTP id 5228F70000A2; Thu, 6 Jan 2011 14:26:37 +0100 (CET) Received: from [192.168.0.20] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by msfrf2319.sfr.fr (SMTP Server) with ESMTP id 2798C70000A1; Thu, 6 Jan 2011 14:26:37 +0100 (CET) X-SFR-UUID: 20110106132637162.2798C70000A1@msfrf2319.sfr.fr Subject: Re: I-D Action:draft-ietf-6man-exthdr-01.txt Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: <4D24D162.3040805@gmail.com> Date: Thu, 6 Jan 2011 14:26:35 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4FD1E7CD248BF84F86BD4814EDDDBCC150E9C6485F@EUSAACMS0703.eamcs.ericsson.se> <5741B0CD-4A89-4DEE-A34D-D7513EEF64C9@gmail.com> <4D24D162.3040805@gmail.com> To: Suresh Krishnan X-Mailer: Apple Mail (2.1082) Cc: 6man 6man , Brian 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: Thu, 06 Jan 2011 13:24:32 -0000 Le 5 janv. 2011 =E0 21:15, Brian E Carpenter a =E9crit : > On 2011-01-06 02:15, RJ Atkinson wrote: > ... >> Prohibiting new IPv6 Extension Headers outright,=20 >> ... > My reaction is that this is going too far, +1 > ... > So I am more inclined to a SHOULD NOT approach; I think I'm agreeing > with a somewhat stronger version of Suresh's proposed paragraph. > At least, add >=20 > ...accompanied by ... and a convincing explanation of a successful > progressive deployment model for the proposed new header. This seems to me a good compromise. +1 RD From brian@innovationslab.net Thu Jan 6 06:00: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 212083A6F1F for ; Thu, 6 Jan 2011 06:00:37 -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 ogs-9laQjRhZ for ; Thu, 6 Jan 2011 06:00:36 -0800 (PST) Received: from uillean.fuaim.com (uillean.fuaim.com [206.197.161.140]) by core3.amsl.com (Postfix) with ESMTP id 512233A6F1D for ; Thu, 6 Jan 2011 06:00:36 -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 B27AE88237 for ; Thu, 6 Jan 2011 06:02:42 -0800 (PST) Received: from clemson.local (c-76-100-105-215.hsd1.md.comcast.net [76.100.105.215]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by clairseach.fuaim.com (Postfix) with ESMTP id 121ED1369380 for ; Thu, 6 Jan 2011 06:02:41 -0800 (PST) Message-ID: <4D25CB80.8060104@innovationslab.net> Date: Thu, 06 Jan 2011 09:02:40 -0500 From: Brian Haberman User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: IPv6 WG Mailing List Subject: Agenda requests for IETF 80 X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 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: Thu, 06 Jan 2011 14:00:37 -0000 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 From tony.li@tony.li Thu Jan 6 08:50:49 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 107003A6D79 for ; Thu, 6 Jan 2011 08:50:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.447 X-Spam-Level: X-Spam-Status: No, score=-102.447 tagged_above=-999 required=5 tests=[AWL=0.152, 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 Rqn8qkdpmmOX for ; Thu, 6 Jan 2011 08:50:46 -0800 (PST) Received: from qmta13.westchester.pa.mail.comcast.net (qmta13.westchester.pa.mail.comcast.net [76.96.59.243]) by core3.amsl.com (Postfix) with ESMTP id 978093A6C4F for ; Thu, 6 Jan 2011 08:50:45 -0800 (PST) Received: from omta02.westchester.pa.mail.comcast.net ([76.96.62.19]) by qmta13.westchester.pa.mail.comcast.net with comcast id sGH31f0070QuhwU5DGstSL; Thu, 06 Jan 2011 16:52:53 +0000 Received: from sjc-vpn3-141.cisco.com ([128.107.239.233]) by omta02.westchester.pa.mail.comcast.net with comcast id sGsU1f00V52qHCY3NGshjR; Thu, 06 Jan 2011 16:52:50 +0000 Subject: Re: Need your input on draft-ietf-6man-exthdr Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Tony Li In-Reply-To: <4D21CD00.1030906@ericsson.com> Date: Thu, 6 Jan 2011 08:52:27 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4D21CD00.1030906@ericsson.com> To: Suresh Krishnan X-Mailer: Apple Mail (2.1082) 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: Thu, 06 Jan 2011 16:50:49 -0000 On Jan 3, 2011, at 5:20 AM, Suresh Krishnan wrote: > a) Specifying a uniform format for all future IPv6 extension headers = to > make them easier to parse/process. Support > b) Requesting a single IP protocol number codepoint for all future > extension headers and multiplexing them using a Specific Type field > inside the generic header. Object: We have not demonstrated necessity. > c) Specifying error-handling and drop behavior for dealing with = unknown > extension headers. This turns out to be a corollary of a), so I support this as well. Once = you say that things are a TLV, the behavior should be obvious to one = skilled in the art. Tony From jhw@apple.com Thu Jan 6 10:26: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 899E23A6F34 for ; Thu, 6 Jan 2011 10:26:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.549 X-Spam-Level: X-Spam-Status: No, score=-106.549 tagged_above=-999 required=5 tests=[AWL=0.050, 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 1zl5Xf6tdt9Z for ; Thu, 6 Jan 2011 10:26:14 -0800 (PST) Received: from mail-out4.apple.com (mail-out.apple.com [17.254.13.23]) by core3.amsl.com (Postfix) with ESMTP id B30EB3A6EFE for ; Thu, 6 Jan 2011 10:26:14 -0800 (PST) Received: from relay11.apple.com (relay11.apple.com [17.128.113.48]) by mail-out4.apple.com (Postfix) with ESMTP id A8AA2C9B8DD2 for ; Thu, 6 Jan 2011 10:28:21 -0800 (PST) X-AuditID: 11807130-b7cb4ae000001037-e6-4d2609c507bc Received: from et.apple.com (et.apple.com [17.151.62.12]) by relay11.apple.com (Apple SCV relay) with SMTP id 14.D9.04151.5C9062D4; Thu, 6 Jan 2011 10:28:21 -0800 (PST) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=us-ascii Received: from [17.153.53.221] by et.apple.com (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008; 32bit)) with ESMTPSA id <0LEM0042H5Z8AU00@et.apple.com> for ipv6@ietf.org; Thu, 06 Jan 2011 10:28:21 -0800 (PST) Subject: Re: I-D Action:draft-ietf-6man-exthdr-01.txt From: james woodyatt In-reply-to: <4D2242E9.8040804@gont.com.ar> Date: Thu, 06 Jan 2011 10:28:20 -0800 Message-id: <7F0B66FC-96A2-40A1-B0AB-7C96A7E0CBE7@apple.com> References: <20101217234501.11691.81147.idtracker@localhost> <63416880-97B6-4CE4-864A-1402DA977B5F@tony.li> <4D113364.3050105@ericsson.com> <201101032040.p03KeE86005244@cichlid.raleigh.ibm.com> <4D223EC0.7020906@gmail.com> <4D2242E9.8040804@gont.com.ar> To: Fernando Gont X-Mailer: Apple Mail (2.1082) X-Brightmail-Tracker: AAAAAA== Cc: 6man Group 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, 06 Jan 2011 18:26:15 -0000 On Jan 3, 2011, at 13:43, Fernando Gont wrote: > > From the POV of a firewall, unless it really wants a packet to pass-through, it will block it. That's an unwarranted assumption. Consider the "firewall" described in I-D.ietf-v6ops-cpe-simple-security, which is intended to block only unsolicited inbound traffic. Once residential gateways that implement IPv6 Simple Security are ubiquitous, it will not be practical to introduce any new extension headers that these firewall appliances do not recognize. If they can't parse past the new extension header to inspect the upper-layer transport header, then they can't record state that will allow packets for the *solicited* return path. In other words, they're still forwarded, but the return path they're meant to solicit cannot be recorded. -- james woodyatt member of technical staff, communications engineering From brian@innovationslab.net Fri Jan 7 07:20: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 9B8723A67F4 for ; Fri, 7 Jan 2011 07:20:21 -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 Cyl6IRriKg7j for ; Fri, 7 Jan 2011 07:20:18 -0800 (PST) Received: from uillean.fuaim.com (uillean.fuaim.com [206.197.161.140]) by core3.amsl.com (Postfix) with ESMTP id CCD103A67E9 for ; Fri, 7 Jan 2011 07:20:18 -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 EFDF188223; Fri, 7 Jan 2011 07:22:24 -0800 (PST) Received: from clemson.local (c-76-100-105-215.hsd1.md.comcast.net [76.100.105.215]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by clairseach.fuaim.com (Postfix) with ESMTP id BD6051369384; Fri, 7 Jan 2011 07:22:23 -0800 (PST) Message-ID: <4D272FAC.70104@innovationslab.net> Date: Fri, 07 Jan 2011 10:22:20 -0500 From: Brian Haberman User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: ipv6@ietf.org Subject: 6MAN WG Last Call: draft-ietf-6man-flow-ecmp-00.txt X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: 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: Fri, 07 Jan 2011 15:20:21 -0000 All, This message starts a 6MAN WG Last Call on advancing: 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-00.txt Pages : 9 Date : 2010-12-01 as a Best Current Practice (BCP). Substantive comments should be sent to the mailing list. Editorial comments can be directed to the document editors. This last call will end on January 21, 2011. Regards, Brian & Bob From daniel.gavelle@nxp.com Fri Jan 7 07:25: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 448423A6900; Fri, 7 Jan 2011 07:25:51 -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 pLuHRawyOQJ8; Fri, 7 Jan 2011 07:25:50 -0800 (PST) Received: from be1ssnxpe2.nxp.com (be1ssnxpe2.nxp.com [57.67.164.70]) by core3.amsl.com (Postfix) with ESMTP id A473E3A68F5; Fri, 7 Jan 2011 07:25:49 -0800 (PST) Received: from EU1RDCRDC1VW025.exi.nxp.com ([134.27.176.170]) by be1ssnxpe2.nxp.com (8.14.3/8.14.3) with ESMTP id p07FRth3026749 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 7 Jan 2011 16:27:55 +0100 Received: from eu1rdcrdc1wx032.exi.nxp.com ([134.27.179.186]) by EU1RDCRDC1VW025.exi.nxp.com ([134.27.176.170]) with mapi; Fri, 7 Jan 2011 16:27:55 +0100 From: Daniel Gavelle To: "roll@ietf.org" , "ipv6@ietf.org" Date: Fri, 7 Jan 2011 16:27:53 +0100 Subject: Discrepancy between draft-ietf-roll-rpl-17 and draft-ietf-6man-rpl-routing-header-01 Thread-Topic: Discrepancy between draft-ietf-roll-rpl-17 and draft-ietf-6man-rpl-routing-header-01 Thread-Index: AcuufmaG0pqVYcizQIi6P/58PErhOAAADbtg Message-ID: <78B923726E7D59429936580CF127E943A13214D942@eu1rdcrdc1wx032.exi.nxp.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-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.2.15, 1.0.148, 0.0.0000 definitions=2011-01-07_07:2011-01-07, 2011-01-07, 1970-01-01 signatures=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, 07 Jan 2011 15:25:51 -0000 A discrepancy between the ROLL and 6man-rpl-routing-header draft was spotte= d a few weeks ago. I haven't seen any comments on this on the ROLL list. = I've posted it to the 6Man list as it also affects a draft in this WG. It = is important that everyone generates the destination unreachable in the sam= e way because the RPL root node will process the destination unreachable to= determine which link has failed. Daniel. -------- Original Message -------- Subject: Re: [Roll] I-D Action:draft-ietf-roll-rpl-17.txt Date: Fri, 17 Dec 2010 14:40:24 -0800 From: Dario Tedeschi To: Internet-Drafts@ietf.org CC: roll@ietf.org, i-d-announce@ietf.org References: <20101215230001.30256.8767.idtracker@localhost> There seems to be a discrepancy between draft-ietf-roll-rpl-17 and draft-ietf-6man-rpl-routing-header-01: The following pseudo code in the RPL RH draft: else if i < n and Address[i] is not on-link { send an ICMP Destination Unreachable, Code 7, message to <--*** the Source Address and discard the packet } else { swap the IPv6 Destination Address and Address[i] <--*** if the IPv6 Hop Limit is less than or equal to 1 { send an ICMP Time Exceeded -- Hop Limit Exceeded in Transit message to the Source Address and discard the packet } does not correlate with the following wording in the RPL draft (section 11.2.2.3): .... .... The "Error in Source Routing Header" message has the same format as the "Destination Unreachable Message" as specified in [RFC4443]. The portion of the invoking packet that is sent back in the ICMP message should record at least up to the routing header, and the routing header should be consumed by this node so that the destination in the IPv6 header is the next hop that this node could <--*** not reach. Dario On 15/12/2010 3:00 PM, Internet-Drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. > This draft is a work item of the Routing Over Low power and Lossy network= s Working Group of the IETF. > > > Title : RPL: IPv6 Routing Protocol for Low power and Lossy Net= works > Author(s) : T. Winter, et al. > Filename : draft-ietf-roll-rpl-17.txt > Pages : 159 > Date : 2010-12-15 > > Low power and Lossy Networks (LLNs) are a class of network in which=20 > both the routers and their interconnect are constrained. LLN routers=20 > typically operate with constraints on processing power, memory, and=20 > energy (battery power). Their interconnects are characterized by high=20 > loss rates, low data rates, and instability. LLNs are comprised of=20 > anything from a few dozen and up to thousands of routers. > Supported traffic flows include point-to-point (between devices inside=20 > the LLN), point-to-multipoint (from a central control point to a=20 > subset of devices inside the LLN), and multipoint-to-point (from=20 > devices inside the LLN towards a central control point). This=20 > document specifies the IPv6 Routing Protocol for LLNs (RPL), which=20 > provides a mechanism whereby multipoint-to-point traffic from devices=20 > inside the LLN towards a central control point, as well as point-to-=20 > multipoint traffic from the central control point to the devices=20 > inside the LLN, is supported. Support for point-to-point traffic is=20 > also available. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-roll-rpl-17.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=20 > implementation to automatically retrieve the ASCII version of the=20 > Internet-Draft. > > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll Regards, Daniel. --=20 __________________________________________________ Daniel Gavelle, Software Team Leader Low Power RF Solutions (formerly Jennic Ltd.) NXP Semiconductors Furnival S= treet, Sheffield, S1 4QT, UK Tel: +44 114 281 2655 Fax: +44 114 281 2951 Comp Reg No: 3191371 - Registered In England http://www.nxp.com http://www.= jennic.com __________________________________________________ From pthubert@cisco.com Fri Jan 7 08:42: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 BB4D73A6842; Fri, 7 Jan 2011 08:42:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.32 X-Spam-Level: X-Spam-Status: No, score=-10.32 tagged_above=-999 required=5 tests=[AWL=0.279, 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 pYb2yL8Oc2fP; Fri, 7 Jan 2011 08:42:13 -0800 (PST) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id 6634E3A6909; Fri, 7 Jan 2011 08:42:13 -0800 (PST) Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEANrRJk2rR7Hu/2dsb2JhbACkKHOjP5gKgw6CPgSOLQ Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-4.cisco.com with ESMTP; 07 Jan 2011 16:44:20 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id p07GiG8C024730; Fri, 7 Jan 2011 16:44:19 GMT Received: from xmb-ams-107.cisco.com ([144.254.74.82]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 7 Jan 2011 17:44:17 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Roll] Discrepancy between draft-ietf-roll-rpl-17 and draft-ietf-6man-rpl-routing-header-01 Date: Fri, 7 Jan 2011 17:44:14 +0100 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D0385FB77@XMB-AMS-107.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] Discrepancy between draft-ietf-roll-rpl-17 and draft-ietf-6man-rpl-routing-header-01 Thread-Index: Acuuih1S3RQmBlNQTJyUzPtsXKbWjg== From: "Pascal Thubert (pthubert)" To: "Daniel Gavelle" , , X-OriginalArrivalTime: 07 Jan 2011 16:44:17.0057 (UTC) FILETIME=[1FB07910:01CBAE8A] 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, 07 Jan 2011 16:42:14 -0000 Hi Daniel: Thanks for the heads up. The text in RPL assumes that the node receives a packet, processes the RH (swaps the destination) and then forwards to the new next hop. If that fails, it seems easier to pass the resulting packet as it now stands than to recomputed the packet as it was received. I think the RH draft should adapt to that . Would you agree? Pascal http://www.xtranormal.com/watch/7011357/ > -----Original Message----- > From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of > Daniel Gavelle > Sent: Friday, January 07, 2011 4:28 PM > To: roll@ietf.org; ipv6@ietf.org > Subject: [Roll] Discrepancy between draft-ietf-roll-rpl-17 and draft-ietf- > 6man-rpl-routing-header-01 >=20 > A discrepancy between the ROLL and 6man-rpl-routing-header draft was > spotted a few weeks ago. I haven't seen any comments on this on the ROLL > list. I've posted it to the 6Man list as it also affects a draft in this WG. It is > important that everyone generates the destination unreachable in the same > way because the RPL root node will process the destination unreachable to > determine which link has failed. >=20 > Daniel. >=20 >=20 > -------- Original Message -------- > Subject: Re: [Roll] I-D Action:draft-ietf-roll-rpl-17.txt > Date: Fri, 17 Dec 2010 14:40:24 -0800 > From: Dario Tedeschi > To: Internet-Drafts@ietf.org > CC: roll@ietf.org, i-d-announce@ietf.org > References: <20101215230001.30256.8767.idtracker@localhost> >=20 >=20 >=20 > There seems to be a discrepancy between draft-ietf-roll-rpl-17 and > draft-ietf-6man-rpl-routing-header-01: >=20 > The following pseudo code in the RPL RH draft: >=20 > else if i < n and Address[i] is not on-link { > send an ICMP Destination Unreachable, Code 7, message to > <--*** > the Source Address and discard the packet > } > else { > swap the IPv6 Destination Address and Address[i] <--*** >=20 > if the IPv6 Hop Limit is less than or equal to 1 { > send an ICMP Time Exceeded -- Hop Limit Exceeded in > Transit message to the Source Address and discard the > packet > } >=20 >=20 > does not correlate with the following wording in the RPL draft (section > 11.2.2.3): >=20 > .... .... The "Error in Source Routing Header" > message has the > same format as the "Destination Unreachable Message" as specified in > [RFC4443]. The portion of the invoking packet that is sent back in > the ICMP message should record at least up to the routing header, and > the routing header should be consumed by this node so that the > destination in the IPv6 header is the next hop that this node could > <--*** > not reach. >=20 >=20 >=20 > Dario >=20 >=20 > On 15/12/2010 3:00 PM, Internet-Drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > This draft is a work item of the Routing Over Low power and Lossy > networks Working Group of the IETF. > > > > > > Title : RPL: IPv6 Routing Protocol for Low power and Lossy > Networks > > Author(s) : T. Winter, et al. > > Filename : draft-ietf-roll-rpl-17.txt > > Pages : 159 > > Date : 2010-12-15 > > > > Low power and Lossy Networks (LLNs) are a class of network in which > > both the routers and their interconnect are constrained. LLN routers > > typically operate with constraints on processing power, memory, and > > energy (battery power). Their interconnects are characterized by high > > loss rates, low data rates, and instability. LLNs are comprised of > > anything from a few dozen and up to thousands of routers. > > Supported traffic flows include point-to-point (between devices inside > > the LLN), point-to-multipoint (from a central control point to a > > subset of devices inside the LLN), and multipoint-to-point (from > > devices inside the LLN towards a central control point). This > > document specifies the IPv6 Routing Protocol for LLNs (RPL), which > > provides a mechanism whereby multipoint-to-point traffic from devices > > inside the LLN towards a central control point, as well as point-to- > > multipoint traffic from the central control point to the devices > > inside the LLN, is supported. Support for point-to-point traffic is > > also available. > > > > A URL for this Internet-Draft is: > > http://www.ietf.org/internet-drafts/draft-ietf-roll-rpl-17.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. > > > > > > _______________________________________________ > > Roll mailing list > > Roll@ietf.org > > https://www.ietf.org/mailman/listinfo/roll >=20 >=20 >=20 > Regards, >=20 > Daniel. >=20 > -- >=20 > __________________________________________________ >=20 > Daniel Gavelle, Software Team Leader > Low Power RF Solutions (formerly Jennic Ltd.) NXP Semiconductors Furnival > Street, Sheffield, S1 4QT, UK > Tel: +44 114 281 2655 > Fax: +44 114 281 2951 > Comp Reg No: 3191371 - Registered In England http://www.nxp.com > http://www.jennic.com > __________________________________________________ > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From daniel.gavelle@nxp.com Fri Jan 7 09:31: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 6FD2E3A693E; Fri, 7 Jan 2011 09:31:07 -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 N-2-p6X+B1-V; Fri, 7 Jan 2011 09:31:04 -0800 (PST) Received: from be1ssnxpe2.nxp.com (be1ssnxpe2.nxp.com [57.67.164.70]) by core3.amsl.com (Postfix) with ESMTP id E00103A6921; Fri, 7 Jan 2011 09:31:03 -0800 (PST) Received: from EU1RDCRDC1VW024.exi.nxp.com ([134.27.176.169]) by be1ssnxpe2.nxp.com (8.14.3/8.14.3) with ESMTP id p07HX5LN029399 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 7 Jan 2011 18:33:06 +0100 Received: from eu1rdcrdc1wx032.exi.nxp.com ([134.27.179.186]) by EU1RDCRDC1VW024.exi.nxp.com ([134.27.176.169]) with mapi; Fri, 7 Jan 2011 18:33:05 +0100 From: Daniel Gavelle To: "Pascal Thubert (pthubert)" , "roll@ietf.org" , "ipv6@ietf.org" Date: Fri, 7 Jan 2011 18:33:05 +0100 Subject: RE: [Roll] Discrepancy between draft-ietf-roll-rpl-17 and draft-ietf-6man-rpl-routing-header-01 Thread-Topic: [Roll] Discrepancy between draft-ietf-roll-rpl-17 and draft-ietf-6man-rpl-routing-header-01 Thread-Index: Acuuih1S3RQmBlNQTJyUzPtsXKbWjgABdWyg Message-ID: <78B923726E7D59429936580CF127E943A13214DDC4@eu1rdcrdc1wx032.exi.nxp.com> References: <6A2A459175DABE4BB11DE2026AA50A5D0385FB77@XMB-AMS-107.cisco.com> In-Reply-To: <6A2A459175DABE4BB11DE2026AA50A5D0385FB77@XMB-AMS-107.cisco.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-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.2.15, 1.0.148, 0.0.0000 definitions=2011-01-07_08:2011-01-07, 2011-01-07, 1970-01-01 signatures=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, 07 Jan 2011 17:31:07 -0000 Pascal, I agree that it is easier to swap the header before generating the response= . It also makes parsing the response on the root node easier, as the desti= nation address will be the address of the node that is no longer reachable.= =20 Daniel. -----Original Message----- From: Pascal Thubert (pthubert) [mailto:pthubert@cisco.com]=20 Sent: 07 January 2011 16:44 To: Daniel Gavelle; roll@ietf.org; ipv6@ietf.org Subject: RE: [Roll] Discrepancy between draft-ietf-roll-rpl-17 and draft-ie= tf-6man-rpl-routing-header-01 Hi Daniel: Thanks for the heads up. The text in RPL assumes that the node receives a packet, processes the RH (swaps the destination) and then forwards to the new next hop. If that fails, it seems easier to pass the resulting packet as it now stands than to recomputed the packet as it was received. I think the RH draft should adapt to that . Would you agree? Pascal http://www.xtranormal.com/watch/7011357/ > -----Original Message----- > From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of > Daniel Gavelle > Sent: Friday, January 07, 2011 4:28 PM > To: roll@ietf.org; ipv6@ietf.org > Subject: [Roll] Discrepancy between draft-ietf-roll-rpl-17 and draft-ietf- > 6man-rpl-routing-header-01 >=20 > A discrepancy between the ROLL and 6man-rpl-routing-header draft was > spotted a few weeks ago. I haven't seen any comments on this on the ROLL > list. I've posted it to the 6Man list as it also affects a draft in this WG. It is > important that everyone generates the destination unreachable in the same > way because the RPL root node will process the destination unreachable to > determine which link has failed. >=20 > Daniel. >=20 >=20 > -------- Original Message -------- > Subject: Re: [Roll] I-D Action:draft-ietf-roll-rpl-17.txt > Date: Fri, 17 Dec 2010 14:40:24 -0800 > From: Dario Tedeschi > To: Internet-Drafts@ietf.org > CC: roll@ietf.org, i-d-announce@ietf.org > References: <20101215230001.30256.8767.idtracker@localhost> >=20 >=20 >=20 > There seems to be a discrepancy between draft-ietf-roll-rpl-17 and > draft-ietf-6man-rpl-routing-header-01: >=20 > The following pseudo code in the RPL RH draft: >=20 > else if i < n and Address[i] is not on-link { > send an ICMP Destination Unreachable, Code 7, message to > <--*** > the Source Address and discard the packet > } > else { > swap the IPv6 Destination Address and Address[i] <--*** >=20 > if the IPv6 Hop Limit is less than or equal to 1 { > send an ICMP Time Exceeded -- Hop Limit Exceeded in > Transit message to the Source Address and discard the > packet > } >=20 >=20 > does not correlate with the following wording in the RPL draft (section > 11.2.2.3): >=20 > .... .... The "Error in Source Routing Header" > message has the > same format as the "Destination Unreachable Message" as specified in > [RFC4443]. The portion of the invoking packet that is sent back in > the ICMP message should record at least up to the routing header, and > the routing header should be consumed by this node so that the > destination in the IPv6 header is the next hop that this node could > <--*** > not reach. >=20 >=20 >=20 > Dario >=20 >=20 > On 15/12/2010 3:00 PM, Internet-Drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > This draft is a work item of the Routing Over Low power and Lossy > networks Working Group of the IETF. > > > > > > Title : RPL: IPv6 Routing Protocol for Low power and Lossy > Networks > > Author(s) : T. Winter, et al. > > Filename : draft-ietf-roll-rpl-17.txt > > Pages : 159 > > Date : 2010-12-15 > > > > Low power and Lossy Networks (LLNs) are a class of network in which > > both the routers and their interconnect are constrained. LLN routers > > typically operate with constraints on processing power, memory, and > > energy (battery power). Their interconnects are characterized by high > > loss rates, low data rates, and instability. LLNs are comprised of > > anything from a few dozen and up to thousands of routers. > > Supported traffic flows include point-to-point (between devices inside > > the LLN), point-to-multipoint (from a central control point to a > > subset of devices inside the LLN), and multipoint-to-point (from > > devices inside the LLN towards a central control point). This > > document specifies the IPv6 Routing Protocol for LLNs (RPL), which > > provides a mechanism whereby multipoint-to-point traffic from devices > > inside the LLN towards a central control point, as well as point-to- > > multipoint traffic from the central control point to the devices > > inside the LLN, is supported. Support for point-to-point traffic is > > also available. > > > > A URL for this Internet-Draft is: > > http://www.ietf.org/internet-drafts/draft-ietf-roll-rpl-17.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. > > > > > > _______________________________________________ > > Roll mailing list > > Roll@ietf.org > > https://www.ietf.org/mailman/listinfo/roll >=20 >=20 >=20 > Regards, >=20 > Daniel. >=20 > -- >=20 > __________________________________________________ >=20 > Daniel Gavelle, Software Team Leader > Low Power RF Solutions (formerly Jennic Ltd.) NXP Semiconductors Furnival > Street, Sheffield, S1 4QT, UK > Tel: +44 114 281 2655 > Fax: +44 114 281 2951 > Comp Reg No: 3191371 - Registered In England http://www.nxp.com > http://www.jennic.com > __________________________________________________ > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From dat@exegin.com Fri Jan 7 13:33: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 142A13A69B3; Fri, 7 Jan 2011 13:33:51 -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=[AWL=0.001, 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 94mzeXDfmRWG; Fri, 7 Jan 2011 13:33:47 -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 953D23A69B2; Fri, 7 Jan 2011 13:30:43 -0800 (PST) Received: by wwa36 with SMTP id 36so17902762wwa.13 for ; Fri, 07 Jan 2011 13:32:49 -0800 (PST) Received: by 10.227.154.69 with SMTP id n5mr15854150wbw.131.1294435968357; Fri, 07 Jan 2011 13:32:48 -0800 (PST) Received: from [172.16.1.52] ([216.251.130.154]) by mx.google.com with ESMTPS id o51sm12681404wes.39.2011.01.07.13.32.45 (version=SSLv3 cipher=RC4-MD5); Fri, 07 Jan 2011 13:32:47 -0800 (PST) Message-ID: <4D278689.8090509@exegin.com> Date: Fri, 07 Jan 2011 13:32:57 -0800 From: Dario Tedeschi User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Daniel Gavelle Subject: Re: [Roll] Discrepancy between draft-ietf-roll-rpl-17 and draft-ietf-6man-rpl-routing-header-01 References: <6A2A459175DABE4BB11DE2026AA50A5D0385FB77@XMB-AMS-107.cisco.com> <78B923726E7D59429936580CF127E943A13214DDC4@eu1rdcrdc1wx032.exi.nxp.com> In-Reply-To: <78B923726E7D59429936580CF127E943A13214DDC4@eu1rdcrdc1wx032.exi.nxp.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Fri, 07 Jan 2011 13:56:04 -0800 Cc: "Pascal Thubert \(pthubert\)" , "ipv6@ietf.org" , "roll@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, 07 Jan 2011 21:33:51 -0000 I second that. On 07/01/2011 9:33 AM, Daniel Gavelle wrote: > Pascal, > > I agree that it is easier to swap the header before generating the response. It also makes parsing the response on the root node easier, as the destination address will be the address of the node that is no longer reachable. > > Daniel. > > > -----Original Message----- > From: Pascal Thubert (pthubert) [mailto:pthubert@cisco.com] > Sent: 07 January 2011 16:44 > To: Daniel Gavelle; roll@ietf.org; ipv6@ietf.org > Subject: RE: [Roll] Discrepancy between draft-ietf-roll-rpl-17 and draft-ietf-6man-rpl-routing-header-01 > > Hi Daniel: > > Thanks for the heads up. > > The text in RPL assumes that the node receives a packet, processes the > RH (swaps the destination) and then forwards to the new next hop. If > that fails, it seems easier to pass the resulting packet as it now > stands than to recomputed the packet as it was received. I think the RH > draft should adapt to that . Would you agree? > > Pascal > http://www.xtranormal.com/watch/7011357/ > > >> -----Original Message----- >> From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf > Of >> Daniel Gavelle >> Sent: Friday, January 07, 2011 4:28 PM >> To: roll@ietf.org; ipv6@ietf.org >> Subject: [Roll] Discrepancy between draft-ietf-roll-rpl-17 and > draft-ietf- >> 6man-rpl-routing-header-01 >> >> A discrepancy between the ROLL and 6man-rpl-routing-header draft was >> spotted a few weeks ago. I haven't seen any comments on this on the > ROLL >> list. I've posted it to the 6Man list as it also affects a draft in > this WG. It is >> important that everyone generates the destination unreachable in the > same >> way because the RPL root node will process the destination unreachable > to >> determine which link has failed. >> >> Daniel. >> >> >> -------- Original Message -------- >> Subject: Re: [Roll] I-D Action:draft-ietf-roll-rpl-17.txt >> Date: Fri, 17 Dec 2010 14:40:24 -0800 >> From: Dario Tedeschi >> To: Internet-Drafts@ietf.org >> CC: roll@ietf.org, i-d-announce@ietf.org >> References: <20101215230001.30256.8767.idtracker@localhost> >> >> >> >> There seems to be a discrepancy between draft-ietf-roll-rpl-17 and >> draft-ietf-6man-rpl-routing-header-01: >> >> The following pseudo code in the RPL RH draft: >> >> else if i< n and Address[i] is not on-link { >> send an ICMP Destination Unreachable, Code 7, message to >> <--*** >> the Source Address and discard the packet >> } >> else { >> swap the IPv6 Destination Address and Address[i] > <--*** >> if the IPv6 Hop Limit is less than or equal to 1 { >> send an ICMP Time Exceeded -- Hop Limit Exceeded in >> Transit message to the Source Address and discard the >> packet >> } >> >> >> does not correlate with the following wording in the RPL draft > (section >> 11.2.2.3): >> >> .... .... The "Error in Source Routing Header" >> message has the >> same format as the "Destination Unreachable Message" as specified > in >> [RFC4443]. The portion of the invoking packet that is sent back > in >> the ICMP message should record at least up to the routing header, > and >> the routing header should be consumed by this node so that the >> destination in the IPv6 header is the next hop that this node > could >> <--*** >> not reach. >> >> >> >> Dario >> >> >> On 15/12/2010 3:00 PM, Internet-Drafts@ietf.org wrote: >>> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >>> This draft is a work item of the Routing Over Low power and Lossy >> networks Working Group of the IETF. >>> >>> Title : RPL: IPv6 Routing Protocol for Low power and > Lossy >> Networks >>> Author(s) : T. Winter, et al. >>> Filename : draft-ietf-roll-rpl-17.txt >>> Pages : 159 >>> Date : 2010-12-15 >>> >>> Low power and Lossy Networks (LLNs) are a class of network in which >>> both the routers and their interconnect are constrained. LLN > routers >>> typically operate with constraints on processing power, memory, and >>> energy (battery power). Their interconnects are characterized by > high >>> loss rates, low data rates, and instability. LLNs are comprised of >>> anything from a few dozen and up to thousands of routers. >>> Supported traffic flows include point-to-point (between devices > inside >>> the LLN), point-to-multipoint (from a central control point to a >>> subset of devices inside the LLN), and multipoint-to-point (from >>> devices inside the LLN towards a central control point). This >>> document specifies the IPv6 Routing Protocol for LLNs (RPL), which >>> provides a mechanism whereby multipoint-to-point traffic from > devices >>> inside the LLN towards a central control point, as well as point-to- >>> multipoint traffic from the central control point to the devices >>> inside the LLN, is supported. Support for point-to-point traffic is >>> also available. >>> >>> A URL for this Internet-Draft is: >>> http://www.ietf.org/internet-drafts/draft-ietf-roll-rpl-17.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. >>> >>> >>> _______________________________________________ >>> Roll mailing list >>> Roll@ietf.org >>> https://www.ietf.org/mailman/listinfo/roll >> >> >> Regards, >> >> Daniel. >> >> -- >> >> __________________________________________________ >> >> Daniel Gavelle, Software Team Leader >> Low Power RF Solutions (formerly Jennic Ltd.) NXP Semiconductors > Furnival >> Street, Sheffield, S1 4QT, UK >> Tel: +44 114 281 2655 >> Fax: +44 114 281 2951 >> Comp Reg No: 3191371 - Registered In England http://www.nxp.com >> http://www.jennic.com >> __________________________________________________ >> _______________________________________________ >> Roll mailing list >> Roll@ietf.org >> https://www.ietf.org/mailman/listinfo/roll > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From brian.e.carpenter@gmail.com Sun Jan 9 12:31:11 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 946213A6842 for ; Sun, 9 Jan 2011 12:31:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.397 X-Spam-Level: X-Spam-Status: No, score=-103.397 tagged_above=-999 required=5 tests=[AWL=0.202, 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 9qh5IbQ+KvKC for ; Sun, 9 Jan 2011 12:31:09 -0800 (PST) Received: from mail-yi0-f44.google.com (mail-yi0-f44.google.com [209.85.218.44]) by core3.amsl.com (Postfix) with ESMTP id 77E983A67D4 for ; Sun, 9 Jan 2011 12:31:09 -0800 (PST) Received: by yie19 with SMTP id 19so5975831yie.31 for ; Sun, 09 Jan 2011 12:33:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :organization:user-agent:mime-version:to:cc:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=KyBrvn+oBbhHTz5U6eIadAh7YBfiTaDr3p4YVwAGNcQ=; b=QgW1fhXyDz461zf2jYNlTxdW6MlFui5y1HIgdzLjWJWQnesNwLL7GLh4o/nCTGWKrW P1Vv9aiOk7Y9w6/tDxmRMLQfAMReaIxM2KKDVAjPCP/Wri4CgX5R+MKuu2axE8EgpmPz QZLRHfMTlrzGagTCrc4ePivjlzxUi5ez7k+wM= 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=kRgY76hG+Qe/Ms14NEbjH104lAX08f17ysnkDZAgDkBB5OfDj2ehB3klPPlykzf31i lsVRQfC7P7uD4ozga6nzm6F1/9XkygWcuqn0dTX0aLA2BP7em37AHvQun9bxPupQ1Vws yG6FBpa3U+rjSVQkcb4dLNKbq1coJCFtuvfsM= Received: by 10.150.52.5 with SMTP id z5mr27756689ybz.236.1294605199704; Sun, 09 Jan 2011 12:33:19 -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 v8sm14284184ybe.1.2011.01.09.12.33.16 (version=SSLv3 cipher=RC4-MD5); Sun, 09 Jan 2011 12:33:18 -0800 (PST) Message-ID: <4D2A1B84.1020003@gmail.com> Date: Mon, 10 Jan 2011 09:33:08 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Fred Baker Subject: Re: [Fwd: I-D Action:draft-ietf-6man-flow-update-00.txt] References: <4CF82E6F.9040309@gmail.com> <4D08165A.3060306@gmail.com> <51661CE4-EC60-46B9-928C-D5763CFDF318@cisco.com> <4D082147.9010209@gmail.com> In-Reply-To: <4D082147.9010209@gmail.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: Sun, 09 Jan 2011 20:31:11 -0000 When reviewing the text for the next update, I rediscovered that we do in fact say "The proposed generic use is to encourage pseudo-random flow labels that can be used to assist load balancing." so (with draft-ietf-6man-flow-ecmp also in progress) I think Fred's point is covered. Regards Brian On 2010-12-15 15:00, Brian E Carpenter wrote: > We do have draft-ietf-6man-flow-ecmp, which is focussed on ECMP/LAG > load sharing in tunnels. The reason we're proposing to recommend > pseudo-random labels by default is so that load sharing becomes a > natural use case. > > When we did RFC 3697, there was strong pressure to keep the spec > as "pure" as possible. I was sort of assuming the same approach > this time around. Of course, the WG can decide otherwise, but > embedding the use case(s) in the protocol spec does lengthen > the discussion considerably. > > Regards > Brian > > On 2010-12-15 14:26, Fred Baker wrote: >> So you're really really not interested in discussing the one use case that people have actually talked about wanting, which has to do with load sharing? What use case are you addressing? >> >> On Dec 14, 2010, at 5:14 PM, Brian E Carpenter wrote: >> >>> Hi, >>> >>> The authors have received one off-list comment on this version, >>> requesting additional clarification of the text associated with >>> this recommendation: >>> >>>>> 2. A network domain MUST NOT forward packets outside the domain >>>>> whose flow label values are other than zero or pseudo-random. >>>>> >>> Does anyone else have comments, or are we getting somewhere near agreement? >>> >>> Regards >>> Brian Carpenter >>> >>> >>> On 2010-12-03 12:40, Brian E Carpenter wrote: >>>> Hi, >>>> >>>> This is intended to reflect the various comments made in Beijing, >>>> notably strengthening the points about the flow label not being >>>> changed en route. Please review - if the WG is generally OK >>>> with this version, we'll start to think about RFC3697bis. >>>> >>>> Brian + Sheng + Shane >>>> >>>> -------- Original Message -------- >>>> Subject: I-D Action:draft-ietf-6man-flow-update-00.txt >>>> Date: Thu, 02 Dec 2010 15:00:02 -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 : Update to the IPv6 flow label specification >>>> Author(s) : S. Amante, et al. >>>> Filename : draft-ietf-6man-flow-update-00.txt >>>> Pages : 13 >>>> Date : 2010-12-02 >>>> >>>> Various published proposals for use of the IPv6 flow label are >>>> incompatible with its existing 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 proposes changes to the >>>> specification in order to clarify it, making it clear what types of >>>> usage are possible, and to introduce some additional flexibility. >>>> >>>> A URL for this Internet-Draft is: >>>> http://www.ietf.org/internet-drafts/draft-ietf-6man-flow-update-00.txt >>>> >>>> >>>> >>>> >>> -------------------------------------------------------------------- >>> IETF IPv6 working group mailing list >>> ipv6@ietf.org >>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >>> -------------------------------------------------------------------- >> > From fred@cisco.com Sun Jan 9 17:24: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 071A03A686D for ; Sun, 9 Jan 2011 17:24:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.452 X-Spam-Level: X-Spam-Status: No, score=-110.452 tagged_above=-999 required=5 tests=[AWL=0.147, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 rCI3yAwdfa4F for ; Sun, 9 Jan 2011 17:24:05 -0800 (PST) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id BFCEA3A6868 for ; Sun, 9 Jan 2011 17:24:05 -0800 (PST) Authentication-Results: sj-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAG/vKU2rR7Hu/2dsb2JhbACkPnOkFpcchUwEhGeGI4Mg Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-1.cisco.com with ESMTP; 10 Jan 2011 01:26:18 +0000 Received: from stealth-10-32-244-218.cisco.com (stealth-10-32-244-218.cisco.com [10.32.244.218]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id p0A1QDl0016860; Mon, 10 Jan 2011 01:26:17 GMT Received: from [127.0.0.1] by stealth-10-32-244-218.cisco.com (PGP Universal service); Sun, 09 Jan 2011 17:26:17 -0800 X-PGP-Universal: processed; by stealth-10-32-244-218.cisco.com on Sun, 09 Jan 2011 17:26:17 -0800 Subject: Re: [Fwd: I-D Action:draft-ietf-6man-flow-update-00.txt] Mime-Version: 1.0 (Apple Message framework v1082) From: Fred Baker In-Reply-To: <4D2A1B84.1020003@gmail.com> Date: Sun, 9 Jan 2011 17:26:03 -0800 Message-Id: References: <4CF82E6F.9040309@gmail.com> <4D08165A.3060306@gmail.com> <51661CE4-EC60-46B9-928C-D5763CFDF318@cisco.com> <4D082147.9010209@gmail.com> <4D2A1B84.1020003@gmail.com> To: Brian E Carpenter X-Mailer: Apple Mail (2.1082) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable 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: Mon, 10 Jan 2011 01:24:07 -0000 The issue is that randomness doesn't help, if you want a scalable = approach. It means that for each flow passing through the load balancing = system, I have to store its flow label and assign it a path. What are = the arguments against NATs? One of the big ones is the expectation of = per-flow state in the network, isn't it? If you're expecting the network = to store per-flow state, you by definition have a scaling problem in the = network. To use the flow label in load sharing and have it be remotely scalable, = the network needs to be in control of the label. On Jan 9, 2011, at 12:33 PM, Brian E Carpenter wrote: > When reviewing the text for the next update, I rediscovered that > we do in fact say >=20 > "The proposed generic use is to encourage pseudo-random flow labels = that can be used to assist load balancing." >=20 > so (with draft-ietf-6man-flow-ecmp also in progress) I think Fred's > point is covered. >=20 > Regards > Brian >=20 > On 2010-12-15 15:00, Brian E Carpenter wrote: >> We do have draft-ietf-6man-flow-ecmp, which is focussed on ECMP/LAG >> load sharing in tunnels. The reason we're proposing to recommend >> pseudo-random labels by default is so that load sharing becomes a >> natural use case. >>=20 >> When we did RFC 3697, there was strong pressure to keep the spec >> as "pure" as possible. I was sort of assuming the same approach >> this time around. Of course, the WG can decide otherwise, but >> embedding the use case(s) in the protocol spec does lengthen >> the discussion considerably. >>=20 >> Regards >> Brian >>=20 >> On 2010-12-15 14:26, Fred Baker wrote: >>> So you're really really not interested in discussing the one use = case that people have actually talked about wanting, which has to do = with load sharing? What use case are you addressing? >>>=20 >>> On Dec 14, 2010, at 5:14 PM, Brian E Carpenter wrote: >>>=20 >>>> Hi, >>>>=20 >>>> The authors have received one off-list comment on this version, >>>> requesting additional clarification of the text associated with >>>> this recommendation: >>>>=20 >>>>>> 2. A network domain MUST NOT forward packets outside the = domain >>>>>> whose flow label values are other than zero or = pseudo-random. >>>>>>=20 >>>> Does anyone else have comments, or are we getting somewhere near = agreement? >>>>=20 >>>> Regards >>>> Brian Carpenter >>>>=20 >>>>=20 >>>> On 2010-12-03 12:40, Brian E Carpenter wrote: >>>>> Hi, >>>>>=20 >>>>> This is intended to reflect the various comments made in Beijing, >>>>> notably strengthening the points about the flow label not being >>>>> changed en route. Please review - if the WG is generally OK >>>>> with this version, we'll start to think about RFC3697bis. >>>>>=20 >>>>> Brian + Sheng + Shane >>>>>=20 >>>>> -------- Original Message -------- >>>>> Subject: I-D Action:draft-ietf-6man-flow-update-00.txt >>>>> Date: Thu, 02 Dec 2010 15:00:02 -0800 >>>>> From: Internet-Drafts@ietf.org >>>>> Reply-To: internet-drafts@ietf.org >>>>> To: i-d-announce@ietf.org >>>>> CC: ipv6@ietf.org >>>>>=20 >>>>> 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. >>>>>=20 >>>>>=20 >>>>> Title : Update to the IPv6 flow label specification >>>>> Author(s) : S. Amante, et al. >>>>> Filename : draft-ietf-6man-flow-update-00.txt >>>>> Pages : 13 >>>>> Date : 2010-12-02 >>>>>=20 >>>>> Various published proposals for use of the IPv6 flow label are >>>>> incompatible with its existing 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 proposes changes to the >>>>> specification in order to clarify it, making it clear what types = of >>>>> usage are possible, and to introduce some additional flexibility. >>>>>=20 >>>>> A URL for this Internet-Draft is: >>>>> = http://www.ietf.org/internet-drafts/draft-ietf-6man-flow-update-00.txt >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>> = -------------------------------------------------------------------- >>>> IETF IPv6 working group mailing list >>>> ipv6@ietf.org >>>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >>>> = -------------------------------------------------------------------- >>>=20 >>=20 From brian.e.carpenter@gmail.com Sun Jan 9 17:43: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 0907928C0DB for ; Sun, 9 Jan 2011 17:43:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.401 X-Spam-Level: X-Spam-Status: No, score=-103.401 tagged_above=-999 required=5 tests=[AWL=0.198, 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 wYo4sPI+TlZA for ; Sun, 9 Jan 2011 17:43:01 -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 B08E028C0D7 for ; Sun, 9 Jan 2011 17:43:00 -0800 (PST) Received: by qwi2 with SMTP id 2so3589608qwi.31 for ; Sun, 09 Jan 2011 17:45:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :organization:user-agent:mime-version:to:cc:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=u1qjfDHhNOnm5LUbDWAl+JabO5sSZQXINQBAa8z12BM=; b=gsT3zn0qB+Al7xt/1zLhRdR+uvAxsjfT0MEsKNsYiscbKklHCKBCahdL+Dn86xn/md r/3+xkOFFdGncDLBOGxJ5BVWhgkJYfUjLCCyTzN/YtDdi79qPDObYLkQy2YIc2k/7AeD MdH6XVs6g1QQd+IYdebYIGoOur5TKOHlCmi50= 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=UloHqGc10fiisdLpGON66G/KudBmVu76HJ2WwI1TEyFr+FxFgDF7St6ryLWylRteEo v+1PfJWj1EzQVhL++TH2lj5dl+VCEroQFCXziOiYlhWMzeiWRMD+ViTNIHjTEWF3K0Xd 2zMs3evzUq2+T/4AA635Saa7XCNLELC4JXuy0= Received: by 10.224.60.203 with SMTP id q11mr21279969qah.167.1294623912189; Sun, 09 Jan 2011 17:45: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 t7sm15917987qcs.4.2011.01.09.17.45.10 (version=SSLv3 cipher=RC4-MD5); Sun, 09 Jan 2011 17:45:11 -0800 (PST) Message-ID: <4D2A64A1.4030400@gmail.com> Date: Mon, 10 Jan 2011 14:45:05 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Fred Baker Subject: Re: [Fwd: I-D Action:draft-ietf-6man-flow-update-00.txt] References: <4CF82E6F.9040309@gmail.com> <4D08165A.3060306@gmail.com> <51661CE4-EC60-46B9-928C-D5763CFDF318@cisco.com> <4D082147.9010209@gmail.com> <4D2A1B84.1020003@gmail.com> In-Reply-To: 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: Mon, 10 Jan 2011 01:43:02 -0000 Fred, I'm confused. We've been talking for months about recommending pseudo-random flow label values as inputs to hash functions, precisely to allow scaleable and stateless load balancing and ECMP. I completely agree that per-flow state doesn't scale. Regards Brian Carpenter On 2011-01-10 14:26, Fred Baker wrote: > The issue is that randomness doesn't help, if you want a scalable approach. It means that for each flow passing through the load balancing system, I have to store its flow label and assign it a path. What are the arguments against NATs? One of the big ones is the expectation of per-flow state in the network, isn't it? If you're expecting the network to store per-flow state, you by definition have a scaling problem in the network. > > To use the flow label in load sharing and have it be remotely scalable, the network needs to be in control of the label. > > On Jan 9, 2011, at 12:33 PM, Brian E Carpenter wrote: > >> When reviewing the text for the next update, I rediscovered that >> we do in fact say >> >> "The proposed generic use is to encourage pseudo-random flow labels that can be used to assist load balancing." >> >> so (with draft-ietf-6man-flow-ecmp also in progress) I think Fred's >> point is covered. >> >> Regards >> Brian >> >> On 2010-12-15 15:00, Brian E Carpenter wrote: >>> We do have draft-ietf-6man-flow-ecmp, which is focussed on ECMP/LAG >>> load sharing in tunnels. The reason we're proposing to recommend >>> pseudo-random labels by default is so that load sharing becomes a >>> natural use case. >>> >>> When we did RFC 3697, there was strong pressure to keep the spec >>> as "pure" as possible. I was sort of assuming the same approach >>> this time around. Of course, the WG can decide otherwise, but >>> embedding the use case(s) in the protocol spec does lengthen >>> the discussion considerably. >>> >>> Regards >>> Brian >>> >>> On 2010-12-15 14:26, Fred Baker wrote: >>>> So you're really really not interested in discussing the one use case that people have actually talked about wanting, which has to do with load sharing? What use case are you addressing? >>>> >>>> On Dec 14, 2010, at 5:14 PM, Brian E Carpenter wrote: >>>> >>>>> Hi, >>>>> >>>>> The authors have received one off-list comment on this version, >>>>> requesting additional clarification of the text associated with >>>>> this recommendation: >>>>> >>>>>>> 2. A network domain MUST NOT forward packets outside the domain >>>>>>> whose flow label values are other than zero or pseudo-random. >>>>>>> >>>>> Does anyone else have comments, or are we getting somewhere near agreement? >>>>> >>>>> Regards >>>>> Brian Carpenter >>>>> >>>>> >>>>> On 2010-12-03 12:40, Brian E Carpenter wrote: >>>>>> Hi, >>>>>> >>>>>> This is intended to reflect the various comments made in Beijing, >>>>>> notably strengthening the points about the flow label not being >>>>>> changed en route. Please review - if the WG is generally OK >>>>>> with this version, we'll start to think about RFC3697bis. >>>>>> >>>>>> Brian + Sheng + Shane >>>>>> >>>>>> -------- Original Message -------- >>>>>> Subject: I-D Action:draft-ietf-6man-flow-update-00.txt >>>>>> Date: Thu, 02 Dec 2010 15:00:02 -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 : Update to the IPv6 flow label specification >>>>>> Author(s) : S. Amante, et al. >>>>>> Filename : draft-ietf-6man-flow-update-00.txt >>>>>> Pages : 13 >>>>>> Date : 2010-12-02 >>>>>> >>>>>> Various published proposals for use of the IPv6 flow label are >>>>>> incompatible with its existing 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 proposes changes to the >>>>>> specification in order to clarify it, making it clear what types of >>>>>> usage are possible, and to introduce some additional flexibility. >>>>>> >>>>>> A URL for this Internet-Draft is: >>>>>> http://www.ietf.org/internet-drafts/draft-ietf-6man-flow-update-00.txt >>>>>> >>>>>> >>>>>> >>>>>> >>>>> -------------------------------------------------------------------- >>>>> IETF IPv6 working group mailing list >>>>> ipv6@ietf.org >>>>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >>>>> -------------------------------------------------------------------- > > From jmh@joelhalpern.com Sun Jan 9 18:33:03 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 0C60D28C0E3 for ; Sun, 9 Jan 2011 18:33:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.045 X-Spam-Level: X-Spam-Status: No, score=-103.045 tagged_above=-999 required=5 tests=[AWL=0.554, 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 CwyXzZcUKbsS for ; Sun, 9 Jan 2011 18:33:00 -0800 (PST) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id C13F528C0D9 for ; Sun, 9 Jan 2011 18:33:00 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 650244300D5; Sun, 9 Jan 2011 18:35:13 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at hermes.tigertech.net Received: from [10.10.10.101] (pool-71-161-51-169.clppva.btas.verizon.net [71.161.51.169]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by hermes.tigertech.net (Postfix) with ESMTPSA id 686C04300B6; Sun, 9 Jan 2011 18:35:12 -0800 (PST) Message-ID: <4D2A705C.2040406@joelhalpern.com> Date: Sun, 09 Jan 2011 21:35:08 -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: Fred Baker Subject: Re: [Fwd: I-D Action:draft-ietf-6man-flow-update-00.txt] References: <4CF82E6F.9040309@gmail.com> <4D08165A.3060306@gmail.com> <51661CE4-EC60-46B9-928C-D5763CFDF318@cisco.com> <4D082147.9010209@gmail.com> <4D2A1B84.1020003@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: 6man , 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: Mon, 10 Jan 2011 02:33:03 -0000 Let me phrase Brian's comment differently. Presume we actually get wide use of the flow label in accordance with the load balancing draft. What can go wrong? Well, someone could send all their traffic with a single flow label, reducing the randomness. So what goes wrong. All of that subscribers traffic ends up on a single link. Mostly, that means that if he does this, he increases the likelihood that his traffic will get damaged. Seems unlikely he would choose to do that. We coudl fo course view this as a deliberate attack. But, in fact, it is an attack that could already be done. The subscriber simply sends all his traffic with a single set of ports (source and dest). That will have the exact same effect on the current system that a fixed flow-label would have under the proposed behavior. So I do not see why the network needs to "control" the flow label, any more than it needs to "control" the ports the subscriber uses. Yours, Joel On 1/9/2011 8:26 PM, Fred Baker wrote: > The issue is that randomness doesn't help, if you want a scalable approach. It means that for each flow passing through the load balancing system, I have to store its flow label and assign it a path. What are the arguments against NATs? One of the big ones is the expectation of per-flow state in the network, isn't it? If you're expecting the network to store per-flow state, you by definition have a scaling problem in the network. > > To use the flow label in load sharing and have it be remotely scalable, the network needs to be in control of the label. > > On Jan 9, 2011, at 12:33 PM, Brian E Carpenter wrote: > >> When reviewing the text for the next update, I rediscovered that >> we do in fact say >> >> "The proposed generic use is to encourage pseudo-random flow labels that can be used to assist load balancing." >> >> so (with draft-ietf-6man-flow-ecmp also in progress) I think Fred's >> point is covered. >> >> Regards >> Brian >> >> On 2010-12-15 15:00, Brian E Carpenter wrote: >>> We do have draft-ietf-6man-flow-ecmp, which is focussed on ECMP/LAG >>> load sharing in tunnels. The reason we're proposing to recommend >>> pseudo-random labels by default is so that load sharing becomes a >>> natural use case. >>> >>> When we did RFC 3697, there was strong pressure to keep the spec >>> as "pure" as possible. I was sort of assuming the same approach >>> this time around. Of course, the WG can decide otherwise, but >>> embedding the use case(s) in the protocol spec does lengthen >>> the discussion considerably. >>> >>> Regards >>> Brian >>> >>> On 2010-12-15 14:26, Fred Baker wrote: >>>> So you're really really not interested in discussing the one use case that people have actually talked about wanting, which has to do with load sharing? What use case are you addressing? >>>> >>>> On Dec 14, 2010, at 5:14 PM, Brian E Carpenter wrote: >>>> >>>>> Hi, >>>>> >>>>> The authors have received one off-list comment on this version, >>>>> requesting additional clarification of the text associated with >>>>> this recommendation: >>>>> >>>>>>> 2. A network domain MUST NOT forward packets outside the domain >>>>>>> whose flow label values are other than zero or pseudo-random. >>>>>>> >>>>> Does anyone else have comments, or are we getting somewhere near agreement? >>>>> >>>>> Regards >>>>> Brian Carpenter >>>>> >>>>> >>>>> On 2010-12-03 12:40, Brian E Carpenter wrote: >>>>>> Hi, >>>>>> >>>>>> This is intended to reflect the various comments made in Beijing, >>>>>> notably strengthening the points about the flow label not being >>>>>> changed en route. Please review - if the WG is generally OK >>>>>> with this version, we'll start to think about RFC3697bis. >>>>>> >>>>>> Brian + Sheng + Shane >>>>>> >>>>>> -------- Original Message -------- >>>>>> Subject: I-D Action:draft-ietf-6man-flow-update-00.txt >>>>>> Date: Thu, 02 Dec 2010 15:00:02 -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 : Update to the IPv6 flow label specification >>>>>> Author(s) : S. Amante, et al. >>>>>> Filename : draft-ietf-6man-flow-update-00.txt >>>>>> Pages : 13 >>>>>> Date : 2010-12-02 >>>>>> >>>>>> Various published proposals for use of the IPv6 flow label are >>>>>> incompatible with its existing 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 proposes changes to the >>>>>> specification in order to clarify it, making it clear what types of >>>>>> usage are possible, and to introduce some additional flexibility. >>>>>> >>>>>> A URL for this Internet-Draft is: >>>>>> http://www.ietf.org/internet-drafts/draft-ietf-6man-flow-update-00.txt >>>>>> >>>>>> >>>>>> >>>>>> >>>>> -------------------------------------------------------------------- >>>>> 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 slblake@petri-meat.com Sun Jan 9 19:03: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 008FB28C0E8 for ; Sun, 9 Jan 2011 19:03:22 -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 bCdRH5lvjJoO for ; Sun, 9 Jan 2011 19:03:20 -0800 (PST) Received: from elom.tchmachines.com (elom.tchmachines.com [208.76.80.198]) by core3.amsl.com (Postfix) with ESMTP id DCBAD28C0D9 for ; Sun, 9 Jan 2011 19:03:20 -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 1Pc84T-0006B7-Iv; Sun, 09 Jan 2011 22:05:25 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Date: Sun, 09 Jan 2011 23:05:25 -0400 From: Steven Blake To: Brian E Carpenter Subject: Re: [Fwd: I-D Action:draft-ietf-6man-flow-update-00.txt] In-Reply-To: <4D2A64A1.4030400@gmail.com> References: <4CF82E6F.9040309@gmail.com> <4D08165A.3060306@gmail.com> <51661CE4-EC60-46B9-928C-D5763CFDF318@cisco.com> <4D082147.9010209@gmail.com> <4D2A1B84.1020003@gmail.com> <4D2A64A1.4030400@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: 6man , Fred Baker 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, 10 Jan 2011 03:03:22 -0000 On Mon, 10 Jan 2011 14:45:05 +1300, Brian E Carpenter wrote: > Fred, > > I'm confused. We've been talking for months about recommending > pseudo-random flow label values as inputs to hash functions, > precisely to allow scaleable and stateless load balancing and ECMP. > > I completely agree that per-flow state doesn't scale. > > Regards > Brian Carpenter > > On 2011-01-10 14:26, Fred Baker wrote: >> >> The issue is that randomness doesn't help, if you want a scalable >> approach. >> It means that for each flow passing through the load balancing >> system, I have >> to store its flow label and assign it a path. What are the arguments >> against >> NATs? One of the big ones is the expectation of per-flow state in >> the network, >> isn't it? If you're expecting the network to store per-flow state, >> you by >> definition have a scaling problem in the network. >> >> To use the flow label in load sharing and have it be remotely >> scalable, >> the network needs to be in control of the label. Perhaps Fred has applications of "load balancing" beyond ECMP or LAG in mind? The network doesn't control port numbers, so his argument obviously doesn't apply to ECMP or LAG. Regards, // Steve From fred@cisco.com Sun Jan 9 21:40: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 B86C83A6932 for ; Sun, 9 Jan 2011 21:40:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.427 X-Spam-Level: X-Spam-Status: No, score=-110.427 tagged_above=-999 required=5 tests=[AWL=0.172, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 kZ8Qg7e5TYc3 for ; Sun, 9 Jan 2011 21:40:22 -0800 (PST) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 0588F3A692F for ; Sun, 9 Jan 2011 21:40:22 -0800 (PST) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAPcqKk2rRN+J/2dsb2JhbACkPXOjYJcmhUwEhGeGI4Mg Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-6.cisco.com with ESMTP; 10 Jan 2011 05:42:34 +0000 Received: from stealth-10-32-244-218.cisco.com (stealth-10-32-244-218.cisco.com [10.32.244.218]) by sj-core-3.cisco.com (8.13.8/8.14.3) with ESMTP id p0A5gPbR000365; Mon, 10 Jan 2011 05:42:29 GMT Received: from [127.0.0.1] by stealth-10-32-244-218.cisco.com (PGP Universal service); Sun, 09 Jan 2011 21:42:34 -0800 X-PGP-Universal: processed; by stealth-10-32-244-218.cisco.com on Sun, 09 Jan 2011 21:42:34 -0800 Subject: Re: [Fwd: I-D Action:draft-ietf-6man-flow-update-00.txt] Mime-Version: 1.0 (Apple Message framework v1082) From: Fred Baker In-Reply-To: <4D2A64A1.4030400@gmail.com> Date: Sun, 9 Jan 2011 21:42:16 -0800 Message-Id: <982F8CA8-789A-42D6-9C86-E194BA868023@cisco.com> References: <4CF82E6F.9040309@gmail.com> <4D08165A.3060306@gmail.com> <51661CE4-EC60-46B9-928C-D5763CFDF318@cisco.com> <4D082147.9010209@gmail.com> <4D2A1B84.1020003@gmail.com> <4D2A64A1.4030400@gmail.com> To: Brian E Carpenter X-Mailer: Apple Mail (2.1082) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable 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: Mon, 10 Jan 2011 05:40:22 -0000 On Jan 9, 2011, at 5:45 PM, Brian E Carpenter wrote: > I'm confused. We've been talking for months about recommending > pseudo-random flow label values as inputs to hash functions, > precisely to allow scaleable and stateless load balancing and ECMP. >=20 > I completely agree that per-flow state doesn't scale. This isn't exactly the first time I have made the statement. I've been = on record on this point regarding the flow label since it was designed = to answer NIMROD's definition of a flow.= From fred@cisco.com Sun Jan 9 21:53:49 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 0CF293A69A9 for ; Sun, 9 Jan 2011 21:53:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.453 X-Spam-Level: X-Spam-Status: No, score=-110.453 tagged_above=-999 required=5 tests=[AWL=0.146, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 XQZRTqN+MHEx for ; Sun, 9 Jan 2011 21:53:48 -0800 (PST) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 1CFB63A69AE for ; Sun, 9 Jan 2011 21:53:48 -0800 (PST) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAHsuKk2rR7H+/2dsb2JhbACkPXOjYpclhUwEhGeGI4Mg Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-6.cisco.com with ESMTP; 10 Jan 2011 05:56:01 +0000 Received: from stealth-10-32-244-218.cisco.com (stealth-10-32-244-218.cisco.com [10.32.244.218]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id p0A5ttVS019656; Mon, 10 Jan 2011 05:56:00 GMT Received: from [127.0.0.1] by stealth-10-32-244-218.cisco.com (PGP Universal service); Sun, 09 Jan 2011 21:56:00 -0800 X-PGP-Universal: processed; by stealth-10-32-244-218.cisco.com on Sun, 09 Jan 2011 21:56:00 -0800 Subject: Re: [Fwd: I-D Action:draft-ietf-6man-flow-update-00.txt] Mime-Version: 1.0 (Apple Message framework v1082) From: Fred Baker In-Reply-To: Date: Sun, 9 Jan 2011 21:55:46 -0800 Message-Id: References: <4CF82E6F.9040309@gmail.com> <4D08165A.3060306@gmail.com> <51661CE4-EC60-46B9-928C-D5763CFDF318@cisco.com> <4D082147.9010209@gmail.com> <4D2A1B84.1020003@gmail.com> <4D2A64A1.4030400@gmail.com> To: Steven Blake X-Mailer: Apple Mail (2.1082) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: 6man , 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: Mon, 10 Jan 2011 05:53:49 -0000 On Jan 9, 2011, at 7:05 PM, Steven Blake wrote: > The network doesn't control port numbers, so his argument obviously = doesn't apply to ECMP or LAG. There are more than two common uses of load balancing. ECMP is a side = effect of routing; we decide to multipath route when we know of two next = hops that get us to a remote destination with the same routing metric. = Link Aggregation (LAG) is what is done when I have multiple paths = between myself and my next hop and want to distribute a data stream = across them. Yes, those are important. The most common use of load balancing is most likely the use in data = centers, where I decide that (to pick but one example) a given HTTP GET = is appropriate to one set of servers and a different one, perhaps within = the same pipelined TCP session, is appropriate to a different one, and = multiplex the session across these sets of servers as appropriate. If = you look up the class of products referred to as "load balancers", you = will find them in those and similar applications. There are a number of = other uses, but they are typified by that use case. If I want a random hash, I can - and do, and have since before the = Internet was a commercial network - already generate that, by hashing = the pseudoheader (actually just the source and destination address) of a = stream of datagrams. That means that I don't have to remember which flow = label I sent on one path and which I sent on another. If you want to = tell me "oh, I take the modulus of the flow label with the number of = servers I have to select which server", or any similar stateless = algorithm, I can do it with that hash just as easily. And yes, that = gives me a session predictably going to the same server. But it doesn't = allow me to balance loads. To balance loads, I need to estimate the load = on individual paths, and assign new data streams to paths as they change = in their actual loading. What having the network be in control of the flow label does is allow = the network to balance loads. Which is what you were trying to do, = wasn't it?= From jmh@joelhalpern.com Mon Jan 10 05:30: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 0D2ED28C159 for ; Mon, 10 Jan 2011 05:30:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.057 X-Spam-Level: X-Spam-Status: No, score=-103.057 tagged_above=-999 required=5 tests=[AWL=0.542, 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 PwS-m-c7+WNm for ; Mon, 10 Jan 2011 05:30:54 -0800 (PST) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id 1458728C158 for ; Mon, 10 Jan 2011 05:30:54 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 195A84300B6; Mon, 10 Jan 2011 05:33:08 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at hermes.tigertech.net Received: from [10.10.10.101] (pool-71-161-51-169.clppva.btas.verizon.net [71.161.51.169]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by hermes.tigertech.net (Postfix) with ESMTPSA id 048504300A5; Mon, 10 Jan 2011 05:33:06 -0800 (PST) Message-ID: <4D2B0A8E.2010805@joelhalpern.com> Date: Mon, 10 Jan 2011 08:33:02 -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: Fred Baker Subject: Re: [Fwd: I-D Action:draft-ietf-6man-flow-update-00.txt] References: <4CF82E6F.9040309@gmail.com> <4D08165A.3060306@gmail.com> <51661CE4-EC60-46B9-928C-D5763CFDF318@cisco.com> <4D082147.9010209@gmail.com> <4D2A1B84.1020003@gmail.com> <4D2A64A1.4030400@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: 6man , Brian E Carpenter , Steven Blake 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, 10 Jan 2011 13:30:55 -0000 A data center load balancer can afford, by its nature, to do as much work as it needs to in order to get the information it needs. The same can not be said for the ECMP / LAG case which Brian, Shane, Steve, and I have been talking about. Specifically, with the structure of extension headers, the possible use of crypto, and the use of tunnels (and probably other issues), it becomes more and more difficult for network devices along the path which need to perofrm ECMP or LAG (L3 or L2 sleection among equivalent paths) while keeping flows together, to do their job. By getting the flow label used in a way that carries enough information, this problem can become MUCH simpler. None of your concerns seem to relate to the this problem. In particular, I see no issue of network side control for this. Yours, Joel On 1/10/2011 12:55 AM, Fred Baker wrote: > > On Jan 9, 2011, at 7:05 PM, Steven Blake wrote: > >> The network doesn't control port numbers, so his argument obviously doesn't apply to ECMP or LAG. > > There are more than two common uses of load balancing. ECMP is a side effect of routing; we decide to multipath route when we know of two next hops that get us to a remote destination with the same routing metric. Link Aggregation (LAG) is what is done when I have multiple paths between myself and my next hop and want to distribute a data stream across them. Yes, those are important. > > The most common use of load balancing is most likely the use in data centers, where I decide that (to pick but one example) a given HTTP GET is appropriate to one set of servers and a different one, perhaps within the same pipelined TCP session, is appropriate to a different one, and multiplex the session across these sets of servers as appropriate. If you look up the class of products referred to as "load balancers", you will find them in those and similar applications. There are a number of other uses, but they are typified by that use case. > > If I want a random hash, I can - and do, and have since before the Internet was a commercial network - already generate that, by hashing the pseudoheader (actually just the source and destination address) of a stream of datagrams. That means that I don't have to remember which flow label I sent on one path and which I sent on another. If you want to tell me "oh, I take the modulus of the flow label with the number of servers I have to select which server", or any similar stateless algorithm, I can do it with that hash just as easily. And yes, that gives me a session predictably going to the same server. But it doesn't allow me to balance loads. To balance loads, I need to estimate the load on individual paths, and assign new data streams to paths as they change in their actual loading. > > What having the network be in control of the flow label does is allow the network to balance loads. Which is what you were trying to do, wasn't it? > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > From narten@us.ibm.com Mon Jan 10 06:08: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 A79E328C17E for ; Mon, 10 Jan 2011 06:08:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.99 X-Spam-Level: X-Spam-Status: No, score=-105.99 tagged_above=-999 required=5 tests=[AWL=0.609, 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 n9yCPXpr0nwV for ; Mon, 10 Jan 2011 06:08:31 -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 C831C28C17C for ; Mon, 10 Jan 2011 06:08:30 -0800 (PST) Received: from d03relay05.boulder.ibm.com (d03relay05.boulder.ibm.com [9.17.195.107]) by e34.co.us.ibm.com (8.14.4/8.13.1) with ESMTP id p0ADxeYl013472 for ; Mon, 10 Jan 2011 06:59:40 -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 p0AEASZJ066808 for ; Mon, 10 Jan 2011 07:10:29 -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 p0AEErHe017202 for ; Mon, 10 Jan 2011 07:14:54 -0700 Received: from cichlid.raleigh.ibm.com (sig-9-48-42-70.mts.ibm.com [9.48.42.70]) by d03av06.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id p0AEEq3g017103 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 10 Jan 2011 07:14: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 p0AEAPNs007778; Mon, 10 Jan 2011 09:10:25 -0500 Message-Id: <201101101410.p0AEAPNs007778@cichlid.raleigh.ibm.com> To: Brian E Carpenter Subject: Psuedo-randomness in flow labels [was Re: [Fwd: I-D Action:draft-ietf-6man-flow-update-00.txt]] In-reply-to: <4D2A64A1.4030400@gmail.com> References: <4CF82E6F.9040309@gmail.com> <4D08165A.3060306@gmail.com> <51661CE4-EC60-46B9-928C-D5763CFDF318@cisco.com> <4D082147.9010209@gmail.com> <4D2A1B84.1020003@gmail.com> <4D2A64A1.4030400@gmail.com> Comments: In-reply-to Brian E Carpenter message dated "Mon, 10 Jan 2011 14:45:05 +1300." Date: Mon, 10 Jan 2011 09:10:25 -0500 From: Thomas Narten Cc: 6man , Fred Baker 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, 10 Jan 2011 14:08:32 -0000 Brian E Carpenter writes: > I'm confused. We've been talking for months about recommending > pseudo-random flow label values as inputs to hash functions, > precisely to allow scaleable and stateless load balancing and ECMP. I have a general issue with the above, but I'm not sure whether its a real issue or just terminology. The crux of the issue is the following: > 1. It is RECOMMENDED that source hosts support the flow label by > setting the flow label field for all packets of a flow to the > same pseudo-random value. I do not see a reason to require this. The goal of using the Flow Label with load balancing is to include it as input to the hash in order to produce a more uniform spread of the output of the hash, and specifically, so different flows from the same machine can be sent across different links. You do NOT need uniform spread on the input to the hash to get such an output. A decent hash algorithm is what you need. You also don't need Flow Labels selected in a psuedo random fashion. RFC 3697 says specifically you can assign Flow Label values sequentially. And that works just fine with the modulo(N) algorithm specified in the ECMP document. Note that I am in favor of suggesting that the Flow Label be included in the hash when doing load balancing. Its a no brainer. At worst, its a now op. But it certainly is never better to exclude it. What I don't think is needed, is *any* requirement for pseudo-randomness on the actual Flow Label values. Thomas From Internet-Drafts@ietf.org Mon Jan 10 07:00: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 74AA73A69B7; Mon, 10 Jan 2011 07:00:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.534 X-Spam-Level: X-Spam-Status: No, score=-102.534 tagged_above=-999 required=5 tests=[AWL=0.065, 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 xiSv+6DisujD; Mon, 10 Jan 2011 07:00:04 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C58CF3A69C5; Mon, 10 Jan 2011 07:00: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-dad-proxy-00.txt X-Test-IDTracker: no X-IETF-IDTracker: 3.10 Message-ID: <20110110150002.25108.52597.idtracker@localhost> Date: Mon, 10 Jan 2011 07:00: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: Mon, 10 Jan 2011 15:00: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 : Duplicate Address Detection Proxy Author(s) : F. Costa, et al. Filename : draft-ietf-6man-dad-proxy-00.txt Pages : 13 Date : 2011-01-10 The document describes a mechanism allowing the use of Duplicate Address Detection (DAD) by IPv6 nodes in a point-to-multipoint architecture with "split-horizon" forwarding scheme. Based on the DAD signalling, the first hop router stores in a Binding Table all known IPv6 addresses used on a point-to-multipoint domain (e.g. VLAN). When a node performs DAD for an address already used by another node, the first hop router replies instead of this last one. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-6man-dad-proxy-00.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-dad-proxy-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-01-10065329.I-D@ietf.org> --NextPart-- From huitema@microsoft.com Mon Jan 10 11:23: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 55F643A6B09 for ; Mon, 10 Jan 2011 11:23:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.343 X-Spam-Level: X-Spam-Status: No, score=-10.343 tagged_above=-999 required=5 tests=[AWL=0.256, 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 WEOGE6WRtFZn for ; Mon, 10 Jan 2011 11:23:53 -0800 (PST) Received: from smtp.microsoft.com (smtp.microsoft.com [131.107.115.215]) by core3.amsl.com (Postfix) with ESMTP id 5947D3A6B07 for ; Mon, 10 Jan 2011 11:23:53 -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; Mon, 10 Jan 2011 11:26:02 -0800 Received: from TK5EX14MLTW651.wingroup.windeploy.ntdev.microsoft.com (157.54.71.39) by TK5EX14HUBC101.redmond.corp.microsoft.com (157.54.7.153) with Microsoft SMTP Server (TLS) id 14.1.255.3; Mon, 10 Jan 2011 11:26:02 -0800 Received: from TK5EX14MBXW653.wingroup.windeploy.ntdev.microsoft.com ([169.254.3.137]) by TK5EX14MLTW651.wingroup.windeploy.ntdev.microsoft.com ([157.54.71.39]) with mapi; Mon, 10 Jan 2011 11:26:02 -0800 From: Christian Huitema To: Thomas Narten , Brian E Carpenter Subject: RE: Psuedo-randomness in flow labels [was Re: [Fwd: I-D Action:draft-ietf-6man-flow-update-00.txt]] Thread-Topic: Psuedo-randomness in flow labels [was Re: [Fwd: I-D Action:draft-ietf-6man-flow-update-00.txt]] Thread-Index: AQHLsNBLiZOVM68AmEO2q8SYbTUdCZPKlYyQ Date: Mon, 10 Jan 2011 19:26:00 +0000 Message-ID: References: <4CF82E6F.9040309@gmail.com> <4D08165A.3060306@gmail.com> <51661CE4-EC60-46B9-928C-D5763CFDF318@cisco.com> <4D082147.9010209@gmail.com> <4D2A1B84.1020003@gmail.com> <4D2A64A1.4030400@gmail.com> <201101101410.p0AEAPNs007778@cichlid.raleigh.ibm.com> In-Reply-To: <201101101410.p0AEAPNs007778@cichlid.raleigh.ibm.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 Cc: 6man , Fred Baker 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, 10 Jan 2011 19:23:54 -0000 Fred wrote: > Note that I am in favor of suggesting that the Flow Label be included in = the hash when doing load balancing. It is a no brainer. At worst, it is a n= o op. But it certainly is never better to exclude it. Have you looked at the security implications? Suppose that an attacker can = predict the hash algorithm used by a router. This attacker could then pick = "interesting" values of the flow ID, to get the flow of traffic directed to= particular paths, or not. For example, they could systematically but a dif= ferent flow label to each packet to ensure the traffic is spread over all a= vailable paths. -- Christian Huitema From narten@us.ibm.com Mon Jan 10 11:49: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 E5BDF3A6B35 for ; Mon, 10 Jan 2011 11:49:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.067 X-Spam-Level: X-Spam-Status: No, score=-106.067 tagged_above=-999 required=5 tests=[AWL=0.532, 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 Di3S1vrTq-ra for ; Mon, 10 Jan 2011 11:49:50 -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 C3F0D3A6B32 for ; Mon, 10 Jan 2011 11:49:49 -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 p0AJWtw6001232 for ; Mon, 10 Jan 2011 14:33:09 -0500 Received: from d01relay07.pok.ibm.com (d01relay07.pok.ibm.com [9.56.227.147]) by d01dlp02.pok.ibm.com (Postfix) with ESMTP id 23BDB4DE8042 for ; Mon, 10 Jan 2011 14:48:57 -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 p0AJppCD2416684 for ; Mon, 10 Jan 2011 14:51:51 -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 p0AJpoBj022657 for ; Mon, 10 Jan 2011 14:51:51 -0500 Received: from cichlid.raleigh.ibm.com (sig-9-48-42-70.mts.ibm.com [9.48.42.70]) by d01av01.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id p0AJpn7j022492 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 10 Jan 2011 14:51:50 -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 p0AJpiCp010647; Mon, 10 Jan 2011 14:51:44 -0500 Message-Id: <201101101951.p0AJpiCp010647@cichlid.raleigh.ibm.com> To: Christian Huitema Subject: Re: Psuedo-randomness in flow labels [was Re: [Fwd: I-D Action:draft-ietf-6man-flow-update-00.txt]] In-reply-to: References: <4CF82E6F.9040309@gmail.com> <4D08165A.3060306@gmail.com> <51661CE4-EC60-46B9-928C-D5763CFDF318@cisco.com> <4D082147.9010209@gmail.com> <4D2A1B84.1020003@gmail.com> <4D2A64A1.4030400@gmail.com> <201101101410.p0AEAPNs007778@cichlid.raleigh.ibm.com> Comments: In-reply-to Christian Huitema message dated "Mon, 10 Jan 2011 19:26:00 +0000." Date: Mon, 10 Jan 2011 14:51:44 -0500 From: Thomas Narten X-Content-Scanned: Fidelis XPS MAILER Cc: 6man , Brian E Carpenter , Fred Baker 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, 10 Jan 2011 19:49:51 -0000 > Have you looked at the security implications? Suppose that an > attacker can predict the hash algorithm used by a router. This > attacker could then pick "interesting" values of the flow ID, to > get the flow of traffic directed to particular paths, or not. For > example, they could systematically but a different flow label to > each packet to ensure the traffic is spread over all available > paths. Yes, this is a potential problem. That said, the router has no assurance that the Flow Label values are not predictable, since it is others that set its value. Thus, no router can *depend* on the properties of the Flow Label to be psuedo random. Thus, nothing we require of the sender can obviate the need for a router to assume worst-case behavior from a DOS perspective. I.e., routers would do well (if they are concerned) to do something not predicitable in terms of the hash it uses. Yes, that increases the cost of the hash, but in today's world of Bad Guys doing Evil Things, it may just be a cost of doing business. :-( But IMO, it is not a requirement for the sender to choose psuedo-random values for the Flow ID, and because there is no way to enforce that in general there doesn't seem to me to be clear reason to do so. Routers will not be able to rely on such properties in any case, which is what the real issue is. Thomas From Internet-Drafts@ietf.org Mon Jan 10 12:45: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 279183A6405; Mon, 10 Jan 2011 12:45:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.553 X-Spam-Level: X-Spam-Status: No, score=-102.553 tagged_above=-999 required=5 tests=[AWL=0.046, 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 DZQuwktBORXk; Mon, 10 Jan 2011 12:45:03 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EA0E83A659C; Mon, 10 Jan 2011 12:45: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-update-01.txt X-Test-IDTracker: no X-IETF-IDTracker: 3.10 Message-ID: <20110110204501.5529.93315.idtracker@localhost> Date: Mon, 10 Jan 2011 12:45: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: Mon, 10 Jan 2011 20:45: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 : Update to the IPv6 flow label specification Author(s) : S. Amante, et al. Filename : draft-ietf-6man-flow-update-01.txt Pages : 13 Date : 2011-01-10 Various published proposals for use of the IPv6 flow label are incompatible with its existing 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 describes and motivates proposed changes to the specification in order to clarify it, making it clear what types of usage are possible, and to introduce some additional flexibility. It does not formally update RFC 3697. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-6man-flow-update-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-update-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-01-10124457.I-D@ietf.org> --NextPart-- From brian.e.carpenter@gmail.com Mon Jan 10 13:08: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 296ED3A67A5 for ; Mon, 10 Jan 2011 13:08:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.405 X-Spam-Level: X-Spam-Status: No, score=-103.405 tagged_above=-999 required=5 tests=[AWL=0.194, 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 SKD-tR2hSOGl for ; Mon, 10 Jan 2011 13:08:19 -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 CCD483A67B2 for ; Mon, 10 Jan 2011 13:08:18 -0800 (PST) Received: by fxm9 with SMTP id 9so19599125fxm.31 for ; Mon, 10 Jan 2011 13:10:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :organization:user-agent:mime-version:to:subject:content-type :content-transfer-encoding; bh=wZm8zWrxuSxfpcS9XmTauufBEdxqYq83UB/e0nV5zxs=; b=dHOt0qi0xQ03KmGzShsa5U/qKhAKcfLJmnzZYHAK4zUxgGG6jqzLldSFTxwGX6YSzg WEgYuyMCSgdYgs+Xl6Mch0op9+D60qJAo1EngQqsjenAUzght0FXFaPcaSaoEuPho2hP kxy5qnYiuubXzLOm7AxDDGKkVfS6Bf7XE4LUk= 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=Bi4oropa8TrJ42iRzaFNwVRQ8WXvUfA5E8jfF1U/jRL7Rn8cVc6Q2ZDqAgy1MzrEKM L71A87buKIwHCkIs4lDm0odJ7+2nk78bSknJGr/yjsqBIfGt/xMyr5Zz5HyJ7cNfKawE cHFwMEHxDvx7u4CfccXcVoauitFNs2NcN3K0s= Received: by 10.223.79.68 with SMTP id o4mr3711583fak.0.1294693832939; Mon, 10 Jan 2011 13:10:32 -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 l14sm7148877fan.33.2011.01.10.13.10.30 (version=SSLv3 cipher=RC4-MD5); Mon, 10 Jan 2011 13:10:31 -0800 (PST) Message-ID: <4D2B75C3.8090100@gmail.com> Date: Tue, 11 Jan 2011 10:10:27 +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-update-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: Mon, 10 Jan 2011 21:08:20 -0000 The changes in this version are basically: - clarified that this is not a formal update of RFC 3697 - clarified text about domains exporting inappropriate labels There are no changes of the intended technical meaning, since as far as we can tell, most of the WG is OK with current technical content. Also see previous replies to comments: http://www.ietf.org/mail-archive/web/ipv6/current/msg13253.html http://www.ietf.org/mail-archive/web/ipv6/current/msg13159.html Brian + Sheng + Shane -------- Original Message -------- Subject: I-D Action:draft-ietf-6man-flow-update-01.txt Date: Mon, 10 Jan 2011 12:45:01 -0800 From: 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 : Update to the IPv6 flow label specification Author(s) : S. Amante, et al. Filename : draft-ietf-6man-flow-update-01.txt Pages : 13 Date : 2011-01-10 Various published proposals for use of the IPv6 flow label are incompatible with its existing 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 describes and motivates proposed changes to the specification in order to clarify it, making it clear what types of usage are possible, and to introduce some additional flexibility. It does not formally update RFC 3697. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-6man-flow-update-01.txt From brian.e.carpenter@gmail.com Mon Jan 10 14:14: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 B01F53A657C for ; Mon, 10 Jan 2011 14:14:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.41 X-Spam-Level: X-Spam-Status: No, score=-103.41 tagged_above=-999 required=5 tests=[AWL=0.189, 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 N3T91xpKjMQF for ; Mon, 10 Jan 2011 14:14:47 -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 624863A63D2 for ; Mon, 10 Jan 2011 14:14:47 -0800 (PST) Received: by fxm9 with SMTP id 9so19658526fxm.31 for ; Mon, 10 Jan 2011 14:17:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :organization:user-agent:mime-version:to:cc:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=kmkjBC10gFypXV0mWr1OwC8a/5P8jvSuF+l2yihmPGg=; b=o0cTbw0uoxKGgnM92zfH29NXj1ubRrJEgNh6vKILajQGI1VZxly/LKlJ36ZbsPyXPX vyj/dfmLMTJqvJ2sAg+uSS6O6CDpNNwOHFNVOJgGSIVPw5XtuBZv4Dfy3M07180WQQc4 Nsqd0TLGDAtsG8A8m6yZcqXYjijmeLLKKCrsU= 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=G+t4IvIQbra9Tqy3LbYYNNkk8vXPAcqyzCtriCTmcAEOc5BH+UYwTB3KFT1v+lQYox /Irf5sNxYrcbOwj483otB+dPB3LxqHLlXE2ufwrQ75xbj4Ooep8WnZ8zwCA+0gwusMIp F4U7Ym+wY+rqHvSHKmakko+c/xLFd701hH3v8= Received: by 10.223.103.6 with SMTP id i6mr2388395fao.84.1294697821622; Mon, 10 Jan 2011 14:17:01 -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 a2sm7174298faw.22.2011.01.10.14.16.58 (version=SSLv3 cipher=RC4-MD5); Mon, 10 Jan 2011 14:17:00 -0800 (PST) Message-ID: <4D2B8557.9090107@gmail.com> Date: Tue, 11 Jan 2011 11:16:55 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Fred Baker Subject: Re: [Fwd: I-D Action:draft-ietf-6man-flow-update-00.txt] References: <4CF82E6F.9040309@gmail.com> <4D08165A.3060306@gmail.com> <51661CE4-EC60-46B9-928C-D5763CFDF318@cisco.com> <4D082147.9010209@gmail.com> <4D2A1B84.1020003@gmail.com> <4D2A64A1.4030400@gmail.com> <982F8CA8-789A-42D6-9C86-E194BA868023@cisco.com> In-Reply-To: <982F8CA8-789A-42D6-9C86-E194BA868023@cisco.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: Mon, 10 Jan 2011 22:14:48 -0000 On 2011-01-10 18:42, Fred Baker wrote: > On Jan 9, 2011, at 5:45 PM, Brian E Carpenter wrote: > >> I'm confused. We've been talking for months about >> recommending pseudo-random flow label values as inputs to >> hash functions, precisely to allow scaleable and stateless >> load balancing and ECMP. >> >> I completely agree that per-flow state doesn't scale. > > This isn't exactly the first time I have made the statement. > I've been on record on this point regarding the flow label > since it was designed to answer NIMROD's definition of a > flow. That is a long time ago, and actually the origin is even older (as noted in draft-hu-flow-label-cases). But anyway, I don't think we're disagreeing on this point. On 2011-01-10 18:55, Fred Baker wrote: > On Jan 9, 2011, at 7:05 PM, Steven Blake wrote: > >>> The network doesn't control port numbers, so his argument >>> obviously doesn't apply to ECMP or LAG. > > There are more than two common uses of load balancing. ECMP > is a side effect of routing; we decide to multipath route > when we know of two next hops that get us to a remote > destination with the same routing metric. Link Aggregation > (LAG) is what is done when I have multiple paths between > myself and my next hop and want to distribute a data stream > across them. Yes, those are important. > > The most common use of load balancing is most likely the use > in data centers, where I decide that (to pick but one > example) a given HTTP GET is appropriate to one set of > servers and a different one, perhaps within the same > pipelined TCP session, is appropriate to a different one, and > multiplex the session across these sets of servers as > appropriate. If you look up the class of products referred to > as "load balancers", you will find them in those and similar > applications. There are a number of other uses, but they are > typified by that use case. Sure, and I think the approach in draft-ietf-6man-flow-ecmp would work there too. > > If I want a random hash, I can - and do, and have since > before the Internet was a commercial network - already > generate that, by hashing the pseudoheader (actually just the > source and destination address) of a stream of datagrams. > That means that I don't have to remember which flow label I > sent on one path and which I sent on another. You don't need to remember anything in the stateless draft-ietf-6man-flow-ecmp model. If you want to > tell me "oh, I take the modulus of the flow label with the > number of servers I have to select which server", or any > similar stateless algorithm, I can do it with that hash just > as easily. And yes, that gives me a session predictably going > to the same server. But it doesn't allow me to balance loads. > To balance loads, I need to estimate the load on individual > paths, and assign new data streams to paths as they change in > their actual loading. Why is that better than a statistical approach? I assume we're talking about thousands of flows. In any case, in massive server farms, the server load may be a more important parameter than the network path load. > > What having the network be in control of the flow label does > is allow the network to balance loads. Which is what you were > trying to do, wasn't it? Well, have you read the fine detail of the current draft (today's version will do fine)? The intent is to provide a default mechanism but to recognize the reality that we cannot prevent network domains doing otherwise. That's what we authors understood to be the WG rough consensus after multiple drafts. Brian From brian.e.carpenter@gmail.com Mon Jan 10 14:23: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 42B8E3A63C9 for ; Mon, 10 Jan 2011 14:23:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.413 X-Spam-Level: X-Spam-Status: No, score=-103.413 tagged_above=-999 required=5 tests=[AWL=0.186, 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 jyNJbY6BbuFE for ; Mon, 10 Jan 2011 14:23:19 -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 14D293A679F for ; Mon, 10 Jan 2011 14:23:18 -0800 (PST) Received: by fxm9 with SMTP id 9so19665487fxm.31 for ; Mon, 10 Jan 2011 14:25:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :organization:user-agent:mime-version:to:cc:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=fZ2XJC2YeOePK6pL8HwHyFeATi1w8yg0RxBAT05UEsc=; b=walvymW+aOam3U35oN9NLuld5iV3ZI0ZYiNGc0gTqXpdSoIvFKHaTYl4khs9Pc1BOy ij+fkp/Wtdz6SahfrXSwOKZPLjTq+HJus7yz9VuCWg8qiK9FKAZocwKHwWpXZHa5Rsfo TNx3XZK1dl5BYa3BKRrOuaKwxMXIgK/mVDefQ= 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=CYANU0pj5mwF2jfl9nKa47yq4d6V3liZ5UZwmLKdPBu35x54PpmS6+3DdIUWSP6IF1 3e0vLIb4ZZAXoE2jrGhKuY7sRb1ytNpK6XtpYS9hxfnJqNtYHCmHSP67giRPRyIDTPGg f/S9NknEWDSX+J+kYNhsOJakPBgf/R5ycnvHM= Received: by 10.223.114.14 with SMTP id c14mr504876faq.103.1294698333431; Mon, 10 Jan 2011 14:25:33 -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 c11sm7174025fav.2.2011.01.10.14.25.29 (version=SSLv3 cipher=RC4-MD5); Mon, 10 Jan 2011 14:25:32 -0800 (PST) Message-ID: <4D2B8757.7050605@gmail.com> Date: Tue, 11 Jan 2011 11:25:27 +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: Psuedo-randomness in flow labels [was Re: [Fwd: I-D Action:draft-ietf-6man-flow-update-00.txt]] References: <4CF82E6F.9040309@gmail.com> <4D08165A.3060306@gmail.com> <51661CE4-EC60-46B9-928C-D5763CFDF318@cisco.com> <4D082147.9010209@gmail.com> <4D2A1B84.1020003@gmail.com> <4D2A64A1.4030400@gmail.com> <201101101410.p0AEAPNs007778@cichlid.raleigh.ibm.com> <201101101951.p0AJpiCp010647@cichlid.raleigh.ibm.com> In-Reply-To: <201101101951.p0AJpiCp010647@cichlid.raleigh.ibm.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Christian Huitema , 6man , Fred Baker 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, 10 Jan 2011 22:23:20 -0000 I'm not sure there's a problem here. The draft has the pseudo-random label as a SHOULD and Fernando's crypto algorithm as OPTIONAL. The problem with the RFC 3697 text is that it apparently encouraged lots of people to design complex schemes for encoding semantics in the flow label. Given that we expect people to put flow labels into a hash function of some kind, a 20-bit pseudo random number seems like a better default than 1,2,3,... (depending on the hash function, obviously). Regards Brian On 2011-01-11 08:51, Thomas Narten wrote: >> Have you looked at the security implications? Suppose that an >> attacker can predict the hash algorithm used by a router. This >> attacker could then pick "interesting" values of the flow ID, to >> get the flow of traffic directed to particular paths, or not. For >> example, they could systematically but a different flow label to >> each packet to ensure the traffic is spread over all available >> paths. > > Yes, this is a potential problem. > > That said, the router has no assurance that the Flow Label values are > not predictable, since it is others that set its value. Thus, no > router can *depend* on the properties of the Flow Label to be psuedo > random. Thus, nothing we require of the sender can obviate the need > for a router to assume worst-case behavior from a DOS perspective. > > I.e., routers would do well (if they are concerned) to do something > not predicitable in terms of the hash it uses. Yes, that increases the > cost of the hash, but in today's world of Bad Guys doing Evil Things, > it may just be a cost of doing business. :-( > > But IMO, it is not a requirement for the sender to choose > psuedo-random values for the Flow ID, and because there is no way to > enforce that in general there doesn't seem to me to be clear reason to > do so. Routers will not be able to rely on such properties in any > case, which is what the real issue is. > > Thomas > From narten@us.ibm.com Mon Jan 10 14:29: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 69AAD3A679F for ; Mon, 10 Jan 2011 14:29:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.126 X-Spam-Level: X-Spam-Status: No, score=-104.126 tagged_above=-999 required=5 tests=[AWL=-1.527, 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 ANlNgRxmuDxv for ; Mon, 10 Jan 2011 14:29:20 -0800 (PST) Received: from e9.ny.us.ibm.com (e9.ny.us.ibm.com [32.97.182.139]) by core3.amsl.com (Postfix) with ESMTP id 81DA53A6767 for ; Mon, 10 Jan 2011 14:29:20 -0800 (PST) Received: from d01dlp02.pok.ibm.com (d01dlp02.pok.ibm.com [9.56.224.85]) by e9.ny.us.ibm.com (8.14.4/8.13.1) with ESMTP id p0AM7VAM016187 for ; Mon, 10 Jan 2011 17:07:31 -0500 Received: from d01relay01.pok.ibm.com (d01relay01.pok.ibm.com [9.56.227.233]) by d01dlp02.pok.ibm.com (Postfix) with ESMTP id AC2CB4DE8044 for ; Mon, 10 Jan 2011 17:28:29 -0500 (EST) Received: from d01av03.pok.ibm.com (d01av03.pok.ibm.com [9.56.224.217]) by d01relay01.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id p0AMVTYA383592 for ; Mon, 10 Jan 2011 17:31:29 -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 p0AMVSqR009115 for ; Mon, 10 Jan 2011 20:31:28 -0200 Received: from cichlid.raleigh.ibm.com (sig-9-48-42-70.mts.ibm.com [9.48.42.70]) by d01av03.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id p0AMVRLL009056 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 10 Jan 2011 20:31:27 -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 p0AMVQ5Z014983; Mon, 10 Jan 2011 17:31:26 -0500 Message-Id: <201101102231.p0AMVQ5Z014983@cichlid.raleigh.ibm.com> To: Brian E Carpenter Subject: Re: Psuedo-randomness in flow labels [was Re: [Fwd: I-D Action:draft-ietf-6man-flow-update-00.txt]] In-reply-to: <4D2B8757.7050605@gmail.com> References: <4CF82E6F.9040309@gmail.com> <4D08165A.3060306@gmail.com> <51661CE4-EC60-46B9-928C-D5763CFDF318@cisco.com> <4D082147.9010209@gmail.com> <4D2A1B84.1020003@gmail.com> <4D2A64A1.4030400@gmail.com> <201101101410.p0AEAPNs007778@cichlid.raleigh.ibm.com> <201101101951.p0AJpiCp010647@cichlid.raleigh.ibm.com> <4D2B8757.7050605@gmail.com> Comments: In-reply-to Brian E Carpenter message dated "Tue, 11 Jan 2011 11:25:27 +1300." Date: Mon, 10 Jan 2011 17:31:26 -0500 From: Thomas Narten X-Content-Scanned: Fidelis XPS MAILER Cc: Christian Huitema , 6man , Fred Baker 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, 10 Jan 2011 22:29:21 -0000 Brian E Carpenter writes: > I'm not sure there's a problem here. The draft has the > pseudo-random label as a SHOULD and Fernando's crypto > algorithm as OPTIONAL. The problem with the RFC 3697 > text is that it apparently encouraged lots of people > to design complex schemes for encoding semantics in the > flow label. I don't follow that last sentence. Can you expand? > Given that we expect people to put flow labels into a > hash function of some kind, a 20-bit pseudo random number > seems like a better default than 1,2,3,... (depending on > the hash function, obviously). I want to challenge that up front. For the example in your draft, MODULO(n), incrementing by one has wonderful properties. Given that incrementing by 1 is about as simple as it gets, that seems like a fine thing to do. There may be security downsides by having such a predicable generator at the source, but that is a different issue than making it hash well. Thomas From fred@cisco.com Mon Jan 10 14:48: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 C9DF93A67A5 for ; Mon, 10 Jan 2011 14:48:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.438 X-Spam-Level: X-Spam-Status: No, score=-110.438 tagged_above=-999 required=5 tests=[AWL=0.161, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 lQah3X2Rxukt for ; Mon, 10 Jan 2011 14:48:02 -0800 (PST) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 2B2073A679F for ; Mon, 10 Jan 2011 14:48:02 -0800 (PST) Authentication-Results: sj-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEADMbK02rRN+J/2dsb2JhbACkS3OieZhhhUwEhGeGI4Mg Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-1.cisco.com with ESMTP; 10 Jan 2011 22:50:17 +0000 Received: from stealth-10-32-244-218.cisco.com (stealth-10-32-244-218.cisco.com [10.32.244.218]) by sj-core-3.cisco.com (8.13.8/8.14.3) with ESMTP id p0AMoBKT017762; Mon, 10 Jan 2011 22:50:16 GMT Received: from [127.0.0.1] by stealth-10-32-244-218.cisco.com (PGP Universal service); Mon, 10 Jan 2011 14:50:16 -0800 X-PGP-Universal: processed; by stealth-10-32-244-218.cisco.com on Mon, 10 Jan 2011 14:50:16 -0800 Subject: Re: Psuedo-randomness in flow labels [was Re: [Fwd: I-D Action:draft-ietf-6man-flow-update-00.txt]] Mime-Version: 1.0 (Apple Message framework v1082) From: Fred Baker In-Reply-To: Date: Mon, 10 Jan 2011 14:50:02 -0800 Message-Id: <53D8FCFF-D460-4BFF-A118-9E5C41AF710B@cisco.com> References: <4CF82E6F.9040309@gmail.com> <4D08165A.3060306@gmail.com> <51661CE4-EC60-46B9-928C-D5763CFDF318@cisco.com> <4D082147.9010209@gmail.com> <4D2A1B84.1020003@gmail.com> <4D2A64A1.4030400@gmail.com> <201101101410.p0AEAPNs007778@cichlid.raleigh.ibm.com> To: Christian Huitema X-Mailer: Apple Mail (2.1082) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: Thomas Narten , 6man , 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: Mon, 10 Jan 2011 22:48:02 -0000 On Jan 10, 2011, at 11:26 AM, Christian Huitema wrote: > Fred wrote: >=20 >> Note that I am in favor of suggesting that the Flow Label be included = in the hash when doing load balancing. It is a no brainer. At worst, it = is a no op. But it certainly is never better to exclude it. >=20 > Have you looked at the security implications? Suppose that an attacker = can predict the hash algorithm used by a router. This attacker could = then pick "interesting" values of the flow ID, to get the flow of = traffic directed to particular paths, or not. For example, they could = systematically but a different flow label to each packet to ensure the = traffic is spread over all available paths. Or he could hit a large number of flows, play with them to see which = values achieve what he's trying to achieve, and simply use them - = without knowledge of the game aforehand. Unless, of course, the network is in control of the flow label. If the = network is in control of the flow label, it is in a position to change = that.= From brian.e.carpenter@gmail.com Mon Jan 10 14:49: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 3E3973A672F for ; Mon, 10 Jan 2011 14:49:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.416 X-Spam-Level: X-Spam-Status: No, score=-103.416 tagged_above=-999 required=5 tests=[AWL=0.183, 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 dQ2ko8r86vm8 for ; Mon, 10 Jan 2011 14:49:29 -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 378A53A657C for ; Mon, 10 Jan 2011 14:49:29 -0800 (PST) Received: by wwa36 with SMTP id 36so20012508wwa.13 for ; Mon, 10 Jan 2011 14:51:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :organization:user-agent:mime-version:to:cc:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=8SBCC7TNcxdP+wQ/UOzdn121zk4lTz4PSM6GksliQNk=; b=lZz1YdDM6SyV5tENe/eTm8gAXc83FmNe1US5Scsg61KLXPDbVDHk0ZiPA1hnVeTFqz EVy0mVAsNatqgQMZNgkWEJQG+dwUaSWTv36WSYBiwXtRRVUdNTrSFSa2aXXWxrPSph+D OU20g9YAfUjO8uwu5TeA3SzMYu4toLc3OAd0o= 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=SerhKNVKpbBe/Zpo2lQDwckW7ll6W9IPj+o+9eh9n5EsB315Ym0VysEd9QbBKie0UL qEYXRbx4tDTNxJapq2Fi/qJPCuqLj/Vn77nic5kBJ+2jHisGw4vH/dVXYojbdhwkpzxn o/DvZx4qJZ34TMpLPJ7tslQERfTpZTinTr/RM= Received: by 10.216.185.142 with SMTP id u14mr2321789wem.31.1294699903454; Mon, 10 Jan 2011 14:51:43 -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 r6sm14387001weq.44.2011.01.10.14.51.39 (version=SSLv3 cipher=RC4-MD5); Mon, 10 Jan 2011 14:51:42 -0800 (PST) Message-ID: <4D2B8D78.9040808@gmail.com> Date: Tue, 11 Jan 2011 11:51:36 +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: Psuedo-randomness in flow labels [was Re: [Fwd: I-D Action:draft-ietf-6man-flow-update-00.txt]] References: <4CF82E6F.9040309@gmail.com> <4D08165A.3060306@gmail.com> <51661CE4-EC60-46B9-928C-D5763CFDF318@cisco.com> <4D082147.9010209@gmail.com> <4D2A1B84.1020003@gmail.com> <4D2A64A1.4030400@gmail.com> <201101101410.p0AEAPNs007778@cichlid.raleigh.ibm.com> <201101101951.p0AJpiCp010647@cichlid.raleigh.ibm.com> <4D2B8757.7050605@gmail.com> <201101102231.p0AMVQ5Z014983@cichlid.raleigh.ibm.com> In-Reply-To: <201101102231.p0AMVQ5Z014983@cichlid.raleigh.ibm.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Christian Huitema , 6man , Fred Baker 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, 10 Jan 2011 22:49:30 -0000 Hi Thomas, On 2011-01-11 11:31, Thomas Narten wrote: > Brian E Carpenter writes: > >> I'm not sure there's a problem here. The draft has the >> pseudo-random label as a SHOULD and Fernando's crypto >> algorithm as OPTIONAL. The problem with the RFC 3697 >> text is that it apparently encouraged lots of people >> to design complex schemes for encoding semantics in the >> flow label. > > I don't follow that last sentence. Can you expand? See draft-hu-flow-label-cases, section 3, for several examples. > >> Given that we expect people to put flow labels into a >> hash function of some kind, a 20-bit pseudo random number >> seems like a better default than 1,2,3,... (depending on >> the hash function, obviously). > > I want to challenge that up front. > > For the example in your draft, MODULO(n), incrementing by one has > wonderful properties. Given that incrementing by 1 is about as simple > as it gets, that seems like a fine thing to do. Yes, certainly, if the modulo is applied directly to the value. But in practice it seems more likely that the value will be hashed up with the traditional 5 tuple, and in that case having 20 variable bits will do more to produce an even distribution of values than if the sources only vary the low-order bits. (Assuming that most sources are only generating a modest number of flows. If a source is generating a few million flows an hour, this argument doesn't apply.) > There may be security downsides by having such a predicable generator > at the source, but that is a different issue than making it hash well. Yes. Should we be using that argument more strongly in the draft? > > Thomas > From brian.e.carpenter@gmail.com Mon Jan 10 15:06: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 80FBC3A6403 for ; Mon, 10 Jan 2011 15:06:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.42 X-Spam-Level: X-Spam-Status: No, score=-103.42 tagged_above=-999 required=5 tests=[AWL=0.179, 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 9EDgxN6RbebZ for ; Mon, 10 Jan 2011 15:06:35 -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 9DD263A657C for ; Mon, 10 Jan 2011 15:06:35 -0800 (PST) Received: by vws7 with SMTP id 7so8103122vws.31 for ; Mon, 10 Jan 2011 15:08:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :organization:user-agent:mime-version:to:cc:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=/Yc/DSRv6a+RbVegJzv5NqO1lk1XMMi2B/mLOYP2yEI=; b=pnrUKr2gIc7WVMmId305AXeeVZ2Iuthk5eXp0RJbf+y7qyIskEL27jsG9Yd3N9BWo/ euYOQmfwv4y3NVjYyya9bHT84/y5ylNw2C8CZjqEcC3jIah7Hk26Mwu8iHrCXUZ8ZMja 8rUGYkyziU7MwbFCmcHulNE+oaqEN7z2f9AGo= 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=nh8K0E34yMoNnxRvomUgGr+VGTLPEieh8rgbGM95g/yCeC0aae+CI7jyj7wScC+ZFS S2zALsla+pU7rPPuD5MkNDWe4p5nxmUcRCHLRh+RnrX/NDsgpaziMH/yR6Kfa1IXuoSk SESEXv4Bjd+F7Mtqi7ueMwxXv2QBcKyUwD54k= Received: by 10.220.193.11 with SMTP id ds11mr8926792vcb.209.1294700930322; Mon, 10 Jan 2011 15:08:50 -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 u14sm6496419vcr.1.2011.01.10.15.08.47 (version=SSLv3 cipher=RC4-MD5); Mon, 10 Jan 2011 15:08:50 -0800 (PST) Message-ID: <4D2B917D.5060809@gmail.com> Date: Tue, 11 Jan 2011 12:08:45 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Fred Baker Subject: Re: Psuedo-randomness in flow labels [was Re: [Fwd: I-D Action:draft-ietf-6man-flow-update-00.txt]] References: <4CF82E6F.9040309@gmail.com> <4D08165A.3060306@gmail.com> <51661CE4-EC60-46B9-928C-D5763CFDF318@cisco.com> <4D082147.9010209@gmail.com> <4D2A1B84.1020003@gmail.com> <4D2A64A1.4030400@gmail.com> <201101101410.p0AEAPNs007778@cichlid.raleigh.ibm.com> <53D8FCFF-D460-4BFF-A118-9E5C41AF710B@cisco.com> In-Reply-To: <53D8FCFF-D460-4BFF-A118-9E5C41AF710B@cisco.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Thomas Narten , Christian Huitema , 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: Mon, 10 Jan 2011 23:06:36 -0000 On 2011-01-11 11:50, Fred Baker wrote: > On Jan 10, 2011, at 11:26 AM, Christian Huitema wrote: > >> Fred wrote: >> >>> Note that I am in favor of suggesting that the Flow Label be included in the hash when doing load balancing. It is a no brainer. At worst, it is a no op. But it certainly is never better to exclude it. >> Have you looked at the security implications? Suppose that an attacker can predict the hash algorithm used by a router. This attacker could then pick "interesting" values of the flow ID, to get the flow of traffic directed to particular paths, or not. For example, they could systematically but a different flow label to each packet to ensure the traffic is spread over all available paths. > > Or he could hit a large number of flows, play with them to see which values achieve what he's trying to achieve, and simply use them - without knowledge of the game aforehand. > > Unless, of course, the network is in control of the flow label. If the network is in control of the flow label, it is in a position to change that. I understood the WG to have reached a consensus that we still want to declare the flow label immutable, except for allowing a router to set it if the source host does not. The draft reflects that consensus. Brian From lucyyong@huawei.com Mon Jan 10 15: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 92ADA3A67E9 for ; Mon, 10 Jan 2011 15:38:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.376 X-Spam-Level: X-Spam-Status: No, score=-3.376 tagged_above=-999 required=5 tests=[AWL=1.119, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.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 pWqVaOdzy6HW for ; Mon, 10 Jan 2011 15:38:36 -0800 (PST) Received: from szxga03-in.huawei.com (unknown [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id AF5273A67AE for ; Mon, 10 Jan 2011 15:38:36 -0800 (PST) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LET006GQZ3RZU@szxga03-in.huawei.com> for ipv6@ietf.org; Tue, 11 Jan 2011 07:40:39 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LET00DLTZ3RTA@szxga03-in.huawei.com> for ipv6@ietf.org; Tue, 11 Jan 2011 07:40:39 +0800 (CST) Received: from y736742 ([10.124.12.68]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LET00CP0Z3OWH@szxml06-in.huawei.com> for ipv6@ietf.org; Tue, 11 Jan 2011 07:40:39 +0800 (CST) Date: Mon, 10 Jan 2011 17:40:42 -0600 From: Yong Lucy Subject: RE: [Fwd: I-D Action:draft-ietf-6man-flow-update-00.txt] In-reply-to: <4D2B8557.9090107@gmail.com> To: 'Brian E Carpenter' , 'Fred Baker' Message-id: <015501cbb11f$cce25a80$c60ca8c0@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3664 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Thread-index: AcuxFCNOJys+PAZXQdCnWMPVxlH3mQACRZ7A References: <4CF82E6F.9040309@gmail.com> <4D08165A.3060306@gmail.com> <51661CE4-EC60-46B9-928C-D5763CFDF318@cisco.com> <4D082147.9010209@gmail.com> <4D2A1B84.1020003@gmail.com> <4D2A64A1.4030400@gmail.com> <982F8CA8-789A-42D6-9C86-E194BA868023@cisco.com> <4D2B8557.9090107@gmail.com> 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: Mon, 10 Jan 2011 23:38:37 -0000 > > If you want to > > tell me "oh, I take the modulus of the flow label with the > > number of servers I have to select which server", or any > > similar stateless algorithm, I can do it with that hash just > > as easily. And yes, that gives me a session predictably going > > to the same server. But it doesn't allow me to balance loads. > > To balance loads, I need to estimate the load on individual > > paths, and assign new data streams to paths as they change in > > their actual loading. > > Why is that better than a statistical approach? I assume we're > talking about thousands of flows. In any case, in massive > server farms, the server load may be a more important parameter > than the network path load. [LY] Statistical approach works well under the consumption that there are thousands of flows and they have the similar rates. Today's Internet may have the flows that only have few packets and the flows that have thousands packets per second and last long. Hash does not work well under this condition. [LY] the server load balance and the network path load balance have different criteria. Lucy ------------------------------------------------------- From brian.e.carpenter@gmail.com Mon Jan 10 17:59: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 3D1F928C12B for ; Mon, 10 Jan 2011 17:59:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.431 X-Spam-Level: X-Spam-Status: No, score=-103.431 tagged_above=-999 required=5 tests=[AWL=0.168, 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 AWwFJhVK1-Jf for ; Mon, 10 Jan 2011 17:59:36 -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 486653A6918 for ; Mon, 10 Jan 2011 17:59:36 -0800 (PST) Received: by vws7 with SMTP id 7so8167149vws.31 for ; Mon, 10 Jan 2011 18:01:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :organization:user-agent:mime-version:to:cc:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=Mim/SWwOgnB24742e1X0nQNH4bf8beRuzaBFDx6n4r0=; b=YJqd2NYJAeDyVur2omG/BP7E/XGeWsJJcOrtyziiRyTF8ewO3cqnB/H4KadQTQNa4Q yjjPvLC+nTRVLQsio83BQTA7f1rIYqLD338US00AOPh5rhHZnvk3/80iV03FVPjhZHST sHUUaijF8OGeag2oky2Foi8Ihj3iHSejSGfWU= 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=nwjqpP0t+s0PBH+0zW4sxSu9jn3d13Cc4qOwudMSWwLsBh3c5KDvlGWzvH2juFSZEz pxIVZbIjAvNmGyxND1rP1psUW/XeXk0ESp1SEMqPO5FkbB8agalZadEXOXshrzGnfo// 9yP2wW4KtnbW2UwLqQiuX3UksmMjpnBJZ1rn4= Received: by 10.220.96.202 with SMTP id i10mr9037139vcn.191.1294711311347; Mon, 10 Jan 2011 18:01:51 -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 c8sm6563968vcc.9.2011.01.10.18.01.49 (version=SSLv3 cipher=RC4-MD5); Mon, 10 Jan 2011 18:01:50 -0800 (PST) Message-ID: <4D2BBA15.309@gmail.com> Date: Tue, 11 Jan 2011 15:01:57 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Yong Lucy Subject: Re: [Fwd: I-D Action:draft-ietf-6man-flow-update-00.txt] References: <4CF82E6F.9040309@gmail.com> <4D08165A.3060306@gmail.com> <51661CE4-EC60-46B9-928C-D5763CFDF318@cisco.com> <4D082147.9010209@gmail.com> <4D2A1B84.1020003@gmail.com> <4D2A64A1.4030400@gmail.com> <982F8CA8-789A-42D6-9C86-E194BA868023@cisco.com> <4D2B8557.9090107@gmail.com> <015501cbb11f$cce25a80$c60ca8c0@china.huawei.com> In-Reply-To: <015501cbb11f$cce25a80$c60ca8c0@china.huawei.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: '6man' , 'Fred Baker' 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, 11 Jan 2011 01:59:37 -0000 On 2011-01-11 12:40, Yong Lucy wrote: >> If you want to >>> tell me "oh, I take the modulus of the flow label with the >>> number of servers I have to select which server", or any >>> similar stateless algorithm, I can do it with that hash just >>> as easily. And yes, that gives me a session predictably going >>> to the same server. But it doesn't allow me to balance loads. >>> To balance loads, I need to estimate the load on individual >>> paths, and assign new data streams to paths as they change in >>> their actual loading. >> Why is that better than a statistical approach? I assume we're >> talking about thousands of flows. In any case, in massive >> server farms, the server load may be a more important parameter >> than the network path load. > > > [LY] Statistical approach works well under the consumption that there are > thousands of flows and they have the similar rates. Today's Internet may > have the flows that only have few packets and the flows that have thousands > packets per second and last long. Hash does not work well under this > condition. In fact no solution works well for short flows and the problem isn't important for long flows with few packets. So I think it's OK to discuss a solution that works for long flows with many packets, since that covers most of the load. > > [LY] the server load balance and the network path load balance have > different criteria. Very true. It isn't clear to me that balancing the network load without knowledge of the server load is a good idea. Brian From shane@castlepoint.net Mon Jan 10 18:16: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 5A9E628C163 for ; Mon, 10 Jan 2011 18:16:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.574 X-Spam-Level: X-Spam-Status: No, score=-2.574 tagged_above=-999 required=5 tests=[AWL=0.025, 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 joZrglq51pCC for ; Mon, 10 Jan 2011 18:16:34 -0800 (PST) Received: from dog.tcb.net (dog.tcb.net [64.78.150.133]) by core3.amsl.com (Postfix) with ESMTP id 7853C28C18C for ; Mon, 10 Jan 2011 18:16:34 -0800 (PST) Received: by dog.tcb.net (Postfix, from userid 0) id 55B0F2684EA; Mon, 10 Jan 2011 19:18:49 -0700 (MST) Received: from host2.tcb.net (64.78.235.218 [64.78.235.218]) (authenticated-user smtp) (TLSv1/SSLv3 AES128-SHA 128/128) by dog.tcb.net with SMTP; Mon, 10 Jan 2011 19:18:49 -0700 (MST) (envelope-from shane@castlepoint.net) X-Avenger: version=0.7.8; receiver=dog.tcb.net; client-ip=64.78.235.218; client-port=53032; data-bytes=0 Subject: Re: Psuedo-randomness in flow labels [was Re: [Fwd: I-D Action:draft-ietf-6man-flow-update-00.txt]] Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Shane Amante In-Reply-To: <201101102231.p0AMVQ5Z014983@cichlid.raleigh.ibm.com> Date: Mon, 10 Jan 2011 19:18:47 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <4B949B24-C97D-4620-94C1-46383C927FC3@castlepoint.net> References: <4CF82E6F.9040309@gmail.com> <4D08165A.3060306@gmail.com> <51661CE4-EC60-46B9-928C-D5763CFDF318@cisco.com> <4D082147.9010209@gmail.com> <4D2A1B84.1020003@gmail.com> <4D2A64A1.4030400@gmail.com> <201101101410.p0AEAPNs007778@cichlid.raleigh.ibm.com> <201101101951.p0AJpiCp010647@cichlid.raleigh.ibm.com> <4D2B8757.7050605@gmail.com> <201101102231.p0AMVQ5Z014983@cichlid.raleigh.ibm.com> To: Thomas Narten X-Mailer: Apple Mail (2.1082) Cc: Christian Huitema , 6man , Brian E Carpenter , Fred Baker 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, 11 Jan 2011 02:16:35 -0000 Thomas, All, On Jan 10, 2011, at 15:31 MST, Thomas Narten wrote: > Brian E Carpenter writes: >> Given that we expect people to put flow labels into a >> hash function of some kind, a 20-bit pseudo random number >> seems like a better default than 1,2,3,... (depending on >> the hash function, obviously). >=20 > I want to challenge that up front. >=20 > For the example in your draft, MODULO(n), incrementing by one has > wonderful properties. Given that incrementing by 1 is about as simple > as it gets, that seems like a fine thing to do. Let's take a step back here for a moment and recognize a few things: 1) Routers, (specifically, 1st-hop routers that would be replacing a = zero flow-label with something non-zero), already implement a = pseudorandom hash algorithm today (sometimes in HW), in order that they = can determine an outgoing component-link for packets sent out/across = LAG's and ECMP paths. So, this draft is simply proposing to re-use an = existing pseudorandom function already built-in to routers and simply = encode that result into a flow-label. =20 2) For your proposal, above, of incrementing the flow-label by one to = be successful, the device encoding the flow-label would have to track = state of all flows in order to ensure that all packets belonging to the = same flow got the same flow-label. While this might be true, and easy, = for hosts or stateful firewalls, this would absolutely not work for = 1st-hop routers that are allowed to set a flow-label if they observe an = incoming packet whose flow-label wasn't set by the host, (IOW, = flow-label =3D=3D 0). So, I'm seeing a technical problem with your proposal (#2) and huge = advantages for re-use of pseudorandom algorithms already implemented = within devices in the network that are potentially responsible for = writing a flow-label with as little state as possible, (#1). -shane > There may be security downsides by having such a predicable generator > at the source, but that is a different issue than making it hash well. >=20 > Thomas > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From narten@us.ibm.com Tue Jan 11 05:39:03 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 1D0CA28C14B for ; Tue, 11 Jan 2011 05:39:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.077 X-Spam-Level: X-Spam-Status: No, score=-106.077 tagged_above=-999 required=5 tests=[AWL=0.522, 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 wU7x8YjMD877 for ; Tue, 11 Jan 2011 05:39:02 -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 4317E28C29A for ; Tue, 11 Jan 2011 05:39:02 -0800 (PST) Received: from d03relay02.boulder.ibm.com (d03relay02.boulder.ibm.com [9.17.195.227]) by e34.co.us.ibm.com (8.14.4/8.13.1) with ESMTP id p0BDUIEr003086 for ; Tue, 11 Jan 2011 06:30:18 -0700 Received: from d03av04.boulder.ibm.com (d03av04.boulder.ibm.com [9.17.195.170]) by d03relay02.boulder.ibm.com (8.13.8/8.13.8/NCO v9.1) with ESMTP id p0BDfChY250000 for ; Tue, 11 Jan 2011 06:41:12 -0700 Received: from d03av04.boulder.ibm.com (loopback [127.0.0.1]) by d03av04.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id p0BDfCB0007311 for ; Tue, 11 Jan 2011 06:41:12 -0700 Received: from cichlid.raleigh.ibm.com (sig-9-65-246-160.mts.ibm.com [9.65.246.160]) by d03av04.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id p0BDfBBe007234 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 11 Jan 2011 06:41:11 -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 p0BDfAiR005195 for ; Tue, 11 Jan 2011 08:41:10 -0500 Message-Id: <201101111341.p0BDfAiR005195@cichlid.raleigh.ibm.com> To: ipv6@ietf.org Subject: Flow Labels: what problem are we solving? Date: Tue, 11 Jan 2011 08:41:10 -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: Tue, 11 Jan 2011 13:39:03 -0000 Sorry to get back to basics, but I have not followed all the Flow Label discussions or read all the drafts. I have read draft-ietf-6man-flow-ecmp-00.txt draft-ietf-6man-flow-update-01.txt pretty carefully and I still don't quite understand what real problem we are trying to solve - and thus, whether the proposed changes actually help or are a no op. Is there a document that speaks to this? Question: I understand the value of ECMP type load balancing. But how much of a problem is it today (with IPv6) if the Flow Label is not used? If you hash on just the 5 tuple (excluding the flow label), you get (I assume) the equivalent of what you have in IPv4 today. Why is that not good enough? Also, splitting flows across different links would seem to have value primarily if you hvae a single source (or rather single src/dest pair) generating a *lot* of traffic/flows, i.e., so that if you split traffic from that source/dest pair, you see measurable load-splitting. Is this happening in practice today? Can operators please speak to this? And if it is a problem, is it primarily with tunneled traffic (where the tunnel aggregates many flows), or is it really between individual pairs of nodes that are sending a *lot* of traffic to each other? Are there examples of this? (I'm not necessarily opposed to this work going forward, but I'm not entirely convinced we are solving a real problem. Help me please.) Thomas From jmh@joelhalpern.com Tue Jan 11 06:11:11 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 CB0E128C27F for ; Tue, 11 Jan 2011 06:11:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.095 X-Spam-Level: X-Spam-Status: No, score=-103.095 tagged_above=-999 required=5 tests=[AWL=0.504, 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 XZOM4G-oZhB1 for ; Tue, 11 Jan 2011 06:11:10 -0800 (PST) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id 86B9028C157 for ; Tue, 11 Jan 2011 06:11:10 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 889B64300CD; Tue, 11 Jan 2011 06:13:27 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at hermes.tigertech.net Received: from [10.10.10.101] (pool-71-161-51-169.clppva.btas.verizon.net [71.161.51.169]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by hermes.tigertech.net (Postfix) with ESMTPSA id B0ABC430034; Tue, 11 Jan 2011 06:13:25 -0800 (PST) Message-ID: <4D2C6580.3020905@joelhalpern.com> Date: Tue, 11 Jan 2011 09:13:20 -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: Thomas Narten Subject: Re: Flow Labels: what problem are we solving? References: <201101111341.p0BDfAiR005195@cichlid.raleigh.ibm.com> In-Reply-To: <201101111341.p0BDfAiR005195@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: Tue, 11 Jan 2011 14:11:12 -0000 The goal is not to split single flows across multiple links. In fact, based on the experience that this causes excessive disordering, we generally require that load splitting techniques must avoid splitting flows across links. Which gets us to the problem. In using multiple links (ECMP / LAG) the routers generally want the finest granularity possible for that operation. That leads, as you say, to using a hash of the 5-tuple. However, the 5-tuple is not always available. The simplest case is tunnels. Unless the tunnel devices add new UDP headers (which is largely gratuitous and has other problems relative to the IPv6 specifications), the 5-tuple is not visible to the devices forwarding teh resulting packets. This also leads to IPSec needing a UDP header. It is also one of the contributors to why using new extension headers is such a bad idea. Thus, in working at the problem of how to get various kinds of traffic to be handled for ECMP / LAG, it seemed to many of us that capgturing the randomness of the port numbers in the flow label would be very helpful. (Yes, this assumes that the current hash approach to ECMP / LAG is reasonable. There is reportedly some question on that, but I take it as the best practice we have, and therefore worth continuing.) Yours, Joel On 1/11/2011 8:41 AM, Thomas Narten wrote: > Sorry to get back to basics, but I have not followed all the Flow > Label discussions or read all the drafts. I have read > > draft-ietf-6man-flow-ecmp-00.txt > draft-ietf-6man-flow-update-01.txt > > pretty carefully and I still don't quite understand what real problem > we are trying to solve - and thus, whether the proposed changes > actually help or are a no op. > > Is there a document that speaks to this? > > Question: > > I understand the value of ECMP type load balancing. But how much of a > problem is it today (with IPv6) if the Flow Label is not used? > > If you hash on just the 5 tuple (excluding the flow label), you get > (I assume) the equivalent of what you have in IPv4 today. Why is that > not good enough? > > Also, splitting flows across different links would seem to have value > primarily if you hvae a single source (or rather single src/dest pair) > generating a *lot* of traffic/flows, i.e., so that if you split > traffic from that source/dest pair, you see measurable load-splitting. > > Is this happening in practice today? Can operators please speak to > this? And if it is a problem, is it primarily with tunneled traffic > (where the tunnel aggregates many flows), or is it really between > individual pairs of nodes that are sending a *lot* of traffic to each > other? Are there examples of this? > > (I'm not necessarily opposed to this work going forward, but I'm not > entirely convinced we are solving a real problem. Help me please.) > > Thomas > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > From pthubert@cisco.com Tue Jan 11 06:30: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 008CD28C2AD for ; Tue, 11 Jan 2011 06:30:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.329 X-Spam-Level: X-Spam-Status: No, score=-10.329 tagged_above=-999 required=5 tests=[AWL=0.270, 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 IFuwUDAzxVgW for ; Tue, 11 Jan 2011 06:30:26 -0800 (PST) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id BF4D428C183 for ; Tue, 11 Jan 2011 06:30:26 -0800 (PST) Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAHL4K02rR7Hu/2dsb2JhbACkOHOjEph7hUwEjjQ Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-4.cisco.com with ESMTP; 11 Jan 2011 14:32:43 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id p0BEWcq3011294; Tue, 11 Jan 2011 14:32:43 GMT Received: from xmb-ams-107.cisco.com ([144.254.74.82]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 11 Jan 2011 15:32:38 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Flow Labels: what problem are we solving? Date: Tue, 11 Jan 2011 15:32:36 +0100 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D039155AE@XMB-AMS-107.cisco.com> In-Reply-To: <201101111341.p0BDfAiR005195@cichlid.raleigh.ibm.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Flow Labels: what problem are we solving? Thread-Index: AcuxlUPGJvpd7+gmSzWBEnXIK9tAFAABWB5Q References: <201101111341.p0BDfAiR005195@cichlid.raleigh.ibm.com> From: "Pascal Thubert (pthubert)" To: "Thomas Narten" , X-OriginalArrivalTime: 11 Jan 2011 14:32:38.0088 (UTC) FILETIME=[65307480:01CBB19C] 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, 11 Jan 2011 14:30:28 -0000 Hi Thomas: I've seen different requirements depending on where the utilization would be. a) Close to the source of the source or destination, the flow label could be used in an application-aware fashion, for instance to influence the routing of the packet in VRFs. We'll note that we do not have a .1Q equivalent in IPv6 and that though too small, the flow label is the only place before the IPv6 header to indicate a context in which the destination address is to be used. b) Farther in the network, it could be used for blind NECM. >From the discussions I've seen, people are mostly focused in b), with an additional assumptions that a flow is something that has a given source/destination pair. Sadly (for me) the case I'm most interested in is a), and the flows I look at can often be useful only if you can group multiple source / destinations in a single flow.=20 What I'd really like to see is that whatever is decided to help b) does not prevent a). I think it can be done easily if the border routers are allowed to overwrite a FL, which is not the case today. Cheers, Pascal http://www.xtranormal.com/watch/7011357/ > -----Original Message----- > From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of > Thomas Narten > Sent: Tuesday, January 11, 2011 2:41 PM > To: ipv6@ietf.org > Subject: Flow Labels: what problem are we solving? >=20 > Sorry to get back to basics, but I have not followed all the Flow Label > discussions or read all the drafts. I have read >=20 > draft-ietf-6man-flow-ecmp-00.txt > draft-ietf-6man-flow-update-01.txt >=20 > pretty carefully and I still don't quite understand what real problem we are > trying to solve - and thus, whether the proposed changes actually help or are > a no op. >=20 > Is there a document that speaks to this? >=20 > Question: >=20 > I understand the value of ECMP type load balancing. But how much of a > problem is it today (with IPv6) if the Flow Label is not used? >=20 > If you hash on just the 5 tuple (excluding the flow label), you get (I assume) > the equivalent of what you have in IPv4 today. Why is that not good enough? >=20 > Also, splitting flows across different links would seem to have value primarily > if you hvae a single source (or rather single src/dest pair) generating a *lot* > of traffic/flows, i.e., so that if you split traffic from that source/dest pair, you > see measurable load-splitting. >=20 > Is this happening in practice today? Can operators please speak to this? And > if it is a problem, is it primarily with tunneled traffic (where the tunnel > aggregates many flows), or is it really between individual pairs of nodes that > are sending a *lot* of traffic to each other? Are there examples of this? >=20 > (I'm not necessarily opposed to this work going forward, but I'm not entirely > convinced we are solving a real problem. Help me please.) >=20 > Thomas > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From narten@us.ibm.com Tue Jan 11 06:31: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 F27C328C2B8 for ; Tue, 11 Jan 2011 06:31:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.094 X-Spam-Level: X-Spam-Status: No, score=-106.094 tagged_above=-999 required=5 tests=[AWL=0.505, 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 EqhL7QryeoGI for ; Tue, 11 Jan 2011 06:31:45 -0800 (PST) Received: from e38.co.us.ibm.com (e38.co.us.ibm.com [32.97.110.159]) by core3.amsl.com (Postfix) with ESMTP id F2B8428C2B1 for ; Tue, 11 Jan 2011 06:31:44 -0800 (PST) Received: from d03relay02.boulder.ibm.com (d03relay02.boulder.ibm.com [9.17.195.227]) by e38.co.us.ibm.com (8.14.4/8.13.1) with ESMTP id p0BEJrlU009904 for ; Tue, 11 Jan 2011 07:19:53 -0700 Received: from d03av06.boulder.ibm.com (d03av06.boulder.ibm.com [9.17.195.245]) by d03relay02.boulder.ibm.com (8.13.8/8.13.8/NCO v9.1) with ESMTP id p0BEXtRj248250 for ; Tue, 11 Jan 2011 07:33:55 -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 p0BEcLAb017817 for ; Tue, 11 Jan 2011 07:38:21 -0700 Received: from cichlid.raleigh.ibm.com (sig-9-65-246-160.mts.ibm.com [9.65.246.160]) by d03av06.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id p0BEcKUU017754 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 11 Jan 2011 07:38:21 -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 p0BEXqWt005552; Tue, 11 Jan 2011 09:33:53 -0500 Message-Id: <201101111433.p0BEXqWt005552@cichlid.raleigh.ibm.com> To: "Joel M. Halpern" Subject: Re: Flow Labels: what problem are we solving? In-reply-to: <4D2C6580.3020905@joelhalpern.com> References: <201101111341.p0BDfAiR005195@cichlid.raleigh.ibm.com> <4D2C6580.3020905@joelhalpern.com> Comments: In-reply-to "Joel M. Halpern" message dated "Tue, 11 Jan 2011 09:13:20 -0500." Date: Tue, 11 Jan 2011 09:33:52 -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: Tue, 11 Jan 2011 14:31:46 -0000 > The goal is not to split single flows across multiple links. Sorry, I know that. Was I that unclear? :-( But isn't it then a goal (or rather a *requirement*) to split traffic between a given src/dst pair across multiple links? I.e., there is enough traffic between a given src/dest pair to justify splitting it into separate flows for load sharing purposes? That would seem to be what we are after. I'm trying to understand exactly which operational scenarios would actually see benefit from this, and get a sense of how common they are. Are we trying to solve a common problem, or is are we really solving an edge case? > Which gets us to the problem. In using multiple links (ECMP / LAG) the > routers generally want the finest granularity possible for that > operation. I understand that they may *want* this. But how bady do they *need* this? Is there real data here? Is the current status quo 80% good enough? 95%? or only 30%? > That leads, as you say, to using a hash of the 5-tuple. > However, the 5-tuple is not always available. The simplest case is > tunnels. Again, how common is this? Is this a 5% problem, or a 50% problem? Or is this an attempt to prepare for the future, since we don't have extension headers defined that are a problem today, and too little traffic is currently encrypted via IPsec... > Unless the tunnel devices add new UDP headers (which is largely > gratuitous and has other problems relative to the IPv6 > specifications), the 5-tuple is not visible to the devices > forwarding teh resulting packets. This also leads to IPSec needing > a UDP header. It is also one of the contributors to why using new > extension headers is such a bad idea. I can see how tunneling would be a problem. But not for all kinds of tunneling. What about GRE with its key field? Is this not widely enough used? Do we have data about what types of tunneling are most common? > Thus, in working at the problem of how to get various kinds of traffic > to be handled for ECMP / LAG, it seemed to many of us that capgturing > the randomness of the port numbers in the flow label would be very > helpful. In other words, the actual goal here then is to take the data (entropy) that is currently in the port fields, and put it into the flow label, and make this happen often enough in practice that routers can use it *instead of* looking at the port numbers? Is that *really* what the main goal is here? > (Yes, this assumes that the current hash approach to ECMP / LAG is > reasonable. There is reportedly some question on that, but I take it as > the best practice we have, and therefore worth continuing.) Right. The question of what makes a good hash is a separate topic. Thomas From yaroslav@arbor.net Tue Jan 11 06:59: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 2A84F28C193 for ; Tue, 11 Jan 2011 06:59:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.599 X-Spam-Level: X-Spam-Status: No, score=-1.599 tagged_above=-999 required=5 tests=[AWL=1.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 flrp6GghAeFB for ; Tue, 11 Jan 2011 06:59:35 -0800 (PST) Received: from gateout02.mbox.net (gateout02.mbox.net [165.212.64.22]) by core3.amsl.com (Postfix) with ESMTP id F0D3028C122 for ; Tue, 11 Jan 2011 06:59:34 -0800 (PST) Received: from gateout02.mbox.net (gwo2-lo [127.0.0.1]) by gateout02.mbox.net (Postfix) with ESMTP id 51CA34BF804; Tue, 11 Jan 2011 15:01:51 +0000 (GMT) X-USANET-Received: from gateout02.mbox.net [127.0.0.1] by gateout02.mbox.net via mtad (C8.MAIN.3.71F) with ESMTP id 403PakPBx2224Mo2; Tue, 11 Jan 2011 15:01:49 -0000 Received: from s1hub1.EXCHPROD.USA.NET [165.212.120.254] by gateout02.mbox.net via smtad (C8.MAIN.3.68M) with ESMTPS id XID419PakPBx2791Xo2; Tue, 11 Jan 2011 15:01:49 -0000 X-USANET-Source: 165.212.120.254 IN yaroslav@arbor.net s1hub1.EXCHPROD.USA.NET X-USANET-MsgId: XID419PakPBx2791Xo2 Received: from MBX14.EXCHPROD.USA.NET ([10.120.221.141]) by s1hub1.EXCHPROD.USA.NET ([10.120.220.31]) with mapi; Tue, 11 Jan 2011 15:01:45 +0000 From: "Rosomakho, Yaroslav" To: Thomas Narten Date: Tue, 11 Jan 2011 15:01:43 +0000 Subject: Re: Flow Labels: what problem are we solving? Thread-Topic: Flow Labels: what problem are we solving? Thread-Index: AcuxoHbgUXsoLXUYT9OiSCZJK+H/WQ== Message-ID: In-Reply-To: <201101111433.p0BEXqWt005552@cichlid.raleigh.ibm.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.0.101115 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 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, 11 Jan 2011 14:59:36 -0000 Hello, Thomas! On 11.01.11 17:33, "Thomas Narten" wrote: >That would seem to be what we are after. I'm trying to understand >exactly which operational scenarios would actually see benefit from >this, and get a sense of how common they are. Are we trying to solve a >common problem, or is are we really solving an edge case? IPv4 5-tuples load-balancing is not always working perfectly for everyone. I have encountered lot of occasions where it's far from perfect. Simplest example would be a VPN concentrator on a LAG. IPv6 is not going to be better then IPv4 when it comes to 5-tuples computation. In fact due to many tunnel transition techniques, it will be worse in general. Also, don't forget that extension header structure is more complex and in many cases routers (especially hardware-based) will not be able to look into layer 4 information. > >> Which gets us to the problem. In using multiple links (ECMP / LAG) the >> routers generally want the finest granularity possible for that >> operation. > >I understand that they may *want* this. But how bady do they *need* >this? Yes, they do. In a perfect world everybody is happily running 100GE everywhere, but it's not happening in real life. People want to keep their current transport for as long as they can. It's not an uncommon request to have more then ten STM-16s bundled and it's a common expectation to have effective throughput of aggregated link to be an exact sum of components. And if you put any "smart" MPLS TE UCMP on top of that, you can get in a real trouble with 5-tuples. > >Is there real data here? Is the current status quo 80% good enough? >95%? or only 30%? I'm not sure what are you proposing to measure... >> That leads, as you say, to using a hash of the 5-tuple. >> However, the 5-tuple is not always available. The simplest case is >> tunnels. > >Again, how common is this? Is this a 5% problem, or a 50% problem? Or >is this an attempt to prepare for the future, since we don't have >extension headers defined that are a problem today, and too little >traffic is currently encrypted via IPsec... Again, 5% of what? Packets traveling in the internet? These drafts try to deal with fundamental load-balancing issue. There is a chance that traffic patterns in 10 years from now will be completely different. Maybe everything will finally collapse inside TCP/80. Maybe everything will be inside ESP. Maybe end-to-end will be reborn. Nobody can tell. But obviously we don't want IPv6 to fail just because of that. Load-balancing is too important to leave it to layer 4. >> Unless the tunnel devices add new UDP headers (which is largely >> gratuitous and has other problems relative to the IPv6 >> specifications), the 5-tuple is not visible to the devices >> forwarding teh resulting packets. This also leads to IPSec needing >> a UDP header. It is also one of the contributors to why using new >> extension headers is such a bad idea. > >I can see how tunneling would be a problem. > >But not for all kinds of tunneling. What about GRE with its key field? >Is this not widely enough used? No, it is not. >Do we have data about what types of tunneling are most common? ESP is the most common non-UDP and non-TCP tunneling mechanism these days. Nobody can reliably predict how will it change in the future. >> Thus, in working at the problem of how to get various kinds of traffic >> to be handled for ECMP / LAG, it seemed to many of us that capgturing >> the randomness of the port numbers in the flow label would be very >> helpful. > >In other words, the actual goal here then is to take the data >(entropy) that is currently in the port fields, and put it into the >flow label, and make this happen often enough in practice that routers >can use it *instead of* looking at the port numbers? Is that *really* >what the main goal is here? Don't forget that load-balancing is often done by layer-2 devices. You can't expect cheap ASIC-based switches to dig through extension headers and find port numbers or GRE keys. But they definitely can look into statically-placed fixed-length flow label at very low processing cost. >> (Yes, this assumes that the current hash approach to ECMP / LAG is >> reasonable. There is reportedly some question on that, but I take it >>as=20 >> the best practice we have, and therefore worth continuing.) > >Right. The question of what makes a good hash is a separate topic. Load-balancing hashes have traditionally been implementation-specific. Maybe we should leave them this way. > >Thomas >-------------------------------------------------------------------- >IETF IPv6 working group mailing list >ipv6@ietf.org >Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >-------------------------------------------------------------------- Best Regards, Yaroslav From jmh@joelhalpern.com Tue Jan 11 07:07: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 ECA6728C193 for ; Tue, 11 Jan 2011 07:07:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.805 X-Spam-Level: X-Spam-Status: No, score=-102.805 tagged_above=-999 required=5 tests=[AWL=0.194, BAYES_00=-2.599, J_CHICKENPOX_61=0.6, 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 0T-5tJZmddi4 for ; Tue, 11 Jan 2011 07:07:59 -0800 (PST) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id 04B0928C152 for ; Tue, 11 Jan 2011 07:07:59 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 2864C4300EF; Tue, 11 Jan 2011 07:10:16 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at hermes.tigertech.net Received: from [10.10.10.101] (pool-71-161-51-169.clppva.btas.verizon.net [71.161.51.169]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by hermes.tigertech.net (Postfix) with ESMTPSA id 5269F4300EA; Tue, 11 Jan 2011 07:10:15 -0800 (PST) Message-ID: <4D2C72D2.4070203@joelhalpern.com> Date: Tue, 11 Jan 2011 10:10: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: Thomas Narten Subject: Re: Flow Labels: what problem are we solving? References: <201101111341.p0BDfAiR005195@cichlid.raleigh.ibm.com> <4D2C6580.3020905@joelhalpern.com> <201101111433.p0BEXqWt005552@cichlid.raleigh.ibm.com> In-Reply-To: <201101111433.p0BEXqWt005552@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: Tue, 11 Jan 2011 15:08:00 -0000 Yes, the usage of ECMP / LAG is very common. Yes, there is plenty of data that shows that using just the src and dst IP address in the hash is NOT good enough. (This does start to get into the quesiton of whether blindly using the ports is good enough,l but that is the current practice.) It is the case that much of the current hardware is built to work around the common packet cases so as to permit ECMP and LAG. (All? How much? I do not have the data.) However, we are seeing a LOT more uses of tunneling. IPSec VPNs are one use, but they are pretty rare. And they generally have to do enough processing that the UDP can be done in those cases. So it is. It should be noted that since tunnels aggregate a lot of sources / destinations into the tunnel end-point addresses. So if we lose the inner addresses, and lose the port numbers, we lose a lot of entropy. In this case, if we could use the flow label, the tunnel device could creat one that restores much of that entropy. (Not all, by any means.) But no, GRE does not work. The problem is that the hardware / firmware is built to look for wpeific things. The more different cases you ahve to handle in different ways, the harder it gets. So generally, as I understand it, the ECMP / LAG logic in most devices which do this in formware / hardware can not use the entropy in the GRE labels. Also, even if we could use them, GRE labels are not per-flow. they are typically per underlying user, which at least restores the granularity of the senders, but not the ports. Admittedly, part of my original motivation was to find a way to allow tunnels to be handled without UDP headers so as to not fight about the UDP header checksum. However, I can not get there in a useful time, so no, this proposal can not fix any of the immediate issues. Short of giving up and saying we can never change any of the fields in the IPv6 header and never fix any of the problems, I am trying to make this useful for the problems we do have. Yours, Joel On 1/11/2011 9:33 AM, Thomas Narten wrote: >> The goal is not to split single flows across multiple links. > > Sorry, I know that. Was I that unclear? :-( > > But isn't it then a goal (or rather a *requirement*) to split traffic > between a given src/dst pair across multiple links? I.e., there is > enough traffic between a given src/dest pair to justify splitting it > into separate flows for load sharing purposes? > > That would seem to be what we are after. I'm trying to understand > exactly which operational scenarios would actually see benefit from > this, and get a sense of how common they are. Are we trying to solve a > common problem, or is are we really solving an edge case? > >> Which gets us to the problem. In using multiple links (ECMP / LAG) the >> routers generally want the finest granularity possible for that >> operation. > > I understand that they may *want* this. But how bady do they *need* > this? > > Is there real data here? Is the current status quo 80% good enough? > 95%? or only 30%? > >> That leads, as you say, to using a hash of the 5-tuple. >> However, the 5-tuple is not always available. The simplest case is >> tunnels. > > Again, how common is this? Is this a 5% problem, or a 50% problem? Or > is this an attempt to prepare for the future, since we don't have > extension headers defined that are a problem today, and too little > traffic is currently encrypted via IPsec... > >> Unless the tunnel devices add new UDP headers (which is largely >> gratuitous and has other problems relative to the IPv6 >> specifications), the 5-tuple is not visible to the devices >> forwarding teh resulting packets. This also leads to IPSec needing >> a UDP header. It is also one of the contributors to why using new >> extension headers is such a bad idea. > > I can see how tunneling would be a problem. > > But not for all kinds of tunneling. What about GRE with its key field? > Is this not widely enough used? > > Do we have data about what types of tunneling are most common? > >> Thus, in working at the problem of how to get various kinds of traffic >> to be handled for ECMP / LAG, it seemed to many of us that capgturing >> the randomness of the port numbers in the flow label would be very >> helpful. > > In other words, the actual goal here then is to take the data > (entropy) that is currently in the port fields, and put it into the > flow label, and make this happen often enough in practice that routers > can use it *instead of* looking at the port numbers? Is that *really* > what the main goal is here? > >> (Yes, this assumes that the current hash approach to ECMP / LAG is >> reasonable. There is reportedly some question on that, but I take it as >> the best practice we have, and therefore worth continuing.) > > Right. The question of what makes a good hash is a separate topic. > > Thomas > From lucyyong@huawei.com Tue Jan 11 07:38: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 097F33A6A39 for ; Tue, 11 Jan 2011 07:38:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.501 X-Spam-Level: X-Spam-Status: No, score=-3.501 tagged_above=-999 required=5 tests=[AWL=0.994, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.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 ecCmE0JMDfk2 for ; Tue, 11 Jan 2011 07:38:57 -0800 (PST) Received: from szxga03-in.huawei.com (unknown [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id 12EB73A67A8 for ; Tue, 11 Jan 2011 07:38:57 -0800 (PST) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LEV004HE7KF5V@szxga03-in.huawei.com> for ipv6@ietf.org; Tue, 11 Jan 2011 23:41:03 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LEV00LYJ7KFTA@szxga03-in.huawei.com> for ipv6@ietf.org; Tue, 11 Jan 2011 23:41:03 +0800 (CST) Received: from y736742 ([10.124.12.68]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LEV00HGJ7KD8R@szxml04-in.huawei.com> for ipv6@ietf.org; Tue, 11 Jan 2011 23:41:03 +0800 (CST) Date: Tue, 11 Jan 2011 09:41:04 -0600 From: Yong Lucy Subject: RE: [Fwd: I-D Action:draft-ietf-6man-flow-update-00.txt] In-reply-to: <4D2BBA15.309@gmail.com> To: 'Brian E Carpenter' Message-id: <01b301cbb1a5$f65dbe50$c60ca8c0@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3664 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Thread-index: AcuxM5YbYZlwcIgeQn6Tn2/mZ50W1wAcIQQQ References: <4CF82E6F.9040309@gmail.com> <4D08165A.3060306@gmail.com> <51661CE4-EC60-46B9-928C-D5763CFDF318@cisco.com> <4D082147.9010209@gmail.com> <4D2A1B84.1020003@gmail.com> <4D2A64A1.4030400@gmail.com> <982F8CA8-789A-42D6-9C86-E194BA868023@cisco.com> <4D2B8557.9090107@gmail.com> <015501cbb11f$cce25a80$c60ca8c0@china.huawei.com> <4D2BBA15.309@gmail.com> Cc: '6man' , 'Fred Baker' 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, 11 Jan 2011 15:38:58 -0000 > > > > > > [LY] Statistical approach works well under the consumption that there > are > > thousands of flows and they have the similar rates. Today's Internet may > > have the flows that only have few packets and the flows that have > thousands > > packets per second and last long. Hash does not work well under this > > condition. > > In fact no solution works well for short flows and the problem isn't > important > for long flows with few packets. So I think it's OK to discuss a solution > that works for long flows with many packets, since that covers most > of the load. [LY] Hash works well for short flows. That was developed when Internet is primarily used for data transport. As more and more video data on Internet, traffic become mixed with long flows with many packets and short flow with few packets. Hash no longer works well in this traffic pattern. > > > > > [LY] the server load balance and the network path load balance have > > different criteria. > > Very true. It isn't clear to me that balancing the network load > without knowledge of the server load is a good idea. [LY] Agree. However, today network performs load balance without considering server load balance; server load performs load balance without considering network load balance. Two operations are independent. Lucy > > Brian From shane@castlepoint.net Tue Jan 11 09:08:34 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 CE2F23A69B9 for ; Tue, 11 Jan 2011 09:08:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.576 X-Spam-Level: X-Spam-Status: No, score=-2.576 tagged_above=-999 required=5 tests=[AWL=0.023, 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 KWh3Qy1obX5Q for ; Tue, 11 Jan 2011 09:08:34 -0800 (PST) Received: from dog.tcb.net (dog.tcb.net [64.78.150.133]) by core3.amsl.com (Postfix) with ESMTP id DAFEC3A677E for ; Tue, 11 Jan 2011 09:08:33 -0800 (PST) Received: by dog.tcb.net (Postfix, from userid 0) id E21C22684EA; Tue, 11 Jan 2011 10:10:50 -0700 (MST) Received: from host2.tcb.net (64.78.235.218 [64.78.235.218]) (authenticated-user smtp) (TLSv1/SSLv3 AES128-SHA 128/128) by dog.tcb.net with SMTP; Tue, 11 Jan 2011 10:10:50 -0700 (MST) (envelope-from shane@castlepoint.net) X-Avenger: version=0.7.8; receiver=dog.tcb.net; client-ip=64.78.235.218; client-port=59106; data-bytes=0 Subject: Re: [Fwd: I-D Action:draft-ietf-6man-flow-update-00.txt] Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Shane Amante In-Reply-To: <01b301cbb1a5$f65dbe50$c60ca8c0@china.huawei.com> Date: Tue, 11 Jan 2011 10:10:49 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4CF82E6F.9040309@gmail.com> <4D08165A.3060306@gmail.com> <51661CE4-EC60-46B9-928C-D5763CFDF318@cisco.com> <4D082147.9010209@gmail.com> <4D2A1B84.1020003@gmail.com> <4D2A64A1.4030400@gmail.com> <982F8CA8-789A-42D6-9C86-E194BA868023@cisco.com> <4D2B8557.9090107@gmail.com> <015501cbb11f$cce25a80$c60ca8c0@china.huawei.com> <4D2BBA15.309@gmail.com> <01b301cbb1a5$f65dbe50$c60ca8c0@china.huawei.com> To: Yong Lucy X-Mailer: Apple Mail (2.1082) Cc: '6man' , 'Brian E Carpenter' , 'Fred Baker' 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, 11 Jan 2011 17:08:34 -0000 Lucy, Brian, On Jan 11, 2011, at 08:41 MST, Yong Lucy wrote: >> In fact no solution works well for short flows and the problem isn't >> important >> for long flows with few packets. So I think it's OK to discuss a = solution >> that works for long flows with many packets, since that covers most >> of the load. >=20 > [LY] Hash works well for short flows. That was developed when Internet = is > primarily used for data transport. As more and more video data on = Internet, > traffic become mixed with long flows with many packets and short flow = with > few packets. Hash no longer works well in this traffic pattern. Let's be careful here and not cause a panic. :-) In reality, hash works quite well for the bulk of Video traffic = currently being distributed over the public Internet, specifically in = the form of streaming TV or movies such as Youtube, Hulu, Netflix, = iTunes, etc. where individual streams/flows tend to be on the order of a = few Mbps -- obviously because individual streams need to fit on "small" = access circuits (relative to the size of Backbone links) to subscriber's = homes that are primarily using either DSL or Cable (DOCSIS) -- at least = from the PoV of here in North America. It's probably better to say that a hash algorithm works well where = individual, long-lived flows (regardless of traffic type) are a = small-ish fraction of the physical BW of any individual component-link = in a LAG or ECMP group. It's when those long-lived flows are a = substantial portion of component-link's physical BW that a hash = algorithm is ineffective and you either need higher capacity = component-links or more "creative" techniques. >>> [LY] the server load balance and the network path load balance have >>> different criteria. >>=20 >> Very true. It isn't clear to me that balancing the network load >> without knowledge of the server load is a good idea. Brian: It is from the perspective that it's stateless, which is a very = desirable property when you're talking about Core/Edge devices with = millions or billions of flows ... -shane > [LY] Agree. However, today network performs load balance without = considering > server load balance; server load performs load balance without = considering > network load balance. Two operations are independent. >=20 > Lucy >>=20 >> Brian >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From fred@cisco.com Tue Jan 11 09:26: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 BB07F28B797 for ; Tue, 11 Jan 2011 09:26:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.461 X-Spam-Level: X-Spam-Status: No, score=-110.461 tagged_above=-999 required=5 tests=[AWL=0.138, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 U4q8vNOP8Clz for ; Tue, 11 Jan 2011 09:26:57 -0800 (PST) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id CF5E13A677E for ; Tue, 11 Jan 2011 09:26:56 -0800 (PST) Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAIEhLE2rR7H+/2dsb2JhbACkOHOjX5hwhUwEhGiGJoMg Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-5.cisco.com with ESMTP; 11 Jan 2011 17:29:13 +0000 Received: from stealth-10-32-244-221.cisco.com (stealth-10-32-244-221.cisco.com [10.32.244.221]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id p0BHT9Hp026415; Tue, 11 Jan 2011 17:29:13 GMT Received: from [127.0.0.1] by stealth-10-32-244-221.cisco.com (PGP Universal service); Tue, 11 Jan 2011 09:29:13 -0800 X-PGP-Universal: processed; by stealth-10-32-244-221.cisco.com on Tue, 11 Jan 2011 09:29:13 -0800 Subject: Re: [Fwd: I-D Action:draft-ietf-6man-flow-update-00.txt] Mime-Version: 1.0 (Apple Message framework v1082) From: Fred Baker In-Reply-To: Date: Tue, 11 Jan 2011 09:29:00 -0800 Message-Id: <88554593-E194-40CB-AC10-29187DCBCDA0@cisco.com> References: <4CF82E6F.9040309@gmail.com> <4D08165A.3060306@gmail.com> <51661CE4-EC60-46B9-928C-D5763CFDF318@cisco.com> <4D082147.9010209@gmail.com> <4D2A1B84.1020003@gmail.com> <4D2A64A1.4030400@gmail.com> <982F8CA8-789A-42D6-9C86-E194BA868023@cisco.com> <4D2B8557.9090107@gmail.com> <015501cbb11f$cce25a80$c60ca8c0@china.huawei.com> <4D2BBA15.309@gmail.com> <01b301cbb1a5$f65dbe50$c60ca8c0@china.huawei.com> To: Shane Amante X-Mailer: Apple Mail (2.1082) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: '6man' , '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: Tue, 11 Jan 2011 17:26:59 -0000 On Jan 11, 2011, at 9:10 AM, Shane Amante wrote: > It's probably better to say that a hash algorithm works well where = individual, long-lived flows (regardless of traffic type) are a = small-ish fraction of the physical BW of any individual component-link = in a LAG or ECMP group. It's when those long-lived flows are a = substantial portion of component-link's physical BW that a hash = algorithm is ineffective and you either need higher capacity = component-links or more "creative" techniques. Statistics we're seeing suggest that long-lived video flows = (video-on-demand, streaming media, netflix/youtube/etc) are becoming a = fairly large subset of internet traffic. You may have seen Wired's = article on it (http://www.wired.com/magazine/2010/08/ff_webrip/all/1) = and the far-better-thought-through rebuttal = (http://boingboing.net/2010/08/17/is-the-web-really-de.html).=20= From shane@castlepoint.net Tue Jan 11 10:12: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 0D4D63A6A64 for ; Tue, 11 Jan 2011 10:12:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.578 X-Spam-Level: X-Spam-Status: No, score=-2.578 tagged_above=-999 required=5 tests=[AWL=0.021, 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 ekQ8tDWEL97p for ; Tue, 11 Jan 2011 10:12:07 -0800 (PST) Received: from dog.tcb.net (dog.tcb.net [64.78.150.133]) by core3.amsl.com (Postfix) with ESMTP id C615D3A6A62 for ; Tue, 11 Jan 2011 10:12:07 -0800 (PST) Received: by dog.tcb.net (Postfix, from userid 0) id BA5EC2684EA; Tue, 11 Jan 2011 11:14:24 -0700 (MST) Received: from host2.tcb.net (64.78.235.218 [64.78.235.218]) (authenticated-user smtp) (TLSv1/SSLv3 AES128-SHA 128/128) by dog.tcb.net with SMTP; Tue, 11 Jan 2011 11:14:24 -0700 (MST) (envelope-from shane@castlepoint.net) X-Avenger: version=0.7.8; receiver=dog.tcb.net; client-ip=64.78.235.218; client-port=60081; data-bytes=0 Subject: Re: [Fwd: I-D Action:draft-ietf-6man-flow-update-00.txt] Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Shane Amante In-Reply-To: <88554593-E194-40CB-AC10-29187DCBCDA0@cisco.com> Date: Tue, 11 Jan 2011 11:14:23 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <74854626-A84C-4B32-ACD5-004EE460ED86@castlepoint.net> References: <4CF82E6F.9040309@gmail.com> <4D08165A.3060306@gmail.com> <51661CE4-EC60-46B9-928C-D5763CFDF318@cisco.com> <4D082147.9010209@gmail.com> <4D2A1B84.1020003@gmail.com> <4D2A64A1.4030400@gmail.com> <982F8CA8-789A-42D6-9C86-E194BA868023@cisco.com> <4D2B8557.9090107@gmail.com> <015501cbb11f$cce25a80$c60ca8c0@china.huawei.com> <4D2BBA15.309@gmail.com> <01b301cbb1a5$f65dbe50$c60ca8c0@china.huawei.com> <88554593-E194-40CB-AC10-29187DCBCDA0@cisco.com> To: Fred Baker X-Mailer: Apple Mail (2.1082) Cc: '6man' , '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: Tue, 11 Jan 2011 18:12:09 -0000 Fred, On Jan 11, 2011, at 10:29 MST, Fred Baker wrote: > On Jan 11, 2011, at 9:10 AM, Shane Amante wrote: >=20 >> It's probably better to say that a hash algorithm works well where = individual, long-lived flows (regardless of traffic type) are a = small-ish fraction of the physical BW of any individual component-link = in a LAG or ECMP group. It's when those long-lived flows are a = substantial portion of component-link's physical BW that a hash = algorithm is ineffective and you either need higher capacity = component-links or more "creative" techniques. >=20 > Statistics we're seeing suggest that long-lived video flows = (video-on-demand, streaming media, netflix/youtube/etc) are becoming a = fairly large subset of internet traffic. You may have seen Wired's = article on it (http://www.wired.com/magazine/2010/08/ff_webrip/all/1) = and the far-better-thought-through rebuttal = (http://boingboing.net/2010/08/17/is-the-web-really-de.html). I have. However, people need to put the [very poor] Wired article in = context. Specifically, there's a significant difference between the = aggregate amount of all Video traffic **versus** the size (bandwidth) of = individual Video streams that will appear in the core of the network. = IOW, as an operator, I don't have concerns transporting Terabits (and, = more) of _aggregate_ Video traffic, so long as the _individual_ Video = streams in that aggregate are "well distributed" amongst themselves and = other traffic that would ultimately be output on a common set of = component-links comprising a single LAG or ECMP group. By that I mean:=20= - each has a relatively unique 5-tuple (since that's the only thing I = can use, today, from the IP header, today, as an input-key for a = load-balancing hash algorithm), to ensure there is the low(est) = probability that all Video flows will get put onto the same = component-link in a LAG or ECMP path; and, - the bandwidth of an individual Video stream is a small-ish fraction of = the BW of a component-link comprising a LAG or ECMP path. IOW, why = should I care about a 5, 10 or 20 Mbps constant rate Internet [Video] = flow on a 10 Gbps component-link, (you're talking about .2% = [2-thousands] of the overall physical capacity of a component-link)? What causes pain and/or worry to us operators is when someone launches a = large *individual* "macro-flow"[1] at the network that start to = represent a decent fraction of the overall capacity of a physical = component-link underlying a LAG and/or ECMP path, (e.g.: and the = following are only an *example*: 200 Mbps, 500 Mbps, 1 Gbps, etc. on a = 10 Gbps link). Unfortunately, due to the fact that load-hashing = algorithms are stateless (and, thus, non-adaptive), that means that = "well-behaved" microflows (think: casual Web surfing, e-mail, etc.) are = still co-mingled with those large, fat-flows across all component-links = in a common LAG/ECMP path *without* taking into account BW utilization = of individual component-links. So, there is a much higher probability = (or, oftentimes, certainty) of congestion and packet loss causing pain = to all users on the one (or, more) component-links with fat, macro-flows = on them that I can't capacity plan for and I can't easily react to. -shane [1] Examples are: IPvX in IPvX tunneling, GRE, IPSec, "WAN acceleration" = type products that are used for extremely fast large file xfers, etc.= From shane@castlepoint.net Tue Jan 11 11:13: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 6CA7D3A6A97 for ; Tue, 11 Jan 2011 11:13:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.421 X-Spam-Level: X-Spam-Status: No, score=-2.421 tagged_above=-999 required=5 tests=[AWL=-0.137, BAYES_00=-2.599, SARE_MILLIONSOF=0.315] 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 5-EjIv40fCnU for ; Tue, 11 Jan 2011 11:13:08 -0800 (PST) Received: from dog.tcb.net (dog.tcb.net [64.78.150.133]) by core3.amsl.com (Postfix) with ESMTP id 097DC3A6A98 for ; Tue, 11 Jan 2011 11:13:03 -0800 (PST) Received: by dog.tcb.net (Postfix, from userid 0) id 620BD2684EA; Tue, 11 Jan 2011 12:15:19 -0700 (MST) Received: from host2.tcb.net (64.78.235.218 [64.78.235.218]) (authenticated-user smtp) (TLSv1/SSLv3 AES128-SHA 128/128) by dog.tcb.net with SMTP; Tue, 11 Jan 2011 12:15:19 -0700 (MST) (envelope-from shane@castlepoint.net) X-Avenger: version=0.7.8; receiver=dog.tcb.net; client-ip=64.78.235.218; client-port=60941; data-bytes=0 Subject: Re: Flow Labels: what problem are we solving? Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Shane Amante In-Reply-To: <201101111341.p0BDfAiR005195@cichlid.raleigh.ibm.com> Date: Tue, 11 Jan 2011 12:15:18 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <2CCF3800-0344-44FC-9BB9-D59ED765E0A6@castlepoint.net> References: <201101111341.p0BDfAiR005195@cichlid.raleigh.ibm.com> To: Thomas Narten 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: Tue, 11 Jan 2011 19:13:09 -0000 Hi Thomas, Token operator here ... :-) See below. On Jan 11, 2011, at 06:41 MST, Thomas Narten wrote: > Sorry to get back to basics, but I have not followed all the Flow > Label discussions or read all the drafts. I have read >=20 > draft-ietf-6man-flow-ecmp-00.txt > draft-ietf-6man-flow-update-01.txt >=20 > pretty carefully and I still don't quite understand what real problem > we are trying to solve - and thus, whether the proposed changes > actually help or are a no op. >=20 > Is there a document that speaks to this? >=20 > Question: >=20 > I understand the value of ECMP type load balancing. But how much of a > problem is it today (with IPv6) if the Flow Label is not used? Today, it's a significant one, especially so for tunneled traffic, e.g.: = IPvX in IPv6, GRE, IPSec, LISP, etc. and WAN acceleration products for = fast file xfer's. In the future, it could significantly inhibit (even, = prohibit) the IETF from developing new protocols that either use new = IPv6 Extension Headers or Destination Options, since Core/Edge = router/switch HW (primarily built around ASIC's) cannot (easily) be = adapted to recognize the granularity of 'individual flows' in those new = protocols -- worst-case, existing HW cannot be adapted and would = requiring swapping it out, which is essentially a non-starter. Even = when existing core HW can be adapted, through SW changes, to recognize = the granularity of new protocols it could be upwards of a decade before = the cycle of coaxing/prodding/cajoling vendors to develop the capability = in SW through operators testing and eventually deploying the capability = in their networks. I would also raise the "architectural purity" argument of: do you really = want millions of routers (and, L2 switches) that are really just = supposed to forward based solely on IP source address, IP destination = address (and, IP Traffic Class) *attempting* to go deeper into the = packet (headers) to discern useful, granular information that could be = used as input-keys for load-balancing across LAG and ECMP paths? = Unfortunately, every device manufacturer is going to make their own = decisions on what they can (or, will) be able to look at in the IP and = Extension Headers as input-keys for a load-balancing hash, but the = end-result will be (and, is currently) a mess in terms of deployment and = operation. (As an example, some vendors can read entire IPv6 addresses = from a IPv6 header in new(er) HW, others can only read parts of the v6 = address, etc.) Finally, there is this jewel in RFC 2460: ---cut here--- With one exception, extension headers are not examined or processed by any node along a packet's delivery path, until the packet reaches the node (or each of the set of nodes, in the case of multicast) identified in the Destination Address field of the IPv6 header. [...] The exception referred to in the preceding paragraph is the Hop-by- Hop Options header, which carries information that must be examined and processed by every node along a packet's delivery path, including the source and destination nodes. ---cut here--- While I wasn't around during during the creation of RFC 2460 (so, please = correct or inform me if I'm wrong), but it seems to at least imply (if = not, mandate?) that intermediate nodes (such as routers and L2 switches) = shouldn't be trying to interpret the characteristics of the upper-layer = protocols being transported. This would make sense when viewed in light = of the end-to-end principle, but perhaps I'm taking too strict an = interpretation. > If you hash on just the 5 tuple (excluding the flow label), you get > (I assume) the equivalent of what you have in IPv4 today. Why is that > not good enough? For one, HW can't glean a 5-tuple when it encounters tunneled packets. = Second, it inhibits/prohibits the IETF from developing new upper-layer = protocols (if/when the need should arise) and getting them deployed in a = reasonable timeframe. Lastly, I would like to get to a point where I = can tell my router/switch vendors to build more simple (and, thus, more = cost-effective) HW, because they don't have to keep piling complexity = into their ASIC's to recognize the various legacy and new permutations = of transport-layer protocols for input-keys for LAG and ECMP = load-balancing hashes. Instead, I would ideally be able to tell them: = just use {IP src, IP dst and IPv6 flow-label} as input-keys -- oh, and = look at that ... they're all at fixed offsets in the IPv6 header and at = the very beginning of the packet so the time (and, amount of memory) for = you to copy that region of the packet to extremely expensive SRAM = (packet buffer memory) has just been reduced, (reducing cycle times to = process the packet, etc.). Now, I will grant you this latter point is a = bit of wishful thinking for now, given that we'll need to be successful = in getting these drafts agreed upon and published. Then, hosts (and, = 1st-hop) routers will need to start writing useful flow-labels (and, = hopefully, firewalls or their administrators do not screw around and = write zero back over the flow-label). However, I'm of the opinion that = if you don't start to make a small change now, you will never see an = improvement down the road. > Also, splitting flows across different links would seem to have value > primarily if you hvae a single source (or rather single src/dest pair) > generating a *lot* of traffic/flows, i.e., so that if you split > traffic from that source/dest pair, you see measurable load-splitting. >=20 > Is this happening in practice today? Can operators please speak to > this? And if it is a problem, is it primarily with tunneled traffic > (where the tunnel aggregates many flows), or is it really between > individual pairs of nodes that are sending a *lot* of traffic to each > other? Are there examples of this? >=20 > (I'm not necessarily opposed to this work going forward, but I'm not > entirely convinced we are solving a real problem. Help me please.) I think I've answered these questions above; however, if you still = aren't satisfied with those answers please let me know. =20 Lastly, I would add that LAG and ECMP have been around for several = [dozen] years and will remain with us indefinitely. IOW, even if 100 = GbE were cost-effective and deployed today, I know of several operators = who will still be using LAG or ECMP over Nx 100 GbE trunks in order to = continue to carry the traffic demand on their networks. So, in summary, = this is not a problem that is going away with 100 GbE, or beyond. -shane= From lucyyong@huawei.com Tue Jan 11 12:15: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 58D7628C0FB for ; Tue, 11 Jan 2011 12:15:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.6 X-Spam-Level: X-Spam-Status: No, score=-3.6 tagged_above=-999 required=5 tests=[AWL=0.895, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.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 ximGoJ114Apc for ; Tue, 11 Jan 2011 12:15:28 -0800 (PST) Received: from szxga04-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id 726A128C0EF for ; Tue, 11 Jan 2011 12:15:28 -0800 (PST) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LEV00FLIKDBCO@szxga04-in.huawei.com> for ipv6@ietf.org; Wed, 12 Jan 2011 04:17:35 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LEV008Z0KDBIW@szxga04-in.huawei.com> for ipv6@ietf.org; Wed, 12 Jan 2011 04:17:35 +0800 (CST) Received: from y736742 ([10.124.12.68]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LEV004QTKD8MG@szxml06-in.huawei.com> for ipv6@ietf.org; Wed, 12 Jan 2011 04:17:35 +0800 (CST) Date: Tue, 11 Jan 2011 14:17:37 -0600 From: Yong Lucy Subject: RE: [Fwd: I-D Action:draft-ietf-6man-flow-update-00.txt] In-reply-to: <74854626-A84C-4B32-ACD5-004EE460ED86@castlepoint.net> To: 'Shane Amante' , 'Fred Baker' Message-id: <022801cbb1cc$986a7730$c60ca8c0@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3664 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Thread-index: Acuxu6eojIQJMCHeTQy2QM2vYOSaMQADlRgw References: <4CF82E6F.9040309@gmail.com> <4D08165A.3060306@gmail.com> <51661CE4-EC60-46B9-928C-D5763CFDF318@cisco.com> <4D082147.9010209@gmail.com> <4D2A1B84.1020003@gmail.com> <4D2A64A1.4030400@gmail.com> <982F8CA8-789A-42D6-9C86-E194BA868023@cisco.com> <4D2B8557.9090107@gmail.com> <015501cbb11f$cce25a80$c60ca8c0@china.huawei.com> <4D2BBA15.309@gmail.com> <01b301cbb1a5$f65dbe50$c60ca8c0@china.huawei.com> <88554593-E194-40CB-AC10-29187DCBCDA0@cisco.com> <74854626-A84C-4B32-ACD5-004EE460ED86@castlepoint.net> Cc: '6man' , '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: Tue, 11 Jan 2011 20:15:29 -0000 Shane and all, > > What causes pain and/or worry to us operators is when someone launches a > large *individual* "macro-flow"[1] at the network that start to represent > a decent fraction of the overall capacity of a physical component-link > underlying a LAG and/or ECMP path, (e.g.: and the following are only an > *example*: 200 Mbps, 500 Mbps, 1 Gbps, etc. on a 10 Gbps link). > Unfortunately, due to the fact that load-hashing algorithms are stateless > (and, thus, non-adaptive), that means that "well-behaved" microflows > (think: casual Web surfing, e-mail, etc.) are still co-mingled with those > large, fat-flows across all component-links in a common LAG/ECMP path > *without* taking into account BW utilization of individual component-links. > So, there is a much higher probability (or, oftentimes, certainty) of > congestion and packet loss causing pain to all users on the one (or, more) > component-links with fat, macro-flows on them that I can't capacity plan > for and I can't easily react to. [LY] Great analysis. As a result, it seems the necessary to differentiate those large flows (decent fraction of the component link capacity) from other "small" flows because there are few such large flows in the network and hash can't do well on a small flow space nor on a large flow space that mixed with huge number of small flows and a few large flows. Lucy > > -shane > > [1] Examples are: IPvX in IPvX tunneling, GRE, IPSec, "WAN acceleration" > type products that are used for extremely fast large file xfers, etc.= From brian.e.carpenter@gmail.com Tue Jan 11 13:02: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 A2A293A6A9D for ; Tue, 11 Jan 2011 13:02:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.43 X-Spam-Level: X-Spam-Status: No, score=-103.43 tagged_above=-999 required=5 tests=[AWL=0.169, 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 tdJ3xJO6FdjA for ; Tue, 11 Jan 2011 13:02:27 -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 A0EAF3A67AD for ; Tue, 11 Jan 2011 13:02:27 -0800 (PST) Received: by ewy8 with SMTP id 8so9770800ewy.31 for ; Tue, 11 Jan 2011 13:04:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :organization:user-agent:mime-version:to:cc:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=U1f02JzsCUwIvoJrIG//wfS7Xr4Q4qtfYGejRTO5wEU=; b=HtGSaUYEPaNibT3alah2q5rYrW+wF4vIB0Ia50Ez9tumegCkN+FEGa+LD9/pyf5PAK 3qQGzDxmxXjKaYK9/i8fBnOXmrRhX15rmBRIT6jbin/nry/nZliSZ/KIVY8ARglf7kta C/tuFZSgrfQHjJj4RaJLo+8p2Eosnkt6UN8iM= 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=U7RsUL5FgY18QeoCQXkyWck4OQu1vlTmCVngpoLBJd0FB5ik5OOTqTfAFTsf6IhLei FPfPXFe9gMV/iFhPzPhjSnnzGKrRk9LwWkDg8+LR08MIKzW8MOh4iHsbUjgLbwHHxe0R fDNDByk1+VNTy6hkkQbE4tjNaXroKKqTAltqk= Received: by 10.223.78.138 with SMTP id l10mr134515fak.17.1294779884416; Tue, 11 Jan 2011 13:04:44 -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 21sm7584165fav.41.2011.01.11.13.04.41 (version=SSLv3 cipher=RC4-MD5); Tue, 11 Jan 2011 13:04:43 -0800 (PST) Message-ID: <4D2CC5E6.2010002@gmail.com> Date: Wed, 12 Jan 2011 10:04:38 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Yong Lucy Subject: Re: [Fwd: I-D Action:draft-ietf-6man-flow-update-00.txt] References: <4CF82E6F.9040309@gmail.com> <4D08165A.3060306@gmail.com> <51661CE4-EC60-46B9-928C-D5763CFDF318@cisco.com> <4D082147.9010209@gmail.com> <4D2A1B84.1020003@gmail.com> <4D2A64A1.4030400@gmail.com> <982F8CA8-789A-42D6-9C86-E194BA868023@cisco.com> <4D2B8557.9090107@gmail.com> <015501cbb11f$cce25a80$c60ca8c0@china.huawei.com> <4D2BBA15.309@gmail.com> <01b301cbb1a5$f65dbe50$c60ca8c0@china.huawei.com> In-Reply-To: <01b301cbb1a5$f65dbe50$c60ca8c0@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: Tue, 11 Jan 2011 21:02:28 -0000 On 2011-01-12 04:41, Yong Lucy wrote: >>> >>> [LY] Statistical approach works well under the consumption that there >> are >>> thousands of flows and they have the similar rates. Today's Internet may >>> have the flows that only have few packets and the flows that have >> thousands >>> packets per second and last long. Hash does not work well under this >>> condition. >> In fact no solution works well for short flows and the problem isn't >> important >> for long flows with few packets. So I think it's OK to discuss a solution >> that works for long flows with many packets, since that covers most >> of the load. > > [LY] Hash works well for short flows. Lucy, I wrote carelessly - really I was thinking about stateful solutions involving a hash, that are simply not worth the overhead for short flows ("short" to me means maybe 5 or 10 packets at most. Yes, a stateless solution can work for short flows, whether it's round-robin or hash based. For the rest, Fred and Shane have covered the discussion, and I don't see that it affects the draft. Brian From brian.e.carpenter@gmail.com Tue Jan 11 13:19: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 324573A677C for ; Tue, 11 Jan 2011 13:19:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.432 X-Spam-Level: X-Spam-Status: No, score=-103.432 tagged_above=-999 required=5 tests=[AWL=0.167, 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 ajHG59-51sun for ; Tue, 11 Jan 2011 13:19: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 C892E3A67AF for ; Tue, 11 Jan 2011 13:19:32 -0800 (PST) Received: by fxm9 with SMTP id 9so20798958fxm.31 for ; Tue, 11 Jan 2011 13:21:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :organization:user-agent:mime-version:to:cc:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=jb4+UBMzOOOpAhcJvyw7YYNm5y6Sh8qykelk1KUxWtM=; b=HjQuzTm0uJqUjpBlrAswuntX/T5cW1LcJ9dXszQXipmtXRyhXu5CC7gcTaUJk5El68 mPLfdVwFwxrBTTIyWenN25mrJ1aMrb7zWUiS2YQOJdKGoN70rbHr0p36+7OibpIueJAK idL0e5L7GEHSFGC5vqKt1mgMb8L/h+5S/K92w= 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=rdNmHwDmx2jMd6Y/6G5FuZRbSZl36ZC27KVuUq1MxWv29WBYjmTvxePfhAeyKZtGon fVw9/1fhEYQGP6szAgyzaWIkYJ4O5qKJ+YbIH09vSly/8Wm/yXhr0Jysg5OOoMjrhCgZ RSLs3iraDwpxHpzL+CXh4kkc9MEvGwa6IRTnM= Received: by 10.223.115.11 with SMTP id g11mr123720faq.64.1294780909060; Tue, 11 Jan 2011 13:21:49 -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 a25sm7590805fak.20.2011.01.11.13.21.46 (version=SSLv3 cipher=RC4-MD5); Tue, 11 Jan 2011 13:21:48 -0800 (PST) Message-ID: <4D2CC9E7.3010201@gmail.com> Date: Wed, 12 Jan 2011 10:21:43 +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: Flow Labels: what problem are we solving? References: <201101111341.p0BDfAiR005195@cichlid.raleigh.ibm.com> In-Reply-To: <201101111341.p0BDfAiR005195@cichlid.raleigh.ibm.com> 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: Tue, 11 Jan 2011 21:19:35 -0000 Thomas, On 2011-01-12 02:41, Thomas Narten wrote: > Sorry to get back to basics, but I have not followed all the Flow > Label discussions or read all the drafts. I have read > > draft-ietf-6man-flow-ecmp-00.txt > draft-ietf-6man-flow-update-01.txt > > pretty carefully and I still don't quite understand what real problem > we are trying to solve - and thus, whether the proposed changes > actually help or are a no op. > > Is there a document that speaks to this? I think others have tried to tackle your question by explaining the perceived need to do some things that we can't do with IPv4. There are also 3 meta-problems, which is why I keep mentioning draft-hu-flow-label-cases (in the Independent stream queue). 1. The existence of 20 unused bits in the header is in itself a problem in some people's eyes - we are wasting bits and energy storing and transmitting (or compressing) those bits. 2. There are intrinsic ambiguities in RFC 3697 that have prevented serious use of the flow label, even in the simple use case defined in draft-carpenter-flow-ecmp. 3. Those ambiguities (and probably other factors) have led to a variety of quite baroque proposals for using the flow label, both posted as I-Ds and published in academic format. For gory details, see draft-hu-flow-label-cases. Brian From fred@cisco.com Tue Jan 11 18:03: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 04E393A67AD for ; Tue, 11 Jan 2011 18:03:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.462 X-Spam-Level: X-Spam-Status: No, score=-110.462 tagged_above=-999 required=5 tests=[AWL=0.137, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 3nGVmIbCV0sU for ; Tue, 11 Jan 2011 18:03:51 -0800 (PST) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id 4AE553A659A for ; Tue, 11 Jan 2011 18:03:51 -0800 (PST) Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAFebLE2rR7Ht/2dsb2JhbACkO3Ojb5h3gweCRQSEZ4YlgyA Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-4.cisco.com with ESMTP; 12 Jan 2011 02:06:09 +0000 Received: from stealth-10-32-244-221.cisco.com (stealth-10-32-244-221.cisco.com [10.32.244.221]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id p0C264lk006623; Wed, 12 Jan 2011 02:06:08 GMT Received: from [127.0.0.1] by stealth-10-32-244-221.cisco.com (PGP Universal service); Tue, 11 Jan 2011 18:06:09 -0800 X-PGP-Universal: processed; by stealth-10-32-244-221.cisco.com on Tue, 11 Jan 2011 18:06:09 -0800 Subject: Re: [Fwd: I-D Action:draft-ietf-6man-flow-update-00.txt] Mime-Version: 1.0 (Apple Message framework v1082) From: Fred Baker In-Reply-To: <74854626-A84C-4B32-ACD5-004EE460ED86@castlepoint.net> Date: Tue, 11 Jan 2011 18:05:54 -0800 Message-Id: References: <4CF82E6F.9040309@gmail.com> <4D08165A.3060306@gmail.com> <51661CE4-EC60-46B9-928C-D5763CFDF318@cisco.com> <4D082147.9010209@gmail.com> <4D2A1B84.1020003@gmail.com> <4D2A64A1.4030400@gmail.com> <982F8CA8-789A-42D6-9C86-E194BA868023@cisco.com> <4D2B8557.9090107@gmail.com> <015501cbb11f$cce25a80$c60ca8c0@china.huawei.com> <4D2BBA15.309@gmail.com> <01b301cbb1a5$f65dbe50$c60ca8c0@china.huawei.com> <88554593-E194-40CB-AC10-29187DCBCDA0@cisco.com> <74854626-A84C-4B32-ACD5-004EE460ED86@castlepoint.net> To: Shane Amante X-Mailer: Apple Mail (2.1082) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: '6man' , '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: Wed, 12 Jan 2011 02:03:53 -0000 On Jan 11, 2011, at 10:14 AM, Shane Amante wrote: > What causes pain and/or worry to us operators is when someone launches = a large *individual* "macro-flow"[1] at the network that start to = represent a decent fraction of the overall capacity of a physical = component-link underlying a LAG and/or ECMP path, (e.g.: and the = following are only an *example*: 200 Mbps, 500 Mbps, 1 Gbps, etc. on a = 10 Gbps link). Unfortunately, due to the fact that load-hashing = algorithms are stateless (and, thus, non-adaptive), that means that = "well-behaved" microflows (think: casual Web surfing, e-mail, etc.) are = still co-mingled with those large, fat-flows across all component-links = in a common LAG/ECMP path *without* taking into account BW utilization = of individual component-links. So, there is a much higher probability = (or, oftentimes, certainty) of congestion and packet loss causing pain = to all users on the one (or, more) component-links with fat, macro-flows = on them that I can't capacity plan for and I can't easily react to. >=20 > -shane >=20 > [1] Examples are: IPvX in IPvX tunneling, GRE, IPSec, "WAN = acceleration" type products that are used for extremely fast large file = xfers, etc. Yes. And there are similar issues in data centers, where load balancing = is also used but in a different way. There is another way to make a video flow be a relatively large chunk of = a link; go closer to the access. "why should I care about a 5/10/20 = MBPS...on a 10 GBPS"? You shouldn't. But, how about a 20 MBPS data flow = for each access customer when you have sized for an aggregate of 25 MBPS = per customer? That can be quite a bit different. For the record, when we = were developing our telepresence product, we had to look at the pacing = of traffic coming out of the camera/codec, because we found that a 5 = MBPS data flow with 10 MBPS peaks could momentarily swamp a 100 MBPS = link. Obvious enough to me (hint: peak on a short timescale !=3D average = on a long timescale), but very counterintuitive to my colleagues. There are ways to make stateless hashes change the way they hash. If = you're using a CRC as a hash generator, for example, it starts with an = initial value placed in a register. Change the initial value, and all = the hashes change. If you find the distribution not to your liking, = change the value, and see if you like that any better. The sad part is = that there is no easy way to "calculate an initial value I will like"; = you have to try them all, or at least occasionally try a different one. Finding a predictable method tends to be about - as Ipsilon proposed a = decade plus ago - identifying the important data flows and doing = something intelligent with them, and running the rest statistically. http://www.ietf.org/rfc/rfc2098.txt 2098 Toshiba's Router Architecture Extensions for ATM : Overview. Y. Katsube, K. Nagami, H. Esaki. February 1997. (Format: TXT=3D43622 bytes) (Status: INFORMATIONAL) http://www.ietf.org/rfc/rfc2129.txt 2129 Toshiba's Flow Attribute Notification Protocol (FANP) Specification. K. Nagami, Y. Katsube, Y. Shobatake, A. Mogi, S. Matsuzawa, T. Jinmei, H. Esaki. April 1997. (Format: TXT=3D41137 = bytes) (Status: INFORMATIONAL) From hingkam16@gmail.com Sat Jan 15 14:45: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 7B9AD3A6B46 for ; Sat, 15 Jan 2011 14:45:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.049 X-Spam-Level: X-Spam-Status: No, score=-3.049 tagged_above=-999 required=5 tests=[AWL=0.250, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, 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 mF7f5bgru7Up for ; Sat, 15 Jan 2011 14:45:02 -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 A4FAD3A6B3C for ; Sat, 15 Jan 2011 14:45:02 -0800 (PST) Received: by iyi42 with SMTP id 42so3874076iyi.31 for ; Sat, 15 Jan 2011 14:47: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=PeOkeyrz2mYy1HtIAo3Y63wZfOy3xNqyTc2bEVWx6II=; b=e5HJUBDTxrucm7aru2njRYn4pTSWVpKmQBDEswKzYRMZFag5HEZw9Wca9WIn2B7YlQ +MT3VdfM1Yg7fRCWH1wIy3SnAgT56H3uWtolAKG9uUthOcC+s+4tLvcQVyO0YQ8zZcBZ 6BMfzIZZUgOWnxq8psZ3D8f1ZgaIglMk9bYbU= 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=VhvIrBNybIrnZ0EyV/Dn95f5wQQwTbyGb2v+8wUyKX1wzEK43gWgUox/oZFVgOhcvN j9OVnTLEZbPrJoV/4Pgh7zAFOOmiMymxT/dsNLlx/CMyZpQy9CMG5r0wG4XnPNt9psiI 3LurUQckT/6lCV1sIqpXkLjKlx7yr/p9tnNxw= MIME-Version: 1.0 Received: by 10.231.206.143 with SMTP id fu15mr2484781ibb.3.1295131652062; Sat, 15 Jan 2011 14:47:32 -0800 (PST) Received: by 10.231.14.141 with HTTP; Sat, 15 Jan 2011 14:47:31 -0800 (PST) In-Reply-To: References: <4FD1E7CD248BF84F86BD4814EDDDBCC150E9C6485F@EUSAACMS0703.eamcs.ericsson.se> <5741B0CD-4A89-4DEE-A34D-D7513EEF64C9@gmail.com> <4D24D162.3040805@gmail.com> Date: Sun, 16 Jan 2011 04:17:31 +0530 Message-ID: Subject: Re: I-D Action:draft-ietf-6man-exthdr-01.txt From: "Hing-Kam (Kam) Lam" To: =?ISO-8859-1?B?UultaSBEZXNwculz?= Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: 6man 6man , Suresh Krishnan , Brian 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: Sat, 15 Jan 2011 22:45:04 -0000 On Thu, Jan 6, 2011 at 6:56 PM, R=E9mi Despr=E9s wro= te: > > Le 5 janv. 2011 =E0 21:15, Brian E Carpenter a =E9crit : >> On 2011-01-06 02:15, RJ Atkinson wrote: >> ... >>> Prohibiting new IPv6 Extension Headers outright, >>> ... >> My reaction is that this is going too far, > > +1 I agree with this. I dont think we should be explicitly prohibiting any new IPv6 extension headers. We could discourage the use of the same, but prohibiting is taking it to a new, and rather an unreasonable level. > >> ... >> So I am more inclined to a SHOULD NOT approach; I think I'm agreeing >> with a somewhat stronger version of Suresh's proposed paragraph. >> At least, add >> >> ...accompanied by ... and a convincing explanation of a successful >> progressive deployment model for the proposed new header. > > This seems to me a good compromise. > +1 Yes, i agree with this as well. We should at the very least document what a new IPv6 extension header must look like, with some text that says that this should only be used once the working group has been convinced that it cannot use the existing IPv6 extension headers for the job. I am ambivalent on the options that have been added. I also agree that using a new protocol ID perhaps is not required. Kam From hingkam16@gmail.com Sat Jan 15 14:52: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 156783A6B98 for ; Sat, 15 Jan 2011 14:52:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.241 X-Spam-Level: X-Spam-Status: No, score=-3.241 tagged_above=-999 required=5 tests=[AWL=0.358, 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 paxMrKr8e2GQ for ; Sat, 15 Jan 2011 14:52:49 -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 DF00D3A6B69 for ; Sat, 15 Jan 2011 14:52:48 -0800 (PST) Received: by iyi42 with SMTP id 42so3877268iyi.31 for ; Sat, 15 Jan 2011 14:55:18 -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=DGsSmecmlWpAQFaM93MXdiDfrm/cn+ycBE+frjT8DLg=; b=B93iZNjm87Vws+zm5pycXbzihEUhKzJTTg11fCDgPJTnt11oDEQkYuqLVnca6BkB8L o3GPGtvYskbLoc03/9dnGXQs6MPHEqGjI5vTUZqfPx0cwT8XbOoxBmFie2BxvhiFIQLI O07nyU51js7sOGi2i0npCGdlST461+E99XB1U= 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=SmCXXaSgzWN9h98Qoxnt7jQkZpf7sjmsah3wqZcjeaUDcummeZflcSMqC9qcWP4E1M R80luCEHAAftHf0Id44BO1Yj0O3LkWy0ypanmj3vw9Z6qdhigxl+GbNwY7q9puIlTADQ fF1Lrh6S/mAZnn8GHv2MnjxllNNAav3ZNu8X4= MIME-Version: 1.0 Received: by 10.231.30.71 with SMTP id t7mr2452502ibc.153.1295132117867; Sat, 15 Jan 2011 14:55:17 -0800 (PST) Received: by 10.231.14.141 with HTTP; Sat, 15 Jan 2011 14:55:17 -0800 (PST) In-Reply-To: <4D2242E9.8040804@gont.com.ar> References: <20101217234501.11691.81147.idtracker@localhost> <63416880-97B6-4CE4-864A-1402DA977B5F@tony.li> <4D113364.3050105@ericsson.com> <201101032040.p03KeE86005244@cichlid.raleigh.ibm.com> <4D223EC0.7020906@gmail.com> <4D2242E9.8040804@gont.com.ar> Date: Sun, 16 Jan 2011 04:25:17 +0530 Message-ID: Subject: Re: I-D Action:draft-ietf-6man-exthdr-01.txt From: "Hing-Kam (Kam) Lam" To: Fernando Gont Content-Type: text/plain; charset=ISO-8859-1 Cc: Thomas Narten , "ipv6@ietf.org" , Brian E Carpenter , Suresh Krishnan 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, 15 Jan 2011 22:52:50 -0000 Fernando, >> >> That is, help middleboxes to violate e2e transparency and, furthermore, >> allow unknown headers to cross those middleboxes. > > I don't think this I-D will make a difference. > > From the POV of a firewall, unless it really wants a packet to > pass-through, it will block it. > > So, whether the Extension Header is unknown, or whether > draft-ietf-6man-exthdr-01.txt is implemented and the Specific type is > unknown will lead to the same result: the packet will be discarded. This is incorrect - The draft clearly says that if the Hdr Options is 00, then the packet will skip over this option and continue with the remaining packet. Kam > > This proposal would only be useful to firewalls that implement a > "default allow", and that simply want to somehow ignore an unknown > extension header and base their decision on the upper-layer protocol > (only). -- But we all know that firewalls operate (or should operate) in > "default deny" rather than "default allow". > > So IMHO this proposal won't be useful for such firewalls. > > Thanks, > -- > Fernando Gont > e-mail: fernando@gont.com.ar || fgont@acm.org > PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 > > > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > From hingkam16@gmail.com Sat Jan 15 14:55: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 0E2633A6BA8 for ; Sat, 15 Jan 2011 14:55:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.292 X-Spam-Level: X-Spam-Status: No, score=-3.292 tagged_above=-999 required=5 tests=[AWL=0.307, 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 oE27zoeIoUWe for ; Sat, 15 Jan 2011 14:55:13 -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 07E4F3A6B9B for ; Sat, 15 Jan 2011 14:55:12 -0800 (PST) Received: by iyi42 with SMTP id 42so3878121iyi.31 for ; Sat, 15 Jan 2011 14:57: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=W+3mHqf+w3DgGt+HjkBdiqAoDy3pj6URyBkRNhACrbk=; b=f+aVtfps6kiUMaPe9JE/+eLtLg7SM9wtfDqMD/USJByN8sXi4+0Vv8o/p915Z6rqDf ghvuLdXFYpZhoPSd2i7ilBzEDxIpPWjhp5WzMsbobiS+rWws6DbWl7c/jIuC5O5pNsi4 /7N7i1y0oVqr3FlAfmSrEbDBCG/Hf/D6Yu7ao= 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=N4PS14LTuNPTX5S6UmUmu7WiSgPwomBg4lTtv08CTdEJ+/dOBB/+wS/03dbPR1j64W tMwYagR718WVXGKgBXE6jainOpU8WnMCjWfF5syoiO9MCV/758GxaIUkAToVh0XY0qaB vAZU8EfrIqRqss0YqSxBmrgchhGy17UYuujIg= MIME-Version: 1.0 Received: by 10.231.10.193 with SMTP id q1mr2463925ibq.53.1295132261163; Sat, 15 Jan 2011 14:57:41 -0800 (PST) Received: by 10.231.14.141 with HTTP; Sat, 15 Jan 2011 14:57:41 -0800 (PST) In-Reply-To: <4D224550.5080808@joelhalpern.com> References: <20101217234501.11691.81147.idtracker@localhost> <63416880-97B6-4CE4-864A-1402DA977B5F@tony.li> <4D113364.3050105@ericsson.com> <201101032040.p03KeE86005244@cichlid.raleigh.ibm.com> <4D223EC0.7020906@gmail.com> <4D2242E9.8040804@gont.com.ar> <4D224550.5080808@joelhalpern.com> Date: Sun, 16 Jan 2011 04:27:41 +0530 Message-ID: Subject: Re: I-D Action:draft-ietf-6man-exthdr-01.txt From: "Hing-Kam (Kam) Lam" 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: Sat, 15 Jan 2011 22:55:14 -0000 > If we take the view that a firewall will block anything it does not know, > without question or limit, then > 1) We have no way to extend our basic protocols that will pass through > firewalls (we have to tunnel / encapsulate) I agree. > 2) you are correct that this document does not help. Disagree. If the Hdr Options is 00, then it will pass through. > > Also, if we assume that no one will ever define any new extension headers= , > then this work does not matter. > > (If we want that prohibition to be the case, we should say so, and remove > the hook for new extension headers that was left in 2460.) > > On the other hand, if we think that there will be new extension headers, = and > we think that firewalls block things if they can not find enough informat= ion > to allow them through, then it can be helpful if the firewalls (and other > devices) can parse pass these new extensions without knowing them. > =A0(Remember, these are for end-point consumption only.) Yes. > > It seems to me a disservice to simultaneously let people use new extensio= n > headers and not give them a way to use them that can be parsed past by th= e > common devices that could easily want to do such parsing. Yes. > > My own preference would probably be to say that all end-to-end IP > information should be in the destination options. =A0But if we do not wan= t to > go there, then we should own up to the implications thereof. =A0(In > particular, there might be corner cases that can't use destination option= s. > =A0We should tell people to use destination options first. =A0And tell th= em what > to do if they can't.) This then could be added in the subsequent versions of this draft. Kam > > Yours, > Joel > > On 1/3/2011 4:43 PM, Fernando Gont wrote: >> >> On 03/01/2011 06:25 p.m., Brian E Carpenter wrote: >> >>> The basic motivation for the present draft is clear: >>> >>>> =A0 =A0However, >>>> =A0 =A0some intermediate nodes such as firewalls, may need to look at = the >>>> =A0 =A0transport layer header fields in order to make a decision to al= low or >>>> =A0 =A0deny the packet. >>> >>> That is, help middleboxes to violate e2e transparency and, furthermore, >>> allow unknown headers to cross those middleboxes. >> >> I don't think this I-D will make a difference. >> >>> From the POV of a firewall, unless it really wants a packet to >> >> pass-through, it will block it. >> >> So, whether the Extension Header is unknown, or whether >> draft-ietf-6man-exthdr-01.txt is implemented and the Specific type is >> unknown will lead to the same result: the packet will be discarded. >> >> This proposal would only be useful to firewalls that implement a >> "default allow", and that simply want to somehow ignore an unknown >> extension header and base their decision on the upper-layer protocol >> (only). -- But we all know that firewalls operate (or should operate) in >> "default deny" rather than "default allow". >> >> So IMHO this proposal won't be useful for such firewalls. >> >> Thanks, > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > From hingkam16@gmail.com Sat Jan 15 14:57: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 0BBFF3A6BA7 for ; Sat, 15 Jan 2011 14:57:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.33 X-Spam-Level: X-Spam-Status: No, score=-3.33 tagged_above=-999 required=5 tests=[AWL=0.269, 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 OLWKKuKgHzLo for ; Sat, 15 Jan 2011 14:57:25 -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 CB2813A6BA6 for ; Sat, 15 Jan 2011 14:57:25 -0800 (PST) Received: by iwn40 with SMTP id 40so3848847iwn.31 for ; Sat, 15 Jan 2011 14:59:55 -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=XbFp4RAQMbeWiWDWm69Cgfd8Ki1FgQPtQZaSdn+wl0w=; b=oxYoysn2DfNtXD0GZ7vRhHmMqhw5lxoAyS6yr5iisWpR6jo9kziKnj+0Inzla2i4Uc ZZIMsfouuZYz0bOO7YBS6gqQzqQoh/SdSE+BHoSYVxv79zr/RflZcrLv1tqVJOTczz71 Rim1kgu5jXEvY+o/BGTRqHSERm9V1yFx8sTbs= 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=ibQZmZO3+rqY0x6yGGH7AH/CxBuiG/FPVK6yLiiTdgbEzxOgkJa0XojPBkzRyJeV1P +mG/m0tyCGocKhDTx29px7BjyqHtDZlO706RVbFc18nOBD1JKgKT56IEmcLiQmUij88r WjA5DaTpIqMrZ25GIeyTatIpAemsN2NbIyHik= MIME-Version: 1.0 Received: by 10.231.12.7 with SMTP id v7mr2456431ibv.78.1295132395164; Sat, 15 Jan 2011 14:59:55 -0800 (PST) Received: by 10.231.14.141 with HTTP; Sat, 15 Jan 2011 14:59:55 -0800 (PST) In-Reply-To: <201101041420.p04EKOmT006328@cichlid.raleigh.ibm.com> References: <20101217234501.11691.81147.idtracker@localhost> <63416880-97B6-4CE4-864A-1402DA977B5F@tony.li> <4D113364.3050105@ericsson.com> <201101032040.p03KeE86005244@cichlid.raleigh.ibm.com> <4D223EC0.7020906@gmail.com> <201101041420.p04EKOmT006328@cichlid.raleigh.ibm.com> Date: Sun, 16 Jan 2011 04:29:55 +0530 Message-ID: Subject: Re: I-D Action:draft-ietf-6man-exthdr-01.txt From: "Hing-Kam (Kam) Lam" To: Thomas Narten Content-Type: text/plain; charset=ISO-8859-1 Cc: "ipv6@ietf.org" , Brian E Carpenter , Suresh Krishnan 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, 15 Jan 2011 22:57:27 -0000 > > But it is a very open question whether any middlebox will bother to > do this. > >> So the one thing this proposal will *not* do is allow new extension headers >> to cross the Internet transparently. All it might do is cause the firewalls >> to dig one layer deeper before discarding the packet. > > This is at best poorly phrased. :-) > > If the firewall will just dig one layer deeper and then discard > anyway, what is the point? It wouldnt in all the cases - not when the Hdr type is 00. Kam From brian.e.carpenter@gmail.com Sat Jan 15 16:26: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 969073A6BA0 for ; Sat, 15 Jan 2011 16:26:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.454 X-Spam-Level: X-Spam-Status: No, score=-103.454 tagged_above=-999 required=5 tests=[AWL=0.145, 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 8gtEQky8a+xA for ; Sat, 15 Jan 2011 16:26:21 -0800 (PST) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by core3.amsl.com (Postfix) with ESMTP id 8DD2F3A6B46 for ; Sat, 15 Jan 2011 16:26:21 -0800 (PST) Received: by yxt33 with SMTP id 33so1762976yxt.31 for ; Sat, 15 Jan 2011 16:28:51 -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=x+FGMNOjEkCzFYTJDehkR0lh8eUQAKjYYRlosMc8esc=; b=lDoZNz1w5/50zFufbp5UJ1Co7q4L8rH+WKQJw7X3TUByCrCuMFWq023JEbebV6TAa5 SLfTR2GfC+yd0LJZUti/5Sseci5x7MzlPqao5HLLskGUiQfOjHmrfpTqWVJ3h8WPVgo6 K1p5Xve/0pkHhNfhKLPUWXxK+16N759cZYnAE= 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=pdSYqRan1PsSPfXbL+AFmnR6fefBoa6MvV5C3pI8pkvvBaU+Bv9hCtXGKOruokwfIa JlwciGDeaSWAPE3QUNr0wszYtX+IcJencAmjwJE92zzGFnfdyhQR5+5Z8+s/nf4OYRUs sEcD1R1AK84ybQZscG5KFj5MSe+1MzemICZuw= Received: by 10.236.109.1 with SMTP id r1mr5202608yhg.1.1295137730941; Sat, 15 Jan 2011 16:28:50 -0800 (PST) Received: from [10.1.1.4] ([121.98.190.33]) by mx.google.com with ESMTPS id a27sm1787694yhd.8.2011.01.15.16.28.48 (version=SSLv3 cipher=RC4-MD5); Sat, 15 Jan 2011 16:28:50 -0800 (PST) Message-ID: <4D323BBF.4070805@gmail.com> Date: Sun, 16 Jan 2011 13:28:47 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: "Hing-Kam (Kam) Lam" Subject: Re: I-D Action:draft-ietf-6man-exthdr-01.txt References: <20101217234501.11691.81147.idtracker@localhost> <63416880-97B6-4CE4-864A-1402DA977B5F@tony.li> <4D113364.3050105@ericsson.com> <201101032040.p03KeE86005244@cichlid.raleigh.ibm.com> <4D223EC0.7020906@gmail.com> <201101041420.p04EKOmT006328@cichlid.raleigh.ibm.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Thomas Narten , "ipv6@ietf.org" , Suresh Krishnan 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, 16 Jan 2011 00:26:22 -0000 On 2011-01-16 11:59, Hing-Kam (Kam) Lam wrote: >> But it is a very open question whether any middlebox will bother to >> do this. >> >>> So the one thing this proposal will *not* do is allow new extension headers >>> to cross the Internet transparently. All it might do is cause the firewalls >>> to dig one layer deeper before discarding the packet. >> This is at best poorly phrased. :-) >> >> If the firewall will just dig one layer deeper and then discard >> anyway, what is the point? > > It wouldnt in all the cases - not when the Hdr type is 00. If the firewall's policy is to dig deeper when the type is 00, it will do so, regardless of what some RFC may say. Firewalls are not known for obeying RFCs. Brian From anchie@fer.hr Sun Jan 16 03:05: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 B31503A6D4F; Sun, 16 Jan 2011 03:05:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.185 X-Spam-Level: X-Spam-Status: No, score=-0.185 tagged_above=-999 required=5 tests=[BAYES_40=-0.185] 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 Hdn5RJx+Sut4; Sun, 16 Jan 2011 03:05:50 -0800 (PST) Received: from munja.zvne.fer.hr (munja.zvne.fer.hr [161.53.66.248]) by core3.amsl.com (Postfix) with ESMTP id 9FB823A6D2B; Sun, 16 Jan 2011 03:05:49 -0800 (PST) Received: from sluga.fer.hr ([161.53.66.244]) by munja.zvne.fer.hr with Microsoft SMTPSVC(6.0.3790.4675); Sun, 16 Jan 2011 12:08:18 +0100 Received: from anchie-MacBook.lan ([93.136.67.168]) by sluga.fer.hr with Microsoft SMTPSVC(6.0.3790.4675); Sun, 16 Jan 2011 12:08:18 +0100 Message-ID: <4D32D1A1.5080003@fer.hr> Date: Sun, 16 Jan 2011 12:08:17 +0100 From: Ana Kukec User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: "cga-ext@ietf.org" , "ipv6@ietf.org" Subject: SEND on FreeBSD Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 16 Jan 2011 11:08:18.0201 (UTC) FILETIME=[ADCAE890:01CBB56D] 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, 16 Jan 2011 11:05:50 -0000 Dear all, I would like to announce the availability of SEND implementation on FreeBSD. The native SEND kernel API can be found in FreeBSD 9, while the port can be found in category net-mgmt/send-0.3: http://www.freebsd.org/cgi/ports.cgi?query=send-0.3&stype=all. Please let me know the feedback. Ana From john.loughney@nokia.com Sun Jan 16 12:23: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 A4BE63A6D2A for ; Sun, 16 Jan 2011 12:23:39 -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 gdS86PzaVQ+1 for ; Sun, 16 Jan 2011 12:23:38 -0800 (PST) Received: from mgw-da01.nokia.com (smtp.nokia.com [147.243.128.24]) by core3.amsl.com (Postfix) with ESMTP id B3E023A6E15 for ; Sun, 16 Jan 2011 12:23:38 -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 p0GKQ59f010519; Sun, 16 Jan 2011 22:26:06 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.6]) by vaebh106.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Sun, 16 Jan 2011 22:26:00 +0200 Received: from 008-AM1MMR1-005.mgdnok.nokia.com (65.54.30.60) by NOK-am1MHUB-02.mgdnok.nokia.com (65.54.30.6) with Microsoft SMTP Server (TLS) id 8.2.255.0; Sun, 16 Jan 2011 21:26:00 +0100 Received: from 008-AM1MPN1-001.mgdnok.nokia.com ([169.254.1.177]) by 008-AM1MMR1-005.mgdnok.nokia.com ([65.54.30.60]) with mapi; Sun, 16 Jan 2011 21:25:59 +0100 From: To: , Subject: RE: 6MAN WG Last Call: Thread-Topic: 6MAN WG Last Call: Thread-Index: AcudigjdbsYEF5EbQam6CoUfsp98aQMoOQKAAuQA5qA= Date: Sun, 16 Jan 2011 20:25:57 +0000 Message-ID: <5A3D6281CDB9694585F5A573EF7CBD8D18B7E4@008-AM1MPN1-001.mgdnok.nokia.com> References: <7B63F7B6-D788-4A05-9722-C1CAAA42B754@gmail.com> <4D1FFB3D.2030804@gmail.com> In-Reply-To: <4D1FFB3D.2030804@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: 16 Jan 2011 20:26:00.0288 (UTC) FILETIME=[96C02E00:01CBB5BB] X-Nokia-AV: Clean Cc: brian@innovationslab.net, 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: Sun, 16 Jan 2011 20:23:39 -0000 Brian, I did not see any comments on this, but in general I agree with your points= below. Comments in-line -----Original Message----- > I would be happy to see this published as-is, but I did notice > a few points. > > I think the Introduction needs a general warning something like: > > This document reflects the state of IPv6 standards at a particular > moment. Subsequent standards work and operational experience may > require changes to the recommendations in this document. This makes sense. > Also in the Introduction: > > > As it is not always possible for an implementer to know the exact > > usage of IPv6 in a node, an overriding requirement for IPv6 nodes is > > that they should adhere to Jon Postel's Robustness Principle: > >=20 > > Be conservative in what you do, be liberal in what you accept from > > others [RFC0793]. > > Note that this is also present in RFC 1958, by which time > Jon had reformulated it slightly as: > > > Be strict when sending and tolerant when receiving. I always thought the 793 text was a bit more poetic, but I think either is = fine. > In 4. Sub-IP Layer > > > In addition to traditional physical link-layers, it is also possible > > to tunnel IPv6 over other protocols. Examples include: > > Should we mention that basic v6/v4 tunnels are specified in [RFC4213]?=20 > > And the examples > > > - Teredo: Tunneling IPv6 over UDP through Network Address > > Translations (NATs) [RFC4380] > > - Transmission of IPv6 over IPv4 Domains without Explicit Tunnels > > [RFC2529] > > may not be so well chosen. Teredo is not loved by operators, and > RFC 2529 is essentially unused today. Maybe 6rd (RFC 5969)and > hub-and-spoke (RFC 5571) would be better examples. Including 4213 makes sense, and I don't oppose dropping 2529. Terado suppo= rt is a judgement call, IMO. > Two topics are not mentioned. > > 1. The flow label and RFC 3697. I think that is probably wise until > we produce 3697bis. I agree. > 2. DNSSEC. I don't recall whether we discussed that. If we did, > I'm sorry to raise it again. However, I suspect we will get pushback > in security review if it is not mentioned. Do we (6man) have any opinion here? > Nit: there should be a Replaces: 4294 header. Agree. John From bob.hinden@gmail.com Sun Jan 16 17:29: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 E57CD3A6E64 for ; Sun, 16 Jan 2011 17:29:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.268 X-Spam-Level: X-Spam-Status: No, score=-103.268 tagged_above=-999 required=5 tests=[AWL=0.331, 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 QPlwvQuHN9CF for ; Sun, 16 Jan 2011 17:29:12 -0800 (PST) Received: from mail-pv0-f172.google.com (mail-pv0-f172.google.com [74.125.83.172]) by core3.amsl.com (Postfix) with ESMTP id 1C0773A6BA2 for ; Sun, 16 Jan 2011 17:29:12 -0800 (PST) Received: by pvc21 with SMTP id 21so963755pvc.31 for ; Sun, 16 Jan 2011 17:31:44 -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:cc:to:mime-version:x-mailer; bh=nkDre2rSQj9vjo9VGpjaT4oGT8q3X9RA/OY0gaG9y80=; b=n+rKRO6Xk1PIYGATRVP46tp18WB3rDqPZ5rIRZK24PZtlF/LuTYS03u816A5yVrmtt mqSlJeKyVukMbIHGBoDP0V+CL6tTKhF03RHttUKk/+4K737cKEUmk6tdqz6RXeJoq5+d zMzCK8XGIqW5J2oCkl96xPnJyKfysSPouES5U= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:content-type:content-transfer-encoding:subject:date:message-id :cc:to:mime-version:x-mailer; b=s3KHNQuwJzXJZWylVNX/TW9KbHjEhihPRd8EzBVIVXJo/XgwrNT+mJxlNsD4RzgfJ3 Bn2T3k+8YyMZaTM5g/aZ8ryTGIliyM6x9jjWrar2wa5B7QGZ3ne6nxdTwOrfpHJvNLOV sdXic/NIXC61vwyYDtzrpvNguzFxvATaKWev0= Received: by 10.142.154.17 with SMTP id b17mr3078412wfe.387.1295227903776; Sun, 16 Jan 2011 17:31:43 -0800 (PST) Received: from [10.0.0.37] (c-24-130-226-27.hsd1.ca.comcast.net [24.130.226.27]) by mx.google.com with ESMTPS id x18sm5813740wfa.23.2011.01.16.17.31.41 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sun, 16 Jan 2011 17:31:42 -0800 (PST) From: Bob Hinden Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: 6MAN WG Last Call: Date: Sun, 16 Jan 2011 17:31:40 -0800 Message-Id: To: 6man Mailing List Mime-Version: 1.0 (Apple Message framework v1082) X-Mailer: Apple Mail (2.1082) Cc: Brian Haberman , 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: Mon, 17 Jan 2011 01:29:13 -0000 All, This message starts a 6MAN Working Group Last Call on advancing: Title : Update to the IPv6 flow label specification Author(s) : S. Amante, et al. Filename : draft-ietf-6man-flow-update-01.txt Pages : 13 Date : 2011-01-10 =09 http://tools.ietf.org/html/draft-ietf-6man-flow-update-01 =20= 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 31, 2011. Regards, Bob Hinden & Brian Haberman 6MAN Chairs From remi.despres@free.fr Mon Jan 17 01:24: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 DCB8E28C1A2 for ; Mon, 17 Jan 2011 01:24:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.436 X-Spam-Level: X-Spam-Status: No, score=-1.436 tagged_above=-999 required=5 tests=[AWL=0.513, BAYES_00=-2.599, HELO_EQ_FR=0.35, 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 Tg1zoOeNUE-t for ; Mon, 17 Jan 2011 01:24:44 -0800 (PST) Received: from smtp23.services.sfr.fr (smtp23.services.sfr.fr [93.17.128.20]) by core3.amsl.com (Postfix) with ESMTP id D31A428C1A1 for ; Mon, 17 Jan 2011 01:24:43 -0800 (PST) Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2309.sfr.fr (SMTP Server) with ESMTP id AAE42700009B; Mon, 17 Jan 2011 10:27:16 +0100 (CET) Received: from [192.168.0.20] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by msfrf2309.sfr.fr (SMTP Server) with ESMTP id 547C770000A8; Mon, 17 Jan 2011 10:27:16 +0100 (CET) X-SFR-UUID: 20110117092716346.547C770000A8@msfrf2309.sfr.fr Subject: draft-ietf-6man-exthdr-01 - Support for adoption Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: Date: Mon, 17 Jan 2011 10:27:15 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <60F6C8B3-4FC0-4393-8168-027D6E6DC013@free.fr> References: <20101217234501.11691.81147.idtracker@localhost> <63416880-97B6-4CE4-864A-1402DA977B5F@tony.li> <4D113364.3050105@ericsson.com> <201101032040.p03KeE86005244@cichlid.raleigh.ibm.com> <4D223EC0.7020906@gmail.com> <201101041420.p04EKOmT006328@cichlid.raleigh.ibm.com> To: 6man 6man X-Mailer: Apple Mail (2.1082) Cc: Thomas Narten , Brian Carpenter , Suresh Krishnan 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, 17 Jan 2011 09:24:45 -0000 Le 15 janv. 2011 =E0 23:59, Hing-Kam (Kam) Lam a =E9crit : >> If the firewall will just dig one layer deeper and then discard >> anyway, what is the point? >=20 > It wouldnt in all the cases - not when the Hdr type is 00. If the draft is adopted, the more precise situation becomes: - NEITHER that all FW's will "discard anyway" - NOR that all FW's will accept packets "in all cases" when Hdr type is = marked as skippable (00) =20 - BUT that FW's, load balancers, etc., MAY accept packets containing new = header types marked as skippable. =20 Without the draft, it is impossible to skip a header of a new type, and = to process subsequent headers for whatever policy applies to them. The draft introduces a new flexibility for those who are interested in = using it, and it won't do any harm to others. (In particular, vendors of FW's who prefer to always discard packets = containing all unknown header types MAY continue to do so.) Diversity and experience of authors of this draft shows that, even if = some others aren't interested, there is a demand.. I therefore support quick adoption of this draft. Regards, RD=20 From narten@us.ibm.com Mon Jan 17 08:24: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 8F9343A6BA3 for ; Mon, 17 Jan 2011 08:24:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.599 X-Spam-Level: X-Spam-Status: No, score=-105.599 tagged_above=-999 required=5 tests=[AWL=1.000, 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 k36uCD8YQpEL for ; Mon, 17 Jan 2011 08:24:10 -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 8D0343A6B94 for ; Mon, 17 Jan 2011 08:24:10 -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 p0HG8voZ010408 for ; Mon, 17 Jan 2011 11:09:17 -0500 Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234]) by d01dlp02.pok.ibm.com (Postfix) with ESMTP id 1EC014DE803B for ; Mon, 17 Jan 2011 11:23:21 -0500 (EST) Received: from d03av04.boulder.ibm.com (d03av04.boulder.ibm.com [9.17.195.170]) by d01relay02.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id p0HGQXbq426982 for ; Mon, 17 Jan 2011 11:26:34 -0500 Received: from d03av04.boulder.ibm.com (loopback [127.0.0.1]) by d03av04.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id p0HGQWDP021337 for ; Mon, 17 Jan 2011 09:26:33 -0700 Received: from cichlid.raleigh.ibm.com (sig-9-49-155-109.mts.ibm.com [9.49.155.109]) by d03av04.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id p0HGQVMs021115 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 17 Jan 2011 09:26:32 -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 p0HGQTvU002982; Mon, 17 Jan 2011 11:26:30 -0500 Message-Id: <201101171626.p0HGQTvU002982@cichlid.raleigh.ibm.com> To: Brian Haberman Subject: Re: 6MAN WG Last Call: draft-ietf-6man-flow-ecmp-00.txt In-reply-to: <4D272FAC.70104@innovationslab.net> References: <4D272FAC.70104@innovationslab.net> Comments: In-reply-to Brian Haberman message dated "Fri, 07 Jan 2011 10:22:20 -0500." Date: Mon, 17 Jan 2011 11:26:29 -0500 From: Thomas Narten X-Content-Scanned: Fidelis XPS MAILER Cc: Bob Hinden , 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, 17 Jan 2011 16:24:12 -0000 Here is my review of the ECMP document. I don't think it is quite ready for advancement yet. I do generally support this document, though there are some clarifications I need to understand. The review is rather lengthy, and is mostly editorial but there is some stuff that may turn out to be substantive. > When several network paths between the same two nodes are known by > the routing system to be equally good (in terms of capacity and > latency), it may be desirable to share traffic among them. Two > such The document seems to focus on "equal cost" paths, but I assume that the applicability is really when you have multiple paths that you want to distribute traffic across. They may be equal cost, but they may not be. For instance, if I have two links, one with double the capacity as another, I may want to distributed the traffic in a weighted fashion (i.e., 1/3 vs. 2/3s). Would be good to make that clear. I.e., rather than say "equal distribution", make clear that other types (weighted, etc.) are also covered. Later in the document, the term "load distribution" is used, which is I think closer to the mark. (This distinction should be clarified throughout.) > o Work-conserving method (no idle time when queue is non-empty). Do we really need to use the term "work conserving?" (I had to go look it up). I don't think it's particularly helpful to use that term in this document. > One lightweight approach to ECMP or LAG is this: if there are N > equally good paths to choose from, then form a modulo(N) hash > [RFC2991] from a consistent set of fields in each packet header, and > use the resulting value to select a particular path. If the hash make clear the "consistent set of fields" means that the contents of those fields are invariant for packets of the same flow. > use the resulting value to select a particular path. If the hash > function is chosen so that the hash values have a uniform statistical > distribution, this method will share traffic roughly equally between For "hash values", I assume this means the "output of the hash" (not the inputs). Perhaps make that more clear? (And it's probably better to say "output" than "value" generally.) The question with such a method, then, is which IP header fields to include to identify a flow. A minimal choice in the routing system is simply to use a hash of the source and destination IP addresses, i.e., the 2-tuple. This is necessary and sufficient to avoid out-of- order delivery, and with a wide variety of sources and destinations, as one finds in the core of the network, sometimes sufficient to achieve work-conserving load sharing. I'd suggest starting this paragraph as a new section, entitled something like "Choice of IP Header Fields for Hash Input". Also, this new section might benefit from some reorganization. Most of the info here is good, but the flow could be better. For example, after the above paragraph would be a good time to go into more detail about why using just the src/dst is insufficient in practice. The mailing list discussion talked alot about tunneled protocols being the real problem (and how tunneling is increasing). Real examples of how in practice this is inadequate would strengthen the motivation for this document. You talk about this further down, but saying it here (all in one place) might be good. Then move on to using 5 tuples, and again describe the limitations and problems. I think it is critical in this part to justify why the existing practice as used in IPv4 today is not sufficient for IPv6. I.e,. why redefining the Flow Label is *necessary* rather than possibly just that is possibly *nice to have*. However, including transport layer information as input keys to a hash may be a problem for IPv4 fragments [RFC2991]. In addition, Yes, but is that relevant to IPv6? (If so, say so, otherwise, the point is presumably irrelevant.) > hash may be a problem for IPv4 fragments [RFC2991]. In addition, > protocol and destination port numbers in the hash will not only make > the hash slightly more expensive to compute, but will not > particularly improve the hash distribution, due to the prevalence of > well known port numbers and popular protocol numbers. Ephemeral > ports, on the other hand, are quite well distributed [Lee10]. In the I disagree with the latter part of the the above. It seems to me that including port numbers (absent tunneling) will certainly improve the hash distribution. It is not a requirement that the input to the hash be uniformly distributed. A good hash will produce a good output distribution, even if the input is skewed. You seem to be making the assumption that if the ports are not distributed, the outputs of the hash wont be distributed either. I do not believe that is true generally. well known port numbers and popular protocol numbers. Ephemeral ports, on the other hand, are quite well distributed [Lee10]. In the And since most flows use one well-known port and one ephemeral port, using both ports as input would seem to give you good properties. Right? In which case the suggestion that using ports isn't good isn't true. In the case of IPv6, protocol numbers are particularly inconvenient due to the variable placement of and variable length of next-headers. In How many of these next headers exist in practice today? I.e., is this a real problem, or a theoretical problem? the variable placement of and variable length of next-headers. In addition, [RFC2460] recommends that all next-headers, except hop-by- hop options, should not be inspected by intermediate nodes in the network, presumably to make introduction of new next-headers more straightforward. Which text in 2460 is being referred to here? I'm not sure I agree with the last part of the sentence. The situation is different in tunneled scenarios. Identifying a flow inside the tunnel is more complicated, particularly because nearly all hardware can only identify flows based on information contained in the outermost IP header. Assume that traffic from many sources to many destinations is aggregated in a single IP-in-IP tunnel from try for IPinIP, but what about GRE with keys? achieved. If there is much tunnel traffic, this will result in a high probability of congestion on one of the paths between R1 and R2. Not necessarily true. Better to just say traffic won't be distributed as intended. That may or may not result in congestion. Also, for IPv6, the total number of bits in the 5-tuple is quite large (296), as well as inconvenient to extract due to the next- header placement. This may be challenging for some hardware implementations, raising the potential that network equipment vendors might sacrifice the length of the fields extracted from an IPv6 I disagree with some of the above. First, 256 bits comes just from the source/dest addresses. another 40 bits is noise relative to this in terms of "number of bits". I.e., saying a 5 tuple is too many bits, but just the src/addr (possibly with the Flow Label) is OK doesn't make sense to me. The argument about accessing the fields seems more compelling and should be made separately. header. The question therefore arises whether the 20-bit flow label in IPv6 packets would be suitable for use as input to an ECMP or LAG hash algorithm. If it could be used in place of the port numbers and protocol number in the 5-tuple, the hash calculation would be simplified. I think the stronger argument here is that it is more likely that a sender could set the Flow Label to a useful value here in cases like tunneling, where the intermediate routers in practice would not have access to the port numbers in in the inner header. The good think is that TEP's can do this today without requiring any changes in existing specs. would it do any harm to the distribution of the hash values. If the community at some stage agrees to set pseudo-random flow labels in the majority of traffic flows, this would add to the value of the hash. I'm confused. Isn't the latter exactly what this document is recommending??? source to the destination(s)." The RFC should perhaps have made clear that a router that has participated in flow state establishment can rely on properties of the resulting flow label values without further signaling. If a router knows these properties, rule 2 is Right. This is my understanding of what the words should have meant. In the tunneling situation sketched above, routers R1 and R2 can rely on the flow labels set by TEP A and TEP B being assigned by a known method. This allows a safe ECMP or LAG method to be based on the flow label without breaching [RFC3697]. Technically, this is only true for those flows that the TEP has set. It is not true for all flows generally, and presumably that is what R1 and R2 would be assuming... Also, I do not believe that including the Flow Label bits as an input key to ECMP violates 3697 at all. What text does this violate? At the time of this writing, the IETF is discussing a possible revision of the rules of RFC 3697 [I-D.ietf-6man-flow-update]. If adopted, that revision would be fully compatible with the present document and would obviate much of the above discussion. This wording seems odd, since the ID cited does not carry any weight and does not update 3697. o The flow label in the outer packet SHOULD be set by the sending TEP to a pseudo-random 20-bit value in accordance with [RFC3697]. pseudo random is not right here. This is a bit of a divergence, but I do not believe it is a requirement that the someone who sets the Flow Label set it to a psuedo-random value. Please clarify *why* this needs to be a SHOULD. Who benefits? There was email discussion about this. Routers can't assume they will be pseudo-random, otherwise they set themselves up for DOS attacks. So why is this necessary? as determined by the IP header fields of the inner packet. * Note that this rule is a SHOULD rather than a MUST, to permit individual implementers to take an alternative approach if they wish to do so. Such an alternative MUST conform to [RFC3697]. Please clarify what type of an exception you are trying to allow for. I need to understand the thinking before agreeing to allow for this. :-) o The sending TEP MUST classify all packets into flows, once it has determined that they should enter a given tunnel, and then write the relevant flow label into the outer IPv6 header. A user flow could be identified by the ingress TEP most simply by its {destination, source} address pair (coarse) or by its 5-tuple {dest addr, source addr, protocol, dest port, source port} (fine). Isn't it ironic that you don't include the Flow Label here? I.e., if the user sets the Flow Label, you don't use its value? That doesn't seem right! :-) This is an implementation detail in the sending TEP. * It might be possible to make this classifier stateless, by using a suitable 20 bit hash of the inner IP header's 2-tuple or 5-tuple as the pseudo-random flow label value. Doesn't this go against the 3697 requirement not to reuse a value? The issue I have with this is that it does mean some base assumptions about Flow Labels no longer hold in general. This may or may not be a problem, but we should speak to this point directly. I.e, this specification is proposing some possibly non-backwards compatable changes to the Flow Label semantics. o At intermediate router(s) that perform load distribution of tunneled packets whose source address is a TEP, the hash algorithm used to determine the outgoing component-link in an ECMP and/or LAG toward the next-hop MUST minimally include the triple {dest addr, source addr, flow label} to meet the [RFC3697] rules. The wording here is awkward. It seems to suggest that you only expect routers to do this for tunneled packets? How will they know which packets those are? Sounds inefficient and requiring of configuration... In practice, won't they just do this for all packets? If so, the wording above seems convoluted... or trying to make something legal if implementations do X, knowing full well they won't in practice. Also, which 3697 rules are being referred to above? How is it a violation of an existing standard to do ECMP on just the src/dst fields? * Intermediate router(s) MAY also include {protocol, dest port, source port} as input keys to the ECMP and/or LAG hash algorithms, to provide sufficient entropy in cases where the flow-label is currently set to zero. Seems like this should be a SHOULD. It never hurts to include these fields, and in many cases helps. To keep things simple, shouldn't the default be just to use the 6 tuple (when available) as input to the hash? 4. Security Considerations The flow label is not protected in any way and can be forged by an on-path attacker. Off-path attackers are unlikely to guess a valid flow label if a pseudo-random value is used. In either case, the worst an attacker could do against ECMP or LAG is to attempt to selectively overload a particular path. For further discussion, see [RFC3697]. This section seem weak, though I need to think a bit about what it should say. From narten@us.ibm.com Mon Jan 17 09:06: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 26C0528C145 for ; Mon, 17 Jan 2011 09:06:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.932 X-Spam-Level: X-Spam-Status: No, score=-105.932 tagged_above=-999 required=5 tests=[AWL=0.667, 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 kQ4FyqulCX-o for ; Mon, 17 Jan 2011 09:06:41 -0800 (PST) Received: from e32.co.us.ibm.com (e32.co.us.ibm.com [32.97.110.150]) by core3.amsl.com (Postfix) with ESMTP id 3A0B028C132 for ; Mon, 17 Jan 2011 09:06:41 -0800 (PST) Received: from d03relay01.boulder.ibm.com (d03relay01.boulder.ibm.com [9.17.195.226]) by e32.co.us.ibm.com (8.14.4/8.13.1) with ESMTP id p0HGx6jX006472 for ; Mon, 17 Jan 2011 09:59:06 -0700 Received: from d03av03.boulder.ibm.com (d03av03.boulder.ibm.com [9.17.195.169]) by d03relay01.boulder.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id p0HH91x6173878 for ; Mon, 17 Jan 2011 10:09:02 -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 p0HH90ix011453 for ; Mon, 17 Jan 2011 10:09:01 -0700 Received: from cichlid.raleigh.ibm.com (sig-9-49-155-109.mts.ibm.com [9.49.155.109]) by d03av03.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id p0HH8xxI011427 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 17 Jan 2011 10:09:00 -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 p0HH8wp8003176; Mon, 17 Jan 2011 12:08:58 -0500 Message-Id: <201101171708.p0HH8wp8003176@cichlid.raleigh.ibm.com> To: Christian Huitema Subject: Re: Psuedo-randomness in flow labels [was Re: [Fwd: I-D Action:draft-ietf-6man-flow-update-00.txt]] In-reply-to: References: <4CF82E6F.9040309@gmail.com> <4D08165A.3060306@gmail.com> <51661CE4-EC60-46B9-928C-D5763CFDF318@cisco.com> <4D082147.9010209@gmail.com> <4D2A1B84.1020003@gmail.com> <4D2A64A1.4030400@gmail.com> <201101101410.p0AEAPNs007778@cichlid.raleigh.ibm.com> Comments: In-reply-to Christian Huitema message dated "Mon, 10 Jan 2011 19:26:00 +0000." Date: Mon, 17 Jan 2011 12:08:58 -0500 From: Thomas Narten Cc: 6man , Brian E Carpenter , Fred Baker 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, 17 Jan 2011 17:06:42 -0000 Christian Huitema writes: > Have you looked at the security implications? Suppose that an > attacker can predict the hash algorithm used by a router. This > attacker could then pick "interesting" values of the flow ID, to get > the flow of traffic directed to particular paths, or not. For > example, they could systematically but a different flow label to > each packet to ensure the traffic is spread over all available > paths. Thinking about this some more. There are two cases to worry about. The first one concerns the (currently mythical) case where a flow setup protocol has been used to create state/reservations along a path for a particular Flow. An attacker might want to target that precise flow in order to cause problems for that one flow (e.g, exceed its flow spec). The attacker would presumably need to determine the src/dst/flow label value of a particular flow in order to exploit this. Since flow setup is involved, presumably the Flow Label value can be choosen somewhat carefully to make this harder for off-path attackers. This case is presumably also not really a relevant to the current discussion. The second case concerns a number of paths across which traffic is to be split. An attacker might want to overload a particular path. One way to do this is to guess the Flow Labels being used for ECMP. But it seems like there is an even easier way. If there are N paths, whatever hash is used will distribute over those N paths. So all an attacker needs to do is generate src/dest/Flow IDs and probe the network to see which paths are actually being used. And then generate lots of traffic to target the particular path they are after. (Rereading the thread I see now that Fred made this same point.) The point being, an attacker doesn't have to guess the actual Flow Labels that are being in use, but just come up with way to generate traffic that ECMP maps onto the target path. That suggests that having Flow Label values themselves be "pseudo random" doesn't buy a whole lot. Or am I missing something? I'm a bit stuck on this point, because both of the current flow label document continue to say flow labels should be generated SHOULD be psuedo-random, and I'm not convinced this is necessary, required, or buys us anything. What compelling argument am I missing? Thomas From narten@us.ibm.com Mon Jan 17 09:26: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 F3C7428C1B1 for ; Mon, 17 Jan 2011 09:26:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.099 X-Spam-Level: X-Spam-Status: No, score=-106.099 tagged_above=-999 required=5 tests=[AWL=0.500, 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 FY06HS8VrRTd for ; Mon, 17 Jan 2011 09:26:37 -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 89E1828C1A5 for ; Mon, 17 Jan 2011 09:26:37 -0800 (PST) Received: from d01dlp01.pok.ibm.com (d01dlp01.pok.ibm.com [9.56.224.56]) by e4.ny.us.ibm.com (8.14.4/8.13.1) with ESMTP id p0HHAQbP028926 for ; Mon, 17 Jan 2011 12:11:11 -0500 Received: from d01relay03.pok.ibm.com (d01relay03.pok.ibm.com [9.56.227.235]) by d01dlp01.pok.ibm.com (Postfix) with ESMTP id 8E949728A09 for ; Mon, 17 Jan 2011 12:19:53 -0500 (EST) Received: from d01av02.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by d01relay03.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id p0HHJrgQ331892 for ; Mon, 17 Jan 2011 12:19:53 -0500 Received: from d01av02.pok.ibm.com (loopback [127.0.0.1]) by d01av02.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id p0HHJqsq022691 for ; Mon, 17 Jan 2011 15:19:53 -0200 Received: from cichlid.raleigh.ibm.com (sig-9-49-155-109.mts.ibm.com [9.49.155.109]) by d01av02.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id p0HHJpO7022613 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 17 Jan 2011 15:19:52 -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 p0HHJox8003240; Mon, 17 Jan 2011 12:19:51 -0500 Message-Id: <201101171719.p0HHJox8003240@cichlid.raleigh.ibm.com> To: Bob Hinden Subject: Re: 6MAN WG Last Call: In-reply-to: References: Comments: In-reply-to Bob Hinden message dated "Sun, 16 Jan 2011 17:31:40 -0800." Date: Mon, 17 Jan 2011 12:19:50 -0500 From: Thomas Narten X-Content-Scanned: Fidelis XPS MAILER Cc: Brian Haberman , 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, 17 Jan 2011 17:26:39 -0000 I admit to only recently jumping into this discussion and gettng caught up on the various drafts, but why are we doing this document? > Title : Update to the IPv6 flow label specification That is the title, but it doesn't update anything at all. It says this explicitly. It says: The intention of this document is to explain this in more detail and to propose changes to RFC 3697 intended to remove the uncertainties and encourage active usage of the flow label. It does not formally update RFC 3697. So we now publish as RFCs proposals to make changes to standards track documents, without actually making a change? This seems like it will confuse the community. Seems to me that if we do not formally clarify the preceding documents (if they need clarifying), we are wasting our time, and that there really isn't a problem here that needs fixing. And in looking at draft-ietf-6man-flow-ecmp-00.txt (also in WGLC), that document is a BCP and does not update any of the previous Flow Label documents. If we need to update the Flow Label specs, we should do so, and this document could be part of that or a rational for the changes. But absent any changes to the existing standards, I am not comfortable with publishing this document. Thomas From huitema@microsoft.com Mon Jan 17 11:24: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 2A5F33A6E5D for ; Mon, 17 Jan 2011 11:24:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.413 X-Spam-Level: X-Spam-Status: No, score=-10.413 tagged_above=-999 required=5 tests=[AWL=0.186, 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 mGtoU0aj-1ai for ; Mon, 17 Jan 2011 11:24:47 -0800 (PST) Received: from smtp.microsoft.com (mail2.microsoft.com [131.107.115.215]) by core3.amsl.com (Postfix) with ESMTP id 4113A3A6DCE for ; Mon, 17 Jan 2011 11:24:47 -0800 (PST) Received: from TK5EX14MLTC103.redmond.corp.microsoft.com (157.54.79.174) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.2.176.0; Mon, 17 Jan 2011 11:27:15 -0800 Received: from TK5EX14MLTW651.wingroup.windeploy.ntdev.microsoft.com (157.54.71.39) by TK5EX14MLTC103.redmond.corp.microsoft.com (157.54.79.174) with Microsoft SMTP Server (TLS) id 14.1.255.3; Mon, 17 Jan 2011 11:27:16 -0800 Received: from TK5EX14MBXW653.wingroup.windeploy.ntdev.microsoft.com ([169.254.3.137]) by TK5EX14MLTW651.wingroup.windeploy.ntdev.microsoft.com ([157.54.71.39]) with mapi; Mon, 17 Jan 2011 11:27:14 -0800 From: Christian Huitema To: Thomas Narten Subject: RE: Psuedo-randomness in flow labels [was Re: [Fwd: I-D Action:draft-ietf-6man-flow-update-00.txt]] Thread-Topic: Psuedo-randomness in flow labels [was Re: [Fwd: I-D Action:draft-ietf-6man-flow-update-00.txt]] Thread-Index: AQHLtmlUoawGkf1OeU6e726Ghp0jZZPVixNA Date: Mon, 17 Jan 2011 19:27:14 +0000 Message-ID: References: <4CF82E6F.9040309@gmail.com> <4D08165A.3060306@gmail.com> <51661CE4-EC60-46B9-928C-D5763CFDF318@cisco.com> <4D082147.9010209@gmail.com> <4D2A1B84.1020003@gmail.com> <4D2A64A1.4030400@gmail.com> <201101101410.p0AEAPNs007778@cichlid.raleigh.ibm.com> <201101171708.p0HH8wp8003176@cichlid.raleigh.ibm.com> In-Reply-To: <201101171708.p0HH8wp8003176@cichlid.raleigh.ibm.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 Cc: 6man , Brian E Carpenter , Fred Baker 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, 17 Jan 2011 19:24:48 -0000 Thomas Narten wrote: > I'm a bit stuck on this point, because both of the current flow label doc= ument=20 > continue to say flow labels should be generated SHOULD be pseudo-random,= =20 > and I'm not convinced this is necessary, required, or buys us anything.=20 > What compelling argument am I missing? I agree. The network routers should not trust that the flow label has any p= articular randomness properties, because misplaced trust would open a path = for attacks. Having the randomness requirement in the spec would only encou= rage routers to make the wrong security assumptions. -- Christian Huitema From narten@us.ibm.com Mon Jan 17 11:30:03 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 9FA5A3A6E59 for ; Mon, 17 Jan 2011 11:30:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.199 X-Spam-Level: X-Spam-Status: No, score=-106.199 tagged_above=-999 required=5 tests=[AWL=0.400, 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 HkHaYivuVjuz for ; Mon, 17 Jan 2011 11:30:01 -0800 (PST) Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.141]) by core3.amsl.com (Postfix) with ESMTP id 5AA103A6DCE for ; Mon, 17 Jan 2011 11:30:01 -0800 (PST) Received: from d01dlp01.pok.ibm.com (d01dlp01.pok.ibm.com [9.56.224.56]) by e1.ny.us.ibm.com (8.14.4/8.13.1) with ESMTP id p0HJLXae023591 for ; Mon, 17 Jan 2011 14:23:41 -0500 Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234]) by d01dlp01.pok.ibm.com (Postfix) with ESMTP id 008D3728061 for ; Mon, 17 Jan 2011 14:32:35 -0500 (EST) Received: from d03av04.boulder.ibm.com (d03av04.boulder.ibm.com [9.17.195.170]) by d01relay02.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id p0HJWYb7427698 for ; Mon, 17 Jan 2011 14:32:34 -0500 Received: from d03av04.boulder.ibm.com (loopback [127.0.0.1]) by d03av04.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id p0HJWXna016898 for ; Mon, 17 Jan 2011 12:32:34 -0700 Received: from cichlid.raleigh.ibm.com (sig-9-49-155-109.mts.ibm.com [9.49.155.109]) by d03av04.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id p0HJWVhp016737 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 17 Jan 2011 12:32:33 -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 p0HJWU58003756; Mon, 17 Jan 2011 14:32:31 -0500 Message-Id: <201101171932.p0HJWU58003756@cichlid.raleigh.ibm.com> To: Bob Hinden Subject: Re: 6MAN WG Last Call: In-reply-to: <7B63F7B6-D788-4A05-9722-C1CAAA42B754@gmail.com> References: <7B63F7B6-D788-4A05-9722-C1CAAA42B754@gmail.com> Comments: In-reply-to Bob Hinden message dated "Thu, 16 Dec 2010 17:30:26 -0800." Date: Mon, 17 Jan 2011 14:32:30 -0500 From: Thomas Narten X-Content-Scanned: Fidelis XPS MAILER Cc: Brian Haberman , 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, 17 Jan 2011 19:30:04 -0000 6man: The LC on this document supposedly ended on Jan 6, but it's pretty obvious that there haven't been enough reviews yet to convince me that the document has received sufficient review to move forward. Now that we're past the holiday seasons, how about a few more reviews? Thanks! Thomas > All, > 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. > Note, while not indicated in the draft the intent for this document > is to obsolete RFC4294. The next version will show this more > clearly. > Regards, > Bob Hinden & Brian Haberman > 6MAN Chairs > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From shane@castlepoint.net Mon Jan 17 11:53: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 1607328C174 for ; Mon, 17 Jan 2011 11:53:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.57 X-Spam-Level: X-Spam-Status: No, score=-2.57 tagged_above=-999 required=5 tests=[AWL=0.029, 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 wONxPZbNJCaQ for ; Mon, 17 Jan 2011 11:53:20 -0800 (PST) Received: from dog.tcb.net (dog.tcb.net [64.78.150.133]) by core3.amsl.com (Postfix) with ESMTP id 141573A6E0A for ; Mon, 17 Jan 2011 11:53:20 -0800 (PST) Received: by dog.tcb.net (Postfix, from userid 0) id E1B872684EA; Mon, 17 Jan 2011 12:55:54 -0700 (MST) Received: from host2.tcb.net (64.78.235.218 [64.78.235.218]) (authenticated-user smtp) (TLSv1/SSLv3 AES128-SHA 128/128) by dog.tcb.net with SMTP; Mon, 17 Jan 2011 12:55:54 -0700 (MST) (envelope-from shane@castlepoint.net) X-Avenger: version=0.7.8; receiver=dog.tcb.net; client-ip=64.78.235.218; client-port=50459; data-bytes=0 Subject: Re: Psuedo-randomness in flow labels [was Re: [Fwd: I-D Action:draft-ietf-6man-flow-update-00.txt]] Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Shane Amante In-Reply-To: <201101171708.p0HH8wp8003176@cichlid.raleigh.ibm.com> Date: Mon, 17 Jan 2011 12:55:53 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4CF82E6F.9040309@gmail.com> <4D08165A.3060306@gmail.com> <51661CE4-EC60-46B9-928C-D5763CFDF318@cisco.com> <4D082147.9010209@gmail.com> <4D2A1B84.1020003@gmail.com> <4D2A64A1.4030400@gmail.com> <201101101410.p0AEAPNs007778@cichlid.raleigh.ibm.com> <201101171708.p0HH8wp8003176@cichlid.raleigh.ibm.com> To: Thomas Narten X-Mailer: Apple Mail (2.1082) Cc: Christian Huitema , 6man , Brian E Carpenter , Fred Baker 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, 17 Jan 2011 19:53:21 -0000 Thomas, On Jan 17, 2011, at 10:08 MST, Thomas Narten wrote: [--snip--] > The second case concerns a number of paths across which traffic is to > be split. An attacker might want to overload a particular path. One > way to do this is to guess the Flow Labels being used for ECMP. But it > seems like there is an even easier way. If there are N paths, whatever > hash is used will distribute over those N paths. So all an attacker > needs to do is generate src/dest/Flow IDs and probe the network to see > which paths are actually being used. And then generate lots of traffic > to target the particular path they are after. (Rereading the thread I > see now that Fred made this same point.) This type of attack is likely insignificant in the real-world, at least = for links within the Backbone. Let's keep in mind that a victim's = traffic (assuming it's well-behaved) will already, automatically be = spread across a large number of component-links in a ECMP/LAG group. = Thus, if an attacker were either patient enough or had the appropriate = HW to generate the right traffic pattern congest a single link in that = ECMP/LAG group, then it would only affect a, possibly small, percentage = of the overall traffic toward a particular victim -- it depends on how = many component-links are in the particular LAG/ECMP group. Instead, = it's much more straightforward for an attacker to [easily] acquire = several hundred/thousand/etc. bots and congest the small-ish access = circuit(s) that are closest to the victim/destination, (i.e.: from PE -> = CE) ... or use application-level attacks on the servers, etc. As you = get closer to the victim/destination LAG/ECMP is less likely to be used, = which is why it's an easier place to attack. > The point being, an attacker doesn't have to guess the actual Flow > Labels that are being in use, but just come up with way to generate > traffic that ECMP maps onto the target path. That suggests that having > Flow Label values themselves be "pseudo random" doesn't buy a whole > lot. >=20 > Or am I missing something? >=20 > I'm a bit stuck on this point, because both of the current flow label > document continue to say flow labels should be generated SHOULD be > psuedo-random, and I'm not convinced this is necessary, required, or > buys us anything. What compelling argument am I missing? Fernando Gont (and, Steve Blake) have been proposing using the = flow-label as a security mechanisms for hosts to prevent off-path = spoofing attacks. However, to successfully implement/deploy this, you = need the pseudo-random flow-labels: Therefore, the Flow Label should be obfuscated so that the chances of an off-path attacker of guessing the Flow Label of future flows are reduced. http://tools.ietf.org/html/draft-gont-6man-flowlabel-security-01 So, why not take the opportunity to use the flow-label to reduce the = attack surface of IPv6, (compared to v4)? Does that help? -shane= From slblake@petri-meat.com Mon Jan 17 12:12: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 151DC28C168 for ; Mon, 17 Jan 2011 12:12:27 -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 1qYP9a4Xhhi3 for ; Mon, 17 Jan 2011 12:12:26 -0800 (PST) Received: from elom.tchmachines.com (elom.tchmachines.com [208.76.80.198]) by core3.amsl.com (Postfix) with ESMTP id 21A4928C112 for ; Mon, 17 Jan 2011 12:12:26 -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 1PevTb-0004oy-9H; Mon, 17 Jan 2011 15:14:55 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Date: Mon, 17 Jan 2011 16:14:55 -0400 From: Steven Blake To: Shane Amante Subject: Re: Psuedo-randomness in flow labels [was Re: [Fwd: I-D Action:draft-ietf-6man-flow-update-00.txt]] In-Reply-To: References: <4CF82E6F.9040309@gmail.com> <4D08165A.3060306@gmail.com> <51661CE4-EC60-46B9-928C-D5763CFDF318@cisco.com> <4D082147.9010209@gmail.com> <4D2A1B84.1020003@gmail.com> <4D2A64A1.4030400@gmail.com> <201101101410.p0AEAPNs007778@cichlid.raleigh.ibm.com> <201101171708.p0HH8wp8003176@cichlid.raleigh.ibm.com> Message-ID: <13d900167d216c3a4adac67abf79f7a5@petri-meat.com> 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: 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: Mon, 17 Jan 2011 20:12:27 -0000 On Mon, 17 Jan 2011 12:55:53 -0700, Shane Amante wrote: > Thomas, > > On Jan 17, 2011, at 10:08 MST, Thomas Narten wrote: >> The point being, an attacker doesn't have to guess the actual Flow >> Labels that are being in use, but just come up with way to generate >> traffic that ECMP maps onto the target path. That suggests that >> having >> Flow Label values themselves be "pseudo random" doesn't buy a whole >> lot. >> >> Or am I missing something? >> >> I'm a bit stuck on this point, because both of the current flow >> label >> document continue to say flow labels should be generated SHOULD be >> psuedo-random, and I'm not convinced this is necessary, required, or >> buys us anything. What compelling argument am I missing? > > Fernando Gont (and, Steve Blake) have been proposing using the > flow-label as a security mechanisms for hosts to prevent off-path > spoofing attacks. However, to successfully implement/deploy this, > you > need the pseudo-random flow-labels: > Therefore, the Flow Label should be obfuscated so that > the chances of an off-path attacker of guessing the Flow Label of > future flows are reduced. > http://tools.ietf.org/html/draft-gont-6man-flowlabel-security-01 > > So, why not take the opportunity to use the flow-label to reduce the > attack surface of IPv6, (compared to v4)? I am not pushing the flow label nonce proposal anymore. I understand that there is a lot of deployed gear that uses CRC16 or CRC32 to compute ECMP/LAG hashes. To the extent that this gear can be configured to use flow labels in the hash key (rather that protocol/ports), I also understand that these CRC algorithms are not great hash functions (i.e., they lack an avalanche effect), although I haven't examined this myself. Setting the flow label using a non-repeating PRNG (*) makes it (slightly?) more likely that one's traffic will experience a good load split. I can't think of a reason at the moment why this should be mandatory, though. (*) This can be achieved using an array of maximum-sequence 20-bit LFSRs, rather than an array of 20-bit counters as in Fernando's draft. Regards, // Steve From brian.e.carpenter@gmail.com Mon Jan 17 12:36: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 1974E28C1EE for ; Mon, 17 Jan 2011 12:36:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.43 X-Spam-Level: X-Spam-Status: No, score=-103.43 tagged_above=-999 required=5 tests=[AWL=0.169, 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 wUlt3025q31J for ; Mon, 17 Jan 2011 12:36:14 -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 D00F228C168 for ; Mon, 17 Jan 2011 12:36:13 -0800 (PST) Received: by fxm9 with SMTP id 9so7091307fxm.31 for ; Mon, 17 Jan 2011 12:38: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=E4o6XGDut7/+HYKmmUHJm6BqyEEzA5UNd8T2umLBxRs=; b=RDW1PZvv/8VovWL4s39/cOgcrXIr2+yiPU8jMfPVQg+vCSzbrbWgwLs8784rzvHTwa d5xFTd5HYxMBg8MI9WfUGPtPo0b2ZsY4UxR2JRgAIaioLRUCw+P2HbmO9+aeD8WZR6/e J23gqQg6/OeWQKX5eRjyd6RrJACaX74MOXkls= 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=kAXa0kKhMndWXkjUJ51VntWosIJLaUSOFgGIYw5ifVAl0y2jTPSJ/+hUuhUyqez9sk a1fkipTE3S2lEkyXDvgNy9Y3UNdOzqRx7NcakKj9N7EyMBeeSpLKz0UZNgNk/La/AWcU oFIwZ+3qaN6AIiGovCwKcSSC5DiK6Wp59pcGs= Received: by 10.223.79.7 with SMTP id n7mr2946081fak.71.1295296728233; Mon, 17 Jan 2011 12:38:48 -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 c11sm1846882fav.2.2011.01.17.12.38.44 (version=SSLv3 cipher=RC4-MD5); Mon, 17 Jan 2011 12:38:47 -0800 (PST) Message-ID: <4D34A8C7.5070107@gmail.com> Date: Tue, 18 Jan 2011 09:38:31 +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: 6MAN WG Last Call: References: <201101171719.p0HHJox8003240@cichlid.raleigh.ibm.com> In-Reply-To: <201101171719.p0HHJox8003240@cichlid.raleigh.ibm.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: 6man Mailing List , Brian Haberman , 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: Mon, 17 Jan 2011 20:36:15 -0000 Thomas, On 2011-01-18 06:19, Thomas Narten wrote: > I admit to only recently jumping into this discussion and gettng > caught up on the various drafts, but why are we doing this document? > >> Title : Update to the IPv6 flow label specification > > That is the title, but it doesn't update anything at all. It says this > explicitly. It says: > > The intention of this document is to explain this in more detail and > to propose changes to RFC 3697 intended to remove the uncertainties > and encourage active usage of the flow label. It does not formally > update RFC 3697. > > So we now publish as RFCs proposals to make changes to standards track > documents, without actually making a change? This seems like it will > confuse the community. > > Seems to me that if we do not formally clarify the preceding documents > (if they need clarifying), we are wasting our time, and that there > really isn't a problem here that needs fixing. There's clearly a problem (20 unused bits and enormous confusion about how they could be used). And clearly the goal is 3697bis. The reason for this draft, as I believe we've discussed over some months, is to set the scene for 3697bis. Indeed we have two choices: 1) agree on the substance of the intended updates and publish them as a stake in the ground, then develop 3697bis. 2) agree on the substance of the intended updates (by means of the present WGLC), and then proceed directly to develop 3697bis. I understood that we'd agreed on 1) but the WG Chairs can tell me I'm wrong. > > And in looking at draft-ietf-6man-flow-ecmp-00.txt (also in WGLC), > that document is a BCP and does not update any of the previous Flow > Label documents. Correct. It doesn't need to; it is additional practice and the intention is to ensure that it's compatible both with 3697 and the eventual 3697bis. (I agree with your comment on that draft that the phrasing on this point is clumsy.) > If we need to update the Flow Label specs, we should do so, and this > document could be part of that or a rational for the changes. But > absent any changes to the existing standards, I am not comfortable > with publishing this document. I would be too, if it was the end of the road, but we have an author team all set to start on 3697bis once we have a clear consensus in the WG about the changes to be made. Can you propose text that is clearer than the following? (In the Abstract) This document describes and motivates proposed changes to the specification in order to clarify it, making it clear what types of usage are possible, and to introduce some additional flexibility. It does not formally update RFC 3697. (In the Introduction) The intention of this document is to explain this in more detail and to propose changes to RFC 3697 intended to remove the uncertainties and encourage active usage of the flow label. It does not formally update RFC 3697. Brian From brian.e.carpenter@gmail.com Mon Jan 17 13:00: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 60D9C28C17D for ; Mon, 17 Jan 2011 13:00:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.432 X-Spam-Level: X-Spam-Status: No, score=-103.432 tagged_above=-999 required=5 tests=[AWL=0.167, 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 OVuUn209FyxM for ; Mon, 17 Jan 2011 13:00:34 -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 3278928C155 for ; Mon, 17 Jan 2011 13:00:33 -0800 (PST) Received: by fxm9 with SMTP id 9so7114639fxm.31 for ; Mon, 17 Jan 2011 13:03:08 -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=bfyb9E9jgfBzD44SknwEGI+ZAubUd8AFwP1STlLqnD0=; b=UOK8OB6xv5frsr8Z6O8tR2l2fkioAdPcItwBqbmsRuKUbt/egKs+N4D+jB5tk9WUdN QM5HJVdTMNILJoUYgDY6ohhKjiy52RTfF9HYS6E4oMkRylJyZOMFSW7ObE0bPTaUBXDd 9PXqye7IctwB/ZWR1aDwXRcHe06DvDoawS16o= 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=ppDGi5oQ2+VFV2c6YabTXaM5dqvOXOphKLxzm1vizbvBNSDoQODDP0k9tRGc9ElLVr 4il53w6tLxdDtUinBOdfdFQNm3wL9xRF47Ef6+SBuHNgu4nGiKFv9WSLm6dqY+76+Cnn xA2Gb6Vqym+lACQUnGBF1nlDNKUyVMf37S3AA= Received: by 10.223.79.72 with SMTP id o8mr5218346fak.19.1295298188684; Mon, 17 Jan 2011 13:03:08 -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 f24sm1855189fak.24.2011.01.17.13.03.04 (version=SSLv3 cipher=RC4-MD5); Mon, 17 Jan 2011 13:03:07 -0800 (PST) Message-ID: <4D34AE7A.8060107@gmail.com> Date: Tue, 18 Jan 2011 10:02:50 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Christian Huitema Subject: Re: Psuedo-randomness in flow labels [was Re: [Fwd: I-D Action:draft-ietf-6man-flow-update-00.txt]] References: <4CF82E6F.9040309@gmail.com> <4D08165A.3060306@gmail.com> <51661CE4-EC60-46B9-928C-D5763CFDF318@cisco.com> <4D082147.9010209@gmail.com> <4D2A1B84.1020003@gmail.com> <4D2A64A1.4030400@gmail.com> <201101101410.p0AEAPNs007778@cichlid.raleigh.ibm.com> <201101171708.p0HH8wp8003176@cichlid.raleigh.ibm.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Thomas Narten , 6man , Fred Baker 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, 17 Jan 2011 21:00:35 -0000 On 2011-01-18 08:27, Christian Huitema wrote: > Thomas Narten wrote: > >> I'm a bit stuck on this point, because both of the current flow label document >> continue to say flow labels should be generated SHOULD be pseudo-random, >> and I'm not convinced this is necessary, required, or buys us anything. >> What compelling argument am I missing? > > I agree. The network routers should not trust that the flow label has any particular randomness properties, because misplaced trust would open a path for attacks. Having the randomness requirement in the spec would only encourage routers to make the wrong security assumptions. There are two, or possibly three, arguments for a "SHOULD" here: 1. The security argument, made in draft-gont-6man-flowlabel-security Obviously downstream nodes must not rely on this, but that in itself doesn't weaken the argument for pseudo-randomness. The draft says "Forwarding nodes such as routers and load balancers MUST NOT depend only on Flow Label values being randomly distributed." I find Christian's counter-argument strange; there are many places where foolish implementers can create security exposures. 2. The argument, that Thomas has disputed, that this provides better input to a load balancing hash. I'll debate that on another thread where Thomas has repeated his arguments. 3. The dubious argument that by recommending a *specific* method of setting the flow label, we increase the chances that implementers will actually do so. It's clear that the present recommendation is too weak in that respect. Brian From narten@us.ibm.com Mon Jan 17 13:16: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 89ADF28C1C9 for ; Mon, 17 Jan 2011 13:16:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.266 X-Spam-Level: X-Spam-Status: No, score=-106.266 tagged_above=-999 required=5 tests=[AWL=0.333, 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 4DBQZ0t0YSRF for ; Mon, 17 Jan 2011 13:16:56 -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 876493A6EDA for ; Mon, 17 Jan 2011 13:16:56 -0800 (PST) Received: from d01dlp02.pok.ibm.com (d01dlp02.pok.ibm.com [9.56.224.85]) by e7.ny.us.ibm.com (8.14.4/8.13.1) with ESMTP id p0HL0F39001869 for ; Mon, 17 Jan 2011 16:00:20 -0500 Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by d01dlp02.pok.ibm.com (Postfix) with ESMTP id 0C03A4DE8043 for ; Mon, 17 Jan 2011 16:16:06 -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 p0HLJJKN157200 for ; Mon, 17 Jan 2011 16:19:19 -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 p0HLJIT4006040 for ; Mon, 17 Jan 2011 14:19:19 -0700 Received: from cichlid.raleigh.ibm.com (sig-9-49-155-109.mts.ibm.com [9.49.155.109]) by d03av01.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id p0HLJHB4005973 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 17 Jan 2011 14:19:17 -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 p0HLJGOw005041; Mon, 17 Jan 2011 16:19:16 -0500 Message-Id: <201101172119.p0HLJGOw005041@cichlid.raleigh.ibm.com> To: Brian E Carpenter Subject: Re: 6MAN WG Last Call: In-reply-to: <4D34A8C7.5070107@gmail.com> References: <201101171719.p0HHJox8003240@cichlid.raleigh.ibm.com> <4D34A8C7.5070107@gmail.com> Comments: In-reply-to Brian E Carpenter message dated "Tue, 18 Jan 2011 09:38:31 +1300." Date: Mon, 17 Jan 2011 16:19:16 -0500 From: Thomas Narten X-Content-Scanned: Fidelis XPS MAILER Cc: 6man Mailing List , Brian Haberman , 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: Mon, 17 Jan 2011 21:16:57 -0000 > There's clearly a problem (20 unused bits and enormous confusion > about how they could be used). And clearly the goal is 3697bis. The > reason for this draft, as I believe we've discussed over some > months, is to set the scene for 3697bis. Indeed we have two choices: > 1) agree on the substance of the intended updates and publish them as a > stake in the ground, then develop 3697bis. > 2) agree on the substance of the intended updates (by means of the > present WGLC), and then proceed directly to develop 3697bis. I would find it helpful to see the proposed changes to 3697bis. If I don't see them, I can't tell for sure whether I agree with the justification for making changes. Also, if we want the justification to be correct, it needs to be in sync with the actual changes. If we publish the proposed changes first, and then make changes, we risk the two not being in sync (when people start discussing the actual changes and realize what is really at issue). Or we risk never actually getting agreement on the changes, and then flow-update ends up being the "end of the road". If we already know what changes will be made, please put them on the table and let's decide and move on. How big of a document are we talking about for the actual changes? > I would be too, if it was the end of the road, but we have an author > team all set to start on 3697bis once we have a clear consensus in > the WG about the changes to be made. What are those proposed changes? And can we guage consensus now, before publishing the documents? I don't like this idea that we say there is agreement on the proposed changes, but we don't actually know what they are. Thomas From bob.hinden@gmail.com Mon Jan 17 13:55: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 939E43A6F64 for ; Mon, 17 Jan 2011 13:55:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.391 X-Spam-Level: X-Spam-Status: No, score=-103.391 tagged_above=-999 required=5 tests=[AWL=0.208, 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 QO3PJfcOy1yI for ; Mon, 17 Jan 2011 13:55:46 -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 B0DC73A6C43 for ; Mon, 17 Jan 2011 13:55:46 -0800 (PST) Received: by pxi6 with SMTP id 6so1146175pxi.31 for ; Mon, 17 Jan 2011 13:58:22 -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=eIgkAZD8P4IS968CHnhDSZH3c6yxZwYEg6AQ3iT5hPE=; b=cDstu/kJsNZ7CVKrXi0pQMY1c7UcrZhnG78WZ5P6eMRkEfpUNjQFAQ7LuyYC59FjnM tcdKsFa525uWpbwlC4K6oLPft8MTLdWwDVwyap275qDLjxtIl+pTPGiIf+sFAjX21MiC woQyItGkFtaS3kv9gTm9mvUkTXENNHLckqvj8= 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=SdT7oDHvLNbx3YaoXw1wtPfer4K5GVdowIVFYFVh34Qu2E4/mjkS8WHZwqQK8zqHkT 9UoKdcrkQtNGW8KUobmfRu0jODuDTLxL5tfJ7GQzdoKsiX2Ny+TSltfaTT3A1FcvkgRB hpj+FZzw47Faq6K4R5ercEf6Def2vQKT1tjW8= Received: by 10.142.163.17 with SMTP id l17mr4288596wfe.260.1295301501994; Mon, 17 Jan 2011 13:58:21 -0800 (PST) Received: from [172.16.224.217] ([209.97.127.34]) by mx.google.com with ESMTPS id x35sm7114015wfd.1.2011.01.17.13.58.20 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 17 Jan 2011 13:58:20 -0800 (PST) Subject: Re: 6MAN WG Last Call: Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Bob Hinden In-Reply-To: <4D34A8C7.5070107@gmail.com> Date: Mon, 17 Jan 2011 13:58:19 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <201101171719.p0HHJox8003240@cichlid.raleigh.ibm.com> <4D34A8C7.5070107@gmail.com> To: Brian E Carpenter X-Mailer: Apple Mail (2.1082) Cc: Thomas Narten , 6man Mailing List , Brian Haberman , 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: Mon, 17 Jan 2011 21:55:47 -0000 Brian, >=20 > There's clearly a problem (20 unused bits and enormous confusion about > how they could be used). And clearly the goal is 3697bis. The reason = for > this draft, as I believe we've discussed over some months, is to set = the > scene for 3697bis. Indeed we have two choices: >=20 > 1) agree on the substance of the intended updates and publish them as = a > stake in the ground, then develop 3697bis. >=20 > 2) agree on the substance of the intended updates (by means of the > present WGLC), and then proceed directly to develop 3697bis. >=20 > I understood that we'd agreed on 1) but the WG Chairs can tell me I'm = wrong. After a short discussion, the chairs think that it would be preferable = to either have this document become an update to RFC3697 itself, or have = an RFC3697bis draft be written to be considered in parallel. In the = last case this draft would be the justification and background, and the = RFC3697bis draft would be an implementers spec (that is, what to do, not = why). I note that RFC3697 is only 9 pages long. Bob >=20 >>=20 >> And in looking at draft-ietf-6man-flow-ecmp-00.txt (also in WGLC), >> that document is a BCP and does not update any of the previous Flow >> Label documents. >=20 > Correct. It doesn't need to; it is additional practice and the = intention > is to ensure that it's compatible both with 3697 and the eventual = 3697bis. > (I agree with your comment on that draft that the phrasing on this > point is clumsy.) >=20 >> If we need to update the Flow Label specs, we should do so, and this >> document could be part of that or a rational for the changes. But >> absent any changes to the existing standards, I am not comfortable >> with publishing this document. >=20 > I would be too, if it was the end of the road, but we have an author > team all set to start on 3697bis once we have a clear consensus in > the WG about the changes to be made. Can you propose text that is > clearer than the following? >=20 > (In the Abstract) > This document describes and motivates proposed > changes to the specification in order to clarify it, making it clear > what types of usage are possible, and to introduce some additional > flexibility. It does not formally update RFC 3697. >=20 >=20 > (In the Introduction) > The intention of this document is to explain this in more detail and > to propose changes to RFC 3697 intended to remove the uncertainties > and encourage active usage of the flow label. It does not formally > update RFC 3697. >=20 > Brian From brian.e.carpenter@gmail.com Mon Jan 17 14:13: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 48DA83A6F6F for ; Mon, 17 Jan 2011 14:13:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.434 X-Spam-Level: X-Spam-Status: No, score=-103.434 tagged_above=-999 required=5 tests=[AWL=0.165, 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 5Anf6Zd6cC0L for ; Mon, 17 Jan 2011 14:13:08 -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 82EE13A6F6E for ; Mon, 17 Jan 2011 14:13:07 -0800 (PST) Received: by wwa36 with SMTP id 36so5391131wwa.13 for ; Mon, 17 Jan 2011 14:15:42 -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=gqygtTq/uw9xSp5Vdu/abaBcvI7fstakXtpMxH4W23g=; b=Ci36t3MSh0qv6Q5/5uKi9lqoaDg02/TUNrVsUm206kXziXypXquMahdb2Xd6/0nPX+ aPCkhrMgSwiEMPks9dTLYsmrohVMlAGOIKm8bJWSkp+9A0nrDiDYs3Jb9qpcdnXx0Wen 9UGQy0taj9q8eZMKON+LG33SUntmzQZetEPdA= 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=G1588EulLqCW6qGbg7/E1VdG6e1EtYRXHDE7jaskdrcRRLYhvg8QiL9jcsBLYM/Mf9 yY2ccqI1eX/OWhck8fug8bZKVTcmldaLAu81CrHn0KvuEHit50VT1PRUlF/S1eSA9wDw yl2AheXGoRY3vamN5nFsqOaTX9K0+otwocOtY= Received: by 10.227.132.208 with SMTP id c16mr1884809wbt.72.1295302541948; Mon, 17 Jan 2011 14:15:41 -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 r38sm2624214weq.47.2011.01.17.14.15.37 (version=SSLv3 cipher=RC4-MD5); Mon, 17 Jan 2011 14:15:40 -0800 (PST) Message-ID: <4D34BF77.5040503@gmail.com> Date: Tue, 18 Jan 2011 11:15:19 +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: 6MAN WG Last Call: draft-ietf-6man-flow-ecmp-00.txt References: <4D272FAC.70104@innovationslab.net> <201101171626.p0HGQTvU002982@cichlid.raleigh.ibm.com> In-Reply-To: <201101171626.p0HGQTvU002982@cichlid.raleigh.ibm.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: ipv6@ietf.org, Brian Haberman , 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: Mon, 17 Jan 2011 22:13:10 -0000 Thomas, Thanks for the thorough review. These are my comments; Shane may have others. On 2011-01-18 05:26, Thomas Narten wrote: > Here is my review of the ECMP document. I don't think it is quite > ready for advancement yet. I do generally support this document, > though there are some clarifications I need to understand. > > The review is rather lengthy, and is mostly editorial but there is > some stuff that may turn out to be substantive. > >> When several network paths between the same two nodes are known by >> the routing system to be equally good (in terms of capacity and >> latency), it may be desirable to share traffic among them. Two >> such > > The document seems to focus on "equal cost" paths, but I assume that > the applicability is really when you have multiple paths that you want > to distribute traffic across. They may be equal cost, but they may not > be. For instance, if I have two links, one with double the capacity as > another, I may want to distributed the traffic in a weighted fashion > (i.e., 1/3 vs. 2/3s). Would be good to make that clear. > > I.e., rather than say "equal distribution", make clear that other > types (weighted, etc.) are also covered. Yes, true. I don't think this changes the main argument, but it should be mentioned. > > Later in the document, the term "load distribution" is used, which is > I think closer to the mark. (This distinction should be clarified > throughout.) > >> o Work-conserving method (no idle time when queue is non-empty). > > Do we really need to use the term "work conserving?" (I had to go look > it up). I don't think it's particularly helpful to use that term in > this document. Well, maybe people don't care about it these days, but it seemed to be a big concern when we were designing diffserv. It's a term of art, which is perhaps distracting. > >> One lightweight approach to ECMP or LAG is this: if there are N >> equally good paths to choose from, then form a modulo(N) hash >> [RFC2991] from a consistent set of fields in each packet header, and >> use the resulting value to select a particular path. If the hash > > make clear the "consistent set of fields" means that the contents of > those fields are invariant for packets of the same flow. Yes > >> use the resulting value to select a particular path. If the hash >> function is chosen so that the hash values have a uniform statistical >> distribution, this method will share traffic roughly equally between > > For "hash values", I assume this means the "output of the hash" (not > the inputs). Perhaps make that more clear? (And it's probably better > to say "output" than "value" generally.) OK. You may want to update the Wikipedia article, which says "The values returned by a hash function are called hash values, hash codes, hash sums, checksums or simply hashes." > > The question with such a method, then, is which IP header fields to > include to identify a flow. A minimal choice in the routing system > is simply to use a hash of the source and destination IP addresses, > i.e., the 2-tuple. This is necessary and sufficient to avoid out-of- > order delivery, and with a wide variety of sources and destinations, > as one finds in the core of the network, sometimes sufficient to > achieve work-conserving load sharing. > > I'd suggest starting this paragraph as a new section, entitled > something like "Choice of IP Header Fields for Hash Input". OK > > Also, this new section might benefit from some reorganization. Most of > the info here is good, but the flow could be better. > > For example, after the above paragraph would be a good time to go into > more detail about why using just the src/dst is insufficient in > practice. The mailing list discussion talked alot about tunneled > protocols being the real problem (and how tunneling is > increasing). Real examples of how in practice this is inadequate would > strengthen the motivation for this document. You talk about this > further down, but saying it here (all in one place) might be good. OK > > Then move on to using 5 tuples, and again describe the limitations and > problems. I think it is critical in this part to justify why the > existing practice as used in IPv4 today is not sufficient for > IPv6. I.e,. why redefining the Flow Label is *necessary* rather than > possibly just that is possibly *nice to have*. My understanding is that existing practice is not sufficient for IPv4 either, so using (not redefining) the flow label is a definite plus point for IPv6. We can make this explicit. > > However, including transport layer information as input keys to a > hash may be a problem for IPv4 fragments [RFC2991]. In addition, > > Yes, but is that relevant to IPv6? (If so, say so, otherwise, the > point is presumably irrelevant.) As far as I understand things, the unfragmentable part of an IPv6 packet does not include the transport header, so the same problem exists for IPv6. I think it should just say "IP fragments". > >> hash may be a problem for IPv4 fragments [RFC2991]. In addition, >> protocol and destination port numbers in the hash will not only make >> the hash slightly more expensive to compute, but will not >> particularly improve the hash distribution, due to the prevalence of >> well known port numbers and popular protocol numbers. Ephemeral >> ports, on the other hand, are quite well distributed [Lee10]. In the > > I disagree with the latter part of the the above. It seems to me that > including port numbers (absent tunneling) will certainly improve the > hash distribution. It is not a requirement that the input to the hash > be uniformly distributed. A good hash will produce a good output > distribution, even if the input is skewed. You seem to be making the > assumption that if the ports are not distributed, the outputs of the > hash wont be distributed either. I do not believe that is true > generally. We may be overcooking the argument. > > well known port numbers and popular protocol numbers. Ephemeral > ports, on the other hand, are quite well distributed [Lee10]. In the > > And since most flows use one well-known port and one ephemeral port, > using both ports as input would seem to give you good > properties. Right? In which case the suggestion that using ports isn't > good isn't true. Yes, the well-known port may be chosen from a very small set in practice so provides little entropy, but the ephemeral port is pretty good. > > In the > case of IPv6, protocol numbers are particularly inconvenient due to > the variable placement of and variable length of next-headers. In > > How many of these next headers exist in practice today? I.e., is this > a real problem, or a theoretical problem? I guess this is the same argument as for draft-ietf-6man-exthdr, but in any case the logic that extracts the 5-tuple has to allow for all legal options, even if extension headers are rare. Should be rephrased to say that. > > the variable placement of and variable length of next-headers. In > addition, [RFC2460] recommends that all next-headers, except hop-by- > hop options, should not be inspected by intermediate nodes in the > network, presumably to make introduction of new next-headers more > straightforward. > > Which text in 2460 is being referred to here? I'm not sure I agree > with the last part of the sentence. "With one exception, extension headers are not examined or processed by any node along a packet's delivery path, until the packet reaches the node (or each of the set of nodes, in the case of multicast) identified in the Destination Address field of the IPv6 header." It's not a formal recommendation, so we should rephrase the sentence; it doesn't add much anyway. > > The situation is different in tunneled scenarios. Identifying a > flow inside the tunnel is more complicated, particularly because > nearly all hardware can only identify flows based on information > contained in the outermost IP header. Assume that traffic from > many sources to many destinations is aggregated in a single > IP-in-IP tunnel from > > try for IPinIP, but what about GRE with keys? Maybe that's why GRE keys were invented ;-) We should be clear about it being IPinIP. > > achieved. If there is much tunnel traffic, this will result in a > high probability of congestion on one of the paths between R1 and R2. > > Not necessarily true. Better to just say traffic won't be distributed > as intended. That may or may not result in congestion. Yes > > Also, for IPv6, the total number of bits in the 5-tuple is quite > large (296), as well as inconvenient to extract due to the next- > header placement. This may be challenging for some hardware > implementations, raising the potential that network equipment vendors > might sacrifice the length of the fields extracted from an IPv6 > > I disagree with some of the above. First, 256 bits comes just from the > source/dest addresses. another 40 bits is noise relative to this in > terms of "number of bits". I.e., saying a 5 tuple is too many bits, > but just the src/addr (possibly with the Flow Label) is OK doesn't > make sense to me. The argument about accessing the fields seems more > compelling and should be made separately. Yes > > header. The question therefore arises whether the 20-bit flow label > in IPv6 packets would be suitable for use as input to an ECMP or LAG > hash algorithm. If it could be used in place of the port numbers and > protocol number in the 5-tuple, the hash calculation would be > simplified. > > I think the stronger argument here is that it is more likely that a > sender could set the Flow Label to a useful value here in cases like > tunneling, where the intermediate routers in practice would not have > access to the port numbers in in the inner header. The good think is > that TEP's can do this today without requiring any changes in existing > specs. Yes > > would it do any harm to the distribution of the hash values. If the > community at some stage agrees to set pseudo-random flow labels in > the majority of traffic flows, this would add to the value of the > hash. > > I'm confused. Isn't the latter exactly what this document is > recommending??? We're recommending that the TEP does so; recommending that everybody does so is the other draft. As you say, TEPs can do this today if they want (that's why this draft is compatible with RFC 3697 as-is). > > source to the destination(s)." The RFC should perhaps have made > clear that a router that has participated in flow state establishment > can rely on properties of the resulting flow label values without > further signaling. If a router knows these properties, rule 2 is > > Right. This is my understanding of what the words should have meant. > > In the tunneling situation sketched above, routers R1 and R2 can rely > on the flow labels set by TEP A and TEP B being assigned by a known > method. This allows a safe ECMP or LAG method to be based on the > flow label without breaching [RFC3697]. > > Technically, this is only true for those flows that the TEP has > set. It is not true for all flows generally, and presumably that is > what R1 and R2 would be assuming... Correct, the problem *this* draft tackles is only balancing the TEP-to-TEP traffic. > > Also, I do not believe that including the Flow Label bits as an input > key to ECMP violates 3697 at all. What text does this violate? It doesn't, so clearly I need to rephrase slightly. > > At the time of this writing, the IETF is discussing a possible > revision of the rules of RFC 3697 [I-D.ietf-6man-flow-update]. If > adopted, that revision would be fully compatible with the present > document and would obviate much of the above discussion. > > This wording seems odd, since the ID cited does not carry any weight > and does not update 3697. See my reply on the other thread. > > o The flow label in the outer packet SHOULD be set by the sending > TEP to a pseudo-random 20-bit value in accordance with [RFC3697]. > > pseudo random is not right here. > > This is a bit of a divergence, but I do not believe it is a > requirement that the someone who sets the Flow Label set it to a > psuedo-random value. Please clarify *why* this needs to be a > SHOULD. Who benefits? There was email discussion about this. Routers > can't assume they will be pseudo-random, otherwise they set themselves > up for DOS attacks. So why is this necessary? Our contention is that this will improve the hash distribution compared to a deterministic method of allocating flow labels. Given that we aren't specifying a hash algorithm, that's a difficult assertion to prove. However, my understanding is that if the inputs to a hash algorithm are distributed uniformly, you can use a relatively simple algorithm to get a uniform output distribution. Pseudo-random values help with this. > as determined by the IP header fields of the inner > packet. > * Note that this rule is a SHOULD rather than a MUST, to permit > individual implementers to take an alternative approach if they > wish to do so. Such an alternative MUST conform to [RFC3697]. > > Please clarify what type of an exception you are trying to allow > for. I need to understand the thinking before agreeing to allow for > this. :-) Well, for example, some lazy implementer who doesn't bother with a pseudo-random function but just does next_label++. That's why there's a normative reference. > > o The sending TEP MUST classify all packets into flows, once it has > determined that they should enter a given tunnel, and then write > the relevant flow label into the outer IPv6 header. A user flow > could be identified by the ingress TEP most simply by its > {destination, source} address pair (coarse) or by its 5-tuple > {dest addr, source addr, protocol, dest port, source port} > (fine). > > Isn't it ironic that you don't include the Flow Label here? I.e., if > the user sets the Flow Label, you don't use its value? That doesn't > seem right! :-) Yes, in today's situation where the label is always zero. Of course, if the source set it, it should be in the mix. We should probably note the irony. > > This is an implementation detail in the sending TEP. > * It might be possible to make this classifier stateless, by > using a suitable 20 bit hash of the inner IP header's 2-tuple > or 5-tuple as the pseudo-random flow label value. > > Doesn't this go against the 3697 requirement not to reuse a value? You raise an interesting point. To be brutal, if your use case is statistical load balancing, you really don't care about occasional re-use. And you really do want to be stateless for performance reasons. > > The issue I have with this is that it does mean some base assumptions > about Flow Labels no longer hold in general. This may or may not be a > problem, but we should speak to this point directly. I.e, this > specification is proposing some possibly non-backwards compatable > changes to the Flow Label semantics. There's a get-out-of-jail card in 3697: "1. Introduction A flow is a sequence of packets sent from a particular source to a particular unicast, anycast, or multicast destination that the source desires to label as a flow. A flow could consist of all packets in a specific transport connection or a media stream. However, a flow is not necessarily 1:1 mapped to a transport connection." In other words, and this was entirely intentional in 3697, a flow is whatever the source chooses to label as a flow (between a given source and destination). So it is completely consistent for a TEP to label two separate user flows with the same label, if that's the way its stateless algorithm happens to operate. > > o At intermediate router(s) that perform load distribution of > tunneled packets whose source address is a TEP, the hash algorithm > used to determine the outgoing component-link in an ECMP and/or > LAG toward the next-hop MUST minimally include the triple {dest > addr, source addr, flow label} to meet the [RFC3697] rules. > > The wording here is awkward. It seems to suggest that you only expect > routers to do this for tunneled packets? How will they know which > packets those are? Sounds inefficient and requiring of > configuration... In practice, won't they just do this for all packets? Yes, definitely. > If so, the wording above seems convoluted... or trying to make > something legal if implementations do X, knowing full well they won't > in practice. It needs rephrasing. > > Also, which 3697 rules are being referred to above? How is it a > violation of an existing standard to do ECMP on just the src/dst > fields? Right, that need rephrasing too - it isn't a question of rules. > > * Intermediate router(s) MAY also include {protocol, dest port, > source port} as input keys to the ECMP and/or LAG hash > algorithms, to provide sufficient entropy in cases where the > flow-label is currently set to zero. > > Seems like this should be a SHOULD. It never hurts to include these > fields, and in many cases helps. To keep things simple, shouldn't the > default be just to use the 6 tuple (when available) as input to the > hash? Well, that's debatable. I still think it's a MAY in RFC 2119 terms, but it's a (lower case) should as a matter of common sense. > > 4. Security Considerations > > The flow label is not protected in any way and can be forged by an > on-path attacker. Off-path attackers are unlikely to guess a valid > flow label if a pseudo-random value is used. In either case, the > worst an attacker could do against ECMP or LAG is to attempt to > selectively overload a particular path. For further discussion, see > [RFC3697]. > > This section seem weak, though I need to think a bit about what it > should say. Ideas welcome. We couldn't think of much to say; we tend to assume that TEPs that are likely to use this will be ISP-managed and really not exposed to MITM risks, so off-path injection of packets is the only obvious risk. Brian From brian.e.carpenter@gmail.com Mon Jan 17 14:23: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 389EB28C151 for ; Mon, 17 Jan 2011 14:23:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.436 X-Spam-Level: X-Spam-Status: No, score=-103.436 tagged_above=-999 required=5 tests=[AWL=0.163, 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 AtK2Kzsl5s94 for ; Mon, 17 Jan 2011 14:23:46 -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 3015C3A6D87 for ; Mon, 17 Jan 2011 14:23:45 -0800 (PST) Received: by vws7 with SMTP id 7so2204830vws.31 for ; Mon, 17 Jan 2011 14:26: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=pnjJT8jYGNtxzVu4w4tei6nOXs4NjTBV4/EUKZpV7ms=; b=JFoAB3JNuxwskmOOb6xKJ+Z0BzqnFXt6BZRQ3+Lox/IZbe1xM80XkH7Zm/3PnCv0BI BypweDLH/5klslXOUG0M6x0mNFZxmTOMV06oTQZnnJ+RYg8opwcWn1RcrpXzkST5tK3S XPll4KpYf9GkdUYgmRwU1YPOC/nCE6h0z+n4I= 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=Ra+9nR3JL+q5EjgzjQ3B9XXWyRGIHIpOVSf/XxdP1Yt//D0+uRWdxDctBYbLqUtsR5 Zq4AknHbqiuycBY3hM1hIyb0VL4MW/Gv/Xww4LCjt4UYYve0wjz4eByUxfxB9zzSfDnf /JTgoCMyHQ7BGEGjXbqTDtx8cb/VeGjn/uBuI= Received: by 10.220.98.210 with SMTP id r18mr1492114vcn.107.1295303180961; Mon, 17 Jan 2011 14:26:20 -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 y14sm1390303vch.28.2011.01.17.14.26.17 (version=SSLv3 cipher=RC4-MD5); Mon, 17 Jan 2011 14:26:20 -0800 (PST) Message-ID: <4D34C1F7.20703@gmail.com> Date: Tue, 18 Jan 2011 11:25:59 +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: 6MAN WG Last Call: References: <201101171719.p0HHJox8003240@cichlid.raleigh.ibm.com> <4D34A8C7.5070107@gmail.com> <201101172119.p0HLJGOw005041@cichlid.raleigh.ibm.com> In-Reply-To: <201101172119.p0HLJGOw005041@cichlid.raleigh.ibm.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: 6man Mailing List , Brian Haberman , 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: Mon, 17 Jan 2011 22:23:47 -0000 Thomas, Section 4 of the draft is explicitly the proposed normative changes; no more and no less, starting at " A description of the changes follows. They are written in normative language to avoid ambiguity. They are mainly not written as specific text changes to RFC 3697, and significant rewriting of the latter is needed to incorporate these changes." Expressing them as diffs to 3697 would produce an unreadable mess. I imagine that the resulting 3697bis would be about the same length as 3697. Regards Brian On 2011-01-18 10:19, Thomas Narten wrote: >> There's clearly a problem (20 unused bits and enormous confusion >> about how they could be used). And clearly the goal is 3697bis. The >> reason for this draft, as I believe we've discussed over some >> months, is to set the scene for 3697bis. Indeed we have two choices: > >> 1) agree on the substance of the intended updates and publish them as a >> stake in the ground, then develop 3697bis. > >> 2) agree on the substance of the intended updates (by means of the >> present WGLC), and then proceed directly to develop 3697bis. > > I would find it helpful to see the proposed changes to 3697bis. If I > don't see them, I can't tell for sure whether I agree with the > justification for making changes. Also, if we want the justification > to be correct, it needs to be in sync with the actual changes. If we > publish the proposed changes first, and then make changes, we risk the > two not being in sync (when people start discussing the actual changes > and realize what is really at issue). Or we risk never actually > getting agreement on the changes, and then flow-update ends up being > the "end of the road". > > If we already know what changes will be made, please put them on the > table and let's decide and move on. > > How big of a document are we talking about for the actual changes? > >> I would be too, if it was the end of the road, but we have an author >> team all set to start on 3697bis once we have a clear consensus in >> the WG about the changes to be made. > > What are those proposed changes? And can we guage consensus now, > before publishing the documents? I don't like this idea that we say > there is agreement on the proposed changes, but we don't actually know > what they are. > > Thomas > From brian.e.carpenter@gmail.com Mon Jan 17 14:30: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 A9EEA28C153 for ; Mon, 17 Jan 2011 14:30:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.438 X-Spam-Level: X-Spam-Status: No, score=-103.438 tagged_above=-999 required=5 tests=[AWL=0.161, 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 irJifzGtNIs1 for ; Mon, 17 Jan 2011 14:30:20 -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 AB48328C151 for ; Mon, 17 Jan 2011 14:30:20 -0800 (PST) Received: by vws7 with SMTP id 7so2206556vws.31 for ; Mon, 17 Jan 2011 14:32:55 -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=k6FnaUK3O+zuFzL+hK2mnaLbhP8YSZPlGDghQYOP/pk=; b=vNrZcO38pHD6S9S4Trt67yPeeNHIxNRUQOxCW3LgZ07SeJ0xce4s8aK/JXfM2bDxAc T67ovD23OVpICrOPH3qPsn+dVfsetjrJ6vlQJ+PgNgWtE5X6Lo1UB5riJXSTjGyDUMke buOFKjGrPHH2CwGVD75UmYNrLeALzHv61czzw= 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=pqMn/fROW05R1BRArIHXYj3uaiBPIpj8hNqZ7jC+trw15WNsCW/aHI9xD+pCIAcHFJ juytCs0SKtpZu4Kbwl8JAtFW/bnYd0QzybTJNIrG3JyjtGQCw9EHomvpNexrB9yUItDc lw4vh0APgWokJ/BmAQ7MCpnmnJJ52gTwNnCtU= Received: by 10.220.191.194 with SMTP id dn2mr1185807vcb.268.1295303575782; Mon, 17 Jan 2011 14:32:55 -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 o6sm1392089vcr.3.2011.01.17.14.32.53 (version=SSLv3 cipher=RC4-MD5); Mon, 17 Jan 2011 14:32:55 -0800 (PST) Message-ID: <4D34C382.6000402@gmail.com> Date: Tue, 18 Jan 2011 11:32:34 +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: 6MAN WG Last Call: References: <201101171719.p0HHJox8003240@cichlid.raleigh.ibm.com> <4D34A8C7.5070107@gmail.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Thomas Narten , Brian Haberman , 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, 17 Jan 2011 22:30:21 -0000 Sure, we can do that. I suggest repurposing the present draft as a rationale document, so basically what we have to do is merge its section 4 into 3697. FYI the proposed authors for 3697bis are Shane Amante Brian Carpenter Sheng Jiang Jarno Rajahalme Since the WG adopted draft-ietf-6man-flow-update, should we post 3697bis immediately as a 6man draft? Regards Brian On 2011-01-18 10:58, Bob Hinden wrote: > Brian, > >> There's clearly a problem (20 unused bits and enormous confusion about >> how they could be used). And clearly the goal is 3697bis. The reason for >> this draft, as I believe we've discussed over some months, is to set the >> scene for 3697bis. Indeed we have two choices: >> >> 1) agree on the substance of the intended updates and publish them as a >> stake in the ground, then develop 3697bis. >> >> 2) agree on the substance of the intended updates (by means of the >> present WGLC), and then proceed directly to develop 3697bis. >> >> I understood that we'd agreed on 1) but the WG Chairs can tell me I'm wrong. > > After a short discussion, the chairs think that it would be preferable to either have this document become an update to RFC3697 itself, or have an RFC3697bis draft be written to be considered in parallel. In the last case this draft would be the justification and background, and the RFC3697bis draft would be an implementers spec (that is, what to do, not why). I note that RFC3697 is only 9 pages long. > > Bob > > >>> And in looking at draft-ietf-6man-flow-ecmp-00.txt (also in WGLC), >>> that document is a BCP and does not update any of the previous Flow >>> Label documents. >> Correct. It doesn't need to; it is additional practice and the intention >> is to ensure that it's compatible both with 3697 and the eventual 3697bis. >> (I agree with your comment on that draft that the phrasing on this >> point is clumsy.) >> >>> If we need to update the Flow Label specs, we should do so, and this >>> document could be part of that or a rational for the changes. But >>> absent any changes to the existing standards, I am not comfortable >>> with publishing this document. >> I would be too, if it was the end of the road, but we have an author >> team all set to start on 3697bis once we have a clear consensus in >> the WG about the changes to be made. Can you propose text that is >> clearer than the following? >> >> (In the Abstract) >> This document describes and motivates proposed >> changes to the specification in order to clarify it, making it clear >> what types of usage are possible, and to introduce some additional >> flexibility. It does not formally update RFC 3697. >> >> >> (In the Introduction) >> The intention of this document is to explain this in more detail and >> to propose changes to RFC 3697 intended to remove the uncertainties >> and encourage active usage of the flow label. It does not formally >> update RFC 3697. >> >> Brian > > From bob.hinden@gmail.com Tue Jan 18 08:02: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 36EB128C1B9 for ; Tue, 18 Jan 2011 08:02:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.338 X-Spam-Level: X-Spam-Status: No, score=-103.338 tagged_above=-999 required=5 tests=[AWL=0.262, 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 86-YPOHXxjrB for ; Tue, 18 Jan 2011 08:02:37 -0800 (PST) Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by core3.amsl.com (Postfix) with ESMTP id 3852B28C1B0 for ; Tue, 18 Jan 2011 08:02:37 -0800 (PST) Received: by pwi7 with SMTP id 7so1356876pwi.31 for ; Tue, 18 Jan 2011 08:05:14 -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=Ieowk+FW3wzsNZe4MVQlyoqjZO0DHvX1NTT7EyQMQ+U=; b=Aj/2DCgzAaRI0NvAnaaKOYysjM64ZgwekpkAOci0y8tL25XYosYPSiB7rOjgtL8jIx lSQ3JqGg/HHSFDnZVte+BpOae4zlqlce/isJLo8t5dG9nbzK8AjsB5N/NwSTr+5ihZyW kce7tf91TZudBreRw4rkYPHui6/C5k96FjfQE= 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=cSIY2JR6fWVGq8o2DtYwI5gfOSil8VbxgjhBsZ8+Ciu3NuqfI0NIdKuPIw9DdzvRF/ WpV1eqx97qqBXz9/VpR4qaDLTRPdGnqHp8zizFXS+cxwb+qeF68QkREm2J0XFZNg/pr1 KyAnZCaGAXbeIcYhntmNllu7v+hllJi8EeYGE= Received: by 10.142.172.2 with SMTP id u2mr5276211wfe.364.1295366714481; Tue, 18 Jan 2011 08:05:14 -0800 (PST) Received: from [10.0.0.37] (c-24-130-226-27.hsd1.ca.comcast.net [24.130.226.27]) by mx.google.com with ESMTPS id e14sm8240228wfg.8.2011.01.18.08.05.12 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 18 Jan 2011 08:05:13 -0800 (PST) Subject: Re: 6MAN WG Last Call: Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Bob Hinden In-Reply-To: <4D34C382.6000402@gmail.com> Date: Tue, 18 Jan 2011 08:05:10 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <31FC1114-67D3-49C5-84FD-6E4D4344B64F@gmail.com> References: <201101171719.p0HHJox8003240@cichlid.raleigh.ibm.com> <4D34A8C7.5070107@gmail.com> <4D34C382.6000402@gmail.com> To: Brian E Carpenter X-Mailer: Apple Mail (2.1082) Cc: Thomas Narten , 6man Mailing List , Brian Haberman , 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: Tue, 18 Jan 2011 16:02:38 -0000 Brian, On Jan 17, 2011, at 2:32 PM, Brian E Carpenter wrote: > Sure, we can do that. I suggest repurposing the present draft as > a rationale document, so basically what we have to do is merge its > section 4 into 3697. >=20 > FYI the proposed authors for 3697bis are > Shane Amante > Brian Carpenter > Sheng Jiang > Jarno Rajahalme >=20 > Since the WG adopted draft-ietf-6man-flow-update, should > we post 3697bis immediately as a 6man draft? Yes, please do that. That is consistent with making the other flow = label drafts 6man w.g. group documents. Thanks, Bob >=20 > Regards > Brian >=20 > On 2011-01-18 10:58, Bob Hinden wrote: >> Brian, >>=20 >>> There's clearly a problem (20 unused bits and enormous confusion = about >>> how they could be used). And clearly the goal is 3697bis. The reason = for >>> this draft, as I believe we've discussed over some months, is to set = the >>> scene for 3697bis. Indeed we have two choices: >>>=20 >>> 1) agree on the substance of the intended updates and publish them = as a >>> stake in the ground, then develop 3697bis. >>>=20 >>> 2) agree on the substance of the intended updates (by means of the >>> present WGLC), and then proceed directly to develop 3697bis. >>>=20 >>> I understood that we'd agreed on 1) but the WG Chairs can tell me = I'm wrong. >>=20 >> After a short discussion, the chairs think that it would be = preferable to either have this document become an update to RFC3697 = itself, or have an RFC3697bis draft be written to be considered in = parallel. In the last case this draft would be the justification and = background, and the RFC3697bis draft would be an implementers spec (that = is, what to do, not why). I note that RFC3697 is only 9 pages long. >>=20 >> Bob >>=20 >>=20 >>>> And in looking at draft-ietf-6man-flow-ecmp-00.txt (also in WGLC), >>>> that document is a BCP and does not update any of the previous Flow >>>> Label documents. >>> Correct. It doesn't need to; it is additional practice and the = intention >>> is to ensure that it's compatible both with 3697 and the eventual = 3697bis. >>> (I agree with your comment on that draft that the phrasing on this >>> point is clumsy.) >>>=20 >>>> If we need to update the Flow Label specs, we should do so, and = this >>>> document could be part of that or a rational for the changes. But >>>> absent any changes to the existing standards, I am not comfortable >>>> with publishing this document. >>> I would be too, if it was the end of the road, but we have an author >>> team all set to start on 3697bis once we have a clear consensus in >>> the WG about the changes to be made. Can you propose text that is >>> clearer than the following? >>>=20 >>> (In the Abstract) >>> This document describes and motivates proposed >>> changes to the specification in order to clarify it, making it = clear >>> what types of usage are possible, and to introduce some additional >>> flexibility. It does not formally update RFC 3697. >>>=20 >>>=20 >>> (In the Introduction) >>> The intention of this document is to explain this in more detail = and >>> to propose changes to RFC 3697 intended to remove the uncertainties >>> and encourage active usage of the flow label. It does not formally >>> update RFC 3697. >>>=20 >>> Brian >>=20 >>=20 From fernando.gont.netbook.win@gmail.com Fri Jan 21 08:53: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 333003A6A5D for ; Fri, 21 Jan 2011 08:53:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.51 X-Spam-Level: X-Spam-Status: No, score=-3.51 tagged_above=-999 required=5 tests=[AWL=0.089, 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 30NXPpdSIjYa for ; Fri, 21 Jan 2011 08:53:21 -0800 (PST) Received: from mail-yi0-f44.google.com (mail-yi0-f44.google.com [209.85.218.44]) by core3.amsl.com (Postfix) with ESMTP id 0C3243A6A5A for ; Fri, 21 Jan 2011 08:53:20 -0800 (PST) Received: by yie19 with SMTP id 19so668551yie.31 for ; Fri, 21 Jan 2011 08:56:07 -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=lQVbzMxkXzH23fjz2U49ahKOBpaqUQDOUgAnEWU+mPA=; b=gJdeIKH1ufGz1SOm/UX0F30+KQjpw8jLPuTsK3KgrxqqzwkTEKrKr7ppwrIsYcxSHW lWFfpufHEMyyodFEKGhXz4TdzhZe257x7VE9RGEsk/KEaj7xcfBxIp6xoxsBSQbRBiOZ cLxlmtsNAPEVyWy00LGhU0tE/92/Y8KC1NNnY= 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=OCXfSpGl+0hTOXA+x/1QBsyAoEPYFkOL9r03sA30k0NEZsBignrNAJRQhaTbtJJlpz k+Eakxd3Rck+p1NP9/U946KTlMfAJei5IaVkNy7Is3YlgyeWsYmxhVQl+MSCdeEYDmYQ yjQZS1fzr0x4CVU+RyMjIjpkqd1iQM+IiqSbY= Received: by 10.147.33.10 with SMTP id l10mr1148924yaj.29.1295628967155; Fri, 21 Jan 2011 08:56:07 -0800 (PST) Received: from [192.168.0.129] (61-128-17-190.fibertel.com.ar [190.17.128.61]) by mx.google.com with ESMTPS id z12sm11696487anp.19.2011.01.21.08.56.00 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 21 Jan 2011 08:56:04 -0800 (PST) Sender: Fernando Gont Message-ID: <4D39BA68.3060304@gont.com.ar> Date: Fri, 21 Jan 2011 13:55:04 -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: Thomas Narten Subject: Re: Psuedo-randomness in flow labels [was Re: [Fwd: I-D Action:draft-ietf-6man-flow-update-00.txt]] References: <4CF82E6F.9040309@gmail.com> <4D08165A.3060306@gmail.com> <51661CE4-EC60-46B9-928C-D5763CFDF318@cisco.com> <4D082147.9010209@gmail.com> <4D2A1B84.1020003@gmail.com> <4D2A64A1.4030400@gmail.com> <201101101410.p0AEAPNs007778@cichlid.raleigh.ibm.com> In-Reply-To: <201101101410.p0AEAPNs007778@cichlid.raleigh.ibm.com> X-Enigmail-Version: 1.1.1 OpenPGP: id=D076FFF1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: 6man , Brian E Carpenter , Fred Baker 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, 21 Jan 2011 16:53:22 -0000 Hi, Thomas, On 10/01/2011 11:10 a.m., Thomas Narten wrote: > The crux of the issue is the following: > >> 1. It is RECOMMENDED that source hosts support the flow label by >> setting the flow label field for all packets of a flow to the >> same pseudo-random value. > > I do not see a reason to require this. Probably that could/should be rephrased as: 1. It is RECOMMENDED that source hosts support the flow label by setting the flow label field for all packets of a flow to the same value. Such value should not be easily predictable by an off-path attacker. > You do NOT need uniform spread on the input to the hash to get such an > output. A decent hash algorithm is what you need. You also don't need > Flow Labels selected in a psuedo random fashion. Agreed. But predictable values have been found to have problems. See e.g. the implications of the IPv4 identification field in http://www.gont.com.ar/papers/InternetProtocol.pdf > RFC 3697 says specifically you can assign Flow Label values > sequentially. Indeed, draft-gont-6man-flowlabel-security does select flow-labels incrementally --- although with a scheme that makes it difficult for an off-path attacker to guess te next flowlabel value. Thanks! Best regards, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 From bob.hinden@gmail.com Fri Jan 21 09:17: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 D99473A6A61 for ; Fri, 21 Jan 2011 09:17:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.457 X-Spam-Level: X-Spam-Status: No, score=-103.457 tagged_above=-999 required=5 tests=[AWL=0.142, 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 cR1-PtKxbTwN for ; Fri, 21 Jan 2011 09:17:51 -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 9DC813A69F5 for ; Fri, 21 Jan 2011 09:17:51 -0800 (PST) Received: by pxi6 with SMTP id 6so421779pxi.31 for ; Fri, 21 Jan 2011 09:20:38 -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=iAIg1IifSO44C+T4vBFIlqHhv05d6sWV3vpMcRC7bdk=; b=HKqUJ/xl/dB5aXZLt5t5wDtZlDXTAjWJc6BFWdtPm7dx/RhiYQXq07patXFZR3GzNt 35tW0SsN9nFUXm6x2OXUy7KUVwiLJaS5FkYKExI26b5wJ8JYXmGgi2elzz+/v3r+h372 4YhTpqnVEM2HO3FQ42nUa7pmLeyh0mwL/ywi8= 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=M9KWbCzgH7CBKYnmtJMd5vyG9Pe1DKasUET/xh5Te1tdiD0aS/dJuauaBxE+4MBY6Q UDZvKnPJ8W1+fbXMpyDl6ga3AgRdgwdSxLThtAxqUFBjZwrGny52Oe2vxiFxTJCERuhF tUCXdjsDH2RvrV8G881DkY8/vn/pDpzaXFE9Y= Received: by 10.142.199.16 with SMTP id w16mr929825wff.158.1295630437676; Fri, 21 Jan 2011 09:20:37 -0800 (PST) Received: from [10.0.0.37] (c-24-130-226-27.hsd1.ca.comcast.net [24.130.226.27]) by mx.google.com with ESMTPS id w14sm12930747wfd.18.2011.01.21.09.20.35 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 21 Jan 2011 09:20:36 -0800 (PST) Subject: Re: Psuedo-randomness in flow labels [was Re: [Fwd: I-D Action:draft-ietf-6man-flow-update-00.txt]] Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Bob Hinden In-Reply-To: <4D39BA68.3060304@gont.com.ar> Date: Fri, 21 Jan 2011 09:20:33 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <6A57A0BB-5574-45DA-8D1B-124E74AA5F5D@gmail.com> References: <4CF82E6F.9040309@gmail.com> <4D08165A.3060306@gmail.com> <51661CE4-EC60-46B9-928C-D5763CFDF318@cisco.com> <4D082147.9010209@gmail.com> <4D2A1B84.1020003@gmail.com> <4D2A64A1.4030400@gmail.com> <201101101410.p0AEAPNs007778@cichlid.raleigh.ibm.com> <4D39BA68.3060304@gont.com.ar> To: Fernando Gont X-Mailer: Apple Mail (2.1082) Cc: Thomas Narten , 6man , Bob Hinden , Brian E Carpenter , Fred Baker 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, 21 Jan 2011 17:17:53 -0000 Fernando, On Jan 21, 2011, at 8:55 AM, Fernando Gont wrote: > Hi, Thomas, >=20 > On 10/01/2011 11:10 a.m., Thomas Narten wrote: >> The crux of the issue is the following: >>=20 >>> 1. It is RECOMMENDED that source hosts support the flow label by >>> setting the flow label field for all packets of a flow to the >>> same pseudo-random value. >>=20 >> I do not see a reason to require this. >=20 > Probably that could/should be rephrased as: >=20 > 1. It is RECOMMENDED that source hosts support the flow label by > setting the flow label field for all packets of a flow to the > same value. Such value should not be easily predictable by an > off-path attacker. We could also add to this something like: One way to achieve this is = with a pseudo-random value. Bob >=20 >=20 >=20 >> You do NOT need uniform spread on the input to the hash to get such = an >> output. A decent hash algorithm is what you need. You also don't need >> Flow Labels selected in a psuedo random fashion. >=20 > Agreed. But predictable values have been found to have problems. See > e.g. the implications of the IPv4 identification field in > http://www.gont.com.ar/papers/InternetProtocol.pdf >=20 >=20 >> RFC 3697 says specifically you can assign Flow Label values >> sequentially.=20 >=20 > Indeed, draft-gont-6man-flowlabel-security does select flow-labels > incrementally --- although with a scheme that makes it difficult for = an > off-path attacker to guess te next flowlabel value. >=20 > Thanks! >=20 > Best regards, > --=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 > -------------------------------------------------------------------- > 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 Fri Jan 21 09:22: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 8A75A28C112 for ; Fri, 21 Jan 2011 09:22:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.512 X-Spam-Level: X-Spam-Status: No, score=-3.512 tagged_above=-999 required=5 tests=[AWL=0.087, 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 MrGNE6GPUOBZ for ; Fri, 21 Jan 2011 09:22:28 -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 22DC128C10F for ; Fri, 21 Jan 2011 09:22:28 -0800 (PST) Received: by ywk9 with SMTP id 9so680186ywk.31 for ; Fri, 21 Jan 2011 09:25:14 -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=s0CQ8IhISu2vsOHjFAPXHjG9BBUbxh7Rr8Z7Xji92Q4=; b=RDeprLhNDFdqnZYnOcfvXhheU9/ZvDLoZzzNR/+XzfVOmDwZq2nP/2eKfDEZHN7buS /997QjDigjGTiKZqEGjmamyT0ukicm91eqpDCp8BL5sLh1Ty17rF8b9N9imPbEGkdXLc czsRTSaF6sZ42/sLIu7Ba9qAm7XT9JrN9NuZg= 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=t71ARA9sboFP+KhN7RbCcWd3LrZyh69pmwY/evYmCR4ykDEGtSdPfuFTLHbJn1M/LN LnYfeOgGgjpBvST1VHzx9oKh1mkNIQLvO2o122FZwCL802//rFS8GN9rN1wK2OrYcr8W h7vp7RjbgHx1PLa0STB0iZ+A75D0uhRPb18qM= Received: by 10.100.6.7 with SMTP id 7mr640690anf.256.1295630714295; Fri, 21 Jan 2011 09:25:14 -0800 (PST) Received: from [192.168.0.129] (61-128-17-190.fibertel.com.ar [190.17.128.61]) by mx.google.com with ESMTPS id 2sm11724560anw.18.2011.01.21.09.25.09 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 21 Jan 2011 09:25:12 -0800 (PST) Sender: Fernando Gont Message-ID: <4D39C13E.20103@gont.com.ar> Date: Fri, 21 Jan 2011 14:24:14 -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: Bob Hinden Subject: Re: Psuedo-randomness in flow labels [was Re: [Fwd: I-D Action:draft-ietf-6man-flow-update-00.txt]] References: <4CF82E6F.9040309@gmail.com> <4D08165A.3060306@gmail.com> <51661CE4-EC60-46B9-928C-D5763CFDF318@cisco.com> <4D082147.9010209@gmail.com> <4D2A1B84.1020003@gmail.com> <4D2A64A1.4030400@gmail.com> <201101101410.p0AEAPNs007778@cichlid.raleigh.ibm.com> <4D39BA68.3060304@gont.com.ar> <6A57A0BB-5574-45DA-8D1B-124E74AA5F5D@gmail.com> In-Reply-To: <6A57A0BB-5574-45DA-8D1B-124E74AA5F5D@gmail.com> X-Enigmail-Version: 1.1.1 OpenPGP: id=D076FFF1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Thomas Narten , 6man , Brian E Carpenter , Fred Baker 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, 21 Jan 2011 17:22:29 -0000 Hi, Bob, On 21/01/2011 02:20 p.m., Bob Hinden wrote: >>>> 1. It is RECOMMENDED that source hosts support the flow label >>>> by setting the flow label field for all packets of a flow to >>>> the same pseudo-random value. >>> >>> I do not see a reason to require this. >> Probably that could/should be rephrased as: >> >> 1. It is RECOMMENDED that source hosts support the flow label by >> setting the flow label field for all packets of a flow to the >> same value. Such value should not be easily predictable by an >> off-path attacker. > > We could also add to this something like: One way to achieve this is with a pseudo-random value. +1 -- Although if the flowlabels are expected to be unique for each flow (as they currently are), then random numbers have a chance for collisions, and the approach proposed in draft-gont-flowlabel-security is better. Thanks! Best regards, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 From brian.e.carpenter@gmail.com Fri Jan 21 11:23: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 8A6323A6A94 for ; Fri, 21 Jan 2011 11:23:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.46 X-Spam-Level: X-Spam-Status: No, score=-103.46 tagged_above=-999 required=5 tests=[AWL=0.139, 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 YgrBt4SfCAbV for ; Fri, 21 Jan 2011 11:23:08 -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 3A9123A6A92 for ; Fri, 21 Jan 2011 11:23:08 -0800 (PST) Received: by bwz12 with SMTP id 12so2035259bwz.31 for ; Fri, 21 Jan 2011 11:25:54 -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=qI0YI6yecBnCIf4MvX3VDsNDAtvjl2xPG4TCOqmXzag=; b=KFrN9LivCr7rPmZYEeitNOWhhvGZZJchU/Vg2pQYVUk6TFWWrcgfBvw6lJQcHFaC4X BfWjt/yEwd1PNLE31yXog3DORBd3quYD91TidWJxsD4oc0qlZ5zI8KBtHbdEicn5AX6j zq8uGPDUTYhhfk3tdqaCZCAGJpLaPKdbX3SMU= 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=Yvc2qh6aE5Hc8ysH1dkdomPuLvCSdvtZMqXqG6kBinZ/cG9YdY1gEI2g3fNXKPfpyv mpFXogFi+SeDcWQ56K1AEkhQpWwq0exNAFX+m48B7OT6ZgY9gsdF0cVIi11wFgTovQBf jwTOxzpQyVJLh/FGgilKonXSjURPhpCr5bUSU= Received: by 10.204.97.193 with SMTP id m1mr1093772bkn.46.1295637953554; Fri, 21 Jan 2011 11:25:53 -0800 (PST) Received: from [10.1.1.4] ([121.98.190.33]) by mx.google.com with ESMTPS id rc9sm3353054bkb.14.2011.01.21.11.25.48 (version=SSLv3 cipher=RC4-MD5); Fri, 21 Jan 2011 11:25:52 -0800 (PST) Message-ID: <4D39DDBA.1070901@gmail.com> Date: Sat, 22 Jan 2011 08:25:46 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Fernando Gont Subject: Re: Psuedo-randomness in flow labels [was Re: [Fwd: I-D Action:draft-ietf-6man-flow-update-00.txt]] References: <4CF82E6F.9040309@gmail.com> <4D08165A.3060306@gmail.com> <51661CE4-EC60-46B9-928C-D5763CFDF318@cisco.com> <4D082147.9010209@gmail.com> <4D2A1B84.1020003@gmail.com> <4D2A64A1.4030400@gmail.com> <201101101410.p0AEAPNs007778@cichlid.raleigh.ibm.com> <4D39BA68.3060304@gont.com.ar> <6A57A0BB-5574-45DA-8D1B-124E74AA5F5D@gmail.com> <4D39C13E.20103@gont.com.ar> In-Reply-To: <4D39C13E.20103@gont.com.ar> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Thomas Narten , 6man , Bob Hinden , Fred Baker 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, 21 Jan 2011 19:23:09 -0000 On 2011-01-22 06:24, Fernando Gont wrote: > Hi, Bob, > > On 21/01/2011 02:20 p.m., Bob Hinden wrote: > >>>>> 1. It is RECOMMENDED that source hosts support the flow label >>>>> by setting the flow label field for all packets of a flow to >>>>> the same pseudo-random value. >>>> I do not see a reason to require this. >>> Probably that could/should be rephrased as: >>> >>> 1. It is RECOMMENDED that source hosts support the flow label by >>> setting the flow label field for all packets of a flow to the >>> same value. Such value should not be easily predictable by an >>> off-path attacker. >> We could also add to this something like: One way to achieve this is with a pseudo-random value. > > +1 > > -- Although if the flowlabels are expected to be unique for each flow > (as they currently are), then random numbers have a chance for > collisions, and the approach proposed in draft-gont-flowlabel-security > is better. We seem to have agreed that the primary purpose of the flow label is to facilitate load balancing, which is a statistical process. For that to work, while minimising reordering, it's required that all packets of the same flow have the same label (as is clear in 3697 and will be clear in 3697bis). However, it is NOT required that flow labels are strictly unique - a birthday-paradox rate of duplicate flow labels really won't matter. I suggest (and this is a new suggestion that's been in my mind for a few days) that the uniqueness requirement can and should be relaxed to 'unique with high probability'. Brian From narten@us.ibm.com Fri Jan 21 11:46: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 B6CA83A6A9B for ; Fri, 21 Jan 2011 11:46:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.756 X-Spam-Level: X-Spam-Status: No, score=-105.756 tagged_above=-999 required=5 tests=[AWL=0.843, 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 wo9AvlVsCRWJ for ; Fri, 21 Jan 2011 11:46:36 -0800 (PST) Received: from e6.ny.us.ibm.com (e6.ny.us.ibm.com [32.97.182.146]) by core3.amsl.com (Postfix) with ESMTP id C74323A67C2 for ; Fri, 21 Jan 2011 11:46:35 -0800 (PST) Received: from d01dlp02.pok.ibm.com (d01dlp02.pok.ibm.com [9.56.224.85]) by e6.ny.us.ibm.com (8.14.4/8.13.1) with ESMTP id p0LJYp6j015319 for ; Fri, 21 Jan 2011 14:34:51 -0500 Received: from d01relay05.pok.ibm.com (d01relay05.pok.ibm.com [9.56.227.237]) by d01dlp02.pok.ibm.com (Postfix) with ESMTP id A1C4C4DE804E for ; Fri, 21 Jan 2011 14:45:52 -0500 (EST) Received: from d01av04.pok.ibm.com (d01av04.pok.ibm.com [9.56.224.64]) by d01relay05.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id p0LJnEQE172922 for ; Fri, 21 Jan 2011 14:49:14 -0500 Received: from d01av04.pok.ibm.com (loopback [127.0.0.1]) by d01av04.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id p0LJnCBT024023 for ; Fri, 21 Jan 2011 14:49:14 -0500 Received: from cichlid.raleigh.ibm.com (sig-9-76-146-211.mts.ibm.com [9.76.146.211]) by d01av04.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id p0LJnBsc024005 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 21 Jan 2011 14:49:12 -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 p0LJn8nh021448; Fri, 21 Jan 2011 14:49:09 -0500 Message-Id: <201101211949.p0LJn8nh021448@cichlid.raleigh.ibm.com> To: Brian E Carpenter Subject: Re: Psuedo-randomness in flow labels [was Re: [Fwd: I-D Action:draft-ietf-6man-flow-update-00.txt]] In-reply-to: <4D39DDBA.1070901@gmail.com> References: <4CF82E6F.9040309@gmail.com> <4D08165A.3060306@gmail.com> <51661CE4-EC60-46B9-928C-D5763CFDF318@cisco.com> <4D082147.9010209@gmail.com> <4D2A1B84.1020003@gmail.com> <4D2A64A1.4030400@gmail.com> <201101101410.p0AEAPNs007778@cichlid.raleigh.ibm.com> <4D39BA68.3060304@gont.com.ar> <6A57A0BB-5574-45DA-8D1B-124E74AA5F5D@gmail.com> <4D39C13E.20103@gont.com.ar> <4D39DDBA.1070901@gmail.com> Comments: In-reply-to Brian E Carpenter message dated "Sat, 22 Jan 2011 08:25:46 +1300." Date: Fri, 21 Jan 2011 14:49:08 -0500 From: Thomas Narten X-Content-Scanned: Fidelis XPS MAILER Cc: 6man , Bob Hinden , Fred Baker 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, 21 Jan 2011 19:46:36 -0000 > However, it is NOT required that flow labels are strictly unique - a > birthday-paradox rate of duplicate flow labels really won't > matter. I suggest (and this is a new suggestion that's been in my > mind for a few days) that the uniqueness requirement can and should > be relaxed to 'unique with high probability'. Right. the way I've been thinking about that is that traditional Flows, ala NSIS/RSVP where a flow setup protocol is in use, does still require uniqueness. But other uses of the Flow Label outside of that do not have that requirement. So, if you do traditional flows, you have to be sure to generate Flow Labels carefully. The default usage outside of signaling does not have the same requirement. Thomas From fernando.gont.netbook.win@gmail.com Fri Jan 21 14:09: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 DF2133A683B for ; Fri, 21 Jan 2011 14:09:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.514 X-Spam-Level: X-Spam-Status: No, score=-3.514 tagged_above=-999 required=5 tests=[AWL=0.085, 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 rF9bB00sCL73 for ; Fri, 21 Jan 2011 14:09:22 -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 E98773A67EE for ; Fri, 21 Jan 2011 14:09:21 -0800 (PST) Received: by ywk9 with SMTP id 9so765179ywk.31 for ; Fri, 21 Jan 2011 14:12:08 -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=FhtDuNUOr66bWnTAovbkjsXYKSqoM6GBwfrkGnRz3Mk=; b=DJef5EoxZ0yc2SPxo6kKQMyI42sCcaAmyEo/yVgzpDF8p+d4IEdOMibm3hWSmOBEht JOhCyaBM8XYZIajWCMIkBcWwWqbAEFm0vSB3ukYj72wrPSurldE7ATnsm9kDyby2hjwa Ehqlj1MilJ01xSBW++fCCVypUaGm7H3Vasyo4= 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=AHYzWcmGCBYYHAkKQjzxnyIMDHkjW4Bet8IoTCMqNKy0kt6FUEU3tDCx0sESyHlX7L YVTg5JP9eteE8JE93ZIrge3FAPchzPm3wEbwBuTwf424mpRYImo5Ud6JZtOjHgx5fJgG 0B5BDdrM5FiPuD49CSrsOrus565mDnsN4bP4s= Received: by 10.146.167.7 with SMTP id p7mr1663767yae.10.1295647928654; Fri, 21 Jan 2011 14:12:08 -0800 (PST) Received: from [192.168.0.129] (61-128-17-190.fibertel.com.ar [190.17.128.61]) by mx.google.com with ESMTPS id w4sm12001713anw.16.2011.01.21.14.12.04 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 21 Jan 2011 14:12:07 -0800 (PST) Sender: Fernando Gont Message-ID: <4D3A0337.9000300@gont.com.ar> Date: Fri, 21 Jan 2011 19:05:43 -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: Thomas Narten Subject: Re: Psuedo-randomness in flow labels [was Re: [Fwd: I-D Action:draft-ietf-6man-flow-update-00.txt]] References: <4CF82E6F.9040309@gmail.com> <4D08165A.3060306@gmail.com> <51661CE4-EC60-46B9-928C-D5763CFDF318@cisco.com> <4D082147.9010209@gmail.com> <4D2A1B84.1020003@gmail.com> <4D2A64A1.4030400@gmail.com> <201101101410.p0AEAPNs007778@cichlid.raleigh.ibm.com> <4D39BA68.3060304@gont.com.ar> <6A57A0BB-5574-45DA-8D1B-124E74AA5F5D@gmail.com> <4D39C13E.20103@gont.com.ar> <4D39DDBA.1070901@gmail.com> <201101211949.p0LJn8nh021448@cichlid.raleigh.ibm.com> In-Reply-To: <201101211949.p0LJn8nh021448@cichlid.raleigh.ibm.com> X-Enigmail-Version: 1.1.1 OpenPGP: id=D076FFF1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: 6man , Bob Hinden , Brian E Carpenter , Fred Baker 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, 21 Jan 2011 22:09:23 -0000 On 21/01/2011 04:49 p.m., Thomas Narten wrote: > But other uses of the Flow Label outside of that do not have that > requirement. > > So, if you do traditional flows, you have to be sure to generate Flow > Labels carefully. The default usage outside of signaling does not > have the same requirement. Having two different FlowLabel generation algorithms does not sound like a good approach to me (not that you're proposing that, though) -- in particular, when we'd have to work on an API for apps to select the proper one. IMHO, pick an algorithm that is suitable for all cases, and that's it. 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 Jan 21 14:19: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 28AEC3A683A for ; Fri, 21 Jan 2011 14:19:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.967 X-Spam-Level: X-Spam-Status: No, score=-105.967 tagged_above=-999 required=5 tests=[AWL=0.632, 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 gs3ROUB+9cLR for ; Fri, 21 Jan 2011 14:19:17 -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 338103A6822 for ; Fri, 21 Jan 2011 14:19:17 -0800 (PST) Received: from d01dlp02.pok.ibm.com (d01dlp02.pok.ibm.com [9.56.224.85]) by e7.ny.us.ibm.com (8.14.4/8.13.1) with ESMTP id p0LM2oiX011171 for ; Fri, 21 Jan 2011 17:02:50 -0500 Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by d01dlp02.pok.ibm.com (Postfix) with ESMTP id A959C4DE8042 for ; Fri, 21 Jan 2011 17:18:25 -0500 (EST) Received: from d03av06.boulder.ibm.com (d03av06.boulder.ibm.com [9.17.195.245]) by d01relay04.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id p0LMLlsx160602 for ; Fri, 21 Jan 2011 17:21:47 -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 p0LMQG78002477 for ; Fri, 21 Jan 2011 15:26:17 -0700 Received: from cichlid.raleigh.ibm.com (sig-9-76-146-211.mts.ibm.com [9.76.146.211]) by d03av06.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id p0LMQFwu002465 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 21 Jan 2011 15:26:16 -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 p0LMLio4022265; Fri, 21 Jan 2011 17:21:44 -0500 Message-Id: <201101212221.p0LMLio4022265@cichlid.raleigh.ibm.com> To: Fernando Gont Subject: Re: Psuedo-randomness in flow labels [was Re: [Fwd: I-D Action:draft-ietf-6man-flow-update-00.txt]] In-reply-to: <4D3A0337.9000300@gont.com.ar> References: <4CF82E6F.9040309@gmail.com> <4D08165A.3060306@gmail.com> <51661CE4-EC60-46B9-928C-D5763CFDF318@cisco.com> <4D082147.9010209@gmail.com> <4D2A1B84.1020003@gmail.com> <4D2A64A1.4030400@gmail.com> <201101101410.p0AEAPNs007778@cichlid.raleigh.ibm.com> <4D39BA68.3060304@gont.com.ar> <6A57A0BB-5574-45DA-8D1B-124E74AA5F5D@gmail.com> <4D39C13E.20103@gont.com.ar> <4D39DDBA.1070901@gmail.com> <201101211949.p0LJn8nh021448@cichlid.raleigh.ibm.com> <4D3A0337.9000300@gont.com.ar> Comments: In-reply-to Fernando Gont message dated "Fri, 21 Jan 2011 19:05:43 -0300." Date: Fri, 21 Jan 2011 17:21:44 -0500 From: Thomas Narten X-Content-Scanned: Fidelis XPS MAILER Cc: 6man , Bob Hinden , Brian E Carpenter , Fred Baker 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, 21 Jan 2011 22:19:18 -0000 Fernando Gont writes: > On 21/01/2011 04:49 p.m., Thomas Narten wrote: > > But other uses of the Flow Label outside of that do not have that > > requirement. > > > > So, if you do traditional flows, you have to be sure to generate Flow > > Labels carefully. The default usage outside of signaling does not > > have the same requirement. > Having two different FlowLabel generation algorithms does not sound like > a good approach to me (not that you're proposing that, though) -- in > particular, when we'd have to work on an API for apps to select the > proper one. You misunderstand me. For flows where the application wants special service, you can afford to have a more sophisticated algorithm. For the vast majority of applications, they won't set the flow label and will leave it to the OS to use heuristics (like each socket gets a different value). That is the case we are trying to make work with load balancers. These can use a much simpler default algorithm. And we need to allow for *very* simple devices, like sensor devices, etc. > IMHO, pick an algorithm that is suitable for all cases, and that's > it. I think it's fine to have a simple default. What I'm arguing against is making the default case more complicated than it really needs to be. We can have a more sophisticated algorithm in those cases where it actually matters, since those will not be the common case (if indeed, we ever develop standards in this area.) Thomas From fred@cisco.com Fri Jan 21 15:04: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 BA8CA3A67E4 for ; Fri, 21 Jan 2011 15:04:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.444 X-Spam-Level: X-Spam-Status: No, score=-110.444 tagged_above=-999 required=5 tests=[AWL=0.155, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 bG4dfmg3UXyW for ; Fri, 21 Jan 2011 15:04:49 -0800 (PST) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id 423D53A6804 for ; Fri, 21 Jan 2011 15:04:49 -0800 (PST) Authentication-Results: sj-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEADSgOU2rRN+J/2dsb2JhbACka3OhRJsahVAEhG+GMIMl Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-2.cisco.com with ESMTP; 21 Jan 2011 23:07:36 +0000 Received: from stealth-10-32-244-221.cisco.com (stealth-10-32-244-221.cisco.com [10.32.244.221]) by sj-core-3.cisco.com (8.13.8/8.14.3) with ESMTP id p0LN7VKD022487; Fri, 21 Jan 2011 23:07:35 GMT Received: from [127.0.0.1] by stealth-10-32-244-221.cisco.com (PGP Universal service); Fri, 21 Jan 2011 15:07:36 -0800 X-PGP-Universal: processed; by stealth-10-32-244-221.cisco.com on Fri, 21 Jan 2011 15:07:36 -0800 Subject: Re: Psuedo-randomness in flow labels [was Re: [Fwd: I-D Action:draft-ietf-6man-flow-update-00.txt]] Mime-Version: 1.0 (Apple Message framework v1082) From: Fred Baker In-Reply-To: <4D39DDBA.1070901@gmail.com> Date: Fri, 21 Jan 2011 15:07:22 -0800 Message-Id: <63E5CE50-0852-485B-9C04-A26F6DFCABB8@cisco.com> References: <4CF82E6F.9040309@gmail.com> <4D08165A.3060306@gmail.com> <51661CE4-EC60-46B9-928C-D5763CFDF318@cisco.com> <4D082147.9010209@gmail.com> <4D2A1B84.1020003@gmail.com> <4D2A64A1.4030400@gmail.com> <201101101410.p0AEAPNs007778@cichlid.raleigh.ibm.com> <4D39BA68.3060304@gont.com.ar> <6A57A0BB-5574-45DA-8D1B-124E74AA5F5D@gmail.com> <4D39C13E.20103@gont.com.ar> <4D39DDBA.1070901@gmail.com> To: Brian E Carpenter X-Mailer: Apple Mail (2.1082) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: Thomas Narten , 6man , 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: Fri, 21 Jan 2011 23:04:51 -0000 On Jan 21, 2011, at 11:25 AM, Brian E Carpenter wrote: > We seem to have agreed that the primary purpose of the flow label is > to facilitate load balancing, which is a statistical process. except when it is not a statistical process. From brian.e.carpenter@gmail.com Fri Jan 21 16:26: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 050CC3A6863 for ; Fri, 21 Jan 2011 16:26:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.461 X-Spam-Level: X-Spam-Status: No, score=-103.461 tagged_above=-999 required=5 tests=[AWL=0.138, 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 HKXbijxkhM3l for ; Fri, 21 Jan 2011 16:26:44 -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 1CEE03A685D for ; Fri, 21 Jan 2011 16:26:44 -0800 (PST) Received: by vws7 with SMTP id 7so1001221vws.31 for ; Fri, 21 Jan 2011 16:29:31 -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=/uhYHHKXtbNU0ndjQvTzIOu+p+xWSpRX7Dnk4SCp0Ug=; b=Vhl8Ilx0nO37AUJnTH8znm61BTmXbDC9H0aX284QX4J3ojtUoC0SGBe6UjyvmXOdgI J+wfZT5kY8JXHwp94lPSGvA419i4FqWbGz80gKyC6BuLlIDUm7KhqPYyB9LxY+A3pVLc NcLJZVUQXlJN9JKtJmSNGqF3KeaAH+OyecAR8= 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=TgffEs9XmnE09g2si9Dlb/P2xN+L9MkvqXT+mbu+13gFNSzq+NpYuCRQdVweAykbMy ABsQPh4EwYgPkWVs7NoDt3LRFdFd7fajmPKqZWcHUd/+kcIPQ+c1BP+rImjkRErGgSwI Dvior7NYoltrwPGO9NEoESN5YAcKPIqQEjv3A= Received: by 10.220.187.75 with SMTP id cv11mr365437vcb.77.1295656170943; Fri, 21 Jan 2011 16:29:30 -0800 (PST) Received: from [10.1.1.4] ([121.98.190.33]) by mx.google.com with ESMTPS id bq5sm3481470vcb.8.2011.01.21.16.29.28 (version=SSLv3 cipher=RC4-MD5); Fri, 21 Jan 2011 16:29:30 -0800 (PST) Message-ID: <4D3A24F1.9030507@gmail.com> Date: Sat, 22 Jan 2011 13:29:37 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Fred Baker Subject: Re: Psuedo-randomness in flow labels [was Re: [Fwd: I-D Action:draft-ietf-6man-flow-update-00.txt]] References: <4CF82E6F.9040309@gmail.com> <4D08165A.3060306@gmail.com> <51661CE4-EC60-46B9-928C-D5763CFDF318@cisco.com> <4D082147.9010209@gmail.com> <4D2A1B84.1020003@gmail.com> <4D2A64A1.4030400@gmail.com> <201101101410.p0AEAPNs007778@cichlid.raleigh.ibm.com> <4D39BA68.3060304@gont.com.ar> <6A57A0BB-5574-45DA-8D1B-124E74AA5F5D@gmail.com> <4D39C13E.20103@gont.com.ar> <4D39DDBA.1070901@gmail.com> <63E5CE50-0852-485B-9C04-A26F6DFCABB8@cisco.com> In-Reply-To: <63E5CE50-0852-485B-9C04-A26F6DFCABB8@cisco.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Thomas Narten , Bob Hinden , 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: Sat, 22 Jan 2011 00:26:45 -0000 On 2011-01-22 12:07, Fred Baker wrote: > On Jan 21, 2011, at 11:25 AM, Brian E Carpenter wrote: > >> We seem to have agreed that the primary purpose of the flow label is >> to facilitate load balancing, which is a statistical process. > > except when it is not a statistical process. Yes, I should have written, We seem to have agreed that the primary purpose of the flow label is to facilitate load balancing, which is commonly implemented as a statistical process. At least, I think that's where the conversation has taken us. Brian From bob.hinden@gmail.com Fri Jan 21 16:46: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 81E013A6864 for ; Fri, 21 Jan 2011 16:46:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.434 X-Spam-Level: X-Spam-Status: No, score=-103.434 tagged_above=-999 required=5 tests=[AWL=0.165, 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 zt8A9uJqSeEO for ; Fri, 21 Jan 2011 16:46:19 -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 3FDA23A685D for ; Fri, 21 Jan 2011 16:46:19 -0800 (PST) Received: by gxk27 with SMTP id 27so799057gxk.31 for ; Fri, 21 Jan 2011 16:49:06 -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=lCXiZGI7xjawWUD70PsegzrfdHB4beIGMe2+J9tfros=; b=XAWMAAZjD/oAVqV0w1Et8dhvreC8DfkiRTGF/sAQny3G+7QziZSGbJSYChS5GMmTf4 O53yN1fL4CW45gtI+5wpLk7KbgSvJ2PYux1N1N/XoEXKXiXZx0jHJ3EF4QHOwzW6cKxO AhaGuugNydShxn8MJj2zLoBiV9wUb1koqI8dY= 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=kkJQnpoGPbmH7tyg21RR+YsaYYoymf83s6pPdxS/hvHdaTZSTOdtpP/NjuQZYhQYki 68AqGAZfYBJR9I7rM5UarfY23Q4guE2d72NIXHTh0vrAVipOBPlprOLiuB75qY9Iea+J 8cbteYBanFlCUQw0k1ay80fFnXZ1P1Z8Jklg4= Received: by 10.150.219.10 with SMTP id r10mr1531275ybg.318.1295657346162; Fri, 21 Jan 2011 16:49:06 -0800 (PST) Received: from [172.16.224.217] ([209.97.127.34]) by mx.google.com with ESMTPS id u10sm810943yba.1.2011.01.21.16.49.04 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 21 Jan 2011 16:49:05 -0800 (PST) Subject: Re: Psuedo-randomness in flow labels [was Re: [Fwd: I-D Action:draft-ietf-6man-flow-update-00.txt]] Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Bob Hinden In-Reply-To: <4D3A24F1.9030507@gmail.com> Date: Fri, 21 Jan 2011 16:49:02 -0800 Content-Transfer-Encoding: 7bit Message-Id: <7EFB02D8-CF59-464E-A56A-9B975244239B@gmail.com> References: <4CF82E6F.9040309@gmail.com> <4D08165A.3060306@gmail.com> <51661CE4-EC60-46B9-928C-D5763CFDF318@cisco.com> <4D082147.9010209@gmail.com> <4D2A1B84.1020003@gmail.com> <4D2A64A1.4030400@gmail.com> <201101101410.p0AEAPNs007778@cichlid.raleigh.ibm.com> <4D39BA68.3060304@gont.com.ar> <6A57A0BB-5574-45DA-8D1B-124E74AA5F5D@gmail.com> <4D39C13E.20103@gont.com.ar> <4D39DDBA.1070901@gmail.com> <63E5CE50-0852-485B-9C04-A26F6DFCABB8@cisco.com> <4D3A24F1.9030507@gmail.com> To: Brian E Carpenter X-Mailer: Apple Mail (2.1082) Cc: Thomas Narten , 6man , Bob Hinden , Fred Baker 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, 22 Jan 2011 00:46:20 -0000 On Jan 21, 2011, at 4:29 PM, Brian E Carpenter wrote: > On 2011-01-22 12:07, Fred Baker wrote: >> On Jan 21, 2011, at 11:25 AM, Brian E Carpenter wrote: >> >>> We seem to have agreed that the primary purpose of the flow label is >>> to facilitate load balancing, which is a statistical process. >> >> except when it is not a statistical process. > > Yes, I should have written, > > We seem to have agreed that the primary purpose of the flow label is > to facilitate load balancing, which is commonly implemented as a > statistical process. > > At least, I think that's where the conversation has taken us. > That's my view as well. Bob From Internet-Drafts@ietf.org Sun Jan 30 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 703BF3A6B20; Sun, 30 Jan 2011 13:30:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.557 X-Spam-Level: X-Spam-Status: No, score=-102.557 tagged_above=-999 required=5 tests=[AWL=0.042, 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 OUeCt4ALMGQ5; Sun, 30 Jan 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 00C893A6AFC; Sun, 30 Jan 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-update-02.txt X-Test-IDTracker: no X-IETF-IDTracker: 3.11 Message-ID: <20110130213001.18925.71315.idtracker@localhost> Date: Sun, 30 Jan 2011 13: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: Sun, 30 Jan 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 : Rationale for update to the IPv6 flow label specification Author(s) : S. Amante, et al. Filename : draft-ietf-6man-flow-update-02.txt Pages : 11 Date : 2011-01-30 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-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-flow-update-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-01-30132458.I-D@ietf.org> --NextPart-- From brian.e.carpenter@gmail.com Sun Jan 30 13:40: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 3EAE43A6881 for ; Sun, 30 Jan 2011 13:40:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.475 X-Spam-Level: X-Spam-Status: No, score=-103.475 tagged_above=-999 required=5 tests=[AWL=0.124, 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 12qq7JubVdZ1 for ; Sun, 30 Jan 2011 13:40:26 -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 5AD653A6885 for ; Sun, 30 Jan 2011 13:40:26 -0800 (PST) Received: by gyd12 with SMTP id 12so2006676gyd.31 for ; Sun, 30 Jan 2011 13:43:38 -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=wdd6clB030tDAAX9yUXB5O+JLwPKYIfa6Rlri0IZGqY=; b=ieR48fhr+4rUqWe7LIQVG6DZ5kP6U65H4Cuz7casf0Vmqb+Q6lHWhdKAk8dnIZYDZ5 csQ8DGY85UHCEP9y7qaUjR2+ju+gwj5dBpYpsunIsgEX3P7qR9EK2UPMVOg+WEjBdgtx THtKUA5X7AEeTJ5Qvy41wr7GMp+JlnJq0bUOQ= 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=JWr6ace66ZaZ3z2DtiXzAwy5mwppngAIt26OKlBCARTDssHawZbFR+jjTz8wcBlRrV Dp+IiR9ywnZw8++7p8aDd+GriBBUlP1Kha/l8uST2iL9b56juc3Q+mEAP+MaIJs3kyan c+6PGl+CG1CnoDEpYA3worDpE4oiC+IvyQGZg= Received: by 10.90.10.34 with SMTP id 34mr7905801agj.157.1296423817860; Sun, 30 Jan 2011 13:43:37 -0800 (PST) Received: from [10.1.1.4] ([121.98.190.33]) by mx.google.com with ESMTPS id w4sm24992561anw.36.2011.01.30.13.43.35 (version=SSLv3 cipher=RC4-MD5); Sun, 30 Jan 2011 13:43:37 -0800 (PST) Message-ID: <4D45DB83.5060209@gmail.com> Date: Mon, 31 Jan 2011 10:43:31 +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-update-02.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: Sun, 30 Jan 2011 21:40:27 -0000 This update goes along with the first draft of 3697bis, which is coming as soon as the WG Chairs approve it to be posted. A full explanation and issues list will come after that. Brian -------- Original Message -------- Subject: I-D Action:draft-ietf-6man-flow-update-02.txt Date: Sun, 30 Jan 2011 13:30:01 -0800 From: 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 : Rationale for update to the IPv6 flow label specification Author(s) : S. Amante, et al. Filename : draft-ietf-6man-flow-update-02.txt Pages : 11 Date : 2011-01-30 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-02.txt From Internet-Drafts@ietf.org Sun Jan 30 19:00: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 CEF713A6B64; Sun, 30 Jan 2011 19:00:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.544 X-Spam-Level: X-Spam-Status: No, score=-102.544 tagged_above=-999 required=5 tests=[AWL=0.055, 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 nG0Dt7npUGTZ; Sun, 30 Jan 2011 19:00:02 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 40C713A69E2; Sun, 30 Jan 2011 19:00: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-00.txt X-Test-IDTracker: no X-IETF-IDTracker: 3.11 Message-ID: <20110131030002.15202.69077.idtracker@localhost> Date: Sun, 30 Jan 2011 19:00: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: Mon, 31 Jan 2011 03:00: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-00.txt Pages : 14 Date : 2011-01-30 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-00.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-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-01-30185426.I-D@ietf.org> --NextPart-- From brian.e.carpenter@gmail.com Sun Jan 30 19:33: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 DCAD23A6B76 for ; Sun, 30 Jan 2011 19:33:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.477 X-Spam-Level: X-Spam-Status: No, score=-103.477 tagged_above=-999 required=5 tests=[AWL=0.122, 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 pO9faNg1WIBx for ; Sun, 30 Jan 2011 19:33:42 -0800 (PST) Received: from mail-gw0-f44.google.com (mail-gw0-f44.google.com [74.125.83.44]) by core3.amsl.com (Postfix) with ESMTP id E3EEB3A6B74 for ; Sun, 30 Jan 2011 19:33:41 -0800 (PST) Received: by gwb20 with SMTP id 20so2114831gwb.31 for ; Sun, 30 Jan 2011 19:36:55 -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=E4dsGoM143NGgSNu4n3Ua6rE6PEln7P3ZSCEVw+7Xso=; b=myobi7BcXstPrwi7I85slHgjHMkat6y0kM/hymx686Teevg4H3ao55/ntYaXlSVnZy gXeiOL2DRWCConTDGhI8cGZHYcyAtvMEqgYaLnAx6y1ge4fCZFKMjbMGVjfz7od/dpfs rJmCtGmupN2YtzTOd9n59ftcf0TRbrkUarAWA= 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=N5bFE59aNB48ILaTaYAZLcuHiMFI6YZ+liN3xSQ4HmkHdbHuDd8Mlq7Vl9swc7Z5rm J98EM+p9N4S5gWq5d0hzrJTwR0bpnTzdUjh3ozoImmtO1s71Oo3l8EYQRAGzGeFYNH/E M9+hoDLBeg6FNxzH1oDlD0k5s3Ng3Ie3bxGV8= Received: by 10.100.154.12 with SMTP id b12mr3569618ane.22.1296445014801; Sun, 30 Jan 2011 19:36:54 -0800 (PST) Received: from [10.1.1.4] ([121.98.190.33]) by mx.google.com with ESMTPS id b27sm25342509ana.28.2011.01.30.19.36.52 (version=SSLv3 cipher=RC4-MD5); Sun, 30 Jan 2011 19:36:54 -0800 (PST) Message-ID: <4D462E51.3040408@gmail.com> Date: Mon, 31 Jan 2011 16:36:49 +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: RFC3697bis draft, and rationale, and open issues Content-Type: multipart/mixed; boundary="------------060307060109010408040101" 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, 31 Jan 2011 03:33:44 -0000 This is a multi-part message in MIME format. --------------060307060109010408040101 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Hi, As requested by the 6MAN chairs, we have posted a draft update of RFC 3697: http://www.ietf.org/internet-drafts/draft-ietf-6man-flow-3697bis-00.txt At the same time we have posted http://www.ietf.org/internet-drafts/draft-ietf-6man-flow-update-02.txt which is now a rationale document for the changes to RFC 3697. Our intention was to make only the changes to 3697 that are directly implied by the discussions on the previous -flow-update drafts**. However, while preparing the draft of 3697bis, we came up with quite a few open issues. The attached document lists them. If you'd like to comment on them, *please* set a subject that indicates which issue you are addressing. ** and we've included a trivial fix for an old problem with RFC 2205. Regards Brian + co-authors --------------060307060109010408040101 Content-Type: text/plain; name="flowIssues.txt" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="flowIssues.txt" T3BlbiBpc3N1ZXMgaW4gMzY5N2Jpcw0KDQotLS0tLS0tLS0tLS0tLQ0KSVNTVUUgMS4gQSBi YXNpYyBhc3N1bXB0aW9uIGluIFJGQyAzNjk3IGlzIHRoYXQgZmxvdyBsYWJlbGxpbmcgbWVj aGFuaXNtcyB3aWxsDQpiZSBzdGF0ZWZ1bCBhbmQgbWF5IG5lZWQgc2lnbmFsaW5nLiBUaGUg Y2hhbmdlcyBkaXNjdXNzZWQgaW4gdGhlIFdHIGNsZWFybHkNCmFkZHJlc3MgYSBzdGF0ZWxl c3MgYXBwcm9hY2ggdGhhdCBuZWVkcyBubyBzaWduYWxpbmcuDQoNClFVRVNUSU9OOiBkbyB3 ZSBrZWVwIHRoZSB0ZXh0IGFib3V0IGZsb3cgZXN0YWJsaXNobWVudCBtZXRob2RzLCBvciBk byB3ZSBzaW1wbHkNCnJlbW92ZSBpdCBhcyBiZWluZyByZWR1bmRhbnQ/IChUaGlzIGFmZmVj dHMgcXVpdGUgYSBsb3Qgb2YgdGV4dCBpbiB0aGUgZHJhZnQsDQphbmQgdGhlcmUgd2lsbCBi ZSBzZXZlcmFsIHNlY29uZGFyeSBpc3N1ZXMgdG8gZGlzY3VzcyBpZiB3ZSBrZWVwIHRoaXMg dGV4dC4pDQoNCi0tLS0tLS0tLS0tLS0tDQpJU1NVRSAyLiBSRkMgMzY5NyBzdGF0ZXMgdGhh dCBmbG93IGxhYmVsIHZhbHVlcyBtdXN0IGJlIHVuaXF1ZSAoZm9yIGEgZ2l2ZW4gYWRkcmVz cw0KcGFpciBhbmQgd2l0aGluIGEgY2VydGFpbiB0aW1lc2NhbGUpLiBUaGlzIHJlcXVpcmVz IHRoZSBub2RlIHRoYXQgc2V0cyB0aGUgbGFiZWwNCnRvIGtlZXAgYSBsaXN0IG9mIGxhYmVs cyBjdXJyZW50bHkgaW4gdXNlLiBUaGF0IGlzIGEgc2lnbmlmaWNhbnQgY29tcGxpY2F0aW9u DQpmb3IgYSAic3RhdGVsZXNzIiBpbXBsZW1lbnRhdGlvbi4gSWYgdGhlIG1haW4gdXNlIG9m IHRoZSBmbG93IGxhYmVsIGlzIGZvcg0KbG9hZCBkaXN0cmlidXRpb24sIG92ZXIgYSB2ZXJ5 IGxhcmdlIG51bWJlciBvZiBmbG93cywgc3RyaWN0IHVuaXF1ZW5lc3MNCmlzbid0IG5lZWRl ZCAtIGEgJ2JpcnRoZGF5IHBhcmFkb3gnIGxldmVsIG9mIGxhYmVsIGNvbGxpc2lvbnMgaXMg bm90IGEgcHJvYmxlbS4NCg0KUVVFU1RJT046IHNob3VsZCB0aGlzIHN0cmljdCB1bmlxdWVu ZXNzIHJlcXVpcmVtZW50IGJlIHJlbGF4ZWQgdG8gJ3VuaXF1ZSB3aXRoIGhpZ2gNCnByb2Jh YmlsaXR5Jy4NCg0KLS0tLS0tLS0tLS0tLS0NCklTU1VFIDMuIDM2OTdiaXMgUkVDT01NRU5E UyBwc2V1ZG8tcmFuZG9tIGZsb3cgbGFiZWwgdmFsdWVzLiBUaGUgZ29hbCBpcyBiZSBhYmxl IHRvIA0KdXNlIGp1c3QgdGhlIDMtdHVwbGUge2Rlc3QgYWRkciwgc291cmNlIGFkZHIsIGxh YmVsfSBhcyBpbnB1dCB0byBsb2FkDQpkaXN0cmlidXRpb24gaGFzaGVzLiBUaGVyZSBoYXZl IGJlZW4gYSBjb3VwbGUgb2Ygb2JqZWN0aW9ucyB0byB0aGlzOg0KIC0gVGhpcyBwcm9wZXJ0 eSBpcyBub3QgcmVxdWlyZWQgZm9yIGVmZmVjdGl2ZSBoYXNoZXMgZm9yIGxvYWQgZGlzdHJp YnV0aW9uOw0KIC0gTm90IGFsbCBsb2FkIGRpc3RyaWJ1dGlvbiBtZXRob2RzIGFyZSBzdGF0 aXN0aWNhbCwgc28gdGhlcmUgbWF5IGJlIHNvbWUgbmVlZCBmb3INCiAgIGRldGVybWluaXN0 aWMgZmxvdyBsYWJlbCB2YWx1ZXMuDQpPbiB0aGUgb3RoZXIgaGFuZCwgdGhlIGFyZ3VtZW50 cyBmb3IgZm9ybWFsbHkgcmVjb21tZW5kaW5nIHBzZXVkby1yYW5kb20gbGFiZWxzIGFyZQ0K dGhhdA0KIC0gcHNldWRvLXJhbmRvbW5lc3MgaGFzIHNlY3VyaXR5IHZhbHVlIChkcmFmdC1n b250LTZtYW4tZmxvd2xhYmVsLXNlY3VyaXR5KTsNCiAtIHBzZXVkby1yYW5kb21uZXNzIGRv ZXMgaGF2ZSB2YWx1ZSBhcyBpbnB1dCB0byBoYXNoZXM7DQogLSBhIE1BWSB3b3VsZCBub3Qg aGF2ZSBtdWNoIGltcGFjdCBvbiBpbXBsZW1lbnRlcnMsIHNvIG5vdGhpbmcgd291bGQgY2hh bmdlLg0KDQpRVUVTVElPTjogZG8gd2UgY2hhbmdlIHRoZSByZWNvbW1lbmRhdGlvbiB0byBz ZXQgcHNldWRvLXJhbmRvbSBmbG93IGxhYmVsIHZhbHVlcz8NCg0KLS0tLS0tLS0tLS0tLS0N CklTU1VFIDQuIFRoZSBJbnRyb2R1Y3Rpb24gcHJldmlvdXNseSBpbmNsdWRlZDoNCg0KICAg RG9pbmcgdGhpcyBbc2V0dGluZyB0aGUgZmxvdyBsYWJlbF0NCiAgIGVuYWJsZXMgbG9hZCBz cHJlYWRpbmcgYW5kIHJlY2VpdmVyIG9yaWVudGVkIHJlc291cmNlIGFsbG9jYXRpb24sIGZv cg0KICAgZXhhbXBsZS4gIA0KDQpUaGUgcGhyYXNlICJyZWNlaXZlciBvcmllbnRlZCByZXNv dXJjZSBhbGxvY2F0aW9uIiBoYXMgYmVlbiBkZWxldGVkIGJlY2F1c2UNCndlIGRvbid0IGtu b3cgd2hhdCBpdCBtZWFucy4NCg0KUVVFU1RJT046IElzIHRoaXMgZGVsZXRpb24gT0s/DQoN Ci0tLS0tLS0tLS0tLS0tDQpJU1NVRSA1LiBTZWN0aW9uIDIgc2F5czoNCg0KICAgSVB2NiBu b2RlcyBNVVNUIE5PVCBhc3N1bWUgdGhhdCB0aGUgRmxvdyBMYWJlbCB2YWx1ZSBpbiBhIGlu Y29taW5nDQogICBwYWNrZXQgaXMgaWRlbnRpY2FsIHRvIHRoZSB2YWx1ZSBzZXQgYnkgdGhl IHNvdXJjZSBub2RlLg0KDQpRVUVTVElPTjogVGhpcyBuZWVkcyB0byBiZSByZWNvbmNpbGVk IHdpdGggdGhlIHNlY3VyaXR5IHVzYWdlIG1lbnRpb25lZCBpbiANCmRyYWZ0LWdvbnQtLiBX b3VsZCBTSE9VTEQgTk9UIGJlIGFjY2VwdGFibGU/DQoNCi0tLS0tLS0tLS0tLS0tDQpJU1NV RSA2LiBBcyBub3RlZCBpbiBTZWN0aW9uIDM6DQoNClFVRVNUSU9OOiBTaG91bGQgd2UgaW5j b3Jwb3JhdGUgZHJhZnQtZ29udC0gaGVyZSwgb3IgbGVhdmUgaXQgc2VwYXJhdGU/DQoNCi0t LS0tLS0tLS0tLS0tDQpJU1NVRSA3LiBTZWN0aW9uIDUgc2F5czoNCg0KICAgVG8gZW5hYmxl IGFwcGxpY2F0aW9ucyBhbmQgdHJhbnNwb3J0IHByb3RvY29scyB0byBkZWZpbmUgd2hhdCBw YWNrZXRzDQogICBjb25zdGl0dXRlIGEgZmxvdywgdGhlIHNvdXJjZSBub2RlIE1VU1QgcHJv dmlkZSBtZWFucyBmb3IgdGhlDQogICBhcHBsaWNhdGlvbnMgYW5kIHRyYW5zcG9ydCBwcm90 b2NvbHMgdG8gc3BlY2lmeSB0aGUgRmxvdyBMYWJlbCB2YWx1ZXMNCiAgIHRvIGJlIHVzZWQg d2l0aCB0aGVpciBmbG93cy4gIFRoZSB1c2Ugb2YgdGhlIG1lYW5zIHRvIHNwZWNpZnkgRmxv dw0KICAgTGFiZWwgdmFsdWVzIGlzIHN1YmplY3QgdG8gYXBwcm9wcmlhdGUgcHJpdmlsZWdl cyAoc2VlIFNlY3Rpb24gNi4xKS4NCiAgIFRoZSBzb3VyY2Ugbm9kZSBTSE9VTEQgYmUgYWJs ZSB0byBzZWxlY3QgdW51c2VkIEZsb3cgTGFiZWwgdmFsdWVzIGZvcg0KICAgZmxvd3Mgbm90 IHJlcXVlc3RpbmcgYSBzcGVjaWZpYyB2YWx1ZSB0byBiZSB1c2VkLg0KDQpBcyBub3RlZCBh Ym92ZSwgaW4gc3RhdGVsZXNzIGxvYWQgZGlzdHJpYnV0aW9uLCBvY2Nhc2lvbmFsIGR1cGxp Y2F0ZSBsYWJlbHMNCnN1cmVseSBkb24ndCBtYXR0ZXIuIEFsc28sIGV4cGVyaWVuY2Ugc3Vn Z2VzdHMgdGhhdCBhcHBsaWNhdGlvbnMgYW5kDQp0cmFuc3BvcnQgcHJvdG9jb2xzIGFyZSB1 bmxpa2VseSB0byBkbyBhbnkgb2YgdGhpcywgYW5kIGl0IGlzbid0DQphIHByb3RvY29sIGRl c2lnbiBpc3N1ZSBhbnl3YXkuDQoNClFVRVNUSU9OOiBTaG91bGQgd2UgcmVkdWNlIHRoaXMg d2hvbGUgcGFyYWdyYXBoIHRvIGEgU0hPVUxEIG9yIE1BWSwgb3IgZXZlbg0KcmVtb3ZlIGl0 IGFzIG91dCBvZiBzY29wZSBpbiBhIHByb3RvY29sIHNwZWM/DQoNCi0tLS0tLS0tLS0tLS0t DQpJU1NVRSA4LiBTZWN0aW9uIDYuMSBzYXlzOg0KDQogICBPbmx5IGFwcGxpY2F0aW9ucyB3 aXRoIGFuIGFwcHJvcHJpYXRlIHByaXZpbGVnZSBpbiBhIHNlbmRpbmcgaG9zdA0KICAgd2ls bCBiZSBlbnRpdGxlZCB0byBzZXQgYSBub24temVybyBGbG93IExhYmVsLiAgTWVjaGFuaXNt cyBmb3IgdGhpcw0KICAgYXJlIG9wZXJhdGluZyBzeXN0ZW0gZGVwZW5kZW50LiAgUmVsYXRl ZCBwb2xpY3kgYW5kIGF1dGhvcml6YXRpb24NCiAgIG1lY2hhbmlzbXMgbWF5IGFsc28gYmUg cmVxdWlyZWQ7IGZvciBleGFtcGxlLCBpbiBhIG11bHRpLXVzZXIgaG9zdCwNCiAgIG9ubHkg c29tZSB1c2VycyBtYXkgYmUgZW50aXRsZWQgdG8gc2V0IHRoZSBGbG93IExhYmVsLiAgU3Vj aA0KICAgYXV0aG9yaXphdGlvbiBpc3N1ZXMgYXJlIG91dHNpZGUgdGhlIHNjb3BlIG9mIHRo aXMgc3BlY2lmaWNhdGlvbi4NCg0KUVVFU1RJT046IFNob3VsZCB0aGlzIGJlIHJlbW92ZWQg YXMgc3BlY3VsYXRpdmUgYW5kIG91dCBvZiBzY29wZSBpbiBhIA0KcHJvdG9jb2wgc3BlYz8N Cg0KLS0tLS0tLS0tLS0tLS0NCklTU1VFIDkuIFRoZSBjaGFuZ2VzIHRvIHNlY3Rpb24gMiBp bmNsdWRlIHRoaXMgcGFyYWdyYXBoLiBQbGVhc2UgcmVhZCBhbGwNCm9mIGl0LCBzaW5jZSB0 aGUgZmlyc3Qgc2VudGVuY2Ugb3V0IG9mIGNvbnRleHQgY2F1c2VzIGNvbmZ1c2lvbjoNCg0K ICAgMi4gIFRvIGVuYWJsZSBzdGF0ZWxlc3MgbG9hZCBkaXN0cmlidXRpb24gYXQgYW55IHBv aW50IGluIHRoZQ0KICAgICAgIEludGVybmV0LCBhIG5ldHdvcmsgZG9tYWluIE1VU1QgTk9U IGZvcndhcmQgcGFja2V0cyBvdXRzaWRlIHRoZQ0KICAgICAgIGRvbWFpbiB3aG9zZSBmbG93 IGxhYmVsIHZhbHVlcyBhcmUgb3RoZXIgdGhhbiB6ZXJvIG9yIHBzZXVkby0NCiAgICAgICBy YW5kb20uICBOZWl0aGVyIGRvbWFpbiBib3JkZXIgZWdyZXNzIHJvdXRlcnMgbm9yIGludGVy bWVkaWF0ZQ0KICAgICAgIHJvdXRlcnMvZGV2aWNlcyAodXNpbmcgYSBmbG93LWxhYmVsLCBm b3IgZXhhbXBsZSwgYXMgYSBwYXJ0IG9mIGFuDQogICAgICAgaW5wdXQta2V5IGZvciBhIGxv YWQtZGlzdHJpYnV0aW9uIGhhc2gpIGNhbiBkZXRlcm1pbmUgYnkNCiAgICAgICBpbnNwZWN0 aW9uIHRoYXQgYSB2YWx1ZSBpcyBub3QgcHNldWRvLXJhbmRvbS4gIFRoZXJlZm9yZSwgaWYN CiAgICAgICBub2RlcyB3aXRoaW4gYSBkb21haW4gaWdub3JlIHRoZSBhYm92ZSByZWNvbW1l bmRhdGlvbnMgdG8gc2V0DQogICAgICAgemVybyBvciBwc2V1ZG8tcmFuZG9tIGZsb3cgbGFi ZWwgdmFsdWVzLCBhbmQgc3VjaCBwYWNrZXRzIGFyZQ0KICAgICAgIGZvcndhcmRlZCBvdXRz aWRlIHRoZSBkb21haW4sIHRoaXMgd291bGQgbGlrZWx5IHJlc3VsdCBpbg0KICAgICAgIHVu ZGVzaXJhYmxlIG9wZXJhdGlvbmFsIGltcGxpY2F0aW9ucyAoZS5nLiwgY29uZ2VzdGlvbiwN CiAgICAgICByZW9yZGVyaW5nKSBmb3Igbm90IG9ubHkgdGhlIGluYXBwcm9wcmlhdGVseSBm bG93LWxhYmVsbGVkDQogICAgICAgcGFja2V0cywgYnV0IGFsc28gd2VsbC1iZWhhdmVkIGZs b3ctbGFiZWxsZWQgcGFja2V0cywgZHVyaW5nDQogICAgICAgZm9yd2FyZGluZyBhdCB2YXJp b3VzIGludGVybWVkaWF0ZSBkZXZpY2VzLiAgVGh1cywgYSBkb21haW4gbXVzdA0KICAgICAg IHByb3RlY3QgaXRzIHBlZXJzIGJ5IG5ldmVyIGV4cG9ydGluZyBpbmFwcHJvcHJpYXRlbHkg bGFiZWxsZWQNCiAgICAgICBwYWNrZXRzLiAgVGhpcyBkb2N1bWVudCBkb2VzIG5vdCBzcGVj aWZ5IHRoZSBtZXRob2QgZm9yIGVuZm9yY2luZw0KICAgICAgIHRoaXMgcnVsZS4gIFRoZSBz dWdnZXN0ZWQgd2F5IHRvIGVuZm9yY2UgaXQgaXMgdGhhdCBub2RlcyB3aXRoaW4NCiAgICAg ICBhIGRvbWFpbiBNVVNUIE5PVCBzZXQgdGhlIGZsb3cgbGFiZWwgdG8gYSBub24temVybyBh bmQgbm9uLQ0KICAgICAgIHBzZXVkby1yYW5kb20gbnVtYmVyIGlmIHRoZSBwYWNrZXQgd2ls bCBsZWF2ZSB0aGUgZG9tYWluLiAgSWYNCiAgICAgICB0aGlzIGlzIG5vdCBrbm93biB0byBi ZSB0aGUgY2FzZSwgdGhlIGJvcmRlciByb3V0ZXIgd2lsbCBuZWVkIHRvDQogICAgICAgY2hh bmdlIG91dGdvaW5nIGZsb3cgbGFiZWxzLg0KDQpXZSd2ZSBkZWJhdGVkIGFuZCB0dW5lZCB0 aGlzIG92ZXIgc2V2ZXJhbCB2ZXJzaW9ucyBvZiB0aGUgcHJlZGVjZXNzb3INCmRyYWZ0LiBC dXQgdGhlcmUgYXJlIHN0aWxsIG9iamVjdGlvbnMsIHN1Y2ggYXM6DQogLSBNVVNUIGlzIHRv byBzdHJvbmcsIGlmIHRoZSBkb3duc3RyZWFtIG9wZXJhdG9yIGRvZXNuJ3QgY2FyZSBhYm91 dA0KICAgdGhlIGZsb3cgbGFiZWw7DQogLSBXZSBkb24ndCBmdWxseSBzcGVjaWZ5IHdoYXQg dGhlIGJvcmRlciByb3V0ZXJzIG11c3QgZG87DQogLSBXZSBzaG91bGQgbW9yZSBmdWxseSBz cGVjaWZ5IHdoYXQgdGhhdCBob3N0cyBtdXN0IGRvLg0KVGhlIGFyZ3VtZW50IGZvciBNVVNU IGlzIHRoYXQgd2Ugc2hvdWRuJ3QgYWxsb3cgYW4gb3BlcmF0b3INCnRvIHNlbmQgcGFja2V0 cyBpbnRvIHRoZSBvcGVuIEludGVybmV0IHdpdGggYmFkbHkgZm9ybWVkIGZsb3cgbGFiZWxz Lg0KRnJvbSB0aGUgSW50ZXJuZXQncyB2aWV3cG9pbnQsIHdlIGRvbid0IGNhcmUgd2hldGhl ciB0aGUgYm9yZGVyIHJvdXRlcg0KZGlzY2FyZHMgcGFja2V0cywgY2xlYXJzIHRoZSBsYWJl bCB0byB6ZXJvLCBvciBjbGFzc2lmaWVzIHBhY2tldHMgYW5kDQpzZXRzIGEgbmV3IHBzZXVk by1yYW5kb20gbGFiZWwuIEFuZCBpZiBhIGhvc3QgZG9lc24ndCBkbyB3aGF0IGlzIGFscmVh ZHkNCnJlY29tbWVuZGVkLCB3ZSBkb24ndCBjYXJlIHdoYXQgaXQgZG9lczsgdGhlIGJvcmRl ciByb3V0ZXIgaGFzIHRvDQpoaWRlIGl0Lg0KDQpRVUVTVElPTjogU2hvdWxkIHdlLCBhbmQg Y2FuIHdlLCBmdXJ0aGVyIGltcHJvdmUgdGhpcyB0ZXh0Pw0KDQotLS0tLS0tLS0tLS0tLQ0K SVNTVUUgMTAuIFNlY3Rpb24gMiBhbHNvIHNheXM6DQoNCiAgIEZvcndhcmRpbmcgbm9kZXMg c3VjaCBhcyByb3V0ZXJzIGFuZCBsb2FkIGJhbGFuY2VycyBNVVNUIE5PVCBkZXBlbmQNCiAg IG9ubHkgb24gRmxvdyBMYWJlbCB2YWx1ZXMgYmVpbmcgcmFuZG9tbHkgZGlzdHJpYnV0ZWQu ICBJbiBhbnkgdXNhZ2UNCiAgIHN1Y2ggYXMgYSBoYXNoIGtleSBmb3IgbG9hZCBiYWxhbmNp bmcsIHRoZSBGbG93IExhYmVsIGJpdHMgTVVTVCBiZQ0KICAgY29tYmluZWQgd2l0aCBiaXRz IGZyb20gb3RoZXIgc291cmNlcyB3aXRoaW4gdGhlIHBhY2tldCwgc28gYXMgdG8NCiAgIHBy b2R1Y2UgYSBzdWl0YWJsZSBkaXN0cmlidXRpb24gb2YgaGFzaCB2YWx1ZXMuDQoNCldoeSBp cyBpdCByZXN0cmljdGVkIHRvICJ3aXRoaW4gdGhlIHBhY2tldCI/IENvdWxkbid0IHRoZSBs b2FkIGJhbGFuY2VyDQp1c2Ugc29tZXRoaW5nIGVsc2UgdG9vLCBlc3BlY2lhbGx5IGZvciBh IHN0YXRlZnVsIG1lY2hhbmlzbT8NCg0KUVVFU1RJT046IFNob3VsZCAid2l0aGluIHRoZSBw YWNrZXQiIGJlIGRlbGV0ZWQ/DQoNCi0tLS0tLS0tLS0tLS0tDQpJU1NVRSAxMS4gSW4gc2Vj dGlvbiAzOg0KDQogICBBIG5vZGUgdGhhdCBmb3J3YXJkcyBhIGZsb3cgd2hvc2UgZmxvdyBs YWJlbCB2YWx1ZSBpbiBhcnJpdmluZw0KICAgcGFja2V0cyBpcyB6ZXJvIE1BWSBzZXQgdGhl IGZsb3cgbGFiZWwgdmFsdWUuICBJbiB0aGF0IGNhc2UsIGl0IGlzDQogICBSRUNPTU1FTkRF RCB0aGF0IHRoZSBmb3J3YXJkaW5nIG5vZGUgc2V0cyB0aGUgZmxvdyBsYWJlbCBmaWVsZCBm b3IgYQ0KICAgZmxvdyB0byBhIHBzZXVkby1yYW5kb20gdmFsdWUuDQoNClFVRVNUSU9OOiBT aG91bGQgd2Ugc3VnZ2VzdCBob3cgdGhlIGZvcndhcmRpbmcgbm9kZSBpZGVudGlmaWVzIHBh Y2tldHMgYmVsb25naW5nDQp0byB0aGUgc2FtZSBmbG93PyAoZHJhZnQtaWV0Zi02bWFuLWZs b3ctZWNtcCB0YWxrcyBhYm91dCB0aGlzLikNCg0KLS0NCg0KDQoNCg0KDQoNCg== --------------060307060109010408040101-- From brian.e.carpenter@gmail.com Sun Jan 30 19:46: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 806FE3A6B7F for ; Sun, 30 Jan 2011 19:46:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.478 X-Spam-Level: X-Spam-Status: No, score=-103.478 tagged_above=-999 required=5 tests=[AWL=0.121, 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 2uxETD3VVfZB for ; Sun, 30 Jan 2011 19:46:41 -0800 (PST) Received: from mail-gw0-f44.google.com (mail-gw0-f44.google.com [74.125.83.44]) by core3.amsl.com (Postfix) with ESMTP id B59713A6B7E for ; Sun, 30 Jan 2011 19:46:41 -0800 (PST) Received: by gwb20 with SMTP id 20so2117973gwb.31 for ; Sun, 30 Jan 2011 19:49:54 -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=yQyBb8QQeInLVr0EaCPNlzHNYowSIGxxfAKAZ2X+8CE=; b=drpclL1iN479U+4OJIps0gAPEuz6wn5XQeQa129QRn1WkFmV2Z5GpFcD+clJow5f1s b2A6i3t6o/p447qOs8e0uDLzEHaolXDgcFo0W93IlqvFbEzxfw11E/Myrw6/4FGagBfT FKi4cqQkdB08WNBZZuR2qX9lH9S08ndyw0BfA= 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=R8tycDhb8Cr/NwZrIeXG+WJsyCgUZH1PyKu+NJ/eLlPjdWOuT8yucYi835nukWSUmH 3rw7rEkafAmt68/5J14lmyv99FWTwbEDMxN2XYfBD4/PGClf54a+d28apGjaxh7kZody H/rc+416bibkOkx2q8tyBJzgPQlQOuMs68aKc= Received: by 10.151.157.20 with SMTP id j20mr4430297ybo.267.1296445794660; Sun, 30 Jan 2011 19:49:54 -0800 (PST) Received: from [10.1.1.4] ([121.98.190.33]) by mx.google.com with ESMTPS id k1sm13208125ybj.12.2011.01.30.19.49.52 (version=SSLv3 cipher=RC4-MD5); Sun, 30 Jan 2011 19:49:54 -0800 (PST) Message-ID: <4D46315C.3050806@gmail.com> Date: Mon, 31 Jan 2011 16:49:48 +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: 3697bis diffs 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: Mon, 31 Jan 2011 03:46:42 -0000 Here's a URL that will give you the diffs between RFC 3697 and draft-ietf-6man-flow-3697bis-00.txt. http://tinyurl.com/3697bis00-diffs -- Regards Brian Carpenter From jarno.rajahalme@nsn.com Mon Jan 31 04:27:03 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 246BF3A6B32 for ; Mon, 31 Jan 2011 04:27:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[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 7LwnT+B9Zeen for ; Mon, 31 Jan 2011 04:27:02 -0800 (PST) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by core3.amsl.com (Postfix) with ESMTP id 36F033A696D for ; Mon, 31 Jan 2011 04:27:01 -0800 (PST) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id p0VCUCkw031952 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 31 Jan 2011 13:30:12 +0100 Received: from fi-sateri014176.emea.nsn-net.net ([10.144.14.176]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id p0VCUBAs005665; Mon, 31 Jan 2011 13:30:11 +0100 Subject: RFC3697bis Open issues 1 & 2 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Jarno Rajahalme In-Reply-To: <4D462E51.3040408@gmail.com> Date: Mon, 31 Jan 2011 14:30:19 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4D462E51.3040408@gmail.com> To: ext Brian E Carpenter X-Mailer: Apple Mail (2.1082) 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: Mon, 31 Jan 2011 12:27:03 -0000 Brian, Here is my take on the issues 1 & 2: > Open issues in 3697bis >=20 > -------------- > ISSUE 1. A basic assumption in RFC 3697 is that flow labelling = mechanisms will > be stateful and may need signaling. The changes discussed in the WG = clearly > address a stateless approach that needs no signaling. >=20 > QUESTION: do we keep the text about flow establishment methods, or do = we simply > remove it as being redundant? (This affects quite a lot of text in the = draft, > and there will be several secondary issues to discuss if we keep this = text.) >=20 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. If the changes lead to a situation where it is common that labels set by = the source are inconsistently changed in transit, it may be futile to = even try classifying based on such ephemeral labels. In this regard the = bis text is ambiguous. In one hand it says that the label, once set to a = non-zero value, MUST be delivered unchanged to the destination(s), but = elsewhere is says that domains MUST NOT export any other label values = than zero or "pseudo-random". IMO the only practical way to ensure = pseudo-randomness on domain exit is to overwrite the value with a new = pseudo-random value, hence the contradiction. One possible way forward in this regard is to mandate that any = domain-exit rewrite be consistent, in practice mapping the received = non-zero value for a flow to a consistent new pseudo-random value. The = rationale for the mapping is to get from a possibly skewed short = time-scale distribution (1,2,3,...) to an approximately even = pseudo-random distribution, also over short time-scales. This should be = easily doable with a router-specific key and pseudo random generator = that takes the previous flow label value as an input (in addition to the = source and destination addresses), always producing the same output for = the same set of input parameters and key. Also, I'd keep the possibility for flow state establishment methods, but = drop the text relating to an API by which applications can set the flow = label value, as this is in direct conflict with the new pseudo-random = requirement. This includes dropping all text relating to any quarantine = periods, as the pseudo-random requirement already provides a very high = likelihood that there is practically no short time-scale reuse of flow = label values. > -------------- > ISSUE 2. RFC 3697 states that flow label values must be unique (for a = given address > pair and within a certain timescale). This requires the node that sets = the label > to keep a list of labels currently in use. That is a significant = complication > for a "stateless" implementation. If the main use of the flow label is = for > load distribution, over a very large number of flows, strict = uniqueness > isn't needed - a 'birthday paradox' level of label collisions is not a = problem. >=20 > QUESTION: should this strict uniqueness requirement be relaxed to = 'unique with high > probability'. =46rom RFC 3697: "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." The only real requirement above is that a random initial value (seed) be = used for any sequence (which could also be a pseudo-random sequence). = Sounds pretty stateless for me. Also, the "uniqueness requirement" in RFC 3697 is actually a requirement = to "MUST ensure that recently used label values are not unintentionally = reused" for other flows, as defined by the source node. My suggestion is to change the requirement to: "A node setting a Flow Label value SHOULD ensure, with a high = probability, that it does not unintentionally reuse recently used Flow Label values." Note: text about 120 second quarantine period is dropped. These = previously two separate paragraphs could now be combined: "A node setting a Flow Label value SHOULD ensure, with a high = probability, that it does not unintentionally reuse recently used Flow Label = values for any given pair of source and destination address. To avoid such accidental Flow Label value reuse, a node setting a Flow = Label value SHOULD select new values in a well-defined pseudo-random sequence and use = random seed values that avoid 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 SHOULD be used." A new requirement could be added to keep the assigned values consistent: "Flow Label values MUST be set consistently. When there is a previous = non-zero Flow Label value, the new pseudo-random value MUST be the same = for all packets for the same set of source and destination addresses and = the previous Flow Label value. When the previous Flow Label value is = zero, the requirement is that the assigned pseudo-random Flow Label = value be the same for all packets with the same 5-tuple (source and = destination addresses and port numbers, and the transport protocol = number)." The above rule could be applied in all nodes setting the flow label = values (source, access router, domain exit). Regards, Jarno From jarno.rajahalme@nsn.com Mon Jan 31 04:37: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 0B8813A6911 for ; Mon, 31 Jan 2011 04:37:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[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 xAI8TEH4Xpyd for ; Mon, 31 Jan 2011 04:37:39 -0800 (PST) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by core3.amsl.com (Postfix) with ESMTP id EE7233A68A7 for ; Mon, 31 Jan 2011 04:37:38 -0800 (PST) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id p0VCepYI028920 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 31 Jan 2011 13:40:51 +0100 Received: from fi-sateri014176.emea.nsn-net.net ([10.144.14.176]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id p0VCeoE9018275; Mon, 31 Jan 2011 13:40:51 +0100 Subject: RFC 3697bis Open Issue 3 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Jarno Rajahalme In-Reply-To: <4D46315C.3050806@gmail.com> Date: Mon, 31 Jan 2011 14:40:58 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4D46315C.3050806@gmail.com> To: ext Brian E Carpenter X-Mailer: Apple Mail (2.1082) 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: Mon, 31 Jan 2011 12:37:40 -0000 Issue 3: > ISSUE 3. 3697bis RECOMMENDS pseudo-random flow label values. The goal = is be able to=20 > use just the 3-tuple {dest addr, source addr, label} as input to load > distribution hashes. There have been a couple of objections to this: > - This property is not required for effective hashes for load = distribution; > - Not all load distribution methods are statistical, so there may be = some need for > deterministic flow label values. > On the other hand, the arguments for formally recommending = pseudo-random labels are > that > - pseudo-randomness has security value = (draft-gont-6man-flowlabel-security); > - pseudo-randomness does have value as input to hashes; > - a MAY would not have much impact on implementers, so nothing would = change. >=20 > QUESTION: do we change the recommendation to set pseudo-random flow = label values? >=20 Change the recommendation to set pseudo-random flow label values, but = also add that all possible re-setting of the value (e.g. on domain exit) = be consistent (i.e. a mapping). This mapping can provide the desired = randomization of the used label values. Also, this concept can naturally = be extended to the case of zero label. In this case the mapping needs to = be consistent for the input packet's 5-tuple.=20 I provided a text proposal to this effect on the mail about issue 1 & 2. Jarno= From jarno.rajahalme@nsn.com Mon Jan 31 04:45: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 E903C3A6BEE for ; Mon, 31 Jan 2011 04:45:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[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 n+1kjwjnRJ9s for ; Mon, 31 Jan 2011 04:45:26 -0800 (PST) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by core3.amsl.com (Postfix) with ESMTP id BAFF83A6BED for ; Mon, 31 Jan 2011 04:45:25 -0800 (PST) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id p0VCmcOX017855 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 31 Jan 2011 13:48:38 +0100 Received: from fi-sateri014176.emea.nsn-net.net ([10.144.14.176]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id p0VCmcX5018148; Mon, 31 Jan 2011 13:48:38 +0100 Subject: RFC 3697bis Open issue 4 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Jarno Rajahalme In-Reply-To: <4D46315C.3050806@gmail.com> Date: Mon, 31 Jan 2011 14:48:45 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4D46315C.3050806@gmail.com> To: ext Brian E Carpenter X-Mailer: Apple Mail (2.1082) 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: Mon, 31 Jan 2011 12:45:27 -0000 > ISSUE 4. The Introduction previously included: >=20 > Doing this [setting the flow label] > enables load spreading and receiver oriented resource allocation, = for > example. =20 >=20 > The phrase "receiver oriented resource allocation" has been deleted = because > we don't know what it means. >=20 > QUESTION: Is this deletion OK? Full context: "The minimum level of IPv6 flow support consists of labeling the=09 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.= From jarno.rajahalme@nsn.com Mon Jan 31 04:48: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 AF4423A6BF2 for ; Mon, 31 Jan 2011 04:48:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[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 6pKkWu7xToor for ; Mon, 31 Jan 2011 04:48:17 -0800 (PST) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by core3.amsl.com (Postfix) with ESMTP id 9FB293A6BF0 for ; Mon, 31 Jan 2011 04:48:16 -0800 (PST) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id p0VCpShL025357 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 31 Jan 2011 13:51:29 +0100 Received: from fi-sateri014176.emea.nsn-net.net ([10.144.14.176]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id p0VCpSjN028997; Mon, 31 Jan 2011 13:51:28 +0100 Subject: RFC3697bis Open Issue 5 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Jarno Rajahalme In-Reply-To: <4D46315C.3050806@gmail.com> Date: Mon, 31 Jan 2011 14:51:36 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <05834D09-0E37-497D-B1E6-3F008E98AECB@nsn.com> References: <4D46315C.3050806@gmail.com> To: ext Brian E Carpenter X-Mailer: Apple Mail (2.1082) 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: Mon, 31 Jan 2011 12:48:17 -0000 > ISSUE 5. Section 2 says: >=20 > IPv6 nodes MUST NOT assume that the Flow Label value in a incoming > packet is identical to the value set by the source node. >=20 > QUESTION: This needs to be reconciled with the security usage = mentioned in=20 > draft-gont-. Would SHOULD NOT be acceptable? IMO "MUST NOT" is proper. What is the case where the receiver COULD = assume the flow label to be identical to the value set by the source = node? Jarno= From jarno.rajahalme@nsn.com Mon Jan 31 04:52: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 355E13A6C00 for ; Mon, 31 Jan 2011 04:52:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[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 kXlCsdHNxGMN for ; Mon, 31 Jan 2011 04:52:52 -0800 (PST) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by core3.amsl.com (Postfix) with ESMTP id 2AFF83A6BAB for ; Mon, 31 Jan 2011 04:52:52 -0800 (PST) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id p0VCu48w006244 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 31 Jan 2011 13:56:04 +0100 Received: from fi-sateri014176.emea.nsn-net.net ([10.144.14.176]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id p0VCu4GD012110; Mon, 31 Jan 2011 13:56:04 +0100 Subject: RFC 3697bis Open Issues 7 & 8 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Jarno Rajahalme In-Reply-To: <4D46315C.3050806@gmail.com> Date: Mon, 31 Jan 2011 14:56:12 +0200 Content-Transfer-Encoding: 7bit Message-Id: <5D328F02-0C12-4316-8ADD-0150A4A4AC6C@nsn.com> References: <4D46315C.3050806@gmail.com> To: ext Brian E Carpenter X-Mailer: Apple Mail (2.1082) 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: Mon, 31 Jan 2011 12:52:53 -0000 > ISSUE 7. Section 5 says: > > 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 6.1). > The source node SHOULD be able to select unused Flow Label values for > flows not requesting a specific value to be used. > > As noted above, in stateless load distribution, occasional duplicate labels > surely don't matter. Also, experience suggests that applications and > transport protocols are unlikely to do any of this, and it isn't > a protocol design issue anyway. > > QUESTION: Should we reduce this whole paragraph to a SHOULD or MAY, or even > remove it as out of scope in a protocol spec? OK for deletion. See also response to Open issues 1 & 2. IMO the pseudo-random mandate makes the above text irrelevant. > > -------------- > ISSUE 8. Section 6.1 says: > > Only applications with an appropriate privilege in a sending host > will be entitled to set a non-zero Flow Label. Mechanisms for this > are operating system dependent. Related policy and authorization > mechanisms may also be required; for example, in a multi-user host, > only some users may be entitled to set the Flow Label. Such > authorization issues are outside the scope of this specification. > > QUESTION: Should this be removed as speculative and out of scope in a > protocol spec? > Ditto. Jarno From jarno.rajahalme@nsn.com Mon Jan 31 05:04: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 BD3953A6BFB for ; Mon, 31 Jan 2011 05:04:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 vA2f1oHboRTT for ; Mon, 31 Jan 2011 05:03:59 -0800 (PST) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by core3.amsl.com (Postfix) with ESMTP id 65B133A694A for ; Mon, 31 Jan 2011 05:03:59 -0800 (PST) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id p0VD76ad004524 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 31 Jan 2011 14:07:06 +0100 Received: from fi-sateri014176.emea.nsn-net.net ([10.144.14.176]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id p0VD757F017107; Mon, 31 Jan 2011 14:07:05 +0100 Subject: RFC 3697bis Open issue 9 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Jarno Rajahalme In-Reply-To: <4D46315C.3050806@gmail.com> Date: Mon, 31 Jan 2011 15:07:13 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <23233BB6-C4D8-414F-A079-5A53B9A49AFF@nsn.com> References: <4D46315C.3050806@gmail.com> To: ext Brian E Carpenter X-Mailer: Apple Mail (2.1082) 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: Mon, 31 Jan 2011 13:04:00 -0000 > ISSUE 9. The changes to section 2 include this paragraph. Please read = all > of it, since the first sentence out of context causes confusion: >=20 > 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. 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. 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) 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. 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. >=20 > We've debated and tuned this over several versions of the predecessor > draft. But there are still objections, such as: > - MUST is too strong, if the downstream operator doesn't care about > the flow label; > - We don't fully specify what the border routers must do; > - We should more fully specify what that hosts must do. > The argument for MUST is that we shoudn't allow an operator > to send packets into the open Internet with badly formed flow labels. > =46rom the Internet's viewpoint, we don't care whether the border = router > discards packets, clears the label to zero, or classifies packets and > sets a new pseudo-random label. And if a host doesn't do what is = already > recommended, we don't care what it does; the border router has to > hide it. >=20 > QUESTION: Should we, and can we, further improve this text? The fact remains that the receiving domain cannot trust the previous = domain to have done the right thing. Therefore: "If (and only if) the receiving domain makes such use of flow label = values, that would benefit from an even pseudo-random distribution, the = ingress routers of such domain SHOULD map the received flow labels to = new, pseudo-random values. The new values MUST be the same for all = packets of any received flow, identified either by a non-zero flow label = value (with the source and destination addresses), or, if the received = flow label value is zero, by the 5-tuple of the received packet." I would remove text about domains protecting their neighbors. Jarno= From jarno.rajahalme@nsn.com Mon Jan 31 05:10: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 5F72A3A6C08 for ; Mon, 31 Jan 2011 05:10:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[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 BWFccFIFhFXd for ; Mon, 31 Jan 2011 05:10:41 -0800 (PST) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by core3.amsl.com (Postfix) with ESMTP id 357053A6BEC for ; Mon, 31 Jan 2011 05:10:41 -0800 (PST) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id p0VDDreQ024042 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 31 Jan 2011 14:13:53 +0100 Received: from fi-sateri014176.emea.nsn-net.net ([10.144.14.176]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id p0VDDrio008231; Mon, 31 Jan 2011 14:13:53 +0100 Subject: RFC 3697bis Open Issues 10 & 11 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Jarno Rajahalme In-Reply-To: <4D46315C.3050806@gmail.com> Date: Mon, 31 Jan 2011 15:14:01 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <04AF0A94-FF05-4407-BF79-742C8C9B2513@nsn.com> References: <4D46315C.3050806@gmail.com> To: ext Brian E Carpenter X-Mailer: Apple Mail (2.1082) 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: Mon, 31 Jan 2011 13:10:42 -0000 > ISSUE 10. Section 2 also says: >=20 > Forwarding nodes such as routers and load balancers MUST NOT depend > only on Flow Label values being randomly distributed. In any usage > such as a hash key for load balancing, the Flow Label bits MUST be > combined with bits from other sources within the packet, so as to > produce a suitable distribution of hash values. >=20 > Why is it restricted to "within the packet"? Couldn't the load = balancer > use something else too, especially for a stateful mechanism? >=20 > QUESTION: Should "within the packet" be deleted? >=20 "within the packet" ensures consistency, if it refers to address fields. = Also, it does not mean ONLY, i.e. other sources (such as a local key) = are not excluded. However, don't see how a protocol spec could mandate = how a router internal hashing is implemented. At best we could say = "SHOULD". > -------------- > ISSUE 11. In section 3: >=20 > A node that forwards a flow whose flow label value in arriving > packets is zero MAY set the flow label value. In that case, it is > RECOMMENDED that the forwarding node sets the flow label field for = a > flow to a pseudo-random value. >=20 > QUESTION: Should we suggest how the forwarding node identifies packets = belonging > to the same flow? (draft-ietf-6man-flow-ecmp talks about this.) Yes. See also my response to issue 9. Jarno= From jmh@joelhalpern.com Mon Jan 31 06:14: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 047EA3A6BED for ; Mon, 31 Jan 2011 06:14:37 -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 UaKIrDe3JBuQ for ; Mon, 31 Jan 2011 06:14:36 -0800 (PST) Received: from hgblob.out.tigertech.net (hgblob.out.tigertech.net [74.114.88.71]) by core3.amsl.com (Postfix) with ESMTP id 241EB3A6B32 for ; Mon, 31 Jan 2011 06:14:36 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hgblob.tigertech.net (Postfix) with ESMTP id C7AC6325AD0E; Mon, 31 Jan 2011 06:17:50 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from [192.35.166.101] (JMHWork.dhcp.nanog.merit.net [192.35.166.101]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by hgblob.tigertech.net (Postfix) with ESMTPSA id 4B2F2325400A; Mon, 31 Jan 2011 06:17:50 -0800 (PST) Message-ID: <4D46C48B.1060806@joelhalpern.com> Date: Mon, 31 Jan 2011 09:17:47 -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: Jarno Rajahalme Subject: Re: RFC 3697bis Open issue 9 References: <4D46315C.3050806@gmail.com> <23233BB6-C4D8-414F-A079-5A53B9A49AFF@nsn.com> In-Reply-To: <23233BB6-C4D8-414F-A079-5A53B9A49AFF@nsn.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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: Mon, 31 Jan 2011 14:14:37 -0000 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. Yours, Joel M. Halpern On 1/31/2011 8:07 AM, Jarno Rajahalme wrote: > >> ISSUE 9. The changes to section 2 include this paragraph. Please read all >> of it, since the first sentence out of context causes confusion: >> >> 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. 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. 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) 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. 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. >> >> We've debated and tuned this over several versions of the predecessor >> draft. But there are still objections, such as: >> - MUST is too strong, if the downstream operator doesn't care about >> the flow label; >> - We don't fully specify what the border routers must do; >> - We should more fully specify what that hosts must do. >> The argument for MUST is that we shoudn't allow an operator >> to send packets into the open Internet with badly formed flow labels. >> From the Internet's viewpoint, we don't care whether the border router >> discards packets, clears the label to zero, or classifies packets and >> sets a new pseudo-random label. And if a host doesn't do what is already >> recommended, we don't care what it does; the border router has to >> hide it. >> >> QUESTION: Should we, and can we, further improve this text? > > The fact remains that the receiving domain cannot trust the previous domain to have done the right thing. Therefore: > > "If (and only if) the receiving domain makes such use of flow label values, that would benefit from an even pseudo-random distribution, the ingress routers of such domain SHOULD map the received flow labels to new, pseudo-random values. The new values MUST be the same for all packets of any received flow, identified either by a non-zero flow label value (with the source and destination addresses), or, if the received flow label value is zero, by the 5-tuple of the received packet." > > I would remove text about domains protecting their neighbors. > > Jarno > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > From jarno.rajahalme@nsn.com Mon Jan 31 06:39: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 6D41B3A6C11 for ; Mon, 31 Jan 2011 06:39:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 GswuguzmEM35 for ; Mon, 31 Jan 2011 06:39:08 -0800 (PST) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by core3.amsl.com (Postfix) with ESMTP id 17E823A6BFF for ; Mon, 31 Jan 2011 06:39:07 -0800 (PST) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id p0VEgJbP027381 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 31 Jan 2011 15:42:20 +0100 Received: from fi-sateri014176.emea.nsn-net.net ([10.144.14.176]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id p0VEgJlu010351; Mon, 31 Jan 2011 15:42:19 +0100 Subject: Re: RFC 3697bis Open issue 9 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Jarno Rajahalme In-Reply-To: <4D46C48B.1060806@joelhalpern.com> Date: Mon, 31 Jan 2011 16:42:27 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4D46315C.3050806@gmail.com> <23233BB6-C4D8-414F-A079-5A53B9A49AFF@nsn.com> <4D46C48B.1060806@joelhalpern.com> To: "ext Joel M. Halpern" X-Mailer: Apple Mail (2.1082) 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: Mon, 31 Jan 2011 14:39:09 -0000 Joel, I did not intend to propose that domain-ingress remarking should be = mandatory. If the receiving domain does not critically depend on the received flow = label values to be very smoothly distributed, then it has no need for = remarking at all. My point is simply just that IF there is a specific requirement on the = distribution of the flow label values, the domain must either provide = such distribution itself, or trust someone else to have done that = already. Maybe this is self-evident, and need not be mentioned in a = protocol spec? It would be way simpler to allow marking only once (from a non-zero = value), with a "pseudo-random" recommendation, and then have the rest of = the path just live with whatever value was set. I would be happy with = such a text. However, I'm also OK with text that allows "reasonable" (=3D=3D = consistent) remarking. But that should not be mandated on anyone. Jarno On Jan 31, 2011, at 16:17 , ext Joel M. 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. >=20 > Yours, > Joel M. Halpern >=20 > On 1/31/2011 8:07 AM, Jarno Rajahalme wrote: >>=20 >>> ISSUE 9. The changes to section 2 include this paragraph. Please = read all >>> of it, since the first sentence out of context causes confusion: >>>=20 >>> 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. 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. 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) 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. 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. >>>=20 >>> We've debated and tuned this over several versions of the = predecessor >>> draft. But there are still objections, such as: >>> - MUST is too strong, if the downstream operator doesn't care about >>> the flow label; >>> - We don't fully specify what the border routers must do; >>> - We should more fully specify what that hosts must do. >>> The argument for MUST is that we shoudn't allow an operator >>> to send packets into the open Internet with badly formed flow = labels. >>> =46rom the Internet's viewpoint, we don't care whether the border = router >>> discards packets, clears the label to zero, or classifies packets = and >>> sets a new pseudo-random label. And if a host doesn't do what is = already >>> recommended, we don't care what it does; the border router has to >>> hide it. >>>=20 >>> QUESTION: Should we, and can we, further improve this text? >>=20 >> The fact remains that the receiving domain cannot trust the previous = domain to have done the right thing. Therefore: >>=20 >> "If (and only if) the receiving domain makes such use of flow label = values, that would benefit from an even pseudo-random distribution, the = ingress routers of such domain SHOULD map the received flow labels to = new, pseudo-random values. The new values MUST be the same for all = packets of any received flow, identified either by a non-zero flow label = value (with the source and destination addresses), or, if the received = flow label value is zero, by the 5-tuple of the received packet." >>=20 >> I would remove text about domains protecting their neighbors. >>=20 >> Jarno >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list >> ipv6@ietf.org >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- >>=20