From edward.jankiewicz@sri.com Thu Apr 1 13:16:22 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 090DA3A6A55; Thu, 1 Apr 2010 13:16:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.245 X-Spam-Level: * X-Spam-Status: No, score=1.245 tagged_above=-999 required=5 tests=[AWL=-0.439, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, HELO_MISMATCH_COM=0.553] 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 o-P4qzcQhzZP; Thu, 1 Apr 2010 13:16:21 -0700 (PDT) Received: from mail1.sri.com (newmail.SRI.COM [128.18.30.17]) by core3.amsl.com (Postfix) with ESMTP id 5F0783A6A4C; Thu, 1 Apr 2010 13:16:18 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII; format=flowed Received: from [192.168.1.2] ([unknown] [71.0.229.111]) by mail.sri.com (Sun Java(tm) System Messaging Server 7u2-7.05 32bit (built Jul 30 2009)) with ESMTPSA id <0L07006JKSBZL3G0@mail.sri.com>; Thu, 01 Apr 2010 13:16:48 -0700 (PDT) Message-id: <4BB4FF36.7070308@sri.com> Date: Thu, 01 Apr 2010 16:16:54 -0400 From: Ed Jankiewicz User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) To: 6man , IPv6 Operations , Behave WG , softwires@ietf.org Subject: applicability of RFC 5841 in node requirements bis 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, 01 Apr 2010 20:16:22 -0000 Packets containing IPv6 traffic originating at an IPv6 host, routed by IPv6 routers and delivered to an IPv6 host without any intervening tunnels, protocol translation, NAT44, NAT64, NAT444, NAT666 or anything else besides native IPv6 SHOULD be marked as 'happy' using the TCP Packet Mood Option defined in RFC 5841. All other packets MAY be marked as 'sad', 'confused', 'surprised', 'silly', 'frustrated', 'angry', 'apathetic', 'sneaky' or 'evil' depending on your opinion of the intervening mechanism. (no need to explicitly reply to this posting, just mark your next packet to me as 'amused' or 'bored') -- Ed Jankiewicz - SRI International Fort Monmouth Branch Office - IPv6 Research Supporting DISA Standards Engineering Branch 732-389-1003 or ed.jankiewicz@sri.com From edward.jankiewicz@sri.com Thu Apr 1 13:45:48 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 488433A696A; Thu, 1 Apr 2010 13:45:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.019 X-Spam-Level: X-Spam-Status: No, score=0.019 tagged_above=-999 required=5 tests=[AWL=0.934, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=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 DL7C059ACHlR; Thu, 1 Apr 2010 13:45:47 -0700 (PDT) Received: from mail1.sri.com (srimail.SRI.COM [128.18.30.17]) by core3.amsl.com (Postfix) with ESMTP id F302E3A692E; Thu, 1 Apr 2010 13:45:45 -0700 (PDT) MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_lWMSupw3zdPf6MR98w3tSw)" Received: from [192.168.1.2] ([unknown] [71.0.229.111]) by mail.sri.com (Sun Java(tm) System Messaging Server 7u2-7.05 32bit (built Jul 30 2009)) with ESMTPSA id <0L0700640QX4L3D0@mail.sri.com>; Thu, 01 Apr 2010 12:46:17 -0700 (PDT) Message-id: <4BB4F80E.4020706@sri.com> Date: Thu, 01 Apr 2010 15:46:22 -0400 From: Ed Jankiewicz User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) To: 6man , IPv6 Operations , Behave WG , softwires@ietf.org Subject: applicability of RFC 5841 in node requirements bis 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, 01 Apr 2010 20:45:48 -0000 This is a multi-part message in MIME format. --Boundary_(ID_lWMSupw3zdPf6MR98w3tSw) Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT Packets containing IPv6 traffic originating at an IPv6 host, routed by IPv6 routers and delivered to an IPv6 host without any intervening tunnels, protocol translation, NAT44, NAT64, NAT444, NAT666 or anything else besides native IPv6 SHOULD be marked as 'happy' using the TCP Packet Mood Option defined in RFC 5841. All other packets MAY be marked as 'sad', 'confused', 'surprised', 'silly', 'frustrated', 'angry', 'apathetic', 'sneaky' or 'evil' depending on your opinion of the intervening mechanism. (no need to explicitly reply to this posting, just mark your next packet to me as 'amused' or 'bored') -- Ed Jankiewicz - SRI International Fort Monmouth Branch Office - IPv6 Research Supporting DISA Standards Engineering Branch 732-389-1003 or ed.jankiewicz@sri.com --Boundary_(ID_lWMSupw3zdPf6MR98w3tSw) Content-type: text/html; CHARSET=US-ASCII Content-transfer-encoding: 7BIT Packets containing IPv6 traffic originating at an IPv6 host, routed by IPv6 routers and delivered to an IPv6 host without any intervening tunnels, protocol translation, NAT44, NAT64, NAT444, NAT666 or anything else besides native IPv6 SHOULD be marked as 'happy' using the TCP Packet Mood Option defined in RFC 5841.

All other packets MAY be marked as 'sad', 'confused', 'surprised', 'silly', 'frustrated', 'angry', 'apathetic', 'sneaky' or 'evil' depending on your opinion of the intervening mechanism.

(no need to explicitly reply to this posting, just mark your next packet to me as 'amused' or 'bored')
-- 
Ed Jankiewicz - SRI International
Fort Monmouth Branch Office - IPv6 Research 
Supporting DISA Standards Engineering Branch
732-389-1003 or  ed.jankiewicz@sri.com 
--Boundary_(ID_lWMSupw3zdPf6MR98w3tSw)-- From brian.e.carpenter@gmail.com Fri Apr 2 08:16:02 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 534EC3A6A7B for ; Fri, 2 Apr 2010 08:16:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.469 X-Spam-Level: X-Spam-Status: No, score=-1.469 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13] 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 fGkCnwYnCYU8 for ; Fri, 2 Apr 2010 08:16:01 -0700 (PDT) Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by core3.amsl.com (Postfix) with ESMTP id C474C3A6A4B for ; Fri, 2 Apr 2010 08:16:00 -0700 (PDT) Received: by pwj2 with SMTP id 2so389152pwj.31 for ; Fri, 02 Apr 2010 08:16:32 -0700 (PDT) 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=0udrM40/dFda4tgYVfoVLyuX8K+xboyvYZCiCHebWX8=; b=hnzaznAYSJaTKAR34EueZ8hyLUZeUfg08WqZM4Bcg0FFnI7u2N9lfieglRyc6d8yg5 4MxNScIegoTzx6JPuBDLsI3WQkEpTBmLJXNn3VKx9B4tsgsshklGMIcMWu7ZiO3RWR6m 3N68z71yeBdA0TJwI+EpV9Hx0XH1DcRH4zIrM= 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=LT1ckBXXP8QfKTxk9UQAoPQxnnse/iuTi3Mcs43QSGMc0jpcFus3atoKWpeP2tmziP 3yt+bFVtAWRB9rzhemUsDpZwxTHznHXsTVASogyJbW3K6vXCxdt8vyI5kznKpgXdIT3B Mv3x1GvTykeqHOsAzck/d/+61lIa9wW2gx3Z8= Received: by 10.114.187.40 with SMTP id k40mr2336718waf.30.1270221392056; Fri, 02 Apr 2010 08:16:32 -0700 (PDT) Received: from [130.202.2.47] (anlextwls002-047.wl.anl-external.org [130.202.2.47]) by mx.google.com with ESMTPS id 21sm1956512iwn.7.2010.04.02.08.16.30 (version=SSLv3 cipher=RC4-MD5); Fri, 02 Apr 2010 08:16:31 -0700 (PDT) Message-ID: <4BB60A4C.5090009@gmail.com> Date: Sat, 03 Apr 2010 04:16:28 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Ed Jankiewicz Subject: Re: FYI: DNSOPS presentation References: <4BB127CE.7020703@sri.com> In-Reply-To: <4BB127CE.7020703@sri.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: IPv6 Operations , 6man X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Apr 2010 15:16:02 -0000 As every successful IPv6 user on Windows XP knows, the hack would break all Windows XP IPv6 usage (since it can't resolve DNS over IPv6 at all). I prefer the current situation, where occasionally I have to disable IPv6 manually due to being on an IPv6-broken network where DNS serves up AAAA records and my regular tunnel is too slow. This seems OK, since people using v6 on XP are normally doing so as conscious early adopters. I do think that Google's solution to this, i.e. being selective about who gets the AAAA records in the first place, is much less of hack with less harmful side effects. Surely a better hack would be for recursive resolvers in IPv6-broken networks not to serve up AAAA records at all? Tunnel users could always find another resolver. Regards Brian From remi.despres@free.fr Fri Apr 2 09:09:32 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 D114C3A6892 for ; Fri, 2 Apr 2010 09:09:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.75 X-Spam-Level: X-Spam-Status: No, score=-0.75 tagged_above=-999 required=5 tests=[AWL=0.069, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, 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 0Z44tsaxiId9 for ; Fri, 2 Apr 2010 09:09:32 -0700 (PDT) Received: from smtp6-g21.free.fr (smtp6-g21.free.fr [212.27.42.6]) by core3.amsl.com (Postfix) with ESMTP id F26A13A6901 for ; Fri, 2 Apr 2010 09:09:29 -0700 (PDT) Received: from smtp6-g21.free.fr (localhost [127.0.0.1]) by smtp6-g21.free.fr (Postfix) with ESMTP id 2320CE0810A; Fri, 2 Apr 2010 18:09:58 +0200 (CEST) Received: from [192.168.0.13] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by smtp6-g21.free.fr (Postfix) with ESMTP id 66455E08010; Fri, 2 Apr 2010 18:09:55 +0200 (CEST) Subject: Re: FYI: DNSOPS presentation Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: <4BB60A4C.5090009@gmail.com> Date: Fri, 2 Apr 2010 18:09:53 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <2CF288DB-61F0-442B-BDBB-49AC4DB07BB9@free.fr> References: <4BB127CE.7020703@sri.com> <4BB60A4C.5090009@gmail.com> To: Brian E Carpenter X-Mailer: Apple Mail (2.1077) Cc: IPv6 Operations , 6man X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Apr 2010 16:09:32 -0000 Le 2 avr. 2010 =E0 17:16, Brian E Carpenter a =E9crit : > I prefer the current situation, where occasionally I have to > disable IPv6 manually due to being on an IPv6-broken network > where DNS serves up AAAA records So do I. > I do think that Google's solution to this, i.e. being selective > about who gets the AAAA records in the first place, is much less > of hack with less harmful side effects. +1 > Surely a better hack would be for recursive resolvers in IPv6-broken > networks not to serve up AAAA records at all? Agreed. RD From bmanning@karoshi.com Fri Apr 2 09:55:27 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 1DECE3A68C2 for ; Fri, 2 Apr 2010 09:55:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.073 X-Spam-Level: X-Spam-Status: No, score=-4.073 tagged_above=-999 required=5 tests=[AWL=1.096, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, MIME_8BIT_HEADER=0.3, 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 4c67W3i51qJl for ; Fri, 2 Apr 2010 09:55:26 -0700 (PDT) Received: from vacation.karoshi.com (vacation.karoshi.com [198.32.6.68]) by core3.amsl.com (Postfix) with ESMTP id 6CC123A67EF for ; Fri, 2 Apr 2010 09:55:26 -0700 (PDT) Received: from karoshi.com (localhost.localdomain [127.0.0.1]) by vacation.karoshi.com (8.12.8/8.12.8) with ESMTP id o32Gtq58008058; Fri, 2 Apr 2010 16:55:52 GMT Received: (from bmanning@localhost) by karoshi.com (8.12.8/8.12.8/Submit) id o32Gtq7r008057; Fri, 2 Apr 2010 16:55:52 GMT Date: Fri, 2 Apr 2010 16:55:52 +0000 From: bmanning@vacation.karoshi.com To: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= Subject: Re: FYI: DNSOPS presentation Message-ID: <20100402165552.GA7583@vacation.karoshi.com.> References: <4BB127CE.7020703@sri.com> <4BB60A4C.5090009@gmail.com> <2CF288DB-61F0-442B-BDBB-49AC4DB07BB9@free.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <2CF288DB-61F0-442B-BDBB-49AC4DB07BB9@free.fr> User-Agent: Mutt/1.4.1i Cc: IPv6 Operations , 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: Fri, 02 Apr 2010 16:55:27 -0000 On Fri, Apr 02, 2010 at 06:09:53PM +0200, Rimi Despris wrote: > > > Surely a better hack would be for recursive resolvers in IPv6-broken > > networks not to serve up AAAA records at all? > > Agreed. > > RD aren't you making the assumption that the recursive resolver is on/in the same broadcast domain as the stub which it is serving? how can you ensure that the IP reachability of the stub is "semantically simialar"** to the IP reachability of the recursive resolver? the DNS has no hooks into topological reachability. ** identical, equivalent, etc... See IDN equivalence --bill From Carroll.Perkins@serco-na.com Fri Apr 2 09:59:52 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 4F11D3A6829 for ; Fri, 2 Apr 2010 09:59:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.481 X-Spam-Level: * X-Spam-Status: No, score=1.481 tagged_above=-999 required=5 tests=[AWL=1.462, BAYES_05=-1.11, DNS_FROM_OPENWHOIS=1.13] 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 8Lalb04reZsV for ; Fri, 2 Apr 2010 09:59:51 -0700 (PDT) Received: from SNAET02.serco-na.com (snaet02.serco-na.com [209.27.15.11]) by core3.amsl.com (Postfix) with ESMTP id 2F1293A69D9 for ; Fri, 2 Apr 2010 09:59:46 -0700 (PDT) Received: from SNAHTCAS02.serco-na.com (10.11.11.142) by SNAET02.serco-na.com (209.27.15.11) with Microsoft SMTP Server (TLS) id 8.2.247.2; Fri, 2 Apr 2010 13:00:15 -0400 Received: from snamb02.serco-na.com ([fe80::e4e0:35e4:9f31:fa9f]) by SNAHTCAS02.serco-na.com ([::1]) with mapi; Fri, 2 Apr 2010 13:00:19 -0400 From: "Perkins, Carroll G" To: Brian E Carpenter , Ed Jankiewicz Date: Fri, 2 Apr 2010 13:00:18 -0400 Subject: RE: FYI: DNSOPS presentation Thread-Topic: FYI: DNSOPS presentation Thread-Index: AcrSd4/HEeDL642hSW2/CvPALHT16AADZ/6M Message-ID: <0C3240F2F9BCC543AF99C9E66685835B0C4EC2@SNAMB02.serco-na.com> References: <4BB127CE.7020703@sri.com>,<4BB60A4C.5090009@gmail.com> In-Reply-To: <4BB60A4C.5090009@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 Operations , 6man X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Apr 2010 16:59:52 -0000 Several thousand hours of IPv6 usage on XP and Windows 7 prompts me to whol= ly agree with Brian. The way DNS works now fits 95% plus of the transition environments. The proposed DNS hack will be obsolete before it can be passed thru the IET= F anyway since IPv6 usage is growing exponentially during 2010. Comcast alone will account for 50% of the transition market during this cal= endar year. And they have hard dates for completing IPv6 implementation du= ring 2010. So don't break DNS for the 95% using it successfully today for the 5% that = are not working today without manual intervention. Carroll Perkins ________________________________________ From: ipv6-bounces@ietf.org [ipv6-bounces@ietf.org] On Behalf Of Brian E Ca= rpenter [brian.e.carpenter@gmail.com] Sent: Friday, April 02, 2010 11:16 AM To: Ed Jankiewicz Cc: IPv6 Operations; 6man Subject: Re: FYI: DNSOPS presentation As every successful IPv6 user on Windows XP knows, the hack would break all Windows XP IPv6 usage (since it can't resolve DNS over IPv6 at all). I prefer the current situation, where occasionally I have to disable IPv6 manually due to being on an IPv6-broken network where DNS serves up AAAA records and my regular tunnel is too slow. This seems OK, since people using v6 on XP are normally doing so as conscious early adopters. I do think that Google's solution to this, i.e. being selective about who gets the AAAA records in the first place, is much less of hack with less harmful side effects. Surely a better hack would be for recursive resolvers in IPv6-broken networks not to serve up AAAA records at all? Tunnel users could always find another resolver. Regards Brian -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From townsley@cisco.com Fri Apr 2 10:31:32 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 D01663A6B30 for ; Fri, 2 Apr 2010 10:31:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.879 X-Spam-Level: X-Spam-Status: No, score=-7.879 tagged_above=-999 required=5 tests=[AWL=1.590, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, 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 Q1WdJoq0rKmL for ; Fri, 2 Apr 2010 10:31:31 -0700 (PDT) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id 3F24B3A6B50 for ; Fri, 2 Apr 2010 10:21:04 -0700 (PDT) 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: ArQFAJbEtUurRN+J/2dsb2JhbACPT4t6cZxZmGGFBQSKDQ X-IronPort-AV: E=Sophos;i="4.51,354,1267401600"; d="scan'208";a="109489090" Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-4.cisco.com with ESMTP; 02 Apr 2010 17:21:38 +0000 Received: from iwan-view3.cisco.com (iwan-view3.cisco.com [171.70.65.13]) by sj-core-3.cisco.com (8.13.8/8.14.3) with ESMTP id o32HLcHE010326 for ; Fri, 2 Apr 2010 17:21:38 GMT Received: from ams-townsley-87111.cisco.com (ams-townsley-87111.cisco.com [10.55.233.236]) by iwan-view3.cisco.com (8.11.2/CISCO.WS.1.2) with ESMTP id o32HLbY14762 for ; Fri, 2 Apr 2010 10:21:37 -0700 (PDT) Message-ID: <4BB627A0.6070500@cisco.com> Date: Fri, 02 Apr 2010 19:21:36 +0200 From: Mark Townsley User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: ipv6@ietf.org Subject: Re: FYI: DNSOPS presentation References: <4BB127CE.7020703@sri.com> <4BB60A4C.5090009@gmail.com> In-Reply-To: <4BB60A4C.5090009@gmail.com> X-Enigmail-Version: 1.0.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: Fri, 02 Apr 2010 17:31:32 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 4/2/10 5:16 PM, Brian E Carpenter wrote: > As every successful IPv6 user on Windows XP knows, the hack > would break all Windows XP IPv6 usage (since it can't resolve > DNS over IPv6 at all). Effectively all MACs as well, as the only way to get DNS resolved over v6 is by manually configuring the IPv6 DNS Server. - - Mark -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJLtiefAAoJEBAcHDFx3DUI98IH/AsV+yEx0uBX0PL792VPhH25 zzAIy4KLlANbU5dsw4ubleiSah+vjQFvVnFxbiGCeeygHTXHhHCNNLUJy5r+S76J qkiKK0dehwckP36fjbY8yv5fEWIgrIaBp3HsykD9XMKDmdlrp00mhdGQFApcAd6p PMCbdb72vUtmYS3g7uHF/orpcMBEvxSxmzs+cDLYB6oGFEswCi81gLD8ezBbt26K wGG+AxnR0PqJXpHfglEbkSNWqrQC8Fl7lCCoYDikkXzAuczyhuifxiXjV9Gyqdgr eWynt86k0+wxPM/GPUz33j8B7OcoXV6FAbGMIqdYuo0xm8yJZXcFb8Im4xdx9ls= =zgeZ -----END PGP SIGNATURE----- From jhw@apple.com Fri Apr 2 11:32:10 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 ABF5E3A6B2C for ; Fri, 2 Apr 2010 11:32:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.117 X-Spam-Level: X-Spam-Status: No, score=-104.117 tagged_above=-999 required=5 tests=[AWL=1.352, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, 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 slj34+tz4Zyr for ; Fri, 2 Apr 2010 11:32:09 -0700 (PDT) Received: from mail-out4.apple.com (mail-out4.apple.com [17.254.13.23]) by core3.amsl.com (Postfix) with ESMTP id 28DEB3A6BF8 for ; Fri, 2 Apr 2010 11:10:29 -0700 (PDT) Received: from relay11.apple.com (relay11.apple.com [17.128.113.48]) by mail-out4.apple.com (Postfix) with ESMTP id 70AB09354F69; Fri, 2 Apr 2010 11:11:03 -0700 (PDT) X-AuditID: 11807130-b7bdeae000004562-f6-4bb633378e03 Received: from il0602b-dhcp250.apple.com (il0602b-dhcp250.apple.com [17.206.24.250]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client did not present a certificate) by relay11.apple.com (Apple SCV relay) with SMTP id B4.3B.17762.73336BB4; Fri, 2 Apr 2010 11:11:03 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1078) Subject: Re: FYI: DNSOPS presentation From: james woodyatt In-Reply-To: <4BB60A4C.5090009@gmail.com> Date: Fri, 2 Apr 2010 11:11:03 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <635027C3-455E-4DB3-84D1-9EE8C1856EF3@apple.com> References: <4BB127CE.7020703@sri.com> <4BB60A4C.5090009@gmail.com> To: IPv6 Operations , 6man X-Mailer: Apple Mail (2.1078) X-Brightmail-Tracker: AAAAAQAAAZE= 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, 02 Apr 2010 18:32:10 -0000 On Apr 2, 2010, at 08:16, Brian E Carpenter wrote: >=20 > I do think that Google's solution to this, i.e. being selective > about who gets the AAAA records in the first place, is much less > of a hack, with less harmful side effects. While everyone else was in the 6MAN session, I was actually jumping back = and forth between 6MAN and DNSOP because I didn't want to miss this = presentation. As I pointed out at the microphone in DNSOP, the proposed = hack is absolutely broken because it relies on a pair of TOTALLY = INOPERATIVE ASSUMPTIONS: A) good IPv6 connectivity between the DNS resolving server and the DNS = content server implies good IPv6 connectivity between the client = application host and the application server host. B) good IPv6 connectivity between the client application host and the = application server host requires good IPv6 connectivity between the DNS = resolving server and the DNS content server. The obvious illustration that comes to mind is a host behind an Apple = AirPort Extreme base station at a public IPv4 address and configured in = 6to4 tunnel mode, but in a domain where the 6to4 relay service is = unreliable, badly-impaired or black-holed, and also configured to = forward its DNS queries to resolving servers that are dual-stack = IPv4/IPv6 capable. This configuration is sufficiently common that any = proposed solution to the problem must have an answer for it, and the = proposed solution doesn't deal with it at all. Shorter james: the proposed hack cannot solve the problem it intends to = solve, and it breaks other networks that work fine today. It should not = be endorsed. -- james woodyatt member of technical staff, communications engineering From brian.e.carpenter@gmail.com Fri Apr 2 12:18:51 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 850C83A6D33 for ; Fri, 2 Apr 2010 12:18:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.206 X-Spam-Level: X-Spam-Status: No, score=-1.206 tagged_above=-999 required=5 tests=[AWL=0.263, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13] 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 gipuqPmqoWAV for ; Fri, 2 Apr 2010 12:18:50 -0700 (PDT) Received: from mail-pv0-f172.google.com (mail-pv0-f172.google.com [74.125.83.172]) by core3.amsl.com (Postfix) with ESMTP id 18D9F3A6D35 for ; Fri, 2 Apr 2010 11:45:15 -0700 (PDT) Received: by pvd12 with SMTP id 12so652267pvd.31 for ; Fri, 02 Apr 2010 11:45:48 -0700 (PDT) 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=zv+vqEObzkoVRUH0ryH/GPpjEYF+VXcK4ft2mpiMlhc=; b=dbXJWz8UCqydIKeMKcI2ma228EKCmdPOzSIz7srVq+QQyd+OlacBHfOdNUufhRQyBg w+26YJHFHEkHcdzh7bMvzUeivxeuRi4g1Iu7IyoAuVGYCxW9tvJt3GjnY089YAxXG1ko yQ9ZLf6TnbEqAWVxZXhFyV0btmHSfriXoIH2w= 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=U5GVMxatKUydgi9b+5yM0K3ZRX9A7FRXrcScXD6L3s7h7GdPgtS3qtg75lzjvycq2o C48qQcgItnpye1SFFGmQTVDBsFETBV5Ud20WhiwhOhWSLX+1sUy2O14reOQ2OANh/vpL tEdE96axKa8iI+E62+4vVCw3+qN0AG/JP/g88= Received: by 10.143.153.42 with SMTP id f42mr930745wfo.299.1270233947882; Fri, 02 Apr 2010 11:45:47 -0700 (PDT) Received: from [130.202.2.47] (anlextwls002-047.wl.anl-external.org [130.202.2.47]) by mx.google.com with ESMTPS id 23sm288850iwn.6.2010.04.02.11.45.46 (version=SSLv3 cipher=RC4-MD5); Fri, 02 Apr 2010 11:45:47 -0700 (PDT) Message-ID: <4BB63B58.8030006@gmail.com> Date: Sat, 03 Apr 2010 07:45:44 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: bmanning@vacation.karoshi.com Subject: Re: FYI: DNSOPS presentation References: <4BB127CE.7020703@sri.com> <4BB60A4C.5090009@gmail.com> <2CF288DB-61F0-442B-BDBB-49AC4DB07BB9@free.fr> <20100402165552.GA7583@vacation.karoshi.com.> In-Reply-To: <20100402165552.GA7583@vacation.karoshi.com.> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: IPv6 Operations , 6man X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Apr 2010 19:18:52 -0000 Bill, On 2010-04-03 05:55, bmanning@vacation.karoshi.com wrote: > On Fri, Apr 02, 2010 at 06:09:53PM +0200, Rimi Despris wrote: >>> Surely a better hack would be for recursive resolvers in IPv6-broken >>> networks not to serve up AAAA records at all? >> Agreed. >> >> RD > > aren't you making the assumption that the recursive resolver is > on/in the same broadcast domain as the stub which it is serving? > how can you ensure that the IP reachability of the stub is "semantically > simialar"** to the IP reachability of the recursive resolver? > > the DNS has no hooks into topological reachability. Correct, but a hack in this area by definition can't cover all cases. Er, much better to mend the IPv6 brokenness, of course. Brian > > ** identical, equivalent, etc... See IDN equivalence > > --bill > From jhw@apple.com Fri Apr 2 12:59:09 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 C34F13A6AB3 for ; Fri, 2 Apr 2010 12:59:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.668 X-Spam-Level: X-Spam-Status: No, score=-104.668 tagged_above=-999 required=5 tests=[AWL=0.801, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, 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 g8ud-yn+u0is for ; Fri, 2 Apr 2010 12:59:09 -0700 (PDT) Received: from mail-out3.apple.com (mail-out3.apple.com [17.254.13.22]) by core3.amsl.com (Postfix) with ESMTP id A0EFF3A6A7F for ; Fri, 2 Apr 2010 12:25:44 -0700 (PDT) Received: from relay16.apple.com (relay16.apple.com [17.128.113.55]) by mail-out3.apple.com (Postfix) with ESMTP id 3007A8C43211; Fri, 2 Apr 2010 12:26:19 -0700 (PDT) X-AuditID: 11807137-b7c52ae000004c84-9f-4bb644db7ea1 Received: from il0602b-dhcp250.apple.com (il0602b-dhcp250.apple.com [17.206.24.250]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client did not present a certificate) by relay16.apple.com (Apple SCV relay) with SMTP id 2F.0B.19588.BD446BB4; Fri, 2 Apr 2010 12:26:19 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1078) Subject: Re: FYI: DNSOPS presentation From: james woodyatt In-Reply-To: <4BB63FDC.7070102@bogus.com> Date: Fri, 2 Apr 2010 12:26:18 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4BB127CE.7020703@sri.com> <4BB60A4C.5090009@gmail.com> <635027C3-455E-4DB3-84D1-9EE8C1856EF3@apple.com> <4BB63FDC.7070102@bogus.com> To: IPv6 Operations , 6man Mailing List X-Mailer: Apple Mail (2.1078) X-Brightmail-Tracker: AAAAAQAAAZE= 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, 02 Apr 2010 19:59:09 -0000 On Apr 2, 2010, at 12:05, Joel Jaeggli wrote: >=20 > actually they don't rest on those assumptions. Actually, I spoke at length with Igor Gashinsky on Tuesday night at IETF = 77 before the presentation in DNSOP, and I'm pretty sure I accurately = characterized the assumptions behind his proposal. Where he and I disagree, I think, is on the question of whether the = assumptions are *operative*. He believes they are; I believe they are = not. It's *his* train set, though, so I suppose he can break it however = he wants. -- james woodyatt member of technical staff, communications engineering From bmanning@karoshi.com Fri Apr 2 13:51:37 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 BB17F3A6B3F for ; Fri, 2 Apr 2010 13:51:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.406 X-Spam-Level: X-Spam-Status: No, score=-4.406 tagged_above=-999 required=5 tests=[AWL=1.063, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, 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 qyxHexLtAtVW for ; Fri, 2 Apr 2010 13:51:37 -0700 (PDT) Received: from vacation.karoshi.com (vacation.karoshi.com [198.32.6.68]) by core3.amsl.com (Postfix) with ESMTP id 42FD13A6BE0 for ; Fri, 2 Apr 2010 13:34:43 -0700 (PDT) Received: from karoshi.com (localhost.localdomain [127.0.0.1]) by vacation.karoshi.com (8.12.8/8.12.8) with ESMTP id o32KZA58009398; Fri, 2 Apr 2010 20:35:10 GMT Received: (from bmanning@localhost) by karoshi.com (8.12.8/8.12.8/Submit) id o32KZ8DB009397; Fri, 2 Apr 2010 20:35:08 GMT Date: Fri, 2 Apr 2010 20:35:08 +0000 From: bmanning@vacation.karoshi.com To: Brian E Carpenter Subject: Re: FYI: DNSOPS presentation Message-ID: <20100402203508.GB9162@vacation.karoshi.com.> References: <4BB127CE.7020703@sri.com> <4BB60A4C.5090009@gmail.com> <2CF288DB-61F0-442B-BDBB-49AC4DB07BB9@free.fr> <20100402165552.GA7583@vacation.karoshi.com.> <4BB63B58.8030006@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4BB63B58.8030006@gmail.com> User-Agent: Mutt/1.4.1i Cc: IPv6 Operations , bmanning@vacation.karoshi.com, 6man X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Apr 2010 20:51:37 -0000 On Sat, Apr 03, 2010 at 07:45:44AM +1300, Brian E Carpenter wrote: > Bill, > > On 2010-04-03 05:55, bmanning@vacation.karoshi.com wrote: > > On Fri, Apr 02, 2010 at 06:09:53PM +0200, Rimi Despris wrote: > >>> Surely a better hack would be for recursive resolvers in IPv6-broken > >>> networks not to serve up AAAA records at all? > >> Agreed. > >> > >> RD > > > > aren't you making the assumption that the recursive resolver is > > on/in the same broadcast domain as the stub which it is serving? > > how can you ensure that the IP reachability of the stub is "semantically > > simialar"** to the IP reachability of the recursive resolver? > > > > the DNS has no hooks into topological reachability. > > Correct, but a hack in this area by definition can't cover all cases. does it even cover a statistically significant fraction of cases? > > Er, much better to mend the IPv6 brokenness, of course. then why not spend the energy/resouce on ensuring v6 transport works instead of wasting this on what is clearly a DNS haq for a temporary condition? Or is this a case of "when all we have is the DNS, everything looks like a query/response"? > > Brian > > > > > ** identical, equivalent, etc... See IDN equivalence > > > > --bill > > From igor@gashinsky.net Fri Apr 2 14:05:15 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 73E4A3A6BAE for ; Fri, 2 Apr 2010 14:05:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.728 X-Spam-Level: X-Spam-Status: No, score=-0.728 tagged_above=-999 required=5 tests=[AWL=0.741, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13] 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 12iybFTmrjqW for ; Fri, 2 Apr 2010 14:05:14 -0700 (PDT) Received: from moonbase.nullrouteit.net (moonbase.nullrouteit.net [216.254.64.30]) by core3.amsl.com (Postfix) with ESMTP id 6C84B3A6BCC for ; Fri, 2 Apr 2010 13:50:38 -0700 (PDT) Received: (qmail 32355 invoked by uid 1000); 2 Apr 2010 20:50:19 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 2 Apr 2010 20:50:19 -0000 Date: Fri, 2 Apr 2010 16:50:19 -0400 (EDT) From: Igor Gashinsky X-X-Sender: igor@moonbase.nullrouteit.net To: james woodyatt Subject: Re: [IPv6] Re: FYI: DNSOPS presentation In-Reply-To: <635027C3-455E-4DB3-84D1-9EE8C1856EF3@apple.com> Message-ID: References: <4BB127CE.7020703@sri.com> <4BB60A4C.5090009@gmail.com> <635027C3-455E-4DB3-84D1-9EE8C1856EF3@apple.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: IPv6 Operations , 6man X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Apr 2010 21:05:15 -0000 On Fri, 2 Apr 2010, james woodyatt wrote: :: On Apr 2, 2010, at 08:16, Brian E Carpenter wrote: :: > :: > I do think that Google's solution to this, i.e. being selective :: > about who gets the AAAA records in the first place, is much less :: > of a hack, with less harmful side effects. :: :: While everyone else was in the 6MAN session, I was actually jumping back and forth between 6MAN and DNSOP because I didn't want to miss this presentation. As I pointed out at the microphone in DNSOP, the proposed hack is absolutely broken because it relies on a pair of TOTALLY INOPERATIVE ASSUMPTIONS: :: :: A) good IPv6 connectivity between the DNS resolving server and the DNS content server implies good IPv6 connectivity between the client application host and the application server host. :: :: B) good IPv6 connectivity between the client application host and the application server host requires good IPv6 connectivity between the DNS resolving server and the DNS content server. Actually, it does not rely on these assumptions. It does however rely on the following: 1) Good connectivity between the DNS resolving server and the DNS content server is easily quantifiable by both the service and content providers via a variety of techniques *PLUS* 2) good connectivity between client application host and DNS resolving server can be identified by the ISP recursive server being able to get DNS queries over IPv6 transport Those 2 combined are an excellent indicator of good connectivity between the client application host and the application server host. Ie, if the user can get to his dns server of ipv6, and the content provider determines that ipv6 connectivity between their network and the ISP network works correctly (which we can do -- this is what whitelisting is all about), then we are reasonably sure that the end-user will be able to get to the content service they want to get to over ipv6, w/o breaking anything. :: The obvious illustration that comes to mind is a host behind an Apple AirPort Extreme base station at a public IPv4 address and configured in 6to4 tunnel mode, but in a domain where the 6to4 relay service is unreliable, badly-impaired or black-holed, and also configured to forward its DNS queries to resolving servers that are dual-stack IPv4/IPv6 capable. This configuration is sufficiently common that any proposed solution to the problem must have an answer for it, and the proposed solution doesn't deal with it at all. Actually, I think it can: If the end user's 6to4 tunnel is "flakey", then the ipv6-transported DNS queries over said tunnel would fail, causing the user to try to resolve them over ipv4 transport, (I'm assuming the user would get both the v4 and the v6 ips of the dualstack recursors in this example), which should work just fine. This would then cause the recursive servers running this "hack" to only reply back with A records (since the query comes in over ipv4), therefore the client would work just fine. No? -igor From igor@gashinsky.net Fri Apr 2 14:06:51 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 521753A6BC6 for ; Fri, 2 Apr 2010 14:06:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.796 X-Spam-Level: X-Spam-Status: No, score=-0.796 tagged_above=-999 required=5 tests=[AWL=0.673, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13] 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 mit2yuTCv8G4 for ; Fri, 2 Apr 2010 14:06:50 -0700 (PDT) Received: from moonbase.nullrouteit.net (moonbase.nullrouteit.net [216.254.64.30]) by core3.amsl.com (Postfix) with ESMTP id 19B833A6AD8 for ; Fri, 2 Apr 2010 13:52:03 -0700 (PDT) Received: (qmail 749 invoked by uid 1000); 2 Apr 2010 20:51:44 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 2 Apr 2010 20:51:44 -0000 Date: Fri, 2 Apr 2010 16:51:44 -0400 (EDT) From: Igor Gashinsky X-X-Sender: igor@moonbase.nullrouteit.net To: Mark Townsley Subject: Re: [IPv6] Re: FYI: DNSOPS presentation In-Reply-To: <4BB627A0.6070500@cisco.com> Message-ID: References: <4BB127CE.7020703@sri.com> <4BB60A4C.5090009@gmail.com> <4BB627A0.6070500@cisco.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Apr 2010 21:06:51 -0000 :: -----BEGIN PGP SIGNED MESSAGE----- :: Hash: SHA1 :: :: On 4/2/10 5:16 PM, Brian E Carpenter wrote: :: > As every successful IPv6 user on Windows XP knows, the hack :: > would break all Windows XP IPv6 usage (since it can't resolve :: > DNS over IPv6 at all). Yes, this was one of the identified caveats. On Fri, 2 Apr 2010, Mark Townsley wrote: :: Effectively all MACs as well, as the only way to get DNS resolved over :: v6 is by manually configuring the IPv6 DNS Server. Until the next release, when this, I believe will be fixed. -igor From igor@gashinsky.net Fri Apr 2 14:13:56 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 C853B3A6A51 for ; Fri, 2 Apr 2010 14:13:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.852 X-Spam-Level: X-Spam-Status: No, score=-0.852 tagged_above=-999 required=5 tests=[AWL=0.617, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13] 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 wDXRlCZBFFlo for ; Fri, 2 Apr 2010 14:13:54 -0700 (PDT) Received: from moonbase.nullrouteit.net (moonbase.nullrouteit.net [216.254.64.30]) by core3.amsl.com (Postfix) with ESMTP id E6FC33A6A06 for ; Fri, 2 Apr 2010 13:58:09 -0700 (PDT) Received: (qmail 4150 invoked by uid 1000); 2 Apr 2010 20:57:51 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 2 Apr 2010 20:57:51 -0000 Date: Fri, 2 Apr 2010 16:57:51 -0400 (EDT) From: Igor Gashinsky X-X-Sender: igor@moonbase.nullrouteit.net To: Brian E Carpenter Subject: Re: [IPv6] Re: FYI: DNSOPS presentation In-Reply-To: <4BB60A4C.5090009@gmail.com> Message-ID: References: <4BB127CE.7020703@sri.com> <4BB60A4C.5090009@gmail.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: IPv6 Operations , 6man X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Apr 2010 21:13:56 -0000 On Sat, 3 Apr 2010, Brian E Carpenter wrote: :: I prefer the current situation, where occasionally I have to :: disable IPv6 manually due to being on an IPv6-broken network :: where DNS serves up AAAA records and my regular tunnel is too :: slow. This seems OK, since people using v6 on XP are normally doing :: so as conscious early adopters. A few months ago I woudl have agreed with you -- anybody who configures IPv6 on windows XP woudl be concidered a "power user", and therefore can suppot and troubleshoot themselves. Unfortunately, a few months ago I found out that one of the torrent clients is enabling IPv6 on XP machine without users even knowing about it. Now, the game has changed, because it's not only powerusers who have ipv6 configured, it's everyone, and I can no longer rely on them to fix themselves, so, now I need to find a way to not break those users when I hand out AAAA without having them be involved. :: I do think that Google's solution to this, i.e. being selective :: about who gets the AAAA records in the first place, is much less :: of hack with less harmful side effects. :: :: Surely a better hack would be for recursive resolvers in IPv6-broken :: networks not to serve up AAAA records at all? Tunnel users could :: always find another resolver. It is the same hack. You would use that very same feature that was developed to accomplish this (filter-aaaa) -- what's more, when your network stops being v6-broken, you get the extra benefit that the users who can query your dns resolvers over ipv6 can now get AAAA's as first step of rollout... -igor From brian.e.carpenter@gmail.com Fri Apr 2 14:39:34 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 F3C603A6842 for ; Fri, 2 Apr 2010 14:39:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.118 X-Spam-Level: X-Spam-Status: No, score=-1.118 tagged_above=-999 required=5 tests=[AWL=0.351, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13] 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 mS-0GGthR019 for ; Fri, 2 Apr 2010 14:39:33 -0700 (PDT) Received: from mail-gx0-f220.google.com (mail-gx0-f220.google.com [209.85.217.220]) by core3.amsl.com (Postfix) with ESMTP id 978EF3A69FB for ; Fri, 2 Apr 2010 14:29:42 -0700 (PDT) Received: by gxk20 with SMTP id 20so1781089gxk.12 for ; Fri, 02 Apr 2010 14:30:14 -0700 (PDT) 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=xutU7Qzeapy7krrXnw/gNP9kkOuV6z35Y5SyJnISVvI=; b=rrYx/F/T5oT6+yp/7ytWnJpG7hu2YpxXt/IlQ1RV6aTzqlEc4mq1PkRw6gd45YdjU7 VW0EUFM6lYCcdULvwU767wqLkFzHE/ui5/Cw/2daSslROEyI/xgqbb6JLwR48XSN9/Km U8eT/kxSSE9L9iNqGbgbdge4MMRkU9x77lJV8= 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=uEbhlkxMvD/M7rfxvJri3F+D1Urvcnm7pk2iaAOyok66M813NuVu90UPE3dO0IlOi0 jOxdD7mUvQ93Vb16uafO5WaZRFgpgGKzoC1ID2akw34H1WygYjPtwZxAVxEmw8ejnrG0 JA3JtBcBtyUNctXR35NpQitF4NLVshv3PUn7o= Received: by 10.101.125.4 with SMTP id c4mr7119049ann.225.1270243813980; Fri, 02 Apr 2010 14:30:13 -0700 (PDT) Received: from [130.202.2.47] (anlextwls002-047.wl.anl-external.org [130.202.2.47]) by mx.google.com with ESMTPS id 22sm229237iwn.0.2010.04.02.14.30.13 (version=SSLv3 cipher=RC4-MD5); Fri, 02 Apr 2010 14:30:13 -0700 (PDT) Message-ID: <4BB661E2.30407@gmail.com> Date: Sat, 03 Apr 2010 10:30:10 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Igor Gashinsky Subject: Re: [IPv6] Re: FYI: DNSOPS presentation References: <4BB127CE.7020703@sri.com> <4BB60A4C.5090009@gmail.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: IPv6 Operations , 6man X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Apr 2010 21:39:34 -0000 On 2010-04-03 09:57, Igor Gashinsky wrote: ... > :: Surely a better hack would be for recursive resolvers in IPv6-broken > :: networks not to serve up AAAA records at all? Tunnel users could > :: always find another resolver. > > It is the same hack. Not if applied administratively, and reversed administratively when the v6 brokenness is fixed. From a network ops point of view, this is much cleaner than automated detection, and will also put the responsibility in the right place: the network manager who has not deployed v6. And early adopters who want to bypass the hack can simply configure a DNS server that does deliver AAAA. Brian Brian You would use that very same feature that was > developed to accomplish this (filter-aaaa) -- what's more, when your > network stops being v6-broken, you get the extra benefit that the users > who can query your dns resolvers over ipv6 can now get AAAA's as first > step of rollout... > > -igor > From lorenzo@google.com Fri Apr 2 17:25:53 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 1F3BD3A681B for ; Fri, 2 Apr 2010 17:25:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.846 X-Spam-Level: X-Spam-Status: No, score=-104.846 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 VWFeBUitgJGx for ; Fri, 2 Apr 2010 17:25:52 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id 0F00B3A67B6 for ; Fri, 2 Apr 2010 17:25:49 -0700 (PDT) Received: from hpaq14.eem.corp.google.com (hpaq14.eem.corp.google.com [10.3.21.14]) by smtp-out.google.com with ESMTP id o330QFah025255 for ; Fri, 2 Apr 2010 17:26:16 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1270254377; bh=KkeTsAsKbslKkTgwIt15HZiv7sA=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=jipIH6gGZB1yvzTwt/6QGWWWtCLv+B2bWWGXoeUa/DyjFAqjRsLBNj/lBD3Li92n/ 12FlQuGFwTIPhnn3Rfqbg== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:from:date:message-id: subject:to:cc:content-type:x-system-of-record; b=FXbLFjVdgY1RtycN0q0jWHgg9z7DZdAa860K4NyUMud0fCXLZ2LAxcK/jLQj0XYcx ssrPWR8LSb2DI+Z0OMIjA== Received: from ywh35 (ywh35.prod.google.com [10.192.8.35]) by hpaq14.eem.corp.google.com with ESMTP id o330QDLE025818 for ; Sat, 3 Apr 2010 02:26:13 +0200 Received: by ywh35 with SMTP id 35so1498437ywh.24 for ; Fri, 02 Apr 2010 17:26:13 -0700 (PDT) MIME-Version: 1.0 Received: by 10.151.124.3 with HTTP; Fri, 2 Apr 2010 17:25:53 -0700 (PDT) In-Reply-To: <20100330223331.65ab7343@opy.nosense.org> References: <20100327.031032.193757830.miyakawa@nttv6.jp> <75cb24521003271010k306dddbbhff877db3c458328a@mail.gmail.com> <20100330073828.1bf4b611@opy.nosense.org> <20100330081721.03cb55a4@opy.nosense.org> <20100330223331.65ab7343@opy.nosense.org> From: Lorenzo Colitti Date: Fri, 2 Apr 2010 17:25:53 -0700 Received: by 10.150.65.3 with SMTP id n3mr3289435yba.322.1270254373121; Fri, 02 Apr 2010 17:26:13 -0700 (PDT) Message-ID: Subject: Re: DHCPv6 support for /127s, for ISP subscriber PPP/PPPoE p2p links (Re: router vs. host discussion in 6man today for the /127 draft) To: Mark Smith Content-Type: multipart/alternative; boundary=000e0cd4a694af2f2204834a24ea X-System-Of-Record: true Cc: Becca Nitzan , Shin@core3.amsl.com, ipv6@ietf.org, "George, Wes E \[NTK\]" , Miyakawa 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, 03 Apr 2010 00:25:53 -0000 --000e0cd4a694af2f2204834a24ea Content-Type: text/plain; charset=ISO-8859-1 On Tue, Mar 30, 2010 at 5:03 AM, Mark Smith < ipng@69706e6720323030352d30312d31340a.nosense.org> wrote: > I'm happy with using /64s for PPPoE links. However, if the /127 draft is > accepted, then I'd want to be able to take advantage of them on > PPP/PPPoE sessions - if there is an approved mechanism available to > save address space I may as well use it. > Why would you do this as opposed to, say, unnumbered addresses? The draft only specifies /127 for inter-router links. What if there's a host on the other side? And what if whatever is on the other side of the link wants to pass on IPv6 connectivity the connectivity to other hosts in its network? Please don't say that it needs to do NAT66. --000e0cd4a694af2f2204834a24ea Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Tue, Mar 30, 2010 at 5:03 AM, Mark Smith <ipng@69706e6720323030352d30312d31340a.nosense.org> wrote:
I'm happy with using = /64s for PPPoE links. However, if the /127 draft is
accepted, then I'd want to be able to take advantage of them on
PPP/PPPoE sessions - if there is an approved mechanism available to
save address space I may as well use it.

Why would you do this as opposed to, say, unnumbered addresses?

The draft only specifies /127 for inter-router links. What = if there's a host on the other side? And what if whatever is on the oth= er side of the link wants to pass on IPv6 connectivity the connectivity to = other hosts in its network? Please don't say that it needs to do NAT66.=
--000e0cd4a694af2f2204834a24ea-- From ipng@69706e6720323030352d30312d31340a.nosense.org Fri Apr 2 22:40:44 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 5DA333A6855 for ; Fri, 2 Apr 2010 22:40:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.346 X-Spam-Level: X-Spam-Status: No, score=-0.346 tagged_above=-999 required=5 tests=[AWL=0.419, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, 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 byAM-sL6Zu64 for ; Fri, 2 Apr 2010 22:40:43 -0700 (PDT) Received: from smtp4.adam.net.au (smtp4.adam.net.au [202.136.110.247]) by core3.amsl.com (Postfix) with ESMTP id 2A0733A68C6 for ; Fri, 2 Apr 2010 22:40:39 -0700 (PDT) Received: from 114-30-109-209.ip.adam.com.au ([114.30.109.209] helo=opy.nosense.org) by smtp4.adam.net.au with esmtp (Exim 4.63) (envelope-from ) id 1Nxw5s-0001w2-N6; Sat, 03 Apr 2010 16:10:28 +1030 Received: from opy.nosense.org (localhost.localdomain [IPv6:::1]) by opy.nosense.org (Postfix) with ESMTP id EDC204930C; Sat, 3 Apr 2010 16:10:25 +1030 (CST) Date: Sat, 3 Apr 2010 16:10:23 +1030 From: Mark Smith To: Lorenzo Colitti Subject: Re: DHCPv6 support for /127s, for ISP subscriber PPP/PPPoE p2p links (Re: router vs. host discussion in 6man today for the /127 draft) Message-ID: <20100403161023.3ad3bf2d@opy.nosense.org> In-Reply-To: References: <20100327.031032.193757830.miyakawa@nttv6.jp> <75cb24521003271010k306dddbbhff877db3c458328a@mail.gmail.com> <20100330073828.1bf4b611@opy.nosense.org> <20100330081721.03cb55a4@opy.nosense.org> <20100330223331.65ab7343@opy.nosense.org> X-Mailer: Claws Mail 3.7.5 (GTK+ 2.18.9; 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: quoted-printable Cc: Becca Nitzan , Shin@core3.amsl.com, ipv6@ietf.org, "George, Wes E \[NTK\]" , Miyakawa 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, 03 Apr 2010 05:40:45 -0000 Hi Lorenzo, On Fri, 2 Apr 2010 17:25:53 -0700 Lorenzo Colitti wrote: > On Tue, Mar 30, 2010 at 5:03 AM, Mark Smith < > ipng@69706e6720323030352d30312d31340a.nosense.org> wrote: >=20 > > I'm happy with using /64s for PPPoE links. However, if the /127 draft is > > accepted, then I'd want to be able to take advantage of them on > > PPP/PPPoE sessions - if there is an approved mechanism available to > > save address space I may as well use it. > > >=20 > Why would you do this as opposed to, say, unnumbered addresses? >=20 =46rom my IPv4 experience with unnumbered P2P links, I'd much rather have a distinct address on each end of a link, although I've since learned that the benefits that I value rely on the device following the strong host model. > The draft only specifies /127 for inter-router links. What if there's a h= ost > on the other side? When you're thinking about PPPoE/PPP scenarios, the most common one is inter-router. If a end-host is running PPPoE/PPP then I think it is a reasonable assumption that it'll handle any /127 point-to-point methods correctly. > And what if whatever is on the other side of the link > wants to pass on IPv6 connectivity the connectivity to other hosts in its > network? > Please don't say that it needs to do NAT66. I certainly wouldn't recommend any form of NAT. I'm all for giving customers lots of subnets in addition to the subnet on the link between them and the SP. That does presume that the customer's device is a router and is able to request prefixes for its downstream interfaces via DHCPv6 PD. I can see that if the /127s are accepted, and you choose not to use them when you can, people are going to accuse you of "wasting" address space, and it'd be hard to convince them otherwise even if you use the simplicity/it's only waste when you get nothing for it argument (that isn't working very well on this list and others either it seems). So I'm identifying a scenario where I think they could be commonly used and would tend to provide a more useful benefit, in comparison to the much small number of infrastructure P2P links in networks. Right now though, one of the drawbacks the /127 proposal is that there is an underlying assumption of static configuration at both ends of the link, which makes it impractical for the scenario I've described. Regards, Mark. From joelja@bogus.com Fri Apr 2 12:38:10 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 88FB43A6816 for ; Fri, 2 Apr 2010 12:38:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.469 X-Spam-Level: X-Spam-Status: No, score=-1.469 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13] 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 nvsdOz5bY+Ju for ; Fri, 2 Apr 2010 12:38:09 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [147.28.0.81]) by core3.amsl.com (Postfix) with ESMTP id 879E13A6A04 for ; Fri, 2 Apr 2010 12:04:37 -0700 (PDT) Received: from [192.103.16.191] ([192.103.16.191]) (authenticated bits=0) by nagasaki.bogus.com (8.14.3/8.14.3) with ESMTP id o32J5AMt056874 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Fri, 2 Apr 2010 19:05:10 GMT (envelope-from joelja@bogus.com) Message-ID: <4BB63FDC.7070102@bogus.com> Date: Fri, 02 Apr 2010 12:05:00 -0700 From: Joel Jaeggli User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.8) Gecko/20100322 Lightning/1.0b1 Thunderbird/3.0.3 MIME-Version: 1.0 To: james woodyatt Subject: Re: FYI: DNSOPS presentation References: <4BB127CE.7020703@sri.com> <4BB60A4C.5090009@gmail.com> <635027C3-455E-4DB3-84D1-9EE8C1856EF3@apple.com> In-Reply-To: <635027C3-455E-4DB3-84D1-9EE8C1856EF3@apple.com> X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.2 (nagasaki.bogus.com [147.28.0.81]); Fri, 02 Apr 2010 19:05:10 +0000 (UTC) X-Mailman-Approved-At: Sat, 03 Apr 2010 01:56:38 -0700 Cc: IPv6 Operations , 6man X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Apr 2010 19:38:10 -0000 On 04/02/2010 11:11 AM, james woodyatt wrote: > On Apr 2, 2010, at 08:16, Brian E Carpenter wrote: >> >> I do think that Google's solution to this, i.e. being selective >> about who gets the AAAA records in the first place, is much less of >> a hack, with less harmful side effects. > > While everyone else was in the 6MAN session, I was actually jumping > back and forth between 6MAN and DNSOP because I didn't want to miss > this presentation. As I pointed out at the microphone in DNSOP, the > proposed hack is absolutely broken because it relies on a pair of > TOTALLY INOPERATIVE ASSUMPTIONS: > > A) good IPv6 connectivity between the DNS resolving server and the > DNS content server implies good IPv6 connectivity between the client > application host and the application server host. > > B) good IPv6 connectivity between the client application host and the > application server host requires good IPv6 connectivity between the > DNS resolving server and the DNS content server. actually they don't rest on those assumptions. the assumption being made is that queriers who are customers of a given set of name-servers have available to them a particular kind of connectivity... this is exactly the same kind of assumption made when selectively returning different A records in an ipv4 global loading balancing setup. The consequences of getting it wrong in ipv4 are you go to a more distant instance of a service. The consequence of getting it wrong in ipv6 are you hand a AAAA record to a host that doesn't use it (this causes no harm) or you hand a AAAA record to host that shouldn't use it (because soemthing about their connectivity is broken). presumably the decision to make a particular set of queriers as blessed for the purpose of reciveing AAAA records is based on a judgement about the likelyhood of the hosts behind that resolver being non-broken. > The obvious illustration that comes to mind is a host behind an Apple > AirPort Extreme base station at a public IPv4 address and configured > in 6to4 tunnel mode, but in a domain where the 6to4 relay service is > unreliable, badly-impaired or black-holed, and also configured to > forward its DNS queries to resolving servers that are dual-stack > IPv4/IPv6 capable. This configuration is sufficiently common that > any proposed solution to the problem must have an answer for it, and > the proposed solution doesn't deal with it at all. > > Shorter james: the proposed hack cannot solve the problem it intends > to solve, and it breaks other networks that work fine today. It > should not be endorsed. > > > -- james woodyatt member of technical staff, > communications engineering > > > From jason_livingood@cable.comcast.com Fri Apr 2 12:53:21 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 C53AC3A6B58 for ; Fri, 2 Apr 2010 12:53:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.334 X-Spam-Level: *** X-Spam-Status: No, score=3.334 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, J_CHICKENPOX_13=0.6, RCVD_NUMERIC_HELO=2.067] 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 7Ley-PgrvsVO for ; Fri, 2 Apr 2010 12:53:21 -0700 (PDT) Received: from paoakoavas10.cable.comcast.com (paoakoavas10.cable.comcast.com [208.17.35.59]) by core3.amsl.com (Postfix) with ESMTP id 4407D3A6B1A for ; Fri, 2 Apr 2010 12:16:50 -0700 (PDT) Received: from ([24.40.15.92]) by paoakoavas10.cable.comcast.com with ESMTP id KP-TDCH7.79485489; Fri, 02 Apr 2010 15:17:05 -0400 Received: from PACDCEXCMB04.cable.comcast.com ([24.40.15.86]) by PACDCEXCSMTP03.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 2 Apr 2010 15:17:05 -0400 Received: from 147.191.227.127 ([147.191.227.127]) by PACDCEXCMB04.cable.comcast.com ([24.40.15.86]) via Exchange Front-End Server webmail.comcast.com ([24.40.8.153]) with Microsoft Exchange Server HTTP-DAV ; Fri, 2 Apr 2010 19:17:04 +0000 User-Agent: Microsoft-Entourage/12.24.0.100205 Date: Fri, 02 Apr 2010 15:17:09 -0400 Subject: Re: FYI: DNSOPS presentation From: Jason Livingood To: james woodyatt , IPv6 Operations , 6man Message-ID: Thread-Topic: FYI: DNSOPS presentation Thread-Index: AcrSmRbt1VMdryaGbEyOTkw1qm5tbQ== In-Reply-To: <635027C3-455E-4DB3-84D1-9EE8C1856EF3@apple.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 02 Apr 2010 19:17:05.0003 (UTC) FILETIME=[148C03B0:01CAD299] X-Mailman-Approved-At: Sat, 03 Apr 2010 01:56:39 -0700 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, 02 Apr 2010 19:53:21 -0000 I agree with what James just posted. Since this has hopped over to v6ops from dnsops, I thought I'd post here what I wrote over there, as I think it's important as we're working on solutions w/o a clear agreement on the problem: It seems that have the cart before the horse, so to speak. IMHO, we need to do the following (and there's no reason they cannot occur rapidly): 1 - Develop a clear problem statement that outlines (1) how "broken" users are defined and (2) what effects this "brokenness" has on these end users (or other parts of the Internet). 2 - Describe all the various methods and tactics by which end user "brokenness" can be detected. This may include website-based detection, DNS-query-based detection, or a variety of other methods. 3 - Then, after we have agreement on Problem Definition and Problem Detection, we can measure the problem to understand what the scope or scale of the problem is. 4 - After we understand Problem Definition, Problem Detection, and Problem Scope, then you can arrive at possible solutions. Seems like in this case we sort of *started* here, which concerns me and I think we need to be careful that discussion thus far does not constrain development of a full list of Solution Options. I further believe we will need to encourage the pursuit of multiple solutions simultaneously. Lastly, just because end user software upgrades may be difficult doesn't mean we shouldn't do them and shouldn't focus just as much energy on those than other options. Jason From ocl@gih.com Sat Apr 3 02:02:10 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 1405F3A691F for ; Sat, 3 Apr 2010 02:02:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.545 X-Spam-Level: * X-Spam-Status: No, score=1.545 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, DNS_FROM_OPENWHOIS=1.13, J_CHICKENPOX_13=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 ZaMc2JXDKa9X for ; Sat, 3 Apr 2010 02:02:09 -0700 (PDT) Received: from waikiki.gih.co.uk (salsa.gih.co.uk [IPv6:2001:470:1f09:92d::b]) by core3.amsl.com (Postfix) with ESMTP id ED4303A693D for ; Sat, 3 Apr 2010 02:01:56 -0700 (PDT) Received: from waikiki.gih.co.uk (localhost6.localdomain6 [IPv6:::1]) by waikiki.gih.co.uk (Postfix) with ESMTP id 26CA518F3AD; Sat, 3 Apr 2010 10:01:52 +0100 (BST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=gih.com; h=message-id:date :from:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; s=mahalo1; bh=UiF+QS+8G 0HRs5IuLHQdPCQJRA8=; b=ew+OaN3OAh75Z+nWf/5yTT+4FvQJGalVGuqmC6iz0 dMjucN5uhPnArAZHsXrL9EuWn6rm+q9rZbqodsQZYtL5jsjaCqAIem8ohvc+HP2J VmtUWXw+V4anQXT8dkyT9XU975ezlvpqM7chLD0Y2Dlbo2GZ9TeUGN4O/qc78Kk2 TA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gih.com; h=message-id:date :from:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; q=dns; s=mahalo1; b=M/c AL/QZpenjz8JgHgIRbfELGOzGbZNjrk1qCJX6T5ZZSV3T6KTQXAatlmh5I+gKnMs b8NHe/tEqQlvhW6j5Fk28K35BYgBiHRCgkbyx0G1HnhGw1BSIBb7dI0+ZzAp7T+c fZPXmQg2GdiE8Fgk7cqWFf1KQouo5djwcCP1mkD8= Received: from [192.168.1.45] (ANice-151-1-80-28.w86-193.abo.wanadoo.fr [86.193.242.28]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by waikiki.gih.co.uk (Postfix) with ESMTPSA id 14DA918F3AC; Sat, 3 Apr 2010 10:01:50 +0100 (BST) Message-ID: <4BB70402.3010700@gih.com> Date: Sat, 03 Apr 2010 11:01:54 +0200 From: Olivier MJ Crepin-Leblond User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; fr; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: Jason Livingood Subject: Re: FYI: DNSOPS presentation References: In-Reply-To: X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Sat, 03 Apr 2010 04:51:21 -0700 Cc: IPv6 Operations , 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, 03 Apr 2010 09:02:10 -0000 On 02/04/2010 21:17, Jason Livingood wrote : > I agree with what James just posted. > > Since this has hopped over to v6ops from dnsops, I thought I'd post her= e > what I wrote over there, as I think it's important as we're working on > solutions w/o a clear agreement on the problem: > > It seems that have the cart before the horse, so to speak. IMHO, we ne= ed to > do the following (and there's no reason they cannot occur rapidly): > > 1 - Develop a clear problem statement that outlines (1) how "broken" us= ers > are defined and (2) what effects this "brokenness" has on these end use= rs > (or other parts of the Internet). > > 2 - Describe all the various methods and tactics by which end user > "brokenness" can be detected. This may include website-based detection= , > DNS-query-based detection, or a variety of other methods. > > 3 - Then, after we have agreement on Problem Definition and Problem > Detection, we can measure the problem to understand what the scope or s= cale > of the problem is.=20 > > 4 - After we understand Problem Definition, Problem Detection, and Prob= lem > Scope, then you can arrive at possible solutions. Completely in agreement, although I'd like to add "...and whether such solutions are required." I feel uneasy messing around with the DNS by introducing "ugly hacks" to resolve a problem with "0.078% of people", thus affecting 99.922% of people who had no problem and who might then end up having a problem due to the hack. Agreed, 470K people is no small number, but we have to look at the bigger picture with 600M people. If we start designing Internet techno to look at the lowest common denominator, we're in for a very bad ride. Warmest regards, Olivier --=20 Olivier MJ Cr=E9pin-Leblond, PhD http://www.gih.com/ocl.html From remi.despres@free.fr Sat Apr 3 06:45:47 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 593F23A6905 for ; Sat, 3 Apr 2010 06:45:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.707 X-Spam-Level: X-Spam-Status: No, score=-0.707 tagged_above=-999 required=5 tests=[AWL=0.112, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, 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 91QgHtFftsTW for ; Sat, 3 Apr 2010 06:45:46 -0700 (PDT) Received: from smtp6-g21.free.fr (smtp6-g21.free.fr [212.27.42.6]) by core3.amsl.com (Postfix) with ESMTP id 765263A67A1 for ; Sat, 3 Apr 2010 06:45:44 -0700 (PDT) Received: from smtp6-g21.free.fr (localhost [127.0.0.1]) by smtp6-g21.free.fr (Postfix) with ESMTP id 2D0C9E080C1; Sat, 3 Apr 2010 15:45:39 +0200 (CEST) Received: from [192.168.0.13] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by smtp6-g21.free.fr (Postfix) with ESMTP id 35F13E080FB; Sat, 3 Apr 2010 15:45:37 +0200 (CEST) Subject: Re: FYI: DNSOPS presentation Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: <635027C3-455E-4DB3-84D1-9EE8C1856EF3@apple.com> Date: Sat, 3 Apr 2010 15:45:35 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <8FE2936E-C73F-4ED2-A84F-E37A59696BAF@free.fr> References: <4BB127CE.7020703@sri.com> <4BB60A4C.5090009@gmail.com> <635027C3-455E-4DB3-84D1-9EE8C1856EF3@apple.com> To: IPv6 Operations , 6man 6man X-Mailer: Apple Mail (2.1077) 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, 03 Apr 2010 13:45:47 -0000 Le 2 avr. 2010 =E0 20:11, james woodyatt a =E9crit : > Shorter james: the proposed hack cannot solve the problem it intends = to solve, and it breaks other networks that work fine today. It should = not be endorsed. +1 An approach that would break what works today in IPv6 MUST be rejected. It remains that a clear description of which problem is encountered, and = by which organization, might help to find a acceptable solution. RD From tore.anderson@redpill-linpro.com Sat Apr 3 08:11:58 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 860AB3A6850 for ; Sat, 3 Apr 2010 08:11:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.1 X-Spam-Level: X-Spam-Status: No, score=-0.1 tagged_above=-999 required=5 tests=[AWL=1.369, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13] 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 RSkWyx0-lpk5 for ; Sat, 3 Apr 2010 08:11:57 -0700 (PDT) Received: from mailhub.linpro.no (mailhub.linpro.no [87.238.49.141]) by core3.amsl.com (Postfix) with ESMTP id E1D803A67F2 for ; Sat, 3 Apr 2010 08:11:56 -0700 (PDT) Received: from localhost (mailhub.linpro.no [87.238.49.141]) by mailhub.linpro.no (Postfix) with ESMTP id 7FFE4C43BD; Sat, 3 Apr 2010 17:11:54 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at mailhub.linpro.no Received: from mailhub.linpro.no ([87.238.49.141]) by localhost (mailhub.linpro.no [87.238.49.141]) (amavisd-new, port 10024) with ESMTP id N1i1EYxMRfGk; Sat, 3 Apr 2010 17:11:46 +0200 (CEST) Received: from zimbra.redpill-linpro.com (claudius.linpro.no [87.238.49.234]) by mailhub.linpro.no (Postfix) with ESMTP; Sat, 3 Apr 2010 17:11:46 +0200 (CEST) Received: from localhost (localhost.localdomain [127.0.0.1]) by zimbra.redpill-linpro.com (Postfix) with ESMTP id 3C91F170C002; Sat, 3 Apr 2010 17:11:46 +0200 (CEST) X-Virus-Scanned: amavisd-new at claudius.linpro.no Received: from zimbra.redpill-linpro.com ([127.0.0.1]) by localhost (zimbra.redpill-linpro.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id veOxHwjV8PQ0; Sat, 3 Apr 2010 17:11:45 +0200 (CEST) Received: from envy.fud.no (stat.linpro.no [87.238.42.2]) by zimbra.redpill-linpro.com (Postfix) with ESMTPSA id 73E55170C001; Sat, 3 Apr 2010 17:11:45 +0200 (CEST) Message-ID: <4BB75AB0.40409@redpill-linpro.com> Date: Sat, 03 Apr 2010 17:11:44 +0200 From: Tore Anderson Organization: Redpill Linpro AS User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.9) Gecko/20100330 Fedora/3.0.4-1.fc12 Thunderbird/3.0.4 MIME-Version: 1.0 To: Olivier MJ Crepin-Leblond Subject: Re: FYI: DNSOPS presentation References: <4BB70402.3010700@gih.com> In-Reply-To: <4BB70402.3010700@gih.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: IPv6 Operations , 6man , Jason Livingood 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, 03 Apr 2010 15:11:58 -0000 Hi, * Olivier MJ Crepin-Leblond > Completely in agreement, although I'd like to add "...and whether > such solutions are required." Currently, the number of end users who can connect to a single-stack IPv4 web site is greater than the number of end users who can connect to a dual-stack web site. This situation must change, or you won't be seeing much IPv6 content appearing on the internet anytime soon. > I feel uneasy messing around with the DNS by introducing "ugly hacks" > to resolve a problem with "0.078% of people", thus affecting 99.922% > of people who had no problem and who might then end up having a > problem due to the hack. The obvious "solution" to this is currently to _not_ deploy IPv6 on existing content. For now, that will keep ~100% of users happy, and doesn't require any DNS hacks/whitelists to be maintained. But I still would like to deploy IPv6 somehow. Suggestions on how exactly I can go about doing that, without messing around with DNS or breaking connectivity for users who up until now have had no problems, would be greatly appreciated. Best regards, -- Tore Anderson Redpill Linpro AS - http://www.redpill-linpro.com/ Tel: +47 21 54 41 27 From marka@isc.org Sat Apr 3 08:45:57 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 C859F3A6897 for ; Sat, 3 Apr 2010 08:45:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.699 X-Spam-Level: **** X-Spam-Status: No, score=4.699 tagged_above=-999 required=5 tests=[DNS_FROM_OPENWHOIS=1.13, FH_HOST_EQ_D_D_D_D=0.765, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_NET=0.311, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RDNS_DYNAMIC=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 BeLbq1c26PUm for ; Sat, 3 Apr 2010 08:45:56 -0700 (PDT) Received: from farside.isc.org (farside.isc.org [IPv6:2001:4f8:3:bb::5]) by core3.amsl.com (Postfix) with ESMTP id BD50D3A677C for ; Sat, 3 Apr 2010 08:45:47 -0700 (PDT) Received: from drugs.dv.isc.org (c-66-30-16-106.hsd1.ma.comcast.net [66.30.16.106]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "drugs.dv.isc.org", Issuer "ISC CA" (not verified)) by farside.isc.org (Postfix) with ESMTP id EACA7E6EE9; Sat, 3 Apr 2010 15:45:43 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.14.3/8.14.3) with ESMTP id o33Fi6oT033111; Sun, 4 Apr 2010 02:44:06 +1100 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <201004031544.o33Fi6oT033111@drugs.dv.isc.org> To: Tore Anderson From: Mark Andrews References: <4BB70402.3010700@gih.com> <4BB75AB0.40409@redpill-linpro.com> Subject: Re: FYI: DNSOPS presentation In-reply-to: Your message of "Sat, 03 Apr 2010 17:11:44 +0200." <4BB75AB0.40409@redpill-linpro.com> Date: Sun, 04 Apr 2010 02:44:06 +1100 Sender: marka@isc.org Cc: Olivier MJ Crepin-Leblond , IPv6 Operations , Jason Livingood , 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, 03 Apr 2010 15:45:57 -0000 In message <4BB75AB0.40409@redpill-linpro.com>, Tore Anderson writes: > Hi, > > * Olivier MJ Crepin-Leblond > > > Completely in agreement, although I'd like to add "...and whether > > such solutions are required." > > Currently, the number of end users who can connect to a single-stack > IPv4 web site is greater than the number of end users who can connect > to a dual-stack web site. This situation must change, or you won't be > seeing much IPv6 content appearing on the internet anytime soon. > > > I feel uneasy messing around with the DNS by introducing "ugly hacks" > > to resolve a problem with "0.078% of people", thus affecting 99.922% > > of people who had no problem and who might then end up having a > > problem due to the hack. > > The obvious "solution" to this is currently to _not_ deploy IPv6 on > existing content. For now, that will keep ~100% of users happy, and > doesn't require any DNS hacks/whitelists to be maintained. > > But I still would like to deploy IPv6 somehow. Suggestions on how > exactly I can go about doing that, without messing around with DNS or > breaking connectivity for users who up until now have had no problems, > would be greatly appreciated. You turn IPv6 on a service at a time. Turn it on for delay tolerent services. e.g. SMTP. Turn it of for services which try different servers quickly. e.g. DNS. Turn it on for the client side. There may be few place to connect to now but the ratio of good to bad will get better as more people turn up IPv6 as a production service on the client side. > Best regards, > -- > Tore Anderson > Redpill Linpro AS - http://www.redpill-linpro.com/ > Tel: +47 21 54 41 27 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From tore.anderson@redpill-linpro.com Sat Apr 3 11:06:46 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 204923A69B0 for ; Sat, 3 Apr 2010 11:06:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=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 P+PkniISrEXo for ; Sat, 3 Apr 2010 11:06:45 -0700 (PDT) Received: from mailhub.linpro.no (mailhub.linpro.no [87.238.49.141]) by core3.amsl.com (Postfix) with ESMTP id B0B853A6980 for ; Sat, 3 Apr 2010 11:06:41 -0700 (PDT) Received: from localhost (mailhub.linpro.no [87.238.49.141]) by mailhub.linpro.no (Postfix) with ESMTP id D74B8C4046; Sat, 3 Apr 2010 20:06:38 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at mailhub.linpro.no Received: from mailhub.linpro.no ([87.238.49.141]) by localhost (mailhub.linpro.no [87.238.49.141]) (amavisd-new, port 10024) with ESMTP id 7mM+x-0zCHpF; Sat, 3 Apr 2010 20:06:30 +0200 (CEST) Received: from zimbra.redpill-linpro.com (claudius.linpro.no [87.238.49.234]) by mailhub.linpro.no (Postfix) with ESMTP; Sat, 3 Apr 2010 20:06:30 +0200 (CEST) Received: from localhost (localhost.localdomain [127.0.0.1]) by zimbra.redpill-linpro.com (Postfix) with ESMTP id 4F99E170C002; Sat, 3 Apr 2010 20:06:30 +0200 (CEST) X-Virus-Scanned: amavisd-new at claudius.linpro.no Received: from zimbra.redpill-linpro.com ([127.0.0.1]) by localhost (zimbra.redpill-linpro.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1LZwGnxfbcpo; Sat, 3 Apr 2010 20:06:28 +0200 (CEST) Received: from envy.fud.no (62.80-203-46.nextgentel.com [80.203.46.62]) by zimbra.redpill-linpro.com (Postfix) with ESMTPSA id 15842170C001; Sat, 3 Apr 2010 20:06:28 +0200 (CEST) Message-ID: <4BB783A3.3020500@redpill-linpro.com> Date: Sat, 03 Apr 2010 20:06:27 +0200 From: Tore Anderson Organization: Redpill Linpro AS User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.9) Gecko/20100330 Fedora/3.0.4-1.fc12 Thunderbird/3.0.4 MIME-Version: 1.0 To: Mark Andrews Subject: Re: FYI: DNSOPS presentation References: <4BB70402.3010700@gih.com> <4BB75AB0.40409@redpill-linpro.com> <201004031544.o33Fi6oT033111@drugs.dv.isc.org> In-Reply-To: <201004031544.o33Fi6oT033111@drugs.dv.isc.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Olivier MJ Crepin-Leblond , IPv6 Operations , Jason Livingood , 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, 03 Apr 2010 18:06:46 -0000 Hi Mark, * Mark Andrews > You turn IPv6 on a service at a time. Turn it on for delay tolerent > services. e.g. SMTP. Turn it of for services which try different > servers quickly. e.g. DNS. Turn it on for the client side. Sure thing, I've already done some of those, but it won't really change much. There's no real reason for a end-user to contact my SMTP or DNS servers directly, as he will normally relay e-mail/DNS queries via his own ISPs servers anyway. And the fact that all the workstations at my office have native IPv6 connectivity doesn't have any effect on all the broken end users in other networks. The problematic service is without question the web sites. > There may be few place to connect to now but the ratio of good to > bad will get better as more people turn up IPv6 as a production > service on the client side. Absolutely. I'm sure that at some point in the future there'll be more end users able to connect to a dualstacked web site than there is end users able to connect to a IPv4-only site. At that point you'll see lots of IPv6 content showing up. No problem. However, when will that point in time be? The way it's going right now it seems to me that it will be well after IPv4 pool is exhausted, when the IPv4 internet is starting really to crumble under CGNs and other life-extending band-aids. I'm more impatient than that though, and don't want to just sit around and wait until then. It appears other content providers like Yahoo and Google don't either. But short of resorting to DNS tricks, or attempting to persuade all the end users' ISPs and/or software vendors to fix their problems, I really don't see what else can be done. By the way I actively pursue the option of asking problematic networks and software vendors to fix their problems. It's a very slow process, though. Even when software patches are released, it takes lots of time before a sufficient amount of end-users have applied them. Best regards, -- Tore Anderson Redpill Linpro AS - http://www.redpill-linpro.com/ Tel: +47 21 54 41 27 From marka@isc.org Sat Apr 3 11:31:48 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 7B1403A67B7 for ; Sat, 3 Apr 2010 11:31:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.135 X-Spam-Level: **** X-Spam-Status: No, score=4.135 tagged_above=-999 required=5 tests=[AWL=0.565, BAYES_50=0.001, FH_HOST_EQ_D_D_D_D=0.765, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_NET=0.311, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RDNS_DYNAMIC=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 ATAXmJVJ0-A0 for ; Sat, 3 Apr 2010 11:31:47 -0700 (PDT) Received: from farside.isc.org (farside.isc.org [IPv6:2001:4f8:3:bb::5]) by core3.amsl.com (Postfix) with ESMTP id 541703A69C7 for ; Sat, 3 Apr 2010 11:31:47 -0700 (PDT) Received: from drugs.dv.isc.org (c-66-30-16-106.hsd1.ma.comcast.net [66.30.16.106]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "drugs.dv.isc.org", Issuer "ISC CA" (not verified)) by farside.isc.org (Postfix) with ESMTP id 9EF84E6F20; Sat, 3 Apr 2010 18:31:44 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.14.3/8.14.3) with ESMTP id o33IU6oq035214; Sun, 4 Apr 2010 04:30:06 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <201004031830.o33IU6oq035214@drugs.dv.isc.org> To: Tore Anderson From: Mark Andrews References: <4BB70402.3010700@gih.com> <4BB75AB0.40409@redpill-linpro.com> <201004031544.o33Fi6oT033111@drugs.dv.isc.org> <4BB783A3.3020500@redpill-linpro.com> Subject: Re: FYI: DNSOPS presentation In-reply-to: Your message of "Sat, 03 Apr 2010 20:06:27 +0200." <4BB783A3.3020500@redpill-linpro.com> Date: Sun, 04 Apr 2010 04:30:05 +1000 Sender: marka@isc.org Cc: Olivier MJ Crepin-Leblond , IPv6 Operations , Jason Livingood , 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, 03 Apr 2010 18:31:48 -0000 In message <4BB783A3.3020500@redpill-linpro.com>, Tore Anderson writes: > Hi Mark, > > * Mark Andrews > > > You turn IPv6 on a service at a time. Turn it on for delay tolerent > > services. e.g. SMTP. Turn it of for services which try different > > servers quickly. e.g. DNS. Turn it on for the client side. > > Sure thing, I've already done some of those, but it won't really change > much. There's no real reason for a end-user to contact my SMTP or DNS > servers directly, as he will normally relay e-mail/DNS queries via his > own ISPs servers anyway. And the fact that all the workstations at my > office have native IPv6 connectivity doesn't have any effect on all the > broken end users in other networks. Except it does, people saying we have IPv6 connectivity and it didn't break things will cause more people to turn on IPv6 as a production service which will disable the automatic transition mechanisms. > The problematic service is without question the web sites. > > > There may be few place to connect to now but the ratio of good to > > bad will get better as more people turn up IPv6 as a production > > service on the client side. > > Absolutely. I'm sure that at some point in the future there'll be more > end users able to connect to a dualstacked web site than there is end > users able to connect to a IPv4-only site. At that point you'll see > lots of IPv6 content showing up. No problem. > > However, when will that point in time be? Well we've had dual stack servers for years now so for us that point has long ago passed. We log bug reports when a service is not available over IPv6 as well as IPv4. > The way it's going right now > it seems to me that it will be well after IPv4 pool is exhausted, when > the IPv4 internet is starting really to crumble under CGNs and other > life-extending band-aids. I'm more impatient than that though, and > don't want to just sit around and wait until then. It appears other > content providers like Yahoo and Google don't either. But short of > resorting to DNS tricks, or attempting to persuade all the end users' > ISPs and/or software vendors to fix their problems, I really don't see > what else can be done. > > By the way I actively pursue the option of asking problematic networks > and software vendors to fix their problems. It's a very slow process, > though. Even when software patches are released, it takes lots of time > before a sufficient amount of end-users have applied them. > > Best regards, > -- > Tore Anderson > Redpill Linpro AS - http://www.redpill-linpro.com/ > Tel: +47 21 54 41 27 -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From brian.e.carpenter@gmail.com Sat Apr 3 16:37:25 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 6D4CE3A691C for ; Sat, 3 Apr 2010 16:37:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.62 X-Spam-Level: X-Spam-Status: No, score=0.62 tagged_above=-999 required=5 tests=[BAYES_50=0.001, RCVD_IN_SORBS_WEB=0.619] 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 sGFWaWEjAJUu for ; Sat, 3 Apr 2010 16:37:23 -0700 (PDT) Received: from mail-pz0-f191.google.com (mail-pz0-f191.google.com [209.85.222.191]) by core3.amsl.com (Postfix) with ESMTP id 944313A68B8 for ; Sat, 3 Apr 2010 16:37:23 -0700 (PDT) Received: by pzk29 with SMTP id 29so123796pzk.31 for ; Sat, 03 Apr 2010 16:37:20 -0700 (PDT) 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=BwNwAhG3meZ3oOWxBtqq2kWttsJW42chcxrp7HvCz7I=; b=NJu0LURo0JsbyKHj9aMbzkSe0CpIJO6+T8uTmlYPZRCgOP+K9gjiDT6VJO1t40ecCm n/9326NON2hCsSNyeOEAEJRmshtAtVaVMFIcfvso4sFKECDsTQMJIydMzuHOU4mohKxf NnNyEDy60dEMeQF/dP8qybju/fSJBX4KA5o1g= 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=ZkYJvkvu3QqXZBk04Kde5cYvMFnr1g0TC6Oalh2PcRcUS/6zCrJ3UGcAk7MnIDyb63 oTMeGS6jys0h5AFmybyG1qkMTrs9vciBxJIxkDpG6cy4rIZ9bG/0Xm5S1gE60ugW1eT1 ntu7Rk+bntzawQmGmcpzxSI4Q3AML5r+8FkTI= Received: by 10.114.248.20 with SMTP id v20mr3467298wah.65.1270337840255; Sat, 03 Apr 2010 16:37:20 -0700 (PDT) Received: from [192.168.160.234] ([12.172.25.68]) by mx.google.com with ESMTPS id 23sm9425903pzk.2.2010.04.03.16.37.17 (version=SSLv3 cipher=RC4-MD5); Sat, 03 Apr 2010 16:37:19 -0700 (PDT) Message-ID: <4BB7D125.6050209@gmail.com> Date: Sun, 04 Apr 2010 11:37:09 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Tore Anderson Subject: Re: FYI: DNSOPS presentation References: <4BB70402.3010700@gih.com> <4BB75AB0.40409@redpill-linpro.com> <201004031544.o33Fi6oT033111@drugs.dv.isc.org> <4BB783A3.3020500@redpill-linpro.com> In-Reply-To: <4BB783A3.3020500@redpill-linpro.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Olivier MJ Crepin-Leblond , IPv6 Operations , Jason Livingood , Mark Andrews , 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, 03 Apr 2010 23:37:25 -0000 On 2010-04-04 06:06, Tore Anderson wrote: ... > By the way I actively pursue the option of asking problematic networks > and software vendors to fix their problems. It's a very slow process, > though. Even when software patches are released, it takes lots of time > before a sufficient amount of end-users have applied them. We used to do a lot of that about 20 years ago when IPv4 connectivity and applications support was patchy. The Internet only works today because the message eventually got through (or the providers and vendors who didn't get the message vanished). There's no short cut. Brian From marka@isc.org Sun Apr 4 20:46:27 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 936CE3A6359 for ; Sun, 4 Apr 2010 20:46:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.852 X-Spam-Level: *** X-Spam-Status: No, score=3.852 tagged_above=-999 required=5 tests=[AWL=0.282, BAYES_50=0.001, FH_HOST_EQ_D_D_D_D=0.765, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_NET=0.311, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RDNS_DYNAMIC=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 Rl8FsdIwBsMo for ; Sun, 4 Apr 2010 20:46:26 -0700 (PDT) Received: from farside.isc.org (farside.isc.org [IPv6:2001:4f8:3:bb::5]) by core3.amsl.com (Postfix) with ESMTP id BCBB83A67B2 for ; Sun, 4 Apr 2010 20:46:01 -0700 (PDT) Received: from drugs.dv.isc.org (c-66-30-16-106.hsd1.ma.comcast.net [66.30.16.106]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "drugs.dv.isc.org", Issuer "ISC CA" (not verified)) by farside.isc.org (Postfix) with ESMTP id 84F43E71B8; Mon, 5 Apr 2010 03:45:57 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.14.3/8.14.3) with ESMTP id o353iDNg017254; Mon, 5 Apr 2010 13:44:13 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <201004050344.o353iDNg017254@drugs.dv.isc.org> To: Tore Anderson From: Mark Andrews References: <4BB70402.3010700@gih.com> <4BB75AB0.40409@redpill-linpro.com> Subject: Re: FYI: DNSOPS presentation In-reply-to: Your message of "Sat, 03 Apr 2010 17:11:44 +0200." <4BB75AB0.40409@redpill-linpro.com> Date: Mon, 05 Apr 2010 13:44:13 +1000 Sender: marka@isc.org Cc: Olivier MJ Crepin-Leblond , IPv6 Operations , Jason Livingood , 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, 05 Apr 2010 03:46:27 -0000 In message <4BB75AB0.40409@redpill-linpro.com>, Tore Anderson writes: > Hi, > > * Olivier MJ Crepin-Leblond > > > Completely in agreement, although I'd like to add "...and whether > > such solutions are required." > > Currently, the number of end users who can connect to a single-stack > IPv4 web site is greater than the number of end users who can connect > to a dual-stack web site. This situation must change, or you won't be > seeing much IPv6 content appearing on the internet anytime soon. > > > I feel uneasy messing around with the DNS by introducing "ugly hacks" > > to resolve a problem with "0.078% of people", thus affecting 99.922% > > of people who had no problem and who might then end up having a > > problem due to the hack. > > The obvious "solution" to this is currently to _not_ deploy IPv6 on > existing content. For now, that will keep ~100% of users happy, and > doesn't require any DNS hacks/whitelists to be maintained. > > But I still would like to deploy IPv6 somehow. Suggestions on how > exactly I can go about doing that, without messing around with DNS or > breaking connectivity for users who up until now have had no problems, > would be greatly appreciated. The first thing is to publish a complete description of the testing methodology and envionment. So far I havn't see it. Most of the transition technology involves encapsulation so was the mtu set to prevent pmtud being triggered due to encapsulation in IPv4? route add net 2002::/16 mtu 1480 or route add net 2002::/16 mtu 1280 What are the figures when you do this? Does either of these change the percentages? Similarly for route change net ::/0 mtu 1480 and route change net ::/0 mtu 1280 Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From tore.anderson@redpill-linpro.com Mon Apr 5 02:46:04 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 49F973A677D for ; Mon, 5 Apr 2010 02:46:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=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 66DeE8IO0S8q for ; Mon, 5 Apr 2010 02:46:03 -0700 (PDT) Received: from mailhub.linpro.no (mailhub.linpro.no [87.238.49.141]) by core3.amsl.com (Postfix) with ESMTP id AA5A03A676A for ; Mon, 5 Apr 2010 02:46:02 -0700 (PDT) Received: from localhost (mailhub.linpro.no [87.238.49.141]) by mailhub.linpro.no (Postfix) with ESMTP id 6D541CC569; Mon, 5 Apr 2010 11:45:59 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at mailhub.linpro.no Received: from mailhub.linpro.no ([87.238.49.141]) by localhost (mailhub.linpro.no [87.238.49.141]) (amavisd-new, port 10024) with ESMTP id vxUcb3py57zQ; Mon, 5 Apr 2010 11:45:52 +0200 (CEST) Received: from zimbra.redpill-linpro.com (claudius.linpro.no [87.238.49.234]) by mailhub.linpro.no (Postfix) with ESMTP; Mon, 5 Apr 2010 11:45:52 +0200 (CEST) Received: from localhost (localhost.localdomain [127.0.0.1]) by zimbra.redpill-linpro.com (Postfix) with ESMTP id 277F4170C002; Mon, 5 Apr 2010 11:45:52 +0200 (CEST) X-Virus-Scanned: amavisd-new at claudius.linpro.no Received: from zimbra.redpill-linpro.com ([127.0.0.1]) by localhost (zimbra.redpill-linpro.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dbCpRRmVO97i; Mon, 5 Apr 2010 11:45:51 +0200 (CEST) Received: from envy.fud.no (stat.linpro.no [87.238.42.2]) by zimbra.redpill-linpro.com (Postfix) with ESMTPSA id 655CA170C001; Mon, 5 Apr 2010 11:45:51 +0200 (CEST) Message-ID: <4BB9B14E.7080409@redpill-linpro.com> Date: Mon, 05 Apr 2010 11:45:50 +0200 From: Tore Anderson Organization: Redpill Linpro AS User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.9) Gecko/20100330 Fedora/3.0.4-1.fc12 Thunderbird/3.0.4 MIME-Version: 1.0 To: Mark Andrews Subject: Re: FYI: DNSOPS presentation References: <4BB70402.3010700@gih.com> <4BB75AB0.40409@redpill-linpro.com> <201004050344.o353iDNg017254@drugs.dv.isc.org> In-Reply-To: <201004050344.o353iDNg017254@drugs.dv.isc.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Olivier MJ Crepin-Leblond , IPv6 Operations , Jason Livingood , 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, 05 Apr 2010 09:46:04 -0000 Hi Mark, * Mark Andrews > The first thing is to publish a complete description of the testing > methodology and envionment. So far I havn't see it. I've posted descriptions a couple of times before: http://lists.cluenet.de/pipermail/ipv6-ops/2009-November/002658.html http://www.ietf.org/mail-archive/web/dnsop/current/msg08406.html Have a look, and don't hesitate to let me know if you're still wondering about something. > Most of the transition technology involves encapsulation so was the > mtu set to prevent pmtud being triggered due to encapsulation in > IPv4? I haven't set the MTU explicitly, but the objects that are being served are (intentionally) very small, so I never transmit any packets that are anywhere near 1280 octets. However I see that I occasionally receive incoming packets that exceed 1280 (HTTP requests with large amounts of header information). I will try to reduce the advertised TCP MSS to prevent PMTUD in the inbound direction from ever becoming an issue. These jumbo requests occur very seldom though, so I'll be very surprised if the lowered MSS will make a noticeable impact on the measured client loss. Thank you for your feedback! BR, -- Tore Anderson Redpill Linpro AS - http://www.redpill-linpro.com/ Tel: +47 21 54 41 27 From gert@Space.Net Mon Apr 5 03:29:57 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 48E653A68C4 for ; Mon, 5 Apr 2010 03:29:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[BAYES_50=0.001, NO_RELAYS=-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 1EUzdWyrwu7Y for ; Mon, 5 Apr 2010 03:29:56 -0700 (PDT) Received: from moebius3.space.net (moebius3.Space.Net [IPv6:2001:608:2:2::250]) by core3.amsl.com (Postfix) with ESMTP id 97D583A68CF for ; Mon, 5 Apr 2010 03:29:53 -0700 (PDT) Received: (qmail 2749 invoked by uid 1007); 5 Apr 2010 12:29:48 +0200 Date: Mon, 5 Apr 2010 12:29:48 +0200 From: Gert Doering To: james woodyatt Subject: Re: FYI: DNSOPS presentation Message-ID: <20100405102948.GL69383@Space.Net> References: <4BB127CE.7020703@sri.com> <4BB60A4C.5090009@gmail.com> <635027C3-455E-4DB3-84D1-9EE8C1856EF3@apple.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <635027C3-455E-4DB3-84D1-9EE8C1856EF3@apple.com> X-NCC-RegID: de.space User-Agent: Mutt/1.5.20 (2009-06-14) X-Mailman-Approved-At: Mon, 05 Apr 2010 09:05:19 -0700 Cc: IPv6 Operations , 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, 05 Apr 2010 10:29:57 -0000 Hi, On Fri, Apr 02, 2010 at 11:11:03AM -0700, james woodyatt wrote: > Shorter james: the proposed hack cannot solve the problem it intends to solve, and it breaks other networks that work fine today. It should not be endorsed. Seconded. (I can't remember how many times I have written in the last 10 years that the transport protocol used for DNS queries coming from recursor servers has nothing whatsoever to do with the transport protocol capabilities of the client sending the DNS query - even without any caching involved) Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 150584 SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279 From ocl@gih.com Mon Apr 5 09:20:53 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 F0B2428C16C for ; Mon, 5 Apr 2010 09:20:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=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 d3zXS8WbFjbl for ; Mon, 5 Apr 2010 09:20:51 -0700 (PDT) Received: from waikiki.gih.co.uk (salsa.gih.co.uk [IPv6:2001:470:1f09:92d::b]) by core3.amsl.com (Postfix) with ESMTP id B567228C1AB for ; Mon, 5 Apr 2010 09:20:35 -0700 (PDT) Received: from waikiki.gih.co.uk (localhost6.localdomain6 [IPv6:::1]) by waikiki.gih.co.uk (Postfix) with ESMTP id 0259018F3AF; Mon, 5 Apr 2010 17:20:29 +0100 (BST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=gih.com; h=message-id:date :from:mime-version:to:cc:subject:references:in-reply-to :content-type; s=mahalo1; bh=1wqmPcUdNlwDrB3ZEw6h/Xec48Q=; b=eSE 9pQuVykZ1AwS/NsyjFY/b2mxvuZbIR5Zev84t+9mqfuUknabbwjIJOFMcZvRbnw/ MnUgaxk0lnShD8oHt+noM8LuV91GyBFOIolHJunWpt5lJjQPKYzOqAqzM1zf/bhF wsFoP2u6EgonoumyoILpAJ5cCAQDvvWsY1LE/Peo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gih.com; h=message-id:date :from:mime-version:to:cc:subject:references:in-reply-to :content-type; q=dns; s=mahalo1; b=CcQQB3DbgJ428I4ZEFyKbVIBIsWMG wPCmfaZKF6QCmhPRy3UrR9vJ7A6EgFd9IqjEok6If+L11/nCYU5hK+/UUwRfj+gF qzZYH13KmP6Q4D0hpr+Z+0EBiGcQFjFxlqqq8avPgFnS0Lqlt84z7YoNKLcIX50z 8Sb4dizRUvV0jk= Received: from [192.168.1.45] (ANice-151-1-80-28.w86-193.abo.wanadoo.fr [86.193.242.28]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by waikiki.gih.co.uk (Postfix) with ESMTPSA id 96FEA18F3AB; Mon, 5 Apr 2010 17:20:27 +0100 (BST) Message-ID: <4BBA0DD3.4050706@gih.com> Date: Mon, 05 Apr 2010 18:20:35 +0200 From: Olivier MJ Crepin-Leblond User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; fr; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: Mark Andrews Subject: Re: FYI: DNSOPS presentation References: <4BB70402.3010700@gih.com> <4BB75AB0.40409@redpill-linpro.com> <201004031544.o33Fi6oT033111@drugs.dv.isc.org> In-Reply-To: <201004031544.o33Fi6oT033111@drugs.dv.isc.org> X-Enigmail-Version: 1.0.1 Content-Type: multipart/alternative; boundary="------------050606050004090605040006" X-Mailman-Approved-At: Mon, 05 Apr 2010 12:08:07 -0700 Cc: IPv6 Operations , Jason Livingood , 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, 05 Apr 2010 16:20:53 -0000 This is a multi-part message in MIME format. --------------050606050004090605040006 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Le 03/04/2010 17:44, Mark Andrews a =E9crit : > > You turn IPv6 on a service at a time. Turn it on for delay tolerent > services. e.g. SMTP. Turn it of for services which try different > servers quickly. e.g. DNS. Turn it on for the client side. There > may be few place to connect to now but the ratio of good to bad > will get better as more people turn up IPv6 as a production service > on the client side. > > =20 This works exactly in line with what I have been suggesting my corporate clients should do when they are looking at implementing IPv6. A copy of my presentation slides can be found on: http://www.slideshare.net/ocl999/suggestion-for-an-ipv6-roll-out Turning the delay tolerant services on, migrating such services to dual stack, enables personnel to gain real IPv6 traffic & admin experience with minimal potential disruption - at low cost. I realise that I am digressing from the matter in the subject, so I'll stop here. Kindest regards, Olivier --=20 Olivier MJ Cr=E9pin-Leblond, PhD http://www.gih.com/ocl.html --------------050606050004090605040006 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit

Le 03/04/2010 17:44, Mark Andrews a écrit :

You turn IPv6 on a service at a time.  Turn it on for delay tolerent
services.  e.g. SMTP.  Turn it of for services which try different
servers quickly.  e.g. DNS.  Turn it on for the client side.  There
may be few place to connect to now but the ratio of good to bad
will get better as more people turn up IPv6 as a production service
on the client side.

  

This works exactly in line with what I have been suggesting my corporate clients should do when they are looking at implementing IPv6.
A copy of my presentation slides can be found on:
http://www.slideshare.net/ocl999/suggestion-for-an-ipv6-roll-out

Turning the delay tolerant services on, migrating such services to dual stack, enables personnel to gain real IPv6 traffic & admin experience with minimal potential disruption - at low cost.
I realise that I am digressing from the matter in the subject, so I'll stop here.

Kindest regards,

Olivier

-- 
Olivier MJ Crépin-Leblond, PhD
http://www.gih.com/ocl.html
--------------050606050004090605040006-- From root@core3.amsl.com Wed Apr 7 15:15:01 2010 Return-Path: X-Original-To: ipv6@ietf.org Delivered-To: ipv6@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id CBFBA3A696C; Wed, 7 Apr 2010 15:15:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Subject: I-D ACTION:draft-ietf-6man-dns-options-bis-00.txt Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20100407221501.CBFBA3A696C@core3.amsl.com> Date: Wed, 7 Apr 2010 15:15:01 -0700 (PDT) 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, 07 Apr 2010 22:15:02 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPv6 Maintenance Working Group of the IETF. Title : IPv6 Router Advertisement Options for DNS Configuration RFC 5006-bis Author(s) : J. Jeong, L. Beloeil, S. Madanapalli, S. Park Filename : draft-ietf-6man-dns-options-bis-00.txt Pages : 16 Date : 2010-4-5 This document specifies IPv6 Router Advertisement options to allow IPv6 routers to advertise a list of DNS recursive server addresses and a DNS search list to IPv6 hosts. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-6man-dns-options-bis-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-dns-options-bis-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-4-7151233.I-D@ietf.org> --NextPart-- From brian.e.carpenter@gmail.com Tue Apr 13 21:48:34 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 6B7BE3A6B9A for ; Tue, 13 Apr 2010 21:48:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.174 X-Spam-Level: X-Spam-Status: No, score=-2.174 tagged_above=-999 required=5 tests=[AWL=0.425, 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 lCFALN5u04LG for ; Tue, 13 Apr 2010 21:48:33 -0700 (PDT) Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by core3.amsl.com (Postfix) with ESMTP id 943733A68D8 for ; Tue, 13 Apr 2010 21:48:33 -0700 (PDT) Received: by pwj2 with SMTP id 2so6082626pwj.31 for ; Tue, 13 Apr 2010 21:48:25 -0700 (PDT) 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=2POM2yoHaDqNEqRS3IHp+cAZLVrqs8XNWRIIw57BRZM=; b=IHEuu5yFmfS+3OQjYOBtQqIOXH555mN1QLMTuBDbzUss0UICTU45PVipiVm7SXJm4c AugEHbgqeIX+I7TISgZKoHRJWN4Dwa/Kx4E110VjUBPY7aXYjim9Xx9WwQbOtXL400KE eeQF4vRYapIwAjBDrAMSUH2wqs813uD4UCMu0= 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=Z+ZkLogeVhzk7O08Fr4RgN7AW2lNaybU+KSjrzmdecJCJQ/NSe8JB4W0RZ6X5rg895 T7V34ShGSzMDSsyv47EIwCQ4YCZBuzu7tpVadAa6aY+eSpGiMVvTzz4Jbs7IfYqmeRdZ aO1MccO4/OtPemO1peqAeNkOsRS4vLcb6ZYyE= Received: by 10.140.83.40 with SMTP id g40mr6609785rvb.223.1271220505379; Tue, 13 Apr 2010 21:48:25 -0700 (PDT) Received: from [130.216.38.124] (stf-brian.sfac.auckland.ac.nz [130.216.38.124]) by mx.google.com with ESMTPS id 21sm5619210pzk.0.2010.04.13.21.48.23 (version=SSLv3 cipher=RC4-MD5); Tue, 13 Apr 2010 21:48:24 -0700 (PDT) Message-ID: <4BC54919.3000900@gmail.com> Date: Wed, 14 Apr 2010 16:48:25 +1200 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: New Version Notification for draft-carpenter-6man-flow-update-02] Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Apr 2010 04:48:34 -0000 Hi, This is completely revised from the proposal we presented in Anaheim. This version allows locally defined use of the flow label in a simpler way, as the discussion suggested. It's still quite a dense read, but we believe that if this was adopted, it would open the way to actually using the flow label. Brian and Sheng -------- Original Message -------- Subject: New Version Notification for draft-carpenter-6man-flow-update-02 Date: Tue, 13 Apr 2010 21:44:42 -0700 (PDT) From: IETF I-D Submission Tool To: brian.e.carpenter@gmail.com CC: shengjiang@huawei.com A new version of I-D, draft-carpenter-6man-flow-update-02.txt has been successfully submitted by Brian Carpenter and posted to the IETF repository. Filename: draft-carpenter-6man-flow-update Revision: 02 Title: Update to the IPv6 flow label specification Creation_date: 2010-04-13 WG ID: Independent Submission Number_of_pages: 10 Abstract: Various uses proposed for the IPv6 flow label are incompatible with its existing specification. This document describes changes to the specification that permit additional use cases as well as allowing continued use of the previous specification. The IETF Secretariat. From paravpandit@yahoo.com Wed Apr 14 02:00:49 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 207233A69E5 for ; Wed, 14 Apr 2010 02:00:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.002 X-Spam-Level: X-Spam-Status: No, score=0.002 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=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 JWmJBHOTmDms for ; Wed, 14 Apr 2010 02:00:48 -0700 (PDT) Received: from web30108.mail.mud.yahoo.com (web30108.mail.mud.yahoo.com [209.191.69.40]) by core3.amsl.com (Postfix) with SMTP id 2A3123A69CE for ; Wed, 14 Apr 2010 02:00:48 -0700 (PDT) Received: (qmail 37869 invoked by uid 60001); 14 Apr 2010 09:00:36 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1271235636; bh=oDJOYGxgt5L6vlbDghflpUtNAkL6bXKikylrIoPMyr0=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:MIME-Version:Content-Type; b=PeEo9noye/AZJvwir5gDEp7OKhlKVmJW0SNjOpoboO9GPfqZ/PEw+Shiee4XI1I9OKgjk9nsWeuouDGCIwp5Rxi1XrRMYCr1ver7eO1p4Nu6ntg9kTlTq4sMBvUCJGwPp3BCTmP5t7+R0KyWU0kL9cMUl+0471PZWBKllZuaga4= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:MIME-Version:Content-Type; b=NyftdbtU0ukJXMo4AzjlXWcVWE69/BEJH6uVjSdaA/pnIaV3WlaJXV+XC/yp2mKaS3AJuNpfALpmz0Z2Nl1545cfmwdUlBrhsnD8ENz4Mia9/iqBE0qU73+ENawzednI4XBZLDYk1B11J9aUdc7WDWHglQt26Xow4jdF+UXiGL0=; Message-ID: <148247.37026.qm@web30108.mail.mud.yahoo.com> X-YMail-OSG: RdNkGzAVM1nzaw0LoqQFgwDS4JQr1LPZ8S1Fl8_8qgjjcUp cp0txiy8lpv1p6CUdywwB3wISOg3qVRLYMhfBNA7uooInYbQ0RhbIaJMUu5f y4Xm4dldmzCKEdJarxVFZr8pI7GDgJGyD8Aa5U80s1MrRMA3PYrJ56NSMLhO c1Xcsn8gVym2IWyIU4SCAMAWAfA2u624GjHhya4cXw1AvQt1hBSkTm1Cnabe 7gakLR5cD2c59FJb_ZM8lJdec16hHb2cm08IBg3geKGYLKZ_EWSYRNXZ1C_Y 1lteQyYl_B6ill_iW80w.ADlnAnoD_gEi.Es- Received: from [111.93.130.139] by web30108.mail.mud.yahoo.com via HTTP; Wed, 14 Apr 2010 02:00:36 PDT X-Mailer: YahooMailClassic/10.1.9 YahooMailWebService/0.8.102.267879 Date: Wed, 14 Apr 2010 02:00:36 -0700 (PDT) From: Parav Pandit Subject: which interface to choose to send to destination link-local address - any RFC? To: ipv6@ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-254538328-1271235636=:37026" 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, 14 Apr 2010 09:00:49 -0000 --0-254538328-1271235636=:37026 Content-Type: text/plain; charset=us-ascii Hi, In IPv6 stack implementation, How IPv6 stack should select the outgoing interface to choose (when multiple interfaces) are available? Typically when the destination is the link-local address which may be on-link on both the interfaces (before the neighbor discovery) is done? Should IPv6 stack do Neighbor discovery on all multiple interfaces in the host? Which RFC defines this behavior? I referred RFC 3484 (Default Address Selection for IPv6) but doesn't seem to define this. I hope I am asking on the right mailing list. If not please divert me to the correct one. Regards, Parav Pandit --0-254538328-1271235636=:37026 Content-Type: text/html; charset=us-ascii
Hi,

In IPv6 stack implementation,

How IPv6 stack should select the outgoing interface to choose (when multiple interfaces) are available? Typically when the destination is the link-local address which may be on-link on both the interfaces (before the neighbor discovery) is done?

Should IPv6 stack do Neighbor discovery on all multiple interfaces in the host?

Which RFC defines this behavior? I referred RFC 3484 (Default Address Selection for IPv6) but doesn't seem to define this.

I hope I am asking on the right mailing list. If not please divert me to the correct one.

Regards,
Parav Pandit


--0-254538328-1271235636=:37026-- From remi@remlab.net Wed Apr 14 02:30:09 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 739C43A691C for ; Wed, 14 Apr 2010 02:30:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.147 X-Spam-Level: X-Spam-Status: No, score=-2.147 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, SARE_SUB_ENC_UTF8=0.152] 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 HL2cJViH0LQm for ; Wed, 14 Apr 2010 02:30:08 -0700 (PDT) Received: from yop.chewa.net (yop.chewa.net [91.121.105.214]) by core3.amsl.com (Postfix) with ESMTP id 33FC63A67F5 for ; Wed, 14 Apr 2010 02:30:08 -0700 (PDT) Received: by yop.chewa.net (Postfix, from userid 33) id 4CB611351; Wed, 14 Apr 2010 11:29:59 +0200 (CEST) To: Parav Pandit Subject: Re: which interface to choose to send to destination link-local address - any =?UTF-8?Q?RFC=3F?= MIME-Version: 1.0 Date: Wed, 14 Apr 2010 11:29:59 +0200 From: =?UTF-8?Q?R=C3=A9mi_Denis-Courmont?= Organization: Remlab.net In-Reply-To: <148247.37026.qm@web30108.mail.mud.yahoo.com> References: <148247.37026.qm@web30108.mail.mud.yahoo.com> Message-ID: <0dceffe53011f294c91870da43bacd8e@chewa.net> X-Sender: remi@remlab.net User-Agent: RoundCube Webmail/0.1 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit 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, 14 Apr 2010 09:30:09 -0000 On Wed, 14 Apr 2010 02:00:36 -0700 (PDT), Parav Pandit wrote: > How IPv6 stack should select the outgoing interface to choose (when > multiple interfaces) are available? Typically when the destination is the > link-local address which may be on-link on both the interfaces (before the > neighbor discovery) is done? Typical IPv6 stacks will simply rely on the application to provide the interface (as sockaddr_in6.sin6_scope_id). If the interface is not provided, attempt to send to a link-scoped destination will simply fail. > Should IPv6 stack do Neighbor discovery on all multiple interfaces in the > host? No. -- Rémi Denis-Courmont http://www.remlab.net http://fi.linkedin.com/in/remidenis From mohacsi@niif.hu Wed Apr 14 02:31:48 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 3EEA63A69E5 for ; Wed, 14 Apr 2010 02:31:48 -0700 (PDT) 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 j0aXarLiaIYH for ; Wed, 14 Apr 2010 02:31:47 -0700 (PDT) Received: from mail.ki.iif.hu (mail.ki.iif.hu [IPv6:2001:738:0:411::241]) by core3.amsl.com (Postfix) with ESMTP id 33DA53A69A5 for ; Wed, 14 Apr 2010 02:31:47 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mail.ki.iif.hu (Postfix) with ESMTP id 67E2F86D05; Wed, 14 Apr 2010 11:31:39 +0200 (CEST) X-Virus-Scanned: by amavisd-new at mignon.ki.iif.hu Received: from mail.ki.iif.hu ([127.0.0.1]) by localhost (mignon.ki.iif.hu [127.0.0.1]) (amavisd-new, port 10024) with LMTP id uoN+47by1z8i; Wed, 14 Apr 2010 11:31:36 +0200 (CEST) Received: by mail.ki.iif.hu (Postfix, from userid 9002) id AD9E586D1C; Wed, 14 Apr 2010 11:31:36 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by mail.ki.iif.hu (Postfix) with ESMTP id AB98086D03; Wed, 14 Apr 2010 11:31:36 +0200 (CEST) Date: Wed, 14 Apr 2010 11:31:36 +0200 (CEST) From: Mohacsi Janos X-X-Sender: mohacsi@mignon.ki.iif.hu To: Parav Pandit Subject: Re: which interface to choose to send to destination link-local address - any RFC? In-Reply-To: <148247.37026.qm@web30108.mail.mud.yahoo.com> Message-ID: References: <148247.37026.qm@web30108.mail.mud.yahoo.com> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: 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, 14 Apr 2010 09:31:48 -0000 On Wed, 14 Apr 2010, Parav Pandit wrote: > Hi, > > In IPv6 stack implementation, > > How IPv6 stack should select the outgoing interface to choose (when multiple interfaces) are available? > Typically when the destination is the link-local address which may be on-link on both the interfaces (before > the neighbor discovery) is done? > > Should IPv6 stack do Neighbor discovery on all multiple interfaces in the host? > > Which RFC defines this behavior? I referred RFC 3484 (Default Address Selection for IPv6) but doesn't seem to > define this. > > I hope I am asking on the right mailing list. If not please divert me to the correct one. The application should know which interface/link to choose in case of link-local address. The link-local is relevant to a specific link only. e.g. ping6 -I bge0 fe80::21b:63ff:fe9f:4527 PING6(56=40+8+8 bytes) fe80::206:5bff:fef2:41c1%bge0 --> fe80::21b:63ff:fe9f:4527 16 bytes from fe80::21b:63ff:fe9f:4527%bge0, icmp_seq=0 hlim=64 time=7.292 ms 16 bytes from fe80::21b:63ff:fe9f:4527%bge0, icmp_seq=1 hlim=64 time=0.656 ms ^C --- fe80::21b:63ff:fe9f:4527 ping6 statistics --- 2 packets transmitted, 2 packets received, 0.0% packet loss round-trip min/avg/max/std-dev = 0.656/3.974/7.292/3.318 ms ping6 fe80::21b:63ff:fe9f:4527 ping6: UDP connect: Network is unreachable If the application knows which link to use then IPv6 protocol stack might use ND to dicover/reach the node. Best Regards, Janos Mohacsi From paravpandit@yahoo.com Wed Apr 14 03:57:04 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 4FEA63A69E2 for ; Wed, 14 Apr 2010 03:57:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.298 X-Spam-Level: X-Spam-Status: No, score=-1.298 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, HTML_MESSAGE=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 yrlI8pLbMbZG for ; Wed, 14 Apr 2010 03:57:03 -0700 (PDT) Received: from web30104.mail.mud.yahoo.com (web30104.mail.mud.yahoo.com [209.191.69.36]) by core3.amsl.com (Postfix) with SMTP id D999D3A69C6 for ; Wed, 14 Apr 2010 03:56:55 -0700 (PDT) Received: (qmail 51524 invoked by uid 60001); 14 Apr 2010 10:56:50 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1271242610; bh=UFjj8f8iKHcX/Ezzfe8CAIn+M1YjBNZ4STt5fyAs1A0=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=i6G6VQ1l1fjElyQ41upPupkd+QDdlgV3mNyaL5SQPBg67hDBj68e7V2lhsfaufMsSxSTSkv2jjQspo7xozeW6pUgb+grwGxGvXuitFgC/YV14h0CwrsX40XUVPY47m1FsrXLZ38Gua+0hD+s7K0c0lvVj5rCiLpLw5scuiqSZ5Y= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=fsZDkT7S1t9eC/DkeIN7wg+Hyifyc86ysoMelYmMfSqcjSiGLhOP7XRQcGe/9SH6cjvfjpVIpnGy3/mYQDsPxLFYBki4u1MtQVyrrBNYyBC4AE8qLzKwtceCzUSoS3hM9nONurbDdYFNz+Q4N1i9K4P0SgPSSZelMH2yS4Hadfk=; Message-ID: <30123.50490.qm@web30104.mail.mud.yahoo.com> X-YMail-OSG: _utJeCkVM1ltQh1_rGO7btJN.dS_bg23OGX2eev18ZqInDZ UMto9NoV1WP8uCFo4xeWqWTuQRJk.W31V6AaqJbidLr5sDB5mpGTXO6KelBk z13zYerLYPeKl.eNmmbsQz0PjqEIiSbyjavN.KdQ6UizrvcA.tSOl2e92.Lr OmdVALHShLPPHpbyJYsdMAN7CmH4m5nVWLX8vzNfxkWNrffMropf0VIwy4rm NWZl3k_XBUDfaXqVD3reJKFpYEiNGHCgQKjcLrAU4TCeKuOaSzbnhEU.MOie OvZBKoBMr27GFKw_13Opa0CYCro4i.JEe4jDC5ME0c9EMD9sKJed1.v8C68k ijhwr1Uo- Received: from [111.93.130.139] by web30104.mail.mud.yahoo.com via HTTP; Wed, 14 Apr 2010 03:56:49 PDT X-Mailer: YahooMailClassic/10.1.9 YahooMailWebService/0.8.102.267879 Date: Wed, 14 Apr 2010 03:56:49 -0700 (PDT) From: Parav Pandit Subject: Re: which interface to choose to send to destination link-local address - any RFC? To: Mohacsi Janos In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-998949753-1271242609=:50490" 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, 14 Apr 2010 10:57:04 -0000 --0-998949753-1271242609=:50490 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Thanks for the quick help. Good example of UDP. So in case of TCP, client which tries to connect to the server, should prov= ide its link-local source address during socket(), bind() calls. Based on t= hat IPv6 stack will figure out the out-going interface. Is that correct understanding? Regards, Parav Pandit --- On Wed, 4/14/10, Mohacsi Janos wrote: From: Mohacsi Janos Subject: Re: which interface to choose to send to destination link-local ad= dress - any RFC? To: "Parav Pandit" Cc: ipv6@ietf.org Date: Wednesday, April 14, 2010, 3:01 PM On Wed, 14 Apr 2010, Parav Pandit wrote: > Hi, >=20 > In IPv6 stack implementation, >=20 > How IPv6 stack should select the outgoing interface to choose (when multi= ple interfaces) are available? > Typically when the destination is the link-local address which may be on-= link on both the interfaces (before > the neighbor discovery) is done? >=20 > Should IPv6 stack do Neighbor discovery on all multiple interfaces in the= host? >=20 > Which RFC defines this behavior? I referred RFC 3484 (Default Address Sel= ection for IPv6) but doesn't seem to > define this. >=20 > I hope I am asking on the right mailing list. If not please divert me to = the correct one. The application should know which interface/link to choose in case of link-= local address. The link-local is relevant to a specific link only. e.g. ping6 -I bge0 fe80::21b:63ff:fe9f:4527 PING6(56=3D40+8+8 bytes) fe80::206:5bff:fef2:41c1%bge0 --> fe80::21b:63ff:f= e9f:4527 16 bytes from fe80::21b:63ff:fe9f:4527%bge0, icmp_seq=3D0 hlim=3D64 time=3D= 7.292 ms 16 bytes from fe80::21b:63ff:fe9f:4527%bge0, icmp_seq=3D1 hlim=3D64 time=3D= 0.656 ms ^C --- fe80::21b:63ff:fe9f:4527 ping6 statistics --- 2 packets transmitted, 2 packets received, 0.0% packet loss round-trip min/avg/max/std-dev =3D 0.656/3.974/7.292/3.318 ms ping6 fe80::21b:63ff:fe9f:4527 ping6: UDP connect: Network is unreachable If the application knows which link to use then IPv6 protocol stack might u= se ND to dicover/reach the node. Best Regards, =A0=A0=A0 =A0=A0=A0 Janos Mohacsi =0A=0A=0A --0-998949753-1271242609=:50490 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
Thanks for the quick help.
Good example of= UDP.
So in case of TCP, client which tries to connect to the server, sh= ould provide its link-local source address during socket(), bind() calls. B= ased on that IPv6 stack will figure out the out-going interface.
Is that= correct understanding?

Regards,
Parav Pandit


--- On <= b>Wed, 4/14/10, Mohacsi Janos <mohacsi@niif.hu> wrote:
=

From: Mohacsi Janos <mohacsi@niif.hu>Subject: Re: which interface to choose to send to destination link-local a= ddress - any RFC?
To: "Parav Pandit" <paravpandit@yahoo.com>
Cc= : ipv6@ietf.org
Date: Wednesday, April 14, 2010, 3:01 PM




On Wed, 14 Apr 2010, Parav Pandit wrote:
> Hi,
>
> In IPv6 stack implementation,
>
> How IP= v6 stack should select the outgoing interface to choose (when multiple inte= rfaces) are available?
> Typically when the destination is the link-l= ocal address which may be on-link on both the interfaces (before
> th= e neighbor discovery) is done?
>
> Should IPv6 stack do Neighb= or discovery on all multiple interfaces in the host?
>
> Which= RFC defines this behavior? I referred RFC 3484 (Default Address Selection = for IPv6) but doesn't seem to
> define this.
>
> I hope = I am asking on the right mailing list. If not please divert me to the corre= ct one.


The application should know which interface/link to choo= se in case of link-local address. The link-local is relevant to a specific = link only.

e.g.

ping6 -I bge0 fe80::21b:63ff:fe9f:4527
PIN= G6(56=3D40+8+8 bytes) fe80::206:5bff:fef2:41c1%bge0 --> fe80::21b:63ff:fe9f:4527
16 bytes from fe80::21b:63ff:fe9f:4527%bge0, i= cmp_seq=3D0 hlim=3D64 time=3D7.292 ms
16 bytes from fe80::21b:63ff:fe9f:= 4527%bge0, icmp_seq=3D1 hlim=3D64 time=3D0.656 ms
^C
--- fe80::21b:63= ff:fe9f:4527 ping6 statistics ---
2 packets transmitted, 2 packets recei= ved, 0.0% packet loss
round-trip min/avg/max/std-dev =3D 0.656/3.974/7.2= 92/3.318 ms


ping6 fe80::21b:63ff:fe9f:4527
ping6: UDP connect= : Network is unreachable

If the application knows which link to use = then IPv6 protocol stack might use ND to dicover/reach the node.

Bes= t Regards,
        Janos Mohacsi
=

=0A=0A=0A=0A=0A=0A=0A=0A --0-998949753-1271242609=:50490-- From simon.perreault@viagenie.ca Wed Apr 14 05:01:23 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 9172328C25F for ; Wed, 14 Apr 2010 05:01:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.371 X-Spam-Level: X-Spam-Status: No, score=-2.371 tagged_above=-999 required=5 tests=[AWL=0.228, 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 aWlKKqIeKRhg for ; Wed, 14 Apr 2010 05:01:22 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [206.123.31.2]) by core3.amsl.com (Postfix) with ESMTP id A403F3A6C30 for ; Wed, 14 Apr 2010 04:58:13 -0700 (PDT) Received: from ringo.viagenie.ca (ringo.viagenie.ca [IPv6:2620:0:230:c000::67]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 94A1321BC5 for ; Wed, 14 Apr 2010 07:58:06 -0400 (EDT) Message-ID: <4BC5ADCD.7010801@viagenie.ca> Date: Wed, 14 Apr 2010 07:58:05 -0400 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.9) Gecko/20100330 Fedora/3.0.4-1.fc12 Thunderbird/3.0.4 MIME-Version: 1.0 To: ipv6@ietf.org Subject: Re: which interface to choose to send to destination link-local address - any RFC? References: <30123.50490.qm@web30104.mail.mud.yahoo.com> In-Reply-To: <30123.50490.qm@web30104.mail.mud.yahoo.com> 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: Wed, 14 Apr 2010 12:01:23 -0000 On 2010-04-14 06:56, Parav Pandit wrote: > So in case of TCP, client which tries to connect to the server, should > provide its link-local source address during socket(), bind() calls. No. On the client side there should be no bind() call, and the socket() call is unaffected since it doesn't take any address parameter. In the connect() call, for the struct sockaddr parameter, the sin6_addr member will contain the server's link-local address and the sin6_scope_id member will contain the scope id of the client's interface on which the server can be reached. > Based on that IPv6 stack will figure out the out-going interface. There is no need for the stack to "figure out" the outgoing interface since the application tells it plainly in the sin6_scope_id parameter. Simon -- NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca vCard 4.0 --> http://www.vcarddav.org From remi.despres@free.fr Wed Apr 14 09:06:34 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 2B20C3A67A4 for ; Wed, 14 Apr 2010 09:06:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.442 X-Spam-Level: X-Spam-Status: No, score=0.442 tagged_above=-999 required=5 tests=[AWL=0.902, BAYES_05=-1.11, 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 pwOzurUfeQ8r for ; Wed, 14 Apr 2010 09:06:30 -0700 (PDT) Received: from smtp6-g21.free.fr (smtp6-g21.free.fr [212.27.42.6]) by core3.amsl.com (Postfix) with ESMTP id ED7C73A68B9 for ; Wed, 14 Apr 2010 09:06:28 -0700 (PDT) Received: from smtp6-g21.free.fr (localhost [127.0.0.1]) by smtp6-g21.free.fr (Postfix) with ESMTP id 04504E081A0; Wed, 14 Apr 2010 18:06:17 +0200 (CEST) Received: from [192.168.0.13] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by smtp6-g21.free.fr (Postfix) with ESMTP id E52A9E08104; Wed, 14 Apr 2010 18:06:14 +0200 (CEST) Subject: Re: [Fwd: New Version Notification for draft-carpenter-6man-flow-update-02] Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: <4BC54919.3000900@gmail.com> Date: Wed, 14 Apr 2010 18:06:14 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4BC54919.3000900@gmail.com> To: Brian E Carpenter , Sheng Jiang X-Mailer: Apple Mail (2.1078) 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: Wed, 14 Apr 2010 16:06:34 -0000 Brian, Sheng, I carefully read the draft, and read again RFC 3697 and = draft-carpenter-6man-flow-update-02. The draft is IMHO overly hard to understand but, unless I misunderstand = its intent (which is quite possible), I appreciate what it proposes. I do support the intent, but feel uncomfortable with how it is = introduced. In my understanding: A) The essential changes are: A1. Flow Labels MAY be changed within the network, instead of "MUST be = delivered unchanged". A2. Nodes that set Flow Labels MAY apply local policies, including = stateless ones, instead of "SHOULD select new Flow Label values in a = well-defined sequence (e.g., sequential or pseudo-random". B) The essentials of what is kept are: B1. Where Flow Labels are set, their values MUST be the same for = packets that have the same 5-tuples (or 3-tuples), and are separated by = less than 120s.=20 B3. For flow-based routing optimization to be possible, Flow Labels = should in general be given different values for different 5-tuples (or = 3-tuples) that share the same source-address/destination-address = couples.=20 If this makes sense, I am convinced that it would be better to propose a = clear and simple new RFC, and obsolete RFC 3697. Trying to complement RFC 3697 with what amounts to a significant change = is in my understanding bond to be awkward. Thoughts? Kind regards, RD =20 Le 14 avr. 2010 =E0 06:48, Brian E Carpenter a =E9crit : > Hi, >=20 > This is completely revised from the proposal we presented > in Anaheim. This version allows locally defined use of > the flow label in a simpler way, as the discussion suggested. > It's still quite a dense read, but we believe that if this was > adopted, it would open the way to actually using the flow label. >=20 > Brian and Sheng >=20 > -------- Original Message -------- > Subject: New Version Notification for = draft-carpenter-6man-flow-update-02 > Date: Tue, 13 Apr 2010 21:44:42 -0700 (PDT) > From: IETF I-D Submission Tool > To: brian.e.carpenter@gmail.com > CC: shengjiang@huawei.com >=20 >=20 > A new version of I-D, draft-carpenter-6man-flow-update-02.txt has been = successfully submitted by Brian Carpenter and posted to > the IETF repository. >=20 > Filename: draft-carpenter-6man-flow-update > Revision: 02 > Title: Update to the IPv6 flow label specification > Creation_date: 2010-04-13 > WG ID: Independent Submission > Number_of_pages: 10 >=20 > Abstract: > Various uses proposed for the IPv6 flow label are incompatible with > its existing specification. This document describes changes to the > specification that permit additional use cases as well as allowing > continued use of the previous specification. >=20 >=20 >=20 > The IETF Secretariat. >=20 >=20 >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From alexandru.petrescu@gmail.com Wed Apr 14 10:22:30 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 0D0F13A6AE1 for ; Wed, 14 Apr 2010 10:22:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.798 X-Spam-Level: X-Spam-Status: No, score=-1.798 tagged_above=-999 required=5 tests=[AWL=0.451, BAYES_00=-2.599, HELO_EQ_FR=0.35] 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 vL98iniqSfRr for ; Wed, 14 Apr 2010 10:22:28 -0700 (PDT) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.166.172.107]) by core3.amsl.com (Postfix) with ESMTP id C67863A6A56 for ; Wed, 14 Apr 2010 10:21:13 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.0) with ESMTP id o3EHL6rW002940 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Wed, 14 Apr 2010 19:21:06 +0200 Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id o3EHL6Yg008192 for ; Wed, 14 Apr 2010 19:21:06 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.133.173]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id o3EHL6lA004704 for ; Wed, 14 Apr 2010 19:21:06 +0200 Message-ID: <4BC5F981.2080101@gmail.com> Date: Wed, 14 Apr 2010 19:21:05 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: ipv6@ietf.org Subject: Re: [Fwd: I-D Action:draft-carpenter-6man-flow-update-00.txt] References: <4B7CB52D.20902@gmail.com> In-Reply-To: <4B7CB52D.20902@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit 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, 14 Apr 2010 17:22:30 -0000 Hi, I came across this draft coming from the ROLL space where a proposal exists to use the Flow Label changed enroute maybe. Besides the fact that I find ROLL use of such spec of 6MAN not being ready, i.e. in its infance (I will suggest that to the ROLL WG), I have a general comment here in 6MAN. Modifying a field of an IP packet "en-route" is something which comes with a price tag: obviously slower. Generally speaking writing takes much longer than reading. I find this proposal to change the Flow Label behaviour to come in too early, at a point where we don't yet have widespread use of simple Flow Labels (or is it widely used?). I wouldn't touch on any IP field enroute... there exist already exceptions allowing to touch enroute and they're not widely used either (RH, HbH, etc.) Alex Le 18/02/2010 04:34, Brian E Carpenter a écrit : > Hi, > > This may seem a bit unexpected, but after working on > draft-carpenter-flow-ecmp (just updated) and working with my student > Qinwen Hu on some aspects of the flow label, it seemed like time for > another look at the flow label standard, and Sheng Jiang was having > similar thoughts. > > We'd like to discuss this in Anaheim if possible. > > Brian > > -------- Original Message -------- Subject: I-D > Action:draft-carpenter-6man-flow-update-00.txt Date: Wed, 17 Feb > 2010 18:15:02 -0800 (PST) From: Internet-Drafts@ietf.org Reply-To: > internet-drafts@ietf.org To: i-d-announce@ietf.org > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > Title : Update to the IPv6 flow label specification > Author(s) : B. Carpenter, S. Jiang Filename : > draft-carpenter-6man-flow-update-00.txt Pages : 9 Date : > 2010-02-17 > > Various uses proposed for the IPv6 flow label are incompatible with > its existing specification. This document describes changes to the > specification that permit additional use cases as well as allowing > continued use of the previous specification. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-carpenter-6man-flow-update-00.txt > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list ipv6@ietf.org Administrative > Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > From alexandru.petrescu@gmail.com Wed Apr 14 10:41:55 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 AF84B28C17B for ; Wed, 14 Apr 2010 10:41:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.88 X-Spam-Level: X-Spam-Status: No, score=-1.88 tagged_above=-999 required=5 tests=[AWL=0.369, BAYES_00=-2.599, HELO_EQ_FR=0.35] 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 tBsTAXTS11GY for ; Wed, 14 Apr 2010 10:41:54 -0700 (PDT) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.166.172.106]) by core3.amsl.com (Postfix) with ESMTP id 5078328C281 for ; Wed, 14 Apr 2010 10:41:18 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.0) with ESMTP id o3EHfArr021408 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 14 Apr 2010 19:41:10 +0200 Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id o3EHfAke009773; Wed, 14 Apr 2010 19:41:10 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.133.173]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id o3EHf9W7008115; Wed, 14 Apr 2010 19:41:10 +0200 Message-ID: <4BC5FE35.4070508@gmail.com> Date: Wed, 14 Apr 2010 19:41:09 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: ipv6@ietf.org Subject: Re: IPv6 Flows, Mobile IPv6 Flows, ROLL RPL Flows (was: [Fwd: I-D Action:draft-carpenter-6man-flow-update-00.txt]) References: <4B7CB52D.20902@gmail.com> <4BC5F981.2080101@gmail.com> In-Reply-To: <4BC5F981.2080101@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit 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, 14 Apr 2010 17:41:55 -0000 I take advantage of my slot here to also talk about the fact that I believe Flow Labels and IPv6 Flows in general are little known in MEXT. For example the MEXT WG defines an "IPv6 flow" to be a "group of packets matching a traffic selector", different than the rfc3697 idea of "3-tuple of the Flow Label and the Source and Destination Address fields enables efficient IPv6 flow classification". MEXT's draft-ietf-mext-flow-binding-06 goes further and defines "A flow identifier uniquely identifies a flow binding associated with a mobile node. It is generated by a mobile node and is cached in the table of flow binding entries maintained by the MN, HA, CN or MAP.". No MEXT mentioning of "Flow Label", but the same spirit - because a flow binding is actually a pair of addresses to which one adds an 16bit (not 20) id. MEXT Mobile IPv6 using the _spirit_ of IPv6 flows (3-tuple address-address-id), and the term "flow" but _not_ the IPv6 Flow Label field was very surprising to me at the time of proposal. Now I am surprised 6MAN proposes to modify the IPv6 Flow Label - what does this mean to MEXT Mobile IPv6? Is 6MAN proposing new Flow Label behaviour in order to be better in MEXT (doesn't seem so, mutability wasn't requested in MEXT)? Or just ROLL? For whom is this Flow Label update intended? Alex Le 14/04/2010 19:21, Alexandru Petrescu a écrit : > Hi, I came across this draft coming from the ROLL space where a > proposal exists to use the Flow Label changed enroute maybe. > > Besides the fact that I find ROLL use of such spec of 6MAN not being > ready, i.e. in its infance (I will suggest that to the ROLL WG), I > have a general comment here in 6MAN. > > Modifying a field of an IP packet "en-route" is something which > comes with a price tag: obviously slower. Generally speaking writing > takes much longer than reading. > > I find this proposal to change the Flow Label behaviour to come in > too early, at a point where we don't yet have widespread use of > simple Flow Labels (or is it widely used?). > > I wouldn't touch on any IP field enroute... there exist already > exceptions allowing to touch enroute and they're not widely used > either (RH, HbH, etc.) > > Alex > > Le 18/02/2010 04:34, Brian E Carpenter a écrit : >> Hi, >> >> This may seem a bit unexpected, but after working on >> draft-carpenter-flow-ecmp (just updated) and working with my >> student Qinwen Hu on some aspects of the flow label, it seemed like >> time for another look at the flow label standard, and Sheng Jiang >> was having similar thoughts. >> >> We'd like to discuss this in Anaheim if possible. >> >> Brian >> >> -------- Original Message -------- Subject: I-D >> Action:draft-carpenter-6man-flow-update-00.txt Date: Wed, 17 Feb >> 2010 18:15:02 -0800 (PST) From: Internet-Drafts@ietf.org Reply-To: >> internet-drafts@ietf.org To: i-d-announce@ietf.org >> >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> >> Title : Update to the IPv6 flow label specification Author(s) : B. >> Carpenter, S. Jiang Filename : >> draft-carpenter-6man-flow-update-00.txt Pages : 9 Date : >> 2010-02-17 >> >> Various uses proposed for the IPv6 flow label are incompatible >> with its existing specification. This document describes changes to >> the specification that permit additional use cases as well as >> allowing continued use of the previous specification. >> >> A URL for this Internet-Draft is: >> > http://www.ietf.org/internet-drafts/draft-carpenter-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 pal@cs.stanford.edu Wed Apr 14 13:25:22 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 1AB9F3A6A79 for ; Wed, 14 Apr 2010 13:25:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.496 X-Spam-Level: X-Spam-Status: No, score=-6.496 tagged_above=-999 required=5 tests=[AWL=0.103, 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 XHZ-xrz3KZco for ; Wed, 14 Apr 2010 13:25:21 -0700 (PDT) Received: from cs-smtp-2.Stanford.EDU (cs-smtp-2.Stanford.EDU [171.64.64.26]) by core3.amsl.com (Postfix) with ESMTP id 1825B3A6A8E for ; Wed, 14 Apr 2010 13:23:13 -0700 (PDT) Received: from dnab40461a.stanford.edu ([171.64.70.26]) by cs-smtp-2.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1O2973-0005fX-Lk; Wed, 14 Apr 2010 13:23:07 -0700 Subject: Re: [Fwd: I-D Action:draft-carpenter-6man-flow-update-00.txt] Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii From: Philip Levis In-Reply-To: <4BC5F981.2080101@gmail.com> Date: Wed, 14 Apr 2010 13:23:05 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4B7CB52D.20902@gmail.com> <4BC5F981.2080101@gmail.com> To: Alexandru Petrescu X-Mailer: Apple Mail (2.1078) X-Scan-Signature: a1ccd6d2fa83ef575f7b7817ead66a1e 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, 14 Apr 2010 20:25:22 -0000 On Apr 14, 2010, at 10:21 AM, Alexandru Petrescu wrote: > Hi, I came across this draft coming from the ROLL space where a = proposal > exists to use the Flow Label changed enroute maybe. Alex, I think you're misrepresenting ROLL here, even though (after your = objections there) the use of the flow label was very clearly described a = few days ago. Changing the flow label enroute is not on the table in = ROLL; it was a while ago as a crazy idea, then everyone realized the = issues it would create.=20 Phil= From brian.e.carpenter@gmail.com Wed Apr 14 14:39:45 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 704F93A6823 for ; Wed, 14 Apr 2010 14:39:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.222 X-Spam-Level: X-Spam-Status: No, score=-2.222 tagged_above=-999 required=5 tests=[AWL=0.377, 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 P6c3Gu20P7uI for ; Wed, 14 Apr 2010 14:39:44 -0700 (PDT) Received: from mail-pv0-f172.google.com (mail-pv0-f172.google.com [74.125.83.172]) by core3.amsl.com (Postfix) with ESMTP id BA6293A67F4 for ; Wed, 14 Apr 2010 14:39:42 -0700 (PDT) Received: by pvf33 with SMTP id 33so432405pvf.31 for ; Wed, 14 Apr 2010 14:39:34 -0700 (PDT) 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=kld/zJghc+Vs3cfmK8HDL53D5xv1/uYAzV5EZOtVAH0=; b=ABtTQtmBvzwUS1EpVRjZ1vlPm5YC07IFo8cY33pmXkAHEKLQlQBuAGl5Q1GfKECCpW INFg16f0k5GXxRNs0TjrX3Emh+mwPz8l/MwV9izbws2np9KvU2Kyww1jR+uiszZ3adgn Sq7//K3dBp/aEl7dgrwf8xO+rsDqBdvDug/DQ= 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=XbxHHSzcmyy0j2Pypw7qt9Ih7UNEmiJUqp2FxauG77Hw3NBPefwm1jTCgIctpJlwU6 LWUIK3yu4mU4VXISu2YzUxAr6C9LnMYwNG+7EQo11aXY9PzkaDklFYNzIckAus0NPVm+ v3Q/xazffFn6m24XbYEsVD5sEMQTPjxJ801kM= Received: by 10.142.152.34 with SMTP id z34mr3506046wfd.176.1271281174078; Wed, 14 Apr 2010 14:39:34 -0700 (PDT) Received: from [130.216.38.124] (stf-brian.sfac.auckland.ac.nz [130.216.38.124]) by mx.google.com with ESMTPS id 20sm642644pzk.7.2010.04.14.14.39.31 (version=SSLv3 cipher=RC4-MD5); Wed, 14 Apr 2010 14:39:32 -0700 (PDT) Message-ID: <4BC6360D.2000400@gmail.com> Date: Thu, 15 Apr 2010 09:39:25 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Parav Pandit Subject: Re: which interface to choose to send to destination link-local address - any RFC? References: <148247.37026.qm@web30108.mail.mud.yahoo.com> In-Reply-To: <148247.37026.qm@web30108.mail.mud.yahoo.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: Wed, 14 Apr 2010 21:39:45 -0000 I think this topic belongs to the MIF WG. Maybe they have already discussed it. If not, they probably should. http://datatracker.ietf.org/wg/mif/charter/ Brian On 2010-04-14 21:00, Parav Pandit wrote: > Hi, > > In IPv6 stack implementation, > > How IPv6 stack should select the outgoing interface to choose (when multiple interfaces) are available? Typically when the destination is the link-local address which may be on-link on both the interfaces (before the neighbor discovery) is done? > > Should IPv6 stack do Neighbor discovery on all multiple interfaces in the host? > > Which RFC defines this behavior? I referred RFC 3484 (Default Address Selection for IPv6) but doesn't seem to define this. > > I hope I am asking on the right mailing list. If not please divert me to the correct one. > > Regards, > Parav Pandit > > > > > > > > ------------------------------------------------------------------------ > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From brian.e.carpenter@gmail.com Wed Apr 14 14:45:56 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 0FEB83A6A6B for ; Wed, 14 Apr 2010 14:45:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.259 X-Spam-Level: X-Spam-Status: No, score=-2.259 tagged_above=-999 required=5 tests=[AWL=0.340, 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 lwBFwncRnrhK for ; Wed, 14 Apr 2010 14:45:55 -0700 (PDT) Received: from mail-pv0-f172.google.com (mail-pv0-f172.google.com [74.125.83.172]) by core3.amsl.com (Postfix) with ESMTP id 07F833A6812 for ; Wed, 14 Apr 2010 14:45:54 -0700 (PDT) Received: by pvf33 with SMTP id 33so435867pvf.31 for ; Wed, 14 Apr 2010 14:45:45 -0700 (PDT) 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=5hlN4ofjdv/SfQF97oZmP51NZWG7oTTIljdjQRgRVHg=; b=HiBp0w+/Aff43vZZK+kWljATQvH0YrtkQgXZXpfb7Shj+nWi6Ad48bxzTx8BWCRMB9 Joek3HRlqUV04RwSnL3aymZN14uYRzIjtKIsrpBlpdUQQssRte4bkuRoZ93VGMf016I8 +bI9yrMYI9XjlEKzaXvIjEWnOT/OpVD2DiuyY= 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=N9luyx9S5pFXeGbt72Z/gzfSORxoDrDKuCOFoceu9zV8atbmrqlOAKze6eDivJYb2j PNRh8cIFY/Be3TZlgNod8iaSq3zaUgyiGVWtclC14m2CWEs91NIuvWmIX0PKRsxtSaBh lMCFg0YtC5T7mqs0cveJEt6J4LeB/2x4m5rSc= Received: by 10.114.251.5 with SMTP id y5mr2214459wah.94.1271281545586; Wed, 14 Apr 2010 14:45:45 -0700 (PDT) Received: from [130.216.38.124] (stf-brian.sfac.auckland.ac.nz [130.216.38.124]) by mx.google.com with ESMTPS id 21sm646960pzk.8.2010.04.14.14.45.31 (version=SSLv3 cipher=RC4-MD5); Wed, 14 Apr 2010 14:45:32 -0700 (PDT) Message-ID: <4BC6377A.5050507@gmail.com> Date: Thu, 15 Apr 2010 09:45:30 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Alexandru Petrescu Subject: Re: IPv6 Flows, Mobile IPv6 Flows, ROLL RPL Flows References: <4B7CB52D.20902@gmail.com> <4BC5F981.2080101@gmail.com> <4BC5FE35.4070508@gmail.com> In-Reply-To: <4BC5FE35.4070508@gmail.com> Content-Type: text/plain; charset=UTF-8 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: Wed, 14 Apr 2010 21:45:56 -0000 > For whom is this Flow Label update intended?=20 1. For all the people who have proposed use cases that are incompatible with RFC 3697. This is briefly discussed in the draft, and I plan another draft with more details about that. 2. To "unlock" the uses cases already proposed that are compatible with RFC 3697 (draft-blake-ipv6-flow-label-nonce, ECMP, and LAG). I haven't tracked MEXT at all. If they want to place requirements on the flow label, now would be a good time for them to tell 6man. Regards Brian On 2010-04-15 05:41, Alexandru Petrescu wrote: > I take advantage of my slot here to also talk about the fact that I > believe Flow Labels and IPv6 Flows in general are little known in MEXT.= >=20 > For example the MEXT WG defines an "IPv6 flow" to be a "group of packet= s > matching a traffic selector", different than the rfc3697 idea of > "3-tuple of the Flow Label and the Source and Destination Address field= s > enables efficient IPv6 flow classification". >=20 > MEXT's draft-ietf-mext-flow-binding-06 goes further and defines "A flow= > identifier uniquely identifies a flow binding associated with a mobile > node. It is generated by a mobile node and is cached in the table of > flow binding entries maintained by the MN, HA, CN or MAP.". >=20 > No MEXT mentioning of "Flow Label", but the same spirit - because a flo= w > binding is actually a pair of addresses to which one adds an 16bit (not= > 20) id. >=20 > MEXT Mobile IPv6 using the _spirit_ of IPv6 flows (3-tuple > address-address-id), and the term "flow" but _not_ the IPv6 Flow Label > field was very surprising to me at the time of proposal. >=20 > Now I am surprised 6MAN proposes to modify the IPv6 Flow Label - what > does this mean to MEXT Mobile IPv6? Is 6MAN proposing new Flow Label > behaviour in order to be better in MEXT (doesn't seem so, mutability > wasn't requested in MEXT)? Or just ROLL? >=20 > For whom is this Flow Label update intended? >=20 > Alex >=20 > Le 14/04/2010 19:21, Alexandru Petrescu a =C3=A9crit : >> Hi, I came across this draft coming from the ROLL space where a >> proposal exists to use the Flow Label changed enroute maybe. >> >> Besides the fact that I find ROLL use of such spec of 6MAN not being >> ready, i.e. in its infance (I will suggest that to the ROLL WG), I >> have a general comment here in 6MAN. >> >> Modifying a field of an IP packet "en-route" is something which >> comes with a price tag: obviously slower. Generally speaking writing >> takes much longer than reading. >> >> I find this proposal to change the Flow Label behaviour to come in >> too early, at a point where we don't yet have widespread use of >> simple Flow Labels (or is it widely used?). >> >> I wouldn't touch on any IP field enroute... there exist already >> exceptions allowing to touch enroute and they're not widely used >> either (RH, HbH, etc.) >> >> Alex >> >> Le 18/02/2010 04:34, Brian E Carpenter a =C3=A9crit : >>> Hi, >>> >>> This may seem a bit unexpected, but after working on >>> draft-carpenter-flow-ecmp (just updated) and working with my >>> student Qinwen Hu on some aspects of the flow label, it seemed like >>> time for another look at the flow label standard, and Sheng Jiang >>> was having similar thoughts. >>> >>> We'd like to discuss this in Anaheim if possible. >>> >>> Brian >>> >>> -------- Original Message -------- Subject: I-D >>> Action:draft-carpenter-6man-flow-update-00.txt Date: Wed, 17 Feb >>> 2010 18:15:02 -0800 (PST) From: Internet-Drafts@ietf.org Reply-To: >>> internet-drafts@ietf.org To: i-d-announce@ietf.org >>> >>> A New Internet-Draft is available from the on-line Internet-Drafts >>> directories. >>> >>> Title : Update to the IPv6 flow label specification Author(s) : B. >>> Carpenter, S. Jiang Filename : >>> draft-carpenter-6man-flow-update-00.txt Pages : 9 Date : >>> 2010-02-17 >>> >>> Various uses proposed for the IPv6 flow label are incompatible >>> with its existing specification. This document describes changes to >>> the specification that permit additional use cases as well as >>> allowing continued use of the previous specification. >>> >>> A URL for this Internet-Draft is: >>> >> http://www.ietf.org/internet-drafts/draft-carpenter-6man-flow-update-0= 0.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 >> -------------------------------------------------------------------- >> >=20 >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- >=20 From brian.e.carpenter@gmail.com Wed Apr 14 14:51:24 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 42C3D3A677D for ; Wed, 14 Apr 2010 14:51:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.29 X-Spam-Level: X-Spam-Status: No, score=-2.29 tagged_above=-999 required=5 tests=[AWL=0.309, 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 pT+dGJj9-aGl for ; Wed, 14 Apr 2010 14:51:23 -0700 (PDT) Received: from mail-pz0-f182.google.com (mail-pz0-f182.google.com [209.85.222.182]) by core3.amsl.com (Postfix) with ESMTP id CEC0B28C115 for ; Wed, 14 Apr 2010 14:51:20 -0700 (PDT) Received: by pzk12 with SMTP id 12so659687pzk.32 for ; Wed, 14 Apr 2010 14:51:11 -0700 (PDT) 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=vNvDn2yZtnQ5zjhvlJYPLmDX60aeoYCGMEgd1TcgKB4=; b=vU/HVPH3/JKqTLT5NZG5E8MuWRgXC1pN9gAiEU4Vzs2noc3ACmCjrp+1HAAubfRIUR MvL3d2nhNalFARvkczpZRgD+Rnop92dG+0pHnGFP7D5fZ6QlMm8d25yXy8o7Oa6cbT3l rgJNaA4Z4ZHkNF20R3GJq1ZGFrt8A4/N+/OAY= 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=gq0FemCefBtZLiog+J/WjxQeg8Iv9oQ5Uxr0TFo+vn+VWLkBkMNo2XP+m8KqYy9Of3 PsSMBu/EKR1WV231TOheTXBgK7n0BFwpzRW17NloLv0Y/RBO8anfvtAI82Hkkfk4BULi cIyNdhfLsHEwT1RCJy5x9LHUAjKKW+K9z3u/s= Received: by 10.142.202.4 with SMTP id z4mr3707100wff.294.1271281871701; Wed, 14 Apr 2010 14:51:11 -0700 (PDT) Received: from [130.216.38.124] (stf-brian.sfac.auckland.ac.nz [130.216.38.124]) by mx.google.com with ESMTPS id 21sm652982pzk.4.2010.04.14.14.51.09 (version=SSLv3 cipher=RC4-MD5); Wed, 14 Apr 2010 14:51:11 -0700 (PDT) Message-ID: <4BC638CC.6020407@gmail.com> Date: Thu, 15 Apr 2010 09:51:08 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Alexandru Petrescu Subject: Re: [Fwd: I-D Action:draft-carpenter-6man-flow-update-00.txt] References: <4B7CB52D.20902@gmail.com> <4BC5F981.2080101@gmail.com> In-Reply-To: <4BC5F981.2080101@gmail.com> Content-Type: text/plain; charset=UTF-8 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: Wed, 14 Apr 2010 21:51:24 -0000 Alexandru, > I find this proposal to change the Flow Label behaviour to come in too > early, at a point where we don't yet have widespread use of simple Flow= > Labels (or is it widely used?).=20 But that's the problem. If you have read the -02 draft, you will understa= nd that flow label usage today is essentially non-existent. Usage is not goi= ng to occur unless we make it desirable - and it's quite clear that RFC 3697 di= d not succeed in making it desirable. So either we do something, or we cont= inue to carry 20 useless bits in every IPv6 packet. Please forget the -00 and -01 drafts, they were completely overtaken by the discussion at IETF77. Regards Brian On 2010-04-15 05:21, Alexandru Petrescu wrote: > Hi, I came across this draft coming from the ROLL space where a proposa= l > exists to use the Flow Label changed enroute maybe. >=20 > Besides the fact that I find ROLL use of such spec of 6MAN not being > ready, i.e. in its infance (I will suggest that to the ROLL WG), I have= > a general comment here in 6MAN. >=20 > Modifying a field of an IP packet "en-route" is something which comes > with a price tag: obviously slower. Generally speaking writing takes > much longer than reading. >=20 > I find this proposal to change the Flow Label behaviour to come in too > early, at a point where we don't yet have widespread use of simple Flow= > Labels (or is it widely used?). >=20 > I wouldn't touch on any IP field enroute... there exist already > exceptions allowing to touch enroute and they're not widely used either= > (RH, HbH, etc.) >=20 > Alex >=20 > Le 18/02/2010 04:34, Brian E Carpenter a =C3=A9crit : >> Hi, >> >> This may seem a bit unexpected, but after working on >> draft-carpenter-flow-ecmp (just updated) and working with my student >> Qinwen Hu on some aspects of the flow label, it seemed like time for >> another look at the flow label standard, and Sheng Jiang was having >> similar thoughts. >> >> We'd like to discuss this in Anaheim if possible. >> >> Brian >> >> -------- Original Message -------- Subject: I-D >> Action:draft-carpenter-6man-flow-update-00.txt Date: Wed, 17 Feb >> 2010 18:15:02 -0800 (PST) From: Internet-Drafts@ietf.org Reply-To: >> internet-drafts@ietf.org To: i-d-announce@ietf.org >> >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> >> Title : Update to the IPv6 flow label specification >> Author(s) : B. Carpenter, S. Jiang Filename : >> draft-carpenter-6man-flow-update-00.txt Pages : 9 Date : >> 2010-02-17 >> >> Various uses proposed for the IPv6 flow label are incompatible with >> its existing specification. This document describes changes to the >> specification that permit additional use cases as well as allowing >> continued use of the previous specification. >> >> A URL for this Internet-Draft is: >> > http://www.ietf.org/internet-drafts/draft-carpenter-6man-flow-update-00= =2Etxt >> >> >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list ipv6@ietf.org Administrative >> Requests: https://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- >> >=20 >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- >=20 From brian.e.carpenter@gmail.com Wed Apr 14 14:59:05 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 5466628C140 for ; Wed, 14 Apr 2010 14:59:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.166 X-Spam-Level: X-Spam-Status: No, score=-2.166 tagged_above=-999 required=5 tests=[AWL=0.133, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n2LoaHkG8gzp for ; Wed, 14 Apr 2010 14:59:04 -0700 (PDT) Received: from mail-pv0-f172.google.com (mail-pv0-f172.google.com [74.125.83.172]) by core3.amsl.com (Postfix) with ESMTP id 62CF428C12D for ; Wed, 14 Apr 2010 14:59:04 -0700 (PDT) Received: by pvf33 with SMTP id 33so442294pvf.31 for ; Wed, 14 Apr 2010 14:58:58 -0700 (PDT) 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=crLQHaZKr6TpqTvwkrvTkfgxXqXAvonXeXHpTwjqY2U=; b=sH9bZPPoQnvWC+a7COFfs9Yg6SmjwbR3QeOf1MXs+loZrSzpJMEfXziXyoXkHDeAa9 nCKcPTxHbVEYAUC53LELotQ/xI/NHgkCNvMOSOopAB7VStD0XHUvUGwz8+CbTx4tzrtO 1IvmAj9QAlpKxwGv8oCAzqSUUnTmYBdgYjGSI= 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=wGh/a4dka6yDSi5fYWc0oBO6eqOi8yaxnkbN2xZ/xfkXllxrOVhK4vqvoekhuuDbpS wc0JdLZQiOqcNvH/y5mGFBf5q3BQjxPOaPzw8zLeyI/gvassuMjVtxY7Ie9lF5c0XrZz O9mzT97fSuufTAdT2zMAa9tIiPhvZPiKBZlKo= Received: by 10.141.214.15 with SMTP id r15mr2483071rvq.266.1271282338464; Wed, 14 Apr 2010 14:58:58 -0700 (PDT) Received: from [130.216.38.124] (stf-brian.sfac.auckland.ac.nz [130.216.38.124]) by mx.google.com with ESMTPS id 21sm655259pzk.12.2010.04.14.14.58.55 (version=SSLv3 cipher=RC4-MD5); Wed, 14 Apr 2010 14:58:57 -0700 (PDT) Message-ID: <4BC63A9D.5080200@gmail.com> Date: Thu, 15 Apr 2010 09:58:53 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: =?UTF-8?B?UsOpbWkgRGVzcHLDqXM=?= Subject: Re: [Fwd: New Version Notification for draft-carpenter-6man-flow-update-02] References: <4BC54919.3000900@gmail.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 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: Wed, 14 Apr 2010 21:59:05 -0000 R=C3=A9mi, Thanks for the analysis. Indeed, the conclusion may be, assuming the WG is interested at all, that a complete refresh of RFC 3697 is better than publishing a delta. I agree that it is a bit complicated to explain, although the underlying concept is quite clear: allow local use of the flow label, but also enable global use. I also think we were too careful in RFC 3697 - if we had unambiguously recommended a pseudo-random label per flow, it might already be used for load balancing. (By the way, there will soon be an update of draft-carpenter-flow-ecmp, adding the LAG case and a second author, which I think will make the load balancing use case very clear.) Thanks Brian On 2010-04-15 04:06, R=C3=A9mi Despr=C3=A9s wrote: > Brian, Sheng, >=20 > I carefully read the draft, and read again RFC 3697 and draft-carpenter= -6man-flow-update-02. > The draft is IMHO overly hard to understand but, unless I misunderstand= its intent (which is quite possible), I appreciate what it proposes. > I do support the intent, but feel uncomfortable with how it is introduc= ed. >=20 > In my understanding: > A) The essential changes are: > A1. Flow Labels MAY be changed within the network, instead of "MUST be= delivered unchanged". > A2. Nodes that set Flow Labels MAY apply local policies, including sta= teless ones, instead of "SHOULD select new Flow Label values in a well-de= fined sequence (e.g., sequential or pseudo-random". > B) The essentials of what is kept are: > B1. Where Flow Labels are set, their values MUST be the same for packe= ts that have the same 5-tuples (or 3-tuples), and are separated by less t= han 120s.=20 > B3. For flow-based routing optimization to be possible, Flow Labels sh= ould in general be given different values for different 5-tuples (or 3-tu= ples) that share the same source-address/destination-address couples.=20 >=20 > If this makes sense, I am convinced that it would be better to propose = a clear and simple new RFC, and obsolete RFC 3697. > Trying to complement RFC 3697 with what amounts to a significant change= is in my understanding bond to be awkward. >=20 > Thoughts? >=20 > Kind regards, > RD > =20 >=20 >=20 > Le 14 avr. 2010 =C3=A0 06:48, Brian E Carpenter a =C3=A9crit : >=20 >> Hi, >> >> This is completely revised from the proposal we presented >> in Anaheim. This version allows locally defined use of >> the flow label in a simpler way, as the discussion suggested. >> It's still quite a dense read, but we believe that if this was >> adopted, it would open the way to actually using the flow label. >> >> Brian and Sheng >> >> -------- Original Message -------- >> Subject: New Version Notification for draft-carpenter-6man-flow-update= -02 >> Date: Tue, 13 Apr 2010 21:44:42 -0700 (PDT) >> From: IETF I-D Submission Tool >> To: brian.e.carpenter@gmail.com >> CC: shengjiang@huawei.com >> >> >> A new version of I-D, draft-carpenter-6man-flow-update-02.txt has been= successfully submitted by Brian Carpenter and posted to >> the IETF repository. >> >> Filename: draft-carpenter-6man-flow-update >> Revision: 02 >> Title: Update to the IPv6 flow label specification >> Creation_date: 2010-04-13 >> WG ID: Independent Submission >> Number_of_pages: 10 >> >> Abstract: >> Various uses proposed for the IPv6 flow label are incompatible with >> its existing specification. This document describes changes to the >> specification that permit additional use cases as well as allowing >> continued use of the previous specification. >> >> >> >> The IETF Secretariat. >> >> >> >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list >> ipv6@ietf.org >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- >=20 >=20 From ipng@69706e6720323030352d30312d31340a.nosense.org Wed Apr 14 14:59:55 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 1BF6F3A685A for ; Wed, 14 Apr 2010 14:59:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.516 X-Spam-Level: X-Spam-Status: No, score=-1.516 tagged_above=-999 required=5 tests=[AWL=0.379, 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 JLE5sjJeyzT7 for ; Wed, 14 Apr 2010 14:59:54 -0700 (PDT) Received: from smtp3.adam.net.au (smtp3.adam.net.au [202.136.110.249]) by core3.amsl.com (Postfix) with ESMTP id 7B38E28C14E for ; Wed, 14 Apr 2010 14:59:45 -0700 (PDT) Received: from 219-90-234-216.ip.adam.com.au ([219.90.234.216] helo=opy.nosense.org) by smtp3.adam.net.au with esmtp (Exim 4.63) (envelope-from ) id 1O2AcT-0006E8-6o; Thu, 15 Apr 2010 07:29:37 +0930 Received: from opy.nosense.org (localhost.localdomain [IPv6:::1]) by opy.nosense.org (Postfix) with ESMTP id 933504922D; Thu, 15 Apr 2010 07:29:36 +0930 (CST) Date: Thu, 15 Apr 2010 07:29:36 +0930 From: Mark Smith To: Brian E Carpenter Subject: Re: [Fwd: New Version Notification for draft-carpenter-6man-flow-update-02] Message-ID: <20100415072936.60eb08ac@opy.nosense.org> In-Reply-To: <4BC54919.3000900@gmail.com> References: <4BC54919.3000900@gmail.com> X-Mailer: Claws Mail 3.7.5 (GTK+ 2.20.0; x86_64-unknown-linux-gnu) X-Location: Lower Mitcham, South Australia, 5062 Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: 6man 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, 14 Apr 2010 21:59:55 -0000 Hi Brian and Sheng, On Wed, 14 Apr 2010 16:48:25 +1200 Brian E Carpenter wrote: > Hi, > > This is completely revised from the proposal we presented > in Anaheim. This version allows locally defined use of > the flow label in a simpler way, as the discussion suggested. > It's still quite a dense read, but we believe that if this was > adopted, it would open the way to actually using the flow label. > I've had a read through it, although not a comprehensive one, which I'll endeavour to do in the next day or so. I'm wondering about this change for a couple of reasons: -- 2. If this is done, all packets in a given flow MUST be given the same flow label value. A flow is defined in this case as all packets with the same source and destination IPv6 addresses and port numbers and the same transport protocol number, i.e., the same final Next Header value [RFC2460]. This rule constrains the definition of a flow in RFC 3697 for the specific case that a router sets the flow label. However, it does not constrain the bits of the flow label in any particular way. -- Firstly, if the IPv6 packets are fragments, the transport layer header may not be available. I think that would mean that although these packets fragments are part of a flow, they wouldn't have their flow label changed. Secondly, for IPv6 packets with a number of extension headers before the transport layer header, I think this rule could impact forwarding performance. While I'm not sure if it is that practical, however it'd be good if flow classification could be done using only fixed headers in the IPv6 packet, or a fixed portion of the fixed header bits. I suppose partly that comes down to what a 'flow' is. In some contexts, it is definitely a transport layer connection. In others, e.g. an MPLS network, I think it could be seen to be all packets that match a Forwarding Equivalence Class. If it was possible to use a FEC to set the flow label, once the packet has traversed the MPLS network, and the MPLS labels are stripped off, the flow label that was set due to the FEC would be preserved, which might be useful. Is there an opportunity to make the definition of a flow a bit more general, and then for allow for the choice of different packet classification methods to be used to define a flow, based on context e.g. transport layer connection in some contexts, MPLS FEC, QoS/Diff Serv classifiers etc. in others? Regards, Mark. > Brian and Sheng > > -------- Original Message -------- > Subject: New Version Notification for draft-carpenter-6man-flow-update-02 > Date: Tue, 13 Apr 2010 21:44:42 -0700 (PDT) > From: IETF I-D Submission Tool > To: brian.e.carpenter@gmail.com > CC: shengjiang@huawei.com > > > A new version of I-D, draft-carpenter-6man-flow-update-02.txt has been successfully submitted by Brian Carpenter and posted to > the IETF repository. > > Filename: draft-carpenter-6man-flow-update > Revision: 02 > Title: Update to the IPv6 flow label specification > Creation_date: 2010-04-13 > WG ID: Independent Submission > Number_of_pages: 10 > > Abstract: > Various uses proposed for the IPv6 flow label are incompatible with > its existing specification. This document describes changes to the > specification that permit additional use cases as well as allowing > continued use of the previous specification. > > > > The IETF Secretariat. > > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From brian.e.carpenter@gmail.com Wed Apr 14 15:13:26 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 655F63A677D for ; Wed, 14 Apr 2010 15:13:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.326 X-Spam-Level: X-Spam-Status: No, score=-2.326 tagged_above=-999 required=5 tests=[AWL=0.273, 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 BcHM-XCMUa9k for ; Wed, 14 Apr 2010 15:13:25 -0700 (PDT) Received: from mail-pv0-f172.google.com (mail-pv0-f172.google.com [74.125.83.172]) by core3.amsl.com (Postfix) with ESMTP id 62E8D3A6AB8 for ; Wed, 14 Apr 2010 15:13:18 -0700 (PDT) Received: by pvf33 with SMTP id 33so448460pvf.31 for ; Wed, 14 Apr 2010 15:13:07 -0700 (PDT) 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=9lcY1Kl9NkmFsFFTIMRhkhrq7SVDRtJ/ydWaru9QMPg=; b=q3Jph5mni51eSotBl5yO7KE7r3BaPpXWckbkdd5L5pLSzZpCXiiZsDnvc87bQ9bW6M t4DHrJFrGtgqiJ40EUjrXijeRc9UEmAZ2hP5nOpfDya3grptBJ/tARxSB14rilpXoOP6 jikNslO4D6Ma2F8eAj9LtJCwUuYyNl5X9vF5E= 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=oXgQbQOCAacrxEZDI6xyrE9zLerN+Lx5Rqza3/XstDr9kavb7EUNpWdwJ6yMtFidHZ BQ6RBJJhGjIIvzwdD3X2q6dAoZQCV8NaVWxs+hZPmR6bNrImLjgr9Jek3Q6uyOraqvfN yRJL7k5moMtSmhjlV34UmCpFlnlVFksWh3jf8= Received: by 10.142.248.6 with SMTP id v6mr3581128wfh.262.1271283187637; Wed, 14 Apr 2010 15:13:07 -0700 (PDT) Received: from [130.216.38.124] (stf-brian.sfac.auckland.ac.nz [130.216.38.124]) by mx.google.com with ESMTPS id 23sm666606pzk.2.2010.04.14.15.13.05 (version=SSLv3 cipher=RC4-MD5); Wed, 14 Apr 2010 15:13:07 -0700 (PDT) Message-ID: <4BC63DF0.6070707@gmail.com> Date: Thu, 15 Apr 2010 10:13:04 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Mark Smith Subject: Re: [Fwd: New Version Notification for draft-carpenter-6man-flow-update-02] References: <4BC54919.3000900@gmail.com> <20100415072936.60eb08ac@opy.nosense.org> In-Reply-To: <20100415072936.60eb08ac@opy.nosense.org> 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: Wed, 14 Apr 2010 22:13:26 -0000 Hi Mark, On 2010-04-15 09:59, Mark Smith wrote: > Hi Brian and Sheng, > > On Wed, 14 Apr 2010 16:48:25 +1200 > Brian E Carpenter wrote: > >> Hi, >> >> This is completely revised from the proposal we presented >> in Anaheim. This version allows locally defined use of >> the flow label in a simpler way, as the discussion suggested. >> It's still quite a dense read, but we believe that if this was >> adopted, it would open the way to actually using the flow label. >> > > I've had a read through it, although not a comprehensive one, which > I'll endeavour to do in the next day or so. > > I'm wondering about this change for a couple of reasons: > > -- > 2. If this is done, all packets in a given flow MUST be given the > same flow label value. A flow is defined in this case as all > packets with the same source and destination IPv6 addresses and > port numbers and the same transport protocol number, i.e., the > same final Next Header value [RFC2460]. This rule constrains the > definition of a flow in RFC 3697 for the specific case that a > router sets the flow label. However, it does not constrain the > bits of the flow label in any particular way. > -- > > Firstly, if the IPv6 packets are fragments, the transport layer header > may not be available. I think that would mean that although these > packets fragments are part of a flow, they wouldn't have their flow > label changed. Yes, certainly, if the router inserting the flow label is stateless. I honestly don't see a way round that and it's probably better to list it as a limitation. It probably doesn't matter - anyone who is deploying a local scheme for the flow label is presumably able to also deploy a non-fragmenting network. > > Secondly, for IPv6 packets with a number of extension headers before > the transport layer header, I think this rule could impact forwarding > performance. While I'm not sure if it is that practical, however it'd > be good if flow classification could be done using only fixed headers > in the IPv6 packet, or a fixed portion of the fixed header bits. I will send a separate message on that point. > > I suppose partly that comes down to what a 'flow' is. In some contexts, > it is definitely a transport layer connection. In others, e.g. an MPLS > network, I think it could be seen to be all packets that match a > Forwarding Equivalence Class. If it was possible to use a FEC to set > the flow label, once the packet has traversed the MPLS network, and the > MPLS labels are stripped off, the flow label that was set due to the > FEC would be preserved, which might be useful. Is there an opportunity > to make the definition of a flow a bit more general, and then for allow > for the choice of different packet classification methods to be used to > define a flow, based on context e.g. transport layer connection in some > contexts, MPLS FEC, QoS/Diff Serv classifiers etc. in others? And that's an even wider question. I'm inclined to duck it, or at least to assert that it's a much wider question than 6man can tackle. Brian > > Regards, > Mark. > > > > > > >> Brian and Sheng >> >> -------- Original Message -------- >> Subject: New Version Notification for draft-carpenter-6man-flow-update-02 >> Date: Tue, 13 Apr 2010 21:44:42 -0700 (PDT) >> From: IETF I-D Submission Tool >> To: brian.e.carpenter@gmail.com >> CC: shengjiang@huawei.com >> >> >> A new version of I-D, draft-carpenter-6man-flow-update-02.txt has been successfully submitted by Brian Carpenter and posted to >> the IETF repository. >> >> Filename: draft-carpenter-6man-flow-update >> Revision: 02 >> Title: Update to the IPv6 flow label specification >> Creation_date: 2010-04-13 >> WG ID: Independent Submission >> Number_of_pages: 10 >> >> Abstract: >> Various uses proposed for the IPv6 flow label are incompatible with >> its existing specification. This document describes changes to the >> specification that permit additional use cases as well as allowing >> continued use of the previous specification. >> >> >> >> The IETF Secretariat. >> >> >> >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list >> ipv6@ietf.org >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- > From brian.e.carpenter@gmail.com Wed Apr 14 15:26:21 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 9822C3A68EE for ; Wed, 14 Apr 2010 15:26:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.346 X-Spam-Level: X-Spam-Status: No, score=-2.346 tagged_above=-999 required=5 tests=[AWL=0.253, 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 X4MltNL97adi for ; Wed, 14 Apr 2010 15:26:20 -0700 (PDT) Received: from mail-pv0-f172.google.com (mail-pv0-f172.google.com [74.125.83.172]) by core3.amsl.com (Postfix) with ESMTP id 96D263A67F3 for ; Wed, 14 Apr 2010 15:26:20 -0700 (PDT) Received: by pvf33 with SMTP id 33so453447pvf.31 for ; Wed, 14 Apr 2010 15:26:12 -0700 (PDT) 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:content-type :content-transfer-encoding; bh=VcaVkol3XNil0FSdYDuH7hkj4PlPYEanwo/DlvWkKnY=; b=Bo34J2lf5IeAK5tAFhVc22R0tm1Nz2po5MwDdLk1i52gZfg8UPPgwTvxK8CLA4nlYM NNGQ6lbYhK3CN8/3W2EVx+2O1idWotWd4q3Ca3lIaEwgZPN46r7xsl7pI9+IMApG6aqw bZy9tfOPVPWyAzEwWfSV8o2QbeNp8FROUu/dc= 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:content-type:content-transfer-encoding; b=BsOKaORSq0//zBP1LDurSZvIMDBFNNPWX2NwAL2FLAwyDuY9ndAS2ouzkN9z4UldTP VtxkpJFa600oxlKN9ay5VdorgmjiGPb0Fk60LmZfsAevkRnmvXHjBKzW8qNizN2pKqZb yqwmY4PN68beCpz3e8FuE2dIduBFwu1oM5Oh0= Received: by 10.114.187.11 with SMTP id k11mr7902701waf.153.1271283972002; Wed, 14 Apr 2010 15:26:12 -0700 (PDT) Received: from [130.216.38.124] (stf-brian.sfac.auckland.ac.nz [130.216.38.124]) by mx.google.com with ESMTPS id 22sm675395pzk.5.2010.04.14.15.26.10 (version=SSLv3 cipher=RC4-MD5); Wed, 14 Apr 2010 15:26:11 -0700 (PDT) Message-ID: <4BC64100.303@gmail.com> Date: Thu, 15 Apr 2010 10:26:08 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: 6man Subject: Extracting the 5-tuple from IPv6 packets Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Nevil Brownlee 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, 14 Apr 2010 22:26:21 -0000 Hi, Common practice in network monitoring and in QoS technologies is to identify a flow of packets by the 5-tuple {source address, dest address, source port, dest port, protocol #}. This is relatively trivial at line speed in IPv4 since these things are at fixed locations in the header. But in IPv6, the protocol number is at the end of a linked list of "next headers." Even if the normal case is only one item in the linked list, any implementation (hardware or software) that extracts the 5-tuple has to follow the linked list to the end. As Mark Smith said in relation to draft-carpenter-6man-flow-update-02 >> Secondly, for IPv6 packets with a number of extension headers before >> the transport layer header, I think this rule could impact forwarding >> performance. While I'm not sure if it is that practical, however it'd >> be good if flow classification could be done using only fixed headers >> in the IPv6 packet, or a fixed portion of the fixed header bits. The problem is, only the protocol number is diagnostic of an individual flow. The earlier next headers are not guaranteed to be the same for all packets in a transport session, and they might be the same for packets in different transport sessions between the same two hosts. So it seems to me that we are stuck with identifying IPv6 flows by the 5-tuple, even though it means following the linked list to the end. Or we can forget about identifying individual transport flows, and identify all traffic between the same two hosts via the 4-tuple {source address, dest address, source port, dest port}. Or we can strongly recommend that all hosts set the flow label, so that we can use the 3-tuple {source address, dest address, flow label}. What do people think? -- Regards Brian Carpenter From alexandru.petrescu@gmail.com Wed Apr 14 15:34:45 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 3BEEB28C142 for ; Wed, 14 Apr 2010 15:34:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.649 X-Spam-Level: X-Spam-Status: No, score=-0.649 tagged_above=-999 required=5 tests=[AWL=0.111, BAYES_05=-1.11, HELO_EQ_FR=0.35] 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 fdSVNmbI+e1A for ; Wed, 14 Apr 2010 15:34:44 -0700 (PDT) Received: from smtp5-g21.free.fr (smtp5-g21.free.fr [212.27.42.5]) by core3.amsl.com (Postfix) with ESMTP id 2222628C117 for ; Wed, 14 Apr 2010 15:32:58 -0700 (PDT) Received: from smtp5-g21.free.fr (localhost [127.0.0.1]) by smtp5-g21.free.fr (Postfix) with ESMTP id F3D85D48002; Thu, 15 Apr 2010 00:32:48 +0200 (CEST) Received: from [127.0.0.1] (bur91-3-82-239-213-32.fbx.proxad.net [82.239.213.32]) by smtp5-g21.free.fr (Postfix) with ESMTP id CD4DCD4801F; Thu, 15 Apr 2010 00:32:45 +0200 (CEST) Message-ID: <4BC6428A.9030808@gmail.com> Date: Thu, 15 Apr 2010 00:32:42 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; fr; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: Philip Levis Subject: Re: [Fwd: I-D Action:draft-carpenter-6man-flow-update-00.txt] References: <4B7CB52D.20902@gmail.com> <4BC5F981.2080101@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Antivirus: avast! (VPS 100414-1, 14/04/2010), Outbound message X-Antivirus-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: Wed, 14 Apr 2010 22:34:45 -0000 Le 14/04/2010 22:23, Philip Levis a écrit : > > On Apr 14, 2010, at 10:21 AM, Alexandru Petrescu wrote: > >> Hi, I came across this draft coming from the ROLL space where a >> proposal exists to use the Flow Label changed enroute maybe. > > Alex, > > I think you're misrepresenting ROLL here, even though (after your > objections there) the use of the flow label was very clearly > described a few days ago. Changing the flow label enroute is not on > the table in ROLL; it was a while ago as a crazy idea, then everyone > realized the issues it would create. Sorry for misunderstanding... (only a day ago it was stated in ROLL list that changing the flow label enroute is possible as long as it is restored...) I guess I have to wait and see. Alex > > Phil From ssenthil@cisco.com Wed Apr 14 15:42:42 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 86ECD28C142 for ; Wed, 14 Apr 2010 15:42:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[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 AfBNN+NuxLYO for ; Wed, 14 Apr 2010 15:42:41 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id D9FF53A6ABF for ; Wed, 14 Apr 2010 15:42:39 -0700 (PDT) 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: AvsEAFvhxUurR7H+/2dsb2JhbACbWnGjVZoMgliCNQSDKQ X-IronPort-AV: E=Sophos;i="4.52,207,1270425600"; d="scan'208";a="183177282" Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-5.cisco.com with ESMTP; 14 Apr 2010 22:42:33 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o3EMgX3K002967; Wed, 14 Apr 2010 22:42:33 GMT Received: from xmb-sjc-236.amer.cisco.com ([128.107.191.121]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 14 Apr 2010 15:42:33 -0700 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: Extracting the 5-tuple from IPv6 packets Date: Wed, 14 Apr 2010 15:42:32 -0700 Message-ID: <85B2F271FDF6B949B3672BA5A7BB62FB09E2D213@xmb-sjc-236.amer.cisco.com> In-Reply-To: <4BC64100.303@gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Extracting the 5-tuple from IPv6 packets Thread-Index: AcrcIYJ66bQBAjsmRYC1A4NV8Pe4wwAAdpFA References: <4BC64100.303@gmail.com> From: "Senthil Sivakumar (ssenthil)" To: "Brian E Carpenter" , "6man" X-OriginalArrivalTime: 14 Apr 2010 22:42:33.0895 (UTC) FILETIME=[C618A370:01CADC23] Cc: Nevil Brownlee 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, 14 Apr 2010 22:42:42 -0000 =20 -----Original Message----- From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of Brian E Carpenter Sent: Wednesday, April 14, 2010 6:26 PM To: 6man Cc: Nevil Brownlee Subject: Extracting the 5-tuple from IPv6 packets Hi, Common practice in network monitoring and in QoS technologies is to identify a flow of packets by the 5-tuple {source address, dest address, source port, dest port, protocol #}. This is relatively trivial at line speed in IPv4 since these things are at fixed locations in the header. But in IPv6, the protocol number is at the end of a linked list of "next headers." Even if the normal case is only one item in the linked list, any implementation (hardware or software) that extracts the 5-tuple has to follow the linked list to the end. As Mark Smith said in relation to draft-carpenter-6man-flow-update-02 >> Secondly, for IPv6 packets with a number of extension headers before=20 >> the transport layer header, I think this rule could impact forwarding >> performance. While I'm not sure if it is that practical, however it'd >> be good if flow classification could be done using only fixed headers >> in the IPv6 packet, or a fixed portion of the fixed header bits. The problem is, only the protocol number is diagnostic of an individual flow. The earlier next headers are not guaranteed to be the same for all packets in a transport session, and they might be the same for packets in different transport sessions between the same two hosts. So it seems to me that we are stuck with identifying IPv6 flows by the 5-tuple, even though it means following the linked list to the end. Or we can forget about identifying individual transport flows, and identify all traffic between the same two hosts via the 4-tuple {source address, dest address, source port, dest port}. [Senthil] In order to get to the port numbers you would still have to traverse the extension headers and in the process you would identify the protocol too, isnt that right? Or we can strongly recommend that all hosts set the flow label, so that we can use the 3-tuple {source address, dest address, flow label}. [Senthil] That would be very useful if we can achieve that. Senthil What do people think? -- Regards Brian Carpenter -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From vishwas.ietf@gmail.com Wed Apr 14 16:03:21 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 3C72C28C12D for ; Wed, 14 Apr 2010 16:03:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.798 X-Spam-Level: X-Spam-Status: No, score=-1.798 tagged_above=-999 required=5 tests=[AWL=0.801, 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 diKhc6ljkIwE for ; Wed, 14 Apr 2010 16:03:19 -0700 (PDT) Received: from mail-gx0-f214.google.com (mail-gx0-f214.google.com [209.85.217.214]) by core3.amsl.com (Postfix) with ESMTP id 92D633A6AB2 for ; Wed, 14 Apr 2010 16:03:19 -0700 (PDT) Received: by gxk6 with SMTP id 6so360023gxk.14 for ; Wed, 14 Apr 2010 16:03:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:received:message-id:subject:from:to:cc:content-type; bh=/AiYcn8SbR/cxWSpa90HOiILNaDaMFiK0k7+G5S+h0M=; b=aaHdh+XaHpgIpirpGDGFpD6t0d+QLdLzYhNhYmKKpj1hjXxoiHR/0zEObjlvk9GjnM /NokWQwLFTH4y/TWiB+EGEgBSdf2WLR1AGpGF4bLCx2l2RUiqFIgN6o2aeJydldq4XlY Rmk3VM96/1xlvag/h63su1BD3Ly4rpRGdp6D4= 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=PcqCsBR9kQ3okub4ajZq/fgLAs8P7J4Pbt0nMuu6/BVD4SCD103UveWJ1DZqW8uGOW GQHp0b3Q9YxfabK/YJvLyv+sWKKXWz/rsI4qdov7sL0YLyYUxG80ApOYBKniYNzl5ubx wOQPP/O2sxEG/iXPgZtaWYpFb82N7TpkaLJ2Y= MIME-Version: 1.0 Received: by 10.151.46.14 with HTTP; Wed, 14 Apr 2010 16:03:10 -0700 (PDT) In-Reply-To: <4BC64100.303@gmail.com> References: <4BC64100.303@gmail.com> Date: Wed, 14 Apr 2010 16:03:10 -0700 Received: by 10.150.247.3 with SMTP id u3mr7846189ybh.41.1271286190705; Wed, 14 Apr 2010 16:03:10 -0700 (PDT) Message-ID: Subject: Re: Extracting the 5-tuple from IPv6 packets From: Vishwas Manral To: Brian E Carpenter Content-Type: text/plain; charset=ISO-8859-1 Cc: Nevil Brownlee , 6man X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Apr 2010 23:03:21 -0000 Hi Brian, > Or we can strongly recommend that all hosts set the flow label, so > that we can use the 3-tuple {source address, dest address, flow label}. Using a 3-tuple helps in stateless firewalls/ middle boxes/ ECMP, which cannot/ do-not reassemble all fragments. The 5-tuple is not available for fragments. Similarly IPsec has similar issues when selectors are 5-tuples, that is why there are special cases for how fragments are to be handled. We had a discussion on this in 2006: http://www.ops.ietf.org/lists/v6ops/v6ops.2006/threads.html#00045 Thanks, Vishwas > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > From brian.e.carpenter@gmail.com Wed Apr 14 16:11:29 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 A25AD3A6B0A for ; Wed, 14 Apr 2010 16:11:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.311 X-Spam-Level: X-Spam-Status: No, score=-2.311 tagged_above=-999 required=5 tests=[AWL=0.288, 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 4D8duBoLka0t for ; Wed, 14 Apr 2010 16:11:28 -0700 (PDT) Received: from mail-pz0-f182.google.com (mail-pz0-f182.google.com [209.85.222.182]) by core3.amsl.com (Postfix) with ESMTP id E03E13A679F for ; Wed, 14 Apr 2010 16:11:27 -0700 (PDT) Received: by pzk12 with SMTP id 12so704269pzk.32 for ; Wed, 14 Apr 2010 16:11:18 -0700 (PDT) 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=3RO+waXssTQLYAkePi8DAWIsaK1oMUI+2aBAk1BGvS0=; b=u/8RfaS37xZ7LPdrs0s0K3Xq08NBZ0HBREJJiFzTC/7chGIzAkoHS1HU8LkUoNTMeX SeNPXPNRHYO6RMjqlmTQLoHBK9osdp6/25KvJQDZlMKc08mxBZ29U9FlexZW+U/S+hS5 glWqcukcQ8L5RDasxrYHnPfT5b+0BS1kCq7Pw= 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=S45+Iwe5y3Mencdmvln7EAWDr5MSJRqXnb8KZRmCuAutRofNUF2ZZLJJ2ImauDYGa+ oDH6awU766quUeH694Bm6LVAg8cxsvkzGfRMLt78pEpbHfrcyqDpmEup6/0BHQolBVUj vL2DnEO76Xch3RA1Uc71pr8a3qXVb38HIhMMY= Received: by 10.115.66.33 with SMTP id t33mr7718604wak.199.1271286678757; Wed, 14 Apr 2010 16:11:18 -0700 (PDT) Received: from [130.216.38.124] (stf-brian.sfac.auckland.ac.nz [130.216.38.124]) by mx.google.com with ESMTPS id 23sm702053pzk.10.2010.04.14.16.11.16 (version=SSLv3 cipher=RC4-MD5); Wed, 14 Apr 2010 16:11:18 -0700 (PDT) Message-ID: <4BC64B93.4010205@gmail.com> Date: Thu, 15 Apr 2010 11:11:15 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: "Senthil Sivakumar (ssenthil)" Subject: Re: Extracting the 5-tuple from IPv6 packets References: <4BC64100.303@gmail.com> <85B2F271FDF6B949B3672BA5A7BB62FB09E2D213@xmb-sjc-236.amer.cisco.com> In-Reply-To: <85B2F271FDF6B949B3672BA5A7BB62FB09E2D213@xmb-sjc-236.amer.cisco.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Nevil Brownlee , 6man X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Apr 2010 23:11:29 -0000 > [Senthil] In order to get to the port numbers you would still have to > traverse the extension headers and in the process you would identify the > protocol too, isnt that right? Oh my yes! How embarassing, but it makes the problem even worse. Regards Brian Carpenter On 2010-04-15 10:42, Senthil Sivakumar (ssenthil) wrote: > > > -----Original Message----- > From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of > Brian E Carpenter > Sent: Wednesday, April 14, 2010 6:26 PM > To: 6man > Cc: Nevil Brownlee > Subject: Extracting the 5-tuple from IPv6 packets > > Hi, > > Common practice in network monitoring and in QoS technologies is to > identify a flow of packets by the 5-tuple {source address, dest address, > source port, dest port, protocol #}. > This is relatively trivial at line speed in IPv4 since these things are > at fixed locations in the header. But in IPv6, the protocol number is at > the end of a linked list of "next headers." Even if the normal case is > only one item in the linked list, any implementation (hardware or > software) that extracts the 5-tuple has to follow the linked list to the > end. > > As Mark Smith said in relation to draft-carpenter-6man-flow-update-02 > >>> Secondly, for IPv6 packets with a number of extension headers before >>> the transport layer header, I think this rule could impact forwarding > >>> performance. While I'm not sure if it is that practical, however it'd > >>> be good if flow classification could be done using only fixed headers > >>> in the IPv6 packet, or a fixed portion of the fixed header bits. > > The problem is, only the protocol number is diagnostic of an individual > flow. The earlier next headers are not guaranteed to be the same for all > packets in a transport session, and they might be the same for packets > in different transport sessions between the same two hosts. > > So it seems to me that we are stuck with identifying IPv6 flows by the > 5-tuple, even though it means following the linked list to the end. Or > we can forget about identifying individual transport flows, and identify > all traffic between the same two hosts via the 4-tuple {source address, > dest address, source port, dest port}. > > [Senthil] In order to get to the port numbers you would still have to > traverse the extension headers and in the process you would identify the > protocol too, isnt that right? > > Or we can strongly recommend that all hosts set the flow label, so that > we can use the 3-tuple {source address, dest address, flow label}. > > [Senthil] That would be very useful if we can achieve that. > > Senthil > > What do people think? > > -- > Regards > Brian Carpenter > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > From bob.hinden@gmail.com Wed Apr 14 16:16:58 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 3EFF53A68AC for ; Wed, 14 Apr 2010 16:16:58 -0700 (PDT) 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 RXPuLc-O7imW for ; Wed, 14 Apr 2010 16:16:57 -0700 (PDT) Received: from mail-qy0-f171.google.com (mail-qy0-f171.google.com [209.85.221.171]) by core3.amsl.com (Postfix) with ESMTP id 9A0993A693E for ; Wed, 14 Apr 2010 16:16:56 -0700 (PDT) Received: by qyk1 with SMTP id 1so797521qyk.15 for ; Wed, 14 Apr 2010 16:16:47 -0700 (PDT) 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=HNHg9tEJGliE4Wc14tez78l2H5ncRrHVzeT+TCFWU60=; b=SIoOpPSbwsYpEK46OoXBNUh00hLeNDviz16gqFmp0frmr8pk2AlrOIptpeNky9QTTZ 6pkFAIqcabn8+odYnhqOR6ij3EMZ/kQm6Z+9bJFmtJe6+AfG6d2QLIhlWUZe4fCuI755 04xyqQElILEHYKPvE1aU1PLqOlGfbZwTeifUQ= 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=HLGFvDbMdetqLzRsWbqGfJWqPT+JniCSYn7Lxzyklt95PN2CZyvJ4+85+GVC2nxTbN sZlcto8nJkGBPa2QBrs9Au8twQ4Zif1vaxBng5OYgJKBpW3E9GKYm8IJEx+MHsnSLbZ+ QmOChp0iTEauxrU3bFMw3PM6M4Njfzv/UuopE= Received: by 10.229.190.209 with SMTP id dj17mr11379675qcb.52.1271287007568; Wed, 14 Apr 2010 16:16:47 -0700 (PDT) Received: from dhcp-209.97.124.227.us.checkpoint.com ([209.97.124.227]) by mx.google.com with ESMTPS id v26sm1000429qce.1.2010.04.14.16.16.45 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 14 Apr 2010 16:16:46 -0700 (PDT) Subject: Re: Extracting the 5-tuple from IPv6 packets Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii From: Bob Hinden In-Reply-To: <4BC64100.303@gmail.com> Date: Wed, 14 Apr 2010 16:16:44 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <21A9EECC-0987-4B3A-9A8C-D17F3037D819@gmail.com> References: <4BC64100.303@gmail.com> To: Brian E Carpenter X-Mailer: Apple Mail (2.1078) Cc: Nevil Brownlee , 6man X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Apr 2010 23:16:58 -0000 Brian, On Apr 14, 2010, at 3:26 PM, Brian E Carpenter wrote: > Hi, >=20 > Common practice in network monitoring and in QoS technologies > is to identify a flow of packets by the 5-tuple > {source address, dest address, source port, dest port, protocol #}. > This is relatively trivial at line speed in IPv4 since > these things are at fixed locations in the header. But in IPv6, > the protocol number is at the end of a linked list of "next > headers." Even if the normal case is only one item in the linked > list, any implementation (hardware or software) that extracts > the 5-tuple has to follow the linked list to the end. Do we have any data on what percentage of packets have the next header a = transport header vs. something else? It would be good to know how often = it's the non-trivial case. I agree that an implementation will have to know how to at least check = what the next header is. =20 >=20 > As Mark Smith said in relation to draft-carpenter-6man-flow-update-02 >=20 >>> Secondly, for IPv6 packets with a number of extension headers before >>> the transport layer header, I think this rule could impact = forwarding >>> performance. While I'm not sure if it is that practical, however = it'd >>> be good if flow classification could be done using only fixed = headers >>> in the IPv6 packet, or a fixed portion of the fixed header bits. >=20 > The problem is, only the protocol number is diagnostic of an = individual > flow. The earlier next headers are not guaranteed to be the same for > all packets in a transport session, and they might be the same for = packets > in different transport sessions between the same two hosts. >=20 > So it seems to me that we are stuck with identifying IPv6 flows by > the 5-tuple, even though it means following the linked list to the > end. Or we can forget about identifying individual transport flows, > and identify all traffic between the same two hosts via the 4-tuple > {source address, dest address, source port, dest port}. >=20 > Or we can strongly recommend that all hosts set the flow label, so > that we can use the 3-tuple {source address, dest address, flow = label}. >=20 > What do people think? That would make a lot of sense to me. It would also have an advantage = of allowing a set of TCP connections between two hosts to be associated = as a single flow where the hosts wanted them to be treated in the same = manner. It's hard to do that with IPv4 as the port numbers will be = different for each TCP connection. Bob From behcetsarikaya@yahoo.com Wed Apr 14 16:23:39 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 C1E4B3A6ABF for ; Wed, 14 Apr 2010 16:23:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.058 X-Spam-Level: X-Spam-Status: No, score=-1.058 tagged_above=-999 required=5 tests=[AWL=1.207, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] 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 DbLeGH7HVdK8 for ; Wed, 14 Apr 2010 16:23:37 -0700 (PDT) Received: from web111413.mail.gq1.yahoo.com (web111413.mail.gq1.yahoo.com [67.195.15.204]) by core3.amsl.com (Postfix) with SMTP id 279FA28C140 for ; Wed, 14 Apr 2010 16:22:44 -0700 (PDT) Received: (qmail 25146 invoked by uid 60001); 14 Apr 2010 23:22:35 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1271287355; bh=2CaOiTgfu8jKBmXHM9MpHFK4Ig0iKLVDEp2/YmACzDw=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=ip/pdDBnrYQLyhX8F2aT68qjeMp8stPxpBmM1zXGrJ/LEHotqQd3tkaOe71kxwerO+sCeiOgs1mi4WJb1SMnTIECvt+16MIClhBHPLcuCEwTXxm7PsVdBHvs1MR1XCMXiPthrGkHbVWFSKxueF8bHvNJ6R6A5dUPptGZmZIU06A= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=1CXl2MX4lS0rS7ouq179HNivtK9CMDNiayCn1Xpg/gGeDWTsbmSi78j5osvlo+aSS6AqzrgkOgy04TR0eoqsj9tCSFjLbyqWRr19+aHetjX2q9pMQTwmXjPrzizjQLEhUUgENdJRdi+yTnwEJ/5LidGr6z21BRMvF1frPZuWu/k=; Message-ID: <630839.24373.qm@web111413.mail.gq1.yahoo.com> X-YMail-OSG: kXm_N0UVM1m7IUxGizO.yZZzixUJZnnLr8FRSl7TCdtW3tY xE7GDHyDRmdxq1nCHOQnkl5aQVRgDDKUh3xrKJK.zanLjYEA_8BWbHq3lq0x 5upS.CcKhvytH2bWKW6b.BepGPWCVMLEY4LQglgd4rVGorV28tpwPWH70iKh KvR5YjEgffAS.1zyt1tuRxyW5QKs6MFHliAqT1Mw5ozltwlB154dIHsMTdSk X1pG8aCvGFKBY5d7iWp85m1zl2D5nyVKdzLnO_HqqpgDocsqxEyEYJUCTvgL s2m9IPRfTjDIwQBtlk81R93vLnKTry4HNy82.Pb4QU4AKmhTMTApQiEaipy5 Asa_Fg7eLXwbX Received: from [206.16.17.212] by web111413.mail.gq1.yahoo.com via HTTP; Wed, 14 Apr 2010 16:22:35 PDT X-Mailer: YahooMailRC/348.5 YahooMailWebService/0.8.100.260964 References: <4B7CB52D.20902@gmail.com> <4BC5F981.2080101@gmail.com> <4BC5FE35.4070508@gmail.com> <4BC6377A.5050507@gmail.com> Date: Wed, 14 Apr 2010 16:22:35 -0700 (PDT) From: Behcet Sarikaya Subject: Re: IPv6 Flows, Mobile IPv6 Flows, ROLL RPL Flows To: Brian E Carpenter , Alexandru Petrescu In-Reply-To: <4BC6377A.5050507@gmail.com> MIME-Version: 1.0 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 Reply-To: Behcet Sarikaya List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Apr 2010 23:23:39 -0000 Using RFC 3697 instead of Traffic Selectors (draft-ietf-mext-binary-ts)=A0h= as been discussed in MEXT, here is a pointer:=0Ahttp://www.ietf.org/mail-ar= chive/web/mext/current/msg03327.html=0A=0AI don't think MEXT opted for that= kind of use, they want more generic flow description.=0A=0ABR,=0A=0ABehcet= =0A=0A=0A----- Original Message ----=0A> From: Brian E Carpenter =0A> To: Alexandru Petrescu =0A> Cc: ipv6@ietf.org=0A> Sent: Wed, April 14, 2010 4:45:30 PM=0A> Subje= ct: Re: IPv6 Flows, Mobile IPv6 Flows, ROLL RPL Flows=0A> =0A> > For whom i= s this Flow Label update intended? =0A=0A1. For all the people =0A> who hav= e proposed use cases that are incompatible=0Awith RFC 3697. This is =0A> br= iefly discussed in the draft, and I plan=0Aanother draft with more details = =0A> about that.=0A=0A2. To "unlock" the uses cases already proposed that a= re =0A> compatible with=0ARFC 3697 (draft-blake-ipv6-flow-label-nonce, ECMP= , and =0A> LAG).=0A=0AI haven't tracked MEXT at all. If they want to place = =0A> requirements=0Aon the flow label, now would be a good time for them to= tell =0A> 6man.=0A=0ARegards=0A=A0 Brian=0A=0AOn 2010-04-15 05:41, Alexand= ru =0A> Petrescu wrote:=0A> I take advantage of my slot here to also talk a= bout the =0A> fact that I=0A> believe Flow Labels and IPv6 Flows in general= are little =0A> known in MEXT.=0A> =0A> For example the MEXT WG defines an= "IPv6 flow" =0A> to be a "group of packets=0A> matching a traffic selector= ", different than =0A> the rfc3697 idea of=0A> "3-tuple of the Flow Label a= nd the Source and =0A> Destination Address fields=0A> enables efficient IPv= 6 flow =0A> classification".=0A> =0A> MEXT's draft-ietf-mext-flow-binding-0= 6 goes =0A> further and defines "A flow=0A> identifier uniquely identifies = a flow =0A> binding associated with a mobile=0A> node.=A0 It is generated b= y a mobile =0A> node and is cached in the table of=0A> flow binding entries= maintained by =0A> the MN, HA, CN or MAP.".=0A> =0A> No MEXT mentioning of= "Flow Label", =0A> but the same spirit - because a flow=0A> binding is act= ually a pair of =0A> addresses to which one adds an 16bit (not=0A> 20) id.= =0A> =0A> MEXT =0A> Mobile IPv6 using the _spirit_ of IPv6 flows (3-tuple= =0A> =0A> address-address-id), and the term "flow" but _not_ the IPv6 Flow = Label=0A> =0A> field was very surprising to me at the time of proposal.=0A>= =0A> Now I =0A> am surprised 6MAN proposes to modify the IPv6 Flow Label -= what=0A> does =0A> this mean to MEXT Mobile IPv6?=A0 Is 6MAN proposing new= Flow Label=0A> =0A> behaviour in order to be better in MEXT (doesn't seem = so, mutability=0A> =0A> wasn't requested in MEXT)?=A0 Or just ROLL?=0A> =0A= > For whom is this =0A> Flow Label update intended?=0A> =0A> Alex=0A> =0A> = Le 14/04/2010 =0A> 19:21, Alexandru Petrescu a =E9crit :=0A>> Hi, I came ac= ross this draft =0A> coming from the ROLL space where a=0A>> proposal exist= s to use the Flow =0A> Label changed enroute maybe.=0A>>=0A>> Besides the f= act that I =0A> find ROLL use of such spec of 6MAN not being=0A>> ready, i.= e. in its =0A> infance (I will suggest that to the ROLL WG), I=0A>> have a = general =0A> comment here in 6MAN.=0A>>=0A>> Modifying a field of an IP pac= ket =0A> "en-route" is something which=0A>> comes with a price tag: obvious= ly =0A> slower. Generally speaking writing=0A>> takes much longer than =0A>= reading.=0A>>=0A>> I find this proposal to change the Flow Label =0A> beha= viour to come in=0A>> too early, at a point where we don't yet have =0A> wi= despread use of=0A>> simple Flow Labels (or is it widely =0A> used?).=0A>>= =0A>> I wouldn't touch on any IP field enroute... =0A> there exist already= =0A>> exceptions allowing to touch enroute and they're =0A> not widely used= =0A>> either (RH, HbH, etc.)=0A>>=0A>> =0A> Alex=0A>>=0A>> Le 18/02/2010 04= :34, Brian E Carpenter a =E9crit =0A> :=0A>>> Hi,=0A>>>=0A>>> This may seem= a bit =0A> unexpected, but after working on=0A>>> draft-carpenter-flow-ecm= p (just =0A> updated) and working with my=0A>>> student Qinwen Hu on some a= spects =0A> of the flow label, it seemed like=0A>>> time for another look a= t the =0A> flow label standard, and Sheng Jiang=0A>>> was having similar = =0A> thoughts.=0A>>>=0A>>> We'd like to discuss this in Anaheim =0A> if pos= sible.=0A>>>=0A>>> =0A> Brian=0A>>>=0A>>> -------- Original Message -------= - =0A> Subject: I-D=0A>>> Action:draft-carpenter-6man-flow-update-00.txt = =0A> Date: Wed, 17 Feb=0A>>> 2010 18:15:02 -0800 (PST) From: > ymailto=3D"m= ailto:Internet-Drafts@ietf.org" =0A> href=3D"mailto:Internet-Drafts@ietf.or= g">Internet-Drafts@ietf.org =0A> Reply-To:=0A>>> > href=3D"mailto:internet-= drafts@ietf.org">internet-drafts@ietf.org To: > ymailto=3D"mailto:i-d-annou= nce@ietf.org" =0A> href=3D"mailto:i-d-announce@ietf.org">i-d-announce@ietf.= org=0A>>>=0A>>> =0A> A New Internet-Draft is available from the on-line =0A= > Internet-Drafts=0A>>> directories.=0A>>>=0A>>> =0A> Title : Update to the= IPv6 flow label specification Author(s) : =0A> B.=0A>>>=A0 Carpenter, S. J= iang Filename :=0A>>> =0A> draft-carpenter-6man-flow-update-00.txt Pages : = 9 Date :=0A>>> =0A> 2010-02-17=0A>>>=0A>>> Various uses proposed for the IP= v6 =0A> flow label are incompatible=0A>>> with its existing specification. = =0A> This document describes changes to=0A>>> the specification that permit= =0A> additional use cases as well as=0A>>> allowing continued use of the = =0A> previous specification.=0A>>>=0A>>> A URL for this =0A> Internet-Draft= is:=0A>>>=0A>> =0A> http://www.ietf.org/internet-drafts/draft-carpenter-6m= an-flow-update-00.txt=0A>>=0A>>>=0A>>>=0A>>>=0A>>=0A>>=0A>>=0A> =0A> ------= --------------------------------------------------------------=0A>>> =0A> I= ETF IPv6 working group mailing list > href=3D"mailto:ipv6@ietf.org">ipv6@ie= tf.org Administrative=0A>>> =0A> Requests: > >https://www.ietf.org/mailman/= listinfo/ipv6=0A>>> =0A> --------------------------------------------------= ------------------=0A>>>=0A>>=0A>>>=0A>>>=0A>>>=0A>>=0A>> =0A> ------------= --------------------------------------------------------=0A>> =0A> IETF IPv= 6 working group mailing list > href=3D"mailto:ipv6@ietf.org">ipv6@ietf.org = Administrative=0A>> =0A> Requests: > >https://www.ietf.org/mailman/listinfo= /ipv6=0A>> =0A> -----------------------------------------------------------= ---------=0A>>=0A> =0A> =0A> =0A> =0A> ------------------------------------= --------------------------------=0A> =0A> IETF IPv6 working group mailing l= ist=0A> > href=3D"mailto:ipv6@ietf.org">ipv6@ietf.org=0A> Administrative Re= quests: =0A> > >https://www.ietf.org/mailman/listinfo/ipv6=0A> =0A> -------= -------------------------------------------------------------=0A> =0A> =0A= =0A--------------------------------------------------------------------=0AI= ETF =0A> IPv6 working group mailing list=0A> href=3D"mailto:ipv6@ietf.org">= ipv6@ietf.org=0AAdministrative Requests: > href=3D"https://www.ietf.org/mai= lman/listinfo/ipv6" target=3D_blank =0A> >https://www.ietf.org/mailman/list= info/ipv6=0A---------------------------------------------------------------= -----=0A=0A=0A From jhw@apple.com Wed Apr 14 17:59:01 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 775933A6868 for ; Wed, 14 Apr 2010 17:59:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.547 X-Spam-Level: X-Spam-Status: No, score=-105.547 tagged_above=-999 required=5 tests=[AWL=1.052, 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 M2z7oVxOPVi6 for ; Wed, 14 Apr 2010 17:59:00 -0700 (PDT) Received: from mail-out3.apple.com (mail-out3.apple.com [17.254.13.22]) by core3.amsl.com (Postfix) with ESMTP id CF68F3A6833 for ; Wed, 14 Apr 2010 17:59:00 -0700 (PDT) Received: from relay15.apple.com (relay15.apple.com [17.128.113.54]) by mail-out3.apple.com (Postfix) with ESMTP id E4C5D8E25CF5; Wed, 14 Apr 2010 17:58:54 -0700 (PDT) X-AuditID: 11807136-b7c33ae00000263c-2b-4bc664ce24d2 Received: from il0602f-dhcp79.apple.com (il0602f-dhcp79.apple.com [17.206.50.79]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client did not present a certificate) by relay15.apple.com (Apple SCV relay) with SMTP id 7A.3B.09788.EC466CB4; Wed, 14 Apr 2010 17:58:54 -0700 (PDT) Subject: Re: Extracting the 5-tuple from IPv6 packets Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii From: james woodyatt In-Reply-To: <4BC64100.303@gmail.com> Date: Wed, 14 Apr 2010 17:58:54 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <535BCC7B-196D-4E2A-99ED-7C6D9A5839DB@apple.com> References: <4BC64100.303@gmail.com> To: Brian E Carpenter X-Mailer: Apple Mail (2.1078) X-Brightmail-Tracker: AAAAAQAAAZE= Cc: 6man X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Apr 2010 00:59:01 -0000 On Apr 14, 2010, at 15:26, Brian E Carpenter wrote: >=20 > What do people think? I think this topic reminds me of = . "This document proposes a new family of IPv6 extension headers that will be encoded in a consistent format so that it is possible for intermediate nodes to skip over unknown extension headers and continue to further process the header chain if they so desire." And look: it's expired again. -- james woodyatt member of technical staff, communications engineering From christopher.morrow@gmail.com Wed Apr 14 18:13:19 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 5D4AD3A6A73 for ; Wed, 14 Apr 2010 18:13:19 -0700 (PDT) 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 Gma3CTSZp9l1 for ; Wed, 14 Apr 2010 18:13:18 -0700 (PDT) Received: from mail-yx0-f184.google.com (mail-yx0-f184.google.com [209.85.210.184]) by core3.amsl.com (Postfix) with ESMTP id C1F693A699C for ; Wed, 14 Apr 2010 18:13:16 -0700 (PDT) Received: by yxe14 with SMTP id 14so444315yxe.5 for ; Wed, 14 Apr 2010 18:13:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:received:message-id:subject:from:to:cc:content-type; bh=gtx4xKdDIzh1PAzs4GnYe1ESliI/JRFOELRNcjT2wrA=; b=R0KVWaRBSkoCTFNM1094fI42jSMgBayU5r0RrFFOA9DLw746opqF13kmuHFMTueTcg /4xMmamrWetFP5a3Z8Y8s4d2N/905NpN4EUofJnUa7ONVQ8oaPM1mMgdmK1jJlwXHLQ4 QOQKQYlj0tIGuv2dqXTIIYt+WLJX90z8ykbQg= 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=SzZRjNmp8PtrPIF7EyPKf+Of7DDqIY09sp8TfC9gDAmbItQrwpTCvwrI8PZzdRjPpc +XSzg8USQkHSV/xe6Xj7elDP6AKyOUI99m7pcTsPODIuOja6e1E7W4h3soZKr5bPKdpV Q7q2ayEgUep5DyQSvfaczRHivR+OTyCdkpIek= MIME-Version: 1.0 Received: by 10.231.172.76 with HTTP; Wed, 14 Apr 2010 18:13:07 -0700 (PDT) In-Reply-To: References: <4BC64100.303@gmail.com> Date: Wed, 14 Apr 2010 21:13:07 -0400 Received: by 10.151.87.12 with SMTP id p12mr7366555ybl.174.1271293988039; Wed, 14 Apr 2010 18:13:08 -0700 (PDT) Message-ID: Subject: Re: Extracting the 5-tuple from IPv6 packets From: Christopher Morrow To: Vishwas Manral Content-Type: text/plain; charset=ISO-8859-1 Cc: 6man , Nevil Brownlee , 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: Thu, 15 Apr 2010 01:13:19 -0000 On Wed, Apr 14, 2010 at 7:03 PM, Vishwas Manral wrote: > Hi Brian, > >> Or we can strongly recommend that all hosts set the flow label, so >> that we can use the 3-tuple {source address, dest address, flow label}. > Using a 3-tuple helps in stateless firewalls/ middle boxes/ ECMP, > which cannot/ do-not reassemble all fragments. The 5-tuple is not > available for fragments. using only the 3 tuple also loses you some granularity in your ecmp decision process... I'm not sure it's a good plan to use the flow label for something it's explicitly not supposed to be used for, and I don't know that you can get enough granularity with just these 3 pieces of 'randomness' to has flows out across wide ecmp paths. More data for the hash seems better. -Chris From christopher.morrow@gmail.com Wed Apr 14 18:17:16 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 9BFC83A6A73 for ; Wed, 14 Apr 2010 18:17:16 -0700 (PDT) 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 XkUe5gbIkhZJ for ; Wed, 14 Apr 2010 18:17:15 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by core3.amsl.com (Postfix) with ESMTP id E8C263A6AC9 for ; Wed, 14 Apr 2010 18:17:13 -0700 (PDT) Received: by gyh4 with SMTP id 4so419778gyh.31 for ; Wed, 14 Apr 2010 18:17:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:received:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=5zaNProszREWipG5D9jRQiOjXYtTqEaEr5KzlhZ717U=; b=C6CbVn9vbbaLadzkPZVl5HY3rcvb0xZA7RnQXto1eWI10lEwd67ccJYmkmkLnJKhhW MbOt61H2CpWo7FHgn4sLzOciarxHMvDWtErW8Cfs3cUzHVnVXM7Wi7t/StSxg38T0hr1 Fdvg2Vzekc922+cPI0yTSCR7cVP/32LyU4idE= 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=bqVwOStwxKSgDfLbuc9XP1Eel+XMkDs4QSulHn68Pg3G/3epWFkFksWFr7a/gYWtVa jCQSh0rnpa61VZpXDFked4Qqgvh0W4ujT+wVTLUJynBOffW0L2eH8hscdnZ/xvvq28Ci Mzfr623JBa/oz0D2CjlfbAm3Q8fS0hHpp4uxw= MIME-Version: 1.0 Received: by 10.231.172.76 with HTTP; Wed, 14 Apr 2010 18:17:03 -0700 (PDT) In-Reply-To: <21A9EECC-0987-4B3A-9A8C-D17F3037D819@gmail.com> References: <4BC64100.303@gmail.com> <21A9EECC-0987-4B3A-9A8C-D17F3037D819@gmail.com> Date: Wed, 14 Apr 2010 21:17:03 -0400 Received: by 10.101.196.32 with SMTP id y32mr12920222anp.81.1271294223693; Wed, 14 Apr 2010 18:17:03 -0700 (PDT) Message-ID: Subject: Re: Extracting the 5-tuple from IPv6 packets From: Christopher Morrow To: Bob Hinden Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: 6man , Nevil Brownlee , 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: Thu, 15 Apr 2010 01:17:16 -0000 On Wed, Apr 14, 2010 at 7:16 PM, Bob Hinden wrote: > Brian, > > On Apr 14, 2010, at 3:26 PM, Brian E Carpenter wrote: > >> Hi, >> >> Common practice in network monitoring and in QoS technologies >> is to identify a flow of packets by the 5-tuple >> {source address, dest address, source port, dest port, protocol #}. >> This is relatively trivial at line speed in IPv4 since >> these things are at fixed locations in the header. But in IPv6, >> the protocol number is at the end of a linked list of "next >> headers." Even if the normal case is only one item in the linked >> list, any implementation (hardware or software) that extracts >> the 5-tuple has to follow the linked list to the end. > > Do we have any data on what percentage of packets have the next header a = transport header vs. something else? =A0It would be good to know how often = it's the non-trivial case. > > I agree that an implementation will have to know how to at least check wh= at the next header is. > most high-end routers today that do v6 only deal with a limited number (3 or so) extension headers anyway, so they've figured out how to do line-rate 100-ge with ipv6 ... this is, also, one of the reason whenever someone says: "We should make an extension header for this!" I say: "Extension headers are the devil, they should all die a horrible death, don't add to an already horrendous problem." >> >> As Mark Smith said in relation to draft-carpenter-6man-flow-update-02 >> Or we can strongly recommend that all hosts set the flow label, so >> that we can use the 3-tuple {source address, dest address, flow label}. >> >> What do people think? > > That would make a lot of sense to me. =A0It would also have an advantage = of allowing a set of TCP connections between two hosts to be associated as = a single flow where the hosts wanted them to be treated in the same manner.= =A0It's hard to do that with IPv4 as the port numbers will be different fo= r each TCP connection. This seems fine, until the 2 sessions are larger (combined) than parts of the pathways between the 2 hosts. ECMP/LAG are nice tools, and necessary in today's internet, if you can't hash the flows reasonably and 2 large flows end up hashed to the same smaller link bad things for the hosts' traffic will happen. -Chris From shane@castlepoint.net Wed Apr 14 19:11:24 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 7964E3A6AE2 for ; Wed, 14 Apr 2010 19:11:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.139 X-Spam-Level: X-Spam-Status: No, score=-2.139 tagged_above=-999 required=5 tests=[AWL=0.460, 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 8r6eEjr8OG7W for ; Wed, 14 Apr 2010 19:11:22 -0700 (PDT) Received: from dog.tcb.net (dog.tcb.net [64.78.150.133]) by core3.amsl.com (Postfix) with ESMTP id 77D4E3A6998 for ; Wed, 14 Apr 2010 19:11:05 -0700 (PDT) Received: by dog.tcb.net (Postfix, from userid 0) id 0FCAF268675; Wed, 14 Apr 2010 20:10:59 -0600 (MDT) Received: from mbpw.castlepoint.net (71-215-81-125.hlrn.qwest.net [71.215.81.125]) (authenticated-user smtp) (TLSv1/SSLv3 AES128-SHA 128/128) by dog.tcb.net with SMTP; Wed, 14 Apr 2010 20:10:58 -0600 (MDT) (envelope-from shane@castlepoint.net) X-Avenger: version=0.7.8; receiver=dog.tcb.net; client-ip=71.215.81.125; client-port=51506; syn-fingerprint=65535:56:1:64:M1452,N,W1,N,N,T,S; data-bytes=0 Subject: Re: [Fwd: New Version Notification for draft-carpenter-6man-flow-update-02] Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii From: Shane Amante In-Reply-To: <4BC63DF0.6070707@gmail.com> Date: Wed, 14 Apr 2010 20:10:42 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4BC54919.3000900@gmail.com> <20100415072936.60eb08ac@opy.nosense.org> <4BC63DF0.6070707@gmail.com> To: Brian E Carpenter X-Mailer: Apple Mail (2.1078) Cc: 6man X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Apr 2010 02:11:25 -0000 Brian, Mark, Brian: FWIW, I like the direction of this version of draft much better = than previous versions; however, I agree with Remi that the current = version is a bit confusing at the moment and could likely be rewritten = to be more simple and just obsolete RFC 3967. In addition, I'm still a = bit unclear and, therefore, uncomfortable on the proposal with respect = to flow-labels within an "administratively defined domain". In = particular, if one administrative domain has set their own "locally = defined" flow-label, I think the draft could benefit from a stronger = emphasis that the flow-label MUST or, at least, SHOULD be reset to 0 = upon /leaving/ that domain, otherwise the next domain may (or, will?) = misinterpret the meaning of the incoming "locally-defined" flow-label. = The way I interpret the text in Bullet 3 of Section 3 seems written in a = way that is specific to packets entering domains that are going to use = locally-defined flow-labels, but not how they must treat those same = packets as they leave their domain and, most importantly, need to = interact with other domains that don't understand or want to use a = "standard" definition of a flow-label, i.e.: in Bullets 1, 2 & 4. Or, = perhaps I'm misunderstanding something. More below. On Apr 14, 2010, at 16:13 MDT, Brian E Carpenter wrote: > Hi Mark, >=20 > On 2010-04-15 09:59, Mark Smith wrote: >> Hi Brian and Sheng, >>=20 >> On Wed, 14 Apr 2010 16:48:25 +1200 >> Brian E Carpenter wrote: >>=20 >>> Hi, >>>=20 >>> This is completely revised from the proposal we presented >>> in Anaheim. This version allows locally defined use of >>> the flow label in a simpler way, as the discussion suggested. >>> It's still quite a dense read, but we believe that if this was >>> adopted, it would open the way to actually using the flow label. >>>=20 >>=20 >> I've had a read through it, although not a comprehensive one, which >> I'll endeavour to do in the next day or so. >>=20 >> I'm wondering about this change for a couple of reasons: >>=20 >> -- >> 2. If this is done, all packets in a given flow MUST be given the >> same flow label value. A flow is defined in this case as all >> packets with the same source and destination IPv6 addresses and >> port numbers and the same transport protocol number, i.e., the >> same final Next Header value [RFC2460]. This rule constrains = the >> definition of a flow in RFC 3697 for the specific case that a >> router sets the flow label. However, it does not constrain the >> bits of the flow label in any particular way. >> -- >>=20 >> Firstly, if the IPv6 packets are fragments, the transport layer = header >> may not be available. I think that would mean that although these >> packets fragments are part of a flow, they wouldn't have their flow >> label changed. >=20 > Yes, certainly, if the router inserting the flow label is stateless. > I honestly don't see a way round that and it's probably better to > list it as a limitation. It probably doesn't matter - anyone who is > deploying a local scheme for the flow label is presumably able to > also deploy a non-fragmenting network. Actually, one would hope that implementations are actually "smart" about = fragments. Specifically, one could look for a Fragment Header and, upon = noticing it, mask out or exclude Layer-4 transport information, (e.g.: = protocol, source and destination port) as input keys for, say, LAG or = ECMP. This means one would only consider the 2-tuple of source and = destination IP address, which is better than nothing, but more = importantly would still preserve ordering. >> Secondly, for IPv6 packets with a number of extension headers before >> the transport layer header, I think this rule could impact forwarding >> performance. While I'm not sure if it is that practical, however it'd >> be good if flow classification could be done using only fixed headers >> in the IPv6 packet, or a fixed portion of the fixed header bits. >=20 > I will send a separate message on that point. I wholeheartedly agree with Mark's point. I would add that IPv6 = Extension Headers may not impact forwarding performance on PE = interfaces, because they are [somewhat] high-touch interfaces that = typically must be capable of imposing various 2- or 5-, or 6-tuple[1] = classifiers on PE-CE interfaces for applying ACL's (forward/drop), = policing/rate-limiting or marking (IPv6 TC field) functions. *However*, = the same is not true of P routers, which generally have several dozen = bleeding edge interfaces of 40G and 100G and beyond. Thus, allowing P = routers to more quickly access input keys to a LAG or ECMP hash function = is pretty critical. [1] 6-tuple if you include Traffic Class. >> I suppose partly that comes down to what a 'flow' is. In some = contexts, >> it is definitely a transport layer connection. In others, e.g. an = MPLS >> network, I think it could be seen to be all packets that match a >> Forwarding Equivalence Class. If it was possible to use a FEC to set >> the flow label, once the packet has traversed the MPLS network, and = the >> MPLS labels are stripped off, the flow label that was set due to the >> FEC would be preserved, which might be useful. Is there an = opportunity >> to make the definition of a flow a bit more general, and then for = allow >> for the choice of different packet classification methods to be used = to >> define a flow, based on context e.g. transport layer connection in = some >> contexts, MPLS FEC, QoS/Diff Serv classifiers etc. in others? >=20 > And that's an even wider question. I'm inclined to duck it, or at > least to assert that it's a much wider question than 6man can tackle. Let's not duck ... not yet, anyway. :-) With respect to MPLS, there is the following, now expired, draft which = might be what you're looking for: http://tools.ietf.org/html/draft-kompella-mpls-entropy-label-00 ... however, there are some challenges with it, namely handling = Penultimate Hop Popping (PHP), which isn't discussed in the draft, plus = the fact that legacy HW certainly most likely will not support pushing = additional labels required to insert an entropy-label. If you're = interested in this draft, I suggest we take if offline and/or to the = MPLS list. That said, I would hope the use of an MPLS entropy label might be = avoided for IP over MPLS traffic and, instead, a simpler approach would = be to use (even in MPLS networks) just the following as input-keys to = LAG or ECMP: - IPv6 source address; - IPv6 destination address; and, - A _proper_ IPv6 flow-label that unambiguously identifies an underlying = "flow" ... without needing to seek out Transport layer info. I believe it would be an implementation detail as to what IPv6 header = fields a vendor would allow to be included as input-keys to a hash that = would be calculated and put into a IPv6 flow-label. Although, certainly = I would hope we could insist on a minimum of the 2-tuple and "recommend" = that they include the more valuable the 5- or 6-tuple as input-keys to = the hash algorithm for the flow-label. -shane > Brian >>=20 >> Regards, >> Mark. >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>> Brian and Sheng >>>=20 >>> -------- Original Message -------- >>> Subject: New Version Notification for = draft-carpenter-6man-flow-update-02 >>> Date: Tue, 13 Apr 2010 21:44:42 -0700 (PDT) >>> From: IETF I-D Submission Tool >>> To: brian.e.carpenter@gmail.com >>> CC: shengjiang@huawei.com >>>=20 >>>=20 >>> A new version of I-D, draft-carpenter-6man-flow-update-02.txt has = been successfully submitted by Brian Carpenter and posted to >>> the IETF repository. >>>=20 >>> Filename: draft-carpenter-6man-flow-update >>> Revision: 02 >>> Title: Update to the IPv6 flow label specification >>> Creation_date: 2010-04-13 >>> WG ID: Independent Submission >>> Number_of_pages: 10 >>>=20 >>> Abstract: >>> Various uses proposed for the IPv6 flow label are incompatible with >>> its existing specification. This document describes changes to the >>> specification that permit additional use cases as well as allowing >>> continued use of the previous specification. >>>=20 >>>=20 >>>=20 >>> The IETF Secretariat. >>>=20 >>>=20 >>>=20 >>> -------------------------------------------------------------------- >>> IETF IPv6 working group mailing list >>> ipv6@ietf.org >>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >>> -------------------------------------------------------------------- >>=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From pal@cs.stanford.edu Wed Apr 14 20:18:45 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 4B19C28C105 for ; Wed, 14 Apr 2010 20:18:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.374 X-Spam-Level: X-Spam-Status: No, score=-6.374 tagged_above=-999 required=5 tests=[AWL=0.225, 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 0K7uwArxmxxF for ; Wed, 14 Apr 2010 20:18:44 -0700 (PDT) Received: from cs-smtp-1.Stanford.EDU (cs-smtp-1.Stanford.EDU [171.64.64.25]) by core3.amsl.com (Postfix) with ESMTP id 2EA9228C0F7 for ; Wed, 14 Apr 2010 20:18:44 -0700 (PDT) Received: from [76.14.71.8] (helo=[192.168.1.102]) by cs-smtp-1.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1O2FbB-0007z9-UG; Wed, 14 Apr 2010 20:18:38 -0700 Subject: Re: [Fwd: I-D Action:draft-carpenter-6man-flow-update-00.txt] Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=iso-8859-1 From: Philip Levis In-Reply-To: <4BC6428A.9030808@gmail.com> Date: Wed, 14 Apr 2010 20:18:37 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <9AE44546-DECD-4686-A346-88B0A58EB25E@cs.stanford.edu> References: <4B7CB52D.20902@gmail.com> <4BC5F981.2080101@gmail.com> <4BC6428A.9030808@gmail.com> To: Alexandru Petrescu X-Mailer: Apple Mail (2.1078) X-Scan-Signature: 8e086a056c9d4443aaf3b84243aabc30 Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Apr 2010 03:18:45 -0000 On Apr 14, 2010, at 3:32 PM, Alexandru Petrescu wrote: > Le 14/04/2010 22:23, Philip Levis a =E9crit : >>=20 >> On Apr 14, 2010, at 10:21 AM, Alexandru Petrescu wrote: >>=20 >>> Hi, I came across this draft coming from the ROLL space where a >>> proposal exists to use the Flow Label changed enroute maybe. >>=20 >> Alex, >>=20 >> I think you're misrepresenting ROLL here, even though (after your >> objections there) the use of the flow label was very clearly >> described a few days ago. Changing the flow label enroute is not on >> the table in ROLL; it was a while ago as a crazy idea, then everyone >> realized the issues it would create. >=20 > Sorry for misunderstanding... >=20 > (only a day ago it was stated in ROLL list that changing the flow = label > enroute is possible as long as it is restored...) Sure, it's possible, that doesn't mean RPL is going to do it. Doing so = requires having somewhere in the packet to store the original value, = which necessitates a header; if there's a header, there's no point in = changing the flow label. It's my understanding there are some proposals = out there for doing this, but in other domains -- this was mentioned at = the mike in Hiroshima -- but that by no means indicates RPL will. Phil= From brian.e.carpenter@gmail.com Wed Apr 14 20:52:36 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 4EED428C169 for ; Wed, 14 Apr 2010 20:52:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.327 X-Spam-Level: X-Spam-Status: No, score=-2.327 tagged_above=-999 required=5 tests=[AWL=0.272, 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 h36H1X8r9rAP for ; Wed, 14 Apr 2010 20:52:35 -0700 (PDT) Received: from mail-pz0-f193.google.com (mail-pz0-f193.google.com [209.85.222.193]) by core3.amsl.com (Postfix) with ESMTP id EBDE028C168 for ; Wed, 14 Apr 2010 20:52:34 -0700 (PDT) Received: by pzk31 with SMTP id 31so40599pzk.31 for ; Wed, 14 Apr 2010 20:52:26 -0700 (PDT) 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=3FShyEd7e5KbxrIzdi115JZZLikIFmEWDly+SywiWjA=; b=twCuffUpU5qz8PEE5Qy0rv2q+OoX9dfmuWS1SGDd9R4lKc/jw7iXMgy0l5pByK6t9/ 6ZSDUkYGE0ex1w+8K4NTSJ7hUo2wM1VuacDbwxOPzwjSAJw6rblikXzyhd/rzGKhsDt2 BRcRue34kU7bcghdlztmFKK8C8NdrcBb6rQDQ= 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=Jt5rnbfR9yhAUSFynZWZYLb8rddm4nNjLkW9c3DL8WverueuDK/Tu0GggsVDOL8YNw bJNdf/sI+Bw1auPv3z6lOR91xD8iJDZVCLqrRnNarHqdVVvWqYxxIS8Ybto3iM+eaEsk KE9Z4yaWGlMCbMy7PEKEsjPYWxJNIrk/RDSxk= Received: by 10.115.81.37 with SMTP id i37mr7937785wal.95.1271303546005; Wed, 14 Apr 2010 20:52:26 -0700 (PDT) Received: from [130.216.38.124] (stf-brian.sfac.auckland.ac.nz [130.216.38.124]) by mx.google.com with ESMTPS id 20sm885216pzk.3.2010.04.14.20.52.24 (version=SSLv3 cipher=RC4-MD5); Wed, 14 Apr 2010 20:52:25 -0700 (PDT) Message-ID: <4BC68D6F.8070500@gmail.com> Date: Thu, 15 Apr 2010 15:52:15 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Shane Amante Subject: Re: [Fwd: New Version Notification for draft-carpenter-6man-flow-update-02] References: <4BC54919.3000900@gmail.com> <20100415072936.60eb08ac@opy.nosense.org> <4BC63DF0.6070707@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: Thu, 15 Apr 2010 03:52:36 -0000 Regards Brian Carpenter On 2010-04-15 14:10, Shane Amante wrote: > Brian, Mark, > > Brian: FWIW, I like the direction of this version of draft > much better than previous versions; however, I agree with > Remi that the current version is a bit confusing at the > moment and could likely be rewritten to be more simple and > just obsolete RFC 3967. In addition, I'm still a bit unclear > and, therefore, uncomfortable on the proposal with respect to > flow-labels within an "administratively defined domain". In > particular, if one administrative domain has set their own > "locally defined" flow-label, I think the draft could benefit > from a stronger emphasis that the flow-label MUST or, at > least, SHOULD be reset to 0 upon /leaving/ that domain, > otherwise the next domain may (or, will?) misinterpret the > meaning of the incoming "locally-defined" flow-label. The I'm personally quite attracted by this. It does further damage to the sacred principle that the flow label is immutable, but maybe that is the inevitable result anyway. Brian > way I interpret the text in Bullet 3 of Section 3 seems > written in a way that is specific to packets entering domains > that are going to use locally-defined flow-labels, but not > how they must treat those same packets as they leave their > domain and, most importantly, need to interact with other > domains that don't understand or want to use a "standard" > definition of a flow-label, i.e.: in Bullets 1, 2 & 4. Or, > perhaps I'm misunderstanding something. > > More below. > > On Apr 14, 2010, at 16:13 MDT, Brian E Carpenter wrote: >> Hi Mark, >> >> On 2010-04-15 09:59, Mark Smith wrote: >>> Hi Brian and Sheng, >>> >>> On Wed, 14 Apr 2010 16:48:25 +1200 Brian E Carpenter >>> wrote: >>> >>>> Hi, >>>> >>>> This is completely revised from the proposal we >>>> presented in Anaheim. This version allows locally >>>> defined use of the flow label in a simpler way, as the >>>> discussion suggested. It's still quite a dense read, >>>> but we believe that if this was adopted, it would open >>>> the way to actually using the flow label. >>>> >>> I've had a read through it, although not a comprehensive >>> one, which I'll endeavour to do in the next day or so. >>> >>> I'm wondering about this change for a couple of reasons: >>> >>> -- 2. If this is done, all packets in a given flow MUST >>> be given the same flow label value. A flow is defined in >>> this case as all packets with the same source and >>> destination IPv6 addresses and port numbers and the same >>> transport protocol number, i.e., the same final Next >>> Header value [RFC2460]. This rule constrains the >>> definition of a flow in RFC 3697 for the specific case >>> that a router sets the flow label. However, it does not >>> constrain the bits of the flow label in any particular >>> way. -- >>> >>> Firstly, if the IPv6 packets are fragments, the transport >>> layer header may not be available. I think that would >>> mean that although these packets fragments are part of a >>> flow, they wouldn't have their flow label changed. >> Yes, certainly, if the router inserting the flow label is >> stateless. I honestly don't see a way round that and it's >> probably better to list it as a limitation. It probably >> doesn't matter - anyone who is deploying a local scheme for >> the flow label is presumably able to also deploy a >> non-fragmenting network. > > Actually, one would hope that implementations are actually > "smart" about fragments. Specifically, one could look for a > Fragment Header and, upon noticing it, mask out or exclude > Layer-4 transport information, (e.g.: protocol, source and > destination port) as input keys for, say, LAG or ECMP. This > means one would only consider the 2-tuple of source and > destination IP address, which is better than nothing, but > more importantly would still preserve ordering. > > >>> Secondly, for IPv6 packets with a number of extension >>> headers before the transport layer header, I think this >>> rule could impact forwarding performance. While I'm not >>> sure if it is that practical, however it'd be good if >>> flow classification could be done using only fixed >>> headers in the IPv6 packet, or a fixed portion of the >>> fixed header bits. >> I will send a separate message on that point. > > I wholeheartedly agree with Mark's point. I would add that > IPv6 Extension Headers may not impact forwarding performance > on PE interfaces, because they are [somewhat] high-touch > interfaces that typically must be capable of imposing various > 2- or 5-, or 6-tuple[1] classifiers on PE-CE interfaces for > applying ACL's (forward/drop), policing/rate-limiting or > marking (IPv6 TC field) functions. *However*, the same is > not true of P routers, which generally have several dozen > bleeding edge interfaces of 40G and 100G and beyond. Thus, > allowing P routers to more quickly access input keys to a LAG > or ECMP hash function is pretty critical. > > [1] 6-tuple if you include Traffic Class. > > >>> I suppose partly that comes down to what a 'flow' is. In >>> some contexts, it is definitely a transport layer >>> connection. In others, e.g. an MPLS network, I think it >>> could be seen to be all packets that match a Forwarding >>> Equivalence Class. If it was possible to use a FEC to set >>> the flow label, once the packet has traversed the MPLS >>> network, and the MPLS labels are stripped off, the flow >>> label that was set due to the FEC would be preserved, >>> which might be useful. Is there an opportunity to make >>> the definition of a flow a bit more general, and then for >>> allow for the choice of different packet classification >>> methods to be used to define a flow, based on context >>> e.g. transport layer connection in some contexts, MPLS >>> FEC, QoS/Diff Serv classifiers etc. in others? >> And that's an even wider question. I'm inclined to duck it, >> or at least to assert that it's a much wider question than >> 6man can tackle. > > Let's not duck ... not yet, anyway. :-) > > With respect to MPLS, there is the following, now expired, > draft which might be what you're looking for: > http://tools.ietf.org/html/draft-kompella-mpls-entropy-label-00 > ... however, there are some challenges with it, namely > handling Penultimate Hop Popping (PHP), which isn't discussed > in the draft, plus the fact that legacy HW certainly most > likely will not support pushing additional labels required to > insert an entropy-label. If you're interested in this draft, > I suggest we take if offline and/or to the MPLS list. > > That said, I would hope the use of an MPLS entropy label > might be avoided for IP over MPLS traffic and, instead, a > simpler approach would be to use (even in MPLS networks) just > the following as input-keys to LAG or ECMP: - IPv6 source > address; - IPv6 destination address; and, - A _proper_ IPv6 > flow-label that unambiguously identifies an underlying "flow" > ... without needing to seek out Transport layer info. > > I believe it would be an implementation detail as to what > IPv6 header fields a vendor would allow to be included as > input-keys to a hash that would be calculated and put into a > IPv6 flow-label. Although, certainly I would hope we could > insist on a minimum of the 2-tuple and "recommend" that they > include the more valuable the 5- or 6-tuple as input-keys to > the hash algorithm for the flow-label. > > -shane > > > > > >> Brian >>> Regards, Mark. >>> >>> >>> >>> >>> >>> >>>> Brian and Sheng >>>> >>>> -------- Original Message -------- Subject: New Version >>>> Notification for draft-carpenter-6man-flow-update-02 >>>> Date: Tue, 13 Apr 2010 21:44:42 -0700 (PDT) From: IETF >>>> I-D Submission Tool To: >>>> brian.e.carpenter@gmail.com CC: shengjiang@huawei.com >>>> >>>> >>>> A new version of I-D, >>>> draft-carpenter-6man-flow-update-02.txt has been >>>> successfully submitted by Brian Carpenter and posted to >>>> the IETF repository. >>>> >>>> Filename: draft-carpenter-6man-flow-update Revision: >>>> 02 Title: Update to the IPv6 flow label specification >>>> Creation_date: 2010-04-13 WG ID: Independent >>>> Submission Number_of_pages: 10 >>>> >>>> Abstract: Various uses proposed for the IPv6 flow label >>>> are incompatible with its existing specification. This >>>> document describes changes to the specification that >>>> permit additional use cases as well as allowing >>>> continued use of the previous specification. >>>> >>>> >>>> >>>> The IETF Secretariat. >>>> >>>> >>>> >>>> -------------------------------------------------------------------- >>>> IETF IPv6 working group mailing list ipv6@ietf.org >>>> Administrative Requests: >>>> https://www.ietf.org/mailman/listinfo/ipv6 >>>> -------------------------------------------------------------------- >>>> >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list ipv6@ietf.org >> Administrative Requests: >> https://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- >> > > From brian.e.carpenter@gmail.com Wed Apr 14 21:53:55 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 B48083A6B34 for ; Wed, 14 Apr 2010 21:53:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.341 X-Spam-Level: X-Spam-Status: No, score=-2.341 tagged_above=-999 required=5 tests=[AWL=0.258, 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 q-tDHVq+x7AT for ; Wed, 14 Apr 2010 21:53:55 -0700 (PDT) Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by core3.amsl.com (Postfix) with ESMTP id F123B3A6ABD for ; Wed, 14 Apr 2010 21:53:54 -0700 (PDT) Received: by pwj2 with SMTP id 2so804893pwj.31 for ; Wed, 14 Apr 2010 21:53:46 -0700 (PDT) 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=3y6Rngz4Q1uJGyZEkGuknDAEQry/Nsh1Df5N9xkl7G8=; b=QUtiGBPJ9sAK/9LspSaeih0hyOWx7K2qL1UGW9ON8szVZPrHLsn7dQDTqSP0BG7sqN z+dwgHvDURgP1vJj7Pp09AtLG7EIht+rzUm/46rR8XSnxSt0DIRcK04w0WQEKJvTyXrQ fcyQRQg6nnYQM8PutLF5P8JPFKtqjCVF2Pvow= 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=MuW+P4Ci+k7ZPzgtfWlI4zWKxByuh1DwT/eR18EcUAFVb7MoDmwBeoGJRW1uv10lWa xYI1dM5bWA5NSXdNUsCGhOnwDxYg9jd/1oPVWiGe17fc1bnt50F+a0RBLAxpwq/IbFGo 2qwk2jRDyK7FjY1MCLrgHz7CpzR1qAQVq3vJA= Received: by 10.142.55.4 with SMTP id d4mr3797317wfa.309.1271307226315; Wed, 14 Apr 2010 21:53:46 -0700 (PDT) Received: from [130.216.38.124] (stf-brian.sfac.auckland.ac.nz [130.216.38.124]) by mx.google.com with ESMTPS id 22sm925745pzk.1.2010.04.14.21.53.45 (version=SSLv3 cipher=RC4-MD5); Wed, 14 Apr 2010 21:53:45 -0700 (PDT) Message-ID: <4BC69BCB.8080701@gmail.com> Date: Thu, 15 Apr 2010 16:53:31 +1200 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: New Version Notification for draft-carpenter-flow-ecmp-02] 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: Thu, 15 Apr 2010 04:53:55 -0000 Shane Amante and I have updated this draft, and we'd like the 6man WG to consider it as a potential BCP (or alternatively, suggest another WG for it, but it does seem like IPv6 maintenance). We think this version responds to the discussion in Anaheim and the comments we've received; the main differences from the 01 draft are a) link aggregation is now explicitly covered b) normative keywords added Brian -------- Original Message -------- Subject: New Version Notification for draft-carpenter-flow-ecmp-02 Date: Wed, 14 Apr 2010 21:49:34 -0700 (PDT) From: IETF I-D Submission Tool To: brian.e.carpenter@gmail.com CC: shane@level3.net A new version of I-D, draft-carpenter-flow-ecmp-02.txt has been successfully submitted by Brian Carpenter and posted to the IETF repository. Filename: draft-carpenter-flow-ecmp Revision: 02 Title: Using the IPv6 flow label for equal cost multipath routing and link aggregation in tunnels Creation_date: 2010-04-14 WG ID: Independent Submission Number_of_pages: 8 Abstract: The IPv6 flow label has certain restrictions on its use. This document describes how those restrictions apply when using the flow label for load balancing by equal cost multipath routing, and for link aggregation, particularly for tunneled traffic. The IETF Secretariat. -- Regards Brian Carpenter From shane@castlepoint.net Wed Apr 14 22:31:18 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 048E53A659C for ; Wed, 14 Apr 2010 22:31:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.216 X-Spam-Level: X-Spam-Status: No, score=-2.216 tagged_above=-999 required=5 tests=[AWL=0.383, 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 u0cp31LnvAKZ for ; Wed, 14 Apr 2010 22:31:15 -0700 (PDT) Received: from dog.tcb.net (dog.tcb.net [64.78.150.133]) by core3.amsl.com (Postfix) with ESMTP id 7A6B23A6B88 for ; Wed, 14 Apr 2010 22:26:45 -0700 (PDT) Received: by dog.tcb.net (Postfix, from userid 0) id B6CF8268675; Wed, 14 Apr 2010 23:25:58 -0600 (MDT) Received: from mbpw.castlepoint.net (71-215-81-125.hlrn.qwest.net [71.215.81.125]) (authenticated-user smtp) (TLSv1/SSLv3 AES128-SHA 128/128) by dog.tcb.net with SMTP; Wed, 14 Apr 2010 23:25:58 -0600 (MDT) (envelope-from shane@castlepoint.net) X-Avenger: version=0.7.8; receiver=dog.tcb.net; client-ip=71.215.81.125; client-port=54337; syn-fingerprint=65535:56:1:64:M1452,N,W1,N,N,T,S; data-bytes=0 Subject: Re: [Fwd: New Version Notification for draft-carpenter-flow-ecmp-02] Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii From: Shane Amante In-Reply-To: <4BC69BCB.8080701@gmail.com> Date: Wed, 14 Apr 2010 23:25:42 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <35A5E745-D613-4C74-A0DB-0540F13A40BE@castlepoint.net> References: <4BC69BCB.8080701@gmail.com> To: Brian E Carpenter X-Mailer: Apple Mail (2.1078) Cc: 6man X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Apr 2010 05:31:18 -0000 A question for the WG. Underneath the diagram of the TEP's, there is reference to the fact that = the input keys to the modulo(N) hash are quite large, which could be = problematic for HW implementations. However, below that, in the last = bullet in Section 2, there is a statement about adding the flow-label to = the existing 5-tuple hash which would increase the input keys from 296 = bits to 316 bits, which seems somewhat contradictory to what was said = above. Perhaps we could change the existing recommendation around to be = as follows: ---snip--- o At intermediate router(s) that perform ECMP or LAG for packets whose source address is a TEP, the hash MUST minimally include the triple {dest addr, source addr, flow label} to meet the [RFC3697] rules. In practice, since the routers are assumed to be unaware of tunneled traffic, this means intermediate router(s) SHOULD add the flow label to the existing 5-tuple hash of the outer IP header. ---snip--- More generally, this really raises the question of the practicality of = searching for Layer-4 protocol, source & destination port info in = headers and using them as input keys for LAG + ECMP when forwarding = IPv6, particularly on high-speed core routers. Ultimately, if the = flow-label was known to denote a proper "microflow" (as defined by RFC = 2474), then it would make HW implementations much simpler in that they = have a known & fixed set of header fields, specifically: {dest address, = src address + flow-label}, they would use as input keys for LAG + ECMP. = Arguably, it makes adding Extension Headers easier in the future, as = well, given that we don't have to worry as much about intermediate = routers being unable to look past them ... Of course, the downside is = this effectively boxes out any other (future) use of the flow-label. = Thoughts? -shane On Apr 14, 2010, at 22:53 MDT, Brian E Carpenter wrote: > Shane Amante and I have updated this draft, and we'd like > the 6man WG to consider it as a potential BCP (or > alternatively, suggest another WG for it, but it does seem > like IPv6 maintenance). >=20 > We think this version responds to the discussion in Anaheim > and the comments we've received; the main differences from the > 01 draft are >=20 > a) link aggregation is now explicitly covered > b) normative keywords added >=20 > Brian >=20 > -------- Original Message -------- > Subject: New Version Notification for draft-carpenter-flow-ecmp-02 > Date: Wed, 14 Apr 2010 21:49:34 -0700 (PDT) > From: IETF I-D Submission Tool > To: brian.e.carpenter@gmail.com > CC: shane@level3.net >=20 >=20 > A new version of I-D, draft-carpenter-flow-ecmp-02.txt has been > successfully submitted by Brian Carpenter and posted to the IETF > repository. >=20 > Filename: draft-carpenter-flow-ecmp > Revision: 02 > Title: Using the IPv6 flow label for equal cost = multipath > routing and link aggregation in tunnels > Creation_date: 2010-04-14 > WG ID: Independent Submission > Number_of_pages: 8 >=20 > Abstract: > The IPv6 flow label has certain restrictions on its use. This > document describes how those restrictions apply when using the flow > label for load balancing by equal cost multipath routing, and for > link aggregation, particularly for tunneled traffic. >=20 >=20 >=20 >=20 > The IETF Secretariat. >=20 >=20 >=20 >=20 > --=20 > Regards > Brian Carpenter >=20 >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From paravpandit@yahoo.com Wed Apr 14 22:57:13 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 4B9E03A6AF7 for ; Wed, 14 Apr 2010 22:57:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.349 X-Spam-Level: X-Spam-Status: No, score=-0.349 tagged_above=-999 required=5 tests=[AWL=-0.950, BAYES_50=0.001, J_CHICKENPOX_44=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 8XCgUpGK2o-d for ; Wed, 14 Apr 2010 22:57:12 -0700 (PDT) Received: from web30104.mail.mud.yahoo.com (web30104.mail.mud.yahoo.com [209.191.69.36]) by core3.amsl.com (Postfix) with SMTP id 52EBB3A68F6 for ; Wed, 14 Apr 2010 22:56:02 -0700 (PDT) Received: (qmail 45868 invoked by uid 60001); 15 Apr 2010 05:55:53 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1271310953; bh=mNv/tsPgUXRC1wFlAh/tw3mxa9u/fmm9ynGScNsPuOY=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:MIME-Version:Content-Type; b=KrMvX3N92tXJZ5hkyW68ocL5fusu15RfNj7WbJF4FwIOlbhpHtfz/vg4ocucn6DAfWS/18Ioc6ht5vdntgV50rMNA52Yx1aK5+7TFo4qvt52wL3ZQt1f8HbguEb5+KQka82jlB2i/gmtfyfoRSyuR0VdkNECqprwxcWuAr5r4P0= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:MIME-Version:Content-Type; b=sbZOm1B3cTAPtbV2jKZ54u1Ve6U9sI7urlNyx4JLgQh9+bPY8NSYnMEEEBSm4c0gAXzg/yk+aurlGwJMwUdZtTR+lDA6uRmVV8wVi7EfplrvosZPXyAfQQRxKAMJZv0ojV+QquuOJipHY5/vkIT87AEzdl3+THF6HKpkFDwKq3I=; Message-ID: <342102.44906.qm@web30104.mail.mud.yahoo.com> X-YMail-OSG: HGC2UL4VM1kDZySrtUGl6INvlSZmdL0WcCTrQTlTlcO6BzT MPj0GHY51WAY5A6aHmckUc_Bdk3kBLJEJbJ4FhvKGXtT_4f6ZTdRDQQJSVGO .uwsoPGQj7Ayj.nbnKhvJV9zEhwVeqzEqSth7IjdmptNISsDcmouLxBb277Z RIUHknMxRyGw7slSp3pA1ymjNAX5k53QI0DlSfzKxhZn4OpXzXSbDCBQ8m9S Ma3SZJZlaIfLAAy3LUr3AKmFHx4AnNzts4VF9xNB9IMQCJcCMHNcpm1WvYwo aYFs6mChdF3p9EPR0vMFvScSN4eGasnnZJ4g- Received: from [111.93.130.139] by web30104.mail.mud.yahoo.com via HTTP; Wed, 14 Apr 2010 22:55:53 PDT X-Mailer: YahooMailClassic/10.1.9 YahooMailWebService/0.8.102.267879 Date: Wed, 14 Apr 2010 22:55:53 -0700 (PDT) From: Parav Pandit Subject: deriving MAC address from destination Link local address without Neighbor discovery To: ipv6@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii 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, 15 Apr 2010 05:57:13 -0000 Hi, As per RFC 2464, Link local address for Ethernet based interfaces are based on the EUI-64 (derived from the MAC address). I have #3 questions based on this. In this case, when one Ethernet based host(from its link-local source) tries to ping the other Ethernet based host, it knows the Mac address implicitly (from the Link local address). 1. Why is it required to explicitly do the Neighbor discovery for the link-local addresses? RFC 4861 says to do the neighbor discovery even for link-local addresses. Correct me if my understanding is incorrect. 2. Does it mean that in Ethernet networks, interface can have only one Link-local address? If not then we violate the RFC 2464. 3. Does RFC 4941 Privacy extension for autoconf apply to Ethernet interfaces? Regards, Parav Pandit From shengjiang@huawei.com Wed Apr 14 23:36:05 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 76E793A6AF5 for ; Wed, 14 Apr 2010 23:36:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.12 X-Spam-Level: X-Spam-Status: No, score=0.12 tagged_above=-999 required=5 tests=[AWL=0.315, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, MIME_8BIT_HEADER=0.3, 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 xUmjUT7Q2BuQ for ; Wed, 14 Apr 2010 23:36:04 -0700 (PDT) Received: from szxga02-in.huawei.com (unknown [119.145.14.65]) by core3.amsl.com (Postfix) with ESMTP id A03413A69E9 for ; Wed, 14 Apr 2010 23:36:00 -0700 (PDT) Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0L0W00KHLNNJPT@szxga02-in.huawei.com> for ipv6@ietf.org; Thu, 15 Apr 2010 14:35:43 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0L0W00NHXNNJ30@szxga02-in.huawei.com> for ipv6@ietf.org; Thu, 15 Apr 2010 14:35:43 +0800 (CST) Received: from j66104a ([10.111.12.115]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0L0W00D58NNJHT@szxml06-in.huawei.com> for ipv6@ietf.org; Thu, 15 Apr 2010 14:35:43 +0800 (CST) Date: Thu, 15 Apr 2010 14:35:42 +0800 From: Sheng Jiang Subject: RE: [Fwd: New Version Notification for draft-carpenter-6man-flow-update-02] In-reply-to: <4BC63A9D.5080200@gmail.com> To: 'Brian E Carpenter' , =?iso-8859-1?Q?'R=E9mi_Despr=E9s'?= Message-id: <003a01cadc65$df54e190$730c6f0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: quoted-printable Thread-index: AcrcHbCwopN90D1qQcSFDPwjYSNAiAARr1/w Cc: '6man' X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Apr 2010 06:36:05 -0000 Hi, Remi, Thanks for your summury. They are is quite right. I agree a new and simple document that obsolete RFC 3697 could be bette approach. Now, the urgency is to make sure the WG agrees on these proposed = changes. After than, how we move forward could also flow the WG's consensus. Cheers, Sheng > -----Original Message----- > From: Brian E Carpenter [mailto:brian.e.carpenter@gmail.com]=20 > Sent: Thursday, April 15, 2010 5:59 AM > To: R=E9mi Despr=E9s > Cc: Sheng Jiang; 6man > Subject: Re: [Fwd: New Version Notification for=20 > draft-carpenter-6man-flow-update-02] >=20 > R=E9mi, >=20 > Thanks for the analysis. Indeed, the conclusion may be,=20 > assuming the WG is interested at all, that a complete refresh=20 > of RFC 3697 is better than publishing a delta. >=20 > I agree that it is a bit complicated to explain, although the=20 > underlying concept is quite clear: allow local use of the=20 > flow label, but also enable global use. I also think we were=20 > too careful in RFC 3697 - if we had unambiguously recommended=20 > a pseudo-random label per flow, it might already be used for=20 > load balancing. (By the way, there will soon be an update of=20 > draft-carpenter-flow-ecmp, adding the LAG case and a second=20 > author, which I think will make the load balancing use case=20 > very clear.) >=20 > Thanks > Brian >=20 > On 2010-04-15 04:06, R=E9mi Despr=E9s wrote: > > Brian, Sheng, > >=20 > > I carefully read the draft, and read again RFC 3697 and=20 > draft-carpenter-6man-flow-update-02. > > The draft is IMHO overly hard to understand but, unless I=20 > misunderstand its intent (which is quite possible), I=20 > appreciate what it proposes. > > I do support the intent, but feel uncomfortable with how it=20 > is introduced. > >=20 > > In my understanding: > > A) The essential changes are: > > A1. Flow Labels MAY be changed within the network, instead=20 > of "MUST be delivered unchanged". > > A2. Nodes that set Flow Labels MAY apply local policies,=20 > including stateless ones, instead of "SHOULD select new Flow=20 > Label values in a well-defined sequence (e.g., sequential or=20 > pseudo-random". > > B) The essentials of what is kept are: > > B1. Where Flow Labels are set, their values MUST be the=20 > same for packets that have the same 5-tuples (or 3-tuples),=20 > and are separated by less than 120s.=20 > > B3. For flow-based routing optimization to be possible,=20 > Flow Labels should in general be given different values for=20 > different 5-tuples (or 3-tuples) that share the same=20 > source-address/destination-address couples.=20 > >=20 > > If this makes sense, I am convinced that it would be better=20 > to propose a clear and simple new RFC, and obsolete RFC 3697. > > Trying to complement RFC 3697 with what amounts to a=20 > significant change is in my understanding bond to be awkward. > >=20 > > Thoughts? > >=20 > > Kind regards, > > RD > > =20 > >=20 > >=20 > > Le 14 avr. 2010 =E0 06:48, Brian E Carpenter a =E9crit : > >=20 > >> Hi, > >> > >> This is completely revised from the proposal we presented=20 > in Anaheim.=20 > >> This version allows locally defined use of the flow label in a=20 > >> simpler way, as the discussion suggested. > >> It's still quite a dense read, but we believe that if this was=20 > >> adopted, it would open the way to actually using the flow label. > >> > >> Brian and Sheng > >> > >> -------- Original Message -------- > >> Subject: New Version Notification for=20 > >> draft-carpenter-6man-flow-update-02 > >> Date: Tue, 13 Apr 2010 21:44:42 -0700 (PDT) > >> From: IETF I-D Submission Tool > >> To: brian.e.carpenter@gmail.com > >> CC: shengjiang@huawei.com > >> > >> > >> A new version of I-D, draft-carpenter-6man-flow-update-02.txt has=20 > >> been successfully submitted by Brian Carpenter and posted=20 > to the IETF repository. > >> > >> Filename: draft-carpenter-6man-flow-update > >> Revision: 02 > >> Title: Update to the IPv6 flow label specification > >> Creation_date: 2010-04-13 > >> WG ID: Independent Submission > >> Number_of_pages: 10 > >> > >> Abstract: > >> Various uses proposed for the IPv6 flow label are=20 > incompatible with=20 > >> its existing specification. This document describes=20 > changes to the=20 > >> specification that permit additional use cases as well as allowing=20 > >> continued use of the previous specification. > >> > >> > >> > >> The IETF Secretariat. > >> > >> > >> > >>=20 > -------------------------------------------------------------------- > >> IETF IPv6 working group mailing list > >> ipv6@ietf.org > >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > >>=20 > -------------------------------------------------------------------- > >=20 > >=20 >=20 From fred@cisco.com Wed Apr 14 23:40:29 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 E63753A693D for ; Wed, 14 Apr 2010 23:40:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.758 X-Spam-Level: X-Spam-Status: No, score=-109.758 tagged_above=-999 required=5 tests=[AWL=0.241, BAYES_00=-2.599, J_CHICKENPOX_44=0.6, 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 cAb3OFpmGO04 for ; Wed, 14 Apr 2010 23:40:28 -0700 (PDT) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id AC2903A6816 for ; Wed, 14 Apr 2010 23:40:28 -0700 (PDT) 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: AvsEAChRxkurRN+J/2dsb2JhbACbYXGkD5obhQ4Egyk X-IronPort-AV: E=Sophos;i="4.52,211,1270425600"; d="scan'208";a="115516874" Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-4.cisco.com with ESMTP; 15 Apr 2010 06:40:22 +0000 Received: from stealth-10-32-244-222.cisco.com (stealth-10-32-244-222.cisco.com [10.32.244.222]) by sj-core-3.cisco.com (8.13.8/8.14.3) with ESMTP id o3F6eM9Q028771; Thu, 15 Apr 2010 06:40:22 GMT Subject: Re: deriving MAC address from destination Link local address without Neighbor discovery Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii From: Fred Baker In-Reply-To: <342102.44906.qm@web30104.mail.mud.yahoo.com> Date: Wed, 14 Apr 2010 23:40:21 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <06CAA304-70CC-4280-8A71-7C4D615E533A@cisco.com> References: <342102.44906.qm@web30104.mail.mud.yahoo.com> To: Parav Pandit X-Mailer: Apple Mail (2.1078) Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Apr 2010 06:40:30 -0000 There has been some water that passed under that bridge. They not only = come from MAC addresses, but from random number generators and = cryptographic algorithms - and can simply be numbers assigned by = administrators. In addition to 2464 Transmission of IPv6 Packets over Ethernet Networks. M. Crawford. December 1998. (Format: TXT=3D12725 bytes) (Obsoletes RFC1972) = (Status: PROPOSED STANDARD) take a look at http://www.ietf.org/rfc/rfc3315.txt 3315 Dynamic Host Configuration Protocol for IPv6 (DHCPv6). R. Droms, Ed., J. Bound, B. Volz, T. Lemon, C. Perkins, M. Carney. July 2003. (Format: TXT=3D231402 bytes) (Updated by RFC4361, RFC5494) (Status: PROPOSED STANDARD) http://www.ietf.org/rfc/rfc3972.txt 3972 Cryptographically Generated Addresses (CGA). T. Aura. March 2005. (Format: TXT=3D51473 bytes) (Updated by RFC4581, RFC4982) (Status: PROPOSED STANDARD) http://www.ietf.org/rfc/rfc4291.txt 4291 IP Version 6 Addressing Architecture. R. Hinden, S. Deering. February 2006. (Format: TXT=3D52897 bytes) (Obsoletes RFC3513) = (Status: DRAFT STANDARD) http://www.ietf.org/rfc/rfc4862.txt 4862 IPv6 Stateless Address Autoconfiguration. S. Thomson, T. Narten, T. Jinmei. September 2007. (Format: TXT=3D72482 bytes) (Obsoletes RFC2462) (Status: DRAFT STANDARD) http://www.ietf.org/rfc/rfc4941.txt 4941 Privacy Extensions for Stateless Address Autoconfiguration in IPv6. T. Narten, R. Draves, S. Krishnan. September 2007. (Format: TXT=3D56699 bytes) (Obsoletes RFC3041) (Status: DRAFT STANDARD) On Apr 14, 2010, at 10:55 PM, Parav Pandit wrote: > Hi, >=20 > As per RFC 2464, Link local address for Ethernet based interfaces are = based on the EUI-64 (derived from the MAC address). >=20 > I have #3 questions based on this. >=20 > In this case,=20 > when one Ethernet based host(from its link-local source) tries to ping = the other Ethernet based host, it knows the Mac address implicitly (from = the Link local address). >=20 > 1. Why is it required to explicitly do the Neighbor discovery for the = link-local addresses? > RFC 4861 says to do the neighbor discovery even for link-local = addresses. > Correct me if my understanding is incorrect. >=20 > 2. Does it mean that in Ethernet networks, interface can have only one = Link-local address? If not then we violate the RFC 2464. >=20 > 3. Does RFC 4941 Privacy extension for autoconf apply to Ethernet = interfaces? >=20 > Regards, > Parav Pandit >=20 >=20 >=20 >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- http://www.ipinc.net/IPv4.GIF From mohacsi@niif.hu Thu Apr 15 00:05:43 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 1F3403A6B4B for ; Thu, 15 Apr 2010 00:05:43 -0700 (PDT) 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 5j+DsO2hEfs4 for ; Thu, 15 Apr 2010 00:05:42 -0700 (PDT) Received: from mail.ki.iif.hu (mail.ki.iif.hu [IPv6:2001:738:0:411::241]) by core3.amsl.com (Postfix) with ESMTP id 2A93E3A6B5F for ; Thu, 15 Apr 2010 00:05:20 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mail.ki.iif.hu (Postfix) with ESMTP id 1B86D86D12; Thu, 15 Apr 2010 09:05:12 +0200 (CEST) X-Virus-Scanned: by amavisd-new at mignon.ki.iif.hu Received: from mail.ki.iif.hu ([127.0.0.1]) by localhost (mignon.ki.iif.hu [127.0.0.1]) (amavisd-new, port 10024) with LMTP id b7ZiN6HH2m6Y; Thu, 15 Apr 2010 09:05:06 +0200 (CEST) Received: by mail.ki.iif.hu (Postfix, from userid 9002) id 4595E86D02; Thu, 15 Apr 2010 09:05:06 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by mail.ki.iif.hu (Postfix) with ESMTP id 2CC7D86CD5; Thu, 15 Apr 2010 09:05:06 +0200 (CEST) Date: Thu, 15 Apr 2010 09:05:06 +0200 (CEST) From: Mohacsi Janos X-X-Sender: mohacsi@mignon.ki.iif.hu To: Brian E Carpenter Subject: Re: Extracting the 5-tuple from IPv6 packets In-Reply-To: <4BC64100.303@gmail.com> Message-ID: References: <4BC64100.303@gmail.com> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Cc: Nevil Brownlee , 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, 15 Apr 2010 07:05:43 -0000 On Thu, 15 Apr 2010, Brian E Carpenter wrote: > Hi, > > Common practice in network monitoring and in QoS technologies > is to identify a flow of packets by the 5-tuple > {source address, dest address, source port, dest port, protocol #}. > This is relatively trivial at line speed in IPv4 since > these things are at fixed locations in the header. I disagree. The source port and destination port is not in fixed location since IPv4 option might have variable lengths. > > Or we can strongly recommend that all hosts set the flow label, so > that we can use the 3-tuple {source address, dest address, flow label}. Agreed. We should avoid extension header porcessing at all price. Janos Mohacsi From shengjiang@huawei.com Thu Apr 15 00:09:02 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 C98453A6AF7 for ; Thu, 15 Apr 2010 00:09:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.187 X-Spam-Level: X-Spam-Status: No, score=-1.187 tagged_above=-999 required=5 tests=[AWL=1.412, 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 mpHR227-sOwe for ; Thu, 15 Apr 2010 00:09:01 -0700 (PDT) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id D6F6C3A6ABA for ; Thu, 15 Apr 2010 00:09:00 -0700 (PDT) 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 <0L0W001NXP3AH5@szxga03-in.huawei.com> for ipv6@ietf.org; Thu, 15 Apr 2010 15:06:46 +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 <0L0W00FSTP3AJP@szxga03-in.huawei.com> for ipv6@ietf.org; Thu, 15 Apr 2010 15:06:46 +0800 (CST) Received: from j66104a ([10.111.12.115]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0L0W00DPRP39HT@szxml06-in.huawei.com> for ipv6@ietf.org; Thu, 15 Apr 2010 15:06:46 +0800 (CST) Date: Thu, 15 Apr 2010 15:06:45 +0800 From: Sheng Jiang Subject: RE: [Fwd: New Version Notification fordraft-carpenter-6man-flow-update-02] In-reply-to: To: 'Shane Amante' , 'Brian E Carpenter' Message-id: <003b01cadc6a$3594d1b0$730c6f0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AcrcQQDt0oSCMOA8SaOe+pPiAqsFzAAJ9auQ Cc: '6man' X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Apr 2010 07:09:02 -0000 > -----Original Message----- > From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On > Behalf Of Shane Amante > Sent: Thursday, April 15, 2010 10:11 AM > To: Brian E Carpenter > Cc: 6man > Subject: Re: [Fwd: New Version Notification > fordraft-carpenter-6man-flow-update-02] > > Brian, Mark, > > Brian: FWIW, I like the direction of this version of draft > much better than previous versions; however, I agree with > Remi that the current version is a bit confusing at the > moment and could likely be rewritten to be more simple and > just obsolete RFC 3967. In addition, I'm still a bit unclear > and, therefore, uncomfortable on the proposal with respect to > flow-labels within an "administratively defined domain". In > particular, if one administrative domain has set their own > "locally defined" flow-label, I think the draft could benefit > from a stronger emphasis that the flow-label MUST or, at > least, SHOULD be reset to 0 upon /leaving/ that domain, > otherwise the next domain may (or, will?) misinterpret the > meaning of the incoming "locally-defined" flow-label. The > way I interpret the text in Bullet 3 of Section 3 seems > written in a way that is specific to packets entering domains > that are going to use locally-defined flow-labels, but not > how they must treat those same packets as th ey leave their > domain and, most importantly, need to interact with other > domains that don't understand or want to use a "standard" > definition of a flow-label, i.e.: in Bullets 1, 2 & 4. Or, > perhaps I'm misunderstanding something. Hi, Shane, I am fully with you. Actually, during our updating for 02 version, I talked with Brian, "whether we need a outbound router to set the router-modified flow label back to all-zero". By that time, we were considering the backwards compatible with RFC3976 "delivered the flow label unchanged". Therefore, we cannot change flow label on the outbound router because we cannot tell whether it is from hosts or routers. Now, we are talking about to obsolete 3967 totally, then reset flow label upon/leaving Flow Label domain would be quite reasonable. Cheers, Sheng > More below. > > On Apr 14, 2010, at 16:13 MDT, Brian E Carpenter wrote: > > Hi Mark, > > > > On 2010-04-15 09:59, Mark Smith wrote: > >> Hi Brian and Sheng, > >> > >> On Wed, 14 Apr 2010 16:48:25 +1200 > >> Brian E Carpenter wrote: > >> > >>> Hi, > >>> > >>> This is completely revised from the proposal we presented in > >>> Anaheim. This version allows locally defined use of the > flow label > >>> in a simpler way, as the discussion suggested. > >>> It's still quite a dense read, but we believe that if this was > >>> adopted, it would open the way to actually using the flow label. > >>> > >> > >> I've had a read through it, although not a comprehensive > one, which > >> I'll endeavour to do in the next day or so. > >> > >> I'm wondering about this change for a couple of reasons: > >> > >> -- > >> 2. If this is done, all packets in a given flow MUST be > given the > >> same flow label value. A flow is defined in this case as all > >> packets with the same source and destination IPv6 > addresses and > >> port numbers and the same transport protocol number, > i.e., the > >> same final Next Header value [RFC2460]. This rule > constrains the > >> definition of a flow in RFC 3697 for the specific case that a > >> router sets the flow label. However, it does not > constrain the > >> bits of the flow label in any particular way. > >> -- > >> > >> Firstly, if the IPv6 packets are fragments, the transport layer > >> header may not be available. I think that would mean that although > >> these packets fragments are part of a flow, they wouldn't > have their > >> flow label changed. > > > > Yes, certainly, if the router inserting the flow label is stateless. > > I honestly don't see a way round that and it's probably > better to list > > it as a limitation. It probably doesn't matter - anyone who is > > deploying a local scheme for the flow label is presumably > able to also > > deploy a non-fragmenting network. > > Actually, one would hope that implementations are actually > "smart" about fragments. Specifically, one could look for a > Fragment Header and, upon noticing it, mask out or exclude > Layer-4 transport information, (e.g.: protocol, source and > destination port) as input keys for, say, LAG or ECMP. This > means one would only consider the 2-tuple of source and > destination IP address, which is better than nothing, but > more importantly would still preserve ordering. > > > >> Secondly, for IPv6 packets with a number of extension > headers before > >> the transport layer header, I think this rule could impact > forwarding > >> performance. While I'm not sure if it is that practical, > however it'd > >> be good if flow classification could be done using only > fixed headers > >> in the IPv6 packet, or a fixed portion of the fixed header bits. > > > > I will send a separate message on that point. > > I wholeheartedly agree with Mark's point. I would add that > IPv6 Extension Headers may not impact forwarding performance > on PE interfaces, because they are [somewhat] high-touch > interfaces that typically must be capable of imposing various > 2- or 5-, or 6-tuple[1] classifiers on PE-CE interfaces for > applying ACL's (forward/drop), policing/rate-limiting or > marking (IPv6 TC field) functions. *However*, the same is > not true of P routers, which generally have several dozen > bleeding edge interfaces of 40G and 100G and beyond. Thus, > allowing P routers to more quickly access input keys to a LAG > or ECMP hash function is pretty critical. > > [1] 6-tuple if you include Traffic Class. > > > >> I suppose partly that comes down to what a 'flow' is. In some > >> contexts, it is definitely a transport layer connection. > In others, > >> e.g. an MPLS network, I think it could be seen to be all > packets that > >> match a Forwarding Equivalence Class. If it was possible > to use a FEC > >> to set the flow label, once the packet has traversed the MPLS > >> network, and the MPLS labels are stripped off, the flow label that > >> was set due to the FEC would be preserved, which might be > useful. Is > >> there an opportunity to make the definition of a flow a bit more > >> general, and then for allow for the choice of different packet > >> classification methods to be used to define a flow, based > on context > >> e.g. transport layer connection in some contexts, MPLS > FEC, QoS/Diff Serv classifiers etc. in others? > > > > And that's an even wider question. I'm inclined to duck it, or at > > least to assert that it's a much wider question than 6man > can tackle. > > Let's not duck ... not yet, anyway. :-) > > With respect to MPLS, there is the following, now expired, > draft which might be what you're looking for: > http://tools.ietf.org/html/draft-kompella-mpls-entropy-label-00 > ... however, there are some challenges with it, namely > handling Penultimate Hop Popping (PHP), which isn't discussed > in the draft, plus the fact that legacy HW certainly most > likely will not support pushing additional labels required to > insert an entropy-label. If you're interested in this draft, > I suggest we take if offline and/or to the MPLS list. > > That said, I would hope the use of an MPLS entropy label > might be avoided for IP over MPLS traffic and, instead, a > simpler approach would be to use (even in MPLS networks) just > the following as input-keys to LAG or ECMP: > - IPv6 source address; > - IPv6 destination address; and, > - A _proper_ IPv6 flow-label that unambiguously identifies an > underlying "flow" > ... without needing to seek out Transport layer info. > > I believe it would be an implementation detail as to what > IPv6 header fields a vendor would allow to be included as > input-keys to a hash that would be calculated and put into a > IPv6 flow-label. Although, certainly I would hope we could > insist on a minimum of the 2-tuple and "recommend" that they > include the more valuable the 5- or 6-tuple as input-keys to > the hash algorithm for the flow-label. > > -shane > > > > > > > Brian > >> > >> Regards, > >> Mark. > >> > >> > >> > >> > >> > >> > >>> Brian and Sheng > >>> > >>> -------- Original Message -------- > >>> Subject: New Version Notification for > >>> draft-carpenter-6man-flow-update-02 > >>> Date: Tue, 13 Apr 2010 21:44:42 -0700 (PDT) > >>> From: IETF I-D Submission Tool > >>> To: brian.e.carpenter@gmail.com > >>> CC: shengjiang@huawei.com > >>> > >>> > >>> A new version of I-D, draft-carpenter-6man-flow-update-02.txt has > >>> been successfully submitted by Brian Carpenter and posted > to the IETF repository. > >>> > >>> Filename: draft-carpenter-6man-flow-update > >>> Revision: 02 > >>> Title: Update to the IPv6 flow label specification > >>> Creation_date: 2010-04-13 > >>> WG ID: Independent Submission > >>> Number_of_pages: 10 > >>> > >>> Abstract: > >>> Various uses proposed for the IPv6 flow label are > incompatible with > >>> its existing specification. This document describes > changes to the > >>> specification that permit additional use cases as well as > allowing > >>> continued use of the previous specification. > >>> > >>> > >>> > >>> The IETF Secretariat. > >>> > >>> > >>> > >>> > -------------------------------------------------------------------- > >>> 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 > > -------------------------------------------------------------------- > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From paravpandit@yahoo.com Thu Apr 15 00:25:10 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 D803F3A6B65 for ; Thu, 15 Apr 2010 00:25:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.332 X-Spam-Level: X-Spam-Status: No, score=-1.332 tagged_above=-999 required=5 tests=[AWL=0.667, BAYES_00=-2.599, J_CHICKENPOX_44=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 s9jynaJf0Krp for ; Thu, 15 Apr 2010 00:25:08 -0700 (PDT) Received: from web30108.mail.mud.yahoo.com (web30108.mail.mud.yahoo.com [209.191.69.40]) by core3.amsl.com (Postfix) with SMTP id BF9983A6B71 for ; Thu, 15 Apr 2010 00:23:53 -0700 (PDT) Received: (qmail 69574 invoked by uid 60001); 15 Apr 2010 07:23:45 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1271316224; bh=s8k/5S+yOxcdfg8Ds9V5QlOP98ZzHxhvSOCzsB/7syk=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=I/pvpCEoGdOunx1w35MV3On3d48A2z/0bXvVmzVNPROAqMWLhi8ukqKwmSsW4O5TmcvC+W7GNVWjYl2o0dz7wpQdcJPbpwzVi+uSmsu6K6tbCHAWF2qYqiViraFlNHM1pYolT3nxmgxFOkr6sm0zhmNhs2qI4BKkawElNOSbaXU= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=vFVIgXsi//MD5lyGEp0u3xmCKno1T+WRoqPZs8tHQihvpzSObmFS2qKdVnOHZW+bBOcuo9gC9+q+vPkzNVtsg9AOkQabmAfe8FYzYknadg6Puv+5VUPjqnXBXgPLtoZg6zjYNerjZae1nha2HzprrmUZPKiFy+Fvd4koBECpk8M=; Message-ID: <922306.68350.qm@web30108.mail.mud.yahoo.com> X-YMail-OSG: udpRtdUVM1lMWziJjMHZHIoEvwOIFKKArhFlve.klTbGhFl YvY1YTmbMmQjBdl.9zIvzIh2yMcI4i1_.4BjLgGOrz.NUyvLlqB4PMtFK29h I5._sMKHTm4v4IuRvMJqw05.9eM67e1HdzDkq6UoYuDmhdsDSeYj187CLR7M BSVJ.0wpiIWsxkKcxN1aleO1a0COWCHBfS6yk585EDDTxMavuwVTot7mhhqj 14JpYS2VjO_FueeJAxjagUEleJ7EKb.mnOr76636CYl7bvyoRN9PlGB_F8_6 KzZ6POShGqSnDJ88rxIUFsFh.BA9z5lfW4LNem8MK6sB3kv5mrGM6Y9G78Tc eyhZSKA-- Received: from [111.93.130.139] by web30108.mail.mud.yahoo.com via HTTP; Thu, 15 Apr 2010 00:23:44 PDT X-Mailer: YahooMailClassic/10.1.9 YahooMailWebService/0.8.102.267879 Date: Thu, 15 Apr 2010 00:23:44 -0700 (PDT) From: Parav Pandit Subject: Re: deriving MAC address from destination Link local address without Neighbor discovery To: Fred Baker In-Reply-To: <06CAA304-70CC-4280-8A71-7C4D615E533A@cisco.com> MIME-Version: 1.0 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: Thu, 15 Apr 2010 07:25:10 -0000 Hi Fred,=0A=0AIn your reply,=0A> They not only come from MAC addresses, but= from random number =0A> generators...=0A=0AI didn't understand "They" appl= y to 64-bit of link_local address or =0A64-bit of autoconf/dhcp address or = both?=0A=0AWhat I understood is: =0ARFC 3972 contradicts with RFC 2464.=0A= =0AOr both the methods are correct for ETHERNET for Link-local and autoconf= addresses?=0A=0ARFC 4291 asks to refer the Link layer specific RFC for the= 64-bit Interface Id of the link-local address - which is 2464 (for Etherne= t).=0A=0ASo thats the confusion I have.=0A=0AOr =0Athe RFC 3972 doesn't app= ly to the 64-bits of the Link-local addresses, but it applies to 64-bit of = the addresses configured via DHCPv6=0Aand/or stateless auto-conf RFCs 3315,= 4862?=0A=0ARegards,=0AParav Pandit=0A=0A--- On Thu, 4/15/10, Fred Baker wrote:=0A=0A> From: Fred Baker =0A> Subject:= Re: deriving MAC address from destination Link local address without Neigh= bor discovery=0A> To: "Parav Pandit" =0A> Cc: ipv6@i= etf.org=0A> Date: Thursday, April 15, 2010, 12:10 PM=0A> There has been som= e water that passed=0A> under that bridge. They not only come from MAC addr= esses,=0A> but from random number generators and cryptographic=0A> algorith= ms - and can simply be numbers assigned by=0A> administrators.=0A> =0A> In = addition to=0A> =0A> 2464 Transmission of IPv6 Packets over Ethernet Networ= ks.=0A> M. Crawford.=0A> =A0 =A0=A0=A0December 1998. (Format: TXT=3D12725= =0A> bytes) (Obsoletes RFC1972) (Status:=0A> =A0 =A0=A0=A0PROPOSED STANDARD= )=0A> =0A> take a look at=0A> =0A> http://www.ietf.org/rfc/rfc3315.txt=0A> = 3315 Dynamic Host Configuration Protocol for IPv6 (DHCPv6).=0A> R. Droms,= =0A> =A0 =A0=A0=A0Ed., J. Bound, B. Volz, T. Lemon,=0A> C. Perkins, M. Carn= ey. July 2003.=0A> =A0 =A0=A0=A0(Format: TXT=3D231402 bytes)=0A> (Updated b= y RFC4361, RFC5494) (Status:=0A> =A0 =A0=A0=A0PROPOSED STANDARD)=0A> =0A> h= ttp://www.ietf.org/rfc/rfc3972.txt=0A> 3972 Cryptographically Generated Add= resses (CGA). T. Aura.=0A> March 2005.=0A> =A0 =A0=A0=A0(Format: TXT=3D5147= 3 bytes) (Updated=0A> by RFC4581, RFC4982) (Status:=0A> =A0 =A0=A0=A0PROPOS= ED STANDARD)=0A> =0A> http://www.ietf.org/rfc/rfc4291.txt=0A> 4291 IP Versi= on 6 Addressing Architecture. R. Hinden, S.=0A> Deering.=0A> =A0 =A0=A0=A0F= ebruary 2006. (Format: TXT=3D52897=0A> bytes) (Obsoletes RFC3513) (Status:= =0A> =A0 =A0=A0=A0DRAFT STANDARD)=0A> =0A> http://www.ietf.org/rfc/rfc4862.= txt=0A> 4862 IPv6 Stateless Address Autoconfiguration. S. Thomson,=0A> T. N= arten,=0A> =A0 =A0=A0=A0T. Jinmei. September 2007.=0A> (Format: TXT=3D72482= bytes) (Obsoletes=0A> =A0 =A0=A0=A0RFC2462) (Status: DRAFT STANDARD)=0A> = =0A> http://www.ietf.org/rfc/rfc4941.txt=0A> 4941 Privacy Extensions for St= ateless Address=0A> Autoconfiguration in=0A> =A0 =A0=A0=A0IPv6. T. Narten, = R. Draves, S.=0A> Krishnan. September 2007. (Format:=0A> =A0 =A0=A0=A0TXT= =3D56699 bytes) (Obsoletes=0A> RFC3041) (Status: DRAFT STANDARD)=0A> =0A> = =0A> On Apr 14, 2010, at 10:55 PM, Parav Pandit wrote:=0A> =0A> > Hi,=0A> >= =0A> > As per RFC 2464, Link local address for Ethernet based=0A> interfac= es are based on the EUI-64 (derived from the MAC=0A> address).=0A> > =0A> >= I have #3 questions based on this.=0A> > =0A> > In this case, =0A> > when = one Ethernet based host(from its link-local=0A> source) tries to ping the o= ther Ethernet based host, it=0A> knows the Mac address implicitly (from the= Link local=0A> address).=0A> > =0A> > 1. Why is it required to explicitly = do the Neighbor=0A> discovery for the link-local addresses?=0A> > RFC 4861 = says to do the neighbor discovery even for=0A> link-local addresses.=0A> > = Correct me if my understanding is incorrect.=0A> > =0A> > 2. Does it mean t= hat in Ethernet networks, interface=0A> can have only one Link-local addres= s? If not then we violate=0A> the RFC 2464.=0A> > =0A> > 3. Does RFC 4941 P= rivacy extension for autoconf apply=0A> to Ethernet interfaces?=0A> > =0A> = > Regards,=0A> > Parav Pandit=0A> > =0A> > =0A> > =0A> > =0A> >=0A> -------= -------------------------------------------------------------=0A> > IETF IP= v6 working group mailing list=0A> > ipv6@ietf.org=0A> > Administrative Requ= ests: https://www.ietf.org/mailman/listinfo/ipv6=0A> >=0A> ----------------= ----------------------------------------------------=0A> =0A> http://www.ip= inc.net/IPv4.GIF=0A> =0A> =0A=0A=0A From remi.despres@free.fr Thu Apr 15 00:35:47 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 36D503A6AE3 for ; Thu, 15 Apr 2010 00:35:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.603 X-Spam-Level: X-Spam-Status: No, score=-0.603 tagged_above=-999 required=5 tests=[AWL=1.346, 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 k7JJdpVxiakC for ; Thu, 15 Apr 2010 00:35:46 -0700 (PDT) Received: from smtp6-g21.free.fr (smtp6-g21.free.fr [212.27.42.6]) by core3.amsl.com (Postfix) with ESMTP id EB0BF3A6941 for ; Thu, 15 Apr 2010 00:35:44 -0700 (PDT) Received: from smtp6-g21.free.fr (localhost [127.0.0.1]) by smtp6-g21.free.fr (Postfix) with ESMTP id 55A99E08119; Thu, 15 Apr 2010 09:35:33 +0200 (CEST) Received: from [192.168.0.13] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by smtp6-g21.free.fr (Postfix) with ESMTP id 270FEE0817C; Thu, 15 Apr 2010 09:35:31 +0200 (CEST) Subject: Re: [Fwd: New Version Notification for draft-carpenter-6man-flow-update-02] Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: <003a01cadc65$df54e190$730c6f0a@china.huawei.com> Date: Thu, 15 Apr 2010 09:35:30 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <3BA35874-EF14-4D63-A692-A5E76D2A00C1@free.fr> References: <003a01cadc65$df54e190$730c6f0a@china.huawei.com> To: Sheng Jiang X-Mailer: Apple Mail (2.1078) 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: Thu, 15 Apr 2010 07:35:47 -0000 Le 15 avr. 2010 =E0 08:35, Sheng Jiang a =E9crit : > Hi, Remi, >=20 > Thanks for your summury. They are is quite right. >=20 > I agree a new and simple document that obsolete RFC 3697 could be = bette > approach. >=20 > Now, the urgency is to make sure the WG agrees on these proposed = changes. > After than, how we move forward could also flow the WG's consensus. The (rare) expressed opinions are so far favorable to the change but, = yes, more time to collect more opinions is appropriate. Cheers, RD >=20 > Cheers, >=20 > Sheng >=20 >> -----Original Message----- >> From: Brian E Carpenter [mailto:brian.e.carpenter@gmail.com]=20 >> Sent: Thursday, April 15, 2010 5:59 AM >> To: R=E9mi Despr=E9s >> Cc: Sheng Jiang; 6man >> Subject: Re: [Fwd: New Version Notification for=20 >> draft-carpenter-6man-flow-update-02] >>=20 >> R=E9mi, >>=20 >> Thanks for the analysis. Indeed, the conclusion may be,=20 >> assuming the WG is interested at all, that a complete refresh=20 >> of RFC 3697 is better than publishing a delta. >>=20 >> I agree that it is a bit complicated to explain, although the=20 >> underlying concept is quite clear: allow local use of the=20 >> flow label, but also enable global use. I also think we were=20 >> too careful in RFC 3697 - if we had unambiguously recommended=20 >> a pseudo-random label per flow, it might already be used for=20 >> load balancing. (By the way, there will soon be an update of=20 >> draft-carpenter-flow-ecmp, adding the LAG case and a second=20 >> author, which I think will make the load balancing use case=20 >> very clear.) >>=20 >> Thanks >> Brian >>=20 >> On 2010-04-15 04:06, R=E9mi Despr=E9s wrote: >>> Brian, Sheng, >>>=20 >>> I carefully read the draft, and read again RFC 3697 and=20 >> draft-carpenter-6man-flow-update-02. >>> The draft is IMHO overly hard to understand but, unless I=20 >> misunderstand its intent (which is quite possible), I=20 >> appreciate what it proposes. >>> I do support the intent, but feel uncomfortable with how it=20 >> is introduced. >>>=20 >>> In my understanding: >>> A) The essential changes are: >>> A1. Flow Labels MAY be changed within the network, instead=20 >> of "MUST be delivered unchanged". >>> A2. Nodes that set Flow Labels MAY apply local policies,=20 >> including stateless ones, instead of "SHOULD select new Flow=20 >> Label values in a well-defined sequence (e.g., sequential or=20 >> pseudo-random". >>> B) The essentials of what is kept are: >>> B1. Where Flow Labels are set, their values MUST be the=20 >> same for packets that have the same 5-tuples (or 3-tuples),=20 >> and are separated by less than 120s.=20 >>> B3. For flow-based routing optimization to be possible,=20 >> Flow Labels should in general be given different values for=20 >> different 5-tuples (or 3-tuples) that share the same=20 >> source-address/destination-address couples.=20 >>>=20 >>> If this makes sense, I am convinced that it would be better=20 >> to propose a clear and simple new RFC, and obsolete RFC 3697. >>> Trying to complement RFC 3697 with what amounts to a=20 >> significant change is in my understanding bond to be awkward. >>>=20 >>> Thoughts? >>>=20 >>> Kind regards, >>> RD >>>=20 >>>=20 >>>=20 >>> Le 14 avr. 2010 =E0 06:48, Brian E Carpenter a =E9crit : >>>=20 >>>> Hi, >>>>=20 >>>> This is completely revised from the proposal we presented=20 >> in Anaheim.=20 >>>> This version allows locally defined use of the flow label in a=20 >>>> simpler way, as the discussion suggested. >>>> It's still quite a dense read, but we believe that if this was=20 >>>> adopted, it would open the way to actually using the flow label. >>>>=20 >>>> Brian and Sheng >>>>=20 >>>> -------- Original Message -------- >>>> Subject: New Version Notification for=20 >>>> draft-carpenter-6man-flow-update-02 >>>> Date: Tue, 13 Apr 2010 21:44:42 -0700 (PDT) >>>> From: IETF I-D Submission Tool >>>> To: brian.e.carpenter@gmail.com >>>> CC: shengjiang@huawei.com >>>>=20 >>>>=20 >>>> A new version of I-D, draft-carpenter-6man-flow-update-02.txt has=20= >>>> been successfully submitted by Brian Carpenter and posted=20 >> to the IETF repository. >>>>=20 >>>> Filename: draft-carpenter-6man-flow-update >>>> Revision: 02 >>>> Title: Update to the IPv6 flow label specification >>>> Creation_date: 2010-04-13 >>>> WG ID: Independent Submission >>>> Number_of_pages: 10 >>>>=20 >>>> Abstract: >>>> Various uses proposed for the IPv6 flow label are=20 >> incompatible with=20 >>>> its existing specification. This document describes=20 >> changes to the=20 >>>> specification that permit additional use cases as well as allowing=20= >>>> continued use of the previous specification. >>>>=20 >>>>=20 >>>>=20 >>>> The IETF Secretariat. >>>>=20 >>>>=20 >>>>=20 >>>>=20 >> -------------------------------------------------------------------- >>>> IETF IPv6 working group mailing list >>>> ipv6@ietf.org >>>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >>>>=20 >> -------------------------------------------------------------------- >>>=20 >>>=20 >>=20 >=20 From alexandru.petrescu@gmail.com Thu Apr 15 02:14:51 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 669E33A692A for ; Thu, 15 Apr 2010 02:14:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[AWL=0.338, BAYES_00=-2.599, HELO_EQ_FR=0.35] 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 Ddj23Ya0TLwS for ; Thu, 15 Apr 2010 02:14:50 -0700 (PDT) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.166.172.107]) by core3.amsl.com (Postfix) with ESMTP id D690A3A6B4E for ; Thu, 15 Apr 2010 02:14:40 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.0) with ESMTP id o3F9EWC9015995 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 15 Apr 2010 11:14:32 +0200 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id o3F9EWO1013830; Thu, 15 Apr 2010 11:14:32 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.133.173]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id o3F9EVR1029443; Thu, 15 Apr 2010 11:14:32 +0200 Message-ID: <4BC6D8F7.1030205@gmail.com> Date: Thu, 15 Apr 2010 11:14:31 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: Brian E Carpenter Subject: Re: MEXT Flow IDs, ROLL mutable Flow Labels and draft-carpenter-6man-flow-update-02 (was: [Fwd: I-D Action:draft-carpenter-6man-flow-update-00.txt]) References: <4B7CB52D.20902@gmail.com> <4BC5F981.2080101@gmail.com> <4BC638CC.6020407@gmail.com> In-Reply-To: <4BC638CC.6020407@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Apr 2010 09:14:51 -0000 Le 14/04/2010 23:51, Brian E Carpenter a écrit : > Alexandru, > >> I find this proposal to change the Flow Label behaviour to come in >> too early, at a point where we don't yet have widespread use of >> simple Flow Labels (or is it widely used?). > > But that's the problem. If you have read the -02 draft, you will > understand that flow label usage today is essentially non-existent. Ok, it is draft-carpenter-6man-flow-update-02 and I will comment on it separately. > Usage is not going to occur unless we make it desirable - and it's > quite clear that RFC 3697 did not succeed in making it desirable. So > either we do something, or we continue to carry 20 useless bits in > every IPv6 packet. I mainly agree to make Flow Labels desirable. Towards that end one would consider two other cases where Flow Labels were considered: - MEXT' WG draft-ietf-mext-flow-binding-06 "Flow Bindings in Mobile IPv6 and NEMO Basic Support"; - ROLL WG's intention of use of Flow Labels in RPL protocol draft-ietf-roll-rpl-07. Currently their way of considering flows and Flow Labels respectively is incoherent with old Flow Labels - and with new Flow Labels too. Or probably are they about to get in synch(?). Why has MEXT WG defined a new flow id instead of reusing the IPv6 Flow Label? Is it because of security? The new 6MAN Flow Labels don't improve on security, they're still uncovered by IPsec. Why has ROLL WG looked at mutable Flow Labels? Is it to change it enroute and restore it when getting out of the flow label domain? The new flow labels don't seem to impose the restoration, in my reading. Are the new Flow Labels better adapted to MEXT and to ROLL? Alex > > Please forget the -00 and -01 drafts, they were completely overtaken > by the discussion at IETF77. > > Regards Brian > > On 2010-04-15 05:21, Alexandru Petrescu wrote: >> Hi, I came across this draft coming from the ROLL space where a >> proposal exists to use the Flow Label changed enroute maybe. >> >> Besides the fact that I find ROLL use of such spec of 6MAN not >> being ready, i.e. in its infance (I will suggest that to the ROLL >> WG), I have a general comment here in 6MAN. >> >> Modifying a field of an IP packet "en-route" is something which >> comes with a price tag: obviously slower. Generally speaking >> writing takes much longer than reading. >> >> I find this proposal to change the Flow Label behaviour to come in >> too early, at a point where we don't yet have widespread use of >> simple Flow Labels (or is it widely used?). >> >> I wouldn't touch on any IP field enroute... there exist already >> exceptions allowing to touch enroute and they're not widely used >> either (RH, HbH, etc.) >> >> Alex >> >> Le 18/02/2010 04:34, Brian E Carpenter a écrit : >>> Hi, >>> >>> This may seem a bit unexpected, but after working on >>> draft-carpenter-flow-ecmp (just updated) and working with my >>> student Qinwen Hu on some aspects of the flow label, it seemed >>> like time for another look at the flow label standard, and Sheng >>> Jiang was having similar thoughts. >>> >>> We'd like to discuss this in Anaheim if possible. >>> >>> Brian >>> >>> -------- Original Message -------- Subject: I-D >>> Action:draft-carpenter-6man-flow-update-00.txt Date: Wed, 17 Feb >>> 2010 18:15:02 -0800 (PST) From: Internet-Drafts@ietf.org >>> Reply-To: internet-drafts@ietf.org To: i-d-announce@ietf.org >>> >>> A New Internet-Draft is available from the on-line >>> Internet-Drafts directories. >>> >>> Title : Update to the IPv6 flow label specification >>> Author(s) : B. Carpenter, S. Jiang Filename : >>> draft-carpenter-6man-flow-update-00.txt Pages : 9 Date >>> : 2010-02-17 >>> >>> Various uses proposed for the IPv6 flow label are incompatible >>> with its existing specification. This document describes >>> changes to the specification that permit additional use cases as >>> well as allowing continued use of the previous specification. >>> >>> A URL for this Internet-Draft is: >>> >> http://www.ietf.org/internet-drafts/draft-carpenter-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 alexandru.petrescu@gmail.com Thu Apr 15 02:19:34 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 92D303A695B for ; Thu, 15 Apr 2010 02:19:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.937 X-Spam-Level: X-Spam-Status: No, score=-1.937 tagged_above=-999 required=5 tests=[AWL=0.312, BAYES_00=-2.599, HELO_EQ_FR=0.35] 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 dtChPSOZT2wL for ; Thu, 15 Apr 2010 02:19:33 -0700 (PDT) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.166.172.106]) by core3.amsl.com (Postfix) with ESMTP id A9BB83A68CC for ; Thu, 15 Apr 2010 02:19:27 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.0) with ESMTP id o3F9JEQb005983 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 15 Apr 2010 11:19:14 +0200 Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id o3F9JDS6015383; Thu, 15 Apr 2010 11:19:13 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.133.173]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id o3F9JDGI025889; Thu, 15 Apr 2010 11:19:13 +0200 Message-ID: <4BC6DA10.4020002@gmail.com> Date: Thu, 15 Apr 2010 11:19:12 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: Philip Levis Subject: Re: RPL and Flow Labels (was: [Fwd: I-D Action:draft-carpenter-6man-flow-update-00.txt]) References: <4B7CB52D.20902@gmail.com> <4BC5F981.2080101@gmail.com> <4BC6428A.9030808@gmail.com> <9AE44546-DECD-4686-A346-88B0A58EB25E@cs.stanford.edu> In-Reply-To: <9AE44546-DECD-4686-A346-88B0A58EB25E@cs.stanford.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Apr 2010 09:19:34 -0000 Le 15/04/2010 05:18, Philip Levis a écrit : > > On Apr 14, 2010, at 3:32 PM, Alexandru Petrescu wrote: > >> Le 14/04/2010 22:23, Philip Levis a écrit : >>> >>> On Apr 14, 2010, at 10:21 AM, Alexandru Petrescu wrote: >>> >>>> Hi, I came across this draft coming from the ROLL space where a >>>> proposal exists to use the Flow Label changed enroute maybe. >>> >>> Alex, >>> >>> I think you're misrepresenting ROLL here, even though (after your >>> objections there) the use of the flow label was very clearly >>> described a few days ago. Changing the flow label enroute is not >>> on the table in ROLL; it was a while ago as a crazy idea, then >>> everyone realized the issues it would create. >> >> Sorry for misunderstanding... >> >> (only a day ago it was stated in ROLL list that changing the flow >> label enroute is possible as long as it is restored...) > > Sure, it's possible, that doesn't mean RPL is going to do it. Doing > so requires having somewhere in the packet to store the original > value, which necessitates a header; if there's a header, there's no > point in changing the flow label. It's my understanding there are > some proposals out there for doing this, but in other domains -- > this was mentioned at the mike in Hiroshima -- but that by no means > indicates RPL will. Ok, this is a discussion about intentions. I am not aware of the discussions in Hiroshima and intentions of future text, thanks for having clarified this. The current text in the RPL 07 draft says bit O oh of Flow Label set to 0 zero by Host and reset and set again by several intermediary routers. I guess this text will change. Alex > > Phil From alexandru.petrescu@gmail.com Thu Apr 15 02:31:28 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 9B5643A69CA for ; Thu, 15 Apr 2010 02:31:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.659 X-Spam-Level: X-Spam-Status: No, score=-1.659 tagged_above=-999 required=5 tests=[AWL=-0.010, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_44=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 XIATt2WrmhV3 for ; Thu, 15 Apr 2010 02:31:27 -0700 (PDT) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.166.172.107]) by core3.amsl.com (Postfix) with ESMTP id 71C3B3A6948 for ; Thu, 15 Apr 2010 02:31:26 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.0) with ESMTP id o3F9VJ5L030807 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 15 Apr 2010 11:31:19 +0200 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id o3F9VIXg019727; Thu, 15 Apr 2010 11:31:18 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.133.173]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id o3F9VIvg005251; Thu, 15 Apr 2010 11:31:18 +0200 Message-ID: <4BC6DCE6.80706@gmail.com> Date: Thu, 15 Apr 2010 11:31:18 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: Parav Pandit Subject: Re: deriving MAC address from destination Link local address without Neighbor discovery References: <342102.44906.qm@web30104.mail.mud.yahoo.com> In-Reply-To: <342102.44906.qm@web30104.mail.mud.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: Ipv 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, 15 Apr 2010 09:31:28 -0000 Le 15/04/2010 07:55, Parav Pandit a écrit : > Hi, > > As per RFC 2464, Link local address for Ethernet based interfaces > are based on the EUI-64 (derived from the MAC address). Right, that is probably a very widespread way of how the link local addresses are derived from a MAC address. There are many other ways, for example link negotiation with PPP IPv6 which for interfaces not having MAC addresses, like a 3G phone... and knowing that 3G IPv6 handheld computers (watches, phones, pdas, pads, netbooks) are potentially very numerous one may think it could be as widespread as the first. For these, deriving the MAC address from the link-local address (w/o doing ND) - will not work. A case that comes to mind is 6LoWPAN's _some_ version of "6LoWPAN Neighbor Discovery" which requires the end node to do just that: derive the MAC address from the LL address. I believe this intention wrongly aimed. One shoudl try to identify why would one need to reversely derive the MAC address from the LL address of some neighbor? Is it to save messages? We can discuss that and see that sometimes it's not needed to save, better use point-to-point links. Why do you need to do this message-less reverse resolution? > I have #3 questions based on this. > > In this case, when one Ethernet based host(from its link-local > source) tries to ping the other Ethernet based host, it knows the > Mac address implicitly (from the Link local address). In this case, if the problem is ping then the solution may be "ping -I iface" (-I specifies the outgoing interface). > 1. Why is it required to explicitly do the Neighbor discovery for > the link-local addresses? RFC 4861 says to do the neighbor discovery > even for link-local addresses. Correct me if my understanding is > incorrect. IMHO, one aspect is that it requires so in order to have the most up to date info about the other node. Sometimes nodes change their LLs and their MAC addresses (ifconfig does that). > 2. Does it mean that in Ethernet networks, interface can have only > one Link-local address? If not then we violate the RFC 2464. I think I can do "ifconfig eth0 add fe80::1/64; ifconfig eth0 add fe80::2/64; echo $?" and see success, I suppose - have you tried? > 3. Does RFC 4941 Privacy extension for autoconf apply to Ethernet > interfaces? Well yes I believe so, I suppose I have it running on my PC right now. Alex > > Regards, Parav Pandit > > > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list ipv6@ietf.org Administrative > Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > From ipng@69706e6720323030352d30312d31340a.nosense.org Thu Apr 15 02:47:03 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 C4C123A6941 for ; Thu, 15 Apr 2010 02:47:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.611 X-Spam-Level: X-Spam-Status: No, score=-1.611 tagged_above=-999 required=5 tests=[AWL=0.284, 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 q3aXuuFtGZYd for ; Thu, 15 Apr 2010 02:47:03 -0700 (PDT) Received: from smtp3.adam.net.au (smtp3.adam.net.au [202.136.110.249]) by core3.amsl.com (Postfix) with ESMTP id 22D263A6943 for ; Thu, 15 Apr 2010 02:47:00 -0700 (PDT) Received: from 219-90-234-216.ip.adam.com.au ([219.90.234.216] helo=opy.nosense.org) by smtp3.adam.net.au with esmtp (Exim 4.63) (envelope-from ) id 1O2Leu-0005vf-Ku; Thu, 15 Apr 2010 19:16:52 +0930 Received: from opy.nosense.org (localhost.localdomain [IPv6:::1]) by opy.nosense.org (Postfix) with ESMTP id 6752D4922D; Thu, 15 Apr 2010 19:16:49 +0930 (CST) Date: Thu, 15 Apr 2010 19:16:48 +0930 From: Mark Smith To: Brian E Carpenter , 6man Subject: Re: [Fwd: New Version Notification for draft-carpenter-6man-flow-update-02] Message-ID: <20100415191648.13efcb8d@opy.nosense.org> In-Reply-To: <4BC63DF0.6070707@gmail.com> References: <4BC54919.3000900@gmail.com> <20100415072936.60eb08ac@opy.nosense.org> <4BC63DF0.6070707@gmail.com> X-Mailer: Claws Mail 3.7.5 (GTK+ 2.20.0; 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 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, 15 Apr 2010 09:47:03 -0000 Hi Brian, On Thu, 15 Apr 2010 10:13:04 +1200 Brian E Carpenter wrote: > Hi Mark, > > On 2010-04-15 09:59, Mark Smith wrote: > > Hi Brian and Sheng, > > > > On Wed, 14 Apr 2010 16:48:25 +1200 > > Brian E Carpenter wrote: > > > >> Hi, > >> > > > > I suppose partly that comes down to what a 'flow' is. In some contexts, > > it is definitely a transport layer connection. In others, e.g. an MPLS > > network, I think it could be seen to be all packets that match a > > Forwarding Equivalence Class. If it was possible to use a FEC to set > > the flow label, once the packet has traversed the MPLS network, and the > > MPLS labels are stripped off, the flow label that was set due to the > > FEC would be preserved, which might be useful. Is there an opportunity > > to make the definition of a flow a bit more general, and then for allow > > for the choice of different packet classification methods to be used to > > define a flow, based on context e.g. transport layer connection in some > > contexts, MPLS FEC, QoS/Diff Serv classifiers etc. in others? > > And that's an even wider question. I'm inclined to duck it, or at > least to assert that it's a much wider question than 6man can tackle. > Are you generally trying to avoid it because it would appear to be an implied IETF definition of a flow, rather than just the IPv6 definition? Or is it to avoid having to start defining the a possibly large set of flow definitions? I think that as the field is an IPv6 one, IPv6 can have a position on what it considers a flow to be. I had a bit of a think about a more general definition of what a flow is and came up with this: "a set of packets that have a common attribute, or common relationship with another entity" with common attribute being things like field (single or multiple ) values, optional fields (e.g. a set of extension headers), same result of a hash of fields etc. A common relationship might be the same MPLS FEC, BGP NEXT_HOP, router incoming interface, destination AS etc. Looking at the definitions of flows in the IPv6 RFC, and in RFC3697, I think the above general definition would encompass those as well. If that was an acceptable general definition, then this draft could also then define one specific instance of a flow definition, namely the fields used to identify a transport layer connection, and state that other instances of applicable flow definitions may be defined in other RFCs, including non-IPv6 ones. Regards, Mark. From paravpandit@yahoo.com Thu Apr 15 02:53:22 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 515F73A6B7C for ; Thu, 15 Apr 2010 02:53:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.754 X-Spam-Level: X-Spam-Status: No, score=-0.754 tagged_above=-999 required=5 tests=[AWL=-0.244, BAYES_05=-1.11, J_CHICKENPOX_44=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 bXTNpXaSO6SQ for ; Thu, 15 Apr 2010 02:53:21 -0700 (PDT) Received: from web30105.mail.mud.yahoo.com (web30105.mail.mud.yahoo.com [209.191.69.37]) by core3.amsl.com (Postfix) with SMTP id DD95D3A6B7D for ; Thu, 15 Apr 2010 02:53:16 -0700 (PDT) Received: (qmail 28640 invoked by uid 60001); 15 Apr 2010 09:53:10 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1271325190; bh=n6i1c5w7MevKq6e1rkuviNzeLddGJz80BG3Aq9p+z1Y=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=g/Yv+xh5dN6TVLbi+wVr8wc6D3GKvRvY7BAho51J7XRkL/RkEEc/8MYaY29SVMmmc0opBq2rUOS1Iu6nwZLHiB7oTxSQvJ82D+8AzEvGQ93r1oLglR6TBKqOuwEzPI2X9XSWWPLvdoWc+s7oxnM/DOaX2rn/hg5Ak0L0Yv3ietU= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=mhlIXa+COTcwkzMW81JIkRz7q/vNVXeevGR75VD5PblB/LbZsnh3sS3TLrdFr+JiARq/zykzKM0uAiz4G7tdAgpiCJw1pCOw9cniVtOYWknHEjttnxFHYFLvJ514U7Ff9wyEmIYzym+O5jSPkHdSTpZ+0EqnbmakW7BdBcEJnU4=; Message-ID: <610143.26817.qm@web30105.mail.mud.yahoo.com> X-YMail-OSG: 1H4nD7sVM1mahZZ5pwMJ8uVpLkhD1vqeYQVJ1m3BhdwXo79 Jc7yOWFhNlkI.8FBkS0S2hCVTjyfHoioZKv9768ktgwsMm.3tiIxnOh8EbRU 7r5h5.GAtOAVyp6aHDlX75c3AKbQn0ZtZjB9U8OcYHZPqaf1Y3.cjXfrZFie GvH8XfRt6s_Oy074g8l2SpKKXtDIJT1G1NdARVnbCK.ymlMyt_9c6ehvARuu NWgk9O.zh_QcJZ9pxYWpgveM6b12PjRwqLcQlMHrQ0yH9yIaM7VQq0YApr94 zCBBwABam7C1wJIyxgTKu13rfi4TucEBo4FL3wHxIZ9tIQ5k7TsBlFA-- Received: from [111.93.130.139] by web30105.mail.mud.yahoo.com via HTTP; Thu, 15 Apr 2010 02:53:10 PDT X-Mailer: YahooMailClassic/10.1.9 YahooMailWebService/0.8.102.267879 Date: Thu, 15 Apr 2010 02:53:10 -0700 (PDT) From: Parav Pandit Subject: Re: deriving MAC address from destination Link local address without Neighbor discovery To: Alexandru Petrescu In-Reply-To: <4BC6DCE6.80706@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Ipv 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, 15 Apr 2010 09:53:22 -0000 Inline.=0A=0AParav=0A=0A=0A--- On Thu, 4/15/10, Alexandru Petrescu wrote:=0A=0A> From: Alexandru Petrescu =0A> Subject: Re: deriving MAC address from destination Li= nk local address without Neighbor discovery=0A> To: "Parav Pandit" =0A> Cc: "Ipv" =0A> Date: Thursday, April 15,= 2010, 3:01 PM=0A> Le 15/04/2010 07:55, Parav Pandit a=0A> =E9crit :=0A> > = Hi,=0A> >=0A> > As per RFC 2464, Link local address for Ethernet based=0A> = interfaces=0A> > are based on the EUI-64 (derived from the MAC=0A> address)= .=0A> =0A> Right, that is probably a very widespread way of how the=0A> lin= k local=0A> addresses are derived from a MAC address.=0A> =0A> There are ma= ny other ways, for example link negotiation=0A> with PPP IPv6=0A> which for= interfaces not having MAC addresses, like a 3G=0A> phone... and=0A> knowin= g that 3G IPv6 handheld computers (watches, phones,=0A> pdas, pads,=0A> net= books) are potentially very numerous one may think it=0A> could be as=0A> w= idespread as the first.=0A> =0A> For these, deriving the MAC address from t= he link-local=0A> address (w/o=0A> doing ND) - will not work.=0A> =0A[Parav= ] You are absolutely correct. RFC 2464 will not be applicable to the exampl= es that you gave because those are non-Ethernet interfaces and their respec= tive link layer RFCs will be applicable but not 2464.=0A=0A=0A> A case that= comes to mind is 6LoWPAN's _some_ version of=0A> "6LoWPAN=0A> Neighbor Dis= covery" which requires the end node to do just=0A> that: derive=0A> the MAC= address from the LL address.=A0 I believe this=0A> intention wrongly=0A> a= imed.=0A> =0A> One shoudl try to identify why would one need to reversely= =0A> derive the=0A> MAC address from the LL address of some neighbor?=A0 Is= =0A> it to save=0A> messages?=A0 We can discuss that and see that sometimes= =0A> it's not needed to=0A> save, better use point-to-point links.=0A> =0A>= Why do you need to do this message-less reverse=0A> resolution?=0A> =0A[PP= ] No. I would not like to prefer doing this reverse resolution.=0AI am tryi= ng to find out and validate that if the IPv6 packet contains Link local add= ress in IPv6 header but contains different MAC address (not related to EUI-= 64) in MAC header. =0AIs this valid packet in ETHERNET networks? Its about = protocol/RFC compliance.=0A=0A=0A> > I have #3 questions based on this.=0A>= >=0A> > In this case, when one Ethernet based host(from its=0A> link-local= =0A> > source) tries to ping the other Ethernet based host,=0A> it knows th= e=0A> > Mac address implicitly (from the Link local address).=0A> =0A> In t= his case, if the problem is ping then the solution may=0A> be=0A> "ping -I = iface" (-I specifies the outgoing interface).=0A> =0A> > 1. Why is it requi= red to explicitly do the Neighbor=0A> discovery for=0A> > the link-local ad= dresses? RFC 4861 says to do the=0A> neighbor discovery=0A> > even for link= -local addresses. Correct me if my=0A> understanding is=0A> > incorrect.=0A= > =0A> IMHO, one aspect is that it requires so in order to have=0A> the mos= t up to=0A> date info about the other node.=A0 Sometimes nodes=0A> change t= heir LLs and=0A> their MAC addresses (ifconfig does that).=0A> =0A> > 2. Do= es it mean that in Ethernet networks, interface=0A> can have only=0A> > one= Link-local address? If not then we violate the RFC=0A> 2464.=0A> =0A> I th= ink I can do "ifconfig eth0 add fe80::1/64; ifconfig=0A> eth0 add=0A> fe80:= :2/64; echo $?" and see success, I suppose - have you=0A> tried?=0A=0A[Para= v] Yes, I have tried doing it on Linux systems and it allowed me!=0AEven it= allowed me entering LL address with prefix size other then 64 for Link loc= al address.=0AThe second part made me doubt about the compliance (or loose = compliance) to the RFC 2464. =0ASeems like it is supporting the older obsol= ete RFC 1972 which allows such stuff.=0A=0A> =0A> > 3. Does RFC 4941 Privac= y extension for autoconf apply=0A> to Ethernet=0A> > interfaces?=0A> =0A> W= ell yes I believe so, I suppose I have it running on my PC=0A> right now.= =0A> =0A[Parav] May be because they follow desolate RFC 1972.=0A=0A> Alex= =0A> =0A> >=0A> > Regards, Parav Pandit=0A=0A=0A=0A From alexandru.petrescu@gmail.com Thu Apr 15 03:16:29 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 45B1B3A6AD6 for ; Thu, 15 Apr 2010 03:16:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.658 X-Spam-Level: X-Spam-Status: No, score=-0.658 tagged_above=-999 required=5 tests=[AWL=-1.009, BAYES_50=0.001, HELO_EQ_FR=0.35] 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 33nDwJrejgww for ; Thu, 15 Apr 2010 03:16:28 -0700 (PDT) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.1]) by core3.amsl.com (Postfix) with ESMTP id 7AD3A28C0E1 for ; Thu, 15 Apr 2010 03:15:00 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.0) with ESMTP id o3FAEr8w010429 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Thu, 15 Apr 2010 12:14:53 +0200 Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id o3FAErLJ031455 for ; Thu, 15 Apr 2010 12:14:53 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.133.173]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id o3FAEq8L016439 for ; Thu, 15 Apr 2010 12:14:52 +0200 Message-ID: <4BC6E71C.1000102@gmail.com> Date: Thu, 15 Apr 2010 12:14:52 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: 6MAN Subject: Comments on draft-carpenter-6man-flow-update-02 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: Thu, 15 Apr 2010 10:16:29 -0000 Hello Authors of draft-carpenter-6man-flow-update-02 at http://tools.ietf.org/html/draft-carpenter-6man-flow-update-02 I have some comments. "a. "The Flow Label value set by the source MUST be delivered unchanged... b. "IPv6 nodes MUST NOT assume any mathematical or other properties... c. "Router performance SHOULD NOT be dependent on the distribution of the Flow Label values... The second two rules appear to forbid a usage in which... However, both before and after these rules were laid down, a considerable number of proposals for use of the flow label have been published... Examples... These authors propose use cases in which some combination of the following options apply: o The flow label may be changed by intermediate systems..." Er? The logic sounds flawed. You seem to be saying that earlier Authors complained about "b" and "c". But then you say they suggested a solution where "a" is addressed too. So actually they complained about "a" too? Not sure I understand what they wanted. > The purpose of the proposed change is that the flow label should be > available for domain-specific use, with locally defined semantics, > without preventing uses that are compatible with RFC 3697. Ok, but then make sure one considers coherently a Host being _in_ xor _out_ of that domain. Sometimes these usages can be mixed. If we say a Host _within_ the domain will _not_ set the Flow Label then we can't say that the intermediary Routers within that domain will change it: because it's hard to imagine a Router is not a Host at the same time. > 1. If and only if the flow label in an IPv6 packet has the default > value of zero, then a router MAY set it to a value between between 1 > and 0xFFFFF. This option modifies the rule that the flow label must > be delivered unchanged, by allowing exactly one router to set it if > the source host did not set it. I believe this may pose problems. The case is when the sending Host1 does not set the Flow Label and the receiving Host2 knows somehow (e.g. the app protocol is older than new Flow Labels) that H1 doesn't implement Flow Labels and so expects "0" zero from it. When H2 sees a flow label set then it deduces something is wrong, because it knows H1 couldn't set it. In RPL there's talk proposing "restoration" of the Flow Label at the exit point, but I don't agree with that either. > packets leaving the local domain may contain flow label values that > are not pseudo-random For some reason I have difficulty understanding "not pseudo-radom": does it mean actually "random", interpreted as a double negation? Does it mean "not random but can't talk random because true random doesn't exist"? The implications of this clarification are wide I believe. > The flow label is not protected in any way and can be forged by an > on-path attacker. On the other hand, a pseudo-random flow label > cannot be readily guessed by an off-path attacker. That "OTOH" makes think that because pseudo-random flow labels cannot be guessed then the Flow Label is protected against on-path attackers. I don't think much protection is afforded by the use of visible be them random numbers. Were it public-private-keys then yes but here we don't talk Flow Labels as security keys, at least because of the obvious performance requirements. Alex From ipng@69706e6720323030352d30312d31340a.nosense.org Thu Apr 15 03:37:02 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 00F5D3A6888 for ; Thu, 15 Apr 2010 03:37:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.668 X-Spam-Level: X-Spam-Status: No, score=-1.668 tagged_above=-999 required=5 tests=[AWL=0.227, 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 Bc2UBdS++kX9 for ; Thu, 15 Apr 2010 03:37:01 -0700 (PDT) Received: from smtp3.adam.net.au (smtp3.adam.net.au [202.136.110.249]) by core3.amsl.com (Postfix) with ESMTP id B9B213A6905 for ; Thu, 15 Apr 2010 03:36:59 -0700 (PDT) Received: from 219-90-234-216.ip.adam.com.au ([219.90.234.216] helo=opy.nosense.org) by smtp3.adam.net.au with esmtp (Exim 4.63) (envelope-from ) id 1O2MRC-0007k9-Ng; Thu, 15 Apr 2010 20:06:46 +0930 Received: from opy.nosense.org (localhost.localdomain [IPv6:::1]) by opy.nosense.org (Postfix) with ESMTP id D354A4922D; Thu, 15 Apr 2010 20:06:45 +0930 (CST) Date: Thu, 15 Apr 2010 20:06:43 +0930 From: Mark Smith To: Brian E Carpenter Subject: Re: [Fwd: New Version Notification for draft-carpenter-6man-flow-update-02] Message-ID: <20100415200643.58449671@opy.nosense.org> In-Reply-To: <4BC68D6F.8070500@gmail.com> References: <4BC54919.3000900@gmail.com> <20100415072936.60eb08ac@opy.nosense.org> <4BC63DF0.6070707@gmail.com> <4BC68D6F.8070500@gmail.com> X-Mailer: Claws Mail 3.7.5 (GTK+ 2.20.0; x86_64-unknown-linux-gnu) X-Location: Lower Mitcham, South Australia, 5062 Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: 6man 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, 15 Apr 2010 10:37:02 -0000 Hi Brian, Shane, On Thu, 15 Apr 2010 15:52:15 +1200 Brian E Carpenter wrote: > > Regards > Brian Carpenter > > > > > On 2010-04-15 14:10, Shane Amante wrote: > > Brian, Mark, > > > > Brian: FWIW, I like the direction of this version of draft > > much better than previous versions; however, I agree with > > Remi that the current version is a bit confusing at the > > moment and could likely be rewritten to be more simple and > > just obsolete RFC 3967. In addition, I'm still a bit unclear > > and, therefore, uncomfortable on the proposal with respect to > > flow-labels within an "administratively defined domain". In > > particular, if one administrative domain has set their own > > "locally defined" flow-label, I think the draft could benefit > > from a stronger emphasis that the flow-label MUST or, at > > least, SHOULD be reset to 0 upon /leaving/ that domain, > > otherwise the next domain may (or, will?) misinterpret the > > meaning of the incoming "locally-defined" flow-label. The > > I'm personally quite attracted by this. It does further damage > to the sacred principle that the flow label is immutable, > but maybe that is the inevitable result anyway. > I think the way the dscp is handled provides a good example. If your network is QoS enabled, then you reset the dscp value upon ingress because you can't trust it, otherwise you completely ignore the value of it as it traverses your network. I think the same model can be applied to flow labels. For an ISP, if it considered it's network to be a separate flow domain from that of it's customers' networks (and my position is that I would, for both business and residential customers), then every egress interface towards a customer would have to be resetting the flow label. ISPs with many PPPoE/PPP customers have as many virtual egress interfaces as they do customers. I think a lot of those customers wouldn't implement a flow domain, so having every virtual interface reset the flow label back to 0 on packet egress would be a relatively high price for the value it provides to only a small number of customers. Regards, Mark. From cabo@tzi.org Thu Apr 15 03:37:29 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 5AAF03A68E3 for ; Thu, 15 Apr 2010 03:37:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.928 X-Spam-Level: X-Spam-Status: No, score=-5.928 tagged_above=-999 required=5 tests=[AWL=0.321, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q6m7UWPeierd for ; Thu, 15 Apr 2010 03:37:28 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9:209:3dff:fe00:7136]) by core3.amsl.com (Postfix) with ESMTP id E2BB428C0F5 for ; Thu, 15 Apr 2010 03:37:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id o3FAb54M005641; Thu, 15 Apr 2010 12:37:05 +0200 (CEST) Received: from [192.168.217.101] (p5489A82C.dip.t-dialin.net [84.137.168.44]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTP id 9E428D604; Thu, 15 Apr 2010 12:37:04 +0200 (CEST) Subject: Re: [Fwd: New Version Notification for draft-carpenter-6man-flow-update-02] Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii From: Carsten Bormann In-Reply-To: <4BC68D6F.8070500@gmail.com> Date: Thu, 15 Apr 2010 12:37:02 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <453EE402-6F1C-4F40-BDC1-29A9A51ADCF4@tzi.org> References: <4BC54919.3000900@gmail.com> <20100415072936.60eb08ac@opy.nosense.org> <4BC63DF0.6070707@gmail.com> <4BC68D6F.8070500@gmail.com> To: Brian E Carpenter X-Mailer: Apple Mail (2.1078) Cc: 6man X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Apr 2010 10:37:29 -0000 On Apr 15, 2010, at 05:52, Brian E Carpenter wrote: >> the flow-label MUST or, at >> least, SHOULD be reset to 0 upon /leaving/ that domain, >> otherwise the next domain may (or, will?) misinterpret the >> meaning of the incoming "locally-defined" flow-label. The >=20 > I'm personally quite attracted by this. It does further damage > to the sacred principle that the flow label is immutable, > but maybe that is the inevitable result anyway. It may be useful to discuss this in the context of a more general = question: How does a domain stash temporary information (meaningful only in that = domain) into an IPv6 packet, with the intention of removing it again at = domain egress? See also: "RPL Option for Carrying RPL Information in Data-Plane Datagrams", Jonathan Hui, JP Vasseur, 10-Mar-10, = The RPL protocol requires data-plane datagrams to carry RPL routing information that is processed by RPL routers when forwarding those datagrams. This document describes the RPL option for use within a RPL domain. This work was originally trying to use the flow label in a similar way, = and has moved to proposing to insert a hop-hy-hop option. Note that = hop-by-hop options *inserted* on the way destroy AH, so in this case = they *must* be removed at egress (including at final delivery; and the = fun part about "removing" is then how to reconstitute any padding in the = original hbh option, if there was one). I'm not saying the flow label does not pose an attractive nuisance for = addressing some of these problems. But if it is already taken in a packet (by the sending host or by an = encapsulating domain), how does the domain derive the benefit? We can either stipulate that everyone (end-to-end, encapsulating domain) = please use it in a similar way (i.e., 5-tuple), or we can provide for a = way to stash it on ingress and reconstruct it on egress (the only way = that would be useful for RPL, as its use would not be about the = 5-tuple). None of this makes me particularly happy right now. (I'm not even saying the flow label work *must* consider this problem. = It just appears it's getting awfully close to it.) Gruesse, Carsten From cb.list6@gmail.com Thu Apr 15 06:19:30 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 A4E1728C1A1 for ; Thu, 15 Apr 2010 06:19:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_44=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 98JHCe18Pjds for ; Thu, 15 Apr 2010 06:19:29 -0700 (PDT) Received: from mail-gw0-f44.google.com (mail-gw0-f44.google.com [74.125.83.44]) by core3.amsl.com (Postfix) with ESMTP id 8BC8128C1E7 for ; Thu, 15 Apr 2010 06:18:08 -0700 (PDT) Received: by gwb1 with SMTP id 1so732393gwb.31 for ; Thu, 15 Apr 2010 06:17:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:received:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=sJHMiPcQ4zQGqLBnH26v2ZgJfOH4bK37UKKV6ANFMiI=; b=JtEkJGs/N4LxSTB3rlmKXENj4eygX2ICHQdm8fCV96KDu3+7cR/PGdKIJCvuEB4x6+ lwuypQUqfIzbz7H1gBsUQqREiJt/VsWqgx2IbupyYyKjxXa+dIrh0xCDDKSfV552RDBd hGdYnYckj4vRJEAz4Cam9a8cyRzTsyExmJRwA= 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=xtbKHxOHaKIElV81p/AimksTnUIkoNDZeObRHtIlQZTFb5y8fScGmRgjmFMgkteUZB vw7jz7SlbVydbjuM6S0WE1YbC2HChgY0DXfzUbd/W837mSXXrpdsMbWxpcrjH863y08K h/5Ln4ejAEpEQRvfxW2cLSOLvtemsEOt7p5cA= MIME-Version: 1.0 Received: by 10.151.98.2 with HTTP; Thu, 15 Apr 2010 06:17:56 -0700 (PDT) In-Reply-To: <4BC6DCE6.80706@gmail.com> References: <342102.44906.qm@web30104.mail.mud.yahoo.com> <4BC6DCE6.80706@gmail.com> Date: Thu, 15 Apr 2010 06:17:56 -0700 Received: by 10.151.87.12 with SMTP id p12mr347441ybl.174.1271337476160; Thu, 15 Apr 2010 06:17:56 -0700 (PDT) Message-ID: Subject: Re: deriving MAC address from destination Link local address without Neighbor discovery From: Cameron Byrne To: Alexandru Petrescu Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Ipv 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, 15 Apr 2010 13:19:30 -0000 On Thu, Apr 15, 2010 at 2:31 AM, Alexandru Petrescu wrote: > Le 15/04/2010 07:55, Parav Pandit a =E9crit : >> >> Hi, >> >> As per RFC 2464, Link local address for Ethernet based interfaces >> are based on the EUI-64 (derived from the MAC address). > > Right, that is probably a very widespread way of how the link local > addresses are derived from a MAC address. > > There are many other ways, for example link negotiation with PPP IPv6 > which for interfaces not having MAC addresses, like a 3G phone... and > knowing that 3G IPv6 handheld computers (watches, phones, pdas, pads, > netbooks) are potentially very numerous one may think it could be as > widespread as the first. > Just as a point of clarification, 3G devices do not use PPP generally. The process is described in RFC 3316 Appendix A Cameron > For these, deriving the MAC address from the link-local address (w/o > doing ND) - will not work. > > A case that comes to mind is 6LoWPAN's _some_ version of "6LoWPAN > Neighbor Discovery" which requires the end node to do just that: derive > the MAC address from the LL address. =A0I believe this intention wrongly > aimed. > > One shoudl try to identify why would one need to reversely derive the > MAC address from the LL address of some neighbor? =A0Is it to save > messages? =A0We can discuss that and see that sometimes it's not needed t= o > save, better use point-to-point links. > > Why do you need to do this message-less reverse resolution? > >> I have #3 questions based on this. >> >> In this case, when one Ethernet based host(from its link-local >> source) tries to ping the other Ethernet based host, it knows the >> Mac address implicitly (from the Link local address). > > In this case, if the problem is ping then the solution may be > "ping -I iface" (-I specifies the outgoing interface). > >> 1. Why is it required to explicitly do the Neighbor discovery for >> the link-local addresses? RFC 4861 says to do the neighbor discovery >> even for link-local addresses. Correct me if my understanding is >> incorrect. > > IMHO, one aspect is that it requires so in order to have the most up to > date info about the other node. =A0Sometimes nodes change their LLs and > their MAC addresses (ifconfig does that). > >> 2. Does it mean that in Ethernet networks, interface can have only >> one Link-local address? If not then we violate the RFC 2464. > > I think I can do "ifconfig eth0 add fe80::1/64; ifconfig eth0 add > fe80::2/64; echo $?" and see success, I suppose - have you tried? > >> 3. Does RFC 4941 Privacy extension for autoconf apply to Ethernet >> interfaces? > > Well yes I believe so, I suppose I have it running on my PC right now. > > Alex > >> >> Regards, Parav Pandit >> >> >> >> >> -------------------------------------------------------------------- >> =A0IETF 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 simon.perreault@viagenie.ca Thu Apr 15 06:50:13 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 B138A3A67AF for ; Thu, 15 Apr 2010 06:50:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.425 X-Spam-Level: X-Spam-Status: No, score=-2.425 tagged_above=-999 required=5 tests=[AWL=0.174, 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 x7nspIDXlleL for ; Thu, 15 Apr 2010 06:50:12 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [206.123.31.2]) by core3.amsl.com (Postfix) with ESMTP id 42EDA3A686C for ; Thu, 15 Apr 2010 06:50:08 -0700 (PDT) Received: from ringo.viagenie.ca (ringo.viagenie.ca [IPv6:2620:0:230:c000::67]) by jazz.viagenie.ca (Postfix) with ESMTPSA id DC2F321BB0 for ; Thu, 15 Apr 2010 09:50:00 -0400 (EDT) Message-ID: <4BC71988.2040908@viagenie.ca> Date: Thu, 15 Apr 2010 09:50:00 -0400 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.9) Gecko/20100330 Fedora/3.0.4-1.fc12 Thunderbird/3.0.4 MIME-Version: 1.0 To: ipv6@ietf.org Subject: Re: Extracting the 5-tuple from IPv6 packets References: <4BC64100.303@gmail.com> In-Reply-To: <4BC64100.303@gmail.com> 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: Thu, 15 Apr 2010 13:50:13 -0000 On 2010-04-14 18:26, Brian E Carpenter wrote: > Common practice in network monitoring and in QoS technologies > is to identify a flow of packets by the 5-tuple > {source address, dest address, source port, dest port, protocol #}. > Or we can strongly recommend that all hosts set the flow label, so > that we can use the 3-tuple {source address, dest address, flow label}. It would be easy for an attacker to put garbage in the flow label to trick the QoS. So you couldn't use the flow label from hosts you don't trust, which is most of them nowadays. Simon -- NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca vCard 4.0 --> http://www.vcarddav.org From alexandru.petrescu@gmail.com Thu Apr 15 06:54:41 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 970B828C195 for ; Thu, 15 Apr 2010 06:54:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.595 X-Spam-Level: X-Spam-Status: No, score=-1.595 tagged_above=-999 required=5 tests=[AWL=0.054, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_44=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 dEoXMIZoakvR for ; Thu, 15 Apr 2010 06:54:40 -0700 (PDT) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.166.172.106]) by core3.amsl.com (Postfix) with ESMTP id A467528C1CC for ; Thu, 15 Apr 2010 06:54:38 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.0) with ESMTP id o3FDsUGg016670 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 15 Apr 2010 15:54:30 +0200 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id o3FDsTli025442; Thu, 15 Apr 2010 15:54:30 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.133.173]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id o3FDsNvO007685; Thu, 15 Apr 2010 15:54:29 +0200 Message-ID: <4BC71A8E.3070001@gmail.com> Date: Thu, 15 Apr 2010 15:54:22 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: Cameron Byrne Subject: Re: deriving MAC address from destination Link local address without Neighbor discovery References: <342102.44906.qm@web30104.mail.mud.yahoo.com> <4BC6DCE6.80706@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: 6MAN X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Apr 2010 13:54:41 -0000 Le 15/04/2010 15:17, Cameron Byrne a écrit : > On Thu, Apr 15, 2010 at 2:31 AM, Alexandru Petrescu > wrote: >> Le 15/04/2010 07:55, Parav Pandit a écrit : >>> >>> Hi, >>> >>> As per RFC 2464, Link local address for Ethernet based interfaces >>> are based on the EUI-64 (derived from the MAC address). >> >> Right, that is probably a very widespread way of how the link local >> addresses are derived from a MAC address. >> >> There are many other ways, for example link negotiation with PPP IPv6 >> which for interfaces not having MAC addresses, like a 3G phone... and >> knowing that 3G IPv6 handheld computers (watches, phones, pdas, pads, >> netbooks) are potentially very numerous one may think it could be as >> widespread as the first. >> > > Just as a point of clarification, 3G devices do not use PPP generally. Sorry what do they use to assign an IP address to the end node? I could have said GPRS instead. I could have said that I used ppp myself to set up a link which is qualified as 3G by the operator. Alex > > The process is described in RFC 3316 Appendix A > > Cameron > > >> For these, deriving the MAC address from the link-local address (w/o >> doing ND) - will not work. >> >> A case that comes to mind is 6LoWPAN's _some_ version of "6LoWPAN >> Neighbor Discovery" which requires the end node to do just that: derive >> the MAC address from the LL address. I believe this intention wrongly >> aimed. >> >> One shoudl try to identify why would one need to reversely derive the >> MAC address from the LL address of some neighbor? Is it to save >> messages? We can discuss that and see that sometimes it's not needed to >> save, better use point-to-point links. >> >> Why do you need to do this message-less reverse resolution? >> >>> I have #3 questions based on this. >>> >>> In this case, when one Ethernet based host(from its link-local >>> source) tries to ping the other Ethernet based host, it knows the >>> Mac address implicitly (from the Link local address). >> >> In this case, if the problem is ping then the solution may be >> "ping -I iface" (-I specifies the outgoing interface). >> >>> 1. Why is it required to explicitly do the Neighbor discovery for >>> the link-local addresses? RFC 4861 says to do the neighbor discovery >>> even for link-local addresses. Correct me if my understanding is >>> incorrect. >> >> IMHO, one aspect is that it requires so in order to have the most up to >> date info about the other node. Sometimes nodes change their LLs and >> their MAC addresses (ifconfig does that). >> >>> 2. Does it mean that in Ethernet networks, interface can have only >>> one Link-local address? If not then we violate the RFC 2464. >> >> I think I can do "ifconfig eth0 add fe80::1/64; ifconfig eth0 add >> fe80::2/64; echo $?" and see success, I suppose - have you tried? >> >>> 3. Does RFC 4941 Privacy extension for autoconf apply to Ethernet >>> interfaces? >> >> Well yes I believe so, I suppose I have it running on my PC right now. >> >> Alex >> >>> >>> Regards, Parav Pandit >>> >>> >>> >>> >>> -------------------------------------------------------------------- >>> 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 Francis.Dupont@fdupont.fr Thu Apr 15 07:00:42 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 2DED03A6956 for ; Thu, 15 Apr 2010 07:00:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dKXdDHkvHcA3 for ; Thu, 15 Apr 2010 07:00:41 -0700 (PDT) Received: from givry.fdupont.fr (givry.fdupont.fr [91.121.26.85]) by core3.amsl.com (Postfix) with ESMTP id F11D328C195 for ; Thu, 15 Apr 2010 07:00:34 -0700 (PDT) Received: from givry.fdupont.fr (localhost [127.0.0.1]) by givry.fdupont.fr (8.14.3/8.14.3) with ESMTP id o3FE0OSA096128; Thu, 15 Apr 2010 14:00:24 GMT (envelope-from dupont@givry.fdupont.fr) Message-Id: <201004151400.o3FE0OSA096128@givry.fdupont.fr> From: Francis Dupont To: Brian E Carpenter Subject: Re: Extracting the 5-tuple from IPv6 packets In-reply-to: Your message of Thu, 15 Apr 2010 10:26:08 +1200. <4BC64100.303@gmail.com> Date: Thu, 15 Apr 2010 16:00:24 +0200 Sender: Francis.Dupont@fdupont.fr Cc: Nevil Brownlee , 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, 15 Apr 2010 14:00:42 -0000 In your previous mail you wrote: any implementation (hardware or software) that extracts the 5-tuple has to follow the linked list to the end. => and in a rare case ports are not in the first fragment... Or we can strongly recommend that all hosts set the flow label, so that we can use the 3-tuple {source address, dest address, flow label}. => the flow label was designed for it, wasn't it? And I can't see a problem with recommending to set the flow label to get a "better" QoS. BTW this simplifies fragment classifying too. Regards Francis.Dupont@fdupont.fr From mohacsi@niif.hu Thu Apr 15 07:34:50 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 136F828C1E8 for ; Thu, 15 Apr 2010 07:34:50 -0700 (PDT) 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 3lzy5AgoB7lV for ; Thu, 15 Apr 2010 07:34:49 -0700 (PDT) Received: from mail.ki.iif.hu (mail.ki.iif.hu [IPv6:2001:738:0:411::241]) by core3.amsl.com (Postfix) with ESMTP id 8C7533A68D7 for ; Thu, 15 Apr 2010 07:32:34 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mail.ki.iif.hu (Postfix) with ESMTP id 1DFA786D13; Thu, 15 Apr 2010 16:32:26 +0200 (CEST) X-Virus-Scanned: by amavisd-new at mignon.ki.iif.hu Received: from mail.ki.iif.hu ([127.0.0.1]) by localhost (mignon.ki.iif.hu [127.0.0.1]) (amavisd-new, port 10024) with LMTP id SXIFnvzSn7sX; Thu, 15 Apr 2010 16:32:23 +0200 (CEST) Received: by mail.ki.iif.hu (Postfix, from userid 9002) id 11FDB86D01; Thu, 15 Apr 2010 16:32:23 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by mail.ki.iif.hu (Postfix) with ESMTP id 1069286CA8; Thu, 15 Apr 2010 16:32:23 +0200 (CEST) Date: Thu, 15 Apr 2010 16:32:22 +0200 (CEST) From: Mohacsi Janos X-X-Sender: mohacsi@mignon.ki.iif.hu To: Simon Perreault Subject: Re: Extracting the 5-tuple from IPv6 packets In-Reply-To: <4BC71988.2040908@viagenie.ca> Message-ID: References: <4BC64100.303@gmail.com> <4BC71988.2040908@viagenie.ca> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Apr 2010 14:34:50 -0000 On Thu, 15 Apr 2010, Simon Perreault wrote: > On 2010-04-14 18:26, Brian E Carpenter wrote: >> Common practice in network monitoring and in QoS technologies >> is to identify a flow of packets by the 5-tuple >> {source address, dest address, source port, dest port, protocol #}. > >> Or we can strongly recommend that all hosts set the flow label, so >> that we can use the 3-tuple {source address, dest address, flow label}. > > It would be easy for an attacker to put garbage in the flow label to trick > the QoS. So you couldn't use the flow label from hosts you don't trust, which > is most of them nowadays. So as put garbage to src and dst port. If BCP-38 network ingres filter is implemented, then not so easy..... Best Regards, Janos Mohacsi > > Simon > -- > NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca > STUN/TURN server --> http://numb.viagenie.ca > vCard 4.0 --> http://www.vcarddav.org > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > From shane@castlepoint.net Thu Apr 15 07:36:26 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 9CE773A6A1B for ; Thu, 15 Apr 2010 07:36:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.271 X-Spam-Level: X-Spam-Status: No, score=-2.271 tagged_above=-999 required=5 tests=[AWL=0.329, 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 PoGgEFtcccFi for ; Thu, 15 Apr 2010 07:36:25 -0700 (PDT) Received: from dog.tcb.net (dog.tcb.net [64.78.150.133]) by core3.amsl.com (Postfix) with ESMTP id 68C3E28C24C for ; Thu, 15 Apr 2010 07:35:02 -0700 (PDT) Received: by dog.tcb.net (Postfix, from userid 0) id F2491268675; Thu, 15 Apr 2010 08:34:55 -0600 (MDT) Received: from mbpw.castlepoint.net (71-215-81-125.hlrn.qwest.net [71.215.81.125]) (authenticated-user smtp) (TLSv1/SSLv3 AES128-SHA 128/128) by dog.tcb.net with SMTP; Thu, 15 Apr 2010 08:34:55 -0600 (MDT) (envelope-from shane@castlepoint.net) X-Avenger: version=0.7.8; receiver=dog.tcb.net; client-ip=71.215.81.125; client-port=58245; syn-fingerprint=65535:56:1:64:M1452,N,W1,N,N,T,S; data-bytes=0 Subject: Re: [Fwd: New Version Notification for draft-carpenter-6man-flow-update-02] Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii From: Shane Amante In-Reply-To: <20100415200643.58449671@opy.nosense.org> Date: Thu, 15 Apr 2010 08:34:40 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4BC54919.3000900@gmail.com> <20100415072936.60eb08ac@opy.nosense.org> <4BC63DF0.6070707@gmail.com> <4BC68D6F.8070500@gmail.com> <20100415200643.58449671@opy.nosense.org> To: Mark Smith X-Mailer: Apple Mail (2.1078) 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: Thu, 15 Apr 2010 14:36:26 -0000 Hi Mark, On Apr 15, 2010, at 04:36 MDT, Mark Smith wrote: > Hi Brian, Shane, >=20 > On Thu, 15 Apr 2010 15:52:15 +1200 > Brian E Carpenter wrote: >=20 >>=20 >> Regards >> Brian Carpenter >>=20 >>=20 >>=20 >>=20 >> On 2010-04-15 14:10, Shane Amante wrote: >>> Brian, Mark, >>>=20 >>> Brian: FWIW, I like the direction of this version of draft >>> much better than previous versions; however, I agree with >>> Remi that the current version is a bit confusing at the >>> moment and could likely be rewritten to be more simple and >>> just obsolete RFC 3967. In addition, I'm still a bit unclear >>> and, therefore, uncomfortable on the proposal with respect to >>> flow-labels within an "administratively defined domain". In >>> particular, if one administrative domain has set their own >>> "locally defined" flow-label, I think the draft could benefit >>> from a stronger emphasis that the flow-label MUST or, at >>> least, SHOULD be reset to 0 upon /leaving/ that domain, >>> otherwise the next domain may (or, will?) misinterpret the >>> meaning of the incoming "locally-defined" flow-label. The >>=20 >> I'm personally quite attracted by this. It does further damage >> to the sacred principle that the flow label is immutable, >> but maybe that is the inevitable result anyway. >>=20 >=20 > I think the way the dscp is handled provides a good example. If your > network is QoS enabled, then you reset the dscp value upon ingress > because you can't trust it, otherwise you completely ignore the value = of > it as it traverses your network. I think the same model can be applied > to flow labels. I believe we're in agreement on the above point. > For an ISP, if it considered it's network to be a separate flow domain > from that of it's customers' networks (and my position is that I > would, for both business and residential customers), then every egress > interface towards a customer would have to be resetting the flow = label. > ISPs with many PPPoE/PPP customers have as many virtual egress > interfaces as they do customers. I think a lot of those customers > wouldn't implement a flow domain, so having every virtual interface > reset the flow label back to 0 on packet egress would be a relatively > high price for the value it provides to only a small number of > customers. I acknowledge the operational burden of resetting the flow-label on = egress; however, the same challenge exists on ingress, as well. IOW, if = you don't trust the flow-label setting coming from another = "administratively defined domain" (ADD), then you'll always need to have = to reset (and/or set) it on ingress before it transits your ADD ... wh/ = would translate into roughly the same problem. Regardless, the way the draft is written now it still seems a bit = ambiguous (at best) as to whether the next, downstream "administratively = defined domain" (ADD) is supposed to accept "as-is" the incoming, = perhaps locally-defined in another ADD, flow-label or not. Most = importantly consideration should be given to what the operational = implications will be if that were the case. IOW, it could result in = very poor load-balancing if the incoming locally-defined flow-label does = not correspond to, say, a 5-tuple "microflow" and, instead, means = something else entirely (e.g.: a "nonce" as per one of the many = proposals to recast/re-use/abuse the flow-label). The reason I offered the proposed text was to make it abundantly clear = that there should be no assumptions made about the flow-label once it = leaves one "administratively defined domain", since one ADD can't tell = if it's locally-defined or not. In summary, I think the text could = stand to be made more clear that a flow-label needs to be reset /either/ = on egress from or ingress to an ADD[1]. I think, in practice, you're = likely correct that most operators would probably (re)set it only on = ingress (similar to IP DSCP or IPv6 TC), since that's a common = operation. Lastly, FWIW, I'd personally rather not carve out a bit in the = flow-label (as was discussed in previous revisions of this draft), for = "locally-defined" flow-labels since the same operational problem exists. = Only in that case, as a packet enters my ADD I won't be able to do = anything with it. This means I need to have even more complex logic in = routers to ignore those flow-labels with that bit set and then attempt = to look for Layer-4 Transport header info at every hop for = load-balancing calculations. -shane [1] I should note that if one or more "consenting" ADD's want to = exchange a locally defined flow-label between them, then that's their = right, i.e.: your network(s), your rules. However, I would typically = expect this to be an exception, not the rule, given the implications a = misunderstanding or misinterpretation a "locally-defined" flow-label = might have.= From simon.perreault@viagenie.ca Thu Apr 15 07:37:07 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 D8F193A698D for ; Thu, 15 Apr 2010 07:37:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.441 X-Spam-Level: X-Spam-Status: No, score=-2.441 tagged_above=-999 required=5 tests=[AWL=0.158, 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 KfzQP6UUeLFB for ; Thu, 15 Apr 2010 07:37:07 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [206.123.31.2]) by core3.amsl.com (Postfix) with ESMTP id 14CF73A68E2 for ; Thu, 15 Apr 2010 07:36:18 -0700 (PDT) Received: from ringo.viagenie.ca (ringo.viagenie.ca [IPv6:2620:0:230:c000::67]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 9570D210FD; Thu, 15 Apr 2010 10:36:10 -0400 (EDT) Message-ID: <4BC7245A.3000905@viagenie.ca> Date: Thu, 15 Apr 2010 10:36:10 -0400 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.9) Gecko/20100330 Fedora/3.0.4-1.fc12 Thunderbird/3.0.4 MIME-Version: 1.0 To: Mohacsi Janos Subject: Re: Extracting the 5-tuple from IPv6 packets References: <4BC64100.303@gmail.com> <4BC71988.2040908@viagenie.ca> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Apr 2010 14:37:07 -0000 On 2010-04-15 10:32, Mohacsi Janos wrote: > So as put garbage to src and dst port. Not as easy because a host often has no control on the destination port. Google won't talk to me unless I put 80 in there. Simon -- NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca vCard 4.0 --> http://www.vcarddav.org From mohacsi@niif.hu Thu Apr 15 07:39: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 BE7123A67D4 for ; Thu, 15 Apr 2010 07:39:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c0FxFMzF7uGs for ; Thu, 15 Apr 2010 07:39:12 -0700 (PDT) Received: from mail.ki.iif.hu (mail.ki.iif.hu [IPv6:2001:738:0:411::241]) by core3.amsl.com (Postfix) with ESMTP id 79A773A686C for ; Thu, 15 Apr 2010 07:39:09 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mail.ki.iif.hu (Postfix) with ESMTP id 5A2A486D01; Thu, 15 Apr 2010 16:39:01 +0200 (CEST) X-Virus-Scanned: by amavisd-new at mignon.ki.iif.hu Received: from mail.ki.iif.hu ([127.0.0.1]) by localhost (mignon.ki.iif.hu [127.0.0.1]) (amavisd-new, port 10024) with LMTP id lABJptk9zsHH; Thu, 15 Apr 2010 16:38:58 +0200 (CEST) Received: by mail.ki.iif.hu (Postfix, from userid 9002) id EB64386D1C; Thu, 15 Apr 2010 16:38:58 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by mail.ki.iif.hu (Postfix) with ESMTP id E9A0D85438; Thu, 15 Apr 2010 16:38:58 +0200 (CEST) Date: Thu, 15 Apr 2010 16:38:58 +0200 (CEST) From: Mohacsi Janos X-X-Sender: mohacsi@mignon.ki.iif.hu To: Simon Perreault Subject: Re: Extracting the 5-tuple from IPv6 packets In-Reply-To: <4BC7245A.3000905@viagenie.ca> Message-ID: References: <4BC64100.303@gmail.com> <4BC71988.2040908@viagenie.ca> <4BC7245A.3000905@viagenie.ca> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Apr 2010 14:39:12 -0000 On Thu, 15 Apr 2010, Simon Perreault wrote: > On 2010-04-15 10:32, Mohacsi Janos wrote: >> So as put garbage to src and dst port. > > Not as easy because a host often has no control on the destination port. > > Google won't talk to me unless I put 80 in there. Why cope with QoS if somebody is sending packets to black-hole? Janos From simon.perreault@viagenie.ca Thu Apr 15 07:49:44 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 E13713A68E2 for ; Thu, 15 Apr 2010 07:49:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.447 X-Spam-Level: X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[AWL=0.152, 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 B4hTbNJRSxvL for ; Thu, 15 Apr 2010 07:49:44 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [206.123.31.2]) by core3.amsl.com (Postfix) with ESMTP id CFB0C3A68E7 for ; Thu, 15 Apr 2010 07:49:43 -0700 (PDT) Received: from ringo.viagenie.ca (ringo.viagenie.ca [IPv6:2620:0:230:c000::67]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 5AD5A210FD; Thu, 15 Apr 2010 10:49:36 -0400 (EDT) Message-ID: <4BC7277F.2010900@viagenie.ca> Date: Thu, 15 Apr 2010 10:49:35 -0400 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.9) Gecko/20100330 Fedora/3.0.4-1.fc12 Thunderbird/3.0.4 MIME-Version: 1.0 To: Mohacsi Janos Subject: Re: Extracting the 5-tuple from IPv6 packets References: <4BC64100.303@gmail.com> <4BC71988.2040908@viagenie.ca> <4BC7245A.3000905@viagenie.ca> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Apr 2010 14:49:45 -0000 On 2010-04-15 10:38, Mohacsi Janos wrote: > Why cope with QoS if somebody is sending packets to black-hole? I don't understand your question, but here's an example use case of the attack I'm suggesting: I want to evade an SFQ QoS for a single flow. If the QoS is based on the flow field, I can just put random values in the flow field so that my packets appear to come from multiple flows, which will let me get better throughput. Many other examples come to mind... This usage of the flow field would need to be treated just like the DSCP field. Maybe you can use it in some applications, not in others. But a recommendation that all hosts on the Internet set it would be pointless if intermediate networks can't or won't use it. Simon -- NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca vCard 4.0 --> http://www.vcarddav.org From vishwas.ietf@gmail.com Thu Apr 15 08:00:00 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 2AB5D28C236 for ; Thu, 15 Apr 2010 08:00:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.913 X-Spam-Level: X-Spam-Status: No, score=-1.913 tagged_above=-999 required=5 tests=[AWL=0.686, 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 PWBuPe0Nb9XV for ; Thu, 15 Apr 2010 07:59:58 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by core3.amsl.com (Postfix) with ESMTP id 53C1C28C214 for ; Thu, 15 Apr 2010 07:59:58 -0700 (PDT) Received: by gyh4 with SMTP id 4so778221gyh.31 for ; Thu, 15 Apr 2010 07:59:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:received:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=fhJDitGRzn+8V2ikhDVmLvvLQQ403am+X3PJb3iVGnc=; b=XLHubmPIofGBro4MS2zErer05BBUlV5UicGxNT3SpwlNsf9BrHN1zBPPyZqtmJ2NRX IYqrsNSjrlebq8x+UQUeiEk5b6/Mp7aHtDTTPpetuz2r6PnU5HBiOSgUcqBTPW1gjGKu 8OefffSaXd5GQUt2lUDQp38H7GcJEtxuA/hd0= 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=RsGDcb4SuiZeu7+G6vENDx6r1Gp7yTA1au1N7m7Zn7OcTgn4l5gbME3GVfPo2P9Nl4 KdjkiaghY7UMg8NrOES9W7yqHUKUoszGTxzv2EQTWAJXu/S5hHnLD7LsOGAABRWe1Al6 4qjdy6+dQXNIbaeIWnF/LB5scKTSKjo0d4DYo= MIME-Version: 1.0 Received: by 10.151.46.14 with HTTP; Thu, 15 Apr 2010 07:59:46 -0700 (PDT) In-Reply-To: <201004151400.o3FE0OSA096128@givry.fdupont.fr> References: <4BC64100.303@gmail.com> <201004151400.o3FE0OSA096128@givry.fdupont.fr> Date: Thu, 15 Apr 2010 07:59:46 -0700 Received: by 10.150.56.27 with SMTP id e27mr460611yba.81.1271343586357; Thu, 15 Apr 2010 07:59:46 -0700 (PDT) Message-ID: Subject: Re: Extracting the 5-tuple from IPv6 packets From: Vishwas Manral To: Francis Dupont Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: 6man , Nevil Brownlee , 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: Thu, 15 Apr 2010 15:00:00 -0000 Hi, I agree with Francis that there is the issue of the transport headers not being present in the first fragment itself. In IPv4 the minimum fragment size is 64 which means the first fragement has the header (even when options are present). We have a draft to take care of this for IPv6: http://tools.ietf.org/html/draft-manral-v6ops-tiny-fragments-issues-03 A link to the tiny Fragment attack http://www.javvin.com/networksecurity/TinyFragmentAttack.html I am also working with Suresh Krishnan to get a new version of this draft o= ut. Thanks, Vishwas On Thu, Apr 15, 2010 at 7:00 AM, Francis Dupont wrote: > =A0In your previous mail you wrote: > > =A0 any implementation (hardware or software) that extracts > =A0 the 5-tuple has to follow the linked list to the end. > > =3D> and in a rare case ports are not in the first fragment... > > =A0 Or we can strongly recommend that all hosts set the flow label, so > =A0 that we can use the 3-tuple {source address, dest address, flow label= }. > > =3D> the flow label was designed for it, wasn't it? And I can't see > a problem with recommending to set the flow label to get a "better" QoS. > BTW this simplifies fragment classifying too. > > Regards > > Francis.Dupont@fdupont.fr > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > From fred@cisco.com Thu Apr 15 08:05:35 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 999CD3A697F for ; Thu, 15 Apr 2010 08:05:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.933 X-Spam-Level: X-Spam-Status: No, score=-109.933 tagged_above=-999 required=5 tests=[AWL=0.066, BAYES_00=-2.599, J_CHICKENPOX_44=0.6, 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 BQRl-bPIBoUh for ; Thu, 15 Apr 2010 08:05:33 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id BA61B3A68BD for ; Thu, 15 Apr 2010 08:05:33 -0700 (PDT) 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: Av0EAEHIxkurR7H+/2dsb2JhbACPRYwpcaRHmiKFDgSDKQ X-IronPort-AV: E=Sophos;i="4.52,213,1270425600"; d="scan'208";a="183561020" Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-5.cisco.com with ESMTP; 15 Apr 2010 15:05:27 +0000 Received: from stealth-10-32-244-222.cisco.com (stealth-10-32-244-222.cisco.com [10.32.244.222]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o3FF5R9Q012542; Thu, 15 Apr 2010 15:05:27 GMT Subject: Re: deriving MAC address from destination Link local address without Neighbor discovery Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii From: Fred Baker In-Reply-To: <922306.68350.qm@web30108.mail.mud.yahoo.com> Date: Thu, 15 Apr 2010 08:05:26 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <922306.68350.qm@web30108.mail.mud.yahoo.com> To: Parav Pandit X-Mailer: Apple Mail (2.1078) Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Apr 2010 15:05:35 -0000 I would say that perhaps RFC 3972 updates 2464. As I perceive this, = SLAAC is how one vets an address, and addresses include an EID that can = come from one of several sources. On Apr 15, 2010, at 12:23 AM, Parav Pandit wrote: > Hi Fred, >=20 > In your reply, >> They not only come from MAC addresses, but from random number=20 >> generators... >=20 > I didn't understand "They" apply to 64-bit of link_local address or=20 > 64-bit of autoconf/dhcp address or both? >=20 > What I understood is:=20 > RFC 3972 contradicts with RFC 2464. >=20 > Or both the methods are correct for ETHERNET for Link-local and = autoconf addresses? >=20 > RFC 4291 asks to refer the Link layer specific RFC for the 64-bit = Interface Id of the link-local address - which is 2464 (for Ethernet). >=20 > So thats the confusion I have. >=20 > Or=20 > the RFC 3972 doesn't apply to the 64-bits of the Link-local addresses, = but it applies to 64-bit of the addresses configured via DHCPv6 > and/or stateless auto-conf RFCs 3315, 4862? >=20 > Regards, > Parav Pandit >=20 > --- On Thu, 4/15/10, Fred Baker wrote: >=20 >> From: Fred Baker >> Subject: Re: deriving MAC address from destination Link local address = without Neighbor discovery >> To: "Parav Pandit" >> Cc: ipv6@ietf.org >> Date: Thursday, April 15, 2010, 12:10 PM >> There has been some water that passed >> under that bridge. They not only come from MAC addresses, >> but from random number generators and cryptographic >> algorithms - and can simply be numbers assigned by >> administrators. >>=20 >> In addition to >>=20 >> 2464 Transmission of IPv6 Packets over Ethernet Networks. >> M. Crawford. >> December 1998. (Format: TXT=3D12725 >> bytes) (Obsoletes RFC1972) (Status: >> PROPOSED STANDARD) >>=20 >> take a look at >>=20 >> http://www.ietf.org/rfc/rfc3315.txt >> 3315 Dynamic Host Configuration Protocol for IPv6 (DHCPv6). >> R. Droms, >> Ed., J. Bound, B. Volz, T. Lemon, >> C. Perkins, M. Carney. July 2003. >> (Format: TXT=3D231402 bytes) >> (Updated by RFC4361, RFC5494) (Status: >> PROPOSED STANDARD) >>=20 >> http://www.ietf.org/rfc/rfc3972.txt >> 3972 Cryptographically Generated Addresses (CGA). T. Aura. >> March 2005. >> (Format: TXT=3D51473 bytes) (Updated >> by RFC4581, RFC4982) (Status: >> PROPOSED STANDARD) >>=20 >> http://www.ietf.org/rfc/rfc4291.txt >> 4291 IP Version 6 Addressing Architecture. R. Hinden, S. >> Deering. >> February 2006. (Format: TXT=3D52897 >> bytes) (Obsoletes RFC3513) (Status: >> DRAFT STANDARD) >>=20 >> http://www.ietf.org/rfc/rfc4862.txt >> 4862 IPv6 Stateless Address Autoconfiguration. S. Thomson, >> T. Narten, >> T. Jinmei. September 2007. >> (Format: TXT=3D72482 bytes) (Obsoletes >> RFC2462) (Status: DRAFT STANDARD) >>=20 >> http://www.ietf.org/rfc/rfc4941.txt >> 4941 Privacy Extensions for Stateless Address >> Autoconfiguration in >> IPv6. T. Narten, R. Draves, S. >> Krishnan. September 2007. (Format: >> TXT=3D56699 bytes) (Obsoletes >> RFC3041) (Status: DRAFT STANDARD) >>=20 >>=20 >> On Apr 14, 2010, at 10:55 PM, Parav Pandit wrote: >>=20 >>> Hi, >>>=20 >>> As per RFC 2464, Link local address for Ethernet based >> interfaces are based on the EUI-64 (derived from the MAC >> address). >>>=20 >>> I have #3 questions based on this. >>>=20 >>> In this case,=20 >>> when one Ethernet based host(from its link-local >> source) tries to ping the other Ethernet based host, it >> knows the Mac address implicitly (from the Link local >> address). >>>=20 >>> 1. Why is it required to explicitly do the Neighbor >> discovery for the link-local addresses? >>> RFC 4861 says to do the neighbor discovery even for >> link-local addresses. >>> Correct me if my understanding is incorrect. >>>=20 >>> 2. Does it mean that in Ethernet networks, interface >> can have only one Link-local address? If not then we violate >> the RFC 2464. >>>=20 >>> 3. Does RFC 4941 Privacy extension for autoconf apply >> to Ethernet interfaces? >>>=20 >>> Regards, >>> Parav Pandit >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >> -------------------------------------------------------------------- >>> IETF IPv6 working group mailing list >>> ipv6@ietf.org >>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >>>=20 >> -------------------------------------------------------------------- >>=20 >> http://www.ipinc.net/IPv4.GIF >>=20 >>=20 >=20 >=20 >=20 http://www.ipinc.net/IPv4.GIF From mohacsi@niif.hu Thu Apr 15 08:12:00 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 529893A69E3 for ; Thu, 15 Apr 2010 08:12:00 -0700 (PDT) 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 JS6UYO5vCNLy for ; Thu, 15 Apr 2010 08:11:59 -0700 (PDT) Received: from mail.ki.iif.hu (mail.ki.iif.hu [IPv6:2001:738:0:411::241]) by core3.amsl.com (Postfix) with ESMTP id 37E643A6A1B for ; Thu, 15 Apr 2010 08:11:58 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mail.ki.iif.hu (Postfix) with ESMTP id 2F23886D24; Thu, 15 Apr 2010 17:11:50 +0200 (CEST) X-Virus-Scanned: by amavisd-new at mignon.ki.iif.hu Received: from mail.ki.iif.hu ([127.0.0.1]) by localhost (mignon.ki.iif.hu [127.0.0.1]) (amavisd-new, port 10024) with LMTP id ObT+c-mYXD7l; Thu, 15 Apr 2010 17:11:43 +0200 (CEST) Received: by mail.ki.iif.hu (Postfix, from userid 9002) id CB5FE86D13; Thu, 15 Apr 2010 17:11:43 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by mail.ki.iif.hu (Postfix) with ESMTP id C4B2D86C28; Thu, 15 Apr 2010 17:11:43 +0200 (CEST) Date: Thu, 15 Apr 2010 17:11:43 +0200 (CEST) From: Mohacsi Janos X-X-Sender: mohacsi@mignon.ki.iif.hu To: Simon Perreault Subject: Re: Extracting the 5-tuple from IPv6 packets In-Reply-To: <4BC7277F.2010900@viagenie.ca> Message-ID: References: <4BC64100.303@gmail.com> <4BC71988.2040908@viagenie.ca> <4BC7245A.3000905@viagenie.ca> <4BC7277F.2010900@viagenie.ca> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Apr 2010 15:12:00 -0000 On Thu, 15 Apr 2010, Simon Perreault wrote: > On 2010-04-15 10:38, Mohacsi Janos wrote: >> Why cope with QoS if somebody is sending packets to black-hole? > > I don't understand your question, but here's an example use case of the > attack I'm suggesting: > > I want to evade an SFQ QoS for a single flow. If the QoS is based on the flow > field, I can just put random values in the flow field so that my packets > appear to come from multiple flows, which will let me get better throughput. Then we are speaking two different beasts: - you are speaking about a policed and/or rate limited flows - I was speaking about a preferential treatment of sent flows > > Many other examples come to mind... > > This usage of the flow field would need to be treated just like the DSCP > field. Maybe you can use it in some applications, not in others. But a > recommendation that all hosts on the Internet set it would be pointless if > intermediate networks can't or won't use it. That is why we are thinking of different models: Diffserv like architecture for flow field. Do we need more classes in a backbone than available in the current DSCP/diffserv model? In the diffserv model you are rewriting DSCP values at the administrative domains. Do we want to rewrite flow fields similarly? or is it e2e? Also you mark/remark packets in you aggregation network according to the services and origin. Do we want to change flow filed? Flow field is a tool for network operators to better classification or more e2e tool for applications? > > Simon > -- > NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca > STUN/TURN server --> http://numb.viagenie.ca > vCard 4.0 --> http://www.vcarddav.org > From jmh@joelhalpern.com Thu Apr 15 08:23:24 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 7F48D3A6955 for ; Thu, 15 Apr 2010 08:23:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.103 X-Spam-Level: X-Spam-Status: No, score=-2.103 tagged_above=-999 required=5 tests=[AWL=0.496, 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 gNuexp3zwfrU for ; Thu, 15 Apr 2010 08:23:21 -0700 (PDT) Received: from hgblob.mail.tigertech.net (hgblob.mail.tigertech.net [64.62.209.71]) by core3.amsl.com (Postfix) with ESMTP id 8EA7B3A696D for ; Thu, 15 Apr 2010 08:22:17 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hgblob.tigertech.net (Postfix) with ESMTP id 79C2F32358AD; Thu, 15 Apr 2010 08:22:11 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from [10.10.10.102] (pool-71-161-51-173.clppva.btas.verizon.net [71.161.51.173]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hgblob.tigertech.net (Postfix) with ESMTPSA id A2BBD3228B94; Thu, 15 Apr 2010 08:22:10 -0700 (PDT) Message-ID: <4BC72F21.2060109@joelhalpern.com> Date: Thu, 15 Apr 2010 11:22:09 -0400 From: "Joel M. Halpern" User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Mohacsi Janos Subject: Re: Extracting the 5-tuple from IPv6 packets References: <4BC64100.303@gmail.com> <4BC71988.2040908@viagenie.ca> <4BC7245A.3000905@viagenie.ca> <4BC7277F.2010900@viagenie.ca> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Apr 2010 15:23:24 -0000 There seem to be two separate things going on here, and they appear to be getting mixed. The first thing is the notion that the host should set a non-zeero value into the flow label. They should do so with the constraint that different packets which are part of the same flow MUST have the same flow label. And flows which the end host is willing to have treated (even if treated may mean simply in terms of which link in a LAG or ECMP selection is used) differently may have different flow labels. However, a network can not give QoS treatment purely on the basis of source and dest IPv6 address plus flow label. There simply is not enough information. A client provided flow label is not a DSCP code point. So networks that want to do QoS will have to do something additional. What? That depends upon what they want to do. I would hope that whatever they do it does not destroy the granularity of the flow label as described above. If we can count on hosts setting the flow label with suitable granularity, then we can use the flow label (plus src and dest IPv6 address) in our ECMP and LAG hashes without having to look for protocol and port numbers. That avoids much complexity related to next headers and similar problems. And it is not subject to an attack by someone mis-setting the flow label field. The one obvious conclusion here is that if we want hosts to actually set flow labels, then we are largely preempting network modification of those flow labels. Whatever setting we want to allow, it would have to preserve the granularity of the original flow label variation. Which is pretty hard. Now, I personally don't quite understand what the "modified flow label" proposal is for. As such, I don't mind giving it up. Particularly if I get cleaner packet processing for the normal case as a result. Yours, Joel Mohacsi Janos wrote: > > > > On Thu, 15 Apr 2010, Simon Perreault wrote: > >> On 2010-04-15 10:38, Mohacsi Janos wrote: >>> Why cope with QoS if somebody is sending packets to black-hole? >> >> I don't understand your question, but here's an example use case of >> the attack I'm suggesting: >> >> I want to evade an SFQ QoS for a single flow. If the QoS is based on >> the flow field, I can just put random values in the flow field so that >> my packets appear to come from multiple flows, which will let me get >> better throughput. > > Then we are speaking two different beasts: > - you are speaking about a policed and/or rate limited flows > - I was speaking about a preferential treatment of sent flows > >> >> Many other examples come to mind... >> >> This usage of the flow field would need to be treated just like the >> DSCP field. Maybe you can use it in some applications, not in others. >> But a recommendation that all hosts on the Internet set it would be >> pointless if intermediate networks can't or won't use it. > > That is why we are thinking of different models: > Diffserv like architecture for flow field. > > Do we need more classes in a backbone than available in the current > DSCP/diffserv model? > > In the diffserv model you are rewriting DSCP values at the > administrative domains. Do we want to rewrite flow fields similarly? or > is it e2e? > > Also you mark/remark packets in you aggregation network according to the > services and origin. Do we want to change flow filed? > > Flow field is a tool for network operators to better classification or > more e2e tool for applications? > > >> >> Simon >> -- >> NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca >> STUN/TURN server --> http://numb.viagenie.ca >> vCard 4.0 --> http://www.vcarddav.org >> > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > From remi.despres@free.fr Thu Apr 15 08:36:03 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 8AD3A3A6B2B for ; Thu, 15 Apr 2010 08:36:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.939 X-Spam-Level: X-Spam-Status: No, score=-0.939 tagged_above=-999 required=5 tests=[AWL=1.010, 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 4d1HIipxT8EA for ; Thu, 15 Apr 2010 08:36:02 -0700 (PDT) Received: from smtp6-g21.free.fr (smtp6-g21.free.fr [212.27.42.6]) by core3.amsl.com (Postfix) with ESMTP id A1C533A69DB for ; Thu, 15 Apr 2010 08:36:00 -0700 (PDT) Received: from smtp6-g21.free.fr (localhost [127.0.0.1]) by smtp6-g21.free.fr (Postfix) with ESMTP id 867DCE08083; Thu, 15 Apr 2010 17:35:49 +0200 (CEST) Received: from [192.168.0.13] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by smtp6-g21.free.fr (Postfix) with ESMTP id BFA00E08089; Thu, 15 Apr 2010 17:35:46 +0200 (CEST) Subject: Re: Extracting the 5-tuple from IPv6 packets Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: <4BC64100.303@gmail.com> Date: Thu, 15 Apr 2010 17:35:46 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4BC64100.303@gmail.com> To: Brian E Carpenter X-Mailer: Apple Mail (2.1078) Cc: Nevil Brownlee , 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, 15 Apr 2010 15:36:03 -0000 Le 15 avr. 2010 =E0 00:26, Brian E Carpenter a =E9crit : > Or we can strongly recommend that all hosts set the flow label, so > that we can use the 3-tuple {source address, dest address, flow = label}. >=20 > What do people think? In view of Mark's remark about the impossibility for routers to identify = 5-tuples of all IPv6 packets, I tend to think this is the right way to = go. But then another requirement of RFC 3697 should be relaxed: - The RFC says: "To avoid accidental Flow Label value reuse, the source = node SHOULD select new Flow Label values in a well-defined sequence" - This implies a stateful assignment of flow labels. A stateless alternative, where flow label values are just a hash of the = 5-tuple (or 3-tuple if alone to be available), should IMHO be permitted, = and not less recommended than the stateful well-defined sequence: - It permits to compute flow labels *on a per datagram basis*, just = before their being transformed into packets. - Hash functions may be different in different hosts (advices may be = welcome, but there is no need to standardize) Regards, RD From remi.despres@free.fr Thu Apr 15 08:38:32 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 C6D9E3A6B2E for ; Thu, 15 Apr 2010 08:38:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.141 X-Spam-Level: X-Spam-Status: No, score=-1.141 tagged_above=-999 required=5 tests=[AWL=0.808, 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 WKga5UXi3LOG for ; Thu, 15 Apr 2010 08:38:31 -0700 (PDT) Received: from smtp6-g21.free.fr (smtp6-g21.free.fr [212.27.42.6]) by core3.amsl.com (Postfix) with ESMTP id 80DC328C188 for ; Thu, 15 Apr 2010 08:38:28 -0700 (PDT) Received: from smtp6-g21.free.fr (localhost [127.0.0.1]) by smtp6-g21.free.fr (Postfix) with ESMTP id DE7DCE080C5; Thu, 15 Apr 2010 17:38:18 +0200 (CEST) Received: from [192.168.0.13] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by smtp6-g21.free.fr (Postfix) with ESMTP id D7479E08163; Thu, 15 Apr 2010 17:38:15 +0200 (CEST) Subject: Re: [Fwd: New Version Notification for draft-carpenter-6man-flow-update-02] Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: <20100415072936.60eb08ac@opy.nosense.org> Date: Thu, 15 Apr 2010 17:38:15 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <5C4467DE-C78E-4D2A-A69C-82999C40D983@free.fr> References: <4BC54919.3000900@gmail.com> <20100415072936.60eb08ac@opy.nosense.org> To: Mark Smith X-Mailer: Apple Mail (2.1078) 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: Thu, 15 Apr 2010 15:38:32 -0000 Le 14 avr. 2010 =E0 23:59, Mark Smith a =E9crit : > Hi Brian and Sheng, >=20 > On Wed, 14 Apr 2010 16:48:25 +1200 > Brian E Carpenter wrote: >=20 >> Hi, >>=20 >> This is completely revised from the proposal we presented >> in Anaheim. This version allows locally defined use of >> the flow label in a simpler way, as the discussion suggested. >> It's still quite a dense read, but we believe that if this was >> adopted, it would open the way to actually using the flow label. >>=20 >=20 > I've had a read through it, although not a comprehensive one, which > I'll endeavour to do in the next day or so. >=20 > I'm wondering about this change for a couple of reasons: >=20 > -- > 2. If this is done, all packets in a given flow MUST be given the > same flow label value. A flow is defined in this case as all > packets with the same source and destination IPv6 addresses and > port numbers and the same transport protocol number, i.e., the > same final Next Header value [RFC2460]. This rule constrains = the > definition of a flow in RFC 3697 for the specific case that a > router sets the flow label. However, it does not constrain the > bits of the flow label in any particular way. > -- >=20 > Firstly, if the IPv6 packets are fragments, the transport layer header > may not be available. > I think that would mean that although these > packets fragments are part of a flow, they wouldn't have their flow > label changed. Strictly speaking, it doesn't prevent routers from changing flow labels, = but it does impose that new values depend only on 3-tuples (source = address, destination address, last Next Header). In practice this limits significantly benefits to be expected from = allowing routers to modify flow labels. =20 A very good point indeed.=20 More comments to come in the next answer to Brian. RD= From behcetsarikaya@yahoo.com Thu Apr 15 08:43:26 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 A64E83A697F for ; Thu, 15 Apr 2010 08:43:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.553 X-Spam-Level: X-Spam-Status: No, score=-1.553 tagged_above=-999 required=5 tests=[AWL=0.712, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] 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 UhyAadd-bS9O for ; Thu, 15 Apr 2010 08:43:25 -0700 (PDT) Received: from web111415.mail.gq1.yahoo.com (web111415.mail.gq1.yahoo.com [67.195.15.216]) by core3.amsl.com (Postfix) with SMTP id BEEE53A6955 for ; Thu, 15 Apr 2010 08:43:24 -0700 (PDT) Received: (qmail 23363 invoked by uid 60001); 15 Apr 2010 15:43:18 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1271346198; bh=82p43z7Dxb3V2C/S02Trjn6ULWSZlL7p74QadMvEMc8=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=3fOdJLvlE+0H2ngUtDX0AfKeZsPNhSDpo0RyPqbxAsZ4hdYpckQmYQxAD6N4drMrmiGI5bZ+jmOnBZ8ws9YLQ8LbeEgno2hDDkc7wGetWniHk/sQ8KWyAFJogxiJVVCvV8Eyoe0xp1yLnOdqS36ESwDOQCrUhWYhNrP6JtFGRko= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=pC+y6hUIUVytnYPMX0W/pJRi/JBdEkaF+JugWNsmWof0+w64kc1zm/asmALNvmOu3QRfiJ5h43vD2OFgU/G6S20ITYCmFkcnndZq92qCBcLGfL4nTnLioydvxtXaBKxC7mWdD39kEU+mBTlsoVT25JM4A2Z/CXrLhs7chPDi+SM=; Message-ID: <444787.20461.qm@web111415.mail.gq1.yahoo.com> X-YMail-OSG: CQ31QLEVM1na6uIDXEoSh2xFMqx1TMJmbgo2mTsxr7ZNgAQ eGDxVkLIATXpEwFqfTsz50zztEnfBZl19EOKR.x1_5VmyGCcT6BuLeV9IOaa IUp53vqTEvEke2msUF3ZMEkvIePBj_ad7tfwpRt6XyMXVGFwqgSaufegxEYC LzvgbKKLpnyxKL0kRPqFvA3Dl5AY4Hp9fAPq7ylL8.nkH3xWLfEPNufmvIZP tJGFGf0rzrH.7SvJtvtoRBZc4WKDpt4Mv4.9jp8wIqm9XqqT6Slo1ATBsnrl MkaSmpxumA3kGBDIAy7i27K6a0yM4MruQtbWY8UQqzT4dyExe01MSpfak2be bg1oSyxLaUKsW Received: from [206.16.17.212] by web111415.mail.gq1.yahoo.com via HTTP; Thu, 15 Apr 2010 08:43:18 PDT X-Mailer: YahooMailRC/348.5 YahooMailWebService/0.8.102.267879 References: <4BC6E71C.1000102@gmail.com> Date: Thu, 15 Apr 2010 08:43:18 -0700 (PDT) From: Behcet Sarikaya Subject: Re: Comments on draft-carpenter-6man-flow-update-02 To: Alexandru Petrescu , 6MAN In-Reply-To: <4BC6E71C.1000102@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Behcet Sarikaya List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Apr 2010 15:43:26 -0000 I agree with Alex's comments.=0A=0AI think that flow label field in IPv6 he= ader is IPv6 design's soft underbelly. I can understand and appreciate Bria= n Carpenter's efforts on trying to resolve this issue.=0A=0AMy suggestion f= or Mext (and Netext) usage is to assign the first 16 bits of the flow label= as FID.=0A=0ARegards,=0A=0ABehcet=0A=0A=0A----- Original Message ----=0A> = From: Alexandru Petrescu =0A> To: 6MAN =0A> Sent: Thu, April 15, 2010 5:14:52 AM=0A> Subject: Comments on= draft-carpenter-6man-flow-update-02=0A> =0A> Hello Authors of draft-carpen= ter-6man-flow-update-02 =0A> at=0Ahttp://tools.ietf.org/html/draft-carpente= r-6man-flow-update-02=0A=0AI =0A> have some comments.=0A=0A=A0 "a.=A0 "The = Flow Label value set by the =0A> source MUST be delivered=0A=A0 =A0 =A0 unc= hanged...=0A=A0 b.=A0 =0A> "IPv6 nodes MUST NOT assume any mathematical or = other=0A=A0 =A0 =A0 =0A> properties...=0A=A0 c.=A0 "Router performance SHOU= LD NOT be dependent on =0A> the distribution=0A=A0 =A0 =A0 of the Flow Labe= l values...=0A=0AThe =0A> second two rules appear to forbid a usage in whic= h... However,=0Aboth before =0A> and after these rules were laid down, a co= nsiderable=0Anumber of proposals for =0A> use of the flow label have been p= ublished...=0AExamples... These authors =0A> propose use cases in which som= e combination=0Aof the following options apply: =0A> o=A0 The flow label ma= y be changed by=0Aintermediate =0A> systems..."=0A=0AEr?=A0 The logic sound= s flawed.=A0 You seem to be =0A> saying that earlier=0AAuthors complained a= bout "b" and "c".=A0 But then you =0A> say they suggested a=0Asolution wher= e "a" is addressed too.=A0 So actually =0A> they complained about=0A"a" too= ?=A0 Not sure I understand what they =0A> wanted.=0A=0A> The purpose of the= proposed change is that the flow label =0A> should be=0A> available for do= main-specific use, with locally defined =0A> semantics,=0A> without prevent= ing uses that are compatible with RFC =0A> 3697.=0A=0AOk, but then make sur= e one considers coherently a Host being _in_ =0A> xor=0A_out_ of that domai= n.=A0 Sometimes these usages can be mixed.=A0 If =0A> we say a=0AHost _with= in_ the domain will _not_ set the Flow Label then we can't =0A> say=0Athat = the intermediary Routers within that domain will change it: =0A> because=0A= it's hard to imagine a Router is not a Host at the same =0A> time.=0A=0A> 1= .=A0 If and only if the flow label in an IPv6 packet has =0A> the default= =0A> value of zero, then a router MAY set it to a value between =0A> betwee= n 1=0A>=A0 and 0xFFFFF.=A0 This option modifies the rule that =0A> the flow= label must=0A>=A0 be delivered unchanged, by allowing exactly =0A> one rou= ter to set it if=0A>=A0 the source host did not set it.=0A=0AI =0A> believe= this may pose problems.=A0 The case is when the sending Host1=0Adoes =0A> = not set the Flow Label and the receiving Host2 knows somehow (e.g.=0Athe ap= p =0A> protocol is older than new Flow Labels) that H1 doesn't=0Aimplement = Flow Labels =0A> and so expects "0" zero from it.=A0 When H2 sees a=0Aflow = label set then it =0A> deduces something is wrong, because it knows H1=0Aco= uldn't set it.=0A=0AIn =0A> RPL there's talk proposing "restoration" of the= Flow Label at the=0Aexit point, =0A> but I don't agree with that either.= =0A=0A> packets leaving the local domain =0A> may contain flow label values= that=0A> are not pseudo-random=0A=0AFor some =0A> reason I have difficulty= understanding "not pseudo-radom": does=0Ait mean =0A> actually "random", i= nterpreted as a double negation?=A0 Does it=0Amean "not =0A> random but can= 't talk random because true random doesn't=0Aexist"?=A0 The =0A> implicatio= ns of this clarification are wide I believe.=0A=0A> The flow =0A> label is = not protected in any way and can be forged by an=0A> on-path =0A> attacker.= =A0 On the other hand, a pseudo-random flow label=0A> cannot be =0A> readil= y guessed by an off-path attacker.=0A=0AThat "OTOH" makes think that =0A> b= ecause pseudo-random flow labels cannot be=0Aguessed then the Flow Label is= =0A> protected against on-path attackers.=A0 I=0Adon't think much protecti= on is =0A> afforded by the use of visible be them=0Arandom numbers.=A0 Were= it =0A> public-private-keys then yes but here we don't=0Atalk Flow Labels = as security =0A> keys, at least because of the obvious=0Aperformance =0A> r= equirements.=0A=0AAlex=0A=0A-----------------------------------------------= ---------------------=0AIETF =0A> IPv6 working group mailing list=0A> href= =3D"mailto:ipv6@ietf.org">ipv6@ietf.org=0AAdministrative Requests: > href= =3D"https://www.ietf.org/mailman/listinfo/ipv6" target=3D_blank =0A> >https= ://www.ietf.org/mailman/listinfo/ipv6=0A-----------------------------------= ---------------------------------=0A=0A=0A From slblake@petri-meat.com Thu Apr 15 08:47:03 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 886323A6BA2 for ; Thu, 15 Apr 2010 08:47:03 -0700 (PDT) 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 GY+g4Xx0dwjK for ; Thu, 15 Apr 2010 08:47:02 -0700 (PDT) Received: from elom.tchmachines.com (elom.tchmachines.com [208.76.80.198]) by core3.amsl.com (Postfix) with ESMTP id 9A34C28C1E5 for ; Thu, 15 Apr 2010 08:46:13 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=petri-meat.com) by elom.tchmachines.com with esmtpa (Exim 4.69) (envelope-from ) id 1O2RGK-0007AG-Al; Thu, 15 Apr 2010 11:45:52 -0400 MIME-Version: 1.0 Date: Thu, 15 Apr 2010 11:45:52 -0400 From: Steven Blake To: "Joel M. Halpern" Subject: Re: Extracting the 5-tuple from IPv6 packets In-Reply-To: <4BC72F21.2060109@joelhalpern.com> References: <4BC64100.303@gmail.com> <4BC71988.2040908@viagenie.ca> <4BC7245A.3000905@viagenie.ca> <4BC7277F.2010900@viagenie.ca> <4BC72F21.2060109@joelhalpern.com> Message-ID: X-Sender: slblake@petri-meat.com User-Agent: RoundCube Webmail/0.3.1 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - elom.tchmachines.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - petri-meat.com Cc: ipv6@ietf.org, Mohacsi Janos 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, 15 Apr 2010 15:47:03 -0000 On Thu, 15 Apr 2010 11:22:09 -0400, "Joel M. Halpern" wrote: > The one obvious conclusion here is that if we want hosts to actually set > flow labels, then we are largely preempting network modification of > those flow labels. Whatever setting we want to allow, it would have to > preserve the granularity of the original flow label variation. Which is > pretty hard. > Now, I personally don't quite understand what the "modified flow label" > proposal is for. As such, I don't mind giving it up. Particularly if I > get cleaner packet processing for the normal case as a result. +1 // Steve From mohacsi@niif.hu Thu Apr 15 08:59:17 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 B57C63A6767 for ; Thu, 15 Apr 2010 08:59:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8shMTCtL2Ck6 for ; Thu, 15 Apr 2010 08:59:17 -0700 (PDT) Received: from mail.ki.iif.hu (mail.ki.iif.hu [IPv6:2001:738:0:411::241]) by core3.amsl.com (Postfix) with ESMTP id 9FD2F3A698D for ; Thu, 15 Apr 2010 08:59:15 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mail.ki.iif.hu (Postfix) with ESMTP id ADA0D86CA8; Thu, 15 Apr 2010 17:59:07 +0200 (CEST) X-Virus-Scanned: by amavisd-new at mignon.ki.iif.hu Received: from mail.ki.iif.hu ([127.0.0.1]) by localhost (mignon.ki.iif.hu [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 1S0YSAOgLYOJ; Thu, 15 Apr 2010 17:59:05 +0200 (CEST) Received: by mail.ki.iif.hu (Postfix, from userid 9002) id 0349786C28; Thu, 15 Apr 2010 17:59:05 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by mail.ki.iif.hu (Postfix) with ESMTP id 014AA86C05; Thu, 15 Apr 2010 17:59:04 +0200 (CEST) Date: Thu, 15 Apr 2010 17:59:04 +0200 (CEST) From: Mohacsi Janos X-X-Sender: mohacsi@mignon.ki.iif.hu To: "Joel M. Halpern" Subject: Re: Extracting the 5-tuple from IPv6 packets In-Reply-To: <4BC72F21.2060109@joelhalpern.com> Message-ID: References: <4BC64100.303@gmail.com> <4BC71988.2040908@viagenie.ca> <4BC7245A.3000905@viagenie.ca> <4BC7277F.2010900@viagenie.ca> <4BC72F21.2060109@joelhalpern.com> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Apr 2010 15:59:17 -0000 On Thu, 15 Apr 2010, Joel M. Halpern wrote: > There seem to be two separate things going on here, and they appear to be > getting mixed. > > The first thing is the notion that the host should set a non-zeero value into > the flow label. They should do so with the constraint that different packets > which are part of the same flow MUST have the same flow label. And flows > which the end host is willing to have treated (even if treated may mean > simply in terms of which link in a LAG or ECMP selection is used) differently > may have different flow labels. > > However, a network can not give QoS treatment purely on the basis of source > and dest IPv6 address plus flow label. There simply is not enough > information. A client provided flow label is not a DSCP code point. > > So networks that want to do QoS will have to do something additional. What? > That depends upon what they want to do. I would hope that whatever they do > it does not destroy the granularity of the flow label as described above. > > If we can count on hosts setting the flow label with suitable granularity, > then we can use the flow label (plus src and dest IPv6 address) in our ECMP > and LAG hashes without having to look for protocol and port numbers. That > avoids much complexity related to next headers and similar problems. And it > is not subject to an attack by someone mis-setting the flow label field. I understand similarly as you. Best Regards, Janos Mohacsi From albert.e.manfredi@boeing.com Thu Apr 15 10:08:29 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 AC2B828C1EE for ; Thu, 15 Apr 2010 10:08:29 -0700 (PDT) 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 ppRX8dctiwu6 for ; Thu, 15 Apr 2010 10:08:28 -0700 (PDT) Received: from slb-smtpout-01.boeing.com (slb-smtpout-01.boeing.com [130.76.64.48]) by core3.amsl.com (Postfix) with ESMTP id E114228C205 for ; Thu, 15 Apr 2010 10:08:25 -0700 (PDT) Received: from slb-av-01.boeing.com (slb-av-01.boeing.com [129.172.13.4]) by slb-smtpout-01.ns.cs.boeing.com (8.14.4/8.14.4/8.14.4/SMTPOUT) with ESMTP id o3FH8Hjc003909 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 15 Apr 2010 10:08:17 -0700 (PDT) Received: from slb-av-01.boeing.com (localhost [127.0.0.1]) by slb-av-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_RELAY) with ESMTP id o3FH8GZG002290; Thu, 15 Apr 2010 10:08:16 -0700 (PDT) Received: from XCH-MWHT-05.mw.nos.boeing.com (xch-mwht-05.mw.nos.boeing.com [134.57.119.160]) by slb-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id o3FH7sxA001634 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Thu, 15 Apr 2010 10:08:16 -0700 (PDT) Received: from XCH-MW-08V.mw.nos.boeing.com ([134.57.119.191]) by XCH-MWHT-05.mw.nos.boeing.com ([134.57.119.160]) with mapi; Thu, 15 Apr 2010 12:08:05 -0500 From: "Manfredi, Albert E" To: "Joel M. Halpern" Date: Thu, 15 Apr 2010 12:08:04 -0500 Subject: RE: Extracting the 5-tuple from IPv6 packets Thread-Topic: Extracting the 5-tuple from IPv6 packets Thread-Index: AcrcvANnv/00Z/JbS0WvMhXXUU25TgAAMGVA Message-ID: References: <4BC64100.303@gmail.com><4BC71988.2040908@viagenie.ca> <4BC7245A.3000905@viagenie.ca > <4BC7277F.2010900@ viagenie.ca> <4BC72F21.2060109@joelhalpern.com> In-Reply-To: <4BC72F21.2060109@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: Thu, 15 Apr 2010 17:08:29 -0000 > -----Original Message----- > From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On=20 > If we can count on hosts setting the flow label with suitable=20 > granularity, then we can use the flow label (plus src and dest IPv6=20 > address) in our ECMP and LAG hashes without having to look=20 > for protocol=20 > and port numbers. That avoids much complexity related to=20 > next headers=20 > and similar problems. And it is not subject to an attack by someone=20 > mis-setting the flow label field. >=20 > The one obvious conclusion here is that if we want hosts to=20 > actually set=20 > flow labels, then we are largely preempting network modification of=20 > those flow labels. Looks to me like this is true as well. In Brian's I-D 02, an edge router at= the destination side would be able to tell whether the flow label had been= set by a source host or an intervening router. So, that makes flow labels = unusable for end-to-end QoS. Question: if we don't want to specify different flow label ranges, e.g. to = show whether the lable was set by a host vs the ISP's network, then isn't t= here a combination of flow label and traffic class that could accomplish th= is? Something like this could be an option, instead of using the traditiona= l 5-tuples? Bert From albert.e.manfredi@boeing.com Thu Apr 15 10:13:19 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 8929C3A6A09 for ; Thu, 15 Apr 2010 10:13:19 -0700 (PDT) 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 OHlE7lOtzTzX for ; Thu, 15 Apr 2010 10:13:17 -0700 (PDT) Received: from stl-smtpout-01.boeing.com (stl-smtpout-01.boeing.com [130.76.96.56]) by core3.amsl.com (Postfix) with ESMTP id 7FB5C28C1CC for ; Thu, 15 Apr 2010 10:13:02 -0700 (PDT) Received: from slb-av-01.boeing.com (slb-av-01.boeing.com [129.172.13.4]) by stl-smtpout-01.ns.cs.boeing.com (8.14.4/8.14.4/8.14.4/SMTPOUT) with ESMTP id o3FHCnV4015808 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 15 Apr 2010 12:12:50 -0500 (CDT) Received: from slb-av-01.boeing.com (localhost [127.0.0.1]) by slb-av-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_RELAY) with ESMTP id o3FHCmYp011297; Thu, 15 Apr 2010 10:12:48 -0700 (PDT) Received: from XCH-MWHT-03.mw.nos.boeing.com (xch-mwht-03.mw.nos.boeing.com [134.57.119.161]) by slb-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id o3FHClKJ011269 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Thu, 15 Apr 2010 10:12:48 -0700 (PDT) Received: from XCH-MW-08V.mw.nos.boeing.com ([134.57.119.191]) by XCH-MWHT-03.mw.nos.boeing.com ([134.57.119.161]) with mapi; Thu, 15 Apr 2010 12:12:47 -0500 From: "Manfredi, Albert E" To: "Joel M. Halpern" Date: Thu, 15 Apr 2010 12:12:46 -0500 Subject: RE: Extracting the 5-tuple from IPv6 packets Thread-Topic: Extracting the 5-tuple from IPv6 packets Thread-Index: AcrcvANnv/00Z/JbS0WvMhXXUU25TgAAMGVAAAB7HVA= Message-ID: References: <4BC64100.303@gmail.com><4BC71988.2040908@viagenie.ca> <4BC7245A.3000905@viagenie.ca > <4BC7277F.2010900@ viagenie.ca><4BC72F21.2060109@joelhalpern.com> 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 Cc: "ipv6@ietf.org" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Apr 2010 17:13:19 -0000 I meant, "In Brian's I-D 02, an edge router at the destination side would *NOT* be a= ble to tell whether the flow label had been set by a source host or an inte= rvening router." Bert -----Original Message----- From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of Man= fredi, Albert E Sent: Thursday, April 15, 2010 1:08 PM To: Joel M. Halpern Cc: ipv6@ietf.org Subject: RE: Extracting the 5-tuple from IPv6 packets > -----Original Message----- > From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On=20 > If we can count on hosts setting the flow label with suitable=20 > granularity, then we can use the flow label (plus src and dest IPv6=20 > address) in our ECMP and LAG hashes without having to look=20 > for protocol=20 > and port numbers. That avoids much complexity related to=20 > next headers=20 > and similar problems. And it is not subject to an attack by someone=20 > mis-setting the flow label field. >=20 > The one obvious conclusion here is that if we want hosts to=20 > actually set=20 > flow labels, then we are largely preempting network modification of=20 > those flow labels. Looks to me like this is true as well. In Brian's I-D 02, an edge router at= the destination side would *not* be able to tell whether the flow label ha= d been set by a source host or an intervening router. So, that makes flow l= abels unusable for end-to-end QoS. Question: if we don't want to specify different flow label ranges, e.g. to = show whether the lable was set by a host vs the ISP's network, then isn't t= here a combination of flow label and traffic class that could accomplish th= is? Something like this could be an option, instead of using the traditiona= l 5-tuples? Bert -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From shane@castlepoint.net Thu Apr 15 10:38:10 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 7DADE3A680A for ; Thu, 15 Apr 2010 10:38:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.312 X-Spam-Level: X-Spam-Status: No, score=-2.312 tagged_above=-999 required=5 tests=[AWL=0.287, 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 Chltj0aPAB3M for ; Thu, 15 Apr 2010 10:38:09 -0700 (PDT) Received: from dog.tcb.net (dog.tcb.net [64.78.150.133]) by core3.amsl.com (Postfix) with ESMTP id 972993A66B4 for ; Thu, 15 Apr 2010 10:38:09 -0700 (PDT) Received: by dog.tcb.net (Postfix, from userid 0) id CDD102684EA; Thu, 15 Apr 2010 11:38:02 -0600 (MDT) Received: from mbpw.castlepoint.net (71-215-81-125.hlrn.qwest.net [71.215.81.125]) (authenticated-user smtp) (TLSv1/SSLv3 AES128-SHA 128/128) by dog.tcb.net with SMTP; Thu, 15 Apr 2010 11:38:02 -0600 (MDT) (envelope-from shane@castlepoint.net) X-Avenger: version=0.7.8; receiver=dog.tcb.net; client-ip=71.215.81.125; client-port=60785; syn-fingerprint=65535:56:1:64:M1452,N,W1,N,N,T,S; data-bytes=0 Subject: Re: Extracting the 5-tuple from IPv6 packets Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii From: Shane Amante In-Reply-To: Date: Thu, 15 Apr 2010 11:37:46 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <98CE51B7-EDE8-401D-BAF4-27FD912FF115@castlepoint.net> References: <4BC64100.303@gmail.com><4BC71988.2040908@viagenie.ca> <4BC7245A.3000905@viagenie.ca > <4BC7277F.2010900@ viagenie.ca><4BC72F21.2060109@joelhalpern.com> To: "Manfredi, Albert E" X-Mailer: Apple Mail (2.1078) Cc: "ipv6@ietf.org" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Apr 2010 17:38:10 -0000 Bert, On Apr 15, 2010, at 11:12 MDT, Manfredi, Albert E wrote: > I meant, >=20 > "In Brian's I-D 02, an edge router at the destination side would *NOT* = be able to tell whether the flow label had been set by a source host or = an intervening router." >=20 > Bert >=20 > -----Original Message----- > From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf = Of Manfredi, Albert E > Sent: Thursday, April 15, 2010 1:08 PM > To: Joel M. Halpern > Cc: ipv6@ietf.org > Subject: RE: Extracting the 5-tuple from IPv6 packets >=20 >> -----Original Message----- >> From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On=20 >=20 >> If we can count on hosts setting the flow label with suitable=20 >> granularity, then we can use the flow label (plus src and dest IPv6=20= >> address) in our ECMP and LAG hashes without having to look=20 >> for protocol=20 >> and port numbers. That avoids much complexity related to=20 >> next headers=20 >> and similar problems. And it is not subject to an attack by someone=20= >> mis-setting the flow label field. >>=20 >> The one obvious conclusion here is that if we want hosts to=20 >> actually set=20 >> flow labels, then we are largely preempting network modification of=20= >> those flow labels. >=20 > Looks to me like this is true as well. In Brian's I-D 02, an edge = router at the destination side would *not* be able to tell whether the = flow label had been set by a source host or an intervening router. So, = that makes flow labels unusable for end-to-end QoS. >=20 > Question: if we don't want to specify different flow label ranges, = e.g. to show whether the lable was set by a host vs the ISP's network, = then isn't there a combination of flow label and traffic class that = could accomplish this? Something like this could be an option, instead = of using the traditional 5-tuples? Or, better, (re-)acknowledge RFC 2474, a.k.a. DiffServ, is the sole go = forward mechanism for CoS treatment, meaning PHB's/treatments are to be = based only on the IP Traffic Class field. The industry seems to have at = least implicitly acknowledged that more granular, IntServ-type signaling = (perhaps, the original intent of the flow-label?) aren't scalable in the = IPv4 Internet and, likely, IPv6 Internet as well. Thus, we should move = on to a more appropriate use of a IPv6 flow-label? -shane= From simon.perreault@viagenie.ca Thu Apr 15 10:40:24 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 A5D473A6A05 for ; Thu, 15 Apr 2010 10:40:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-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 HXKQhJAktVo1 for ; Thu, 15 Apr 2010 10:40:23 -0700 (PDT) Received: from jazz.viagenie.ca (unknown [IPv6:2620:0:230:8000:226:55ff:fe57:14db]) by core3.amsl.com (Postfix) with ESMTP id EDDE73A6A5E for ; Thu, 15 Apr 2010 10:40:22 -0700 (PDT) Received: from ringo.viagenie.ca (ringo.viagenie.ca [IPv6:2620:0:230:c000::67]) by jazz.viagenie.ca (Postfix) with ESMTPSA id C1D0520EE1; Thu, 15 Apr 2010 13:40:15 -0400 (EDT) Message-ID: <4BC74F7F.6060007@viagenie.ca> Date: Thu, 15 Apr 2010 13:40:15 -0400 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.9) Gecko/20100330 Fedora/3.0.4-1.fc12 Thunderbird/3.0.4 MIME-Version: 1.0 To: "Joel M. Halpern" Subject: Re: Extracting the 5-tuple from IPv6 packets References: <4BC64100.303@gmail.com> <4BC71988.2040908@viagenie.ca> <4BC7245A.3000905@viagenie.ca> <4BC7277F.2010900@viagenie.ca> <4BC72F21.2060109@joelhalpern.com> In-Reply-To: <4BC72F21.2060109@joelhalpern.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: ipv6@ietf.org, Mohacsi Janos 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, 15 Apr 2010 17:40:24 -0000 On 2010-04-15 11:22, Joel M. Halpern wrote: > However, a network can not give QoS treatment purely on the basis of > source and dest IPv6 address plus flow label. There simply is not enough > information. A client provided flow label is not a DSCP code point. My point with comparing this proposal with DSCP was that you cannot trust a host to do it in good faith in both cases. With DSCP, since hosts can trivially set the "fast bit", networks filter it at the edge. Same goes for the flow label if used for QoS. Other than that, I agree with your assessment. Thanks, Simon -- NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca vCard 4.0 --> http://www.vcarddav.org From brian@innovationslab.net Thu Apr 15 10:41:07 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 8E86928C199 for ; Thu, 15 Apr 2010 10:41:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.74 X-Spam-Level: X-Spam-Status: No, score=-0.74 tagged_above=-999 required=5 tests=[BAYES_20=-0.74] 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 9BWtYOWST1jB for ; Thu, 15 Apr 2010 10:41:06 -0700 (PDT) Received: from uillean.fuaim.com (uillean.fuaim.com [206.197.161.140]) by core3.amsl.com (Postfix) with ESMTP id 07AD328C1D5 for ; Thu, 15 Apr 2010 10:41:05 -0700 (PDT) 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 9F3F288245 for ; Thu, 15 Apr 2010 10:40:58 -0700 (PDT) Received: from clemson.jhuapl.edu (unknown [128.244.207.66]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by clairseach.fuaim.com (Postfix) with ESMTP id 29F38130002 for ; Thu, 15 Apr 2010 10:40:58 -0700 (PDT) Message-ID: <4BC74FA8.7080001@innovationslab.net> Date: Thu, 15 Apr 2010 13:40:56 -0400 From: Brian Haberman User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: ipv6@ietf.org Subject: Re: [Fwd: New Version Notification for draft-carpenter-flow-ecmp-02] References: <4BC69BCB.8080701@gmail.com> <35A5E745-D613-4C74-A0DB-0540F13A40BE@castlepoint.net> In-Reply-To: <35A5E745-D613-4C74-A0DB-0540F13A40BE@castlepoint.net> 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, 15 Apr 2010 17:41:07 -0000 Hi Shane, On 4/15/10 1:25 AM, Shane Amante wrote: > > More generally, this really raises the question of the practicality > of searching for Layer-4 protocol, source & destination port info in > headers and using them as input keys for LAG + ECMP when forwarding > IPv6, particularly on high-speed core routers. Ultimately, if the > flow-label was known to denote a proper "microflow" (as defined by > RFC 2474), then it would make HW implementations much simpler in that > they have a known & fixed set of header fields, specifically: {dest > address, src address + flow-label}, they would use as input keys for > LAG + ECMP. Arguably, it makes adding Extension Headers easier in > the future, as well, given that we don't have to worry as much about > intermediate routers being unable to look past them ... Of course, > the downside is this effectively boxes out any other (future) use of > the flow-label. Thoughts? This type of scenario is what prompted my question to Brian C. at the mic in Anaheim. In a previous life, I was looking at ways to leverage ECMP for IPv6 traffic when the traditional 5-tuple was unavailable. Typically, this was due to the payload being encrypted. The only sane way was to hash as long as the Flow Label was set by the originating host. The prototype I hacked together on the host side set the flow label per socket. I also threw together a Quagga-based marking box that did the DPI on unencrypted packets and assigned a unique Flow Label per in order to allow boxes doing ECMP to use the Flow Label-based 3-tuple. The cost of doing the DPI to mark the packets was quite heavy given the arbitrary extension headers I threw at it. In the long run, I believe we need a way to create ECMP & LAG hashes out of *just* the base IPv6 header fields given these constraints on finding the layer-4 information and the limitation that some routers have of not having the entire packet available for searching. Regards, Brian From ipng@69706e6720323030352d30312d31340a.nosense.org Thu Apr 15 13:39:24 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 91E573A699D for ; Thu, 15 Apr 2010 13:39:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.706 X-Spam-Level: X-Spam-Status: No, score=-1.706 tagged_above=-999 required=5 tests=[AWL=0.189, 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 vQUgPpfMq24a for ; Thu, 15 Apr 2010 13:39:23 -0700 (PDT) Received: from smtp3.adam.net.au (smtp3.adam.net.au [202.136.110.249]) by core3.amsl.com (Postfix) with ESMTP id 24EB33A680A for ; Thu, 15 Apr 2010 13:39:15 -0700 (PDT) Received: from 219-90-234-216.ip.adam.com.au ([219.90.234.216] helo=opy.nosense.org) by smtp3.adam.net.au with esmtp (Exim 4.63) (envelope-from ) id 1O2Vq2-0008MQ-86; Fri, 16 Apr 2010 06:09:02 +0930 Received: from opy.nosense.org (localhost.localdomain [IPv6:::1]) by opy.nosense.org (Postfix) with ESMTP id 097B64922D; Fri, 16 Apr 2010 06:09:01 +0930 (CST) Date: Fri, 16 Apr 2010 06:08:57 +0930 From: Mark Smith To: Shane Amante Subject: Re: [Fwd: New Version Notification for draft-carpenter-6man-flow-update-02] Message-ID: <20100416060857.278fb126@opy.nosense.org> In-Reply-To: References: <4BC54919.3000900@gmail.com> <20100415072936.60eb08ac@opy.nosense.org> <4BC63DF0.6070707@gmail.com> <4BC68D6F.8070500@gmail.com> <20100415200643.58449671@opy.nosense.org> X-Mailer: Claws Mail 3.7.5 (GTK+ 2.20.0; x86_64-unknown-linux-gnu) X-Location: Lower Mitcham, South Australia, 5062 Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: 6man , 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: Thu, 15 Apr 2010 20:39:24 -0000 On Thu, 15 Apr 2010 08:34:40 -0600 Shane Amante wrote: > Hi Mark, > > On Apr 15, 2010, at 04:36 MDT, Mark Smith wrote: > > Hi Brian, Shane, > > > > On Thu, 15 Apr 2010 15:52:15 +1200 > > Brian E Carpenter wrote: > > > >> > >> Regards > >> Brian Carpenter > >> > >> > >> > >> > >> On 2010-04-15 14:10, Shane Amante wrote: > >>> Brian, Mark, > >>> > >>> Brian: FWIW, I like the direction of this version of draft > >>> much better than previous versions; however, I agree with > >>> Remi that the current version is a bit confusing at the > >>> moment and could likely be rewritten to be more simple and > >>> just obsolete RFC 3967. In addition, I'm still a bit unclear > >>> and, therefore, uncomfortable on the proposal with respect to > >>> flow-labels within an "administratively defined domain". In > >>> particular, if one administrative domain has set their own > >>> "locally defined" flow-label, I think the draft could benefit > >>> from a stronger emphasis that the flow-label MUST or, at > >>> least, SHOULD be reset to 0 upon /leaving/ that domain, > >>> otherwise the next domain may (or, will?) misinterpret the > >>> meaning of the incoming "locally-defined" flow-label. The > >> > >> I'm personally quite attracted by this. It does further damage > >> to the sacred principle that the flow label is immutable, > >> but maybe that is the inevitable result anyway. > >> > > > > I think the way the dscp is handled provides a good example. If your > > network is QoS enabled, then you reset the dscp value upon ingress > > because you can't trust it, otherwise you completely ignore the value of > > it as it traverses your network. I think the same model can be applied > > to flow labels. > > I believe we're in agreement on the above point. > > > > For an ISP, if it considered it's network to be a separate flow domain > > from that of it's customers' networks (and my position is that I > > would, for both business and residential customers), then every egress > > interface towards a customer would have to be resetting the flow label. > > ISPs with many PPPoE/PPP customers have as many virtual egress > > interfaces as they do customers. I think a lot of those customers > > wouldn't implement a flow domain, so having every virtual interface > > reset the flow label back to 0 on packet egress would be a relatively > > high price for the value it provides to only a small number of > > customers. > > I acknowledge the operational burden of resetting the flow-label on egress; however, the same challenge exists on ingress, as well. IOW, if you don't trust the flow-label setting coming from another "administratively defined domain" (ADD), then you'll always need to have to reset (and/or set) it on ingress before it transits your ADD ... wh/ would translate into roughly the same problem. > You're right, I've been influenced by my past experience. In that (IPv4) scenario, dscp was set when traffic entered via the ISP transit links and that was for billing purposes. Traffic coming from customers had the dscp values left alone. As long resetting it on egress was an option operation, I think it would facilitate both points of view. (That dscp for billing idea was implemented before I started at that organisation. I didn't mind the idea of labelling packets to categorise them, however I didn't like using the dscp, as that has a specific QoS meaning. The flow label field seems to me to be a bit more general purpose, so I'd think the flow label would be the right field to use in that scenario) > Regardless, the way the draft is written now it still seems a bit ambiguous (at best) as to whether the next, downstream "administratively defined domain" (ADD) is supposed to accept "as-is" the incoming, perhaps locally-defined in another ADD, flow-label or not. Most importantly consideration should be given to what the operational implications will be if that were the case. IOW, it could result in very poor load-balancing if the incoming locally-defined flow-label does not correspond to, say, a 5-tuple "microflow" and, instead, means something else entirely (e.g.: a "nonce" as per one of the many proposals to recast/re-use/abuse the flow-label). > > The reason I offered the proposed text was to make it abundantly clear that there should be no assumptions made about the flow-label once it leaves one "administratively defined domain", since one ADD can't tell if it's locally-defined or not. In summary, I think the text could stand to be made more clear that a flow-label needs to be reset /either/ on egress from or ingress to an ADD[1]. I think, in practice, you're likely correct that most operators would probably (re)set it only on ingress (similar to IP DSCP or IPv6 TC), since that's a common operation. > > Lastly, FWIW, I'd personally rather not carve out a bit in the flow-label (as was discussed in previous revisions of this draft), for "locally-defined" flow-labels since the same operational problem exists. Only in that case, as a packet enters my ADD I won't be able to do anything with it. This means I need to have even more complex logic in routers to ignore those flow-labels with that bit set and then attempt to look for Layer-4 Transport header info at every hop for load-balancing calculations. > > -shane > > [1] I should note that if one or more "consenting" ADD's want to exchange a locally defined flow-label between them, then that's their right, i.e.: your network(s), your rules. However, I would typically expect this to be an exception, not the rule, given the implications a misunderstanding or misinterpretation a "locally-defined" flow-label might have. Regards, Mark. From brian.e.carpenter@gmail.com Thu Apr 15 15:23:08 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 064903A6AAA for ; Thu, 15 Apr 2010 15:23:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.34 X-Spam-Level: X-Spam-Status: No, score=-2.34 tagged_above=-999 required=5 tests=[AWL=0.259, 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 JoXSnlnWIJlo for ; Thu, 15 Apr 2010 15:23:06 -0700 (PDT) Received: from mail-pz0-f193.google.com (mail-pz0-f193.google.com [209.85.222.193]) by core3.amsl.com (Postfix) with ESMTP id C9E473A6AAB for ; Thu, 15 Apr 2010 15:22:46 -0700 (PDT) Received: by pzk31 with SMTP id 31so873715pzk.31 for ; Thu, 15 Apr 2010 15:22:36 -0700 (PDT) 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=Fv2ImcOLWEfDzEEcNSWiqDW+BQlNQCdINQPyLiXThY8=; b=Z0CMsAFAsS9U6mH8oc3Lx7NlngLTJxoP98BqU8cdV9s7Xq1LujILXjSYfkGrzlBEqb +BdIkbf1bvOzUbbK0iSI/Q07rTFfQRY4wnqbHqqM/7ohps3UXJauYyD4nCyshwDvX1A9 3pIc138Xy0VsH6QAsOVpd1eecIG7GsDBa2by0= 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=uM6cVNe7TedGczTUJalVOIQLKEbqdGs4NH7n8y+86ZifQ9/kgkFTnXbBHw3GorcQM0 VQ7JdzZk/pBETga+LRoAowxy7kKv8C5zvWMR6dJ0NV2HPvOhY6x4V4+de6WYhv7en57l 5Rw+oCAComMjFAGqBMWDU3v5IF2l2m1wbPq4M= Received: by 10.115.148.18 with SMTP id a18mr863401wao.229.1271370156232; Thu, 15 Apr 2010 15:22:36 -0700 (PDT) Received: from [130.216.38.124] (stf-brian.sfac.auckland.ac.nz [130.216.38.124]) by mx.google.com with ESMTPS id 22sm1657612pzk.1.2010.04.15.15.22.34 (version=SSLv3 cipher=RC4-MD5); Thu, 15 Apr 2010 15:22:35 -0700 (PDT) Message-ID: <4BC791A8.4090105@gmail.com> Date: Fri, 16 Apr 2010 10:22:32 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Simon Perreault Subject: Re: Extracting the 5-tuple from IPv6 packets References: <4BC64100.303@gmail.com> <4BC71988.2040908@viagenie.ca> <4BC7245A.3000905@viagenie.ca> <4BC7277F.2010900@viagenie.ca> <4BC72F21.2060109@joelhalpern.com> <4BC74F7F.6060007@viagenie.ca> In-Reply-To: <4BC74F7F.6060007@viagenie.ca> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: ipv6@ietf.org, Mohacsi Janos 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, 15 Apr 2010 22:23:08 -0000 Simon, On 2010-04-16 05:40, Simon Perreault wrote: > On 2010-04-15 11:22, Joel M. Halpern wrote: >> However, a network can not give QoS treatment purely on the basis of >> source and dest IPv6 address plus flow label. There simply is not enough >> information. A client provided flow label is not a DSCP code point. > > My point with comparing this proposal with DSCP was that you cannot > trust a host to do it in good faith in both cases. With DSCP, since > hosts can trivially set the "fast bit", networks filter it at the edge. > Same goes for the flow label if used for QoS. If used as an *encoded* field for QoS. Exactly. That's why the idea can be boiled down to: For generic use, set a pseudo-random label per flow. (forging it won't help you very much ;-) For local use, set an *encoded* value meaning whatever you want, but don't trust such values at the border. I think we can simplify the proposal further after this discussion. And then the decision is whether we want to allow the local use case. I assure you there are people who want it. Brian > > Other than that, I agree with your assessment. > > Thanks, > Simon From brian.e.carpenter@gmail.com Thu Apr 15 15:26:03 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 2AE9728C277 for ; Thu, 15 Apr 2010 15:26:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.351 X-Spam-Level: X-Spam-Status: No, score=-2.351 tagged_above=-999 required=5 tests=[AWL=0.248, 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 JqZazuTQXWF2 for ; Thu, 15 Apr 2010 15:26:02 -0700 (PDT) Received: from mail-pv0-f172.google.com (mail-pv0-f172.google.com [74.125.83.172]) by core3.amsl.com (Postfix) with ESMTP id 1610F3A6AA7 for ; Thu, 15 Apr 2010 15:24:55 -0700 (PDT) Received: by pvf33 with SMTP id 33so1297390pvf.31 for ; Thu, 15 Apr 2010 15:24:45 -0700 (PDT) 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=Os65Pa90P0+Z507OQq4PkMl2fVQA7ahhaVt3XbcSif4=; b=rwmdoGlOoMHzw9hNXG9uZvVEUitgj+NrCOrLMekq10n7U1wr1HkRL6CmZj3rhPz+9L szJ0Xl0UG0dw2mobUu2Ibw9QGuIcnSknXZ/e7D1T9pjUsPeVlsHkyp1H68GGdawVGEfl WPNWeQLogzhCuVZDeg6mWEbFb4yaSsV4C6JCk= 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=EWjoyC/LNhqkXe6/ebusNuOfFiAs8lO/Ftgm8hHEDLIdcvkQXZwH4hsCTEuCxQptp3 dERtJNt2HSATcJmDrq3SE2vApv1oAR7wDZmgpSdfYqzsDotd3PQasnkORYq6gnzeTlb+ 8uF24QkBSfPiClPAqlLt0hJzZFgI622p/54Z8= Received: by 10.140.248.8 with SMTP id v8mr1208018rvh.9.1271370284940; Thu, 15 Apr 2010 15:24:44 -0700 (PDT) Received: from [130.216.38.124] (stf-brian.sfac.auckland.ac.nz [130.216.38.124]) by mx.google.com with ESMTPS id 23sm1653763pzk.10.2010.04.15.15.24.43 (version=SSLv3 cipher=RC4-MD5); Thu, 15 Apr 2010 15:24:44 -0700 (PDT) Message-ID: <4BC7922A.9040406@gmail.com> Date: Fri, 16 Apr 2010 10:24:42 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Alexandru Petrescu Subject: Re: MEXT Flow IDs, ROLL mutable Flow Labels and draft-carpenter-6man-flow-update-02 References: <4B7CB52D.20902@gmail.com> <4BC5F981.2080101@gmail.com> <4BC638CC.6020407@gmail.com> <4BC6D8F7.1030205@gmail.com> In-Reply-To: <4BC6D8F7.1030205@gmail.com> Content-Type: text/plain; charset=UTF-8 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: Thu, 15 Apr 2010 22:26:03 -0000 Below... On 2010-04-15 21:14, Alexandru Petrescu wrote: > Le 14/04/2010 23:51, Brian E Carpenter a =C3=A9crit : >> Alexandru, >> >>> I find this proposal to change the Flow Label behaviour to come in >>> too early, at a point where we don't yet have widespread use of >>> simple Flow Labels (or is it widely used?). >> >> But that's the problem. If you have read the -02 draft, you will >> understand that flow label usage today is essentially non-existent. >=20 > Ok, it is draft-carpenter-6man-flow-update-02 and I will comment on it > separately. >=20 >> Usage is not going to occur unless we make it desirable - and it's >> quite clear that RFC 3697 did not succeed in making it desirable. So >> either we do something, or we continue to carry 20 useless bits in >> every IPv6 packet. >=20 > I mainly agree to make Flow Labels desirable. Towards that end one > would consider two other cases where Flow Labels were considered: >=20 > - MEXT' WG draft-ietf-mext-flow-binding-06 "Flow Bindings in Mobile > IPv6 and NEMO Basic Support"; > - ROLL WG's intention of use of Flow Labels in RPL > protocol draft-ietf-roll-rpl-07. >=20 > Currently their way of considering flows and Flow Labels respectively i= s > incoherent with old Flow Labels - and with new Flow Labels too. Or > probably are they about to get in synch(?). >=20 > Why has MEXT WG defined a new flow id instead of reusing the IPv6 Flow > Label? Is it because of security? The new 6MAN Flow Labels don't > improve on security, they're still uncovered by IPsec. >=20 > Why has ROLL WG looked at mutable Flow Labels? Is it to change it > enroute and restore it when getting out of the flow label domain? The > new flow labels don't seem to impose the restoration, in my reading. >=20 > Are the new Flow Labels better adapted to MEXT and to ROLL? Well, if we get to a stable proposal here, we cn ask them exactly that. Brian From brian.e.carpenter@gmail.com Thu Apr 15 16:41:56 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 BB1003A6803 for ; Thu, 15 Apr 2010 16:41:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.361 X-Spam-Level: X-Spam-Status: No, score=-2.361 tagged_above=-999 required=5 tests=[AWL=0.238, 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 h1Tuz-owh21g for ; Thu, 15 Apr 2010 16:41:55 -0700 (PDT) Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by core3.amsl.com (Postfix) with ESMTP id 1A72F3A6931 for ; Thu, 15 Apr 2010 16:41:40 -0700 (PDT) Received: by pwj2 with SMTP id 2so1600022pwj.31 for ; Thu, 15 Apr 2010 16:41:30 -0700 (PDT) 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=4n9L9vTQrWTumXaTZXC9n9fCpIdp+mcuOFiRYuxR4po=; b=Ud3kUkWpIF1T3KMxmvt3yLkqlTU2s3UfhPebXz6nHRB1GP2s0Z1aS6NcErHJN6WimM ebnNRHInRdFbtRTldHUb9FYkfmSR/B63w4+F7Xlg0PjFULYQlVXMibTTW/1s8poqupJc ZgjkZH2aZld+F81IehBKIQRrALBeucVGzoNLc= 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=RhWdah2zDkNgGY4HQ93urfutuzdxkBrxZ8QCO/75UTOlvJUFiju6UcgbpF22K5eMr6 KoMXaa51KTftbKYvNeRq5aSpqRRDkss/lL2y+Y367rkWMk8ZdUAHxhhT2KyUKgzEO9jc VrmB2ARfAtvnhNxrj/TWKC2wM2ycW12YxDKUM= Received: by 10.141.3.3 with SMTP id f3mr1167283rvi.237.1271374890333; Thu, 15 Apr 2010 16:41:30 -0700 (PDT) Received: from [130.216.38.124] (stf-brian.sfac.auckland.ac.nz [130.216.38.124]) by mx.google.com with ESMTPS id 21sm1710343pzk.4.2010.04.15.16.41.28 (version=SSLv3 cipher=RC4-MD5); Thu, 15 Apr 2010 16:41:29 -0700 (PDT) Message-ID: <4BC7A426.9020009@gmail.com> Date: Fri, 16 Apr 2010 11:41:26 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Alexandru Petrescu Subject: Re: Comments on draft-carpenter-6man-flow-update-02 References: <4BC6E71C.1000102@gmail.com> In-Reply-To: <4BC6E71C.1000102@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: Thu, 15 Apr 2010 23:41:56 -0000 Thanks for the comments. Extracting: On 2010-04-15 22:14, Alexandru Petrescu wrote: ... >> 1. If and only if the flow label in an IPv6 packet has the default >> value of zero, then a router MAY set it to a value between between 1 >> and 0xFFFFF. This option modifies the rule that the flow label must >> be delivered unchanged, by allowing exactly one router to set it if >> the source host did not set it. > > I believe this may pose problems. The case is when the sending Host1 > does not set the Flow Label and the receiving Host2 knows somehow (e.g. > the app protocol is older than new Flow Labels) that H1 doesn't > implement Flow Labels and so expects "0" zero from it. When H2 sees a > flow label set then it deduces something is wrong, because it knows H1 > couldn't set it. Indeed, I think we should make it clear that receiving hosts MUST NOT rely on the flow label for any kind of upper layer behaviour. That is a missing rule in RFC3697, I think. > In RPL there's talk proposing "restoration" of the Flow Label at the > exit point, but I don't agree with that either. That is *required* by the existing rules of RFC3697. >> packets leaving the local domain may contain flow label values that >> are not pseudo-random > > For some reason I have difficulty understanding "not pseudo-radom": does > it mean actually "random", interpreted as a double negation? Does it > mean "not random but can't talk random because true random doesn't > exist"? The implications of this clarification are wide I believe. OK, good point. What is intended by "not pseudo-random" is that it's either assigned systematically (e.g. 1, 2, 3...) or that the bits are encoded with some special meanings. I don't like to write plain "random" because most network nodes don't contain random number devices. > >> The flow label is not protected in any way and can be forged by an >> on-path attacker. On the other hand, a pseudo-random flow label >> cannot be readily guessed by an off-path attacker. > > That "OTOH" makes think that because pseudo-random flow labels cannot be > guessed then the Flow Label is protected against on-path attackers. I What? Not at all. On-path attackers can observe and/or forge any flow label. But as draft-blake-ipv6-flow-label-nonce shows, they can have value for making off-path attacks harder. > don't think much protection is afforded by the use of visible be them > random numbers. Were it public-private-keys then yes but here we don't > talk Flow Labels as security keys, at least because of the obvious > performance requirements. Indeed not. Brian From brian.e.carpenter@gmail.com Thu Apr 15 16:50:47 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 23F8028C101 for ; Thu, 15 Apr 2010 16:50:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.37 X-Spam-Level: X-Spam-Status: No, score=-2.37 tagged_above=-999 required=5 tests=[AWL=0.229, 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 MzakXSfuPNq9 for ; Thu, 15 Apr 2010 16:50:46 -0700 (PDT) Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by core3.amsl.com (Postfix) with ESMTP id 5EC1D3A6AC5 for ; Thu, 15 Apr 2010 16:50:41 -0700 (PDT) Received: by pwj2 with SMTP id 2so1603165pwj.31 for ; Thu, 15 Apr 2010 16:50:32 -0700 (PDT) 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=9iI3+F0OLHWlRrw883FP6DQm/FoWvoRpvvnAiwgL+I0=; b=Za2KqEvcanADkVn4QdAMRzV74syCTt9Je2mjUbsd1cmCC+HEG3HX45Im5XyvKmQZzN c2YnkNmlXG4nWOXlFI8T0eb1NlF++cd1xWXAk+fTzl0LUlw6pa8T9tehusm0Z6ZW41Sy oalWgIPppYFfsWBtvQuhEBhQn1TR1rEAnHh+I= 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=CSORrw+9UJpJtkI1GvLqJnn/Dntm/NEuHOgtQQLUPlcNRNRtfRKuVcdJaI3LkxX9NS g4ZOqqd/s5vZ0iTxINp33HR1C/VBfXlPibvQj+lDXC2sXMnIPSBzhI4bfzMxuITEquKw I5VSzHtp0FWH+VlxeHjiSBdZ7EEY3ciGOO1TY= Received: by 10.140.251.13 with SMTP id y13mr1089660rvh.116.1271375432000; Thu, 15 Apr 2010 16:50:32 -0700 (PDT) Received: from [130.216.38.124] (stf-brian.sfac.auckland.ac.nz [130.216.38.124]) by mx.google.com with ESMTPS id 22sm1714003pzk.13.2010.04.15.16.50.30 (version=SSLv3 cipher=RC4-MD5); Thu, 15 Apr 2010 16:50:31 -0700 (PDT) Message-ID: <4BC7A644.2040403@gmail.com> Date: Fri, 16 Apr 2010 11:50:28 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Mark Smith Subject: Re: [Fwd: New Version Notification for draft-carpenter-6man-flow-update-02] References: <4BC54919.3000900@gmail.com> <20100415072936.60eb08ac@opy.nosense.org> <4BC63DF0.6070707@gmail.com> <20100415191648.13efcb8d@opy.nosense.org> In-Reply-To: <20100415191648.13efcb8d@opy.nosense.org> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: 6man X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Apr 2010 23:50:47 -0000 Hi Mark, > Are you generally trying to avoid it because it would appear to be an > implied IETF definition of a flow, rather than just the IPv6 > definition? Or is it to avoid having to start defining the a possibly > large set of flow definitions? Actually, because I have enough email to deal with right now anyway :-) Your proposed definition looks reasonable, but the IPFIX people have a rather different definition: "A flow is defined as a set of IP packets passing an observation point in the network during a certain time interval. All packets belonging to a particular flow have a set of common properties.... A flow is considered to be expired if no packet of this flow has been observed for a given timeout interval" [RFC3917] The crucial difference is the tiemout. In the observational world of IPFIX, a flow is deemed to end when there is a certain period of silence. So a stop-start flow meeting your definition might be broken up into multiple flows by IPFIX. That's where things get vague. Regards Brian On 2010-04-15 21:46, Mark Smith wrote: > Hi Brian, > > On Thu, 15 Apr 2010 10:13:04 +1200 > Brian E Carpenter wrote: > >> Hi Mark, >> >> On 2010-04-15 09:59, Mark Smith wrote: >>> Hi Brian and Sheng, >>> >>> On Wed, 14 Apr 2010 16:48:25 +1200 >>> Brian E Carpenter wrote: >>> >>>> Hi, >>>> > > > >>> I suppose partly that comes down to what a 'flow' is. In some contexts, >>> it is definitely a transport layer connection. In others, e.g. an MPLS >>> network, I think it could be seen to be all packets that match a >>> Forwarding Equivalence Class. If it was possible to use a FEC to set >>> the flow label, once the packet has traversed the MPLS network, and the >>> MPLS labels are stripped off, the flow label that was set due to the >>> FEC would be preserved, which might be useful. Is there an opportunity >>> to make the definition of a flow a bit more general, and then for allow >>> for the choice of different packet classification methods to be used to >>> define a flow, based on context e.g. transport layer connection in some >>> contexts, MPLS FEC, QoS/Diff Serv classifiers etc. in others? >> And that's an even wider question. I'm inclined to duck it, or at >> least to assert that it's a much wider question than 6man can tackle. >> > > Are you generally trying to avoid it because it would appear to be an > implied IETF definition of a flow, rather than just the IPv6 > definition? Or is it to avoid having to start defining the a possibly > large set of flow definitions? > > I think that as the field is an IPv6 one, IPv6 can have a position on > what it considers a flow to be. > > I had a bit of a think about a more general definition of what a flow > is and came up with this: > > "a set of packets that have a common attribute, or common relationship > with another entity" > > with common attribute being things like field (single or multiple > ) values, optional fields (e.g. a set of extension headers), same > result of a hash of fields etc. > > A common relationship might be the same MPLS FEC, BGP NEXT_HOP, router > incoming interface, destination AS etc. > > Looking at the definitions of flows in the IPv6 RFC, and in RFC3697, I > think the above general definition would encompass those as well. > > If that was an acceptable general definition, then this draft could > also then define one specific instance of a flow definition, namely the > fields used to identify a transport layer connection, and state that > other instances of applicable flow definitions may be defined in other > RFCs, including non-IPv6 ones. > > > Regards, > Mark. > From suresh.krishnan@ericsson.com Thu Apr 15 17:23:46 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 F393A3A6AAB for ; Thu, 15 Apr 2010 17:23:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.082 X-Spam-Level: X-Spam-Status: No, score=-4.082 tagged_above=-999 required=5 tests=[AWL=-2.083, BAYES_00=-2.599, J_CHICKENPOX_44=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 thTxagX8aPRb for ; Thu, 15 Apr 2010 17:23:45 -0700 (PDT) Received: from imr3.ericy.com (imr3.ericy.com [198.24.6.13]) by core3.amsl.com (Postfix) with ESMTP id 9A5B23A6AAC for ; Thu, 15 Apr 2010 17:22:46 -0700 (PDT) Received: from eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) by imr3.ericy.com (8.13.8/8.13.8) with ESMTP id o3G0McHP028252 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 15 Apr 2010 19:22:38 -0500 Received: from [142.133.10.113] (147.117.20.212) by eusaamw0711.eamcs.ericsson.se (147.117.20.179) with Microsoft SMTP Server id 8.1.375.2; Thu, 15 Apr 2010 20:22:36 -0400 Message-ID: <4BC7AC7A.2090606@ericsson.com> Date: Thu, 15 Apr 2010 20:16:58 -0400 From: Suresh Krishnan User-Agent: Thunderbird 2.0.0.24 (X11/20100411) MIME-Version: 1.0 To: Parav Pandit Subject: Re: deriving MAC address from destination Link local address without Neighbor discovery References: <342102.44906.qm@web30104.mail.mud.yahoo.com> In-Reply-To: <342102.44906.qm@web30104.mail.mud.yahoo.com> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit Cc: "ipv6@ietf.org" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Apr 2010 00:23:47 -0000 Hi Parav, Please see comments inline. On 10-04-15 01:55 AM, Parav Pandit wrote: > Hi, > > As per RFC 2464, Link local address for Ethernet based interfaces are based on the EUI-64 (derived from the MAC address). > > I have #3 questions based on this. > > In this case, > when one Ethernet based host(from its link-local source) tries to ping the other Ethernet based host, it knows the Mac address implicitly (from the Link local address). > > 1. Why is it required to explicitly do the Neighbor discovery for the link-local addresses? > RFC 4861 says to do the neighbor discovery even for link-local addresses. > Correct me if my understanding is incorrect. Address resolution is required even for link-local addresses. Link-local addresses can be formed with arbitrary IIDs that do not need to be derived from MAC addresses and more importantly . > > 2. Does it mean that in Ethernet networks, interface can have only one Link-local address? If not then we violate the RFC 2464. RFC2464 does not have any normative language in this regard. Why do you think this will violate RFC2464? > > 3. Does RFC 4941 Privacy extension for autoconf apply to Ethernet interfaces? Yes. Certainly. Thanks Suresh From niviya.vijayan.t@gmail.com Fri Apr 16 01:18:57 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 1DD3D3A6B19 for ; Fri, 16 Apr 2010 01:18:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=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 SQ6WeuII4bLd for ; Fri, 16 Apr 2010 01:18:54 -0700 (PDT) Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by core3.amsl.com (Postfix) with ESMTP id A30863A6A33 for ; Fri, 16 Apr 2010 01:18:54 -0700 (PDT) Received: by pwj2 with SMTP id 2so1771870pwj.31 for ; Fri, 16 Apr 2010 01:18:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:received:message-id :subject:from:to:content-type; bh=JY50Uu5nGpvsbgw7WJ5jYrxjG+ZVMVqu++POKMvTDXM=; b=ReNS0F7AE1XRhGJnvfLnbWc8kIKrX1J/Yj1qWPinw46TZHVRy6FYqNUW0bIoiuv/XS iDHwDPmFJRMpoQ9lV2cSkhkpuSzWziAy4j1IXR8VpxcQaDABe3V1sIA2nq2ltDM4S1Np uB9qk3PW8HDMbFlBcwIQwyy9I3YWlEHRO7tcY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=YEcxb28CwN6GDPqkUm3GMfqpp0pl8C64wuA1Qh4wTdrHOVPma5FrHIeZ3bJAPeXDSP FP0SqVQfEWdgL9tSmC3N5gukhX+4LAITOg+YRmDWJw4RRQdrs2S+0puduWiIhbrskieN c3/MQDx+m1M305j/Ruy3RIVV4sFmfxJ/44TWg= MIME-Version: 1.0 Received: by 10.142.180.6 with HTTP; Fri, 16 Apr 2010 01:18:44 -0700 (PDT) Date: Fri, 16 Apr 2010 13:48:44 +0530 Received: by 10.142.65.24 with SMTP id n24mr662560wfa.302.1271405925008; Fri, 16 Apr 2010 01:18:45 -0700 (PDT) Message-ID: Subject: RFC 4861:-Link-Local address joining all-node multicast group. From: niviya vijayan To: ipv6@ietf.org Content-Type: multipart/alternative; boundary=001636e0a54a8687600484564275 X-Mailman-Approved-At: Fri, 16 Apr 2010 01:57:32 -0700 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, 16 Apr 2010 08:28:17 -0000 --001636e0a54a8687600484564275 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi , I have a query regarding the interface initialization process for an ipv6 enabled interface. As per the RFC4861, the node has to join a. All-node multicast address{FE02::1} b. Solicited multicast address {FF02::1:ff00:} I have tried capturing packets for one of the switch while configuring an ipv6 address. I could see IPv6 node (Ipv6 address) joining =91All node multicast address=92 and =91Solicited multicast address=92. Apart from that= I am seeing an extra join request from the Link Local address to the =91All node multicast address=92. Any specific reason for this? Is this a correct behaviour ?or is there any requirement for joining link local address on th= e all node multicast node while creating an ipv6 address on the interface? wh= y it is required? if it is required, then this message will repeat for each & every ipv6 address created on an interface since it has only one link-local address. I havent seen anywhere RFC taking about this. please help me to understand this behaviour. RFC 4861 Statement:- 7.2.1.Interface Initialization =93When a multicast-capable interface becomes enabled, the node MUST join t= he all-nodes multicast address on that interface, as well as the solicited- node multicast address corresponding to each of the IP addresses assigne= d to the interface.=94 Thnaks & Regards, Niviya --001636e0a54a8687600484564275 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
Hi ,
=A0
=A0I have a query regarding the interface initializati= on process for an ipv6 enabled interface.
=A0

=A0As per the RFC4861, the node has to join=A0

a.=A0=A0=A0=A0=A0=A0 All-node multicast address{FE02::1}

b.=A0=A0=A0=A0=A0 Solicited multicast address {FF02::1:ff00:<last 24 bits of ipaddress>= ;}

=A0

I have tri= ed=A0capturing =A0packets for one of the switch while configuring an ipv6 a= ddress.=A0I could see IPv6 node (Ipv6 address) joining =91All node multicas= t address=92 and =91Solicited multicast address=92. Apart from that I am se= eing an extra join request from the Link Local address to the =91All node m= ulticast address=92.=A0 Any specific reason for this? Is this a correct beh= aviour ?or is there any requirement for joining link local address on the a= ll node multicast node while creating an ipv6 address on the interface? why= it is required? if it is required, then this message will repeat for each = & every=A0ipv6 address created=A0on an interface since it has only one = link-local address.
=A0
=A0I haven= t seen anywhere RFC taking about this. please help me to understand this be= haviour.
=A0
RFC 4861 Statement:- 7.2.1.Interface Initialization
=93When a multicast-capable interface becomes enabled,= the node MUST join the all-nodes multicast address on that interface, as w= ell as the solicited- =A0=A0=A0node multicast address corresponding to each= of the IP addresses assigned to the interface.=94
=A0
=A0
Thnaks & Regards,
Niviya
--001636e0a54a8687600484564275-- From remi.despres@free.fr Fri Apr 16 02:44:39 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 95FDD3A67CC for ; Fri, 16 Apr 2010 02:44:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.186 X-Spam-Level: X-Spam-Status: No, score=-1.186 tagged_above=-999 required=5 tests=[AWL=0.763, 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 kBDCTwqWqlBR for ; Fri, 16 Apr 2010 02:44:39 -0700 (PDT) Received: from smtp1-g21.free.fr (smtp1-g21.free.fr [212.27.42.1]) by core3.amsl.com (Postfix) with ESMTP id AA38B3A6863 for ; Fri, 16 Apr 2010 02:44:37 -0700 (PDT) Received: from smtp1-g21.free.fr (localhost [127.0.0.1]) by smtp1-g21.free.fr (Postfix) with ESMTP id D1078940141; Fri, 16 Apr 2010 11:44:26 +0200 (CEST) Received: from [192.168.0.13] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by smtp1-g21.free.fr (Postfix) with ESMTP id CA1E3940154; Fri, 16 Apr 2010 11:44:23 +0200 (CEST) Subject: Draft-krishnan-ipv6-exthdr-08 to become asap a 6man WG draft ? Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: <535BCC7B-196D-4E2A-99ED-7C6D9A5839DB@apple.com> Date: Fri, 16 Apr 2010 11:44:23 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <5CF3944B-A8C4-41D9-BE32-D154878FA27F@free.fr> References: <4BC64100.303@gmail.com> <535BCC7B-196D-4E2A-99ED-7C6D9A5839DB@apple.com> To: 6man 6man X-Mailer: Apple Mail (2.1078) 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, 16 Apr 2010 09:44:39 -0000 Hi all, Thanks to James for the pointer to draft-krishnan-ipv6-exthdr-08. I don't know exactly what the status of draft-krishnan-ipv6-exthdr-08 is = today, but it this proposal has IMHO to become quickly a standard-track = RFC: - The ability of skipping an extension header in a node that doesn't = know it is clearly needed.=20 - This need should have been satisfied in the original IPv6 = specification. I therefore support that this draft should become asap a 6man WG = document. Regards, RD Le 15 avr. 2010 =E0 02:58, james woodyatt a =E9crit : > On Apr 14, 2010, at 15:26, Brian E Carpenter wrote: >>=20 >> What do people think? >=20 > I think this topic reminds me of = . >=20 > "This document proposes a new family of IPv6 extension headers that > will be encoded in a consistent format so that it is possible for > intermediate nodes to skip over unknown extension headers and > continue to further process the header chain if they so desire." >=20 > And look: it's expired again. >=20 >=20 > -- > james woodyatt > member of technical staff, communications engineering >=20 >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From suresh.krishnan@ericsson.com Fri Apr 16 08:18:42 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 023B83A691B for ; Fri, 16 Apr 2010 08:18:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.085 X-Spam-Level: X-Spam-Status: No, score=-4.085 tagged_above=-999 required=5 tests=[AWL=-1.486, 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 8doyMZXVLSrA for ; Fri, 16 Apr 2010 08:18:41 -0700 (PDT) Received: from imr3.ericy.com (imr3.ericy.com [198.24.6.13]) by core3.amsl.com (Postfix) with ESMTP id 995E93A68ED for ; Fri, 16 Apr 2010 08:17:48 -0700 (PDT) Received: from eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) by imr3.ericy.com (8.13.8/8.13.8) with ESMTP id o3GFHegk002339 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 16 Apr 2010 10:17:40 -0500 Received: from [142.133.10.113] (147.117.20.212) by eusaamw0712.eamcs.ericsson.se (147.117.20.182) with Microsoft SMTP Server id 8.1.375.2; Fri, 16 Apr 2010 11:17:39 -0400 Message-ID: <4BC87E3E.80504@ericsson.com> Date: Fri, 16 Apr 2010 11:11:58 -0400 From: Suresh Krishnan User-Agent: Thunderbird 2.0.0.24 (X11/20100411) MIME-Version: 1.0 To: niviya vijayan Subject: Re: RFC 4861:-Link-Local address joining all-node multicast group. References: In-Reply-To: Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 8bit Cc: "ipv6@ietf.org" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Apr 2010 15:18:42 -0000 Hi Niviya, On 10-04-16 04:18 AM, niviya vijayan wrote: > Hi , > > I have a query regarding the interface initialization process for an > ipv6 enabled interface. > > > As per the RFC4861, the node has to join > > a. All-node multicast address{FE02::1} > > b. Solicited multicast address {FF02::1:ff00: ipaddress>} > > > > I have tried capturing packets for one of the switch while configuring > an ipv6 address. I could see IPv6 node (Ipv6 address) joining ‘All node > multicast address’ and ‘Solicited multicast address’. Apart from that I > am seeing an extra join request from the Link Local address to the ‘All > node multicast address’. Any specific reason for this? Is this a > correct behaviour ?or is there any requirement for joining link local > address on the all node multicast node while creating an ipv6 address on > the interface? why it is required? if it is required, then this message > will repeat for each & every ipv6 address created on an interface since > it has only one link-local address. It is very strange that you see a join for the all nodes multicast address. Nodes don't have to send a MLD join for the link-local all-nodes multicast address and I have never seen an implementation that does this. What I would expect is 2 MLD (listener report) joins 1) MLD join for the solicited node multicast address from the unspecified address (to test for the uniqueness of the tentative link-local address). 2) MLD join for the solicited node multicast address from the link-local address. Cheers Suresh From alexandru.petrescu@gmail.com Fri Apr 16 09:00:11 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 BA1EF28C1CF for ; Fri, 16 Apr 2010 09:00:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.951 X-Spam-Level: X-Spam-Status: No, score=-1.951 tagged_above=-999 required=5 tests=[AWL=0.298, BAYES_00=-2.599, HELO_EQ_FR=0.35] 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 y2YmFZsIDvm7 for ; Fri, 16 Apr 2010 09:00:10 -0700 (PDT) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.1]) by core3.amsl.com (Postfix) with ESMTP id 4ED7428C196 for ; Fri, 16 Apr 2010 09:00:10 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.0) with ESMTP id o3GG01S2019555 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Fri, 16 Apr 2010 18:00:02 +0200 Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id o3GG01DM016044 for ; Fri, 16 Apr 2010 18:00:01 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.133.173]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id o3GG01F1003144 for ; Fri, 16 Apr 2010 18:00:01 +0200 Message-ID: <4BC88981.1010502@gmail.com> Date: Fri, 16 Apr 2010 18:00:01 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: ipv6@ietf.org Subject: Re: RFC 4861:-Link-Local address joining all-node multicast group. References: <4BC87E3E.80504@ericsson.com> In-Reply-To: <4BC87E3E.80504@ericsson.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit 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, 16 Apr 2010 16:00:11 -0000 Le 16/04/2010 17:11, Suresh Krishnan a écrit : > Hi Niviya, > > On 10-04-16 04:18 AM, niviya vijayan wrote: >> Hi , >> >> I have a query regarding the interface initialization process for an >> ipv6 enabled interface. >> >> >> As per the RFC4861, the node has to join >> a. All-node multicast address{FE02::1} >> >> b. Solicited multicast address {FF02::1:ff00:} >> >> >> >> I have tried capturing packets for one of the switch while configuring >> an ipv6 address. I could see IPv6 node (Ipv6 address) joining ‘All >> node multicast address’ and ‘Solicited multicast address’. Apart from >> that I am seeing an extra join request from the Link Local address to >> the ‘All node multicast address’. Any specific reason for this? Is >> this a correct behaviour ?or is there any requirement for joining link >> local address on the all node multicast node while creating an ipv6 >> address on the interface? why it is required? if it is required, then >> this message will repeat for each & every ipv6 address created on an >> interface since it has only one link-local address. > > It is very strange that you see a join for the all nodes multicast > address. Nodes don't have to send a MLD join for the link-local > all-nodes multicast address and I have never seen an implementation that > does this. What I would expect is 2 MLD (listener report) joins > > 1) MLD join for the solicited node multicast address from the > unspecified address (to test for the uniqueness of the tentative > link-local address). > 2) MLD join for the solicited node multicast address from the link-local > address. Strange, what I see is an exclude filter... I have to think what's left if the excluded things go away. Alex > > Cheers > Suresh > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > From paravpandit@yahoo.com Fri Apr 16 11:01:54 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 5660C3A683E for ; Fri, 16 Apr 2010 11:01:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.45 X-Spam-Level: X-Spam-Status: No, score=-1.45 tagged_above=-999 required=5 tests=[AWL=0.549, BAYES_00=-2.599, J_CHICKENPOX_44=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 iaDjZRMv96EE for ; Fri, 16 Apr 2010 11:01:52 -0700 (PDT) Received: from web30101.mail.mud.yahoo.com (web30101.mail.mud.yahoo.com [209.191.69.33]) by core3.amsl.com (Postfix) with SMTP id DFF143A67A2 for ; Fri, 16 Apr 2010 11:01:51 -0700 (PDT) Received: (qmail 79726 invoked by uid 60001); 16 Apr 2010 18:01:39 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1271440899; bh=vM4qATxE5sH5dacG9esL2c/6IOaNvnhllYrbfHj3WKs=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=vspg6oPl0qaJdQ48aHF0f8rReY5IWTQHDEBTHruGCtBqmVRyS0FQpiFn24vvxjrca84csStipq5P6D2QUbKz9dOesWOV6e08mqfR1GzPXgl4tRBy66t/viVTH6qL7JibovpWpMxmWWs8AY5L+njAyrU2CY3yXHTAgw+L1D4uLsc= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=1he884XThHnGwmw/kwt4RJzUgcQa6LxhHZodhJPmzPSIIdoWFtP4vtERhIF466go4WuZtLEObCZ4csFJr5bchk0+1Cz+07t5T56qEJnI8YvJm/IeI5/AmOfsujdFUQUcB2w1sPZWS5AmiPaXPH+EaI04+OnRNNLOVTxL8KIEAh8=; Message-ID: <624797.78158.qm@web30101.mail.mud.yahoo.com> X-YMail-OSG: 90M1Xu4VM1lwQm7pdUVsS6oVwWblrMID9f6b3yc7_bJvBtw iEZUn.yX9O1egYii.mNQXlOGA1f1dzrC9k2wS6bRpdyyY1rohohmC4c4hjmf qvNV39vOfbCVIXJhk8.N_mXx4vS1sni.o3gpZzG4rT0R9d9QPbslRfZygajN rG7QGhTpoaXYKb3f.0m4iIZwfygAXklsr8v1J1OC3jkghdMH3fNjfg230VXT dthWWHfguttXBD0huzuD3nHtHL4lfFR_lCs4nZQrYLKnvD9NKwiXkbakeSeQ DKVj3KSGECQ3bE3dgT.G.GaYf2R0bRtnugozClZzGJK5CU1I8Cl3DRLggdKr bWAkNZFSlq55QTdqCL9HLiNgYsU83lQ-- Received: from [111.93.130.139] by web30101.mail.mud.yahoo.com via HTTP; Fri, 16 Apr 2010 11:01:39 PDT X-Mailer: YahooMailClassic/10.1.9 YahooMailWebService/0.8.103.269680 Date: Fri, 16 Apr 2010 11:01:39 -0700 (PDT) From: Parav Pandit Subject: Re: deriving MAC address from destination Link local address without Neighbor discovery To: Suresh Krishnan In-Reply-To: <4BC7AC7A.2090606@ericsson.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "ipv6@ietf.org" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Apr 2010 18:01:54 -0000 Please fine inline response.=0AParav=0A=0A=0A--- On Fri, 4/16/10, Suresh Kr= ishnan wrote:=0A=0A> From: Suresh Krishnan <= suresh.krishnan@ericsson.com>=0A> Subject: Re: deriving MAC address from de= stination Link local address without Neighbor discovery=0A> To: "Parav Pand= it" =0A> Cc: "ipv6@ietf.org" =0A> Dat= e: Friday, April 16, 2010, 5:46 AM=0A> Hi Parav,=0A> =A0 Please see comment= s inline.=0A> =0A> On 10-04-15 01:55 AM, Parav Pandit wrote:=0A> > Hi,=0A> = > =0A> > As per RFC 2464, Link local address for Ethernet based=0A> interfa= ces are based on the EUI-64 (derived from the MAC=0A> address).=0A> > =0A> = > I have #3 questions based on this.=0A> > =0A> > In this case, when one Et= hernet based host(from its=0A> link-local source) tries to ping the other E= thernet based=0A> host, it knows the Mac address implicitly (from the Link= =0A> local address).=0A> > =0A> > 1. Why is it required to explicitly do th= e Neighbor=0A> discovery for the link-local addresses?=0A> > RFC 4861 says = to do the neighbor discovery even for=0A> link-local addresses.=0A> > Corre= ct me if my understanding is incorrect.=0A> =0A> Address resolution is requ= ired even for link-local=0A> addresses. Link-local addresses can be formed = with arbitrary=0A> IIDs that do not need to be derived from MAC addresses a= nd=0A> more importantly they were= formed from MAC addresses or not>.=0A> =0A> > =0A> > 2. Does it mean that = in Ethernet networks, interface=0A> can have only one Link-local address? I= f not then we violate=0A> the RFC 2464.=0A> =0A> RFC2464 does not have any = normative language in this=0A> regard. Why do you think this will violate R= FC2464?=0A> =0A[Parav] RFC 2464 says, it can fall back to other mechanism o= f assigning it by administrator when ND fails (other system owns it).=0AIts= silent about the "not using" other mechanism.=0ASo I thought EUI-64 is the= only way to assign link-local address.=0AThanks for the clarifications.=0A= =0A> > =0A> > 3. Does RFC 4941 Privacy extension for autoconf apply=0A> to = Ethernet interfaces?=0A> =0A> Yes. Certainly.=0A> =0A> Thanks=0A> Suresh=0A= > =0A> =0A=0A=0A From jhw@apple.com Fri Apr 16 11:58:16 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 D945228C143 for ; Fri, 16 Apr 2010 11:58:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.27 X-Spam-Level: X-Spam-Status: No, score=-104.27 tagged_above=-999 required=5 tests=[AWL=-0.926, BAYES_20=-0.74, MIME_QP_LONG_LINE=1.396, 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 6FCyhNJK1XtK for ; Fri, 16 Apr 2010 11:58:16 -0700 (PDT) Received: from mail-out3.apple.com (mail-out3.apple.com [17.254.13.22]) by core3.amsl.com (Postfix) with ESMTP id 1AFB528C142 for ; Fri, 16 Apr 2010 11:58:16 -0700 (PDT) Received: from relay11.apple.com (relay11.apple.com [17.128.113.48]) by mail-out3.apple.com (Postfix) with ESMTP id 565A68E6FB57 for ; Fri, 16 Apr 2010 11:58:09 -0700 (PDT) X-AuditID: 11807130-b7cbdae0000079bd-e5-4bc8b3417554 Received: from il0602f-dhcp79.apple.com (il0602f-dhcp79.apple.com [17.206.50.79]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client did not present a certificate) by relay11.apple.com (Apple SCV relay) with SMTP id 99.19.31165.143B8CB4; Fri, 16 Apr 2010 11:58:09 -0700 (PDT) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Apple Message framework v1078) Subject: Re: Draft-krishnan-ipv6-exthdr-08 to become asap a 6man WG draft ? From: james woodyatt In-Reply-To: <5CF3944B-A8C4-41D9-BE32-D154878FA27F@free.fr> Date: Fri, 16 Apr 2010 11:58:08 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <69EDDF6B-A964-4A76-84D3-97F0BA2AD14F@apple.com> References: <4BC64100.303@gmail.com> <535BCC7B-196D-4E2A-99ED-7C6D9A5839DB@apple.com> <5CF3944B-A8C4-41D9-BE32-D154878FA27F@free.fr> To: 6MAN Working Group X-Mailer: Apple Mail (2.1078) X-Brightmail-Tracker: AAAAAQAAAZE= 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, 16 Apr 2010 18:58:16 -0000 On Apr 16, 2010, at 02:44, R=E9mi Despr=E9s wrote: >=20 > I don't know exactly what the status of draft-krishnan-ipv6-exthdr-08 = is today, but it this proposal has IMHO to become quickly a = standard-track RFC: The draft was presented most recently at IETF-72 Dublin. =46rom the minutes = : >>=20 >> Extension Headers, Suresh Krishnan >> =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 >> Document: draft-krishnan-ipv6-exthdr-03.txt >> Slides: Extension Headers, 6man-6.pdf >> =20 >> Suresh reported on the update to the extension headers = draft. >> He addressed all comments received except for the "who is >> going to use extension headers?" comment. The point of this >> document is "if you use them, this is how you do it". A = number >> of issues were addressed in the update. The remaining open >> issue is backwards compatibility. Extension headers may = alter >> processing. A packet cannot be processed by older >> implementations that don't understand the extension header. >> The standard approach for dealing with this issue is >> recommending that implementations do not process >> unrecognized extension headers. There was a question about >> who is responsible for the IPv6 API? It is currently an >> informational RFC. It falls within the domain of the POSIX >> standards community, but they have not taken it up yet. We = can >> only give recommendations to the POXIX community. Brian >> Haberman concluded the discussion by asking Suresh to = revise >> the document and ask the mailing list for consensus. [continuing quote from R=E9mi] >=20 > - The ability of skipping an extension header in a node that doesn't = know it is clearly needed.=20 > - This need should have been satisfied in the original IPv6 = specification. I was present in the room for the discussion. I don't think the = audience recognized as clear a need for this draft as the nominal = authors did. The meeting adjourned moments later without the working = group taking up the draft as a work item. -- james woodyatt member of technical staff, communications engineering From suresh.krishnan@ericsson.com Fri Apr 16 12:49:11 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 2859A28C189 for ; Fri, 16 Apr 2010 12:49:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.827 X-Spam-Level: X-Spam-Status: No, score=-3.827 tagged_above=-999 required=5 tests=[AWL=-1.528, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mno8NL4+tk1x for ; Fri, 16 Apr 2010 12:49:10 -0700 (PDT) Received: from imr3.ericy.com (imr3.ericy.com [198.24.6.13]) by core3.amsl.com (Postfix) with ESMTP id 57C5328C154 for ; Fri, 16 Apr 2010 12:49:10 -0700 (PDT) Received: from eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) by imr3.ericy.com (8.13.8/8.13.8) with ESMTP id o3GJn0RM003479 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 16 Apr 2010 14:49:01 -0500 Received: from [142.133.10.113] (147.117.20.212) by eusaamw0712.eamcs.ericsson.se (147.117.20.182) with Microsoft SMTP Server id 8.1.375.2; Fri, 16 Apr 2010 15:49:00 -0400 Message-ID: <4BC8BDD7.9030101@ericsson.com> Date: Fri, 16 Apr 2010 15:43:19 -0400 From: Suresh Krishnan User-Agent: Thunderbird 2.0.0.24 (X11/20100411) MIME-Version: 1.0 To: =?ISO-8859-1?Q?R=E9mi_Despr=E9s?= Subject: Re: Draft-krishnan-ipv6-exthdr-08 to become asap a 6man WG draft ? References: <4BC64100.303@gmail.com> <535BCC7B-196D-4E2A-99ED-7C6D9A5839DB@apple.com> <5CF3944B-A8C4-41D9-BE32-D154878FA27F@free.fr> In-Reply-To: <5CF3944B-A8C4-41D9-BE32-D154878FA27F@free.fr> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 8bit Cc: 6man 6man X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Apr 2010 19:49:11 -0000 Hi Remi, On 10-04-16 05:44 AM, Rémi Després wrote: > Hi all, > > Thanks to James for the pointer to draft-krishnan-ipv6-exthdr-08. > > I don't know exactly what the status of draft-krishnan-ipv6-exthdr-08 is today, but it this proposal has IMHO to become quickly a standard-track RFC: > - The ability of skipping an extension header in a node that doesn't know it is clearly needed. > - This need should have been satisfied in the original IPv6 specification. > > I therefore support that this draft should become asap a 6man WG document. As James chimed in, we let the draft expire because there was no clear consensus in the WG as to the need to define new extension headers. We have addressed all the comments received from the WG in the last version the draft. We can refresh the draft and request the chairs for adoption, provided we see somebody trying to define or seeing a need to define a new extension header. Cheers Suresh From suresh.krishnan@ericsson.com Fri Apr 16 12:57:26 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 B982C3A67D4 for ; Fri, 16 Apr 2010 12:57:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.824 X-Spam-Level: X-Spam-Status: No, score=-3.824 tagged_above=-999 required=5 tests=[AWL=-1.225, 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 lQweysFcUXsC for ; Fri, 16 Apr 2010 12:57:26 -0700 (PDT) Received: from imr3.ericy.com (imr3.ericy.com [198.24.6.13]) by core3.amsl.com (Postfix) with ESMTP id A0F5F3A6959 for ; Fri, 16 Apr 2010 12:57:25 -0700 (PDT) Received: from eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) by imr3.ericy.com (8.13.8/8.13.8) with ESMTP id o3GJvHTx004573 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 16 Apr 2010 14:57:17 -0500 Received: from [142.133.10.113] (147.117.20.212) by eusaamw0707.eamcs.ericsson.se (147.117.20.92) with Microsoft SMTP Server id 8.1.375.2; Fri, 16 Apr 2010 15:57:14 -0400 Message-ID: <4BC8BFC5.7000802@ericsson.com> Date: Fri, 16 Apr 2010 15:51:33 -0400 From: Suresh Krishnan User-Agent: Thunderbird 2.0.0.24 (X11/20100411) MIME-Version: 1.0 To: Alexandru Petrescu Subject: Re: RFC 4861:-Link-Local address joining all-node multicast group. References: <4BC87E3E.80504@ericsson.com> <4BC88981.1010502@gmail.com> In-Reply-To: <4BC88981.1010502@gmail.com> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 8bit Cc: "ipv6@ietf.org" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Apr 2010 19:57:26 -0000 Hi Alex, On 10-04-16 12:00 PM, Alexandru Petrescu wrote: > Le 16/04/2010 17:11, Suresh Krishnan a écrit : >> 1) MLD join for the solicited node multicast address from the >> unspecified address (to test for the uniqueness of the tentative >> link-local address). >> 2) MLD join for the solicited node multicast address from the link-local >> address. > > Strange, what I see is an exclude filter... I have to think what's left > if the excluded things go away. I think what you are seeing is a MLD Filter Mode Change Record (Record Type 4) which is setting the filter mode to EXCLUDE with an empty set. This is SOP for starting to listen for multicast traffic from ANY source. Cheers Suresh From jhw@apple.com Fri Apr 16 13:29:22 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 3A94B28C1A5 for ; Fri, 16 Apr 2010 13:29:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.666 X-Spam-Level: X-Spam-Status: No, score=-105.666 tagged_above=-999 required=5 tests=[AWL=0.933, 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 16TWh4yjDz3i for ; Fri, 16 Apr 2010 13:29:21 -0700 (PDT) Received: from mail-out3.apple.com (mail-out3.apple.com [17.254.13.22]) by core3.amsl.com (Postfix) with ESMTP id 49C9028C1AB for ; Fri, 16 Apr 2010 13:28:50 -0700 (PDT) Received: from relay16.apple.com (relay16.apple.com [17.128.113.55]) by mail-out3.apple.com (Postfix) with ESMTP id 5F0C78E72F1E for ; Fri, 16 Apr 2010 13:28:43 -0700 (PDT) X-AuditID: 11807137-b7ce7ae0000056c8-41-4bc8c87b99cd Received: from il0602f-dhcp79.apple.com (il0602f-dhcp79.apple.com [17.206.50.79]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client did not present a certificate) by relay16.apple.com (Apple SCV relay) with SMTP id 56.5E.22216.B78C8CB4; Fri, 16 Apr 2010 13:28:43 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1078) Subject: Re: Draft-krishnan-ipv6-exthdr-08 to become asap a 6man WG draft ? From: james woodyatt In-Reply-To: <4BC8BDD7.9030101@ericsson.com> Date: Fri, 16 Apr 2010 13:28:42 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <25BB1652-E5D2-4F7C-9370-FC52E91E1AEA@apple.com> References: <4BC64100.303@gmail.com> <535BCC7B-196D-4E2A-99ED-7C6D9A5839DB@apple.com> <5CF3944B-A8C4-41D9-BE32-D154878FA27F@free.fr> <4BC8BDD7.9030101@ericsson.com> To: 6MAN Working Group X-Mailer: Apple Mail (2.1078) X-Brightmail-Tracker: AAAAAQAAAZE= 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, 16 Apr 2010 20:29:22 -0000 On Apr 16, 2010, at 12:43, Suresh Krishnan wrote: >=20 > As James chimed in, we let the draft expire because there was no clear = consensus in the WG as to the need to define new extension headers. We = have addressed all the comments received from the WG in the last version = the draft. We can refresh the draft and request the chairs for adoption, = provided we see somebody trying to define or seeing a need to define a = new extension header. In other words, it appears to be the sense of the working group that the = presence of an unrecognized next header value currently precludes the = possibility of identifying whether there is an unrecognized extension = header interposed between the IPv6 header and the upper-layer transport = header. It's important to note that 'unrecognized' does not mean = 'undefined' here-- it just means 'undefined when the packet analyzer was = made' which is not precisely the same thing. Going back to Mr. Carpenter's message about extracting the 5-tuple from = IPv6 packets, it seems pretty clear that the logical consequence of the = above is that we have only two real alternatives available: A) strongly = recommend that all hosts set the flow label, so that we can use the = 3-tuple {source address, dest address, flow label}, B) change our mind = about whether we need a standard format for generic extension headers, = so that we have some hope of always being able to find the 5-tuple even = when we cannot process the interposing extension header. For the record, I *strongly* prefer option A over option B. On the = other hand, if we go with option B, then that will allow greater = flexibility in using RFC 3692 protocol numbers in the face of stateful = packet filters like those described in = I-D.ietf-v6ops-cpe-simple-security, making them less of an interference = than they would otherwise be. -- james woodyatt member of technical staff, communications engineering From brian@innovationslab.net Fri Apr 16 13:57:24 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 7922E3A6BA8 for ; Fri, 16 Apr 2010 13:57:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.67 X-Spam-Level: X-Spam-Status: No, score=-1.67 tagged_above=-999 required=5 tests=[AWL=0.930, 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 OSpLr6OME5su for ; Fri, 16 Apr 2010 13:57:23 -0700 (PDT) Received: from uillean.fuaim.com (uillean.fuaim.com [206.197.161.140]) by core3.amsl.com (Postfix) with ESMTP id 3FBAA3A69DB for ; Fri, 16 Apr 2010 13:57:18 -0700 (PDT) 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 6CC7388383 for ; Fri, 16 Apr 2010 13:57:11 -0700 (PDT) Received: from clemson.jhuapl.edu (unknown [128.244.207.66]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by clairseach.fuaim.com (Postfix) with ESMTP id D6EFB136831B for ; Fri, 16 Apr 2010 13:57:10 -0700 (PDT) Message-ID: <4BC8CF25.7050906@innovationslab.net> Date: Fri, 16 Apr 2010 16:57:09 -0400 From: Brian Haberman User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: ipv6@ietf.org Subject: Re: Draft-krishnan-ipv6-exthdr-08 to become asap a 6man WG draft ? References: <4BC64100.303@gmail.com> <535BCC7B-196D-4E2A-99ED-7C6D9A5839DB@apple.com> <5CF3944B-A8C4-41D9-BE32-D154878FA27F@free.fr> <4BC8BDD7.9030101@ericsson.com> <25BB1652-E5D2-4F7C-9370-FC52E91E1AEA@apple.com> In-Reply-To: <25BB1652-E5D2-4F7C-9370-FC52E91E1AEA@apple.com> 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: Fri, 16 Apr 2010 20:57:24 -0000 On 4/16/10 4:28 PM, james woodyatt wrote: > On Apr 16, 2010, at 12:43, Suresh Krishnan wrote: >> >> As James chimed in, we let the draft expire because there was no >> clear consensus in the WG as to the need to define new extension >> headers. We have addressed all the comments received from the WG in >> the last version the draft. We can refresh the draft and request >> the chairs for adoption, provided we see somebody trying to define >> or seeing a need to define a new extension header. > > In other words, it appears to be the sense of the working group that > the presence of an unrecognized next header value currently precludes > the possibility of identifying whether there is an unrecognized > extension header interposed between the IPv6 header and the > upper-layer transport header. It's important to note that > 'unrecognized' does not mean 'undefined' here-- it just means > 'undefined when the packet analyzer was made' which is not precisely > the same thing. > > Going back to Mr. Carpenter's message about extracting the 5-tuple > from IPv6 packets, it seems pretty clear that the logical consequence > of the above is that we have only two real alternatives available: A) > strongly recommend that all hosts set the flow label, so that we can > use the 3-tuple {source address, dest address, flow label}, B) change > our mind about whether we need a standard format for generic > extension headers, so that we have some hope of always being able to > find the 5-tuple even when we cannot process the interposing > extension header. > > For the record, I *strongly* prefer option A over option B. On the > other hand, if we go with option B, then that will allow greater > flexibility in using RFC 3692 protocol numbers in the face of > stateful packet filters like those described in > I-D.ietf-v6ops-cpe-simple-security, making them less of an > interference than they would otherwise be. Option A also allows for the handling of encrypted packets where the transport layer port numbers can't be found regardless. Regards, Brian H. From stig@venaas.com Fri Apr 16 17:40:50 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 CC0E73A6A8C for ; Fri, 16 Apr 2010 17:40:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Iz2V4wpeG+su for ; Fri, 16 Apr 2010 17:40:41 -0700 (PDT) Received: from ufisa.uninett.no (ufisa.uninett.no [IPv6:2001:700:1:2:158:38:152:126]) by core3.amsl.com (Postfix) with ESMTP id 73AE33A6892 for ; Fri, 16 Apr 2010 17:40:41 -0700 (PDT) Received: from [10.21.113.243] (128-107-239-233.cisco.com [128.107.239.233]) by ufisa.uninett.no (Postfix) with ESMTPSA id 41304807B; Sat, 17 Apr 2010 02:40:31 +0200 (CEST) Message-ID: <4BC902F4.5080402@venaas.com> Date: Fri, 16 Apr 2010 17:38:12 -0700 From: Stig Venaas User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Suresh Krishnan Subject: Re: Draft-krishnan-ipv6-exthdr-08 to become asap a 6man WG draft ? References: <4BC64100.303@gmail.com> <535BCC7B-196D-4E2A-99ED-7C6D9A5839DB@apple.com> <5CF3944B-A8C4-41D9-BE32-D154878FA27F@free.fr> <4BC8BDD7.9030101@ericsson.com> In-Reply-To: <4BC8BDD7.9030101@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: 6man 6man X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Apr 2010 00:40:50 -0000 Suresh Krishnan wrote: > Hi Remi, > > On 10-04-16 05:44 AM, Rémi Després wrote: >> Hi all, >> >> Thanks to James for the pointer to draft-krishnan-ipv6-exthdr-08. >> >> I don't know exactly what the status of draft-krishnan-ipv6-exthdr-08 >> is today, but it this proposal has IMHO to become quickly a >> standard-track RFC: >> - The ability of skipping an extension header in a node that doesn't >> know it is clearly needed. - This need should have been satisfied in >> the original IPv6 specification. >> >> I therefore support that this draft should become asap a 6man WG >> document. > > As James chimed in, we let the draft expire because there was no clear > consensus in the WG as to the need to define new extension headers. We > have addressed all the comments received from the WG in the last version > the draft. We can refresh the draft and request the chairs for adoption, > provided we see somebody trying to define or seeing a need to define a > new extension header. It's clear to me that this draft is needed. Ever since I wrote some packet analyzer code many years ago and realized I couldn't handle unknown IPv6 options in a good way (that is, ignoring them and still finding the transport header). I support adoption. Stig > Cheers > Suresh > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From ipng@69706e6720323030352d30312d31340a.nosense.org Sun Apr 18 14:41:39 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 3A7053A67D1 for ; Sun, 18 Apr 2010 14:41:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.433 X-Spam-Level: X-Spam-Status: No, score=-0.433 tagged_above=-999 required=5 tests=[AWL=-1.138, BAYES_50=0.001, 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 MbzBm7bWrmIK for ; Sun, 18 Apr 2010 14:41:38 -0700 (PDT) Received: from smtp3.adam.net.au (smtp3.adam.net.au [202.136.110.249]) by core3.amsl.com (Postfix) with ESMTP id 234FF3A6774 for ; Sun, 18 Apr 2010 14:41:38 -0700 (PDT) Received: from 219-90-234-216.ip.adam.com.au ([219.90.234.216] helo=opy.nosense.org) by smtp3.adam.net.au with esmtp (Exim 4.63) (envelope-from ) id 1O3cF5-0006ku-Hm; Mon, 19 Apr 2010 07:11:27 +0930 Received: from opy.nosense.org (localhost.localdomain [IPv6:::1]) by opy.nosense.org (Postfix) with ESMTP id 6D2574922D; Mon, 19 Apr 2010 07:11:26 +0930 (CST) Date: Mon, 19 Apr 2010 07:11:25 +0930 From: Mark Smith To: Brian E Carpenter Subject: Re: [Fwd: New Version Notification for draft-carpenter-6man-flow-update-02] Message-ID: <20100419071125.32b5b70c@opy.nosense.org> In-Reply-To: <4BC7A644.2040403@gmail.com> References: <4BC54919.3000900@gmail.com> <20100415072936.60eb08ac@opy.nosense.org> <4BC63DF0.6070707@gmail.com> <20100415191648.13efcb8d@opy.nosense.org> <4BC7A644.2040403@gmail.com> X-Mailer: Claws Mail 3.7.5 (GTK+ 2.20.0; x86_64-unknown-linux-gnu) X-Location: Lower Mitcham, South Australia, 5062 Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: 6man 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, 18 Apr 2010 21:41:39 -0000 Hi Brian, On Fri, 16 Apr 2010 11:50:28 +1200 Brian E Carpenter wrote: > Hi Mark, > > > Are you generally trying to avoid it because it would appear to be an > > implied IETF definition of a flow, rather than just the IPv6 > > definition? Or is it to avoid having to start defining the a possibly > > large set of flow definitions? > > Actually, because I have enough email to deal with right now anyway :-) > > Your proposed definition looks reasonable, but the IPFIX people have > a rather different definition: > > "A flow is defined as a set of IP packets passing an observation point > in the network during a certain time interval. All packets belonging > to a particular flow have a set of common properties.... > A flow is considered to be expired if no packet of this flow has been > observed for a given timeout interval" [RFC3917] > > The crucial difference is the tiemout. In the observational world > of IPFIX, a flow is deemed to end when there is a certain period of > silence. So a stop-start flow meeting your definition might be > broken up into multiple flows by IPFIX. That's where things get vague. > My understanding is that IPFIX is generally an IETF standardised version of Cisco's Netflow. In Netflow, timeouts are needed for a few reasons: o A timeout is used to expire flows for protocols that aren't connection oriented (e.g. UDP) or the implementation doesn't know are connection oriented because the implementation doesn't understand the protocol. When the timeout occurs, a netflow record is emitted towards the netflow collector, and the router clears the netflow cache entry for the flow. o Long lived TCP connections may go for long enough that people want to know partial flow information about them. This timeout is an upper bound on how long a flow can continue before a netflow record is emitted. The TCP flow stays active in the flow cache, so there will be at least another netflow record at the end of the TCP connection or if the flow cache becomes full and the flow is punted from it. So those timeouts are more to do with emission of flow records, and flow cache maintenance, rather than being a more general definition of what a flow is. Regards, Mark. From brian.e.carpenter@gmail.com Sun Apr 18 16:27:31 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 4713D3A6807 for ; Sun, 18 Apr 2010 16:27:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.389 X-Spam-Level: X-Spam-Status: No, score=-2.389 tagged_above=-999 required=5 tests=[AWL=0.210, 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 4iJE6F3fXmIw for ; Sun, 18 Apr 2010 16:27:30 -0700 (PDT) Received: from mail-gw0-f44.google.com (mail-gw0-f44.google.com [74.125.83.44]) by core3.amsl.com (Postfix) with ESMTP id 3C7ED3A67A6 for ; Sun, 18 Apr 2010 16:27:30 -0700 (PDT) Received: by gwj20 with SMTP id 20so78687gwj.31 for ; Sun, 18 Apr 2010 16:27:18 -0700 (PDT) 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:content-type :content-transfer-encoding; bh=QV/ZCNGmdh82h5HFvAWNK64MZfQyeSEp03d3jvcOvmQ=; b=dN1YAkSIEXSASguQPnQ+RbONuQGJZXrPy/h9A5PHm6V0HgoKwC9mFc6S9zyAINxy2R 7Yz/TWJEsphUVOAlGtIORyAj/auQucYcadyoH0XDChkAAfpQ3ng/5+zqHPHEVgKYaHMV uBmXp4yvJ0uxSwaJQiNsOeo1f10ZMISBhVSOw= 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:content-type:content-transfer-encoding; b=UivCm6F2P7rGZyih01zuh+I6Rr242WpozSpvVsWxA4Sbpd7D40Hym4QZQCVW2Pq3I6 jOVyJBYp5UHnL3b0wcnQC/2D211B2RNQcAYiEUnxjfOM6Z+Jijajoj2L2OmRRP7jNHC4 0hFmlp1K6ICX8NEAfvZJI3cxl6mESjA8S4XCs= Received: by 10.101.190.12 with SMTP id s12mr11052058anp.177.1271633237909; Sun, 18 Apr 2010 16:27:17 -0700 (PDT) Received: from [10.1.1.3] ([121.98.142.15]) by mx.google.com with ESMTPS id b10sm39813870ana.6.2010.04.18.16.27.15 (version=SSLv3 cipher=RC4-MD5); Sun, 18 Apr 2010 16:27:17 -0700 (PDT) Message-ID: <4BCB954F.8020408@gmail.com> Date: Mon, 19 Apr 2010 11:27:11 +1200 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-hu-flow-label-cases-00.txt] Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "Qinwen Hu \(Steven\)" 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, 18 Apr 2010 23:27:31 -0000 Hi 6man, This is by way of background on the flow label. My student Qinwen Hu and I have put it together and we'd welcome feedback. It doesn't really lie in 6man's charter (maintenance, upkeep), so our plan is to submit it as an Independent Submission to the RFC series. Brian + Qinwen -------- Original Message -------- Subject: I-D Action:draft-hu-flow-label-cases-00.txt Date: Sun, 18 Apr 2010 16:15:01 -0700 (PDT) From: Internet-Drafts@ietf.org Reply-To: internet-drafts@ietf.org To: i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Survey of proposed use cases for the IPv6 flow label Author(s) : Q. Hu, B. Carpenter Filename : draft-hu-flow-label-cases-00.txt Pages : 16 Date : 2010-04-18 The IPv6 protocol includes a flow label in every packet header, but it is not used in practice. This paper describes the flow label standard and discusses the implementation issues that it raises. It then describes various published proposals for using the flow label, and shows that most of them are inconsistent with the standard. Methods to address this problem are briefly reviewed. We also question whether the standard should be revised. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-hu-flow-label-cases-00.txt From tena@huawei.com Mon Apr 19 20:12:04 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 77FD63A69BB for ; Mon, 19 Apr 2010 20:12:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.567 X-Spam-Level: X-Spam-Status: No, score=-100.567 tagged_above=-999 required=5 tests=[AWL=-1.562, BAYES_05=-1.11, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RDNS_NONE=0.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 GUOmYsKFiGtv for ; Mon, 19 Apr 2010 20:12:03 -0700 (PDT) Received: from szxga03-in.huawei.com (unknown [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id D94723A6892 for ; Mon, 19 Apr 2010 20:12:02 -0700 (PDT) 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 <0L15002BTNJJX9@szxga03-in.huawei.com> for ipv6@ietf.org; Tue, 20 Apr 2010 11:11:43 +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 <0L15007UPNJIEM@szxga03-in.huawei.com> for ipv6@ietf.org; Tue, 20 Apr 2010 11:11:42 +0800 (CST) Received: from z00147053k ([10.70.39.148]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0L1500EL7NJISH@szxml06-in.huawei.com> for ipv6@ietf.org; Tue, 20 Apr 2010 11:11:42 +0800 (CST) Date: Tue, 20 Apr 2010 11:11:42 +0800 From: Tina TSOU Subject: Questions on RFC 4293 Management Information Base for the Internet Protocol (IP) To: ipv6@ietf.org, v6ops@ops.ietf.org, Bob Hinden , Dan Romascanu , fenner@fenron.com, fenner@gmail.com, dthaler@microsoft.com, brian@innovationslab.net, brian.haberman@jhuapl.edu, sar@iwl.com Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 X-Mailer: Microsoft Outlook Express 6.00.2900.5843 Content-type: multipart/alternative; boundary="Boundary_(ID_L6wjHg2JjcjaYwS0mGWqbA)" X-Priority: 3 X-MSMail-priority: Normal 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, 20 Apr 2010 03:12:04 -0000 This is a multi-part message in MIME format. --Boundary_(ID_L6wjHg2JjcjaYwS0mGWqbA) Content-type: text/plain; charset=gb2312 Content-transfer-encoding: 7BIT Hi all, In RFC 4293, - ipAddressTable is described as writable, this table uses address as index, but the critical information for configuring address, the address prefix ipAddressPrefix node is read-only. It seems contradict to me. This table uses address as index, but the public network and VPN may have exactly the same IP address. This table does not explicitly say whether it only supports public network. If supporting VPN at the same time, there might occur the following case: only on address is displayed among the same IP addresses. ipAddressTable OBJECT-TYPE SYNTAX SEQUENCE OF IpAddressEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table contains addressing information relevant to the entity's interfaces. This table does not contain multicast address information. Tables for such information should be contained in multicast specific MIBs, such as RFC 3019. While this table is writable, the user will note that several objects, such as ipAddressOrigin, are not. The intention in allowing a user to write to this table is to allow them to add or remove any entry that isn't permanent. The user should be allowed to modify objects and entries when that would not cause inconsistencies within the table. Allowing write access to objects, such as ipAddressOrigin, could allow a user to insert an entry and then label it incorrectly. ipAddressPrefix OBJECT-TYPE SYNTAX RowPointer MAX-ACCESS read-only STATUS current DESCRIPTION "A pointer to the row in the prefix table to which this address belongs. May be { 0 0 } if there is no such row." DEFVAL { zeroDotZero } ::= { ipAddressEntry 5 } B. R. Tina http://tinatsou.weebly.com/contact.html --Boundary_(ID_L6wjHg2JjcjaYwS0mGWqbA) Content-type: text/html; charset=gb2312 Content-transfer-encoding: 7BIT
Hi all,
In RFC 4293,
- ipAddressTable is described as writable, this table uses address
as index, but the critical information for configuring address, the
address prefix ipAddressPrefix node is read-only. It seems
contradict to me.
This table uses address as index, but the public network and VPN
may have exactly the same IP address. This table does not
explicitly say whether it only supports public network. If
supporting VPN at the same time, there might occur the following
case: only on address is displayed among the same IP addresses.
ipAddressTable OBJECT-TYPE
   SYNTAX     SEQUENCE OF IpAddressEntry
   MAX-ACCESS not-accessible
   STATUS     current
   DESCRIPTION
          "This table contains addressing information relevant to the
           entity's interfaces.
           This table does not contain multicast address information.
           Tables for such information should be contained in multicast
           specific MIBs, such as RFC 3019.
           While this table is writable, the user will note that
           several objects, such as ipAddressOrigin, are not.  The
           intention in allowing a user to write to this table is to
           allow them to add or remove any entry that isn't
           permanent.  The user should be allowed to modify objects
           and entries when that would not cause inconsistencies
           within the table.  Allowing write access to objects, such
           as ipAddressOrigin, could allow a user to insert an entry
           and then label it incorrectly.
ipAddressPrefix OBJECT-TYPE
   SYNTAX     RowPointer
   MAX-ACCESS read-only
   STATUS     current
   DESCRIPTION
          "A pointer to the row in the prefix table to which this
           address belongs.  May be { 0 0 } if there is no such row."
   DEFVAL { zeroDotZero }
   ::= { ipAddressEntry 5 }
 
--Boundary_(ID_L6wjHg2JjcjaYwS0mGWqbA)-- From niviya.vijayan.t@gmail.com Tue Apr 20 02:09:44 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 DA2823A6AC8 for ; Tue, 20 Apr 2010 02:09:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.522 X-Spam-Level: X-Spam-Status: No, score=-2.522 tagged_above=-999 required=5 tests=[AWL=0.076, BAYES_00=-2.599, HTML_MESSAGE=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 hvMiN1qyKMNL for ; Tue, 20 Apr 2010 02:09:43 -0700 (PDT) Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by core3.amsl.com (Postfix) with ESMTP id B439E3A6A14 for ; Tue, 20 Apr 2010 02:09:43 -0700 (PDT) Received: by pwj2 with SMTP id 2so4039755pwj.31 for ; Tue, 20 Apr 2010 02:09:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:received:message-id:subject:from:to:cc:content-type; bh=1+tqR3KWVbEael4Vh93zLk7nALJZloIwgewVRTIn9Ro=; b=Kwteh8L+X2uq1MZFdjxnbYXwooE5PPyDQNP8mxAXl5e1lY9lSBsemY39PudWE1x5GU v+PrsIEGGsLBmYQ/J1wMLD2EL8BSG0YRan1Ha8XLHps3ZoqvkySOQVaEUXPPIuLrpzLF MbWTnhOmyrT61Op2kbpfaUtmUTNiDrjUM+lKM= 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=BWRQA+JnDzOnLjUyjPn8t/bk2bGYRBowz49H8il+vdFitc06GdWC8Gc5OBtI8oSYKG 5GkxP0ECFqkvZrTR6rhRYDnb22osiMkJYs7D8ZS3o0zmYEFNxLp7Ce2cvnsJrzKJssYv 53FC3REpUJLHeE7K/QQKIvJqdHbJLwMMHPgMo= MIME-Version: 1.0 Received: by 10.142.180.6 with HTTP; Tue, 20 Apr 2010 02:09:31 -0700 (PDT) In-Reply-To: <4BC87E3E.80504@ericsson.com> References: <4BC87E3E.80504@ericsson.com> Date: Tue, 20 Apr 2010 14:39:31 +0530 Received: by 10.142.247.33 with SMTP id u33mr2623174wfh.44.1271754571962; Tue, 20 Apr 2010 02:09:31 -0700 (PDT) Message-ID: Subject: Re: RFC 4861:-Link-Local address joining all-node multicast group. From: niviya vijayan To: Suresh Krishnan Content-Type: multipart/alternative; boundary=00504502cc6280d90d0484a76f04 X-Mailman-Approved-At: Tue, 20 Apr 2010 04:49:45 -0700 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, 20 Apr 2010 09:09:44 -0000 --00504502cc6280d90d0484a76f04 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Suresh, Thanks for your reply. I have a doubt on your answer. As per your comments, there can be two MLD report msg which will join the node in solicited multicast group . But in the RFC 4861, they have mention there should be a join request to all node multicast group. . RFC 4861 Statement:- 7.2.1.Interface Initialization =93When a multicast-capable interface becomes enabled, the node MUST join t= he all-nodes multicast address on that interface, as well as the solicited- node multicast address corresponding to each of the IP addresses assigne= d to the interface.=94 I have one more query regarding NA messages. While creating ipv6 address on an interface, unsolicited NA messages will b= e sent to all node multicast address to inform all other nodes in the network= . When i tried this scenario , I have seen two NA messages. 1) source as ipv6 address and destination as ipv6 all node address. 2) source as link-local address and destination as ipv6 all node address. My question is, whenever there is a change in ipv6 address on a node, both these 2 NA messages will propogate through the network? or is it really required to share about the link-local address as we are no= t at all changing the ipv6 link-local address.? Thanks in advance, Niviya On Fri, Apr 16, 2010 at 8:41 PM, Suresh Krishnan < suresh.krishnan@ericsson.com> wrote: > Hi Niviya, > > > On 10-04-16 04:18 AM, niviya vijayan wrote: > >> Hi , >> I have a query regarding the interface initialization process for an ip= v6 >> enabled interface. >> >> As per the RFC4861, the node has to join >> a. All-node multicast address{FE02::1} >> >> b. Solicited multicast address {FF02::1:ff00:> ipaddress>} >> >> >> I have tried capturing packets for one of the switch while configuring = an >> ipv6 address. I could see IPv6 node (Ipv6 address) joining =91All node >> multicast address=92 and =91Solicited multicast address=92. Apart from t= hat I am >> seeing an extra join request from the Link Local address to the =91All n= ode >> multicast address=92. Any specific reason for this? Is this a correct >> behaviour ?or is there any requirement for joining link local address on= the >> all node multicast node while creating an ipv6 address on the interface?= why >> it is required? if it is required, then this message will repeat for eac= h & >> every ipv6 address created on an interface since it has only one link-lo= cal >> address. >> > > It is very strange that you see a join for the all nodes multicast addres= s. > Nodes don't have to send a MLD join for the link-local all-nodes multicas= t > address and I have never seen an implementation that does this. What I wo= uld > expect is 2 MLD (listener report) joins > > 1) MLD join for the solicited node multicast address from the unspecified > address (to test for the uniqueness of the tentative link-local address). > 2) MLD join for the solicited node multicast address from the link-local > address. > > Cheers > Suresh > > > --00504502cc6280d90d0484a76f04 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
Hi Suresh,
=A0
Thanks for your reply. I have a doubt on your answer.
=A0
As per your comments, there can be two MLD report msg which will join = the node in solicited multicast group . But in the RFC 4861, they have ment= ion there should be a join request to all node multicast group.
.
=A0=A0=20

RFC 4861 Statement:- 7.2.1.Interface Initialization

=93When a multicast-capable interface becomes enabled, the node= MUST join the all-nodes multicast address on that interface, as well as th= e solicited- =A0=A0=A0node multicast address corresponding to each of the I= P addresses assigned to the interface.=94

=A0
=A0=A0
I have one more query=A0 regarding NA messages.
=A0
While creating ipv6 address on an interface, unsolicited NA messages w= ill be sent to all node multicast address to inform all other nodes in the = network. When i tried this scenario , I have seen two NA=A0messages.
=A0
1) source as ipv6 address and destination as ipv6 all node address.
2) source as link-local address and destination as ipv6 all node addre= ss.
=A0
My question is, whenever there is a change in ipv6 address on a node, = both these 2 NA messages will propogate through the network?
or is it really required to share about the link-local address as we a= re not at all changing the ipv6 link-local address.?
=A0
Thanks in advance,
Niviya

=A0
On Fri, Apr 16, 2010 at 8:41 PM, Suresh Krishnan= <suresh.krishnan@ericsson.com> wrote:
Hi Niviya,=20


On 10-04-16 04:18 AM, niviya vijayan wrote:
Hi ,
=A0I have a query regard= ing the interface initialization process for an ipv6 enabled interface.
= =A0
=A0As per the RFC4861, the node has to join
a. =A0 =A0 =A0 All-node mul= ticast address{FE02::1}

b. =A0 =A0 =A0Solicited multicast address {F= F02::1:ff00:<last 24 bits of ipaddress>}

=A0
I have tried c= apturing =A0packets for one of the switch while configuring an ipv6 address= . I could see IPv6 node (Ipv6 address) joining =91All node multicast addres= s=92 and =91Solicited multicast address=92. Apart from that I am seeing an = extra join request from the Link Local address to the =91All node multicast= address=92. =A0Any specific reason for this? Is this a correct behaviour ?= or is there any requirement for joining link local address on the all node = multicast node while creating an ipv6 address on the interface? why it is r= equired? if it is required, then this message will repeat for each & ev= ery ipv6 address created on an interface since it has only one link-local a= ddress.

It is very strange that you see a join for the all n= odes multicast address. Nodes don't have to send a MLD join for the lin= k-local all-nodes multicast address and I have never seen an implementation= that does this. What I would expect is 2 MLD (listener report) joins

1) MLD join for the solicited node multicast address from the unspecifi= ed address (to test for the uniqueness of the tentative link-local address)= .
2) MLD join for the solicited node multicast address from the link-loc= al address.

Cheers
Suresh



--00504502cc6280d90d0484a76f04-- From shrinivas_ashok.joshi@alcatel-lucent.com Tue Apr 20 05:48:47 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 36EBB3A6BB4 for ; Tue, 20 Apr 2010 05:48:47 -0700 (PDT) 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 KTurSY2LnUPB for ; Tue, 20 Apr 2010 05:48:41 -0700 (PDT) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by core3.amsl.com (Postfix) with ESMTP id 86B663A69E8 for ; Tue, 20 Apr 2010 05:48:41 -0700 (PDT) Received: from inbansmailrelay1.in.alcatel-lucent.com (h135-250-11-31.lucent.com [135.250.11.31]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id o3KCmQoB022132 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 20 Apr 2010 07:48:28 -0500 (CDT) Received: from INBANSXCHHUB03.in.alcatel-lucent.com (inbansxchhub03.in.alcatel-lucent.com [135.250.12.80]) by inbansmailrelay1.in.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id o3KCmPUQ005739 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 20 Apr 2010 18:18:25 +0530 Received: from INBANSXCHMBSA3.in.alcatel-lucent.com ([135.250.12.50]) by INBANSXCHHUB03.in.alcatel-lucent.com ([135.250.12.80]) with mapi; Tue, 20 Apr 2010 18:18:25 +0530 From: "JOSHI, SHRINIVAS ASHOK (SHRINIVAS ASHOK)" To: niviya vijayan , Suresh Krishnan Date: Tue, 20 Apr 2010 18:18:24 +0530 Subject: RE: RFC 4861:-Link-Local address joining all-node multicast group. Thread-Topic: RFC 4861:-Link-Local address joining all-node multicast group. Thread-Index: Acrgf7zm17caCvUZTMugyrMFRDWxWwAB52/Q Message-ID: References: <4BC87E3E.80504@ericsson.com> 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="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 X-Scanned-By: MIMEDefang 2.64 on 135.250.11.31 Cc: "ipv6@ietf.org" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Apr 2010 12:48:47 -0000 >> My question is, whenever there is a change in ipv6 address on a node, bo= th these 2 NA messages will propogate through the network? >> or is it really required to share about the link-local address as we are= not at all changing the ipv6 link-local address.? If link local ipv6 is already active, DAD needs to be performed only for c= hanged ipv6 address (and not link local).=20 No need to send DAD for link local once again. -- Shree From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of niv= iya vijayan Sent: Tuesday, April 20, 2010 2:40 PM To: Suresh Krishnan Cc: ipv6@ietf.org Subject: Re: RFC 4861:-Link-Local address joining all-node multicast group. Hi Suresh, =A0 Thanks for your reply. I have a doubt on your answer. =A0 As per your comments, there can be two MLD report msg which will join the n= ode in solicited multicast group . But in the RFC 4861, they have mention t= here should be a join request to all node multicast group. . =A0=A0=20 RFC 4861 Statement:- 7.2.1.Interface Initialization=20 "When a multicast-capable interface becomes enabled, the node MUST join the= all-nodes multicast address on that interface, as well as the solicited- = =A0=A0=A0node multicast address corresponding to each of the IP addresses a= ssigned to the interface." =A0 =A0=A0 I have one more query=A0 regarding NA messages. =A0 While creating ipv6 address on an interface, unsolicited NA messages will b= e sent to all node multicast address to inform all other nodes in the netwo= rk. When i tried this scenario , I have seen two NA=A0messages.=20 =A0 1) source as ipv6 address and destination as ipv6 all node address. 2) source as link-local address and destination as ipv6 all node address. =A0 My question is, whenever there is a change in ipv6 address on a node, both = these 2 NA messages will propogate through the network? or is it really required to share about the link-local address as we are no= t at all changing the ipv6 link-local address.? =A0 Thanks in advance, Niviya =A0 On Fri, Apr 16, 2010 at 8:41 PM, Suresh Krishnan wrote: Hi Niviya,=20 On 10-04-16 04:18 AM, niviya vijayan wrote: Hi , =A0I have a query regarding the interface initialization process for an ipv= 6 enabled interface. =A0 =A0As per the RFC4861, the node has to join=20 a. =A0 =A0 =A0 All-node multicast address{FE02::1} b. =A0 =A0 =A0Solicited multicast address {FF02::1:ff00:} =A0 I have tried capturing =A0packets for one of the switch while configuring a= n ipv6 address. I could see IPv6 node (Ipv6 address) joining 'All node mult= icast address' and 'Solicited multicast address'. Apart from that I am seei= ng an extra join request from the Link Local address to the 'All node multi= cast address'. =A0Any specific reason for this? Is this a correct behaviour= ?or is there any requirement for joining link local address on the all nod= e multicast node while creating an ipv6 address on the interface? why it is= required? if it is required, then this message will repeat for each & ever= y ipv6 address created on an interface since it has only one link-local add= ress. It is very strange that you see a join for the all nodes multicast address.= Nodes don't have to send a MLD join for the link-local all-nodes multicast= address and I have never seen an implementation that does this. What I wou= ld expect is 2 MLD (listener report) joins 1) MLD join for the solicited node multicast address from the unspecified a= ddress (to test for the uniqueness of the tentative link-local address). 2) MLD join for the solicited node multicast address from the link-local ad= dress. Cheers Suresh From remi.despres@free.fr Tue Apr 20 06:52:54 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 CE3F23A6A9A for ; Tue, 20 Apr 2010 06:52:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.226 X-Spam-Level: X-Spam-Status: No, score=0.226 tagged_above=-999 required=5 tests=[AWL=-0.425, 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 M47SOcbwj4bf for ; Tue, 20 Apr 2010 06:52:54 -0700 (PDT) Received: from smtp6-g21.free.fr (smtp6-g21.free.fr [212.27.42.6]) by core3.amsl.com (Postfix) with ESMTP id A12A13A6AAC for ; Tue, 20 Apr 2010 06:52:52 -0700 (PDT) Received: from smtp6-g21.free.fr (localhost [127.0.0.1]) by smtp6-g21.free.fr (Postfix) with ESMTP id 5DBDFE080C7; Tue, 20 Apr 2010 15:52:37 +0200 (CEST) Received: from [192.168.0.13] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by smtp6-g21.free.fr (Postfix) with ESMTP id 21FFDE0813B; Tue, 20 Apr 2010 15:52:35 +0200 (CEST) Subject: Re: Draft-krishnan-ipv6-exthdr-08 to become asap a 6man WG draft ? Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: <4BC8BDD7.9030101@ericsson.com> Date: Tue, 20 Apr 2010 15:52:34 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <74BD2EE3-B470-41D7-A340-FB1C7A9948EB@free.fr> References: <4BC64100.303@gmail.com> <535BCC7B-196D-4E2A-99ED-7C6D9A5839DB@apple.com> <5CF3944B-A8C4-41D9-BE32-D154878FA27F@free.fr> <4BC8BDD7.9030101@ericsson.com> To: Suresh Krishnan X-Mailer: Apple Mail (2.1078) Cc: Bob Hinden , Brian Haberman , 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: Tue, 20 Apr 2010 13:52:54 -0000 Le 16 avr. 2010 =E0 21:43, Suresh Krishnan a =E9crit : >> I don't know exactly what the status of draft-krishnan-ipv6-exthdr-08 = is today, but it this proposal has IMHO to become quickly a = standard-track RFC: >> - The ability of skipping an extension header in a node that doesn't = know it is clearly needed. - This need should have been satisfied in the = original IPv6 specification. >> I therefore support that this draft should become asap a 6man WG = document. >=20 > As James chimed in, we let the draft expire because there was no clear = consensus in the WG as to the need to define new extension headers. Your draft, which has authors from Ericsson, Cisco, Google, Symantec, = covers per se a wide spectrum of industrial perspectives.=20 What would be needed to differ its adoption would be, IMHO, arguments = showing that it mighgt be harmful. AFAIK, no such argument exists. On the contrary, Stig Venaas wrote on 2010-04-16: "It's clear to me that this draft is needed. Ever since I wrote some packet analyzer code many years ago and realized I couldn't handle unknown IPv6 options in a good way (that is, ignoring them and still finding the transport header)." > We have addressed all the comments received from the WG in the last = version the draft. > We can refresh the draft and request the chairs for adoption, provided = we see somebody trying to define or seeing a need to define a new = extension header. Waiting for this new extension header to be found useful would be IMHO a = DESIGN MISTAKE: if and when such an extension is found useful, it will = be too late because ALL codes that look for ports will need to be = upgraded before deployment of the new extension. If the 6man chair may accept a resubmission as WG draft in view of the = recent discussion on this list (i.e. significant interest expressed, and = no objection), this would be the best. If this isn't possible, your reviving the draft would leave a chance to = finally solve a real problem. Cheers, RD From root@core3.amsl.com Tue Apr 20 09:00:02 2010 Return-Path: X-Original-To: ipv6@ietf.org Delivered-To: ipv6@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 3F3C63A6B3E; Tue, 20 Apr 2010 09:00:02 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Subject: I-D Action:draft-ietf-6man-ipv6-subnet-model-11.txt Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20100420160002.3F3C63A6B3E@core3.amsl.com> Date: Tue, 20 Apr 2010 09:00:02 -0700 (PDT) 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, 20 Apr 2010 16:00:02 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPv6 Maintenance Working Group of the IETF. Title : IPv6 Subnet Model: the Relationship between Links and Subnet Prefixes Author(s) : H. Singh, et al. Filename : draft-ietf-6man-ipv6-subnet-model-11.txt Pages : 13 Date : 2010-04-20 IPv6 specifies a model of a subnet that is different than the IPv4 subnet model. The subtlety of the differences has resulted in incorrect implementations that do not interoperate. This document spells out the most important difference: that an IPv6 address isn't automatically associated with an IPv6 on-link prefix. This document also updates (partially due to security concerns caused by incorrect implementations) a part of the definition of on-link from [RFC4861]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-6man-ipv6-subnet-model-11.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-ipv6-subnet-model-11.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-04-20085544.I-D@ietf.org> --NextPart-- From jhw@apple.com Tue Apr 20 09:25:58 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 4CA543A6944 for ; Tue, 20 Apr 2010 09:25:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.299 X-Spam-Level: X-Spam-Status: No, score=-106.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, 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 kJx64E3NAQmg for ; Tue, 20 Apr 2010 09:25:57 -0700 (PDT) Received: from mail-out4.apple.com (mail-out4.apple.com [17.254.13.23]) by core3.amsl.com (Postfix) with ESMTP id 7607E3A68BC for ; Tue, 20 Apr 2010 09:25:57 -0700 (PDT) Received: from relay14.apple.com (relay14.apple.com [17.128.113.52]) by mail-out4.apple.com (Postfix) with ESMTP id B297796059CB; Tue, 20 Apr 2010 09:25:48 -0700 (PDT) X-AuditID: 11807134-b7b22ae000005450-22-4bcdd5853e8b Received: from [17.151.103.117] (Unknown_Domain [17.151.103.117]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client did not present a certificate) by relay14.apple.com (Apple SCV relay) with SMTP id 63.7D.21584.985DDCB4; Tue, 20 Apr 2010 09:25:48 -0700 (PDT) Subject: Re: Draft-krishnan-ipv6-exthdr-08 to become asap a 6man WG draft ? Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=iso-8859-1 From: james woodyatt In-Reply-To: <74BD2EE3-B470-41D7-A340-FB1C7A9948EB@free.fr> Date: Tue, 20 Apr 2010 09:25:39 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <30EBFCF3-26B2-409B-A047-DC168A397A9C@apple.com> References: <4BC64100.303@gmail.com> <535BCC7B-196D-4E2A-99ED-7C6D9A5839DB@apple.com> <5CF3944B-A8C4-41D9-BE32-D154878FA27F@free.fr> <4BC8BDD7.9030101@ericsson.com> <74BD2EE3-B470-41D7-A340-FB1C7A9948EB@free.fr> To: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= X-Mailer: Apple Mail (2.1078) X-Brightmail-Tracker: AAAAAQAAAZE= 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: Tue, 20 Apr 2010 16:25:58 -0000 On Apr 20, 2010, at 06:52, R=E9mi Despr=E9s wrote: >=20 > Waiting for this new extension header to be found useful would be IMHO = a DESIGN MISTAKE: if and when such an extension is found useful, it will = be too late because ALL codes that look for ports will need to be = upgraded before deployment of the new extension. I think this argues that we should position I-D.krishnan-ipv6-exthdr as = an update to RFC 3692 and instruct IANA to reserve two additional = numbers for experimental IPv6 extension headers, which we then require = to be formatted accordingly, and which we also permit nodes to silently = ignore if they do not support processing them. The general problem of distinguishing extension headers from upper-layer = transports by a programmatic method is, I suspect, not worth the trouble = that would surely be involved in solving it. -- james woodyatt member of technical staff, communications engineering From remi.despres@free.fr Tue Apr 20 09:56:54 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 2CBF43A6AAB for ; Tue, 20 Apr 2010 09:56:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.252 X-Spam-Level: X-Spam-Status: No, score=-0.252 tagged_above=-999 required=5 tests=[AWL=0.208, BAYES_05=-1.11, 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 vGAD6vYffqVF for ; Tue, 20 Apr 2010 09:56:52 -0700 (PDT) Received: from smtp6-g21.free.fr (smtp6-g21.free.fr [212.27.42.6]) by core3.amsl.com (Postfix) with ESMTP id 438633A6AF7 for ; Tue, 20 Apr 2010 09:56:50 -0700 (PDT) Received: from smtp6-g21.free.fr (localhost [127.0.0.1]) by smtp6-g21.free.fr (Postfix) with ESMTP id 2631BE0805C; Tue, 20 Apr 2010 18:56:37 +0200 (CEST) Received: from [192.168.0.13] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by smtp6-g21.free.fr (Postfix) with ESMTP id B823BE0803A; Tue, 20 Apr 2010 18:56:34 +0200 (CEST) Subject: Re: Draft-krishnan-ipv6-exthdr-08 to become asap a 6man WG draft ? Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: <30EBFCF3-26B2-409B-A047-DC168A397A9C@apple.com> Date: Tue, 20 Apr 2010 18:56:34 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <1D5C7613-684E-4139-A338-3D5B91328CA9@free.fr> References: <4BC64100.303@gmail.com> <535BCC7B-196D-4E2A-99ED-7C6D9A5839DB@apple.com> <5CF3944B-A8C4-41D9-BE32-D154878FA27F@free.fr> <4BC8BDD7.9030101@ericsson.com> <74BD2EE3-B470-41D7-A340-FB1C7A9948EB@free.fr> <30EBFCF3-26B2-409B-A047-DC168A397A9C@apple.com> To: james woodyatt X-Mailer: Apple Mail (2.1078) 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: Tue, 20 Apr 2010 16:56:54 -0000 Hi James, Using the experimental status seems to me confusing (and why two numbers = instead of one?) If the draft becomes a standard-track RFC, as originally proposed but so = far insufficiently supported, we will have all what is needed, simply an = cleanly. I hope this can happen. Regards, RD Le 20 avr. 2010 =E0 18:25, james woodyatt a =E9crit : > On Apr 20, 2010, at 06:52, R=E9mi Despr=E9s wrote: >>=20 >> Waiting for this new extension header to be found useful would be = IMHO a DESIGN MISTAKE: if and when such an extension is found useful, it = will be too late because ALL codes that look for ports will need to be = upgraded before deployment of the new extension. >=20 > I think this argues that we should position I-D.krishnan-ipv6-exthdr = as an update to RFC 3692 and instruct IANA to reserve two additional = numbers for experimental IPv6 extension headers, which we then require = to be formatted accordingly, and which we also permit nodes to silently = ignore if they do not support processing them. >=20 > The general problem of distinguishing extension headers from = upper-layer transports by a programmatic method is, I suspect, not worth = the trouble that would surely be involved in solving it. >=20 >=20 > -- > james woodyatt > member of technical staff, communications engineering >=20 >=20 From jhw@apple.com Tue Apr 20 10:35:16 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 D8F903A69C2 for ; Tue, 20 Apr 2010 10:35:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.773 X-Spam-Level: X-Spam-Status: No, score=-104.773 tagged_above=-999 required=5 tests=[AWL=-0.333, BAYES_20=-0.74, MIME_8BIT_HEADER=0.3, 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 WYGUAcOhOTlc for ; Tue, 20 Apr 2010 10:35:16 -0700 (PDT) Received: from mail-out3.apple.com (mail-out3.apple.com [17.254.13.22]) by core3.amsl.com (Postfix) with ESMTP id 0E62E3A68BF for ; Tue, 20 Apr 2010 10:35:16 -0700 (PDT) Received: from relay14.apple.com (relay14.apple.com [17.128.113.52]) by mail-out3.apple.com (Postfix) with ESMTP id 26D7B8F083C5; Tue, 20 Apr 2010 10:35:07 -0700 (PDT) X-AuditID: 11807134-b7b22ae000005450-57-4bcde5cae2a5 Received: from il0601a-dhcp08.apple.com (il0601a-dhcp08.apple.com [17.206.14.136]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client did not present a certificate) by relay14.apple.com (Apple SCV relay) with SMTP id CC.9F.21584.BC5EDCB4; Tue, 20 Apr 2010 10:35:07 -0700 (PDT) Subject: Re: Draft-krishnan-ipv6-exthdr-08 to become asap a 6man WG draft ? Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=iso-8859-1 From: james woodyatt In-Reply-To: <1D5C7613-684E-4139-A338-3D5B91328CA9@free.fr> Date: Tue, 20 Apr 2010 10:35:06 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4BC64100.303@gmail.com> <535BCC7B-196D-4E2A-99ED-7C6D9A5839DB@apple.com> <5CF3944B-A8C4-41D9-BE32-D154878FA27F@free.fr> <4BC8BDD7.9030101@ericsson.com> <74BD2EE3-B470-41D7-A340-FB1C7A9948EB@free.fr> <30EBFCF3-26B2-409B-A047-DC168A397A9C@apple.com> <1D5C7613-684E-4139-A338-3D5B91328CA9@free.fr> To: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= X-Mailer: Apple Mail (2.1078) X-Brightmail-Tracker: AAAAAQAAAZE= 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: Tue, 20 Apr 2010 17:35:16 -0000 On Apr 20, 2010, at 09:56, R=E9mi Despr=E9s wrote: > Using the experimental status seems to me confusing (and why two = numbers instead of one?) There are two numbers reserved for protocols, and I was plagued by the = hobgoblins of consistency. I suppose we could assign only one. Or more = than two. It's a discussion point. > If the draft becomes a standard-track RFC, as originally proposed but = so far insufficiently supported, we will have all what is needed, simply = an cleanly. Okay... how do you propose that IPv6 nodes and/or packet analyzers = programmatically distinguish between extension headers and upper-layer = transports if they are given only an unrecognized protocol number = without access to the online IANA assigned protocol numbers database? I think if you pull on the threads of that question, you will quickly = come to a snarly knot of related problems that are A) difficult, and B) = probably not worth solving if you bypass them with a simple update to = RFC 3692 as I just proposed. ----- To reiterate, I think the original motive for bringing this up, = extracting 5-tuples from IPv6 packets, is a bad idea. In general, only = some IPv6 packets have 5-tuples, and of those, only a subset can have = 5-tuples that packet analyzers can extract, i.e. the rest are = encapsulated in ESP or a moral equivalent (and ESP packets have = 4-tuples). Hosts should set flow labels. They should probably use RFC 2205 if they = need fine-grained resource reservations to claw out marginal capacity in = under-provisioned networks. Otherwise, they should ride the best-effort = bus like everyone else. -- james woodyatt member of technical staff, communications engineering From suresh.krishnan@ericsson.com Tue Apr 20 15:48:49 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 F0EC43A6955 for ; Tue, 20 Apr 2010 15:48:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.713 X-Spam-Level: X-Spam-Status: No, score=-5.713 tagged_above=-999 required=5 tests=[AWL=0.886, 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 jw0maMwzBn2f for ; Tue, 20 Apr 2010 15:48:48 -0700 (PDT) Received: from imr1.ericy.com (imr1.ericy.com [198.24.6.9]) by core3.amsl.com (Postfix) with ESMTP id 22F0F3A6953 for ; Tue, 20 Apr 2010 15:48:47 -0700 (PDT) Received: from eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) by imr1.ericy.com (8.13.1/8.13.1) with ESMTP id o3KMrEPH027026; Tue, 20 Apr 2010 17:53:14 -0500 Received: from [142.133.10.113] (147.117.20.212) by eusaamw0706.eamcs.ericsson.se (147.117.20.91) with Microsoft SMTP Server id 8.1.375.2; Tue, 20 Apr 2010 18:48:36 -0400 Message-ID: <4BCE2DE0.6010908@ericsson.com> Date: Tue, 20 Apr 2010 18:42:40 -0400 From: Suresh Krishnan User-Agent: Thunderbird 2.0.0.24 (X11/20100411) MIME-Version: 1.0 To: james woodyatt Subject: Re: Draft-krishnan-ipv6-exthdr-08 to become asap a 6man WG draft ? References: <4BC64100.303@gmail.com> <535BCC7B-196D-4E2A-99ED-7C6D9A5839DB@apple.com> <5CF3944B-A8C4-41D9-BE32-D154878FA27F@free.fr> <4BC8BDD7.9030101@ericsson.com> <74BD2EE3-B470-41D7-A340-FB1C7A9948EB@free.fr> <30EBFCF3-26B2-409B-A047-DC168A397A9C@apple.com> <1D5C7613-684E-4139-A338-3D5B91328CA9@free.fr> In-Reply-To: Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 8bit Cc: 6man 6man X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Apr 2010 22:48:49 -0000 Hi James, On 10-04-20 01:35 PM, james woodyatt wrote: > On Apr 20, 2010, at 09:56, Rémi Després wrote: >> Using the experimental status seems to me confusing (and why two numbers instead of one?) > > There are two numbers reserved for protocols, and I was plagued by the hobgoblins of consistency. I suppose we could assign only one. Or more than two. It's a discussion point. > >> If the draft becomes a standard-track RFC, as originally proposed but so far insufficiently supported, we will have all what is needed, simply an cleanly. > > Okay... how do you propose that IPv6 nodes and/or packet analyzers programmatically distinguish between extension headers and upper-layer transports if they are given only an unrecognized protocol number without access to the online IANA assigned protocol numbers database? Simple. All future IPv6 extension headers will use the same next header value (the one allocated for the GIEH). Anything else can be considered a unknown upper layer header. Cheers Suresh From suresh.krishnan@ericsson.com Tue Apr 20 15:59:01 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 347923A6B64 for ; Tue, 20 Apr 2010 15:59:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.787 X-Spam-Level: X-Spam-Status: No, score=-3.787 tagged_above=-999 required=5 tests=[AWL=-1.188, 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 p+7nPswKd76q for ; Tue, 20 Apr 2010 15:59:00 -0700 (PDT) Received: from imr3.ericy.com (imr3.ericy.com [198.24.6.13]) by core3.amsl.com (Postfix) with ESMTP id 4A0653A6953 for ; Tue, 20 Apr 2010 15:59:00 -0700 (PDT) Received: from eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) by imr3.ericy.com (8.13.8/8.13.8) with ESMTP id o3KMwmhQ031778 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 20 Apr 2010 17:58:49 -0500 Received: from [142.133.10.113] (147.117.20.212) by eusaamw0711.eamcs.ericsson.se (147.117.20.179) with Microsoft SMTP Server id 8.1.375.2; Tue, 20 Apr 2010 18:58:48 -0400 Message-ID: <4BCE3045.9030205@ericsson.com> Date: Tue, 20 Apr 2010 18:52:53 -0400 From: Suresh Krishnan User-Agent: Thunderbird 2.0.0.24 (X11/20100411) MIME-Version: 1.0 To: niviya vijayan Subject: Re: RFC 4861:-Link-Local address joining all-node multicast group. References: <4BC87E3E.80504@ericsson.com> In-Reply-To: Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 8bit 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, 20 Apr 2010 22:59:01 -0000 Hi Niviya, On 10-04-20 05:09 AM, niviya vijayan wrote: > Hi Suresh, > > Thanks for your reply. I have a doubt on your answer. > > As per your comments, there can be two MLD report msg which will join > the node in solicited multicast group . But in the RFC 4861, they have > mention there should be a join request to all node multicast group. As described in section 6 of RFC3810 MLD reports are not sent for the all-nodes multicast address " The link-scope all-nodes multicast address, (FF02::1), is handled as a special case. On all nodes -- that is all hosts and routers, including multicast routers -- listening to packets destined to the all-nodes multicast address, from all sources, is permanently enabled on all interfaces on which multicast listening is supported. No MLD messages are ever sent regarding neither the link-scope all-nodes multicast address, nor any multicast address of scope 0 (reserved) or 1 (node-local)." > . > > > RFC 4861 Statement:- 7.2.1.Interface Initialization > > “When a multicast-capable interface becomes enabled, the node MUST join > the all-nodes multicast address on that interface, as well as the > solicited- node multicast address corresponding to each of the IP > addresses assigned to the interface.” > > > > I have one more query regarding NA messages. > > While creating ipv6 address on an interface, unsolicited NA messages > will be sent to all node multicast address to inform all other nodes in > the network. When i tried this scenario , I have seen two NA messages. > > 1) source as ipv6 address and destination as ipv6 all node address. > 2) source as link-local address and destination as ipv6 all node address. > > My question is, whenever there is a change in ipv6 address on a node, > both these 2 NA messages will propogate through the network? > or is it really required to share about the link-local address as we are > not at all changing the ipv6 link-local address.? It is unclear what the circumstances are. Specifically, what action did you perform that resulted in these messages? Did you change the MAC address of the card? Cheers Suresh From jhw@apple.com Tue Apr 20 18:02: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 759303A6880 for ; Tue, 20 Apr 2010 18:02:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.735 X-Spam-Level: X-Spam-Status: No, score=-105.735 tagged_above=-999 required=5 tests=[AWL=0.864, 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 59sAhseq7xF3 for ; Tue, 20 Apr 2010 18:02:11 -0700 (PDT) Received: from mail-out4.apple.com (mail-out4.apple.com [17.254.13.23]) by core3.amsl.com (Postfix) with ESMTP id 8FC2E3A6874 for ; Tue, 20 Apr 2010 18:02:11 -0700 (PDT) Received: from relay11.apple.com (relay11.apple.com [17.128.113.48]) by mail-out4.apple.com (Postfix) with ESMTP id BC9509618AD9; Tue, 20 Apr 2010 18:02:02 -0700 (PDT) X-AuditID: 11807130-b7cbdae0000079bd-1a-4bce4e8a435d Received: from il0602f-dhcp79.apple.com (il0602f-dhcp79.apple.com [17.206.50.79]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client did not present a certificate) by relay11.apple.com (Apple SCV relay) with SMTP id E8.D3.31165.A8E4ECB4; Tue, 20 Apr 2010 18:02:02 -0700 (PDT) Subject: Re: I-D.krishnan-ipv6-exthdr to 6man WG draft ? Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii From: james woodyatt In-Reply-To: <4BCE2DE0.6010908@ericsson.com> Date: Tue, 20 Apr 2010 18:02:02 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <057276D1-642A-4CC0-B212-189BCA343347@apple.com> References: <4BC64100.303@gmail.com> <535BCC7B-196D-4E2A-99ED-7C6D9A5839DB@apple.com> <5CF3944B-A8C4-41D9-BE32-D154878FA27F@free.fr> <4BC8BDD7.9030101@ericsson.com> <74BD2EE3-B470-41D7-A340-FB1C7A9948EB@free.fr> <30EBFCF3-26B2-409B-A047-DC168A397A9C@apple.com> <1D5C7613-684E-4139-A338-3D5B91328CA9@free.fr> <4BCE2DE0.6010908@ericsson.com> To: Suresh Krishnan X-Mailer: Apple Mail (2.1078) X-Brightmail-Tracker: AAAAAQAAAZE= Cc: 6MAN Working 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: Wed, 21 Apr 2010 01:02:12 -0000 On Apr 20, 2010, at 15:42, Suresh Krishnan wrote: >=20 > Simple. All future IPv6 extension headers will use the same next = header value (the one allocated for the GIEH). Anything else can be = considered a unknown upper layer header. That's proposed informally in the draft, but it doesn't appear to be = formalized in any way, which is why I wasn't sure that it would be safe = for packet analyzers to assume they could identify all the extension = headers. (Grmf. And I'm nominally a co-author on the draft.) I'd say there are two changes we should make to Section 6, IANA = Considerations, in the next revision: + instruct IANA to reserve GIEH sub-type values for experimental = purposes and cite RFC 3692. + instruct IANA to require a *separate* IETF standards action to allow = IPv6 extension headers to be numbered from the assigned protocol number = database *before* assigning any such numbers to a new extension header. -- james woodyatt member of technical staff, communications engineering From brian.e.carpenter@gmail.com Tue Apr 20 21:34:17 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 DE56D3A69DD for ; Tue, 20 Apr 2010 21:34:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.323 X-Spam-Level: X-Spam-Status: No, score=-2.323 tagged_above=-999 required=5 tests=[AWL=0.276, 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 6Ut02UvXnYn1 for ; Tue, 20 Apr 2010 21:34:17 -0700 (PDT) Received: from mail-pv0-f172.google.com (mail-pv0-f172.google.com [74.125.83.172]) by core3.amsl.com (Postfix) with ESMTP id 10CE528C0DF for ; Tue, 20 Apr 2010 21:33:23 -0700 (PDT) Received: by pvg7 with SMTP id 7so90315pvg.31 for ; Tue, 20 Apr 2010 21:33:12 -0700 (PDT) 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=n5y2d4JJo6sxno0QBvocTWf7HVxpNqBNPqd/a9Zk984=; b=gDcJnySx9nybOMjgGbqb/ksT5McSfW1hCbTmgxg+5Ym9ZdYuxVbmpehSNqXZ/OQmcf JTHZhpdJuDfJk64p77fEJMl5tKqs0hHpaLK+1NUjiZyTOGIPEr2+qdaSRqAQamPmz//z CCXJHB14mIZUX4QmrNr28UUAkr9h2ldopztf4= 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=BMo0R2BqRbdk8UCXtBwKxF+Uw5mDXowB2XIloa+gBgFVOOvF89qWpfF50S9K7i9NGG 6r8Ryeiuj+YHY2oC/AAjt7CZL/NbEHT4Txhhh0u7xqKqSmC5CzcPRmuImuZTcQWd0WRT DFxcd/8T/Rx5JpGl/DpjFhsbYjvweu1gXrUMo= Received: by 10.114.189.13 with SMTP id m13mr6715110waf.130.1271824392461; Tue, 20 Apr 2010 21:33:12 -0700 (PDT) Received: from [130.216.38.124] (stf-brian.sfac.auckland.ac.nz [130.216.38.124]) by mx.google.com with ESMTPS id 21sm6961567pzk.12.2010.04.20.21.33.09 (version=SSLv3 cipher=RC4-MD5); Tue, 20 Apr 2010 21:33:11 -0700 (PDT) Message-ID: <4BCE7FFF.4090108@gmail.com> Date: Wed, 21 Apr 2010 16:33:03 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Mark Smith Subject: Re: [Fwd: New Version Notification for draft-carpenter-6man-flow-update-02] References: <4BC54919.3000900@gmail.com> <20100415072936.60eb08ac@opy.nosense.org> <4BC63DF0.6070707@gmail.com> <20100415191648.13efcb8d@opy.nosense.org> <4BC7A644.2040403@gmail.com> <20100419071125.32b5b70c@opy.nosense.org> In-Reply-To: <20100419071125.32b5b70c@opy.nosense.org> 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: Wed, 21 Apr 2010 04:34:18 -0000 Mark, I was hoping someone else might chime in, but since they didn't, let me extract from your messages: > So those [IPFIX] timeouts are more to do with emission of flow records, and > flow cache maintenance, rather than being a more general definition of > what a flow is Certainly. But supposing someone was led to build a stateful flow marker. (That's on the assumption that we change the rules to allow routers to overwrite the flow label.) A stateful marker would have exactly the same problem with UDP flows as an IPFIX meter. By contrast, a source host never has this problem, because it knows by construction when a flow ends (chances are, flow == socket). Brian On 2010-04-19 09:41, Mark Smith wrote: > Hi Brian, > > On Fri, 16 Apr 2010 11:50:28 +1200 > Brian E Carpenter wrote: > >> Hi Mark, >> >>> Are you generally trying to avoid it because it would appear to be an >>> implied IETF definition of a flow, rather than just the IPv6 >>> definition? Or is it to avoid having to start defining the a possibly >>> large set of flow definitions? >> Actually, because I have enough email to deal with right now anyway :-) >> >> Your proposed definition looks reasonable, but the IPFIX people have >> a rather different definition: >> >> "A flow is defined as a set of IP packets passing an observation point >> in the network during a certain time interval. All packets belonging >> to a particular flow have a set of common properties.... >> A flow is considered to be expired if no packet of this flow has been >> observed for a given timeout interval" [RFC3917] >> >> The crucial difference is the tiemout. In the observational world >> of IPFIX, a flow is deemed to end when there is a certain period of >> silence. So a stop-start flow meeting your definition might be >> broken up into multiple flows by IPFIX. That's where things get vague. >> > > My understanding is that IPFIX is generally an IETF standardised > version of Cisco's Netflow. In Netflow, timeouts are needed for a > few reasons: > > o A timeout is used to expire flows for protocols that aren't > connection oriented (e.g. UDP) or the implementation doesn't know > are connection oriented because the implementation doesn't understand > the protocol. When the timeout occurs, a netflow record is emitted > towards the netflow collector, and the router clears the netflow cache > entry for the flow. > > o Long lived TCP connections may go for long enough that people want > to know partial flow information about them. This timeout is an upper > bound on how long a flow can continue before a netflow record is > emitted. The TCP flow stays active in the flow cache, so there will be > at least another netflow record at the end of the TCP connection or if > the flow cache becomes full and the flow is punted from it. > > So those timeouts are more to do with emission of flow records, and > flow cache maintenance, rather than being a more general definition of > what a flow is. > > Regards, > Mark. > From pch-b6B5344D9@u-1.phicoh.com Wed Apr 21 00:11:54 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 859B43A6A59 for ; Wed, 21 Apr 2010 00:11:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.599 X-Spam-Level: X-Spam-Status: No, score=-4.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_I_LETTER=-2] 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 Y5QpSCojsHJ7 for ; Wed, 21 Apr 2010 00:11:53 -0700 (PDT) Received: from stereo.hq.phicoh.net (stereo.hq.phicoh.net [130.37.15.35]) by core3.amsl.com (Postfix) with ESMTP id 795803A6A3C for ; Wed, 21 Apr 2010 00:11:51 -0700 (PDT) Received: from stereo.hq.phicoh.net ([127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #2) id m1O4U5z-0001dDC; Wed, 21 Apr 2010 09:11 +0200 Message-Id: To: Brian E Carpenter Subject: Re: [Fwd: New Version Notification for draft-carpenter-6man-flow-update-02] From: Philip Homburg Sender: pch-b6B5344D9@u-1.phicoh.com References: <4BC54919.3000900@gmail.com> <20100415072936.60eb08ac@opy.nosense.org> <4BC63DF0.6070707@gmail.com> <20100415191648.13efcb8d@opy.nosense.org> <4BC7A644.2040403@gmail.com> <20100419071125.32b5b70c@opy.nosense.org> <4BCE7FFF.4090108@gmail.com> In-reply-to: Your message of "Wed, 21 Apr 2010 16:33:03 +1200 ." <4BCE7FFF.4090108@gmail.com> Date: Wed, 21 Apr 2010 09:11:38 +0200 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: Wed, 21 Apr 2010 07:11:54 -0000 In your letter dated Wed, 21 Apr 2010 16:33:03 +1200 you wrote: >By contrast, a source host >never has this problem, because it knows by construction when a flow >ends (chances are, flow == socket). I'm wondering about the 'never' part. What if an application uses sendto() to communicate over UDP with multiple peers, and some of those peers happen to be located on a single remote host. How is the kernel supposed to keep track of those flows? Or does the application have to maintain flow-ids? From remi.despres@free.fr Wed Apr 21 01:44:17 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 77AB93A6A0E for ; Wed, 21 Apr 2010 01:44:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.006 X-Spam-Level: X-Spam-Status: No, score=-1.006 tagged_above=-999 required=5 tests=[AWL=0.943, 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 ZR6UmYuuqL7L for ; Wed, 21 Apr 2010 01:44:13 -0700 (PDT) Received: from smtp6-g21.free.fr (smtp6-g21.free.fr [212.27.42.6]) by core3.amsl.com (Postfix) with ESMTP id 4AA1F3A679C for ; Wed, 21 Apr 2010 01:44:11 -0700 (PDT) Received: from smtp6-g21.free.fr (localhost [127.0.0.1]) by smtp6-g21.free.fr (Postfix) with ESMTP id 11059E0813A; Wed, 21 Apr 2010 10:43:58 +0200 (CEST) Received: from [192.168.0.13] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by smtp6-g21.free.fr (Postfix) with ESMTP id D7B9DE081AC; Wed, 21 Apr 2010 10:43:55 +0200 (CEST) Subject: Re: Draft-krishnan-ipv6-exthdr-08 to become asap a 6man WG draft ? Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: Date: Wed, 21 Apr 2010 10:43:55 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <5AD500D8-B59B-4DCE-A9E8-93B1CA5848E6@free.fr> References: <4BC64100.303@gmail.com> <535BCC7B-196D-4E2A-99ED-7C6D9A5839DB@apple.com> <5CF3944B-A8C4-41D9-BE32-D154878FA27F@free.fr> <4BC8BDD7.9030101@ericsson.com> <74BD2EE3-B470-41D7-A340-FB1C7A9948EB@free.fr> <30EBFCF3-26B2-409B-A047-DC168A397A9C@apple.com> <1D5C7613-684E-4139-A338-3D5B91328CA9@free.fr> To: james woodyatt X-Mailer: Apple Mail (2.1078) Cc: 6man 6man X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Apr 2010 08:44:17 -0000 Le 20 avr. 2010 =E0 19:35, james woodyatt a =E9crit : > On Apr 20, 2010, at 09:56, R=E9mi Despr=E9s wrote: >> Using the experimental status seems to me confusing (and why two = numbers instead of one?) >=20 > There are two numbers reserved for protocols, and I was plagued by the = hobgoblins of consistency. I suppose we could assign only one. Or more = than two. It's a discussion point. In my understanding, the draft needs only one, to be standardized rather = than experimented. I personally sees no reason to change this (see below) >> If the draft becomes a standard-track RFC, as originally proposed but = so far insufficiently supported, we will have all what is needed, simply = an cleanly. >=20 > Okay... how do you propose that IPv6 nodes and/or packet analyzers = programmatically distinguish between extension headers and upper-layer = transports if they are given only an unrecognized protocol number = without access to the online IANA assigned protocol numbers database? If a packet analyzer needs to recognize a protocol above IP: - It skips all extensions headers specified before 2010, with due = knowledge of their individual format. - It skips all extension headers specified later (they are identified by = their common GIEH number in next-header fields that precedes them, and = their lengths are found in their common "Hdr Ext Len" fields). - When it finds a different next-header value, it is that of the = protocol above IP. (Then it can do whatever it has to do on the found protocol above IP, = e.g process ports numbers if it is TCP, UDP, DCCP, SCTP, and discard = others if it is a stateful translator. Its code no longer needs an = update if and when new IP-layer extension headers are introduced in the = future.) =20 > I think if you pull on the threads of that question, you will quickly = come to a snarly knot of related problems that are A) difficult, and B) = probably not worth solving if you bypass them with a simple update to = RFC 3692 as I just proposed. >=20 > ----- >=20 > To reiterate, I think the original motive for bringing this up, = extracting 5-tuples from IPv6 packets, is a bad idea. I agree that this is a bad idea as regards the flow-label discussion, = essentially because of what Mark Smith pointed out: this doesn't work on = a per packet basis for fragmented IPv6 datagrams. BUT draft-krishnan-ipv6-exthdr-08 was proposed before this discussion, = and with a motivation that still holds on its own, and is sufficient in = my understanding to justify its endorsement. > In general, only some IPv6 packets have 5-tuples, and of those, only = a subset can have 5-tuples that packet analyzers can extract, i.e. the = rest are encapsulated in ESP or a moral equivalent (and ESP packets have = 4-tuples). >=20 > Hosts should set flow labels. =20 Agreed. This should be IMHO the conclusion of the current discussion on flow = labels, BUT provided hosts are explicitly permitted to set flow-label = values statelessly for each datagram, with a hash of their 5-tuples. (RFC 3697 says "To avoid accidental Flow Label value reuse, the source = node SHOULD select new Flow Label values in a well-defined sequence", = which privileges flow-label assignments that are stateful per = connection, a choice significantly more complex than needed.) Regards, RD =20 > They should probably use RFC 2205 if they need fine-grained resource = reservations to claw out marginal capacity in under-provisioned = networks. Otherwise, they should ride the best-effort bus like everyone = else.=20 >=20 > -- > james woodyatt > member of technical staff, communications engineering >=20 >=20 From remi.despres@free.fr Wed Apr 21 01:50:34 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 895BB28C0EF for ; Wed, 21 Apr 2010 01:50:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.047 X-Spam-Level: X-Spam-Status: No, score=-1.047 tagged_above=-999 required=5 tests=[AWL=0.902, 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 xtj33g9WGW6n for ; Wed, 21 Apr 2010 01:50:33 -0700 (PDT) Received: from smtp6-g21.free.fr (smtp6-g21.free.fr [212.27.42.6]) by core3.amsl.com (Postfix) with ESMTP id 4F6713A6358 for ; Wed, 21 Apr 2010 01:50:25 -0700 (PDT) Received: from smtp6-g21.free.fr (localhost [127.0.0.1]) by smtp6-g21.free.fr (Postfix) with ESMTP id 8C051E08148; Wed, 21 Apr 2010 10:50:12 +0200 (CEST) Received: from [192.168.0.13] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by smtp6-g21.free.fr (Postfix) with ESMTP id 8ADF0E080C2; Wed, 21 Apr 2010 10:50:10 +0200 (CEST) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Apple Message framework v1078) Subject: Stateless assignment of flow-labels in source hosts From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= Date: Wed, 21 Apr 2010 10:50:10 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <6029E6FA-DF50-409F-8EB6-2F67D1A886FF@free.fr> References: <5AD500D8-B59B-4DCE-A9E8-93B1CA5848E6@free.fr> To: Brian E Carpenter X-Mailer: Apple Mail (2.1078) Cc: 6man 6man X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Apr 2010 08:50:34 -0000 Hi Brian, I wonder what you think of what I answered to James on another = discussion thread. Regards, RD =20 D=E9but du message r=E9exp=E9di=E9 : > De : R=E9mi Despr=E9s > Date : 21 avril 2010 10:43:55 HAEC > =C0 : james woodyatt > Cc : 6man 6man > Objet : R=E9p : Draft-krishnan-ipv6-exthdr-08 to become asap a 6man WG = draft ? >=20 > ... >> In general, only some IPv6 packets have 5-tuples, and of those, only = a subset can have 5-tuples that packet analyzers can extract, i.e. the = rest are encapsulated in ESP or a moral equivalent (and ESP packets have = 4-tuples). >>=20 >> Hosts should set flow labels. =20 >=20 > Agreed. >=20 > This should be IMHO the conclusion of the current discussion on flow = labels, BUT provided hosts are explicitly permitted to set flow-label = values statelessly for each datagram, with a hash of their 5-tuples. > (RFC 3697 says "To avoid accidental Flow Label value reuse, the source = node SHOULD select new Flow Label values in a well-defined sequence", = which privileges flow-label assignments that are stateful per = connection, a choice significantly more complex than needed.) >=20 From niviya.vijayan.t@gmail.com Tue Apr 20 22:29:55 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 9B3303A6992 for ; Tue, 20 Apr 2010 22:29:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.548 X-Spam-Level: X-Spam-Status: No, score=-2.548 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, HTML_MESSAGE=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 aS6UKpYcYf0E for ; Tue, 20 Apr 2010 22:29:54 -0700 (PDT) Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by core3.amsl.com (Postfix) with ESMTP id ACEC93A6A28 for ; Tue, 20 Apr 2010 22:29:20 -0700 (PDT) Received: by pwj2 with SMTP id 2so4863293pwj.31 for ; Tue, 20 Apr 2010 22:29:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:received:message-id:subject:from:to:cc:content-type; bh=L9lXNO4mY93+2aVx+t68n1CGS6AGeieChjlEG0JrQnQ=; b=JKxaYuirFFCl1jlVBA2LQpRAq8HrIMYvRyQi4sDVi7wdUb3noRiboh0BNMqqFO7jxX /wnH/23PWMqn/LVpT7GnBaoezhej+FuRK582sL+YY+BllCqm4Ym3e1nR4mwwfezMpros 5SEntJ+VlWb87D9nS3XhJhKtu/E2FIyHXKfX8= 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=mNzcfJEBMCEknIv9rxqdi+eZ8ZfeTZ/h9YtXzgVlbltKjkxjmUo0PtCh8Ed8CTtEz+ HnUKykyBNu47baMnNGpWimqgRlmgK5zrHSU7a450rIuAcJMgetvDWKEHuObDj1XrRxH7 k8VkL7Y9HglWtuxk+7bFf/0qg1NssCW3d6mP4= MIME-Version: 1.0 Received: by 10.142.180.6 with HTTP; Tue, 20 Apr 2010 22:29:08 -0700 (PDT) In-Reply-To: <4BCE3045.9030205@ericsson.com> References: <4BC87E3E.80504@ericsson.com> <4BCE3045.9030205@ericsson.com> Date: Wed, 21 Apr 2010 10:59:08 +0530 Received: by 10.143.177.5 with SMTP id e5mr3597824wfp.304.1271827748732; Tue, 20 Apr 2010 22:29:08 -0700 (PDT) Message-ID: Subject: Re: RFC 4861:-Link-Local address joining all-node multicast group. From: niviya vijayan To: Suresh Krishnan Content-Type: multipart/alternative; boundary=000e0cd4d9982dbe9f0484b879a1 X-Mailman-Approved-At: Wed, 21 Apr 2010 01:55:50 -0700 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, 21 Apr 2010 05:29:55 -0000 --000e0cd4d9982dbe9f0484b879a1 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Suresh, RFC 4861 Statement:- 7.2.1.Interface Initialization =93When a multicast-capable interface becomes enabled, the node MUST join t= he all-nodes multicast address on that interface, as well as the solicited- node multicast address corresponding to each of the IP addresses assigned to the interface.=94 *Any idea What does this statement mean?* For the second query:- I didnt change the MAC address of the card. I tried creating a new ipv6 address on the interface and I have seen these two unsolicited NA messages.My question is , Why the node is sending unsolicited NA message ( with source as "link-local address" & destination as "all-node multicast address").I am expecting only one unsolicited NA message( with source as "ipv6 global address" & destination as "all-node multicast address"). I am not at all changing the link-local address and the link-local address is already active on the interface. Regards, Niviya On Wed, Apr 21, 2010 at 4:22 AM, Suresh Krishnan < suresh.krishnan@ericsson.com> wrote: > Hi Niviya, > > > On 10-04-20 05:09 AM, niviya vijayan wrote: > >> Hi Suresh, >> Thanks for your reply. I have a doubt on your answer. >> As per your comments, there can be two MLD report msg which will join t= he >> node in solicited multicast group . But in the RFC 4861, they have menti= on >> there should be a join request to all node multicast group. >> > > As described in section 6 of RFC3810 MLD reports are not sent for the > all-nodes multicast address > > " The link-scope all-nodes multicast address, (FF02::1), is handled as > a special case. On all nodes -- that is all hosts and routers, > including multicast routers -- listening to packets destined to the > all-nodes multicast address, from all sources, is permanently enabled > on all interfaces on which multicast listening is supported. No MLD > messages are ever sent regarding neither the link-scope all-nodes > multicast address, nor any multicast address of scope 0 (reserved) or > 1 (node-local)." > > > . >> >> RFC 4861 Statement:- 7.2.1.Interface Initialization >> >> =93When a multicast-capable interface becomes enabled, the node MUST joi= n >> the all-nodes multicast address on that interface, as well as the solici= ted- >> node multicast address corresponding to each of the IP addresses assi= gned >> to the interface.=94 >> >> I have one more query regarding NA messages. >> While creating ipv6 address on an interface, unsolicited NA messages wi= ll >> be sent to all node multicast address to inform all other nodes in the >> network. When i tried this scenario , I have seen two NA messages. >> 1) source as ipv6 address and destination as ipv6 all node address. >> 2) source as link-local address and destination as ipv6 all node address= . >> My question is, whenever there is a change in ipv6 address on a node, >> both these 2 NA messages will propogate through the network? >> or is it really required to share about the link-local address as we are >> not at all changing the ipv6 link-local address.? >> > > It is unclear what the circumstances are. Specifically, what action did y= ou > perform that resulted in these messages? Did you change the MAC address o= f > the card? > Hi Suresh, I didnt change the MAC address of the card. I tried creating a new ipv6 address on the interface and I have seen these two unsolicited NA messages.My question is , Why the node is sending unsolicited NA message ( with source as "link-local address" & destination as "all-node multicast address").I am expecting only one unsolicited NA message( with source as "ipv6 global address" & destination as "all-node multicast address"). I am not at all changing the link-local address and the link-local address is already active on the interface. > > Cheers > Suresh > > > > --000e0cd4d9982dbe9f0484b879a1 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
Hi Suresh,
=A0
RFC 4861 Statement:- 7.2.1.Interface Initializ= ation

=93When a multicast-capable interface becomes enabled, the nod= e MUST join the all-nodes multicast address on that interface, as well as t= he solicited- =A0 =A0node multicast address corresponding to each of the IP= addresses assigned to the interface.=94
Any idea What does this statement mean?
=A0
For the second query:-
=A0
I didnt change the MAC address of the card. I = tried creating a new ipv6 address on the interface and I have seen these tw= o unsolicited NA messages.My question is , Why the node is sending unsolici= ted NA message ( with source as "link-local address" & destin= ation as "all-node multicast address").I am expecting only one un= solicited NA message( with source as "ipv6 global address" & = destination as "all-node multicast address").=A0=A0I am not at al= l changing the link-local address and the link-local address is already act= ive on the interface.=A0
=A0
Regards,
Niviya

=A0
On Wed, Apr 21, 2010 at 4:22 AM, Suresh Krishnan= <sure= sh.krishnan@ericsson.com> wrote:
Hi Niviya,=20


On 10-04-20 05:09 AM, niviya vijayan wrote:
Hi Suresh,
=A0Thanks for your= reply. I have a doubt on your answer.
=A0As per your comments, there ca= n be two MLD report msg which will join the node in solicited multicast gro= up . But in the RFC 4861, they have mention there should be a join request = to all node multicast group.

As described in section 6 of RFC3810 MLD reports are= not sent for the all-nodes multicast address

" =A0The link-sco= pe all-nodes multicast address, (FF02::1), is handled as
=A0 a special c= ase. =A0On all nodes -- that is all hosts and routers,
=A0 including multicast routers -- listening to packets destined to the
= =A0 all-nodes multicast address, from all sources, is permanently enabled=A0 on all interfaces on which multicast listening is supported. =A0No ML= D
=A0 messages are ever sent regarding neither the link-scope all-nodes
= =A0 multicast address, nor any multicast address of scope 0 (reserved) or=A0 1 (node-local)."=20


.
=A0
RFC 4861 Statement:-= 7.2.1.Interface Initialization

=93When a multicast-capable interfac= e becomes enabled, the node MUST join the all-nodes multicast address on th= at interface, as well as the solicited- =A0 =A0node multicast address corre= sponding to each of the IP addresses assigned to the interface.=94

=A0 I have one more query =A0regarding NA messages.
=A0While creatin= g ipv6 address on an interface, unsolicited NA messages will be sent to all= node multicast address to inform all other nodes in the network. When i tr= ied this scenario , I have seen two NA messages.
=A01) source as ipv6 address and destination as ipv6 all node address.
2= ) source as link-local address and destination as ipv6 all node address.=A0My question is, whenever there is a change in ipv6 address on a node, b= oth these 2 NA messages will propogate through the network?
or is it really required to share about the link-local address as we are no= t at all changing the ipv6 link-local address.?

I= t is unclear what the circumstances are. Specifically, what action did you = perform that resulted in these messages? Did you change the MAC address of = the card?
=A0
Hi Suresh,
=A0
I didnt change the MAC address of the card. I tried creating a new ipv= 6 address on the interface and I have seen these two unsolicited NA message= s.My question is , Why the node is sending unsolicited NA message ( with so= urce as "link-local address" & destination as "all-node = multicast address").I am expecting only one unsolicited NA message( wi= th source as "ipv6 global address" & destination as "all= -node multicast address").=A0=A0I am not at all changing the link-loca= l address and the link-local address is already active on the interface.=A0=

Cheers
Suresh




--000e0cd4d9982dbe9f0484b879a1-- From tena@huawei.com Wed Apr 21 03:17:57 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 73A903A684C for ; Wed, 21 Apr 2010 03:17:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.888 X-Spam-Level: X-Spam-Status: No, score=-101.888 tagged_above=-999 required=5 tests=[AWL=0.710, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xhhvg-ADh2B8 for ; Wed, 21 Apr 2010 03:17:55 -0700 (PDT) Received: from szxga02-in.huawei.com (szxga02-in.huawei.com [119.145.14.65]) by core3.amsl.com (Postfix) with ESMTP id 2D9703A6B4F for ; Wed, 21 Apr 2010 03:17:41 -0700 (PDT) Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0L1800JVF1X594@szxga02-in.huawei.com> for ipv6@ietf.org; Wed, 21 Apr 2010 18:17:30 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0L18008CO1X5PC@szxga02-in.huawei.com> for ipv6@ietf.org; Wed, 21 Apr 2010 18:17:29 +0800 (CST) Received: from z00147053k ([10.70.39.148]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0L1800BE41X59G@szxml06-in.huawei.com> for ipv6@ietf.org; Wed, 21 Apr 2010 18:17:29 +0800 (CST) Date: Wed, 21 Apr 2010 18:17:29 +0800 From: Tina TSOU Subject: Ping...//Re: Questions on RFC 4293 Management Information Base for the Internet Protocol (IP) To: ipv6@ietf.org, v6ops@ops.ietf.org, Bob Hinden , Dan Romascanu , fenner@fenron.com, fenner@gmail.com, dthaler@microsoft.com, brian@innovationslab.net, brian.haberman@jhuapl.edu, sar@iwl.com Message-id: <691A690E805140C2A6EA5D2ACC20D399@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 X-Mailer: Microsoft Outlook Express 6.00.2900.5843 Content-type: multipart/alternative; boundary="Boundary_(ID_Nj2WRiFwsz/OonLhGOfD0A)" X-Priority: 3 X-MSMail-priority: Normal References: 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, 21 Apr 2010 10:17:57 -0000 This is a multi-part message in MIME format. --Boundary_(ID_Nj2WRiFwsz/OonLhGOfD0A) Content-type: text/plain; charset=gb2312 Content-transfer-encoding: 7BIT No answer from anywhere, even the State of Confusion... B. R. Tina http://tinatsou.weebly.com/contact.html ----- Original Message ----- From: Tina TSOU To: ipv6@ietf.org ; v6ops@ops.ietf.org ; Bob Hinden ; Dan Romascanu ; fenner@fenron.com ; fenner@gmail.com ; dthaler@microsoft.com ; brian@innovationslab.net ; brian.haberman@jhuapl.edu ; sar@iwl.com Sent: Tuesday, April 20, 2010 11:11 AM Subject: Questions on RFC 4293 Management Information Base for the Internet Protocol (IP) Hi all, In RFC 4293, - ipAddressTable is described as writable, this table uses address as index, but the critical information for configuring address, the address prefix ipAddressPrefix node is read-only. It seems contradict to me. This table uses address as index, but the public network and VPN may have exactly the same IP address. This table does not explicitly say whether it only supports public network. If supporting VPN at the same time, there might occur the following case: only on address is displayed among the same IP addresses. ipAddressTable OBJECT-TYPE SYNTAX SEQUENCE OF IpAddressEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table contains addressing information relevant to the entity's interfaces. This table does not contain multicast address information. Tables for such information should be contained in multicast specific MIBs, such as RFC 3019. While this table is writable, the user will note that several objects, such as ipAddressOrigin, are not. The intention in allowing a user to write to this table is to allow them to add or remove any entry that isn't permanent. The user should be allowed to modify objects and entries when that would not cause inconsistencies within the table. Allowing write access to objects, such as ipAddressOrigin, could allow a user to insert an entry and then label it incorrectly. ipAddressPrefix OBJECT-TYPE SYNTAX RowPointer MAX-ACCESS read-only STATUS current DESCRIPTION "A pointer to the row in the prefix table to which this address belongs. May be { 0 0 } if there is no such row." DEFVAL { zeroDotZero } ::= { ipAddressEntry 5 } B. R. Tina http://tinatsou.weebly.com/contact.html --Boundary_(ID_Nj2WRiFwsz/OonLhGOfD0A) Content-type: text/html; charset=gb2312 Content-transfer-encoding: 7BIT
No answer from anywhere, even the State of Confusion...
 
----- Original Message -----
From: Tina TSOU
Sent: Tuesday, April 20, 2010 11:11 AM
Subject: Questions on RFC 4293 Management Information Base for the Internet Protocol (IP)

Hi all,
In RFC 4293,
- ipAddressTable is described as writable, this table uses address
as index, but the critical information for configuring address, the
address prefix ipAddressPrefix node is read-only. It seems
contradict to me.
This table uses address as index, but the public network and VPN
may have exactly the same IP address. This table does not
explicitly say whether it only supports public network. If
supporting VPN at the same time, there might occur the following
case: only on address is displayed among the same IP addresses.
ipAddressTable OBJECT-TYPE
   SYNTAX     SEQUENCE OF IpAddressEntry
   MAX-ACCESS not-accessible
   STATUS     current
   DESCRIPTION
          "This table contains addressing information relevant to the
           entity's interfaces.
           This table does not contain multicast address information.
           Tables for such information should be contained in multicast
           specific MIBs, such as RFC 3019.
           While this table is writable, the user will note that
           several objects, such as ipAddressOrigin, are not.  The
           intention in allowing a user to write to this table is to
           allow them to add or remove any entry that isn't
           permanent.  The user should be allowed to modify objects
           and entries when that would not cause inconsistencies
           within the table.  Allowing write access to objects, such
           as ipAddressOrigin, could allow a user to insert an entry
           and then label it incorrectly.
ipAddressPrefix OBJECT-TYPE
   SYNTAX     RowPointer
   MAX-ACCESS read-only
   STATUS     current
   DESCRIPTION
          "A pointer to the row in the prefix table to which this
           address belongs.  May be { 0 0 } if there is no such row."
   DEFVAL { zeroDotZero }
   ::= { ipAddressEntry 5 }
 
--Boundary_(ID_Nj2WRiFwsz/OonLhGOfD0A)-- From shrinivas_ashok.joshi@alcatel-lucent.com Wed Apr 21 04:01:59 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 CA09D3A6B70 for ; Wed, 21 Apr 2010 04:01:59 -0700 (PDT) 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 jIzDaKM3lFwW for ; Wed, 21 Apr 2010 04:01:58 -0700 (PDT) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by core3.amsl.com (Postfix) with ESMTP id F3BB73A6B60 for ; Wed, 21 Apr 2010 04:01:57 -0700 (PDT) Received: from inbansmailrelay1.in.alcatel-lucent.com (h135-250-11-31.lucent.com [135.250.11.31]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id o3LB1c4P004336 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 21 Apr 2010 06:01:40 -0500 (CDT) Received: from INBANSXCHHUB02.in.alcatel-lucent.com (inbansxchhub02.in.alcatel-lucent.com [135.250.12.35]) by inbansmailrelay1.in.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id o3LB1b1N028763 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 21 Apr 2010 16:31:37 +0530 Received: from INBANSXCHMBSA3.in.alcatel-lucent.com ([135.250.12.50]) by INBANSXCHHUB02.in.alcatel-lucent.com ([135.250.12.35]) with mapi; Wed, 21 Apr 2010 16:31:37 +0530 From: "JOSHI, SHRINIVAS ASHOK (SHRINIVAS ASHOK)" To: niviya vijayan , Suresh Krishnan Date: Wed, 21 Apr 2010 16:31:35 +0530 Subject: RE: RFC 4861:-Link-Local address joining all-node multicast group. Thread-Topic: RFC 4861:-Link-Local address joining all-node multicast group. Thread-Index: AcrhMIj7Laaw7B94TgG3JrFxvucFBgADgKdg Message-ID: References: <4BC87E3E.80504@ericsson.com> <4BCE3045.9030205@ericsson.com> 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="iso-8859-1" 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.31 Cc: "ipv6@ietf.org" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Apr 2010 11:01:59 -0000 Niviya, >> "When a multicast-capable interface becomes enabled, the node MUST join = the all-nodes multicast address on that interface, as well as the solicited= - =20 >> node multicast address corresponding to each of the IP addresses assigne= d to the interface." >> Any idea What does this statement mean? [Shree] If the hosts on link are connected through a multicast aware device= (e.g. switch with MLD proxy), =20 these messages are intended to inform the switch that host is interested i= n receiving packets destined=20 to all -nodes and solicited node multicast address.=20 >> Why the node is sending unsolicited NA message ( with source as "link-lo= cal address" & destination as "all-node multicast address"). >> I am expecting only one unsolicited NA message( with source as "ipv6 glo= bal address" & destination as "all-node multicast address"). =20 >> I am not at all changing the link-local address and the link-local addre= ss is already active on the interface. [Shree] If you are assigning an address the node should send out Neighbor s= olicitation=20 as part of Duplicate Address Detection(source as unspecified address and d= estination as solicited node multicast address). >From what you are seeing it looks like link layer address is getting change= d, one way to verify it is through the override flag and source link layer = address option n unsolicited neighbor advertisement. Before and after you apply the ipv6 a= ddress. -- Shree From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of niv= iya vijayan Sent: Wednesday, April 21, 2010 10:59 AM To: Suresh Krishnan Cc: ipv6@ietf.org Subject: Re: RFC 4861:-Link-Local address joining all-node multicast group. Hi Suresh, =A0 RFC 4861 Statement:- 7.2.1.Interface Initialization "When a multicast-capable interface becomes enabled, the node MUST join the= all-nodes multicast address on that interface, as well as the solicited- = =A0 =A0node multicast address corresponding to each of the IP addresses ass= igned to the interface." Any idea What does this statement mean? =A0 For the second query:- =A0 I didnt change the MAC address of the card. I tried creating a new ipv6 add= ress on the interface and I have seen these two unsolicited NA messages.My = question is , Why the node is sending unsolicited NA message ( with source = as "link-local address" & destination as "all-node multicast address").I am= expecting only one unsolicited NA message( with source as "ipv6 global add= ress" & destination as "all-node multicast address").=A0=A0I am not at all = changing the link-local address and the link-local address is already activ= e on the interface.=A0 =A0 Regards, Niviya =A0 On Wed, Apr 21, 2010 at 4:22 AM, Suresh Krishnan wrote: Hi Niviya,=20 On 10-04-20 05:09 AM, niviya vijayan wrote: Hi Suresh, =A0Thanks for your reply. I have a doubt on your answer. =A0As per your comments, there can be two MLD report msg which will join th= e node in solicited multicast group . But in the RFC 4861, they have mentio= n there should be a join request to all node multicast group. As described in section 6 of RFC3810 MLD reports are not sent for the all-n= odes multicast address " =A0The link-scope all-nodes multicast address, (FF02::1), is handled as =A0 a special case. =A0On all nodes -- that is all hosts and routers, =A0 including multicast routers -- listening to packets destined to the =A0 all-nodes multicast address, from all sources, is permanently enabled =A0 on all interfaces on which multicast listening is supported. =A0No MLD =A0 messages are ever sent regarding neither the link-scope all-nodes =A0 multicast address, nor any multicast address of scope 0 (reserved) or =A0 1 (node-local)."=20 . =A0 RFC 4861 Statement:- 7.2.1.Interface Initialization "When a multicast-capable interface becomes enabled, the node MUST join the= all-nodes multicast address on that interface, as well as the solicited- = =A0 =A0node multicast address corresponding to each of the IP addresses ass= igned to the interface." =A0 I have one more query =A0regarding NA messages. =A0While creating ipv6 address on an interface, unsolicited NA messages wil= l be sent to all node multicast address to inform all other nodes in the ne= twork. When i tried this scenario , I have seen two NA messages. =A01) source as ipv6 address and destination as ipv6 all node address. 2) source as link-local address and destination as ipv6 all node address. =A0My question is, whenever there is a change in ipv6 address on a node, bo= th these 2 NA messages will propogate through the network? or is it really required to share about the link-local address as we are no= t at all changing the ipv6 link-local address.? It is unclear what the circumstances are. Specifically, what action did you= perform that resulted in these messages? Did you change the MAC address of= the card? =A0 Hi Suresh, =A0 I didnt change the MAC address of the card. I tried creating a new ipv6 add= ress on the interface and I have seen these two unsolicited NA messages.My = question is , Why the node is sending unsolicited NA message ( with source = as "link-local address" & destination as "all-node multicast address").I am= expecting only one unsolicited NA message( with source as "ipv6 global add= ress" & destination as "all-node multicast address").=A0=A0I am not at all = changing the link-local address and the link-local address is already activ= e on the interface.=A0 Cheers Suresh From fenner@fenron.com Wed Apr 21 04:53:29 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 904543A6B8A for ; Wed, 21 Apr 2010 04:53:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.977 X-Spam-Level: X-Spam-Status: No, score=-101.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 8IRBrcwpVB+G for ; Wed, 21 Apr 2010 04:53:28 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by core3.amsl.com (Postfix) with ESMTP id 05A0A3A6B88 for ; Wed, 21 Apr 2010 04:53:15 -0700 (PDT) Received: by vws10 with SMTP id 10so999530vws.31 for ; Wed, 21 Apr 2010 04:53:03 -0700 (PDT) MIME-Version: 1.0 Sender: fenner@fenron.com Received: by 10.220.16.197 with HTTP; Wed, 21 Apr 2010 04:53:03 -0700 (PDT) In-Reply-To: References: Date: Wed, 21 Apr 2010 07:53:03 -0400 X-Google-Sender-Auth: 544bda473c51e036 Received: by 10.220.126.166 with SMTP id c38mr5638299vcs.49.1271850783416; Wed, 21 Apr 2010 04:53:03 -0700 (PDT) Message-ID: Subject: Re: Questions on RFC 4293 Management Information Base for the Internet Protocol (IP) From: Bill Fenner To: Tina TSOU Content-Type: text/plain; charset=ISO-8859-1 Cc: fenner@gmail.com, brian@innovationslab.net, ipv6@ietf.org, sar@iwl.com, Bob Hinden , dthaler@microsoft.com, v6ops@ops.ietf.org, brian.haberman@jhuapl.edu 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, 21 Apr 2010 11:53:29 -0000 [sorry if you get duplicates, replying from an address that actually *works* this time] 2010/4/19 Tina TSOU : > In RFC 4293, > - ipAddressTable is described as writable, this table uses address > as index, but the critical information for configuring address, the > address prefix ipAddressPrefix node is read-only. It seems > contradict to me. Worse, the whole ipAddressPrefixTable is read-only, so you can't insert a new row to try to point to. This seems like we didn't pay enough attention to making these configurable via SNMP. > This table uses address as index, but the public network and VPN > may have exactly the same IP address. This table does not > explicitly say whether it only supports public network. As with most MIBs, if you have multiple contexts on the device, you need multiple instances of the MIB, usually using SNMPv3 contexts and the entLogicalTable to associate SNMPv2 communities if needed. Bill From fenner@fenron.com Wed Apr 21 04:51:29 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 A8E6D3A6928 for ; Wed, 21 Apr 2010 04:51:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.977 X-Spam-Level: X-Spam-Status: No, score=-101.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 e9JxM9e1EAHw for ; Wed, 21 Apr 2010 04:51:29 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by core3.amsl.com (Postfix) with ESMTP id CFF753A69AC for ; Wed, 21 Apr 2010 04:51:12 -0700 (PDT) Received: by vws10 with SMTP id 10so998741vws.31 for ; Wed, 21 Apr 2010 04:51:01 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.16.197 with HTTP; Wed, 21 Apr 2010 04:51:00 -0700 (PDT) In-Reply-To: References: Date: Wed, 21 Apr 2010 07:51:00 -0400 Received: by 10.220.121.229 with SMTP id i37mr5577275vcr.237.1271850660753; Wed, 21 Apr 2010 04:51:00 -0700 (PDT) Message-ID: Subject: Re: Questions on RFC 4293 Management Information Base for the Internet Protocol (IP) From: Bill Fenner To: Tina TSOU Content-Type: text/plain; charset=ISO-8859-1 X-Mailman-Approved-At: Wed, 21 Apr 2010 05:04:36 -0700 Cc: fenner@gmail.com, brian@innovationslab.net, ipv6@ietf.org, sar@iwl.com, Bob Hinden , dthaler@microsoft.com, v6ops@ops.ietf.org, brian.haberman@jhuapl.edu 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, 21 Apr 2010 11:51:29 -0000 2010/4/19 Tina TSOU : > In RFC 4293, > - ipAddressTable is described as writable, this table uses address > as index, but the critical information for configuring address, the > address prefix ipAddressPrefix node is read-only. It seems > contradict to me. Worse, the whole ipAddressPrefixTable is read-only, so you can't insert a new row to try to point to. This seems like we didn't pay enough attention to making these configurable via SNMP. > This table uses address as index, but the public network and VPN > may have exactly the same IP address. This table does not > explicitly say whether it only supports public network. As with most MIBs, if you have multiple contexts on the device, you need multiple instances of the MIB, usually using SNMPv3 contexts and the entLogicalTable to associate SNMPv2 communities if needed. Bill From fred@cisco.com Wed Apr 21 08:39:21 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 AB37B28C12C for ; Wed, 21 Apr 2010 08:39:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.158 X-Spam-Level: X-Spam-Status: No, score=-110.158 tagged_above=-999 required=5 tests=[AWL=0.441, 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 kBmENQEv2Cjv for ; Wed, 21 Apr 2010 08:39:20 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 6695428C43C for ; Wed, 21 Apr 2010 08:15:31 -0700 (PDT) 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: AvsEAMqzzkurR7Ht/2dsb2JhbACcEHGjWJpNhQ8EgzQ X-IronPort-AV: E=Sophos;i="4.52,250,1270425600"; d="scan'208";a="186307362" Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-5.cisco.com with ESMTP; 21 Apr 2010 15:15:22 +0000 Received: from stealth-10-32-244-222.cisco.com (stealth-10-32-244-222.cisco.com [10.32.244.222]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o3LFFLeK013585; Wed, 21 Apr 2010 15:15:21 GMT Subject: Re: Questions on RFC 4293 Management Information Base for the Internet Protocol (IP) Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii From: Fred Baker In-Reply-To: Date: Wed, 21 Apr 2010 08:15:21 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Bill Fenner X-Mailer: Apple Mail (2.1078) Cc: Bill Fenner , Brian Haberman , IETF IPv6 Mailing List , sar@iwl.com, Bob Hinden , Dave Thaler , IPv6 v6ops , Brian Haberman 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, 21 Apr 2010 15:39:21 -0000 "we didn't pay enough attention" is a very kind way to put it. The = entire SNMP exercise was about monitoring; those like me who tried to = make things writable pushed rocks uphill politically. That, and the = experience of trying to make event triggered management rather than = poll-driven management, is the major reason that I, personally, don't = want to have anything to do with network management in the IETF. On Apr 21, 2010, at 4:53 AM, Bill Fenner wrote: > [sorry if you get duplicates, replying from an address that actually > *works* this time] >=20 > 2010/4/19 Tina TSOU : >> In RFC 4293, >> - ipAddressTable is described as writable, this table uses address >> as index, but the critical information for configuring address, the >> address prefix ipAddressPrefix node is read-only. It seems >> contradict to me. >=20 > Worse, the whole ipAddressPrefixTable is read-only, so you can't > insert a new row to try to point to. This seems like we didn't pay > enough attention to making these configurable via SNMP. >=20 >> This table uses address as index, but the public network and VPN >> may have exactly the same IP address. This table does not >> explicitly say whether it only supports public network. >=20 > As with most MIBs, if you have multiple contexts on the device, you > need multiple instances of the MIB, usually using SNMPv3 contexts and > the entLogicalTable to associate SNMPv2 communities if needed. >=20 > Bill > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- http://www.ipinc.net/IPv4.GIF From brian.e.carpenter@gmail.com Wed Apr 21 14:13:06 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 CB53E3A6AF1 for ; Wed, 21 Apr 2010 14:13:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.332 X-Spam-Level: X-Spam-Status: No, score=-3.332 tagged_above=-999 required=5 tests=[AWL=1.267, BAYES_00=-2.599, GB_I_LETTER=-2] 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 FkeIA0oNCsSX for ; Wed, 21 Apr 2010 14:13:06 -0700 (PDT) Received: from mail-pz0-f198.google.com (mail-pz0-f198.google.com [209.85.222.198]) by core3.amsl.com (Postfix) with ESMTP id CEC1B3A6962 for ; Wed, 21 Apr 2010 14:13:04 -0700 (PDT) Received: by pzk36 with SMTP id 36so1607666pzk.24 for ; Wed, 21 Apr 2010 14:12:53 -0700 (PDT) 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=nW+eM0stWqYPhcAm1XX4Uay0lZWvMFmsXutYc51WZ5w=; b=V39SHNFR5kSQ+kcodFbh7UdzYzcaEfxT9VQkMgsbMiBUDKOGs5W9eS7F+zOfxS/o1y b4ADfCWilbLY6JozGzyhQF7Ym0u2fJ/XMwFnLCfl8FJ7E0rZErLZtbT3rohYdsU02+pI SYCwGb3JldVCgg219u0DBm5hcj/5M8Pu0h5Mc= 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=hOFyxGOtuPMWciOs4lTuAzpGbWmHqSr6mT6LzutP2cnprZ+VOASFkfguJXnMlkJnbO TOwpSlVsi+8vDtKf7YiNLDVfy2IwYDmHak4t25yPB6h2CQhkMxcsM13zDtFqfo3ki3Qo jbzSfbnq5IgwcAxO0DyqPx2mNENEfJI14LT9Y= Received: by 10.141.91.13 with SMTP id t13mr4440013rvl.266.1271884372945; Wed, 21 Apr 2010 14:12:52 -0700 (PDT) Received: from [130.216.38.124] (stf-brian.sfac.auckland.ac.nz [130.216.38.124]) by mx.google.com with ESMTPS id g14sm10301705rvb.1.2010.04.21.14.12.50 (version=SSLv3 cipher=RC4-MD5); Wed, 21 Apr 2010 14:12:51 -0700 (PDT) Message-ID: <4BCF6A4D.9040601@gmail.com> Date: Thu, 22 Apr 2010 09:12:45 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Philip Homburg Subject: Re: [Fwd: New Version Notification for draft-carpenter-6man-flow-update-02] References: <4BC54919.3000900@gmail.com> <20100415072936.60eb08ac@opy.nosense.org> <4BC63DF0.6070707@gmail.com> <20100415191648.13efcb8d@opy.nosense.org> <4BC7A644.2040403@gmail.com> <20100419071125.32b5b70c@opy.nosense.org> <4BCE7FFF.4090108@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: Wed, 21 Apr 2010 21:13:06 -0000 On 2010-04-21 19:11, Philip Homburg wrote: > In your letter dated Wed, 21 Apr 2010 16:33:03 +1200 you wrote: >> By contrast, a source host >> never has this problem, because it knows by construction when a flow >> ends (chances are, flow == socket). > > I'm wondering about the 'never' part. What if an application uses sendto() > to communicate over UDP with multiple peers, and some of those peers happen > to be located on a single remote host. > > How is the kernel supposed to keep track of those flows? Or does the > application have to maintain flow-ids? The latter, I think, in such a complex case. RFC 3697 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." That was because we intentionally did not define exactly what a flow is; the IPv6 WG didn't want to do so at that time. Brian From brian.e.carpenter@gmail.com Wed Apr 21 14:17:25 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 9BE493A68F1 for ; Wed, 21 Apr 2010 14:17:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.22 X-Spam-Level: X-Spam-Status: No, score=-2.22 tagged_above=-999 required=5 tests=[AWL=0.079, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id prIDpzgZdgq6 for ; Wed, 21 Apr 2010 14:17:24 -0700 (PDT) Received: from mail-pz0-f180.google.com (mail-pz0-f180.google.com [209.85.222.180]) by core3.amsl.com (Postfix) with ESMTP id A325E3A680D for ; Wed, 21 Apr 2010 14:17:24 -0700 (PDT) Received: by pzk10 with SMTP id 10so1922170pzk.20 for ; Wed, 21 Apr 2010 14:17:12 -0700 (PDT) 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=OK87smakOhpntUdqtaDGLjdc35oDZv+205DnhU9+liI=; b=gebOY6KPxuiptyaI3c5xQQDFFts9TqU9KKmzSrLogCTsIpwRPX99smFGRVanaYYVTQ qZi6OMlkAnd/I8wb3bSKMRFddm2kZ6q50lyYs8RfgZ5FxNSa/ulwDQMw6OKCn+v0ruZN R9Fq23/7n5n92MIpfB0S6loUX+kfyti6HwrFU= 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=cjxGYYl3iZTI1C09fmYeboB6Zlb0nZrWEOaERCyN1k7WFzqpc0Qzfk7qdt0rmxrmyI aPPYLABIj77tkY4BxS5CD79rC+d4T4oyAu09Q8V9NH43Q2cKUQh8J0ncggzZT7GS4ART PxIYLJrijeVgcr6bPa0gc8CubbQAaQpWCi5xY= Received: by 10.141.2.21 with SMTP id e21mr2633809rvi.193.1271884632664; Wed, 21 Apr 2010 14:17:12 -0700 (PDT) Received: from [130.216.38.124] (stf-brian.sfac.auckland.ac.nz [130.216.38.124]) by mx.google.com with ESMTPS id g14sm10303871rvb.1.2010.04.21.14.17.10 (version=SSLv3 cipher=RC4-MD5); Wed, 21 Apr 2010 14:17:11 -0700 (PDT) Message-ID: <4BCF6B55.3010005@gmail.com> Date: Thu, 22 Apr 2010 09:17:09 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: =?UTF-8?B?UsOpbWkgRGVzcHLDqXM=?= Subject: Re: Stateless assignment of flow-labels in source hosts References: <5AD500D8-B59B-4DCE-A9E8-93B1CA5848E6@free.fr> <6029E6FA-DF50-409F-8EB6-2F67D1A886FF@free.fr> In-Reply-To: <6029E6FA-DF50-409F-8EB6-2F67D1A886FF@free.fr> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: 6man 6man X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Apr 2010 21:17:25 -0000 On 2010-04-21 20:50, R=C3=A9mi Despr=C3=A9s wrote: > Hi Brian, >=20 > I wonder what you think of what I answered to James on another discussi= on thread. I agree. I think that particular SHOULD in the RFC is an error. It "SHOUL= D" have said something like: "The source node MUST select new Flow Label values by a method that prevents unintended Flow Label value reuse." Brian > Regards, > RD > =20 >=20 > D=C3=A9but du message r=C3=A9exp=C3=A9di=C3=A9 : >=20 >> De : R=C3=A9mi Despr=C3=A9s >> Date : 21 avril 2010 10:43:55 HAEC >> =C3=80 : james woodyatt >> Cc : 6man 6man >> Objet : R=C3=A9p : Draft-krishnan-ipv6-exthdr-08 to become asap a 6man= WG draft ? >> >> ... >>> In general, only some IPv6 packets have 5-tuples, and of those, only = a subset can have 5-tuples that packet analyzers can extract, i.e. the re= st are encapsulated in ESP or a moral equivalent (and ESP packets have 4-= tuples). >>> >>> Hosts should set flow labels. =20 >> Agreed. >> >> This should be IMHO the conclusion of the current discussion on flow l= abels, BUT provided hosts are explicitly permitted to set flow-label valu= es statelessly for each datagram, with a hash of their 5-tuples. >> (RFC 3697 says "To avoid accidental Flow Label value reuse, the source= node SHOULD select new Flow Label values in a well-defined sequence", wh= ich privileges flow-label assignments that are stateful per connection, a= choice significantly more complex than needed.) >> >=20 >=20 From brian.e.carpenter@gmail.com Wed Apr 21 19:56:36 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 BC5F93A69CA for ; Wed, 21 Apr 2010 19:56:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.338 X-Spam-Level: X-Spam-Status: No, score=-2.338 tagged_above=-999 required=5 tests=[AWL=0.261, 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 E02Tc4LcDLuQ for ; Wed, 21 Apr 2010 19:56:36 -0700 (PDT) Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by core3.amsl.com (Postfix) with ESMTP id EF4DA3A696D for ; Wed, 21 Apr 2010 19:56:35 -0700 (PDT) Received: by pwj2 with SMTP id 2so5664901pwj.31 for ; Wed, 21 Apr 2010 19:56:24 -0700 (PDT) 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:content-type :content-transfer-encoding; bh=xhB6QAifgKcbb8GKV6RDnCZEKuFl0zbKB+DbPqps3QE=; b=GXo0VaDKME0VTtimwbIUaLnBuCiHhtSaGf4ms6lfIyqmhKjLnuAUQTH39drZ1Z9M7/ XZxPkM4+z3Ug2WcYhhm3x2rt34KWY8j/7c5PtY3vnku+9ZFXT+vWlc1KSNEt3K15gCpy CCnF+YTE9g1ZS0G5LvcU2PcMvKJfTYv6qqS3c= 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:content-type:content-transfer-encoding; b=BIBk3Zmbvax0UmA1iJEneVRGRXWycamXijvlJIenEW0JeJkmSxtzpvFEV7po3ERFYE irANinWEu90KFNKrdDu6BN1JuB4da4m3sbgtJ7s53SY9E+IvWJtes1DcJeCUlLLhOyMG 2AG5/J+L2dAjk2qwulmKpY6ybmN4fwBbirFuQ= Received: by 10.143.84.8 with SMTP id m8mr1290660wfl.293.1271904984047; Wed, 21 Apr 2010 19:56:24 -0700 (PDT) Received: from [130.216.38.124] (stf-brian.sfac.auckland.ac.nz [130.216.38.124]) by mx.google.com with ESMTPS id 23sm708863pzk.10.2010.04.21.19.56.22 (version=SSLv3 cipher=RC4-MD5); Wed, 21 Apr 2010 19:56:23 -0700 (PDT) Message-ID: <4BCFBADA.8090901@gmail.com> Date: Thu, 22 Apr 2010 14:56:26 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: 6man Subject: DRAFT: Request for guidance about the flow label 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: Thu, 22 Apr 2010 02:56:36 -0000 Hi, Sheng and I would like to continue our attempt to make the flow label useful. The discussions in Anaheim and on this list have been very stimulating. I think we need to simplify the change proposed in draft-carpenter-6man-flow-update-02 even more after the recent discussions, while maintaining the proposed duality (RFC 3697-like use still possible, but locally-defined use also possible for those who want it). Independently, I expect to continue with draft-hu-flow-label-cases as background material and with draft-carpenter-flow-ecmp as a specific RFC 3697 use case, with my co-authors on those two drafts. The guidance we need from the 6MAN WG is: should we start to draft rfc3697bis, fixing the issues that have been raised and incorporating the (simplified) proposal from draft-carpenter-6man-flow-update? That would also need a new milestone added to the 6man charter. Regards Brian Carpenter From brian.e.carpenter@gmail.com Wed Apr 21 20:30:08 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 EC1133A6998 for ; Wed, 21 Apr 2010 20:30:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.345 X-Spam-Level: X-Spam-Status: No, score=-2.345 tagged_above=-999 required=5 tests=[AWL=0.254, 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 I9FQDHal2z5O for ; Wed, 21 Apr 2010 20:30:06 -0700 (PDT) Received: from mail-pz0-f187.google.com (mail-pz0-f187.google.com [209.85.222.187]) by core3.amsl.com (Postfix) with ESMTP id C422B3A6912 for ; Wed, 21 Apr 2010 20:30:06 -0700 (PDT) Received: by pzk17 with SMTP id 17so5331365pzk.5 for ; Wed, 21 Apr 2010 20:29:54 -0700 (PDT) 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:content-type :content-transfer-encoding; bh=xhB6QAifgKcbb8GKV6RDnCZEKuFl0zbKB+DbPqps3QE=; b=EdUddx5YzgS5TpZsGZRf3mJIbVsifSjRnPCrjakIcPumQ7dhZ9U6fMxPTRpgc/PaDJ X0pigSgVzDsvs2lKN/qcyHf7Y/Nzvgt5EzG680gLBo8Lbo0l9eSvcfu1sHO/WOAFDSek J8WCA67rGMzDF6Ud7L0Qow1iy+37FQ6V5NyUg= 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:content-type:content-transfer-encoding; b=FIyZIV8D+Ef0RL9tcwikWizJJaptKz1yjnhtJLzLlgu3iVbj3Y9XD2LMnwuywBjlal b65Z4BxUXCuJ2fkLgsT88ucaJl+I0uclT377XzyHkj2FqR9IN0dWgT4GBlKy5wm+kEXr STMMc0tr1Z0pqF4EA5h3zYOf3sSyyLD3s2phs= Received: by 10.141.214.32 with SMTP id r32mr5997021rvq.27.1271906993346; Wed, 21 Apr 2010 20:29:53 -0700 (PDT) Received: from [130.216.38.124] (stf-brian.sfac.auckland.ac.nz [130.216.38.124]) by mx.google.com with ESMTPS id b10sm10457458rvn.3.2010.04.21.20.29.49 (version=SSLv3 cipher=RC4-MD5); Wed, 21 Apr 2010 20:29:52 -0700 (PDT) Message-ID: <4BCFC2AD.4060401@gmail.com> Date: Thu, 22 Apr 2010 15:29:49 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: 6man Subject: Request for guidance about the flow label 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: Thu, 22 Apr 2010 03:30:09 -0000 Hi, Sheng and I would like to continue our attempt to make the flow label useful. The discussions in Anaheim and on this list have been very stimulating. I think we need to simplify the change proposed in draft-carpenter-6man-flow-update-02 even more after the recent discussions, while maintaining the proposed duality (RFC 3697-like use still possible, but locally-defined use also possible for those who want it). Independently, I expect to continue with draft-hu-flow-label-cases as background material and with draft-carpenter-flow-ecmp as a specific RFC 3697 use case, with my co-authors on those two drafts. The guidance we need from the 6MAN WG is: should we start to draft rfc3697bis, fixing the issues that have been raised and incorporating the (simplified) proposal from draft-carpenter-6man-flow-update? That would also need a new milestone added to the 6man charter. Regards Brian Carpenter From remi.despres@free.fr Thu Apr 22 01:08:53 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 CF4D33A6852 for ; Thu, 22 Apr 2010 01:08:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.088 X-Spam-Level: X-Spam-Status: No, score=-1.088 tagged_above=-999 required=5 tests=[AWL=0.861, 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 icEpZPKKZLFm for ; Thu, 22 Apr 2010 01:08:53 -0700 (PDT) Received: from smtp6-g21.free.fr (smtp6-g21.free.fr [212.27.42.6]) by core3.amsl.com (Postfix) with ESMTP id CB4DB3A68D5 for ; Thu, 22 Apr 2010 01:08:51 -0700 (PDT) Received: from smtp6-g21.free.fr (localhost [127.0.0.1]) by smtp6-g21.free.fr (Postfix) with ESMTP id 0D468E08076; Thu, 22 Apr 2010 10:08:37 +0200 (CEST) Received: from [192.168.0.13] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by smtp6-g21.free.fr (Postfix) with ESMTP id D18F9E08152; Thu, 22 Apr 2010 10:08:34 +0200 (CEST) Subject: Re: Stateless assignment of flow-labels in source hosts Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: <4BCF6B55.3010005@gmail.com> Date: Thu, 22 Apr 2010 10:08:34 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <7CF502E9-9D9C-4CF6-992A-6B726E409A41@free.fr> References: <5AD500D8-B59B-4DCE-A9E8-93B1CA5848E6@free.fr> <6029E6FA-DF50-409F-8EB6-2F67D1A886FF@free.fr> <4BCF6B55.3010005@gmail.com> To: Brian E Carpenter X-Mailer: Apple Mail (2.1078) 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, 22 Apr 2010 08:08:53 -0000 Le 21 avr. 2010 =E0 23:17, Brian E Carpenter a =E9crit : > On 2010-04-21 20:50, R=E9mi Despr=E9s wrote: >> Hi Brian, >>=20 >> I wonder what you think of what I answered to James on another = discussion thread. >=20 > I agree. I think that particular SHOULD in the RFC is an error. It = "SHOULD" > have said something like: >=20 > "The source node MUST select new Flow Label values by a method that > prevents unintended Flow Label value reuse." Yes, that's more appropriate. Suggesting in addition that a 5-tuple hash can be an easy way to set = flow-label values, because it is stateless, would IMHO improve chances = that host really set them. Wold you agree on this too? RD >=20 > Brian >=20 >> Regards, >> RD >>=20 >>=20 >> D=E9but du message r=E9exp=E9di=E9 : >>=20 >>> De : R=E9mi Despr=E9s >>> Date : 21 avril 2010 10:43:55 HAEC >>> =C0 : james woodyatt >>> Cc : 6man 6man >>> Objet : R=E9p : Draft-krishnan-ipv6-exthdr-08 to become asap a 6man = WG draft ? >>>=20 >>> ... >>>> In general, only some IPv6 packets have 5-tuples, and of those, = only a subset can have 5-tuples that packet analyzers can extract, i.e. = the rest are encapsulated in ESP or a moral equivalent (and ESP packets = have 4-tuples). >>>>=20 >>>> Hosts should set flow labels. =20 >>> Agreed. >>>=20 >>> This should be IMHO the conclusion of the current discussion on flow = labels, BUT provided hosts are explicitly permitted to set flow-label = values statelessly for each datagram, with a hash of their 5-tuples. >>> (RFC 3697 says "To avoid accidental Flow Label value reuse, the = source node SHOULD select new Flow Label values in a well-defined = sequence", which privileges flow-label assignments that are stateful per = connection, a choice significantly more complex than needed.) >>>=20 >>=20 >>=20 >=20 From remi.despres@free.fr Thu Apr 22 05:51:17 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 733A23A6816 for ; Thu, 22 Apr 2010 05:51:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.179 X-Spam-Level: X-Spam-Status: No, score=0.179 tagged_above=-999 required=5 tests=[AWL=-0.472, 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 POjeKZkdA6D4 for ; Thu, 22 Apr 2010 05:51:16 -0700 (PDT) Received: from smtp6-g21.free.fr (smtp6-g21.free.fr [212.27.42.6]) by core3.amsl.com (Postfix) with ESMTP id 19A1C3A6A79 for ; Thu, 22 Apr 2010 05:51:10 -0700 (PDT) Received: from smtp6-g21.free.fr (localhost [127.0.0.1]) by smtp6-g21.free.fr (Postfix) with ESMTP id DE92FE08091; Thu, 22 Apr 2010 14:50:57 +0200 (CEST) Received: from [192.168.0.13] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by smtp6-g21.free.fr (Postfix) with ESMTP id B5FCFE0804A; Thu, 22 Apr 2010 14:50:54 +0200 (CEST) Subject: Re: DRAFT: Request for guidance about the flow label Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: <4BCFBADA.8090901@gmail.com> Date: Thu, 22 Apr 2010 14:50:52 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <0FEC3C33-071C-48C4-9BD8-91CF63573377@free.fr> References: <4BCFBADA.8090901@gmail.com> To: Brian E Carpenter X-Mailer: Apple Mail (2.1078) Cc: 6man X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Apr 2010 12:51:17 -0000 Le 22 avr. 2010 =E0 04:56, Brian E Carpenter a =E9crit : > I think we need to simplify the change proposed in > draft-carpenter-6man-flow-update-02 even more after the recent > discussions, while maintaining the proposed duality > (RFC 3697-like > use still possible, but locally-defined use also possible for those = who > want it). In my understanding, restoring domain-entrance FL-values at domain exit = should be a "MUST" for any domain-specific use: - Efficiency of FL-based load balancing requires that FLs are in general = different for different 5-tuples. - For fragmented datagrams, only source hosts are in a position to base = FL values on 5-tuples (intra-domain nodes aren't). =20 Provided this obligation is complied with, any domain-specific use of = FLs is clearly permitted (it remains a purely local matter). =20 > Independently, I expect to continue with draft-hu-flow-label-cases > as background material and with draft-carpenter-flow-ecmp as a > specific RFC 3697 use case, with my co-authors on those two drafts. > The guidance we need from the 6MAN WG is: should we start to draft > rfc3697bis, fixing the issues that have been raised and incorporating > the (simplified) proposal from draft-carpenter-6man-flow-update? IMHO, yes. > That would also need a new milestone added to the 6man charter. Support for this. Regards, RD From sheila.frankel@nist.gov Thu Apr 22 06:53:38 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 8D50228C12D; Thu, 22 Apr 2010 06:53:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.999 X-Spam-Level: X-Spam-Status: No, score=-3.999 tagged_above=-999 required=5 tests=[BAYES_50=0.001, 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 BcECi3J11sWV; Thu, 22 Apr 2010 06:53:37 -0700 (PDT) Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by core3.amsl.com (Postfix) with ESMTP id 664D328C145; Thu, 22 Apr 2010 06:52:19 -0700 (PDT) Received: from WSXGHUB2.xchange.nist.gov (WSXGHUB2.xchange.nist.gov [129.6.18.19]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id o3MDnpjx011064; Thu, 22 Apr 2010 09:49:51 -0400 Received: from MBCLUSTER.xchange.nist.gov ([fe80::d479:3188:aec0:cb66]) by WSXGHUB2.xchange.nist.gov ([129.6.18.19]) with mapi; Wed, 21 Apr 2010 08:46:04 -0400 From: "Frankel, Sheila E." To: "ipsec@ietf.org" , "ipv6@ietf.org" Date: Wed, 21 Apr 2010 08:45:34 -0400 Subject: Announcing the USGv6 Testing Meeting at NIST Thread-Topic: Announcing the USGv6 Testing Meeting at NIST Thread-Index: Acrgnico98ik2GHIRGmPrMP7EVsXWAAsi+sg Message-ID: 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" MIME-Version: 1.0 X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: sheila.frankel@nist.gov 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, 22 Apr 2010 13:53:38 -0000 Announcing the USGv6 Testing Meeting at NIST. To be held on Thursday May 20th 2010 in the AML Conference Room, Building 215 Room C103, from 9am till 5pm. Following publication of the USG Profile NIST has established a testing program to determine products' compliance to USGv6 capabilities. There are at present 2 accreditors and 2 accredited test laboratories enrolled in the program, with more test laboratories in consideration. July 2010 marks the date when USG Federal Agencies begin to make IT acquisitions using the USGv6 profile version 1.0. We wanted to host a public meeting to give: - a review of how the testing program is operating. - an opportunity for feedback from Stakeholders, including test laboratories, product vendors and USG Agencies. Accordingly we seek discussion inputs to include: - statements from accredited and prospective test laboratories. - statements/questions and issues from Agencies and users. - statements, questions and issues from USGv6 product vendors. Issues are expected to include: - testing operations and interlaboratory comparisons. - USGv6 capabilities and requirements. - Suppliers Declaration of Conformity. There will also be some discussion of the forthcoming USGv6 profile version 2. A full Agenda will be posted to signed up attendees closer to the day of the meeting. Due to room size limitations there can be a maximum of about 70 participants at this meeting, and attendance from any one company may need to be limited. Reply to usgv6-project@antd.nist.gov if you wish to participate, giving full name, company affiliation, title, contact details and whether you are a U.S. citizen. Please also let us know if you have issues you wish to present, with a maximum of 2 or 3 slides, and speaking time limited depending on the response. For further information, please contact Stephen Nightingale (night@nist.gov) From latif@ladid.lu Thu Apr 22 07:04:07 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 5072228C0EC; Thu, 22 Apr 2010 07:04:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=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 gf3l7mh3kgSV; Thu, 22 Apr 2010 07:04:06 -0700 (PDT) Received: from mailout4.pt.lu (mailout4.pt.lu [195.46.255.246]) by core3.amsl.com (Postfix) with ESMTP id 778D73A6B4C; Thu, 22 Apr 2010 07:03:51 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EABP0z0vCmsBU/2dsb2JhbACRMYpycb5HhQ8E X-IronPort-AV: E=Sophos;i="4.52,256,1270418400"; d="scan'208";a="51379829" Received: from webhost1.pt.lu ([194.154.192.84]) by smtp.pt.lu with ESMTP/TLS/DHE-RSA-AES256-SHA; 22 Apr 2010 16:03:40 +0200 Received: from IPv6ForumPC (ip-88-207-169-205.dyn.luxdsl.pt.lu [88.207.169.205] (may be forged)) (authenticated bits=0) by webhost1.pt.lu with ESMTP id o3ME3ZE8011753; Thu, 22 Apr 2010 16:03:38 +0200 From: "Latif LADID \(\"The New Internet based on IPv6\"\)" To: "'Frankel, Sheila E.'" , , References: In-Reply-To: Subject: RE: Announcing the USGv6 Testing Meeting at NIST Date: Thu, 22 Apr 2010 16:03:32 +0200 Message-ID: <020601cae224$9ab391c0$d01ab540$@lu> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acrgnico98ik2GHIRGmPrMP7EVsXWAAsi+sgADTzSyA= Content-Language: en-gb X-Seen-By: scanner3.pt.lu Cc: ipv6ready-tech@ipv6ready.org, nav6tf@ipv6forum.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: Thu, 22 Apr 2010 14:04:07 -0000 Thanks Sheila! Good to see you working on IPv6 so vigorously recalling our days of work on IPsec back in 99. I have Copied the North American v6 Task Force members and the IPv6 Ready logo program team. Cheers Latif -----Original Message----- From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of Frankel, Sheila E. Sent: 21 April 2010 14:46 To: ipsec@ietf.org; ipv6@ietf.org Subject: Announcing the USGv6 Testing Meeting at NIST Announcing the USGv6 Testing Meeting at NIST. To be held on Thursday May 20th 2010 in the AML Conference Room, Building 215 Room C103, from 9am till 5pm. Following publication of the USG Profile NIST has established a testing program to determine products' compliance to USGv6 capabilities. There are at present 2 accreditors and 2 accredited test laboratories enrolled in the program, with more test laboratories in consideration. July 2010 marks the date when USG Federal Agencies begin to make IT acquisitions using the USGv6 profile version 1.0. We wanted to host a public meeting to give: - a review of how the testing program is operating. - an opportunity for feedback from Stakeholders, including test laboratories, product vendors and USG Agencies. Accordingly we seek discussion inputs to include: - statements from accredited and prospective test laboratories. - statements/questions and issues from Agencies and users. - statements, questions and issues from USGv6 product vendors. Issues are expected to include: - testing operations and interlaboratory comparisons. - USGv6 capabilities and requirements. - Suppliers Declaration of Conformity. There will also be some discussion of the forthcoming USGv6 profile version 2. A full Agenda will be posted to signed up attendees closer to the day of the meeting. Due to room size limitations there can be a maximum of about 70 participants at this meeting, and attendance from any one company may need to be limited. Reply to usgv6-project@antd.nist.gov if you wish to participate, giving full name, company affiliation, title, contact details and whether you are a U.S. citizen. Please also let us know if you have issues you wish to present, with a maximum of 2 or 3 slides, and speaking time limited depending on the response. For further information, please contact Stephen Nightingale (night@nist.gov) -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From jeanmichel.combes@gmail.com Thu Apr 22 08:25:47 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 F31A728C1C8 for ; Thu, 22 Apr 2010 08:25:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.759 X-Spam-Level: X-Spam-Status: No, score=-0.759 tagged_above=-999 required=5 tests=[AWL=-0.574, 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 nzJZ4PAlhc9q for ; Thu, 22 Apr 2010 08:25:46 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by core3.amsl.com (Postfix) with ESMTP id 91E2728C1C5 for ; Thu, 22 Apr 2010 08:22:40 -0700 (PDT) Received: by wyb35 with SMTP id 35so685997wyb.31 for ; Thu, 22 Apr 2010 08:22:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:received:message-id :subject:from:to:content-type; bh=3refbSWMJSN4HUS/yqKFcIKVAt5EVF9swRFGmNJp9n8=; b=jLIBlujBO82Gq+be3ocskgSGPNlwJI5gAHfv88GQGE1A7tCVPJ7LZznCNeUrGG8Bme vj3A60btuEgdAiCXCVesgPGA/gEha49CYmC1wzzrRFRftfW0OYYwBOhPWdxxxnA2TVWz ua7rzxkjUkhxRiqFLR5iTFT89BT26oJref1vk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=Urbmg3ExRmfr3sf/sOmE7fyrGmZ9WIdDC3C/sQ25cRYdoQpvyV1u64Y976fgizz6MB Hb5uH4qbPyR+9zcAXeqYtsk5oWZsqxCDENg1Z2PYyROArGTwC1PQkbiPvjPqBWFkXaT2 FEu5qWQEvXP5pFunPb1ap279R5Hp5HAdcjZqk= MIME-Version: 1.0 Received: by 10.216.186.4 with HTTP; Thu, 22 Apr 2010 08:22:26 -0700 (PDT) Date: Thu, 22 Apr 2010 17:22:26 +0200 Received: by 10.216.87.18 with SMTP id x18mr2025635wee.85.1271949746377; Thu, 22 Apr 2010 08:22:26 -0700 (PDT) Message-ID: Subject: RFC 4862 - Clarification question on DAD procedure From: Jean-Michel Combes To: ipv6@ietf.org Content-Type: text/plain; charset=ISO-8859-1 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Apr 2010 15:25:47 -0000 Hi, I don't understand a specific point in DAD procedure specified in RFC 4862. In section 5.4.3, it is said: 5.4.3. Receiving Neighbor Solicitation Messages [snip] If the source address of the Neighbor Solicitation is the unspecified address, the solicitation is from a node performing Duplicate Address Detection. If the solicitation is from another node, the tentative address is a duplicate and should not be used (by either node). ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ But I must admit I don't see how the another node would be aware of the tentative address is a duplicate. Indeed, as the first node has to stop DAD after the another node's NS message reception, this first node should not send new NS messages with the same tentative address and so the another node should validate this address ... Did I miss something? Thanks in advance for your help. Best regards. JMC. From shane@castlepoint.net Thu Apr 22 08:31:47 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 9B5253A697F for ; Thu, 22 Apr 2010 08:31:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bohx5auvUPa4 for ; Thu, 22 Apr 2010 08:31:46 -0700 (PDT) Received: from dog.tcb.net (dog.tcb.net [64.78.150.133]) by core3.amsl.com (Postfix) with ESMTP id A295A3A6B99 for ; Thu, 22 Apr 2010 08:31:17 -0700 (PDT) Received: by dog.tcb.net (Postfix, from userid 0) id C2C0D2684EA; Thu, 22 Apr 2010 09:31:07 -0600 (MDT) 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; Thu, 22 Apr 2010 09:31:07 -0600 (MDT) (envelope-from shane@castlepoint.net) X-Avenger: version=0.7.8; receiver=dog.tcb.net; client-ip=64.78.235.218; client-port=52902; data-bytes=0 Subject: Re: DRAFT: Request for guidance about the flow label Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=iso-8859-1 From: Shane Amante In-Reply-To: <0FEC3C33-071C-48C4-9BD8-91CF63573377@free.fr> Date: Thu, 22 Apr 2010 09:31:06 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <2FC3BE87-AFDD-441F-8262-55049B6AFED1@castlepoint.net> References: <4BCFBADA.8090901@gmail.com> <0FEC3C33-071C-48C4-9BD8-91CF63573377@free.fr> To: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= X-Mailer: Apple Mail (2.1078) 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: Thu, 22 Apr 2010 15:31:47 -0000 Brian, Remi, On Apr 22, 2010, at 06:50 MDT, R=E9mi Despr=E9s wrote: > Le 22 avr. 2010 =E0 04:56, Brian E Carpenter a =E9crit : >=20 >> I think we need to simplify the change proposed in >> draft-carpenter-6man-flow-update-02 even more after the recent >> discussions, while maintaining the proposed duality >> (RFC 3697-like >> use still possible, but locally-defined use also possible for those = who >> want it). >=20 > In my understanding, restoring domain-entrance FL-values at domain = exit should be a "MUST" for any domain-specific use: I'm concerned with Remi's above proposal about restoring FL-values at = domain exit. IMHO, instead of restoring FL-values at domain exit, it is /much/ more = simple to declare that Flow-Label values are _mutable_ when a packet = crosses over from one administratively defined domain to the next. I = doubt any existing, already deployed high-speed network equipment = (routers) would support any scheme to "restore" domain-specific = FL-values from entrance to exit of a domain -- although, I haven't = conducted a thorough investigation with them; rather, I'm basing this on = knowledge of the forwarding architecture of various, **already = deployed** (and, will keep getting deployed) platforms whose ASIC's are = extremely limited, to say the least. Of course, declaring the FL as "mutable" would still allow two (or = more), "consenting" administrative domains to decide that they want to = preserve a special "administrative-domain" flow-label treatment between = them and that is fine. In fact, this would be similar to how the IP = DSCP/TC field is dealt with today, particularly in the context of VPN's = that span two, or more, administrative domains. > - Efficiency of FL-based load balancing requires that FLs are in = general different for different 5-tuples. Agreed. > - For fragmented datagrams, only source hosts are in a position to = base FL values on 5-tuples (intra-domain nodes aren't). =20 I would instead rephrase this as "sources are in the _best_ position" = and we should certainly encourage them to encode a FL value on all = packets, (incl. fragmented packets). However, intermediate = nodes/routers can detect a fragmented datagram (by looking for a = fragment Ext. header) and once they do so, revert to just using the = 2-tuple of IPv6 src + dst address, which is not great, but better than = nothing. Related to the above, I was thinking that a 3967bis may want to = recommend the following: - For "plain" IPv6 packets, (i.e.: non-tunneled, non-encrypted packets), = just encode, say, the 3-tuple of {protocol, src port, dst port}, since = the source and destination addresses are already available to = intermediate nodes. - OTOH, if it is a tunneled and/or encrypted packet (i.e.: IP/IPv6 or = IPSec/IPv6), then the host should encode the entire 5-tuple of the inner = IP packet's header in the flow-label, in order that we have the most = granularity in the flow-label to distribute those packets as widely as = possible over LAG and ECMP paths. > Provided this obligation is complied with, any domain-specific use of = FLs is clearly permitted (it remains a purely local matter). >=20 >=20 >> Independently, I expect to continue with draft-hu-flow-label-cases >> as background material and with draft-carpenter-flow-ecmp as a >> specific RFC 3697 use case, with my co-authors on those two drafts. >=20 >> The guidance we need from the 6MAN WG is: should we start to draft >> rfc3697bis, fixing the issues that have been raised and incorporating >> the (simplified) proposal from draft-carpenter-6man-flow-update? >=20 > IMHO, yes. Yes, I support that. >> That would also need a new milestone added to the 6man charter. >=20 > Support for this. Yes, I support that. -shane > Regards, > RD >=20 >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From latif@ladid.lu Thu Apr 22 09:42:07 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 8CDC628C0EE; Thu, 22 Apr 2010 09:42:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.046 X-Spam-Level: X-Spam-Status: No, score=0.046 tagged_above=-999 required=5 tests=[AWL=-0.045, BAYES_05=-1.11, HTML_MESSAGE=0.001, J_CHICKENPOX_12=0.6, J_CHICKENPOX_32=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 MLCX4h2HPEqP; Thu, 22 Apr 2010 09:42:01 -0700 (PDT) Received: from mailout4.pt.lu (mailout4.pt.lu [195.46.255.246]) by core3.amsl.com (Postfix) with ESMTP id 90D383A6900; Thu, 22 Apr 2010 09:41:59 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjcFAHwZ0EvCmsBU/2dsb2JhbACBP492inJxiCK4NQKCc4IaBIZP X-IronPort-AV: E=Sophos;i="4.52,257,1270418400"; d="scan'208,217";a="51445838" Received: from webhost1.pt.lu ([194.154.192.84]) by smtp.pt.lu with ESMTP/TLS/DHE-RSA-AES256-SHA; 22 Apr 2010 18:41:47 +0200 Received: from IPv6ForumPC (ip-88-207-169-205.dyn.luxdsl.pt.lu [88.207.169.205] (may be forged)) (authenticated bits=0) by webhost1.pt.lu with ESMTP id o3MGfgFc007686; Thu, 22 Apr 2010 18:41:45 +0200 From: "Latif LADID \(\"The New Internet based on IPv6\"\)" To: "'Davis, Terry L'" , "'Frankel, Sheila E.'" , , References: <020601cae224$9ab391c0$d01ab540$@lu> <0267B5481DCC474D8088BF4A25C7F1DF5516235A2A@XCH-NW-05V.nw.nos.boeing.com> In-Reply-To: <0267B5481DCC474D8088BF4A25C7F1DF5516235A2A@XCH-NW-05V.nw.nos.boeing.com> Subject: RE: [Nav6tf] Announcing the USGv6 Testing Meeting at NIST Date: Thu, 22 Apr 2010 18:41:39 +0200 Message-ID: <027301cae23a$b1592370$140b6a50$@lu> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0274_01CAE24B.74E1F370" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acrgnico98ik2GHIRGmPrMP7EVsXWAAsi+sgADTzSyAAArx+YAACgoxg Content-Language: en-gb X-Seen-By: scanner3.pt.lu Cc: "'Whitlock, Stephen'" , ipv6ready-tech@ipv6ready.org, nav6tf@ipv6forum.com, members@ipv6forum.com, tim.polk@nist.gov 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, 22 Apr 2010 16:42:07 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0274_01CAE24B.74E1F370 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Terry, You touch a core issue of the he IPv6 Ready Logo program. The v6RL Phase II (Logo) includes IPsec interop testing. Though we have stayed away at this staged from mandating IPsec per RFC to give industry the time to put its arms around IPv6 issues first, there a dozen of products that tested IPsec succesfully: http://cf.v6pc.jp/logo_db/approved_list_ph2.php We have not yet defined Phase III which could include IPsec mandated. Now, we need to carefully define the test profiles. This needs a serious discussion before moving forward. Cheers Latif From: nav6tf-bounces@ipv6forum.com [mailto:nav6tf-bounces@ipv6forum.com] On Behalf Of Davis, Terry L Sent: 22 April 2010 18:06 To: 'Latif LADID ("The New Internet based on IPv6")'; 'Frankel, Sheila E.'; ipsec@ietf.org; ipv6@ietf.org Cc: Whitlock, Stephen; ipv6ready-tech@ipv6ready.org; nav6tf@ipv6forum.com; 'tim.polk@nist.gov' Subject: Re: [Nav6tf] Announcing the USGv6 Testing Meeting at NIST Sheila Like Latif said, THANK YOU! As you know from the Seattle meeting with aviation industry representatives and the vendor community last fall, the Internet security protocols' interoperability is a key lynchpin in being able to ensure that the next generation of Internet enabled aircraft can establish secure communications in the global aviation environment. Aviation continues to be concerned that current IPv4 versions of IPsec, IKE, and IKEv2 still have vendor-to-vendor compatibility issues that would be difficult for us to overcome in a fully heterogeneous global environment. In our environment, an aircraft is continually making and breaking security associations between different service providers and air traffic management entities as it transverses from country to country and continent to continent. Thus our environment requires a very high degree of confidence in the ability of our systems to dynamically re-establish secure links with these new entities. We would encourage that interoperability testing fully include versions of IPSec, IKE, and IKEv2 to ensure these issues do not continue with IPv6 on which the next generations of global air traffic management will reply on (ICAO Document 9896). The testing ideally should demonstrate a vendor's system's ability to establish links with other vendors systems with minimal time and effort for setup and link customization as the ease-of-use and ease-of-deployment will be critical for a global aviation infrastructure. Unfortunately I will be unable to attend as I will in ICAO meetings that week, part of which will focus on these same issues. Take care Terry L Davis, P.E Boeing Technical Fellow Aircraft Network and Security, Architecture & Strategy Engineering Core - Avionics Boeing Commercial Airplanes Phone: 206-280-3716 Email: Terry.L.Davis@Boeing.com PS: It would also seem likely that the other CI sectors would have similar IPv6 security interoperability needs. > -----Original Message----- > From: nav6tf-bounces@ipv6forum.com > [mailto:nav6tf-bounces@ipv6forum.com] On Behalf Of Latif > LADID ("The New Internet based on IPv6") > Sent: Thursday, April 22, 2010 7:04 AM > To: 'Frankel, Sheila E.'; IPSec@ietf.org; ipv6@ietf.org > Cc: ipv6ready-tech@ipv6ready.org; nav6tf@ipv6forum.com > Subject: Re: [Nav6tf] Announcing the USGv6 Testing Meeting at NIST > > Thanks Sheila! Good to see you working on IPv6 so vigorously > recalling our > days of work on IPsec back in 99. > > I have Copied the North American v6 Task Force members and > the IPv6 Ready > logo program team. > > Cheers > Latif > > -----Original Message----- > From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On > Behalf Of > Frankel, Sheila E. > Sent: 21 April 2010 14:46 > To: ipsec@ietf.org; ipv6@ietf.org > Subject: Announcing the USGv6 Testing Meeting at NIST > > Announcing the USGv6 Testing Meeting at NIST. > > To be held on Thursday May 20th 2010 in the AML Conference Room, > Building 215 Room C103, from 9am till 5pm. > > Following publication of the USG Profile NIST has established > a testing > program to determine products' compliance to USGv6 > capabilities. There > are at present 2 accreditors and 2 accredited test > laboratories enrolled > in the program, with more test laboratories in consideration. > July 2010 > marks the date when USG Federal Agencies begin to make IT > acquisitions > using the USGv6 profile version 1.0. We wanted to host a > public meeting > to give: > - a review of how the testing program is operating. > - an opportunity for feedback from Stakeholders, including test > laboratories, product vendors and USG Agencies. > > Accordingly we seek discussion inputs to include: > - statements from accredited and prospective test laboratories. > - statements/questions and issues from Agencies and users. > - statements, questions and issues from USGv6 product vendors. > > Issues are expected to include: > - testing operations and interlaboratory comparisons. > - USGv6 capabilities and requirements. > - Suppliers Declaration of Conformity. > > There will also be some discussion of the forthcoming USGv6 profile > version 2. A full Agenda will be posted to signed up > attendees closer > to the day of the meeting. Due to room size limitations > there can be a > maximum of about 70 participants at this meeting, and attendance from > any one company may need to be limited. Reply to > usgv6-project@antd.nist.gov if you wish to participate, giving full > name, company affiliation, title, contact details and whether > you are a > U.S. citizen. Please also let us know if you have issues you wish to > present, with a maximum of 2 or 3 slides, and speaking time limited > depending on the response. > > For further information, please contact Stephen Nightingale > (night@nist.gov) > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > > _______________________________________________ > Nav6tf mailing list > Nav6tf@ipv6forum.com > http://lists.ipv6forum.com/mailman/listinfo/nav6tf > ------=_NextPart_000_0274_01CAE24B.74E1F370 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Terry,

 

You touch a core issue of the he IPv6 Ready Logo = program.

 

The v6RL Phase II (Logo) includes IPsec interop = testing.

 

Though we have stayed away at this staged from mandating = IPsec per RFC to give industry the time to put its arms around IPv6 issues = first,

there a dozen of products that tested IPsec succesfully: =

 

http://cf.v6pc.j= p/logo_db/approved_list_ph2.php

 

We have not yet defined Phase III which could include = IPsec mandated. Now, we need to carefully define the test = profiles.

 

This needs a serious discussion before moving = forward.

 

Cheers

Latif

 

 

From: nav6tf-bounces@ipv6forum.com [mailto:nav6tf-bounces@ipv6forum.com] On Behalf Of Davis, Terry = L
Sent: 22 April 2010 18:06
To: 'Latif LADID ("The New Internet based on IPv6")'; 'Frankel, Sheila E.'; ipsec@ietf.org; ipv6@ietf.org
Cc: Whitlock, Stephen; ipv6ready-tech@ipv6ready.org; nav6tf@ipv6forum.com; 'tim.polk@nist.gov'
Subject: Re: [Nav6tf] Announcing the USGv6 Testing Meeting at = NIST

 

Sheila

Like Latif said, THANK YOU!

As you know from the Seattle meeting with aviation industry = representatives and the vendor community last fall, the Internet security protocols' interoperability is a key lynchpin in being able to ensure that the next generation of Internet enabled aircraft can establish secure = communications in the global aviation environment.  Aviation continues to be = concerned that current IPv4 versions of IPsec, IKE, and IKEv2 still have  vendor-to-vendor compatibility issues that would be difficult for us to overcome in a fully heterogeneous global environment.  In our environment, an aircraft is continually making and breaking = security associations between different service providers and air traffic management entities = as it transverses from country to country and continent to continent.  Thus our environment requires a very high degree of confidence in = the ability of our systems to dynamically re-establish secure links = with these new entities.

We would encourage that interoperability testing fully include versions = of IPSec, IKE, and IKEv2 to ensure these issues do not continue with IPv6 = on which the next generations of global air traffic management will reply on = (ICAO Document 9896).  The testing ideally should demonstrate a vendor's system's ability to establish links with other vendors systems with = minimal time and effort for setup and link customization as the ease-of-use and ease-of-deployment will be critical for a global aviation = infrastructure.

Unfortunately I will be unable to attend as I will in ICAO = meetings that week, part of which will focus on these same issues.

Take care

Terry L Davis, P.E
Boeing Technical Fellow

Aircraft Network and Security, Architecture & Strategy
Engineering Core – Avionics =
Boeing Commercial Airplanes

Phone:  206-280-3716
Email:   Terry.L.Davis@Boeing.com

PS:  It would also seem likely that the other CI sectors would = have similar IPv6 security interoperability needs.




> -----Original Message-----
> From: nav6tf-bounces@ipv6forum.com
> [mailto:nav6tf-bounces@ipv6fo= rum.com] On Behalf Of Latif
> LADID ("The New Internet based on IPv6")
> Sent: Thursday, April 22, 2010 7:04 AM
> To: 'Frankel, Sheila E.'; IPSec@ietf.org; ipv6@ietf.org
> Cc: ipv6ready-tech@ipv6ready.org; nav6tf@ipv6forum.com
> Subject: Re: [Nav6tf] Announcing the USGv6 Testing Meeting at = NIST
>
> Thanks Sheila! Good to see you working on IPv6 so vigorously
> recalling our
> days of work on IPsec back in 99.
>
> I have Copied the North American v6 Task Force members and
> the IPv6 Ready
> logo program team.
>
> Cheers
> Latif
>
> -----Original Message-----
> From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On
> Behalf Of
> Frankel, Sheila E.
> Sent: 21 April 2010 14:46
> To: ipsec@ietf.org; ipv6@ietf.org
> Subject: Announcing the USGv6 Testing Meeting at NIST
>
> Announcing the USGv6 Testing Meeting at NIST.
>
> To be held on Thursday May 20th 2010 in the AML Conference = Room,
> Building 215 Room C103, from 9am till 5pm.
>
> Following publication of the USG Profile NIST has established
> a testing
> program to determine products' compliance to USGv6
> capabilities. There
> are at present 2 accreditors and 2 accredited test
> laboratories enrolled
> in the program, with more test laboratories in consideration.
>  July 2010
> marks the date when USG Federal Agencies begin to make IT
> acquisitions
> using the USGv6 profile version 1.0.  We wanted to host a
> public meeting
> to give:
>     - a review of how the testing program is operating.
>     - an opportunity for feedback from = Stakeholders, including test
> laboratories, product vendors and USG Agencies.
>
> Accordingly we seek discussion inputs to include:
>     - statements from accredited and = prospective test laboratories.
>     - statements/questions and issues from = Agencies and users.
>     - statements, questions and issues from = USGv6 product vendors.
>
> Issues are expected to include:
>     - testing operations and interlaboratory comparisons.
>     - USGv6 capabilities and requirements.
>     - Suppliers Declaration of Conformity.
>
> There will also be some discussion of the forthcoming USGv6 = profile
> version 2.  A full Agenda will be posted to signed up
> attendees closer
> to the day of the meeting.  Due to room size limitations
> there can be a
> maximum of about 70 participants at this meeting, and attendance = from
> any one company may need to be limited. Reply to
> usgv6-project@antd.nist.gov if you wish to participate, giving = full
> name, company affiliation, title, contact details and whether
> you are a
> U.S. citizen. Please also let us know if you have issues you wish = to
> present, with a maximum of 2 or 3 slides, and speaking time = limited
> depending on the response.
>
> For further information, please contact Stephen Nightingale
> (night@nist.gov)
>
>
> = --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/= mailman/listinfo/ipv6
> = --------------------------------------------------------------------
>
> _______________________________________________
> Nav6tf mailing list
> Nav6tf@ipv6forum.com
> http://lists.= ipv6forum.com/mailman/listinfo/nav6tf
>

------=_NextPart_000_0274_01CAE24B.74E1F370-- From remi.despres@free.fr Thu Apr 22 09:50:25 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 870B428C14B for ; Thu, 22 Apr 2010 09:50:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.104 X-Spam-Level: X-Spam-Status: No, score=-1.104 tagged_above=-999 required=5 tests=[AWL=0.845, 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 ryrELwaGIfJT for ; Thu, 22 Apr 2010 09:50:24 -0700 (PDT) Received: from smtp6-g21.free.fr (smtp6-g21.free.fr [212.27.42.6]) by core3.amsl.com (Postfix) with ESMTP id E574428C143 for ; Thu, 22 Apr 2010 09:50:19 -0700 (PDT) Received: from smtp6-g21.free.fr (localhost [127.0.0.1]) by smtp6-g21.free.fr (Postfix) with ESMTP id C02F6E080D2; Thu, 22 Apr 2010 18:50:05 +0200 (CEST) Received: from [192.168.0.13] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by smtp6-g21.free.fr (Postfix) with ESMTP id 5A198E08188; Thu, 22 Apr 2010 18:50:02 +0200 (CEST) Subject: Re: DRAFT: Request for guidance about the flow label Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: <2FC3BE87-AFDD-441F-8262-55049B6AFED1@castlepoint.net> Date: Thu, 22 Apr 2010 18:50:00 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <1D69CC44-FA38-4D7D-A456-83D315B1F06B@free.fr> References: <4BCFBADA.8090901@gmail.com> <0FEC3C33-071C-48C4-9BD8-91CF63573377@free.fr> <2FC3BE87-AFDD-441F-8262-55049B6AFED1@castlepoint.net> To: Shane Amante X-Mailer: Apple Mail (2.1078) 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: Thu, 22 Apr 2010 16:50:25 -0000 Le 22 avr. 2010 =E0 17:31, Shane Amante a =E9crit : > Brian, Remi, >=20 > On Apr 22, 2010, at 06:50 MDT, R=E9mi Despr=E9s wrote: >> Le 22 avr. 2010 =E0 04:56, Brian E Carpenter a =E9crit : >>=20 >>> I think we need to simplify the change proposed in >>> draft-carpenter-6man-flow-update-02 even more after the recent >>> discussions, while maintaining the proposed duality >>> (RFC 3697-like >>> use still possible, but locally-defined use also possible for those = who >>> want it). >>=20 >> In my understanding, restoring domain-entrance FL-values at domain = exit should be a "MUST" for any domain-specific use: >=20 > I'm concerned with Remi's above proposal about restoring FL-values at = domain exit. >=20 > IMHO, instead of restoring FL-values at domain exit, it is /much/ more = simple to declare that Flow-Label values are _mutable_ when a packet = crosses over from one administratively defined domain to the next. I = doubt any existing, already deployed high-speed network equipment = (routers) would support any scheme to "restore" domain-specific = FL-values from entrance to exit of a domain -- although, I haven't = conducted a thorough investigation with them; rather, I'm basing this on = knowledge of the forwarding architecture of various, **already = deployed** (and, will keep getting deployed) platforms whose ASIC's are = extremely limited, to say the least. Would these deployment use domain-specific computations of flow labels? If yes, have you more information on what they do? (Any computation of FLs based on 5-tuples in intermediate routers would = be well beyond what an asic can do.) The main reason I see to restore FLs is that, if a domain replaces a = "good" FL coming from upstream (host generated and 5-tuple based ), by = another that isn't 5-tuple based, routers that are further downstream = won't be able to use the "good" FL for their load sharing. Regards, RD From wwwrun@core3.amsl.com Thu Apr 22 10:29:41 2010 Return-Path: X-Original-To: ipv6@ietf.org Delivered-To: ipv6@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id B70513A6B63; Thu, 22 Apr 2010 10:29:40 -0700 (PDT) X-idtracker: yes From: The IESG To: IETF-Announce Subject: Protocol Action: 'A Recommendation for IPv6 Address Text Representation' to Proposed Standard Message-Id: <20100422172940.B70513A6B63@core3.amsl.com> Date: Thu, 22 Apr 2010 10:29:40 -0700 (PDT) Cc: 6man chair <6man-chairs@tools.ietf.org>, Internet Architecture Board , 6man mailing list , RFC Editor X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Apr 2010 17:29:41 -0000 The IESG has approved the following document: - 'A Recommendation for IPv6 Address Text Representation ' as a Proposed Standard This document is the product of the IPv6 Maintenance Working Group. The IESG contact persons are Jari Arkko and Ralph Droms. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-6man-text-addr-representation-07.txt Technical Summary This document defines a canonical text representation format of IPv6 addresses for use by operators, system engineers, and users. The recommendation complies fully with [RFC4291], is implemented by various operating systems, and is human friendly. The recommendation in this document SHOULD be followed by systems when generating an address to represent as text, but all implementations MUST accept any legitimate [RFC4291] format. It is advised that humans also follow these recommendations when spelling an address. Working Group Summary The 6MAN working group reviewed and discussed this document several times. There is a strong consensus to move this forward. Document Quality This document has been reviewed by key members of the 6MAN working group and the chairs. Personnel The Document Shepherd is Bob Hinden, and the responsible Area Director is Jari Arkko. From latif@ladid.lu Thu Apr 22 10:32:49 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 3FC2E28C1E7; Thu, 22 Apr 2010 10:32:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.531 X-Spam-Level: X-Spam-Status: No, score=0.531 tagged_above=-999 required=5 tests=[AWL=-0.485, BAYES_40=-0.185, HTML_MESSAGE=0.001, J_CHICKENPOX_12=0.6, J_CHICKENPOX_32=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 FTZkjSOAXKuj; Thu, 22 Apr 2010 10:32:27 -0700 (PDT) Received: from mailout3.pt.lu (mailout3.pt.lu [195.46.255.245]) by core3.amsl.com (Postfix) with ESMTP id 32B0A3A6886; Thu, 22 Apr 2010 10:27:45 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjgFAEsj0EvCmsBU/2dsb2JhbACBP4FXjiCKcnGIIqZmkV4CgnOBLW0Ehk8 X-IronPort-AV: E=Sophos;i="4.52,258,1270418400"; d="scan'208,217";a="56253223" Received: from webhost1.pt.lu ([194.154.192.84]) by smtp.pt.lu with ESMTP/TLS/DHE-RSA-AES256-SHA; 22 Apr 2010 19:24:37 +0200 Received: from IPv6ForumPC (ip-88-207-169-205.dyn.luxdsl.pt.lu [88.207.169.205] (may be forged)) (authenticated bits=0) by webhost1.pt.lu with ESMTP id o3MHOUWS024021; Thu, 22 Apr 2010 19:24:34 +0200 From: "Latif LADID \(\"The New Internet based on IPv6\"\)" To: "'Tseronis, Peter'" , , , , References: In-Reply-To: Subject: RE: [Members] [Nav6tf] Announcing the USGv6 Testing Meeting at NIST Date: Thu, 22 Apr 2010 19:24:27 +0200 Message-ID: <02b701cae240$ac1397f0$043ac7d0$@lu> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_02B8_01CAE251.6F9C67F0" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acrgnico98ik2GHIRGmPrMP7EVsXWAAsi+sgADTzSyAAArx+YAACgoxgAACPvgUAAK2R8A== Content-Language: en-gb X-Seen-By: scanner3.pt.lu Cc: stephen.whitlock@boeing.com, ipv6ready-tech@ipv6ready.org, nav6tf@ipv6forum.com, members@ipv6forum.com, tim.polk@nist.gov 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, 22 Apr 2010 17:32:49 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_02B8_01CAE251.6F9C67F0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Pete, =20 This meeting is very crucial especially for vendors and to a certain = extent to ISPs, so John could publish this event (most probably already = done so) to his ARIN constituency as it=E2=80=99s Sheila=E2=80=99s = desire to get a good representation from all stakeholders. =20 It would be good to time Yanick for this meeting as she oversees all v6 = Ready & Enabled programs together with Hiroshis, Erica, Timothy, etc, = all power designers of these very technical and complex Interop = programs. =20 We have Germany coming pretty strong as well with a great event (IPv6 = Congress) May 20: http://www.heise.de/events/2010/ipv6-kongress/ =20 In terms of v6 prefix ranking the US has shot thru the roof with 450 v6 = Prefixes visible among 1230 allocated, making the US by far the largest = v6 world. I guess ARIN=E2=80=99s aggressive campaign is collecting its = fruits. Congrats. =20 Cheers Latif=20 =20 =20 From: Tseronis, Peter [mailto:Peter.Tseronis@hq.doe.gov]=20 Sent: 22 April 2010 18:47 To: 'latif@ladid.lu'; 'terry.l.davis@boeing.com'; = 'sheila.frankel@nist.gov'; 'ipsec@ietf.org'; 'ipv6@ietf.org' Cc: 'stephen.whitlock@boeing.com'; 'ipv6ready-tech@ipv6ready.org'; = 'nav6tf@ipv6forum.com'; 'members@ipv6forum.com'; 'tim.polk@nist.gov' Subject: Re: [Members] [Nav6tf] Announcing the USGv6 Testing Meeting at = NIST =20 Latif, Will you be in town for this? I will be there for sure. Yanick and I are getting together ahead of the meeting. Also, Junaid Islam, John Curran, and I are meeting on Monday. Pete=20 Peter J. Tseronis=20 Senior Advisor=20 U.S. Department of Energy=20 301-903-8262 (office)=20 202-841-5335 (mobile) =20 _____ =20 From: members-bounces@ipv6forum.com =20 To: 'Davis, Terry L' ; 'Frankel, Sheila E.' = ; ipsec@ietf.org ; = ipv6@ietf.org =20 Cc: 'Whitlock, Stephen' ; = ipv6ready-tech@ipv6ready.org ; = nav6tf@ipv6forum.com ; members@ipv6forum.com = ; tim.polk@nist.gov =20 Sent: Thu Apr 22 12:41:39 2010 Subject: Re: [Members] [Nav6tf] Announcing the USGv6 Testing Meeting at = NIST=20 Terry, =20 You touch a core issue of the he IPv6 Ready Logo program. =20 The v6RL Phase II (Logo) includes IPsec interop testing. =20 Though we have stayed away at this staged from mandating IPsec per RFC = to give industry the time to put its arms around IPv6 issues first, there a dozen of products that tested IPsec succesfully:=20 =20 http://cf.v6pc.jp/logo_db/approved_list_ph2.php =20 We have not yet defined Phase III which could include IPsec mandated. = Now, we need to carefully define the test profiles. =20 This needs a serious discussion before moving forward. =20 Cheers Latif=20 =20 =20 From: nav6tf-bounces@ipv6forum.com [mailto:nav6tf-bounces@ipv6forum.com] = On Behalf Of Davis, Terry L Sent: 22 April 2010 18:06 To: 'Latif LADID ("The New Internet based on IPv6")'; 'Frankel, Sheila = E.'; ipsec@ietf.org; ipv6@ietf.org Cc: Whitlock, Stephen; ipv6ready-tech@ipv6ready.org; = nav6tf@ipv6forum.com; 'tim.polk@nist.gov' Subject: Re: [Nav6tf] Announcing the USGv6 Testing Meeting at NIST =20 Sheila Like Latif said, THANK YOU! As you know from the Seattle meeting with aviation industry = representatives and the vendor community last fall, the Internet = security protocols' interoperability is a key lynchpin in being able to = ensure that the next generation of Internet enabled aircraft can = establish secure communications in the global aviation environment. = Aviation continues to be concerned that current IPv4 versions of IPsec, = IKE, and IKEv2 still have vendor-to-vendor compatibility issues that = would be difficult for us to overcome in a fully heterogeneous global = environment. In our environment, an aircraft is continually making and = breaking security associations between different service providers and = air traffic management entities as it transverses from country to = country and continent to continent. Thus our environment requires a = very high degree of confidence in the ability of our systems to = dynamically re-establish secure links with these new entities. We would encourage that interoperability testing fully include versions = of IPSec, IKE, and IKEv2 to ensure these issues do not continue with = IPv6 on which the next generations of global air traffic management will = reply on (ICAO Document 9896). The testing ideally should demonstrate a = vendor's system's ability to establish links with other vendors systems = with minimal time and effort for setup and link customization as the = ease-of-use and ease-of-deployment will be critical for a global = aviation infrastructure. Unfortunately I will be unable to attend as I will in ICAO meetings that = week, part of which will focus on these same issues. Take care Terry L Davis, P.E=20 Boeing Technical Fellow=20 Aircraft Network and Security, Architecture & Strategy=20 Engineering Core =E2=80=93 Avionics=20 Boeing Commercial Airplanes=20 Phone: 206-280-3716=20 Email: Terry.L.Davis@Boeing.com=20 PS: It would also seem likely that the other CI sectors would have = similar IPv6 security interoperability needs. > -----Original Message----- > From: nav6tf-bounces@ipv6forum.com > [mailto:nav6tf-bounces@ipv6forum.com] On Behalf Of Latif > LADID ("The New Internet based on IPv6") > Sent: Thursday, April 22, 2010 7:04 AM > To: 'Frankel, Sheila E.'; IPSec@ietf.org; ipv6@ietf.org > Cc: ipv6ready-tech@ipv6ready.org; nav6tf@ipv6forum.com > Subject: Re: [Nav6tf] Announcing the USGv6 Testing Meeting at NIST > > Thanks Sheila! Good to see you working on IPv6 so vigorously > recalling our > days of work on IPsec back in 99. > > I have Copied the North American v6 Task Force members and > the IPv6 Ready > logo program team. > > Cheers > Latif > > -----Original Message----- > From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On > Behalf Of > Frankel, Sheila E. > Sent: 21 April 2010 14:46 > To: ipsec@ietf.org; ipv6@ietf.org > Subject: Announcing the USGv6 Testing Meeting at NIST > > Announcing the USGv6 Testing Meeting at NIST. > > To be held on Thursday May 20th 2010 in the AML Conference Room, > Building 215 Room C103, from 9am till 5pm. > > Following publication of the USG Profile NIST has established > a testing > program to determine products' compliance to USGv6 > capabilities. There > are at present 2 accreditors and 2 accredited test > laboratories enrolled > in the program, with more test laboratories in consideration. > July 2010 > marks the date when USG Federal Agencies begin to make IT > acquisitions > using the USGv6 profile version 1.0. We wanted to host a > public meeting > to give: > - a review of how the testing program is operating. > - an opportunity for feedback from Stakeholders, including test > laboratories, product vendors and USG Agencies. > > Accordingly we seek discussion inputs to include: > - statements from accredited and prospective test laboratories. > - statements/questions and issues from Agencies and users. > - statements, questions and issues from USGv6 product vendors. > > Issues are expected to include: > - testing operations and interlaboratory comparisons. > - USGv6 capabilities and requirements. > - Suppliers Declaration of Conformity. > > There will also be some discussion of the forthcoming USGv6 profile > version 2. A full Agenda will be posted to signed up > attendees closer > to the day of the meeting. Due to room size limitations > there can be a > maximum of about 70 participants at this meeting, and attendance from > any one company may need to be limited. Reply to > usgv6-project@antd.nist.gov if you wish to participate, giving full > name, company affiliation, title, contact details and whether > you are a > U.S. citizen. Please also let us know if you have issues you wish to > present, with a maximum of 2 or 3 slides, and speaking time limited > depending on the response. > > For further information, please contact Stephen Nightingale > (night@nist.gov) > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > > _______________________________________________ > Nav6tf mailing list > Nav6tf@ipv6forum.com > http://lists.ipv6forum.com/mailman/listinfo/nav6tf >=20 ------=_NextPart_000_02B8_01CAE251.6F9C67F0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Pete,

 

This meeting is very crucial especially for vendors and = to a certain extent to ISPs, so John could publish =C2=A0this event (most = probably already done so) to his ARIN constituency as it=E2=80=99s = Sheila=E2=80=99s desire to get a good representation from all stakeholders.

 

It would be good to time Yanick for this meeting as she = oversees all v6 Ready & Enabled programs together with Hiroshis, Erica, = Timothy, etc, all power designers of these very technical and complex Interop = programs.

 

We have Germany coming pretty strong as well with a great = event (IPv6 Congress) May 20: http://www.heise.= de/events/2010/ipv6-kongress/

 

In terms of v6 prefix ranking the US has shot thru the = roof with 450 v6 Prefixes visible among 1230 allocated, making the US by far the = largest v6 world. I guess ARIN=E2=80=99s aggressive campaign is collecting its = fruits. Congrats.

 

Cheers

Latif

 

 

From: Tseronis, Peter [mailto:Peter.Tseronis@hq.doe.gov]
Sent: 22 April 2010 18:47
To: 'latif@ladid.lu'; 'terry.l.davis@boeing.com'; 'sheila.frankel@nist.gov'; 'ipsec@ietf.org'; 'ipv6@ietf.org'
Cc: 'stephen.whitlock@boeing.com'; = 'ipv6ready-tech@ipv6ready.org'; 'nav6tf@ipv6forum.com'; 'members@ipv6forum.com'; 'tim.polk@nist.gov'
Subject: Re: [Members] [Nav6tf] Announcing the USGv6 Testing = Meeting at NIST

 

Latif,

Will you be in town for this? I will be there for sure.

Yanick and I are getting together ahead of the meeting.

Also, Junaid Islam, John Curran, and I are meeting on Monday.

Pete
Peter J. Tseronis
Senior Advisor
U.S. Department of Energy
301-903-8262 (office)
202-841-5335 (mobile)

 


From: members-bounces@ipv6forum.com <members-bounces@ipv6forum.com>
To: 'Davis, Terry L' <terry.l.davis@boeing.com>; 'Frankel, = Sheila E.' <sheila.frankel@nist.gov>; ipsec@ietf.org = <ipsec@ietf.org>; ipv6@ietf.org <ipv6@ietf.org>
Cc: 'Whitlock, Stephen' <stephen.whitlock@boeing.com>; ipv6ready-tech@ipv6ready.org <ipv6ready-tech@ipv6ready.org>; nav6tf@ipv6forum.com <nav6tf@ipv6forum.com>; members@ipv6forum.com <members@ipv6forum.com>; tim.polk@nist.gov = <tim.polk@nist.gov>
Sent: Thu Apr 22 12:41:39 2010
Subject: Re: [Members] [Nav6tf] Announcing the USGv6 Testing = Meeting at NIST

Terry,

 

You touch a core issue of the he IPv6 Ready Logo = program.

 

The v6RL Phase II (Logo) includes IPsec interop = testing.

 

Though we have stayed away at this staged from mandating = IPsec per RFC to give industry the time to put its arms around IPv6 issues = first,

there a dozen of products that tested IPsec succesfully: =

 

http://cf.v6pc.j= p/logo_db/approved_list_ph2.php

 

We have not yet defined Phase III which could include = IPsec mandated. Now, we need to carefully define the test = profiles.

 

This needs a serious discussion before moving = forward.

 

Cheers

Latif

 

 

From: nav6tf-bounces@ipv6forum.com [mailto:nav6tf-bounces@ipv6forum.com] On Behalf Of Davis, Terry = L
Sent: 22 April 2010 18:06
To: 'Latif LADID ("The New Internet based on IPv6")'; 'Frankel, Sheila E.'; ipsec@ietf.org; ipv6@ietf.org
Cc: Whitlock, Stephen; ipv6ready-tech@ipv6ready.org; nav6tf@ipv6forum.com; 'tim.polk@nist.gov'
Subject: Re: [Nav6tf] Announcing the USGv6 Testing Meeting at = NIST

 

Sheila

Like Latif said, THANK YOU!

As you know from the Seattle meeting with aviation industry = representatives and the vendor community last fall, the Internet security protocols' interoperability is a key lynchpin in being able to ensure that the next generation of Internet enabled aircraft can establish secure = communications in the global aviation environment.  Aviation continues to be = concerned that current IPv4 versions of IPsec, IKE, and IKEv2 still have  vendor-to-vendor compatibility issues that would be difficult for us to overcome in a fully heterogeneous global environment.  In our environment, an aircraft is continually making and breaking = security associations between different service providers and air traffic = management entities as it transverses from country to country and continent to = continent.  Thus our environment requires a very high degree of confidence in = the ability of our systems to dynamically re-establish secure links = with these new entities.

We would encourage that interoperability testing fully include versions = of IPSec, IKE, and IKEv2 to ensure these issues do not continue with IPv6 = on which the next generations of global air traffic management will reply on = (ICAO Document 9896).  The testing ideally should demonstrate a vendor's system's ability to establish links with other vendors systems with = minimal time and effort for setup and link customization as the ease-of-use and ease-of-deployment will be critical for a global aviation = infrastructure.

Unfortunately I will be unable to attend as I will in ICAO = meetings that week, part of which will focus on these same issues.

Take care

Terry L Davis, P.E
Boeing Technical Fellow

Aircraft Network and Security, Architecture & Strategy
Engineering Core =E2=80=93 Avionics =
Boeing Commercial Airplanes

Phone:  206-280-3716
Email:   Terry.L.Davis@Boeing.com

PS:  It would also seem likely that the other CI sectors would = have similar IPv6 security interoperability needs.




> -----Original Message-----
> From: nav6tf-bounces@ipv6forum.com
> [mailto:nav6tf-bounces@ipv6fo= rum.com] On Behalf Of Latif
> LADID ("The New Internet based on IPv6")
> Sent: Thursday, April 22, 2010 7:04 AM
> To: 'Frankel, Sheila E.'; IPSec@ietf.org; ipv6@ietf.org
> Cc: ipv6ready-tech@ipv6ready.org; nav6tf@ipv6forum.com
> Subject: Re: [Nav6tf] Announcing the USGv6 Testing Meeting at = NIST
>
> Thanks Sheila! Good to see you working on IPv6 so vigorously
> recalling our
> days of work on IPsec back in 99.
>
> I have Copied the North American v6 Task Force members and
> the IPv6 Ready
> logo program team.
>
> Cheers
> Latif
>
> -----Original Message-----
> From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On
> Behalf Of
> Frankel, Sheila E.
> Sent: 21 April 2010 14:46
> To: ipsec@ietf.org; ipv6@ietf.org
> Subject: Announcing the USGv6 Testing Meeting at NIST
>
> Announcing the USGv6 Testing Meeting at NIST.
>
> To be held on Thursday May 20th 2010 in the AML Conference = Room,
> Building 215 Room C103, from 9am till 5pm.
>
> Following publication of the USG Profile NIST has established
> a testing
> program to determine products' compliance to USGv6
> capabilities. There
> are at present 2 accreditors and 2 accredited test
> laboratories enrolled
> in the program, with more test laboratories in consideration.
>  July 2010
> marks the date when USG Federal Agencies begin to make IT
> acquisitions
> using the USGv6 profile version 1.0.  We wanted to host a
> public meeting
> to give:
>     - a review of how the testing program is operating.
>     - an opportunity for feedback from = Stakeholders, including test
> laboratories, product vendors and USG Agencies.
>
> Accordingly we seek discussion inputs to include:
>     - statements from accredited and = prospective test laboratories.
>     - statements/questions and issues from = Agencies and users.
>     - statements, questions and issues from = USGv6 product vendors.
>
> Issues are expected to include:
>     - testing operations and interlaboratory comparisons.
>     - USGv6 capabilities and requirements.
>     - Suppliers Declaration of Conformity.
>
> There will also be some discussion of the forthcoming USGv6 = profile
> version 2.  A full Agenda will be posted to signed up
> attendees closer
> to the day of the meeting.  Due to room size limitations
> there can be a
> maximum of about 70 participants at this meeting, and attendance = from
> any one company may need to be limited. Reply to
> usgv6-project@antd.nist.gov if you wish to participate, giving = full
> name, company affiliation, title, contact details and whether
> you are a
> U.S. citizen. Please also let us know if you have issues you wish = to
> present, with a maximum of 2 or 3 slides, and speaking time = limited
> depending on the response.
>
> For further information, please contact Stephen Nightingale
> (night@nist.gov)
>
>
> = --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/= mailman/listinfo/ipv6
> = --------------------------------------------------------------------
>
> _______________________________________________
> Nav6tf mailing list
> Nav6tf@ipv6forum.com
> http://lists.= ipv6forum.com/mailman/listinfo/nav6tf
>

------=_NextPart_000_02B8_01CAE251.6F9C67F0-- From slblake@petri-meat.com Thu Apr 22 10:44:11 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 D7E523A6C4D for ; Thu, 22 Apr 2010 10:44:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.498 X-Spam-Level: X-Spam-Status: No, score=-0.498 tagged_above=-999 required=5 tests=[AWL=0.312, BAYES_05=-1.11, 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 Mn1Gu73ZdJBR for ; Thu, 22 Apr 2010 10:44:10 -0700 (PDT) Received: from elom.tchmachines.com (elom.tchmachines.com [208.76.80.198]) by core3.amsl.com (Postfix) with ESMTP id 3F1263A6C0E for ; Thu, 22 Apr 2010 10:32:16 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=petri-meat.com) by elom.tchmachines.com with esmtpa (Exim 4.69) (envelope-from ) id 1O50FN-0006jZ-Bg; Thu, 22 Apr 2010 13:31:29 -0400 MIME-Version: 1.0 Date: Thu, 22 Apr 2010 13:31:29 -0400 From: Steven Blake To: =?UTF-8?Q?R=C3=A9mi_Despr=C3=A9s?= Subject: Re: Stateless assignment of flow-labels in source hosts In-Reply-To: <7CF502E9-9D9C-4CF6-992A-6B726E409A41@free.fr> References: <5AD500D8-B59B-4DCE-A9E8-93B1CA5848E6@free.fr> <6029E6FA-DF50-409F-8EB6-2F67D1A886FF@free.fr> <4BCF6B55.3010005@gmail.com> <7CF502E9-9D9C-4CF6-992A-6B726E409A41@free.fr> Message-ID: <571d0581303e04f90f84669944003254@petri-meat.com> X-Sender: slblake@petri-meat.com User-Agent: RoundCube Webmail/0.3.1 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8 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 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: Thu, 22 Apr 2010 17:44:12 -0000 On Thu, 22 Apr 2010 10:08:34 +0200, Rémi Després wrote: > Le 21 avr. 2010 à 23:17, Brian E Carpenter a écrit : > >> On 2010-04-21 20:50, Rémi Després wrote: >>> Hi Brian, >>> >>> I wonder what you think of what I answered to James on another >>> discussion thread. >> >> I agree. I think that particular SHOULD in the RFC is an error. It >> "SHOULD" >> have said something like: >> >> "The source node MUST select new Flow Label values by a method that >> prevents unintended Flow Label value reuse." > > Yes, that's more appropriate. > > Suggesting in addition that a 5-tuple hash can be an easy way to set > flow-label values, because it is stateless, would IMHO improve chances that > host really set them. > Wold you agree on this too? My reading of "The source node MUST select new Flow Label values by a method that prevents unintended Flow Label value reuse." would preclude use of a 5-tuple hash, which could result in coincidental selection of a flow label value already in-use by another flow. Do we really want/need to specify a MUST here? What is wrong with low-probability, coincidental flow label reuse between flows with different source/destination address pairs, so long as the values are otherwise uniformly distributed and unpredictable? Regards, // Steve From jinmei@isc.org Thu Apr 22 11:28:42 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 0994728C1DC for ; Thu, 22 Apr 2010 11:28:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.65 X-Spam-Level: X-Spam-Status: No, score=0.65 tagged_above=-999 required=5 tests=[AWL=-0.050, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, RDNS_DYNAMIC=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 2G1Ezu0Y5OIL for ; Thu, 22 Apr 2010 11:28:35 -0700 (PDT) Received: from farside.isc.org (farside.isc.org [IPv6:2001:4f8:3:bb::5]) by core3.amsl.com (Postfix) with ESMTP id E97BE3A6A41 for ; Thu, 22 Apr 2010 11:20:22 -0700 (PDT) Received: from jmb.jinmei.org (dhcp-95.sql1.isc.org [149.20.50.95]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by farside.isc.org (Postfix) with ESMTP id 516DEE92C1; Thu, 22 Apr 2010 18:20:10 +0000 (UTC) (envelope-from jinmei@isc.org) Date: Thu, 22 Apr 2010 11:20:09 -0700 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Jean-Michel Combes Subject: Re: RFC 4862 - Clarification question on DAD procedure In-Reply-To: References: User-Agent: Wanderlust/2.14.0 (Africa) Emacs/22.1 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Apr 2010 18:28:42 -0000 At Thu, 22 Apr 2010 17:22:26 +0200, Jean-Michel Combes wrote: > 5.4.3. Receiving Neighbor Solicitation Messages > > [snip] > > If the source address of the Neighbor Solicitation is the unspecified > address, the solicitation is from a node performing Duplicate Address > Detection. If the solicitation is from another node, the tentative > address is a duplicate and should not be used (by either node). > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > But I must admit I don't see how the another node would be aware of > the tentative address is a duplicate. > Indeed, as the first node has to stop DAD after the another node's NS > message reception, this first node should not send new NS messages > with the same tentative address and so the another node should > validate this address ... I suspect the intended scenario was that nodes A and B simultaneously start DAD and send out their NSes (probably after some random delays) almost at the same time so that both nodes see the other NSes while still performing DAD: 1. node A starts DAD, waiting some random period 2. node B starts DAD, waiting some random period 3. node A sends out a DAD NS, waiting 1sec 4. node B sends out a DAD NS (before receiving and handling A's NS), waiting 1sec 5. node B receives A's NS, detect duplicate 6. node A receives B's NS, detect duplicate Of course, this could also go like this: 1. node A starts DAD, waiting some random period 2. node B starts DAD, waiting some random period 3. node A sends out a DAD NS, waiting 1sec 4. node B receives A's NS, detect duplicate (before the waiting period expires, so there's no NS from B) In this case, yes, A will keep using the address. Remember, DAD is not a 100% reliable protocol, and in some cases it can result in a suboptimal state. But in this specific case, the result is not as bad as the case where two or more nodes keep using a duplicate address (e.g., due to DAD NSes being dropped); at least one of the conflicting nodes can detect the duplicate. --- JINMEI, Tatuya Internet Systems Consortium, Inc. From remi.despres@free.fr Thu Apr 22 12:06:08 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 C7F033A6C96 for ; Thu, 22 Apr 2010 12:06:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.39 X-Spam-Level: X-Spam-Status: No, score=-0.39 tagged_above=-999 required=5 tests=[AWL=0.070, BAYES_05=-1.11, 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 4NgFgLmCd1a1 for ; Thu, 22 Apr 2010 12:06:08 -0700 (PDT) Received: from smtp6-g21.free.fr (smtp6-g21.free.fr [212.27.42.6]) by core3.amsl.com (Postfix) with ESMTP id DA77528C278 for ; Thu, 22 Apr 2010 11:41:10 -0700 (PDT) Received: from smtp6-g21.free.fr (localhost [127.0.0.1]) by smtp6-g21.free.fr (Postfix) with ESMTP id B16E0E08142; Thu, 22 Apr 2010 20:40:56 +0200 (CEST) Received: from [192.168.0.13] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by smtp6-g21.free.fr (Postfix) with ESMTP id A13A1E080FB; Thu, 22 Apr 2010 20:40:53 +0200 (CEST) Subject: Re: Stateless assignment of flow-labels in source hosts Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: <571d0581303e04f90f84669944003254@petri-meat.com> Date: Thu, 22 Apr 2010 20:40:53 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <64A922ED-88FF-4CFF-823C-6F804AED3340@free.fr> References: <5AD500D8-B59B-4DCE-A9E8-93B1CA5848E6@free.fr> <6029E6FA-DF50-409F-8EB6-2F67D1A886FF@free.fr> <4BCF6B55.3010005@gmail.com> <7CF502E9-9D9C-4CF6-992A-6B726E409A41@free.fr> <571d0581303e04f90f84669944003254@petri-meat.com> To: Steven Blake X-Mailer: Apple Mail (2.1078) Cc: 6man 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: Thu, 22 Apr 2010 19:06:08 -0000 Le 22 avr. 2010 =E0 19:31, Steven Blake a =E9crit : > On Thu, 22 Apr 2010 10:08:34 +0200, R=E9mi Despr=E9s = > wrote: >=20 >> Le 21 avr. 2010 =E0 23:17, Brian E Carpenter a =E9crit : >>=20 >>> On 2010-04-21 20:50, R=E9mi Despr=E9s wrote: >>>> Hi Brian, >>>>=20 >>>> I wonder what you think of what I answered to James on another >>>> discussion thread. >>>=20 >>> I agree. I think that particular SHOULD in the RFC is an error. It >>> "SHOULD" >>> have said something like: >>>=20 >>> "The source node MUST select new Flow Label values by a method that >>> prevents unintended Flow Label value reuse." >>=20 >> Yes, that's more appropriate. >>=20 >> Suggesting in addition that a 5-tuple hash can be an easy way to set >> flow-label values, because it is stateless, would IMHO improve = chances > that >> host really set them. >> Wold you agree on this too? >=20 > My reading of "The source node MUST select new Flow Label values by a > method that prevents unintended Flow Label value reuse." would = preclude use > of a 5-tuple hash, which could result in coincidental selection of a = flow > label value already in-use by another flow. Well, "unintended" may be taken as permitting the hash (its intent of = the hash that two different 5-tuples give in general two different = values, with only statistically rare exceptions), but better words may = also be proposed. In any case, explicitly permitting the 5-tuple hash is IMHO desireble. Regard, RD >=20 > Do we really want/need to specify a MUST here? What is wrong with > low-probability, coincidental flow label reuse between flows with = different > source/destination address pairs, so long as the values are otherwise > uniformly distributed and unpredictable? >=20 >=20 > Regards,=20 >=20 > // Steve From shane@castlepoint.net Thu Apr 22 12:40:45 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 3B3A53A692B for ; Thu, 22 Apr 2010 12:40:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jh3V7I8WlnoC for ; Thu, 22 Apr 2010 12:40:44 -0700 (PDT) Received: from dog.tcb.net (dog.tcb.net [64.78.150.133]) by core3.amsl.com (Postfix) with ESMTP id E7EA228C1D1 for ; Thu, 22 Apr 2010 12:30:53 -0700 (PDT) Received: by dog.tcb.net (Postfix, from userid 0) id BF63026866F; Thu, 22 Apr 2010 13:30:43 -0600 (MDT) 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; Thu, 22 Apr 2010 13:30:43 -0600 (MDT) (envelope-from shane@castlepoint.net) X-Avenger: version=0.7.8; receiver=dog.tcb.net; client-ip=64.78.235.218; client-port=55762; data-bytes=0 Subject: Re: DRAFT: Request for guidance about the flow label Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=iso-8859-1 From: Shane Amante In-Reply-To: <1D69CC44-FA38-4D7D-A456-83D315B1F06B@free.fr> Date: Thu, 22 Apr 2010 13:30:42 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <545F3966-1BF8-41DC-91B3-6DB3D3C679B2@castlepoint.net> References: <4BCFBADA.8090901@gmail.com> <0FEC3C33-071C-48C4-9BD8-91CF63573377@free.fr> <2FC3BE87-AFDD-441F-8262-55049B6AFED1@castlepoint.net> <1D69CC44-FA38-4D7D-A456-83D315B1F06B@free.fr> To: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= X-Mailer: Apple Mail (2.1078) 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: Thu, 22 Apr 2010 19:40:45 -0000 Remi, I think we may be in agreement that domain-specific uses of the = flow-label are problematic for the reason you illustrate below? Namely, = that once one domain sets it to something that is not known to be a 3- = or 5-tuple of the IPv6 header, then you lose the ability to use that = flow-label for, say, calculating a load-balancing hash for LAG and ECMP = paths. See below for more. On Apr 22, 2010, at 10:50 MDT, R=E9mi Despr=E9s wrote: > Le 22 avr. 2010 =E0 17:31, Shane Amante a =E9crit : >=20 >> Brian, Remi, >>=20 >> On Apr 22, 2010, at 06:50 MDT, R=E9mi Despr=E9s wrote: >>> Le 22 avr. 2010 =E0 04:56, Brian E Carpenter a =E9crit : >>>=20 >>>> I think we need to simplify the change proposed in >>>> draft-carpenter-6man-flow-update-02 even more after the recent >>>> discussions, while maintaining the proposed duality >>>> (RFC 3697-like >>>> use still possible, but locally-defined use also possible for those = who >>>> want it). >>>=20 >>> In my understanding, restoring domain-entrance FL-values at domain = exit should be a "MUST" for any domain-specific use: >>=20 >> I'm concerned with Remi's above proposal about restoring FL-values at = domain exit. >>=20 >> IMHO, instead of restoring FL-values at domain exit, it is /much/ = more simple to declare that Flow-Label values are _mutable_ when a = packet crosses over from one administratively defined domain to the = next. I doubt any existing, already deployed high-speed network = equipment (routers) would support any scheme to "restore" = domain-specific FL-values from entrance to exit of a domain -- although, = I haven't conducted a thorough investigation with them; rather, I'm = basing this on knowledge of the forwarding architecture of various, = **already deployed** (and, will keep getting deployed) platforms whose = ASIC's are extremely limited, to say the least. >=20 > Would these deployment use domain-specific computations of flow = labels? Since I'm not a proponent of domain-specific, "special-use" flow-labels, = that's a question I can't answer, particularly given each = domain-specific proposal likely has various amounts of computational = complexity. (I'll save my comments on 'draft-hu-flow-label-cases' for a = separate e-mail).=20 > If yes, have you more information on what they do? > (Any computation of FLs based on 5-tuples in intermediate routers = would be well beyond what an asic can do.) How would we expect to implement restoral of domain-specific flow-labels = upon entrance or exit of a administratively-defined domain, (hopefully = in a _stateless_ manner)? I'm not sure if this has already been = discussed, but the only thing I've come up with is that upon entrance to = a domain, the ingress PE would have to "push" the existing IPv6 = flow-label into a new, to-be-defined IPv6 Extension Header for transport = across the domain. Then, at exit from the administrative domain, the = egress PE would have to be able to "pop" the Extension Header containing = the old IPv6 flow-label and put it back into the outermost IPv6 = flow-label field. That's: a) likely difficult/impossible to do in = existing HW; b) creates more challenges for routers in dealing with, = possibly, unknown Extension Headers; and, c) challenging operationally, = particularly if we were to require operators to turn this behavior = on/off at each border interface to their network. > The main reason I see to restore FLs is that, if a domain replaces a = "good" FL coming from upstream (host generated and 5-tuple based ), by = another that isn't 5-tuple based, routers that are further downstream = won't be able to use the "good" FL for their load sharing. I completely agree that this is a challenging problem; however, I see a = few ways of potentially dealing with it: a) Restoral of domain-specific flow-label values, (your proposal), at = egress from an administratively defined domain -- which I find might be = impractical to implement; or, b) Declare that the flow-label is _mutable_ by each administrative = domain. Therefore, I _MAY_ not trust an incoming IPv6 flow-label from = another administrative domain. However, in thinking about this a bit = more, this has problems of it's own, namely: a) the dependency of = intermediate routers to (re)calculate a "good" flow-label based off the = 3- or 5-tuple in the IPv6 header (possible, but not guaranteed); and, b) = it could unintentionally overwrite "good" flow-labels, particularly = those of inter-domain IP-in-IPv6 tunnels (cf: = draft-carpenter-flow-ecmp), where the outer IPv6 header may have a = "good" flow-label based on the inner IP header's 5-tuple -- which is = bad. c) Declare the flow-label is _immutable_ and must be set by all hosts = and must only contain a 3- or 5-tuple hash of the appropriate IPv6 = headers. Further use cases for the flow-label would be restricted. = IMHO, this would be by far the easiest from an implementation and = operational point-of-view, however this is unlikely to appeal to = proponents of domain-specific special-uses of flow-labels, = unfortunately. =20 FWIW, related to the last point, (and as I'm sure you're well aware of), = I'd also add that we're well beyond the alpha and beta stages of IPv6 = deployment and well into mad deployment phase of IPv6 to mitigate IPv4 = address exhaustion. Therefore, if a legitimate use of flow-labels has = not been found in the last 15 years of IPv6 development, it's time to = move on and use the flow-label for something useful and practical in = production networks, (i.e.: a hash of the 3- or 5-tuple of L3 + L4 = headers for LAG + ECMP load-balancing). -shane= From albert.e.manfredi@boeing.com Thu Apr 22 13:24:30 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 6B55E3A6951 for ; Thu, 22 Apr 2010 13:24:30 -0700 (PDT) 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 4b4o0S34X+IQ for ; Thu, 22 Apr 2010 13:24:29 -0700 (PDT) Received: from slb-smtpout-01.boeing.com (slb-smtpout-01.boeing.com [130.76.64.48]) by core3.amsl.com (Postfix) with ESMTP id 3697C3A67FE for ; Thu, 22 Apr 2010 13:24:10 -0700 (PDT) Received: from stl-av-01.boeing.com (stl-av-01.boeing.com [192.76.190.6]) by slb-smtpout-01.ns.cs.boeing.com (8.14.4/8.14.4/8.14.4/SMTPOUT) with ESMTP id o3MKNTH6004663 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 22 Apr 2010 13:23:29 -0700 (PDT) Received: from stl-av-01.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_RELAY) with ESMTP id o3MKNSi2012918; Thu, 22 Apr 2010 15:23:28 -0500 (CDT) Received: from XCH-MWHT-03.mw.nos.boeing.com (xch-mwht-03.mw.nos.boeing.com [134.57.119.161]) by stl-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id o3MKNSnG012913 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Thu, 22 Apr 2010 15:23:28 -0500 (CDT) Received: from XCH-MW-08V.mw.nos.boeing.com ([134.57.119.191]) by XCH-MWHT-03.mw.nos.boeing.com ([134.57.119.161]) with mapi; Thu, 22 Apr 2010 15:23:28 -0500 From: "Manfredi, Albert E" To: Shane Amante Date: Thu, 22 Apr 2010 15:23:27 -0500 Subject: RE: DRAFT: Request for guidance about the flow label Thread-Topic: DRAFT: Request for guidance about the flow label Thread-Index: AcriVglTrlrFdUu8RjOfiqYrlrN73QAAqryA Message-ID: References: <4BCFBADA.8090901@gmail.com><0FEC3C33-071C-48C4-9BD8-91CF6357337 7@free.fr><2FC3BE87-AFDD-441F-8262-55049B6AFED1@castlepoint.net><1D69CC44-FA38-4D7D-A456-83D315B1F06B@free.fr> <545F3966-1BF8-41DC-91B3-6DB3D3C679B2@castlepoint.net> In-Reply-To: <545F3966-1BF8-41DC-91B3-6DB3D3C679B2@castlepoint.net> 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: 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, 22 Apr 2010 20:24:30 -0000 > -----Original Message----- > From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On=20 > Behalf Of Shane Amante > c) Declare the flow-label is _immutable_ and must be set by=20 > all hosts and must only contain a 3- or 5-tuple hash of the=20 > appropriate IPv6 headers. Further use cases for the=20 > flow-label would be restricted. IMHO, this would be by far=20 > the easiest from an implementation and operational=20 > point-of-view, however this is unlikely to appeal to=20 > proponents of domain-specific special-uses of flow-labels,=20 > unfortunately. =20 Count me in. In following this thread, I've come to believe that this is th= e best course of action. And it keeps the flow label immutable, as original= ly prescribed. > Therefore, if a legitimate use of flow-labels has not been=20 > found in the last 15 years of IPv6 development, it's time to=20 > move on and use the flow-label for something useful and=20 > practical in production networks, (i.e.: a hash of the 3- or=20 > 5-tuple of L3 + L4 headers for LAG + ECMP load-balancing). Indeed. This becomes doable easily in IPv6, no matter the extension headers= . What better purpose could there be for this field? And it's certainly NOT= a stretch to think that the traditional 5-tuple was, in fact, used to defi= ne what some might call a "flow." Bert From jinmei@isc.org Thu Apr 22 14:02:31 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 9DF133A698C for ; Thu, 22 Apr 2010 14:02:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.459 X-Spam-Level: ** X-Spam-Status: No, score=2.459 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, CHARSET_FARAWAY_HEADER=3.2, NO_RELAYS=-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 S74YcbTy+p1s for ; Thu, 22 Apr 2010 14:02:30 -0700 (PDT) Received: from farside.isc.org (farside.isc.org [IPv6:2001:4f8:3:bb::5]) by core3.amsl.com (Postfix) with ESMTP id C9C1B3A6957 for ; Thu, 22 Apr 2010 14:02:26 -0700 (PDT) Received: from jmb.jinmei.org (unknown [IPv6:2001:4f8:3:64:217:f2ff:fee0:a91f]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by farside.isc.org (Postfix) with ESMTP id AD4E8E92F3; Thu, 22 Apr 2010 21:02:13 +0000 (UTC) (envelope-from jinmei@isc.org) Date: Thu, 22 Apr 2010 14:02:13 -0700 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Simon Perreault Subject: Re: which interface to choose to send to destination link-local address - any RFC? In-Reply-To: <4BC5ADCD.7010801@viagenie.ca> References: <30123.50490.qm@web30104.mail.mud.yahoo.com> <4BC5ADCD.7010801@viagenie.ca> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/22.1 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Apr 2010 21:02:31 -0000 At Wed, 14 Apr 2010 07:58:05 -0400, Simon Perreault wrote: > > So in case of TCP, client which tries to connect to the server, should > > provide its link-local source address during socket(), bind() calls. > > No. On the client side there should be no bind() call, and the socket() > call is unaffected since it doesn't take any address parameter. In the > connect() call, for the struct sockaddr parameter, the sin6_addr member > will contain the server's link-local address and the sin6_scope_id > member will contain the scope id of the client's interface on which the > server can be reached. And, if the implementation supports an extension to textual address representation as described in RFC4007 Section 11, and if the application uses the getaddrinfo(3) library function that understands the extension, the application doesn't have to do anything about sin6_scope_id. I don't know how many implementations support this extension, but all BSD variants should support it, and Linux (i.e. glibc getaddrinfo) seems to support it. I heard Windows also support the extension, but I don't know much about it. BTW: to be pedantic as a co-author of RFC4007, I'd like to note that "link" is a broader scope than "interface", at least architecturally. So, for example, two different interfaces can belong to the same single link, and "the sin6_scope_id member will contain the scope id of the client's interface on which the server can be reached." should actually read "...client's link on which ...". In practice, however, many (if not all) implementations assume one-to-one mapping between links and interfaces, so we can normally use "interface" and "link" interchangeably. > > Based on that IPv6 stack will figure out the out-going interface. > > There is no need for the stack to "figure out" the outgoing interface > since the application tells it plainly in the sin6_scope_id parameter. That's true, although I've heard there used to be an implementation that tries neighbor discovery on all possible links when the outgoing link is ambiguous from the destination address. I'd also like to note that RFC4007 suggests the implementation have the notion of "default scope zone". In some sense, it could be considered a way for the stack to figure out outgoing link (interface) when it's ambiguous. --- JINMEI, Tatuya Internet Systems Consortium, Inc. From brian.e.carpenter@gmail.com Thu Apr 22 14:25:36 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 A19833A6970 for ; Thu, 22 Apr 2010 14:25:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.207 X-Spam-Level: X-Spam-Status: No, score=-2.207 tagged_above=-999 required=5 tests=[AWL=0.092, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MIfKNid5ZtRs for ; Thu, 22 Apr 2010 14:25:35 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by core3.amsl.com (Postfix) with ESMTP id E725C3A692C for ; Thu, 22 Apr 2010 14:25:33 -0700 (PDT) Received: by wwb24 with SMTP id 24so1635315wwb.31 for ; Thu, 22 Apr 2010 14:25:20 -0700 (PDT) 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=27cQdhZ/9ZceW13LBmAsS9jvsKj+GmsgdO6NSMHxH+E=; b=meVzx4i7mFkS5qoWMtBJcxNWUKoDGKOdO12IE3EBluGaHjxesf8Xx9bbfqEYd3L6AO OK9pn9mBtK4NZ97409gnXxl0y70nRsLXJynGwdr7x/Nj7MCLoJMmzktref+5yPDgDQ0s AwgkpH36SDfhAaBQStTeOufnE3RS2AqJ5i7h4= 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=gVj4Ow4Zt0SKJWhVQjGKYea6prJ+oVElOwFwo8zdg1b8fhjKT9OhmLTD1omQIjo2e7 Esuo/LmmRA9Ke959/zGh6gkAgSetAs0EHhx8iMqqMzWofWQMWNs4NsZgO6UShiEIAUbB gg91WGbc5qU8sSHouxQLNmWLzT9Ai6ybmotAE= Received: by 10.216.172.21 with SMTP id s21mr242093wel.61.1271971520471; Thu, 22 Apr 2010 14:25:20 -0700 (PDT) Received: from [130.216.38.124] (stf-brian.sfac.auckland.ac.nz [130.216.38.124]) by mx.google.com with ESMTPS id x14sm2710220wbs.6.2010.04.22.14.25.16 (version=SSLv3 cipher=RC4-MD5); Thu, 22 Apr 2010 14:25:19 -0700 (PDT) Message-ID: <4BD0BEAC.6000706@gmail.com> Date: Fri, 23 Apr 2010 09:25:00 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: =?UTF-8?B?UsOpbWkgRGVzcHLDqXM=?= Subject: Re: Stateless assignment of flow-labels in source hosts References: <5AD500D8-B59B-4DCE-A9E8-93B1CA5848E6@free.fr> <6029E6FA-DF50-409F-8EB6-2F67D1A886FF@free.fr> <4BCF6B55.3010005@gmail.com> <7CF502E9-9D9C-4CF6-992A-6B726E409A41@free.fr> <571d0581303e04f90f84669944003254@petri-meat.com> <64A922ED-88FF-4CFF-823C-6F804AED3340@free.fr> In-Reply-To: <64A922ED-88FF-4CFF-823C-6F804AED3340@free.fr> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: 6man , 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: Thu, 22 Apr 2010 21:25:36 -0000 On 2010-04-23 06:40, R=C3=A9mi Despr=C3=A9s wrote: > Le 22 avr. 2010 =C3=A0 19:31, Steven Blake a =C3=A9crit : >=20 >> On Thu, 22 Apr 2010 10:08:34 +0200, R=C3=A9mi Despr=C3=A9s >> wrote: >> >>> Le 21 avr. 2010 =C3=A0 23:17, Brian E Carpenter a =C3=A9crit : >>> >>>> On 2010-04-21 20:50, R=C3=A9mi Despr=C3=A9s wrote: >>>>> Hi Brian, >>>>> >>>>> I wonder what you think of what I answered to James on another >>>>> discussion thread. >>>> I agree. I think that particular SHOULD in the RFC is an error. It >>>> "SHOULD" >>>> have said something like: >>>> >>>> "The source node MUST select new Flow Label values by a method that >>>> prevents unintended Flow Label value reuse." >>> Yes, that's more appropriate. >>> >>> Suggesting in addition that a 5-tuple hash can be an easy way to set >>> flow-label values, because it is stateless, would IMHO improve chance= s >> that >>> host really set them. >>> Wold you agree on this too? >> My reading of "The source node MUST select new Flow Label values by a >> method that prevents unintended Flow Label value reuse." would preclud= e use >> of a 5-tuple hash, which could result in coincidental selection of a f= low >> label value already in-use by another flow. >=20 > Well, "unintended" may be taken as permitting the hash (its intent of t= he hash that two different 5-tuples give in general two different values,= with only statistically rare exceptions), but better words may also be = proposed. > In any case, explicitly permitting the 5-tuple hash is IMHO desireble. Yes. And if that produces identical hashes for two different 5-tuples, th= en the lawyer in me says that's "intended" so does not break the MUST. This needs to be carefully wordsmithed, but I think we are in agreement. Brian >=20 > Regard, > RD >=20 >=20 >> Do we really want/need to specify a MUST here? What is wrong with >> low-probability, coincidental flow label reuse between flows with diff= erent >> source/destination address pairs, so long as the values are otherwise >> uniformly distributed and unpredictable? >> >> >> Regards,=20 >> >> // Steve >=20 >=20 From vishwas.ietf@gmail.com Thu Apr 22 14:39:54 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 558033A68DF for ; Thu, 22 Apr 2010 14:39:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.796 X-Spam-Level: X-Spam-Status: No, score=-1.796 tagged_above=-999 required=5 tests=[AWL=0.803, 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 lpwZq-vBjMkt for ; Thu, 22 Apr 2010 14:39:53 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by core3.amsl.com (Postfix) with ESMTP id 2408F3A68C8 for ; Thu, 22 Apr 2010 14:39:53 -0700 (PDT) Received: by gyh4 with SMTP id 4so4755221gyh.31 for ; Thu, 22 Apr 2010 14:39:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:received:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=FK1lf5GoFsFscIuITx3kX3mkZ4A15fZyB+2RShjlWMo=; b=OmOa7ZHQ7Q21cD6sVReoe4eHiJtQOdk4hhYHrj/ChhG3MeJvTxfIO5MFI132S8hL/W sY8iG6oapJxNrEAsIdG7SwulQwoAha9+9rhnM00JgxQ5byU22aU1vWmJMbGxu5yHoRRy ZUMtr/udCcZiCFY8lLMHr8BwMedc8K/9HNtH8= 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=SXQk4jajt41ZGGhp1lcvb+wL6/WoEWEbSBTXHbfKdNSyjLGdbNtz1eErEQrwWb5RBf E5A89/9WJ793jk7VT4QpBEgLv0oGxk9MAx72BbddnDmJqRC82PKx045NoqIFQIRoqfQ9 vEC14XffETitxXcbo3pcx7H4holebNsqJLEXU= MIME-Version: 1.0 Received: by 10.151.27.4 with HTTP; Thu, 22 Apr 2010 14:39:40 -0700 (PDT) In-Reply-To: <4BD0BEAC.6000706@gmail.com> References: <5AD500D8-B59B-4DCE-A9E8-93B1CA5848E6@free.fr> <6029E6FA-DF50-409F-8EB6-2F67D1A886FF@free.fr> <4BCF6B55.3010005@gmail.com> <7CF502E9-9D9C-4CF6-992A-6B726E409A41@free.fr> <571d0581303e04f90f84669944003254@petri-meat.com> <64A922ED-88FF-4CFF-823C-6F804AED3340@free.fr> <4BD0BEAC.6000706@gmail.com> Date: Thu, 22 Apr 2010 14:39:40 -0700 Received: by 10.150.160.4 with SMTP id i4mr10637684ybe.57.1271972380373; Thu, 22 Apr 2010 14:39:40 -0700 (PDT) Message-ID: Subject: Re: Stateless assignment of flow-labels in source hosts From: Vishwas Manral To: Brian E Carpenter Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: 6man , 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: Thu, 22 Apr 2010 21:39:54 -0000 Hi Brian, >> Well, "unintended" may be taken as permitting the hash (its intent of th= e hash that two different 5-tuples give in general two different values, wi= th only statistically rare exceptions), =A0but better words may also be pro= posed. >> In any case, explicitly permitting the 5-tuple hash is IMHO desireble. > > Yes. And if that produces identical hashes for two different 5-tuples, th= en > the lawyer in me says that's "intended" so does not break the MUST. > This needs to be carefully wordsmithed, but I think we are in agreement. Though as the size of the 5-tuple is more than when using the 4-tuple with flow label, it should not be an issue at all. The ingress can use same flow labels when the it doesn't care if certain flows go over the same path or not/ or it could use different flow labels when sending sub-flow traffic over different paths. It could also use the intelligence to distribute flows with different labels, which it cannot in case of the 5-tuple as the values cannot be changed based on flow needs. Thanks, Vishwas > =A0 Brian >> >> Regard, >> RD >> >> >>> Do we really want/need to specify a MUST here? =A0What is wrong with >>> low-probability, coincidental flow label reuse between flows with diffe= rent >>> source/destination address pairs, so long as the values are otherwise >>> uniformly distributed and unpredictable? >>> >>> >>> Regards, >>> >>> // Steve >> >> > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > From brian.e.carpenter@gmail.com Thu Apr 22 14:41:14 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 DF31D3A6A0B for ; Thu, 22 Apr 2010 14:41:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.359 X-Spam-Level: X-Spam-Status: No, score=-2.359 tagged_above=-999 required=5 tests=[AWL=0.240, 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 fT9do0MpC7cO for ; Thu, 22 Apr 2010 14:41:13 -0700 (PDT) Received: from mail-pv0-f172.google.com (mail-pv0-f172.google.com [74.125.83.172]) by core3.amsl.com (Postfix) with ESMTP id D6CBE3A69CA for ; Thu, 22 Apr 2010 14:41:13 -0700 (PDT) Received: by pvg7 with SMTP id 7so1676764pvg.31 for ; Thu, 22 Apr 2010 14:41:01 -0700 (PDT) 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=KVV9rkvv2TdqVSa7Kkm8c99P8HAqEyuWQ7YOhhMfFi4=; b=Ayun13azUNBX6O0hg0mlUnDzLsfBMg1F97m7/7gb+5sYypjqxKZwQpbXgozbTHZJlf inMCezWaKXBdqz0+lLfym3b6j+iCxAdz2vjT1lLdywUJMjoiaea5KcG0c1d0uWFWZgVk ZGVo2g08hS61B/EplcvCLz3OG+sCWajY+u2E8= 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=ffx+YRZU6yU12r82J/iok77LPFHAjiZOUwGc9tBTCj/uMybjHXrYgtgzUgTbDLYamT luW6wLUKBPxOLoaoiWeNpc+ziqwr6qMAu1MaID4Emjkr/jPTRyWS+7tEXZiU4tdntREi fC+iUTS4e9alXFasmqB13+S3K1KMQ3jbOYkiA= Received: by 10.142.250.21 with SMTP id x21mr4956407wfh.263.1271972461692; Thu, 22 Apr 2010 14:41:01 -0700 (PDT) Received: from [130.216.38.124] (stf-brian.sfac.auckland.ac.nz [130.216.38.124]) by mx.google.com with ESMTPS id x34sm165976wfi.16.2010.04.22.14.40.59 (version=SSLv3 cipher=RC4-MD5); Thu, 22 Apr 2010 14:41:00 -0700 (PDT) Message-ID: <4BD0C25B.6010004@gmail.com> Date: Fri, 23 Apr 2010 09:40:43 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Shane Amante Subject: Re: DRAFT: Request for guidance about the flow label References: <4BCFBADA.8090901@gmail.com> <0FEC3C33-071C-48C4-9BD8-91CF63573377@free.fr> <2FC3BE87-AFDD-441F-8262-55049B6AFED1@castlepoint.net> <1D69CC44-FA38-4D7D-A456-83D315B1F06B@free.fr> <545F3966-1BF8-41DC-91B3-6DB3D3C679B2@castlepoint.net> In-Reply-To: <545F3966-1BF8-41DC-91B3-6DB3D3C679B2@castlepoint.net> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: 6man X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Apr 2010 21:41:15 -0000 (Sorry, I messed up the subject of this thread by including "DRAFT") On 2010-04-23 07:30, Shane Amante wrote: > I completely agree that this is a challenging problem; > however, I see a few ways of potentially dealing with it: a) > Restoral of domain-specific flow-label values, (your > proposal), at egress from an administratively defined domain > -- which I find might be impractical to implement; or, There are ways to do this, but they are complex and IMHO undesirable. b) > Declare that the flow-label is _mutable_ by each > administrative domain. Therefore, I _MAY_ not trust an > incoming IPv6 flow-label from another administrative domain. > However, in thinking about this a bit more, this has problems > of it's own, namely: a) the dependency of intermediate > routers to (re)calculate a "good" flow-label based off the 3- > or 5-tuple in the IPv6 header (possible, but not guaranteed); > and, b) it could unintentionally overwrite "good" > flow-labels, particularly those of inter-domain IP-in-IPv6 > tunnels (cf: draft-carpenter-flow-ecmp), where the outer IPv6 > header may have a "good" flow-label based on the inner IP > header's 5-tuple -- which is bad. However, consider that the flow label is a forgeable field, not protected by any checksum (including IPSEC). So you can't trust it and an attacker could always attack your ECMP or LAG by giving all packets the same label. It may be that the only safe way is to recalculate the label at a trusted border. (Good luck doing that at 100 Gb/s.) So maybe mutability is in fact the only way to make it safe to use across domain boundaries? c) Declare the flow-label > is _immutable_ and must be set by all hosts and must only > contain a 3- or 5-tuple hash of the appropriate IPv6 headers. > Further use cases for the flow-label would be restricted. > IMHO, this would be by far the easiest from an implementation > and operational point-of-view, however this is unlikely to > appeal to proponents of domain-specific special-uses of > flow-labels, unfortunately. True, and it's also the current standard, which as far as I know is not being used. > > FWIW, related to the last point, (and as I'm sure you're well > aware of), I'd also add that we're well beyond the alpha and > beta stages of IPv6 deployment and well into mad deployment > phase of IPv6 to mitigate IPv4 address exhaustion. > Therefore, if a legitimate use of flow-labels has not been > found in the last 15 years of IPv6 development, it's time to > move on and use the flow-label for something useful and > practical in production networks, (i.e.: a hash of the 3- or > 5-tuple of L3 + L4 headers for LAG + ECMP load-balancing). Oh yes, we certainly need to enable that, but it doesn't need any change in the current standards. It's a product issue. Brian From terry.l.davis@boeing.com Thu Apr 22 09:06:43 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 385103A6A14; Thu, 22 Apr 2010 09:06:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.998 X-Spam-Level: X-Spam-Status: No, score=-4.998 tagged_above=-999 required=5 tests=[AWL=-1.601, BAYES_50=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_32=0.6, 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 IY0dG8F9KKf3; Thu, 22 Apr 2010 09:06:35 -0700 (PDT) Received: from slb-smtpout-01.boeing.com (slb-smtpout-01.boeing.com [130.76.64.48]) by core3.amsl.com (Postfix) with ESMTP id 9241D3A6972; Thu, 22 Apr 2010 09:06:35 -0700 (PDT) Received: from slb-av-01.boeing.com (slb-av-01.boeing.com [129.172.13.4]) by slb-smtpout-01.ns.cs.boeing.com (8.14.4/8.14.4/8.14.4/SMTPOUT) with ESMTP id o3MG61aI005225 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 22 Apr 2010 09:06:04 -0700 (PDT) Received: from slb-av-01.boeing.com (localhost [127.0.0.1]) by slb-av-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_RELAY) with ESMTP id o3MG61sP001526; Thu, 22 Apr 2010 09:06:01 -0700 (PDT) Received: from XCH-NWHT-01.nw.nos.boeing.com (xch-nwht-01.nw.nos.boeing.com [130.247.70.222]) by slb-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id o3MG60JV001515 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Thu, 22 Apr 2010 09:06:01 -0700 (PDT) Received: from XCH-NW-05V.nw.nos.boeing.com ([130.247.25.217]) by XCH-NWHT-01.nw.nos.boeing.com ([130.247.70.222]) with mapi; Thu, 22 Apr 2010 09:06:00 -0700 From: "Davis, Terry L" To: "'Latif LADID (\"The New Internet based on IPv6\")'" , "'Frankel, Sheila E.'" , "ipsec@ietf.org" , "ipv6@ietf.org" Date: Thu, 22 Apr 2010 09:05:59 -0700 Subject: RE: [Nav6tf] Announcing the USGv6 Testing Meeting at NIST Thread-Topic: [Nav6tf] Announcing the USGv6 Testing Meeting at NIST Thread-Index: Acrgnico98ik2GHIRGmPrMP7EVsXWAAsi+sgADTzSyAAArx+YA== Message-ID: <0267B5481DCC474D8088BF4A25C7F1DF5516235A2A@XCH-NW-05V.nw.nos.boeing.com> References: <020601cae224$9ab391c0$d01ab540$@lu> In-Reply-To: <020601cae224$9ab391c0$d01ab540$@lu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_0267B5481DCC474D8088BF4A25C7F1DF5516235A2AXCHNW05Vnwnos_" MIME-Version: 1.0 X-Mailman-Approved-At: Thu, 22 Apr 2010 14:53:55 -0700 Cc: "Whitlock, Stephen" , "ipv6ready-tech@ipv6ready.org" , "nav6tf@ipv6forum.com" , "'tim.polk@nist.gov'" 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, 22 Apr 2010 16:06:43 -0000 --_000_0267B5481DCC474D8088BF4A25C7F1DF5516235A2AXCHNW05Vnwnos_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Sheila Like Latif said, THANK YOU! As you know from the Seattle meeting with aviation industry representatives= and the vendor community last fall, the Internet security protocols' inter= operability is a key lynchpin in being able to ensure that the next generat= ion of Internet enabled aircraft can establish secure communications in the= global aviation environment. Aviation continues to be concerned that curr= ent IPv4 versions of IPsec, IKE, and IKEv2 still have vendor-to-vendor com= patibility issues that would be difficult for us to overcome in a fully het= erogeneous global environment. In our environment, an aircraft is continua= lly making and breaking security associations between different service pro= viders and air traffic management entities as it transverses from country t= o country and continent to continent. Thus our environment requires a very= high degree of confidence in the ability of our systems to dynamically re-= establish secure links with these new entities. We would encourage that interoperability testing fully include versions of = IPSec, IKE, and IKEv2 to ensure these issues do not continue with IPv6 on w= hich the next generations of global air traffic management will reply on (I= CAO Document 9896). The testing ideally should demonstrate a vendor's syst= em's ability to establish links with other vendors systems with minimal tim= e and effort for setup and link customization as the ease-of-use and ease-o= f-deployment will be critical for a global aviation infrastructure. Unfortunately I will be unable to attend as I will in ICAO meetings that we= ek, part of which will focus on these same issues. Take care Terry L Davis, P.E Boeing Technical Fellow Aircraft Network and Security, Architecture & Strategy Engineering Core - Avionics Boeing Commercial Airplanes Phone: 206-280-3716 Email: Terry.L.Davis@Boeing.com PS: It would also seem likely that the other CI sectors would have similar= IPv6 security interoperability needs. > -----Original Message----- > From: nav6tf-bounces@ipv6forum.com > [mailto:nav6tf-bounces@ipv6forum.com] On Behalf Of Latif > LADID ("The New Internet based on IPv6") > Sent: Thursday, April 22, 2010 7:04 AM > To: 'Frankel, Sheila E.'; IPSec@ietf.org; ipv6@ietf.org > Cc: ipv6ready-tech@ipv6ready.org; nav6tf@ipv6forum.com > Subject: Re: [Nav6tf] Announcing the USGv6 Testing Meeting at NIST > > Thanks Sheila! Good to see you working on IPv6 so vigorously > recalling our > days of work on IPsec back in 99. > > I have Copied the North American v6 Task Force members and > the IPv6 Ready > logo program team. > > Cheers > Latif > > -----Original Message----- > From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On > Behalf Of > Frankel, Sheila E. > Sent: 21 April 2010 14:46 > To: ipsec@ietf.org; ipv6@ietf.org > Subject: Announcing the USGv6 Testing Meeting at NIST > > Announcing the USGv6 Testing Meeting at NIST. > > To be held on Thursday May 20th 2010 in the AML Conference Room, > Building 215 Room C103, from 9am till 5pm. > > Following publication of the USG Profile NIST has established > a testing > program to determine products' compliance to USGv6 > capabilities. There > are at present 2 accreditors and 2 accredited test > laboratories enrolled > in the program, with more test laboratories in consideration. > July 2010 > marks the date when USG Federal Agencies begin to make IT > acquisitions > using the USGv6 profile version 1.0. We wanted to host a > public meeting > to give: > - a review of how the testing program is operating. > - an opportunity for feedback from Stakeholders, including test > laboratories, product vendors and USG Agencies. > > Accordingly we seek discussion inputs to include: > - statements from accredited and prospective test laboratories. > - statements/questions and issues from Agencies and users. > - statements, questions and issues from USGv6 product vendors. > > Issues are expected to include: > - testing operations and interlaboratory comparisons. > - USGv6 capabilities and requirements. > - Suppliers Declaration of Conformity. > > There will also be some discussion of the forthcoming USGv6 profile > version 2. A full Agenda will be posted to signed up > attendees closer > to the day of the meeting. Due to room size limitations > there can be a > maximum of about 70 participants at this meeting, and attendance from > any one company may need to be limited. Reply to > usgv6-project@antd.nist.gov if you wish to participate, giving full > name, company affiliation, title, contact details and whether > you are a > U.S. citizen. Please also let us know if you have issues you wish to > present, with a maximum of 2 or 3 slides, and speaking time limited > depending on the response. > > For further information, please contact Stephen Nightingale > (night@nist.gov) > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > > _______________________________________________ > Nav6tf mailing list > Nav6tf@ipv6forum.com > http://lists.ipv6forum.com/mailman/listinfo/nav6tf > --_000_0267B5481DCC474D8088BF4A25C7F1DF5516235A2AXCHNW05Vnwnos_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Sheila

Like Latif said, THANK YOU!<= BR>
As=20 you know from the Seattle meeting with aviation industry representatives an= d the=20 vendor community last fall, the Internet security protocols' interoperabili= ty is=20 a key lynchpin in being able to ensure that the next generation of Internet= =20 enabled aircraft can establish secure communications in the global aviation= =20 environment.  Aviation continues to be concerned that current IPv4 ver= sions=20 of IPsec, IKE, and IKEv2 still have  vendor-to-vendor compatibility is= sues=20 that would be difficult for us to overcome in a fully heterogeneous global= =20 environment.  In our environment, an aircraft is continually maki= ng=20 and breaking security associations between different service providers and = air=20 traffic management entities as it transverses from country to country and=20 continent to continent.  Thus our environment requires a very hig= h=20 degree of confidence in the ability of our systems to dynamically re-establ= ish=20 secure links with these new entities.

We would encourage that=20 interoperability testing fully include versions of IPSec, IKE, and IKEv2 to= =20 ensure these issues do not continue with IPv6 on which the next generations= of=20 global air traffic management will reply on (ICAO Document 9896).  The= =20 testing ideally should demonstrate a vendor's system's ability to establish= =20 links with other vendors systems with minimal time and effort for setup and= link=20 customization as the ease-of-use and ease-of-deployment will be critical fo= r a=20 global aviation infrastructure.

Unfortunately I will be unable to attend a= s I=20 will in ICAO meetings that week, part of which will focus on these sam= e=20 issues.

Take=20 care

Terry L Davis= ,=20 P.E
Boeing Technical Fellow
<= /P>

Aircraft Netw= ork and=20 Security, Architecture & Strategy
Engineering Core –=20 Avionics
Boeing Commercial Airplanes

Phone: = =20 206-280-3716
Email:  =20 Terry.L.Davis@Boeing.com

PS:  It wo= uld also=20 seem likely that the other CI sectors would have similar IPv6 security=20 interoperability needs.




> -----Original=20 Message-----
> From: nav6tf-bounces@ipv6forum.com
> [mailto:nav6tf-bounces@ipv6foru= m.com]=20 On Behalf Of Latif
> LADID ("The New Internet based on IPv6")
>= =20 Sent: Thursday, April 22, 2010 7:04 AM
> To: 'Frankel, Sheila E.';=20 IPSec@ietf.org; ipv6@ietf.org
> Cc: ipv6ready-tech@ipv6ready.o= rg;=20 nav6tf@ipv6forum.com
> Subject: Re: [Nav6tf] Announcing the USGv6 Tes= ting=20 Meeting at NIST
>
> Thanks Sheila! Good to see you working on I= Pv6=20 so vigorously
> recalling our
> days of work on IPsec back in=20 99.
>
> I have Copied the North American v6 Task Force members= =20 and
> the IPv6 Ready
> logo program team.
>
>=20 Cheers
> Latif
>
> -----Original Message-----
> Fro= m:=20 ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On<= BR>>=20 Behalf Of
> Frankel, Sheila E.
> Sent: 21 April 2010 14:46
&= gt;=20 To: ipsec@ietf.org; ipv6@ietf.org
> Subject: Announcing the USGv6 Tes= ting=20 Meeting at NIST
>
> Announcing the USGv6 Testing Meeting at=20 NIST.
>
> To be held on Thursday May 20th 2010 in the AML Confe= rence=20 Room,
> Building 215 Room C103, from 9am till 5pm.
>
>=20 Following publication of the USG Profile NIST has established
> a=20 testing
> program to determine products' compliance to USGv6
>= =20 capabilities. There
> are at present 2 accreditors and 2 accredited=20 test
> laboratories enrolled
> in the program, with more test=20 laboratories in consideration.
>  July 2010
> marks the da= te=20 when USG Federal Agencies begin to make IT
> acquisitions
> usi= ng=20 the USGv6 profile version 1.0.  We wanted to host a
> public=20 meeting
> to give:
>     - a review of how = the=20 testing program is operating.
>     - an opportun= ity=20 for feedback from Stakeholders, including test
> laboratories, produc= t=20 vendors and USG Agencies.
>
> Accordingly we seek discussion in= puts=20 to include:
>     - statements from accredited an= d=20 prospective test laboratories.
>     -=20 statements/questions and issues from Agencies and=20 users.
>     - statements, questions and issues f= rom=20 USGv6 product vendors.
>
> Issues are expected to=20 include:
>     - testing operations and=20 interlaboratory comparisons.
>     - USGv6=20 capabilities and requirements.
>     - Suppliers= =20 Declaration of Conformity.
>
> There will also be some discussi= on of=20 the forthcoming USGv6 profile
> version 2.  A full Agenda will b= e=20 posted to signed up
> attendees closer
> to the day of the=20 meeting.  Due to room size limitations
> there can be a
>= =20 maximum of about 70 participants at this meeting, and attendance from
&g= t;=20 any one company may need to be limited. Reply to
>=20 usgv6-project@antd.nist.gov if you wish to participate, giving full
>= =20 name, company affiliation, title, contact details and whether
> you a= re=20 a
> U.S. citizen. Please also let us know if you have issues you wish= =20 to
> present, with a maximum of 2 or 3 slides, and speaking time=20 limited
> depending on the response.
>
> For further=20 information, please contact Stephen Nightingale
>=20 (night@nist.gov)
>
>
>=20 --------------------------------------------------------------------
>= ;=20 IETF IPv6 working group mailing list
> ipv6@ietf.org
>=20 Administrative Requests: https://www.ietf.org/ma= ilman/listinfo/ipv6
>=20 --------------------------------------------------------------------
>= ;
>=20 _______________________________________________
> Nav6tf mailing=20 list
> Nav6tf@ipv6forum.com
> http://lists.ip= v6forum.com/mailman/listinfo/nav6tf
>=20

--_000_0267B5481DCC474D8088BF4A25C7F1DF5516235A2AXCHNW05Vnwnos_-- From fred@cisco.com Thu Apr 22 15:11:07 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 665C03A6954 for ; Thu, 22 Apr 2010 15:11:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.954 X-Spam-Level: X-Spam-Status: No, score=-109.954 tagged_above=-999 required=5 tests=[AWL=0.645, 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 K7XLE1bT1CwU for ; Thu, 22 Apr 2010 15:11:04 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id 502993A68C8 for ; Thu, 22 Apr 2010 15:11:04 -0700 (PDT) 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: AvsEABxm0EurRN+K/2dsb2JhbACcKnGnEpo2glmCNgSDNA X-IronPort-AV: E=Sophos;i="4.52,259,1270425600"; d="scan'208";a="252007386" Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-2.cisco.com with ESMTP; 22 Apr 2010 22:10:54 +0000 Received: from stealth-10-32-244-222.cisco.com (stealth-10-32-244-222.cisco.com [10.32.244.222]) by sj-core-4.cisco.com (8.13.8/8.14.3) with ESMTP id o3MMAsn1003561; Thu, 22 Apr 2010 22:10:54 GMT Subject: Re: DRAFT: Request for guidance about the flow label Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii From: Fred Baker In-Reply-To: Date: Thu, 22 Apr 2010 15:10:53 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <4598F0D6-8C0C-4C1F-84CB-D7E4D75EEAE9@cisco.com> References: <4BCFBADA.8090901@gmail.com><0FEC3C33-071C-48C4-9BD8-91CF6357337 7@free.fr><2FC3BE87-AFDD-441F-8262-55049B6AFED1@castlepoint.net><1D69CC44-FA38-4D7D-A456-83D315B1F06B@free.fr> <545F3966-1BF8-41DC-91B3-6DB3D3C679B2@castlepoint.net> To: "Manfredi, Albert E" X-Mailer: Apple Mail (2.1078) Cc: 6man X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Apr 2010 22:11:08 -0000 personally, I would prefer to see it *mutable*, and undefined. Given = that there are many host implementations out there, I could imagine = difficulties getting any specific specification (such as a hash) widely = deployed in a finite amount of time. However, if a network could use it = to identify an egress or the path to an egress (or, using multiple = values per egress, sets of traffic headed to an egress) in a scalable = fashion, it might allow for load sharing among what would today be = non-sharable MPLS LSPs. On Apr 22, 2010, at 1:23 PM, Manfredi, Albert E wrote: >> -----Original Message----- >> From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On=20 >> Behalf Of Shane Amante >=20 >> c) Declare the flow-label is _immutable_ and must be set by=20 >> all hosts and must only contain a 3- or 5-tuple hash of the=20 >> appropriate IPv6 headers. Further use cases for the=20 >> flow-label would be restricted. IMHO, this would be by far=20 >> the easiest from an implementation and operational=20 >> point-of-view, however this is unlikely to appeal to=20 >> proponents of domain-specific special-uses of flow-labels,=20 >> unfortunately. =20 >=20 > Count me in. In following this thread, I've come to believe that this = is the best course of action. And it keeps the flow label immutable, as = originally prescribed. >=20 >> Therefore, if a legitimate use of flow-labels has not been=20 >> found in the last 15 years of IPv6 development, it's time to=20 >> move on and use the flow-label for something useful and=20 >> practical in production networks, (i.e.: a hash of the 3- or=20 >> 5-tuple of L3 + L4 headers for LAG + ECMP load-balancing). >=20 > Indeed. This becomes doable easily in IPv6, no matter the extension = headers. What better purpose could there be for this field? And it's = certainly NOT a stretch to think that the traditional 5-tuple was, in = fact, used to define what some might call a "flow." >=20 > Bert > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- http://www.ipinc.net/IPv4.GIF From fred@cisco.com Thu Apr 22 15:59:03 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 487633A685B for ; Thu, 22 Apr 2010 15:59:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.186 X-Spam-Level: X-Spam-Status: No, score=-110.186 tagged_above=-999 required=5 tests=[AWL=0.413, 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 6sB256xjULB2 for ; Thu, 22 Apr 2010 15:59:02 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 66B1C3A6853 for ; Thu, 22 Apr 2010 15:59:02 -0700 (PDT) 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: AvsEAFdx0EurR7Ht/2dsb2JhbACcKnGnIZo2hQ8EgzQ X-IronPort-AV: E=Sophos;i="4.52,259,1270425600"; d="scan'208";a="519213856" Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-6.cisco.com with ESMTP; 22 Apr 2010 22:58:52 +0000 Received: from stealth-10-32-244-222.cisco.com (stealth-10-32-244-222.cisco.com [10.32.244.222]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o3MMwqEM004409; Thu, 22 Apr 2010 22:58:52 GMT Subject: Re: DRAFT: Request for guidance about the flow label Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii From: Fred Baker In-Reply-To: <4BD0C25B.6010004@gmail.com> Date: Thu, 22 Apr 2010 15:58:51 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <464DBB25-C7F5-4838-BDF1-10DE7E9B19FF@cisco.com> References: <4BCFBADA.8090901@gmail.com> <0FEC3C33-071C-48C4-9BD8-91CF63573377@free.fr> <2FC3BE87-AFDD-441F-8262-55049B6AFED1@castlepoint.net> <1D69CC44-FA38-4D7D-A456-83D315B1F06B@free.fr> <545F3966-1BF8-41DC-91B3-6DB3D3C679B2@castlepoint.net> <4BD0C25B.6010004@gmail.com> To: Brian E Carpenter X-Mailer: Apple Mail (2.1078) Cc: 6man X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Apr 2010 22:59:03 -0000 On Apr 22, 2010, at 2:40 PM, Brian E Carpenter wrote: > However, consider that the flow label is a forgeable field, not > protected by any checksum (including IPSEC).=20 > So maybe mutability is in fact the only way to make it safe to > use across domain boundaries? Interesting. I had it in my head that AH protected it. Mutability, to me, is a good thing. It means that an ISP can use it, as = suggested, to carry a load balancing hash, or an egress identifier. Or = for that matter an ingress identifier for tracing purposes. I'll have to = think about the implications of that. http://www.ipinc.net/IPv4.GIF From jmh@joelhalpern.com Thu Apr 22 18:57:47 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 0B0C33A67AD for ; Thu, 22 Apr 2010 18:57:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.155 X-Spam-Level: X-Spam-Status: No, score=-2.155 tagged_above=-999 required=5 tests=[AWL=0.444, 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 kRcFf2HYIsbw for ; Thu, 22 Apr 2010 18:57:46 -0700 (PDT) Received: from hgblob.mail.tigertech.net (hgblob.mail.tigertech.net [64.62.209.71]) by core3.amsl.com (Postfix) with ESMTP id 4EFA13A676A for ; Thu, 22 Apr 2010 18:57:46 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hgblob.tigertech.net (Postfix) with ESMTP id 9EA0132358AD; Thu, 22 Apr 2010 18:57:36 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from [10.10.10.102] (pool-71-161-51-173.clppva.btas.verizon.net [71.161.51.173]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hgblob.tigertech.net (Postfix) with ESMTPSA id E4E7C3235875; Thu, 22 Apr 2010 18:57:35 -0700 (PDT) Message-ID: <4BD0FE8E.8000007@joelhalpern.com> Date: Thu, 22 Apr 2010 21:57:34 -0400 From: "Joel M. Halpern" User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Fred Baker Subject: Re: DRAFT: Request for guidance about the flow label References: <4BCFBADA.8090901@gmail.com> <0FEC3C33-071C-48C4-9BD8-91CF63573377@free.fr> <2FC3BE87-AFDD-441F-8262-55049B6AFED1@castlepoint.net> <1D69CC44-FA38-4D7D-A456-83D315B1F06B@free.fr> <545F3966-1BF8-41DC-91B3-6DB3D3C679B2@castlepoint.net> <4BD0C25B.6010004@gmail.com> <464DBB25-C7F5-4838-BDF1-10DE7E9B19FF@cisco.com> In-Reply-To: <464DBB25-C7F5-4838-BDF1-10DE7E9B19FF@cisco.com> 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: Fri, 23 Apr 2010 01:57:47 -0000 The problem for me is that if it is arbitrarily mutable, then we can not use the flow label in a reliable and useful fashion in the ECMP / LAG. After all, if it is arbitrarily mutable some ISP might set it to 0xFACE because that was useful to them without regard to specific flows. I would really like to be able to move towards a regime in which the flow label is useful for ECMP/LAG, and is actually used, as that resolves a number of awkward cases. yours, Joel Fred Baker wrote: > On Apr 22, 2010, at 2:40 PM, Brian E Carpenter wrote: > >> However, consider that the flow label is a forgeable field, not >> protected by any checksum (including IPSEC). > >> So maybe mutability is in fact the only way to make it safe to >> use across domain boundaries? > > Interesting. I had it in my head that AH protected it. > > Mutability, to me, is a good thing. It means that an ISP can use it, as suggested, to carry a load balancing hash, or an egress identifier. Or for that matter an ingress identifier for tracing purposes. I'll have to think about the implications of that. > > http://www.ipinc.net/IPv4.GIF > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > From fred@cisco.com Thu Apr 22 22:26:21 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 AF1A73A6973 for ; Thu, 22 Apr 2010 22:26:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.202 X-Spam-Level: X-Spam-Status: No, score=-110.202 tagged_above=-999 required=5 tests=[AWL=0.397, 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 8ZVtwIxHbZ+A for ; Thu, 22 Apr 2010 22:26:19 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id E6FB03A6983 for ; Thu, 22 Apr 2010 22:23:29 -0700 (PDT) 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: AvsEAJPL0EurR7H+/2dsb2JhbACcLHGkbpothQ8EgzU X-IronPort-AV: E=Sophos;i="4.52,260,1270425600"; d="scan'208";a="187213938" Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-5.cisco.com with ESMTP; 23 Apr 2010 05:21:49 +0000 Received: from stealth-10-32-244-222.cisco.com (stealth-10-32-244-222.cisco.com [10.32.244.222]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o3N5LmQs017565; Fri, 23 Apr 2010 05:21:48 GMT Subject: Re: DRAFT: Request for guidance about the flow label Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii From: Fred Baker In-Reply-To: <4BD0FE8E.8000007@joelhalpern.com> Date: Thu, 22 Apr 2010 22:21:48 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <7C8549E5-5807-433F-B9BD-A3AE6BDFC182@cisco.com> References: <4BCFBADA.8090901@gmail.com> <0FEC3C33-071C-48C4-9BD8-91CF63573377@free.fr> <2FC3BE87-AFDD-441F-8262-55049B6AFED1@castlepoint.net> <1D69CC44-FA38-4D7D-A456-83D315B1F06B@free.fr> <545F3966-1BF8-41DC-91B3-6DB3D3C679B2@castlepoint.net> <4BD0C25B.6010004@gmail.com> <464DBB25-C7F5-4838-BDF1-10DE7E9B19FF@cisco.com> <4BD0FE8E.8000007@joelhalpern.com> To: "Joel M. Halpern" X-Mailer: Apple Mail (2.1078) 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: Fri, 23 Apr 2010 05:26:21 -0000 It is already mutable, as it turns out. It always was. On Apr 22, 2010, at 6:57 PM, Joel M. Halpern wrote: > The problem for me is that if it is arbitrarily mutable, then we can = not use the flow label in a reliable and useful fashion in the ECMP / = LAG. After all, if it is arbitrarily mutable some ISP might set it to = 0xFACE because that was useful to them without regard to specific flows. > I would really like to be able to move towards a regime in which the = flow label is useful for ECMP/LAG, and is actually used, as that = resolves a number of awkward cases. >=20 > yours, > Joel >=20 > Fred Baker wrote: >> On Apr 22, 2010, at 2:40 PM, Brian E Carpenter wrote: >>> However, consider that the flow label is a forgeable field, not >>> protected by any checksum (including IPSEC).=20 >>> So maybe mutability is in fact the only way to make it safe to >>> use across domain boundaries? >> Interesting. I had it in my head that AH protected it. >> Mutability, to me, is a good thing. It means that an ISP can use it, = as suggested, to carry a load balancing hash, or an egress identifier. = Or for that matter an ingress identifier for tracing purposes. I'll have = to think about the implications of that. >> http://www.ipinc.net/IPv4.GIF >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list >> ipv6@ietf.org >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- http://www.ipinc.net/IPv4.GIF From niviya.vijayan.t@gmail.com Thu Apr 22 23:35:39 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 6EB873A67AD for ; Thu, 22 Apr 2010 23:35:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=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 xnG8DFrdDbf8 for ; Thu, 22 Apr 2010 23:35:38 -0700 (PDT) Received: from mail-pv0-f172.google.com (mail-pv0-f172.google.com [74.125.83.172]) by core3.amsl.com (Postfix) with ESMTP id 7F2EA3A68ED for ; Thu, 22 Apr 2010 23:35:21 -0700 (PDT) Received: by pvg7 with SMTP id 7so1899195pvg.31 for ; Thu, 22 Apr 2010 23:35:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:received:message-id:subject:from:to:cc:content-type; bh=jgFhgqUQxej7AKPY2G5BYCmPPuYHokJzDkiBkaF7HIc=; b=awEioW4oDyT859cfGeF2pcu1oi49Bzds+PFdbQEuJ5mi/wQXcbn0CTHguUC3B/y7tk ExOqzcH7xxOcvuAEBj5+8WY47m0NcPbhaTM1KxOeG1M3nNZg7Plgkn2g7a4pOkJQ+c+K WvzCPSCuFjnjgIA+OSYSZlYAwKdoIVqv0bvxY= 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=FbumEvf+LDhQXSHCUbhpKovlH1wkA/lfmhVZUFJ/IO6i2GQ3+MjvO8neLFO425Kv8W vvx0aV8RLT3I7s99RzomRtvLjpxwWqSRPL9uX9m2gksRKvcLsQv729wkpv7yZC5Y+dam J+sf4DV9BecGEv0WK1csm4+KFE4mot0tLlk1M= MIME-Version: 1.0 Received: by 10.142.218.16 with HTTP; Thu, 22 Apr 2010 23:35:07 -0700 (PDT) In-Reply-To: References: <4BC87E3E.80504@ericsson.com> <4BCE3045.9030205@ericsson.com> Date: Fri, 23 Apr 2010 12:05:07 +0530 Received: by 10.143.194.3 with SMTP id w3mr2265848wfp.308.1272004508421; Thu, 22 Apr 2010 23:35:08 -0700 (PDT) Message-ID: Subject: Re: RFC 4861:-Link-Local address joining all-node multicast group. From: niviya vijayan To: "JOSHI, SHRINIVAS ASHOK (SHRINIVAS ASHOK)" Content-Type: multipart/alternative; boundary=000e0cd482c4e08ea40484e1a0e9 X-Mailman-Approved-At: Fri, 23 Apr 2010 02:17:33 -0700 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: Fri, 23 Apr 2010 06:35:39 -0000 --000e0cd482c4e08ea40484e1a0e9 Content-Type: text/plain; charset=ISO-8859-1 Hi Shree, On Wed, Apr 21, 2010 at 4:31 PM, JOSHI, SHRINIVAS ASHOK (SHRINIVAS ASHOK) < shrinivas_ashok.joshi@alcatel-lucent.com> wrote: > Niviya, > > > >> "When a multicast-capable interface becomes enabled, the node MUST join > the all-nodes multicast address on that interface, as well as the solicited- > >> node multicast address corresponding to each of the IP addresses > assigned to the interface." > >> Any idea What does this statement mean? > > [Shree] If the hosts on link are connected through a multicast aware device > (e.g. switch with MLD proxy), > these messages are intended to inform the switch that host is interested > in receiving packets destined > to all -nodes and solicited node multicast address. > > Can u please tell me what protocol it will use ? Will it be a MLD > report with destination "all-node multicast address"? If it is yes, As per > RFC3810, MLD report should not use for joining into all node multicast > address.? > > >> Why the node is sending unsolicited NA message ( with source as > "link-local address" & destination as "all-node multicast address"). > >> I am expecting only one unsolicited NA message( with source as "ipv6 > global address" & destination as "all-node multicast address"). > >> I am not at all changing the link-local address and the link-local > address is already active on the interface. > > > [Shree] If you are assigning an address the node should send out Neighbor > solicitation > as part of Duplicate Address Detection(source as unspecified address and > destination as solicited node multicast address). > > What will happen if I didnt enable DAD ? > From what you are seeing it looks like link layer address is getting > changed, one way to verify it is through the override flag and source link > layer address option > n unsolicited neighbor advertisement. Before and after you apply the ipv6 > address. > > Override flag is set and source link-layer address remains the same:- > -- > Shree > > > From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of > niviya vijayan > Sent: Wednesday, April 21, 2010 10:59 AM > To: Suresh Krishnan > Cc: ipv6@ietf.org > Subject: Re: RFC 4861:-Link-Local address joining all-node multicast group. > > Hi Suresh, > > RFC 4861 Statement:- 7.2.1.Interface Initialization > > "When a multicast-capable interface becomes enabled, the node MUST join the > all-nodes multicast address on that interface, as well as the solicited- > node multicast address corresponding to each of the IP addresses assigned > to the interface." > Any idea What does this statement mean? > > For the second query:- > > I didnt change the MAC address of the card. I tried creating a new ipv6 > address on the interface and I have seen these two unsolicited NA > messages.My question is , Why the node is sending unsolicited NA message ( > with source as "link-local address" & destination as "all-node multicast > address").I am expecting only one unsolicited NA message( with source as > "ipv6 global address" & destination as "all-node multicast address"). I am > not at all changing the link-local address and the link-local address is > already active on the interface. > > Regards, > Niviya > > > On Wed, Apr 21, 2010 at 4:22 AM, Suresh Krishnan < > suresh.krishnan@ericsson.com> wrote: > Hi Niviya, > > > On 10-04-20 05:09 AM, niviya vijayan wrote: > Hi Suresh, > Thanks for your reply. I have a doubt on your answer. > As per your comments, there can be two MLD report msg which will join the > node in solicited multicast group . But in the RFC 4861, they have mention > there should be a join request to all node multicast group. > > As described in section 6 of RFC3810 MLD reports are not sent for the > all-nodes multicast address > > " The link-scope all-nodes multicast address, (FF02::1), is handled as > a special case. On all nodes -- that is all hosts and routers, > including multicast routers -- listening to packets destined to the > all-nodes multicast address, from all sources, is permanently enabled > on all interfaces on which multicast listening is supported. No MLD > messages are ever sent regarding neither the link-scope all-nodes > multicast address, nor any multicast address of scope 0 (reserved) or > 1 (node-local)." > > . > > RFC 4861 Statement:- 7.2.1.Interface Initialization > > "When a multicast-capable interface becomes enabled, the node MUST join the > all-nodes multicast address on that interface, as well as the solicited- > node multicast address corresponding to each of the IP addresses assigned > to the interface." > > I have one more query regarding NA messages. > While creating ipv6 address on an interface, unsolicited NA messages will > be sent to all node multicast address to inform all other nodes in the > network. When i tried this scenario , I have seen two NA messages. > 1) source as ipv6 address and destination as ipv6 all node address. > 2) source as link-local address and destination as ipv6 all node address. > My question is, whenever there is a change in ipv6 address on a node, both > these 2 NA messages will propogate through the network? > or is it really required to share about the link-local address as we are > not at all changing the ipv6 link-local address.? > > It is unclear what the circumstances are. Specifically, what action did you > perform that resulted in these messages? Did you change the MAC address of > the card? > > Hi Suresh, > > I didnt change the MAC address of the card. I tried creating a new ipv6 > address on the interface and I have seen these two unsolicited NA > messages.My question is , Why the node is sending unsolicited NA message ( > with source as "link-local address" & destination as "all-node multicast > address").I am expecting only one unsolicited NA message( with source as > "ipv6 global address" & destination as "all-node multicast address"). I am > not at all changing the link-local address and the link-local address is > already active on the interface. > > Cheers > Suresh > > > > --000e0cd482c4e08ea40484e1a0e9 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Shree,

On Wed, Apr 21, 2010 at 4:31 PM, JOSHI, SHRINIVA= S ASHOK (SHRINIVAS ASHOK) <shrinivas_ashok.joshi@alcatel-lucent.com> wrote:
Niviya,


>> "When a multicast-capable interface= becomes enabled, the node MUST join the all-nodes multicast address on tha= t interface, as well as the solicited-
>> node multicast address c= orresponding to each of the IP addresses assigned to the interface." >> Any idea What does this statement mean?

[Shree] If th= e hosts on link are connected through a multicast aware device (e.g. switch= with MLD proxy),
these messages are intended to =A0inform the switch th= at host is interested in receiving packets destined
to all -nodes and solicited node multicast address.

Can u= please tell me what protocol it will use=A0? Will it be a MLD report=A0=A0= with destination "all-node multicast address"?=A0If it is yes, As= per RFC3810, MLD report should not use for joining into all node multicast= address.?
=A0
=A0
>> Why the node is sending unsolicited NA message (= with source as "link-local address" & destination as "a= ll-node multicast address").
>> I am expecting only one unsol= icited NA message( with source as "ipv6 global address" & des= tination as "all-node multicast address").
>> I am not at all changing the link-local address and the link-local= address is already active on the interface.


[Shree] If yo= u are assigning an address the node should send out Neighbor solicitation =A0as part of Duplicate Address Detection(source as unspecified address and= destination as solicited node multicast address).

What will happen if I=A0didnt enable DAD ?
=A0
From what you are seeing it look= s like link layer address is getting changed, one way to verify it is throu= gh the override flag and source link layer address option
n unsolicited neighbor advertisement. Before and after you apply the ipv6 a= ddress.

Override flag is set and source link-layer add= ress remains the same:-
--
Shree


From:
ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of niviya vijayan
Sent: Wednesday, April 21, 2010 10:59 AM
To: Suresh Krishnan
Cc: ipv6@ietf.org
Subject: Re: RFC 4861:-Link-Local address joining a= ll-node multicast group.

Hi Suresh,
=A0
RFC 4861 Statement:- 7.2.1.Interface= Initialization

"When a multicast-capable interface becomes ena= bled, the node MUST join the all-nodes multicast address on that interface,= as well as the solicited- =A0 =A0node multicast address corresponding to e= ach of the IP addresses assigned to the interface."
Any idea What does this statement mean?
=A0
For the second query:-=A0
I didnt change the MAC address of the card. I tried creating a new = ipv6 address on the interface and I have seen these two unsolicited NA mess= ages.My question is , Why the node is sending unsolicited NA message ( with= source as "link-local address" & destination as "all-no= de multicast address").I am expecting only one unsolicited NA message(= with source as "ipv6 global address" & destination as "= all-node multicast address").=A0=A0I am not at all changing the link-l= ocal address and the link-local address is already active on the interface.= =A0
=A0
Regards,
Niviya

=A0
On Wed, Apr 21, 2010 at 4:22 AM, Su= resh Krishnan <suresh.kr= ishnan@ericsson.com> wrote:
Hi Niviya,


On 10-04-20 05:= 09 AM, niviya vijayan wrote:
Hi Suresh,
=A0Thanks for your reply. I have a doubt on your answer.
= =A0As per your comments, there can be two MLD report msg which will join th= e node in solicited multicast group . But in the RFC 4861, they have mentio= n there should be a join request to all node multicast group.

As described in section 6 of RFC3810 MLD reports are not sent for the a= ll-nodes multicast address

" =A0The link-scope all-nodes multic= ast address, (FF02::1), is handled as
=A0 a special case. =A0On all node= s -- that is all hosts and routers,
=A0 including multicast routers -- listening to packets destined to the
= =A0 all-nodes multicast address, from all sources, is permanently enabled=A0 on all interfaces on which multicast listening is supported. =A0No ML= D
=A0 messages are ever sent regarding neither the link-scope all-nodes
= =A0 multicast address, nor any multicast address of scope 0 (reserved) or=A0 1 (node-local)."

.
=A0
RFC 4861 Statement:- 7.2.1.I= nterface Initialization

"When a multicast-capable interface becomes enabled, the node MUST= join the all-nodes multicast address on that interface, as well as the sol= icited- =A0 =A0node multicast address corresponding to each of the IP addre= sses assigned to the interface."

=A0 I have one more query =A0regarding NA messages.
=A0While creatin= g ipv6 address on an interface, unsolicited NA messages will be sent to all= node multicast address to inform all other nodes in the network. When i tr= ied this scenario , I have seen two NA messages.
=A01) source as ipv6 address and destination as ipv6 all node address.
2= ) source as link-local address and destination as ipv6 all node address.=A0My question is, whenever there is a change in ipv6 address on a node, b= oth these 2 NA messages will propogate through the network?
or is it really required to share about the link-local address as we are no= t at all changing the ipv6 link-local address.?

It is unclear what t= he circumstances are. Specifically, what action did you perform that result= ed in these messages? Did you change the MAC address of the card?
=A0
Hi Suresh,
=A0
I didnt change the MAC address of the card. I t= ried creating a new ipv6 address on the interface and I have seen these two= unsolicited NA messages.My question is , Why the node is sending unsolicit= ed NA message ( with source as "link-local address" & destina= tion as "all-node multicast address").I am expecting only one uns= olicited NA message( with source as "ipv6 global address" & d= estination as "all-node multicast address").=A0=A0I am not at all= changing the link-local address and the link-local address is already acti= ve on the interface.=A0

Cheers
Suresh




--000e0cd482c4e08ea40484e1a0e9-- From fw@deneb.enyo.de Fri Apr 23 04:59:27 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 B64AD3A6D65 for ; Fri, 23 Apr 2010 04:59:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.118 X-Spam-Level: X-Spam-Status: No, score=0.118 tagged_above=-999 required=5 tests=[AWL=-0.233, BAYES_50=0.001, HELO_EQ_DE=0.35] 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 ou9vH1P+qx1x for ; Fri, 23 Apr 2010 04:59:24 -0700 (PDT) Received: from ka.mail.enyo.de (ka.mail.enyo.de [87.106.162.201]) by core3.amsl.com (Postfix) with ESMTP id 84ACA28C251 for ; Fri, 23 Apr 2010 04:28:42 -0700 (PDT) Received: from [172.17.135.4] (helo=deneb.enyo.de) by ka.mail.enyo.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) id 1O5H3a-0006av-Mq; Fri, 23 Apr 2010 13:28:26 +0200 Received: from fw by deneb.enyo.de with local (Exim 4.71) (envelope-from ) id 1O5H3a-00046o-GQ; Fri, 23 Apr 2010 13:28:26 +0200 From: Florian Weimer To: Brian E Carpenter Subject: Re: Extracting the 5-tuple from IPv6 packets References: <4BC64100.303@gmail.com> Date: Fri, 23 Apr 2010 13:28:26 +0200 In-Reply-To: <4BC64100.303@gmail.com> (Brian E. Carpenter's message of "Thu, 15 Apr 2010 10:26:08 +1200") Message-ID: <87k4ry1k85.fsf@mid.deneb.enyo.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Nevil Brownlee , 6man X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Apr 2010 11:59:27 -0000 * Brian E. Carpenter: > Common practice in network monitoring and in QoS technologies > is to identify a flow of packets by the 5-tuple > {source address, dest address, source port, dest port, protocol #}. > This is relatively trivial at line speed in IPv4 since > these things are at fixed locations in the header. Only if you ignore IP options. Of course, IP options have been operationally deprecated and are typically not forwarded across the public Internet. > But in IPv6, the protocol number is at the end of a linked list of > "next headers." Even if the normal case is only one item in the > linked list, any implementation (hardware or software) that extracts > the 5-tuple has to follow the linked list to the end. As far as I can tell, all extension headers except fragmentation are deprecated, similar to IP options in IPv4 land. This should make extraction much simpler. > What do people think? >From today's perspective, the IPv6 header design is complete crap. Maybe it was optimized for software forwarding on in-order CPUs, but that's distant history now. From ipng@69706e6720323030352d30312d31340a.nosense.org Fri Apr 23 08:28:14 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 DBAB03A695E for ; Fri, 23 Apr 2010 08:28:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.556 X-Spam-Level: X-Spam-Status: No, score=-1.556 tagged_above=-999 required=5 tests=[AWL=0.339, 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 P1mR2oEPvG+m for ; Fri, 23 Apr 2010 08:28:14 -0700 (PDT) Received: from smtp2.adam.net.au (smtp2.adam.net.au [202.136.110.251]) by core3.amsl.com (Postfix) with ESMTP id 84AE63A68F8 for ; Fri, 23 Apr 2010 08:28:13 -0700 (PDT) Received: from 219-90-229-29.ip.adam.com.au ([219.90.229.29] helo=opy.nosense.org) by smtp2.adam.net.au with esmtp (Exim 4.63) (envelope-from ) id 1O5KnJ-00006N-3g; Sat, 24 Apr 2010 00:57:53 +0930 Received: from opy.nosense.org (localhost.localdomain [IPv6:::1]) by opy.nosense.org (Postfix) with ESMTP id 27B3349239; Sat, 24 Apr 2010 00:57:52 +0930 (CST) Date: Sat, 24 Apr 2010 00:57:52 +0930 From: Mark Smith To: "Manfredi, Albert E" Subject: Re: DRAFT: Request for guidance about the flow label Message-ID: <20100424005752.38f433a6@opy.nosense.org> In-Reply-To: References: <4BCFBADA.8090901@gmail.com> <0FEC3C33-071C-48C4-9BD8-91CF6357337 7@free.fr> <2FC3BE87-AFDD-441F-8262-55049B6AFED1@castlepoint.net> <1D69CC44-FA38-4D7D-A456-83D315B1F06B@free.fr> <545F3966-1BF8-41DC-91B3-6DB3D3C679B2@castlepoint.net> X-Mailer: Claws Mail 3.7.5 (GTK+ 2.20.0; x86_64-unknown-linux-gnu) X-Location: Lower Mitcham, South Australia, 5062 Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: 6man 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, 23 Apr 2010 15:28:15 -0000 On Thu, 22 Apr 2010 15:23:27 -0500 "Manfredi, Albert E" wrote: > > -----Original Message----- > > From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On > > Behalf Of Shane Amante > > > c) Declare the flow-label is _immutable_ and must be set by > > all hosts and must only contain a 3- or 5-tuple hash of the > > appropriate IPv6 headers. Further use cases for the > > flow-label would be restricted. IMHO, this would be by far > > the easiest from an implementation and operational > > point-of-view, however this is unlikely to appeal to > > proponents of domain-specific special-uses of flow-labels, > > unfortunately. > > Count me in. In following this thread, I've come to believe that this is the best course of action. And it keeps the flow label immutable, as originally prescribed. > There's the interesting question. If it was supposed to be end-to-end immutable, then it should have been covered by an end-to-end checksum, which in the case of IPv6 means a transport layer checksum, via a transport layer IPv6 pseudo-header. Even further, as the IPsec AH header doesn't cover it, then that means that not only isn't it protected against network faults, it also means it's integrity isn't ever assured from a 'proper' security perspective. Since it wasn't end-to-end protected, then I think that fundamentally indicates that it is mutable as it traverses the network. I think that therefore means that you can only trust it's value across a domain upon which you can trust the network's integrity, and I think that domain only corresponds to a network which you control and operate, or one that you are paying to use, with error-free service level agreements. And there's the interesting quandary. The attractive value of the flow label is that the only checksum that protects it is the layer 2 checksum (should there be one). Conversely, the fundamental problem with the flow label is that it isn't protected by a checksum, other than a layer 2 one. So it's not protected end-to-end, it isn't protected against layer 2 errors when layer 2 doesn't implement checksums, and it isn't protected against memory errors in routers, even when layer 2 has a checksum that protects it. In other words, similar to IPv6 packets themselves, the flow label fields is only a 'best effort' field, and can only be trusted within a domain that can be controlled, or one that the flow label serves the purpose of a hint, not a value to be absolutely relied upon. I think there is a fair amount value in the field (verses new extension headers that could be used for the same purpose), and I think there are a number of uses for it. We just need to be careful about uses which place absolute trust in it, outside domains where the trust in it's integrity can be assumed and assured. Regards, Mark. > > Therefore, if a legitimate use of flow-labels has not been > > found in the last 15 years of IPv6 development, it's time to > > move on and use the flow-label for something useful and > > practical in production networks, (i.e.: a hash of the 3- or > > 5-tuple of L3 + L4 headers for LAG + ECMP load-balancing). > > Indeed. This becomes doable easily in IPv6, no matter the extension headers. What better purpose could there be for this field? And it's certainly NOT a stretch to think that the traditional 5-tuple was, in fact, used to define what some might call a "flow." > > Bert > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From jeanmichel.combes@gmail.com Fri Apr 23 10:25:38 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 C289C3A6914 for ; Fri, 23 Apr 2010 10:25:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.822 X-Spam-Level: X-Spam-Status: No, score=-1.822 tagged_above=-999 required=5 tests=[AWL=0.777, 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 H4eVb69AdiLh for ; Fri, 23 Apr 2010 10:25:37 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by core3.amsl.com (Postfix) with ESMTP id 89E853A6907 for ; Fri, 23 Apr 2010 10:25:37 -0700 (PDT) Received: by wwb24 with SMTP id 24so2199175wwb.31 for ; Fri, 23 Apr 2010 10:25:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=6BCEOL3E76yfPiOg7AgcDHrDPC5xJbDKyB74tVojd60=; b=AVlGke9SVjZNsw05MC54UvoHGNKwFUOPhe+50yAcYx3lB1j9wxp3ru1em1pZ1RrUFr 7pdkl0MWsIJ6naB0kZieoXZ8kBrKcUAqTfLNBT4j6BGnYRDk7+c/TIjCDjx9L3Gnm7kh ZdKbaTLCPEb0N7uTo9sZ3SW8WbJ+g2c+7o9eY= 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=nhjaGJjs+cOR/k9z9l97hydGdWJ7itxKGcuObpf0Gf4Z2haJv8E7NpmfWaGaUVeNzs w1Eos6Hu1fnwiPrHyt7N/qNoJygb4y56h+AHu8rWqS+P/8iOqjYsi1v/xCHvhHtW52XM rMN4PfHR9SUjRf7e26C2aFS1zw9XL34nb7Dns= MIME-Version: 1.0 Received: by 10.216.90.206 with SMTP id e56mr471813wef.167.1272043522725; Fri, 23 Apr 2010 10:25:22 -0700 (PDT) Received: by 10.216.186.4 with HTTP; Fri, 23 Apr 2010 10:25:22 -0700 (PDT) In-Reply-To: References: Date: Fri, 23 Apr 2010 19:25:22 +0200 Message-ID: Subject: Re: RFC 4862 - Clarification question on DAD procedure From: Jean-Michel Combes To: =?ISO-2022-JP?B?SklOTUVJIFRhdHV5YSAvIBskQj9ATEBDIzpIGyhC?= Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Apr 2010 17:25:38 -0000 Hi, 2010/4/22 JINMEI Tatuya / $B?@L@C#:H(B : > At Thu, 22 Apr 2010 17:22:26 +0200, > Jean-Michel Combes wrote: > >> 5.4.3. Receiving Neighbor Solicitation Messages >> >> [snip] >> >> If the source address of the Neighbor Solicitation is the unspecified >> address, the solicitation is from a node performing Duplicate Address >> Detection. If the solicitation is from another node, the tentative >> address is a duplicate and should not be used (by either node). >> >> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >> >> But I must admit I don't see how the another node would be aware of >> the tentative address is a duplicate. >> Indeed, as the first node has to stop DAD after the another node's NS >> message reception, this first node should not send new NS messages >> with the same tentative address and so the another node should >> validate this address ... > > I suspect the intended scenario was that nodes A and B simultaneously > start DAD and send out their NSes (probably after some random delays) > almost at the same time so that both nodes see the other NSes while > still performing DAD: > > 1. node A starts DAD, waiting some random period > 2. node B starts DAD, waiting some random period > 3. node A sends out a DAD NS, waiting 1sec > 4. node B sends out a DAD NS (before receiving and handling A's NS), > waiting 1sec > 5. node B receives A's NS, detect duplicate > 6. node A receives B's NS, detect duplicate > > Of course, this could also go like this: > > 1. node A starts DAD, waiting some random period > 2. node B starts DAD, waiting some random period > 3. node A sends out a DAD NS, waiting 1sec > 4. node B receives A's NS, detect duplicate (before the waiting period > expires, so there's no NS from B) > > In this case, yes, A will keep using the address. Remember, DAD is > not a 100% reliable protocol, and in some cases it can result in a > suboptimal state. But in this specific case, the result is not as bad > as the case where two or more nodes keep using a duplicate address > (e.g., due to DAD NSes being dropped); at least one of the conflicting > nodes can detect the duplicate. OK. I see now. Thanks a lot for the clarification! Best regards. JMC. > > --- > JINMEI, Tatuya > Internet Systems Consortium, Inc. > From brett@broadsoft.com Sun Apr 25 12:45:05 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 567D03A681D for ; Sun, 25 Apr 2010 12:45:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.199 X-Spam-Level: X-Spam-Status: No, score=-1.199 tagged_above=-999 required=5 tests=[AWL=-1.200, BAYES_50=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 QThAiE60bJ79 for ; Sun, 25 Apr 2010 12:45:04 -0700 (PDT) Received: from smtp-out01.seaservers.net (smtp-out01.seaservers.net [72.37.232.66]) by core3.amsl.com (Postfix) with ESMTP id A82413A659A for ; Sun, 25 Apr 2010 12:45:04 -0700 (PDT) Received: from EXMBXCLUS01.citservers.local ([fe80:0000:0000:0000:a488:d1ec:167.6.58.109]) by casumhub01.citservers.local ([172.16.98.57]) with mapi; Sun, 25 Apr 2010 12:44:53 -0700 From: Brett Tate To: "ipv6@ietf.org" Date: Sun, 25 Apr 2010 12:44:00 -0700 Subject: Draft-ietf-6man-text-addr-representation: usage of "::" Thread-Topic: Draft-ietf-6man-text-addr-representation: usage of "::" Thread-Index: Acrkr6bKHYsIRyiJRA6u7xib4nE0SQ== Message-ID: <747A6506A991724FB09B129B79D5FEB61481012590@EXMBXCLUS01.citservers.local> 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-Mailman-Approved-At: Sun, 25 Apr 2010 15:30:25 -0700 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, 25 Apr 2010 19:45:05 -0000 The following is indicated within draft-ietf-6man-text-addr-representation-= 07 section 4.2.1 Shorten As Much As Possible. "The use of symbol "::" MUST be used to its maximum capability. For exampl= e, 2001:db8::0:1 is not acceptable, because the symbol "::" could have been= used to produce a shorter representation 2001:db8::1." Concerning "::" usage, is the requirement that=20 1) "::" MUST be used when valid, or=20 2) only that if used, it MUST be used to its maximum capability? Thanks, Brett From shane@castlepoint.net Sun Apr 25 15:39:00 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 BE0493A62C1 for ; Sun, 25 Apr 2010 15:39:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.972 X-Spam-Level: X-Spam-Status: No, score=-0.972 tagged_above=-999 required=5 tests=[AWL=-0.973, BAYES_50=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 f6GmvvwV4F8z for ; Sun, 25 Apr 2010 15:38:59 -0700 (PDT) Received: from dog.tcb.net (dog.tcb.net [64.78.150.133]) by core3.amsl.com (Postfix) with ESMTP id 5F7793A67C1 for ; Sun, 25 Apr 2010 15:38:59 -0700 (PDT) Received: by dog.tcb.net (Postfix, from userid 0) id BAD2F26866A; Sun, 25 Apr 2010 16:38:47 -0600 (MDT) Received: from mbpw.castlepoint.net (71-215-81-125.hlrn.qwest.net [71.215.81.125]) (authenticated-user smtp) (TLSv1/SSLv3 AES128-SHA 128/128) by dog.tcb.net with SMTP; Sun, 25 Apr 2010 16:38:47 -0600 (MDT) (envelope-from shane@castlepoint.net) X-Avenger: version=0.7.8; receiver=dog.tcb.net; client-ip=71.215.81.125; client-port=50196; syn-fingerprint=65535:56:1:64:M1452,N,W1,N,N,T,S; data-bytes=0 Subject: Re: DRAFT: Request for guidance about the flow label Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii From: Shane Amante In-Reply-To: <4BD0C25B.6010004@gmail.com> Date: Sun, 25 Apr 2010 16:38:31 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <919E6C80-57F2-425D-9B05-745D9F01C3A7@castlepoint.net> References: <4BCFBADA.8090901@gmail.com> <0FEC3C33-071C-48C4-9BD8-91CF63573377@free.fr> <2FC3BE87-AFDD-441F-8262-55049B6AFED1@castlepoint.net> <1D69CC44-FA38-4D7D-A456-83D315B1F06B@free.fr> <545F3966-1BF8-41DC-91B3-6DB3D3C679B2@castlepoint.net> <4BD0C25B.6010004@gmail.com> To: Brian E Carpenter X-Mailer: Apple Mail (2.1078) 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, 25 Apr 2010 22:39:01 -0000 Hi Brian, Apologies for the delay in responding. Snipping parts that I agree = with. On Apr 22, 2010, at 15:40 MDT, Brian E Carpenter wrote: > b) >> Declare that the flow-label is _mutable_ by each >> administrative domain. Therefore, I _MAY_ not trust an >> incoming IPv6 flow-label from another administrative domain. >> However, in thinking about this a bit more, this has problems >> of it's own, namely: a) the dependency of intermediate >> routers to (re)calculate a "good" flow-label based off the 3- >> or 5-tuple in the IPv6 header (possible, but not guaranteed); >> and, b) it could unintentionally overwrite "good" >> flow-labels, particularly those of inter-domain IP-in-IPv6 >> tunnels (cf: draft-carpenter-flow-ecmp), where the outer IPv6 >> header may have a "good" flow-label based on the inner IP >> header's 5-tuple -- which is bad.=20 >=20 > However, consider that the flow label is a forgeable field, not > protected by any checksum (including IPSEC). So you can't trust > it and an attacker could always attack your ECMP or LAG by > giving all packets the same label. It may be that the only safe > way is to recalculate the label at a trusted border. (Good luck > doing that at 100 Gb/s.) >=20 > So maybe mutability is in fact the only way to make it safe to > use across domain boundaries? That seems like a reasonable conclusion. Given the packet inspection = capabilities on most newer PE devices have to be pretty good, (in order = to perform the usual classification on, say, the 5-tuple to either = forward/drop the packet for security reasons or to set/reset the IP = Traffic Class field), it doesn't seem too unreasonable to expect them to = (re-)calculate a flow-label as a packet enters a domain. =20 Although, in the one case of Inter-Domain IP-in-IPv6 encapsulation it = /might/ be challenging in the near term for intermediate routers, at a = border entrance, to grab enough of the inner L4 + L3 headers + outer = packet headers to form a 'decent' outer header flow-label. Regardless, = this doesn't [currently] comprise a substantial portion of the = Inter-Domain traffic to be of short-term concern. In addition, the = end-result of this work should bring awareness of the issue of tunneled = packets to SP's and equipment vendors so that, eventually, equipment can = support it properly, which is the best we can do. Finally, to ameliorate some of the concerns of having PE's (a.k.a. = intermediate routers), with high-speed interfaces, identify "flows" as = packets enter the domain, it would be beneficial to have [much] simpler = IPv6 Extension Headers, as James Woodyatt mentioned a couple of weeks = ago in a different thread on this list: http://www.ietf.org/mail-archive/web/ipv6/current/msg11566.html ... thus, I would support that effort, as well, given the benefits to = not only application writers, but also intermediate routers, = middleboxes, etc. (eventually). Of course, work on draft-krishnan can = proceed in parallel and there shouldn't be any contingency on moving the = flow-label work forward. (If anything, the flow-label work can help = make a better case for draft-krishnan). -shane= From kawamucho@mesh.ad.jp Sun Apr 25 17:11:43 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 A38263A6AAE for ; Sun, 25 Apr 2010 17:11:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.117 X-Spam-Level: * X-Spam-Status: No, score=1.117 tagged_above=-999 required=5 tests=[AWL=-1.207, BAYES_40=-0.185, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] 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 u0r9zYu2AvhR for ; Sun, 25 Apr 2010 17:11:42 -0700 (PDT) Received: from tyo202.gate.nec.co.jp (TYO202.gate.nec.co.jp [202.32.8.206]) by core3.amsl.com (Postfix) with ESMTP id 965D628B56A for ; Sun, 25 Apr 2010 17:11:41 -0700 (PDT) Received: from mailgate3.nec.co.jp ([10.7.69.192]) by tyo202.gate.nec.co.jp (8.13.8/8.13.4) with ESMTP id o3Q0BPJa000734; Mon, 26 Apr 2010 09:11:25 +0900 (JST) Received: (from root@localhost) by mailgate3.nec.co.jp (8.11.7/3.7W-MAILGATE-NEC) id o3Q0BP522593; Mon, 26 Apr 2010 09:11:25 +0900 (JST) Received: from bgas200085.sys.biglobe.nec.co.jp (bgas200085.sys.biglobe.nec.co.jp [10.82.141.45]) by mailsv.nec.co.jp (8.13.8/8.13.4) with ESMTP id o3Q0BPqK022830; Mon, 26 Apr 2010 09:11:25 +0900 (JST) Received: from bsac29088.sys.biglobe.nec.co.jp (localhost [127.0.0.1]) by bgas200085.sys.biglobe.nec.co.jp (BINGO/BINGO/06101717) with ESMTP id o3Q0BO2E010264; Mon, 26 Apr 2010 09:11:25 +0900 Received: from mail.sys.biglobe.nec.co.jp (bgsx5626.sys.biglobe.nec.co.jp [10.18.151.10]) by bsac29088.sys.biglobe.nec.co.jp (BINGO/BINGO/06101717) with ESMTP id o3Q0BOTp016066; Mon, 26 Apr 2010 09:11:24 +0900 Received: from [127.0.0.1] (edonet065.sys.biglobe.nec.co.jp [10.19.137.65]) (authenticated bits=0) (envelope-from kawamucho@mesh.ad.jp) by mail.sys.biglobe.nec.co.jp (BINGO/BINGO/06101717) with ESMTP id o3Q0BOx0015829 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 26 Apr 2010 09:11:24 +0900 Message-ID: <4BD4DA2B.1050008@mesh.ad.jp> Date: Mon, 26 Apr 2010 09:11:23 +0900 From: Seiichi Kawamura User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Brett Tate Subject: Re: Draft-ietf-6man-text-addr-representation: usage of "::" References: <747A6506A991724FB09B129B79D5FEB61481012590@EXMBXCLUS01.citservers.local> In-Reply-To: <747A6506A991724FB09B129B79D5FEB61481012590@EXMBXCLUS01.citservers.local> X-Enigmail-Version: 0.96.0 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: Mon, 26 Apr 2010 00:11:44 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Brett Its both. Regards, Seiichi Brett Tate wrote: > The following is indicated within draft-ietf-6man-text-addr-representation-07 section 4.2.1 Shorten As Much As Possible. > > "The use of symbol "::" MUST be used to its maximum capability. For example, 2001:db8::0:1 is not acceptable, because the symbol "::" could have been used to produce a shorter representation 2001:db8::1." > > Concerning "::" usage, is the requirement that > 1) "::" MUST be used when valid, or > 2) only that if used, it MUST be used to its maximum capability? > > Thanks, > Brett > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) iEYEARECAAYFAkvU2ioACgkQcrhTYfxyMkIvvQCeLbz4doaNxmJme2TdOjvazCU2 kYMAmwSmhHdqHYi9tjgk/lLHVCHe4xNC =WgBS -----END PGP SIGNATURE----- From suresh.krishnan@ericsson.com Sun Apr 25 22:05:16 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 43E0B3A6AF6 for ; Sun, 25 Apr 2010 22:05:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.951 X-Spam-Level: X-Spam-Status: No, score=-2.951 tagged_above=-999 required=5 tests=[AWL=-1.841, BAYES_05=-1.11] 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 D5f85WDBgjFp for ; Sun, 25 Apr 2010 22:05:15 -0700 (PDT) Received: from imr3.ericy.com (imr3.ericy.com [198.24.6.13]) by core3.amsl.com (Postfix) with ESMTP id 207BC3A6864 for ; Sun, 25 Apr 2010 22:05:14 -0700 (PDT) Received: from eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) by imr3.ericy.com (8.13.8/8.13.8) with ESMTP id o3Q550eZ002461 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 26 Apr 2010 00:05:00 -0500 Received: from [142.133.10.113] (147.117.20.212) by eusaamw0711.eamcs.ericsson.se (147.117.20.179) with Microsoft SMTP Server id 8.1.375.2; Mon, 26 Apr 2010 01:04:59 -0400 Message-ID: <4BD51D87.80909@ericsson.com> Date: Mon, 26 Apr 2010 00:58:47 -0400 From: Suresh Krishnan User-Agent: Thunderbird 2.0.0.24 (X11/20100411) MIME-Version: 1.0 To: Seiichi Kawamura Subject: Re: Draft-ietf-6man-text-addr-representation: usage of "::" References: <747A6506A991724FB09B129B79D5FEB61481012590@EXMBXCLUS01.citservers.local> <4BD4DA2B.1050008@mesh.ad.jp> In-Reply-To: <4BD4DA2B.1050008@mesh.ad.jp> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit Cc: "ipv6@ietf.org" , Brett Tate 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, 26 Apr 2010 05:05:16 -0000 Hi Seiichi, On 10-04-25 08:11 PM, Seiichi Kawamura wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hi Brett > > Its both. While this may be the intent of the draft, it is unclear if "::" MUST always be used if there are at least two consecutive 16-bit 0 fields. I think it is a good idea and this can be accomplished by adding another subsection e.g. 4.2.0 Mandatory usage If the address contains at least two consecutive 16-bit 0 fields, "::" MUST be used to compress consecutive 16-bit 0 fields as described in the following sections. Thanks Suresh From kawamucho@mesh.ad.jp Sun Apr 25 22:37:02 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 DCEE728C100 for ; Sun, 25 Apr 2010 22:37:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.519 X-Spam-Level: * X-Spam-Status: No, score=1.519 tagged_above=-999 required=5 tests=[AWL=-0.805, BAYES_40=-0.185, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] 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 pZyLMA993ngr for ; Sun, 25 Apr 2010 22:37:02 -0700 (PDT) Received: from tyo202.gate.nec.co.jp (TYO202.gate.nec.co.jp [202.32.8.206]) by core3.amsl.com (Postfix) with ESMTP id 9441D3A6B14 for ; Sun, 25 Apr 2010 22:28:12 -0700 (PDT) Received: from mailgate3.nec.co.jp ([10.7.69.197]) by tyo202.gate.nec.co.jp (8.13.8/8.13.4) with ESMTP id o3Q5RqkO004353; Mon, 26 Apr 2010 14:27:52 +0900 (JST) Received: (from root@localhost) by mailgate3.nec.co.jp (8.11.7/3.7W-MAILGATE-NEC) id o3Q5Rqg18304; Mon, 26 Apr 2010 14:27:52 +0900 (JST) Received: from bgas200085.sys.biglobe.nec.co.jp (bgas200085.sys.biglobe.nec.co.jp [10.82.141.45]) by mailsv.nec.co.jp (8.13.8/8.13.4) with ESMTP id o3Q5RpNe004651; Mon, 26 Apr 2010 14:27:51 +0900 (JST) Received: from bsac29088.sys.biglobe.nec.co.jp (localhost [127.0.0.1]) by bgas200085.sys.biglobe.nec.co.jp (BINGO/BINGO/06101717) with ESMTP id o3Q5Rpal010267; Mon, 26 Apr 2010 14:27:51 +0900 Received: from mail.sys.biglobe.nec.co.jp (bgsx5626.sys.biglobe.nec.co.jp [10.18.151.10]) by bsac29088.sys.biglobe.nec.co.jp (BINGO/BINGO/06101717) with ESMTP id o3Q5RpLV025555; Mon, 26 Apr 2010 14:27:51 +0900 Received: from [127.0.0.1] (edonet065.sys.biglobe.nec.co.jp [10.19.137.65]) (authenticated bits=0) (envelope-from kawamucho@mesh.ad.jp) by mail.sys.biglobe.nec.co.jp (BINGO/BINGO/06101717) with ESMTP id o3Q5RpmU019193 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 26 Apr 2010 14:27:51 +0900 Message-ID: <4BD52456.8060901@mesh.ad.jp> Date: Mon, 26 Apr 2010 14:27:50 +0900 From: Seiichi Kawamura User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Suresh Krishnan Subject: Re: Draft-ietf-6man-text-addr-representation: usage of "::" References: <747A6506A991724FB09B129B79D5FEB61481012590@EXMBXCLUS01.citservers.local> <4BD4DA2B.1050008@mesh.ad.jp> <4BD51D87.80909@ericsson.com> In-Reply-To: <4BD51D87.80909@ericsson.com> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "ipv6@ietf.org" , Brett Tate 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, 26 Apr 2010 05:37:03 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Suresh I was just asking myself why I was being asked this question. I realised that the mandatory usage clause was left out when editing a few versions ago. (I can remember writing that down in some version in the past but don't remember which) Do you think the following would work? I merged "4.2.2. Handling One 16 bit 0 Field" with your text 4.2.1. When to use "::" If the address contains at least two consecutive 16-bit 0 fields, "::" MUST be used to compress consecutive 16-bit 0 fields. The symbol "::" MUST NOT be used to shorten just one 16 bit 0 field. For example, the representation 2001:db8:0:1:1:1:1:1 is correct, but 2001:db8::1:1:1:1:1 is not correct. Regards, Seiichi Suresh Krishnan wrote: > Hi Seiichi, > > On 10-04-25 08:11 PM, Seiichi Kawamura wrote: >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> Hi Brett >> >> Its both. > > While this may be the intent of the draft, it is unclear if "::" MUST > always be used if there are at least two consecutive 16-bit 0 fields. I > think it is a good idea and this can be accomplished by adding another > subsection e.g. > > 4.2.0 Mandatory usage > If the address contains at least two consecutive 16-bit 0 fields, "::" > MUST be used to compress consecutive 16-bit 0 fields as described in the > following sections. > > Thanks > Suresh > > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) iEYEARECAAYFAkvVJFYACgkQcrhTYfxyMkKC4QCeLyu596DXFs8Mafgqdg7ByH1s O0AAnAytBxYyGerfx+Kjoiex7IJxgNsw =8BiU -----END PGP SIGNATURE----- From brian@innovationslab.net Mon Apr 26 05:17:43 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 118EF3A6809 for ; Mon, 26 Apr 2010 05:17:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.205 X-Spam-Level: X-Spam-Status: No, score=-1.205 tagged_above=-999 required=5 tests=[AWL=-0.465, BAYES_20=-0.74] 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 nMS6hEpLcaKG for ; Mon, 26 Apr 2010 05:17:42 -0700 (PDT) Received: from uillean.fuaim.com (uillean.fuaim.com [206.197.161.140]) by core3.amsl.com (Postfix) with ESMTP id 0D4373A699E for ; Mon, 26 Apr 2010 05:17:24 -0700 (PDT) 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 A76298817E for ; Mon, 26 Apr 2010 05:17:12 -0700 (PDT) Received: from tigers.local (tigers.jhuapl.edu [128.244.178.215]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by clairseach.fuaim.com (Postfix) with ESMTP id 56CBF130003 for ; Mon, 26 Apr 2010 05:17:12 -0700 (PDT) Message-ID: <4BD58447.9000003@innovationslab.net> Date: Mon, 26 Apr 2010 08:17:11 -0400 From: Brian Haberman User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.4; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: IPv6 WG Mailing List Subject: Consensus call on adopting draft-krishnan-ipv6-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, 26 Apr 2010 12:17:43 -0000 All, The 6MAN chairs would like feedback from the working group on adopting draft-krishnan-ipv6-exthdr as a WG item. Please send your comments/opinions to the mailing list (or the chairs) by May 7, 2010. Regards, Brian & Bob From vishwas.ietf@gmail.com Mon Apr 26 07:52:30 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 9E7CA3A68E7 for ; Mon, 26 Apr 2010 07:52:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[AWL=0.499, 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 loHeTOqoTNmw for ; Mon, 26 Apr 2010 07:52:30 -0700 (PDT) Received: from mail-pv0-f172.google.com (mail-pv0-f172.google.com [74.125.83.172]) by core3.amsl.com (Postfix) with ESMTP id 8884C28C1F9 for ; Mon, 26 Apr 2010 07:37:28 -0700 (PDT) Received: by pvg11 with SMTP id 11so547591pvg.31 for ; Mon, 26 Apr 2010 07:37:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=LxndP7lkwxjKiO1wLTh3ZOkCaCaXsByFZ9CnpLE18Xo=; b=HHrTVBehojcgJw72FDrLYCxgnEa5kC8ziUsLS9QwaABgKcK2RyksqyS9dF66xcTYnn gE9bk6RUu9JBOIPmRsVQmDAXShn+wKZkOkDSBwM6zDl76rxu7Y62DvoUXJJYvdP4r4AF zQ/EZ5IfE6MPMxUY55ULcdRUPSXYVruml99rA= 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=BvzM85iLQdSG1R9DpYD7Bl5TMgEIaAQNKqlm5lEBTcV37TSKLJUIEHL/xrS5/7s7dL EVzVGuFRij5C+6yInN68LSiyfVI73gMuGLLCDr9ks4zTpn8jqXjMEVhl7lOzt1LBw4YP DPMYwPT7RKVVd/Yqqx4K9Wr7iBwRT3cvviaNQ= MIME-Version: 1.0 Received: by 10.141.106.12 with SMTP id i12mr3726719rvm.149.1272292636131; Mon, 26 Apr 2010 07:37:16 -0700 (PDT) Received: by 10.151.27.4 with HTTP; Mon, 26 Apr 2010 07:37:16 -0700 (PDT) In-Reply-To: <4BD58447.9000003@innovationslab.net> References: <4BD58447.9000003@innovationslab.net> Date: Mon, 26 Apr 2010 07:37:16 -0700 Message-ID: Subject: Re: Consensus call on adopting draft-krishnan-ipv6-exthdr From: Vishwas Manral To: Brian Haberman Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: IPv6 WG 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, 26 Apr 2010 14:52:30 -0000 Hi, I support the effort. Thanks, Vishwas On Mon, Apr 26, 2010 at 5:17 AM, Brian Haberman wrote: > All, > =A0 =A0 The 6MAN chairs would like feedback from the working group on ado= pting > draft-krishnan-ipv6-exthdr as a WG item. =A0Please send your comments/opi= nions > to the mailing list (or the chairs) by May 7, 2010. > > Regards, > Brian & Bob > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > From alexandru.petrescu@gmail.com Mon Apr 26 08:10:38 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 993703A6A05 for ; Mon, 26 Apr 2010 08:10:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.965 X-Spam-Level: X-Spam-Status: No, score=-1.965 tagged_above=-999 required=5 tests=[AWL=0.284, BAYES_00=-2.599, HELO_EQ_FR=0.35] 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 XM5j5QyqBPvh for ; Mon, 26 Apr 2010 08:10:37 -0700 (PDT) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.166.172.107]) by core3.amsl.com (Postfix) with ESMTP id DAEB33A6AB5 for ; Mon, 26 Apr 2010 08:02:19 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.0) with ESMTP id o3QF26lM017845 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Mon, 26 Apr 2010 17:02:06 +0200 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id o3QF26Sl011738 for ; Mon, 26 Apr 2010 17:02:06 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.133.173]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id o3QF245E018180 for ; Mon, 26 Apr 2010 17:02:06 +0200 Message-ID: <4BD5AAEC.7030505@gmail.com> Date: Mon, 26 Apr 2010 17:02:04 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: ipv6@ietf.org Subject: Re: Consensus call on adopting draft-krishnan-ipv6-exthdr References: <4BD58447.9000003@innovationslab.net> In-Reply-To: <4BD58447.9000003@innovationslab.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit 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, 26 Apr 2010 15:10:38 -0000 Le 26/04/2010 14:17, Brian Haberman a écrit : > All, > The 6MAN chairs would like feedback from the working group on adopting > draft-krishnan-ipv6-exthdr as a WG item. Please send your > comments/opinions to the mailing list (or the chairs) by May 7, 2010. Comments... > 3. Backward Compatibility > > > The scheme proposed in this document is not backward compatible with > all the currently defined IPv6 extension headers. It only applies to > newly defined extension headers. Specifically, the following > extension headers predate this document and do not follow the format > proposed in this document. > > o IPv6 Hop-by-Hop Options Header > o IPv6 Routing Header > o IPv6 Fragment Header > o IPv6 Destination Options Header And AH and ESP? Alex > > Regards, > Brian & Bob > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > From suresh.krishnan@ericsson.com Mon Apr 26 08:30:41 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 DA3C728C149 for ; Mon, 26 Apr 2010 08:30:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.564 X-Spam-Level: X-Spam-Status: No, score=-5.564 tagged_above=-999 required=5 tests=[AWL=1.035, 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 fXykvJ+dhzne for ; Mon, 26 Apr 2010 08:30:41 -0700 (PDT) Received: from imr1.ericy.com (imr1.ericy.com [198.24.6.9]) by core3.amsl.com (Postfix) with ESMTP id CFDE13A6B87 for ; Mon, 26 Apr 2010 08:28:55 -0700 (PDT) Received: from eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) by imr1.ericy.com (8.13.1/8.13.1) with ESMTP id o3QFXXYG027401; Mon, 26 Apr 2010 10:33:34 -0500 Received: from [142.133.10.113] (147.117.20.212) by eusaamw0706.eamcs.ericsson.se (147.117.20.91) with Microsoft SMTP Server id 8.1.375.2; Mon, 26 Apr 2010 11:28:40 -0400 Message-ID: <4BD5AFB2.4000905@ericsson.com> Date: Mon, 26 Apr 2010 11:22:26 -0400 From: Suresh Krishnan User-Agent: Thunderbird 2.0.0.24 (X11/20100411) MIME-Version: 1.0 To: Seiichi Kawamura Subject: Re: Draft-ietf-6man-text-addr-representation: usage of "::" References: <747A6506A991724FB09B129B79D5FEB61481012590@EXMBXCLUS01.citservers.local> <4BD4DA2B.1050008@mesh.ad.jp> <4BD51D87.80909@ericsson.com> <4BD52456.8060901@mesh.ad.jp> In-Reply-To: <4BD52456.8060901@mesh.ad.jp> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit Cc: "ipv6@ietf.org" , Brett Tate 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, 26 Apr 2010 15:30:42 -0000 Hi Seiichi, On 10-04-26 01:27 AM, Seiichi Kawamura wrote: > Do you think the following would work? > I merged "4.2.2. Handling One 16 bit 0 Field" with your text > > 4.2.1. When to use "::" > > If the address contains at least two consecutive 16-bit 0 fields, "::" > MUST be used to compress consecutive 16-bit 0 fields. > The symbol "::" MUST NOT be used to shorten just one 16 bit 0 field. > For example, the representation 2001:db8:0:1:1:1:1:1 is correct, but > 2001:db8::1:1:1:1:1 is not correct. Perfect. Sounds good. Go for it. I just noticed that the draft is in the RFC editor queue. If the WG is OK with this change (you need to check*) you can make the edit in AUTH48. Thanks Suresh NOTE(*): I made an AUTH48 change to RFC4941 and I sent this message to the mailing list to verify if it was OK. If you want, you can send something similar to this to initiate comments on the proposed change. http://www.ietf.org/mail-archive/web/ipv6/current/msg07900.html From wbeebee@cisco.com Mon Apr 26 10:45:02 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 8A11C28C1BC for ; Mon, 26 Apr 2010 10:45:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.781 X-Spam-Level: X-Spam-Status: No, score=-9.781 tagged_above=-999 required=5 tests=[AWL=0.818, 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 SQ7ji1YW5Xyt for ; Mon, 26 Apr 2010 10:45:01 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 7F69C28C132 for ; Mon, 26 Apr 2010 10:45:01 -0700 (PDT) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEADZu1UutJV2d/2dsb2JhbACcPnGpYZl/hQsEgzk X-IronPort-AV: E=Sophos;i="4.52,274,1270425600"; d="scan'208";a="105181981" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rtp-iport-1.cisco.com with ESMTP; 26 Apr 2010 17:44:49 +0000 Received: from xbh-rcd-302.cisco.com (xbh-rcd-302.cisco.com [72.163.63.9]) by rcdn-core-6.cisco.com (8.14.3/8.14.3) with ESMTP id o3QHimj6031379; Mon, 26 Apr 2010 17:44:48 GMT Received: from xmb-rcd-201.cisco.com ([72.163.62.208]) by xbh-rcd-302.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 26 Apr 2010 12:44:49 -0500 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: Consensus call on adopting draft-krishnan-ipv6-exthdr Date: Mon, 26 Apr 2010 12:44:45 -0500 Message-ID: In-Reply-To: <4BD58447.9000003@innovationslab.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Consensus call on adopting draft-krishnan-ipv6-exthdr Thread-Index: AcrlOnsc4XPLC8SbSJ+MR728q+yLCAALV0bg References: <4BD58447.9000003@innovationslab.net> From: "Wes Beebee (wbeebee)" To: "Brian Haberman" , "IPv6 WG Mailing List" X-OriginalArrivalTime: 26 Apr 2010 17:44:49.0237 (UTC) FILETIME=[2AE32850:01CAE568] 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, 26 Apr 2010 17:45:02 -0000 I support this effort as I think it will "future proof" extension headers as far as stateful firewalls are concerned - but what I'm interested in is finding out how much demand for new extension headers there is out there - and what those new extension headers would be. - Wes -----Original Message----- From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of Brian Haberman Sent: Monday, April 26, 2010 8:17 AM To: IPv6 WG Mailing List Subject: Consensus call on adopting draft-krishnan-ipv6-exthdr All, The 6MAN chairs would like feedback from the working group on=20 adopting draft-krishnan-ipv6-exthdr as a WG item. Please send your=20 comments/opinions to the mailing list (or the chairs) by May 7, 2010. Regards, Brian & Bob -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From suresh.krishnan@ericsson.com Mon Apr 26 11:03:51 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 043EE3A69AA for ; Mon, 26 Apr 2010 11:03:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.633 X-Spam-Level: X-Spam-Status: No, score=-5.633 tagged_above=-999 required=5 tests=[AWL=0.966, 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+TXAy+WS7CG for ; Mon, 26 Apr 2010 11:03:50 -0700 (PDT) Received: from imr1.ericy.com (imr1.ericy.com [198.24.6.9]) by core3.amsl.com (Postfix) with ESMTP id 1A09328C1C0 for ; Mon, 26 Apr 2010 11:03:49 -0700 (PDT) Received: from eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) by imr1.ericy.com (8.13.1/8.13.1) with ESMTP id o3QI8Ubw031513; Mon, 26 Apr 2010 13:08:30 -0500 Received: from [142.133.10.113] (147.117.20.212) by eusaamw0712.eamcs.ericsson.se (147.117.20.182) with Microsoft SMTP Server id 8.1.375.2; Mon, 26 Apr 2010 14:03:36 -0400 Message-ID: <4BD5D402.2090402@ericsson.com> Date: Mon, 26 Apr 2010 13:57:22 -0400 From: Suresh Krishnan User-Agent: Thunderbird 2.0.0.24 (X11/20100411) MIME-Version: 1.0 To: Alexandru Petrescu Subject: Re: Consensus call on adopting draft-krishnan-ipv6-exthdr References: <4BD58447.9000003@innovationslab.net> <4BD5AAEC.7030505@gmail.com> In-Reply-To: <4BD5AAEC.7030505@gmail.com> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 8bit 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, 26 Apr 2010 18:03:51 -0000 Hi Alex, On 10-04-26 11:02 AM, Alexandru Petrescu wrote: > Le 26/04/2010 14:17, Brian Haberman a écrit : >> All, >> The 6MAN chairs would like feedback from the working group on adopting >> draft-krishnan-ipv6-exthdr as a WG item. Please send your >> comments/opinions to the mailing list (or the chairs) by May 7, 2010. > > Comments... >> 3. Backward Compatibility >> >> >> The scheme proposed in this document is not backward compatible with >> all the currently defined IPv6 extension headers. It only applies to >> newly defined extension headers. Specifically, the following >> extension headers predate this document and do not follow the format >> proposed in this document. >> >> o IPv6 Hop-by-Hop Options Header >> o IPv6 Routing Header >> o IPv6 Fragment Header >> o IPv6 Destination Options Header > > And AH and ESP? AH & ESP are not considered as IPv6 extension headers and they are considered as payload as far as IPv6 is concerned. Thanks Suresh From vishwas.ietf@gmail.com Mon Apr 26 11:21:27 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 737DF3A6A42 for ; Mon, 26 Apr 2010 11:21:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.133 X-Spam-Level: X-Spam-Status: No, score=-2.133 tagged_above=-999 required=5 tests=[AWL=0.466, 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 ZHjBBhPx7Axm for ; Mon, 26 Apr 2010 11:21:25 -0700 (PDT) Received: from mail-pv0-f172.google.com (mail-pv0-f172.google.com [74.125.83.172]) by core3.amsl.com (Postfix) with ESMTP id 0DCB73A6ACE for ; Mon, 26 Apr 2010 11:20:50 -0700 (PDT) Received: by pvg11 with SMTP id 11so798414pvg.31 for ; Mon, 26 Apr 2010 11:20:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=XfYmyprb5C6aq33+xHIB+YtKp5B9z4M5gnUoiKa2mJA=; b=MbkhIuMlk2boTt++USyVQp7UFOooIvQfQvc5R4XtMPDfQ6Jmza9orptydnn4f7KGdt gSMmJbHdFEeldVyTyr5dfDL4N6HuH5B9cqLsl4guscEPVPB3e/u460I0N24LcZITKX92 t5DgnVUQexDHPtcSLsDYsl1AQ5rqS/5Tf2q90= 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=ZuT9Lo11yx3ABnjIktGozikQvr7mp06tK6fGEbQobL/LJVaoKu+oeDWzz4lAiS7ypZ Wofzqjk0U896JeqGyVrkGVgJiWCGTUJQcR5t4/fOVg2F5kOccMeMvMtO/yXQXwN2gx2M LVGzIoFet41rrUc1kfnoKGQ/qJiWmdMrwI6VQ= MIME-Version: 1.0 Received: by 10.114.188.31 with SMTP id l31mr4924219waf.32.1272306034889; Mon, 26 Apr 2010 11:20:34 -0700 (PDT) Received: by 10.151.27.4 with HTTP; Mon, 26 Apr 2010 11:20:34 -0700 (PDT) In-Reply-To: <4BD5D402.2090402@ericsson.com> References: <4BD58447.9000003@innovationslab.net> <4BD5AAEC.7030505@gmail.com> <4BD5D402.2090402@ericsson.com> Date: Mon, 26 Apr 2010 11:20:34 -0700 Message-ID: Subject: Re: Consensus call on adopting draft-krishnan-ipv6-exthdr From: Vishwas Manral To: Suresh Krishnan Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Alexandru Petrescu , "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, 26 Apr 2010 18:21:27 -0000 Hi Suresh, This brings the interesting issue, how do I know if the unknown inner header is payload vs Extension header? Thanks, Vishwas On Mon, Apr 26, 2010 at 10:57 AM, Suresh Krishnan wrote: > Hi Alex, > > On 10-04-26 11:02 AM, Alexandru Petrescu wrote: >> >> Le 26/04/2010 14:17, Brian Haberman a =E9crit : >>> >>> All, >>> The 6MAN chairs would like feedback from the working group on adopting >>> draft-krishnan-ipv6-exthdr as a WG item. Please send your >>> comments/opinions to the mailing list (or the chairs) by May 7, 2010. >> >> Comments... >>> >>> 3. Backward Compatibility >>> >>> >>> =A0 The scheme proposed in this document is not backward compatible wit= h >>> =A0 all the currently defined IPv6 extension headers. =A0It only applie= s to >>> =A0 newly defined extension headers. =A0Specifically, the following >>> =A0 extension headers predate this document and do not follow the forma= t >>> =A0 proposed in this document. >>> >>> =A0 o =A0IPv6 Hop-by-Hop Options Header >>> =A0 o =A0IPv6 Routing Header >>> =A0 o =A0IPv6 Fragment Header >>> =A0 o =A0IPv6 Destination Options Header >> >> And AH and ESP? > > AH & ESP are not considered as IPv6 extension headers and they are > considered as payload as far as IPv6 is concerned. > > Thanks > Suresh > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > From suresh.krishnan@ericsson.com Mon Apr 26 11:24:58 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 E6B803A6899 for ; Mon, 26 Apr 2010 11:24:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.693 X-Spam-Level: X-Spam-Status: No, score=-5.693 tagged_above=-999 required=5 tests=[AWL=0.906, 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 9wX98O-ChsyR for ; Mon, 26 Apr 2010 11:24:58 -0700 (PDT) Received: from imr1.ericy.com (imr1.ericy.com [198.24.6.9]) by core3.amsl.com (Postfix) with ESMTP id 0C8933A6872 for ; Mon, 26 Apr 2010 11:24:57 -0700 (PDT) Received: from eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) by imr1.ericy.com (8.13.1/8.13.1) with ESMTP id o3QITclT012396; Mon, 26 Apr 2010 13:29:38 -0500 Received: from [142.133.10.113] (147.117.20.212) by eusaamw0707.eamcs.ericsson.se (147.117.20.92) with Microsoft SMTP Server id 8.1.375.2; Mon, 26 Apr 2010 14:24:44 -0400 Message-ID: <4BD5D8F5.9080904@ericsson.com> Date: Mon, 26 Apr 2010 14:18:29 -0400 From: Suresh Krishnan User-Agent: Thunderbird 2.0.0.24 (X11/20100411) MIME-Version: 1.0 To: Vishwas Manral Subject: Re: Consensus call on adopting draft-krishnan-ipv6-exthdr References: <4BD58447.9000003@innovationslab.net> <4BD5AAEC.7030505@gmail.com> <4BD5D402.2090402@ericsson.com> In-Reply-To: Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 8bit Cc: Alexandru Petrescu , "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, 26 Apr 2010 18:24:59 -0000 Hi Vishwas, The idea is that all new IPv6 extension headers will use the same Next Header value (allocated in this draft). Anything else will be a payload/upper layer protocol. i.e. An unknown extension header will have a known "Next Header" value but an unknown "Specific Type" inside the GIEH and an unknown upper layer protocol will have an unknown "Next Header" value. Thanks Suresh On 10-04-26 02:20 PM, Vishwas Manral wrote: > Hi Suresh, > > This brings the interesting issue, how do I know if the unknown inner > header is payload vs Extension header? > > Thanks, > Vishwas > > On Mon, Apr 26, 2010 at 10:57 AM, Suresh Krishnan > wrote: >> Hi Alex, >> >> On 10-04-26 11:02 AM, Alexandru Petrescu wrote: >>> Le 26/04/2010 14:17, Brian Haberman a écrit : >>>> All, >>>> The 6MAN chairs would like feedback from the working group on adopting >>>> draft-krishnan-ipv6-exthdr as a WG item. Please send your >>>> comments/opinions to the mailing list (or the chairs) by May 7, 2010. >>> Comments... >>>> 3. Backward Compatibility >>>> >>>> >>>> The scheme proposed in this document is not backward compatible with >>>> all the currently defined IPv6 extension headers. It only applies to >>>> newly defined extension headers. Specifically, the following >>>> extension headers predate this document and do not follow the format >>>> proposed in this document. >>>> >>>> o IPv6 Hop-by-Hop Options Header >>>> o IPv6 Routing Header >>>> o IPv6 Fragment Header >>>> o IPv6 Destination Options Header >>> And AH and ESP? >> AH & ESP are not considered as IPv6 extension headers and they are >> considered as payload as far as IPv6 is concerned. >> >> Thanks >> Suresh >> >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list >> ipv6@ietf.org >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- >> From vishwas.ietf@gmail.com Mon Apr 26 11:37:37 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 2A5A93A6957 for ; Mon, 26 Apr 2010 11:37:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.021 X-Spam-Level: X-Spam-Status: No, score=-2.021 tagged_above=-999 required=5 tests=[AWL=0.578, 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 tD4gySdTTq02 for ; Mon, 26 Apr 2010 11:37:36 -0700 (PDT) Received: from mail-pz0-f182.google.com (mail-pz0-f182.google.com [209.85.222.182]) by core3.amsl.com (Postfix) with ESMTP id 1C08F3A6845 for ; Mon, 26 Apr 2010 11:37:36 -0700 (PDT) Received: by pzk12 with SMTP id 12so8690128pzk.32 for ; Mon, 26 Apr 2010 11:37:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=O+PuaaRGuX4jLBsxUUksr4L7+8EB0QERSveSAJivdTM=; b=eAatwBpMMIgPN9WL6CQHdclUXNJZ9XY5MuieBk8q0UzfJKaQg62R3OVAMDZ2eef4BI 4FcaY24KIX7m4LBpmQEz+G+0ilEHUmyojqt1ESHIlNX3gYO9O9vIE6awqPAMw1d2vhJw VEL6GqceGo1JDuikTfYh62+8aQY2CItpKDGfs= 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=XGsQcgGykzFwHx7U8/4TEClCXfMifuCG3/S8Bb7BqGtkh8q5Vz87yHFtYUpSSGXxCB It1cWCuOyJLsY1xAROvzPn8bqrczQqbijI8SuPk1dLWga5/IJpQzSGLHbt/Khx7N/X4J wrtPavwM4VWUrdbRu6d0xPGhjGFsNdd53+hbE= MIME-Version: 1.0 Received: by 10.142.55.11 with SMTP id d11mr2243826wfa.99.1272307041158; Mon, 26 Apr 2010 11:37:21 -0700 (PDT) Received: by 10.151.27.4 with HTTP; Mon, 26 Apr 2010 11:37:21 -0700 (PDT) In-Reply-To: <4BD5D8F5.9080904@ericsson.com> References: <4BD58447.9000003@innovationslab.net> <4BD5AAEC.7030505@gmail.com> <4BD5D402.2090402@ericsson.com> <4BD5D8F5.9080904@ericsson.com> Date: Mon, 26 Apr 2010 11:37:21 -0700 Message-ID: Subject: Re: Consensus call on adopting draft-krishnan-ipv6-exthdr From: Vishwas Manral To: Suresh Krishnan Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Alexandru Petrescu , "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, 26 Apr 2010 18:37:37 -0000 Hi Suresh, > i.e. An unknown extension header will have a known "Next Header" value bu= t > an unknown "Specific Type" inside the GIEH and an unknown upper layer > protocol will have an unknown "Next Header" value. This need not be the case. What if two new headers are defined. Also if it is a payload how do we make sure the payload first byte does not match a known "Next header" field. I think the first case you need to define is some values of extension headers (x to y). That will solve all your issues. Thanks, Vishwas On Mon, Apr 26, 2010 at 11:18 AM, Suresh Krishnan wrote: > Hi Vishwas, > =A0The idea is that all new IPv6 extension headers will use the same Next > Header value (allocated in this draft). Anything else will be a > payload/upper layer protocol. > > i.e. An unknown extension header will have a known "Next Header" value bu= t > an unknown "Specific Type" inside the GIEH and an unknown upper layer > protocol will have an unknown "Next Header" value. > > Thanks > Suresh > > On 10-04-26 02:20 PM, Vishwas Manral wrote: >> >> Hi Suresh, >> >> This brings the interesting issue, how do I know if the unknown inner >> header is payload vs Extension header? >> >> Thanks, >> Vishwas >> >> On Mon, Apr 26, 2010 at 10:57 AM, Suresh Krishnan >> wrote: >>> >>> Hi Alex, >>> >>> On 10-04-26 11:02 AM, Alexandru Petrescu wrote: >>>> >>>> Le 26/04/2010 14:17, Brian Haberman a =E9crit : >>>>> >>>>> All, >>>>> The 6MAN chairs would like feedback from the working group on adoptin= g >>>>> draft-krishnan-ipv6-exthdr as a WG item. Please send your >>>>> comments/opinions to the mailing list (or the chairs) by May 7, 2010. >>>> >>>> Comments... >>>>> >>>>> 3. Backward Compatibility >>>>> >>>>> >>>>> =A0The scheme proposed in this document is not backward compatible wi= th >>>>> =A0all the currently defined IPv6 extension headers. =A0It only appli= es to >>>>> =A0newly defined extension headers. =A0Specifically, the following >>>>> =A0extension headers predate this document and do not follow the form= at >>>>> =A0proposed in this document. >>>>> >>>>> =A0o =A0IPv6 Hop-by-Hop Options Header >>>>> =A0o =A0IPv6 Routing Header >>>>> =A0o =A0IPv6 Fragment Header >>>>> =A0o =A0IPv6 Destination Options Header >>>> >>>> And AH and ESP? >>> >>> AH & ESP are not considered as IPv6 extension headers and they are >>> considered as payload as far as IPv6 is concerned. >>> >>> Thanks >>> Suresh >>> >>> -------------------------------------------------------------------- >>> IETF IPv6 working group mailing list >>> ipv6@ietf.org >>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >>> -------------------------------------------------------------------- >>> > > From suresh.krishnan@ericsson.com Mon Apr 26 12:14:07 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 C7BC63A68A4 for ; Mon, 26 Apr 2010 12:14:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.746 X-Spam-Level: X-Spam-Status: No, score=-3.746 tagged_above=-999 required=5 tests=[AWL=-1.147, 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 J-2wF+WRW+Lq for ; Mon, 26 Apr 2010 12:14:07 -0700 (PDT) Received: from imr3.ericy.com (imr3.ericy.com [198.24.6.13]) by core3.amsl.com (Postfix) with ESMTP id 18EC83A689D for ; Mon, 26 Apr 2010 12:14:06 -0700 (PDT) Received: from eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) by imr3.ericy.com (8.13.8/8.13.8) with ESMTP id o3QJDpRH003279 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 26 Apr 2010 14:13:51 -0500 Received: from [142.133.10.113] (147.117.20.212) by eusaamw0707.eamcs.ericsson.se (147.117.20.92) with Microsoft SMTP Server id 8.1.375.2; Mon, 26 Apr 2010 15:13:51 -0400 Message-ID: <4BD5E478.9040709@ericsson.com> Date: Mon, 26 Apr 2010 15:07:36 -0400 From: Suresh Krishnan User-Agent: Thunderbird 2.0.0.24 (X11/20100411) MIME-Version: 1.0 To: "Duncan, Jeremy" Subject: Re: Consensus call on adopting draft-krishnan-ipv6-exthdr References: <4BD58447.9000003@innovationslab.net> <4BD5AAEC.7030505@gmail.com>, <4BD5D402.2090402@ericsson.com> <3D94AC8453ABFD4C9504DFBE27043B0F269398C9A6@sfed07> In-Reply-To: <3D94AC8453ABFD4C9504DFBE27043B0F269398C9A6@sfed07> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit Cc: Alexandru Petrescu , "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, 26 Apr 2010 19:14:07 -0000 Hi Jeremy, On 10-04-26 02:07 PM, Duncan, Jeremy wrote: > Pretty sure all extension headers are considered payload of the IPv6 header. Check out RFC 2460. It says ESP and AH are there.. As you stated above RFC2460 does talk about the AH and ESP, but the AH spec itself contains the following text. "In the IPv6 context, AH is viewed as an end-to-end payload, and thus should appear after hop-by-hop, routing, and fragmentation extension headers." I do not have any strong opinions on whether to include AH and ESP in the Backward compatibility section. I can change the text to add AH and ESP if there is working group consensus to do so. Thanks Suresh From alexandru.petrescu@gmail.com Mon Apr 26 13:38:13 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 C78393A6ABE for ; Mon, 26 Apr 2010 13:38:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.008 X-Spam-Level: X-Spam-Status: No, score=0.008 tagged_above=-999 required=5 tests=[AWL=-0.343, BAYES_50=0.001, HELO_EQ_FR=0.35] 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 36qbpS0MvS8B for ; Mon, 26 Apr 2010 13:38:13 -0700 (PDT) Received: from smtp1-g21.free.fr (smtp1-g21.free.fr [212.27.42.1]) by core3.amsl.com (Postfix) with ESMTP id C3E053A6AAF for ; Mon, 26 Apr 2010 13:38:11 -0700 (PDT) Received: from smtp1-g21.free.fr (localhost [127.0.0.1]) by smtp1-g21.free.fr (Postfix) with ESMTP id EAA6794016B; Mon, 26 Apr 2010 22:37:55 +0200 (CEST) Received: from [127.0.0.1] (bur91-3-82-239-213-32.fbx.proxad.net [82.239.213.32]) by smtp1-g21.free.fr (Postfix) with ESMTP id 92F1694017E; Mon, 26 Apr 2010 22:37:52 +0200 (CEST) Message-ID: <4BD5F9A0.1060408@gmail.com> Date: Mon, 26 Apr 2010 22:37:52 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; fr; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: Suresh Krishnan Subject: Re: Consensus call on adopting draft-krishnan-ipv6-exthdr References: <4BD58447.9000003@innovationslab.net> <4BD5AAEC.7030505@gmail.com> <4BD5D402.2090402@ericsson.com> In-Reply-To: <4BD5D402.2090402@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Antivirus: avast! (VPS 100426-0, 26/04/2010), Outbound message X-Antivirus-Status: Clean 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, 26 Apr 2010 20:38:13 -0000 Le 26/04/2010 19:57, Suresh Krishnan a écrit : > Hi Alex, > > On 10-04-26 11:02 AM, Alexandru Petrescu wrote: >> Le 26/04/2010 14:17, Brian Haberman a écrit : >>> All, The 6MAN chairs would like feedback from the working group >>> on adopting draft-krishnan-ipv6-exthdr as a WG item. Please send >>> your comments/opinions to the mailing list (or the chairs) by >>> May 7, 2010. >> >> Comments... >>> 3. Backward Compatibility >>> >>> >>> The scheme proposed in this document is not backward compatible >>> with all the currently defined IPv6 extension headers. It only >>> applies to newly defined extension headers. Specifically, the >>> following extension headers predate this document and do not >>> follow the format proposed in this document. >>> >>> o IPv6 Hop-by-Hop Options Header o IPv6 Routing Header o IPv6 >>> Fragment Header o IPv6 Destination Options Header >> >> And AH and ESP? > > AH & ESP are not considered as IPv6 extension headers and they are > considered as payload as far as IPv6 is concerned. Related... DO (and others maybe) may sometimes appear before some times after AH. Will the krishnan-exthdr appear before and some times after AH? In addition, how would one specify which fields of the yet-to-be-specified extension header using the krishnan-exthdr rules, be covered by AH? (and which fields not covered by AH). Or is this draft mainly intended for firewalls which would ignore AH? I am curious, is there some other draft planning to use krishnan-exthdr? Somebody plans on using it? Thanks, Alex > > Thanks Suresh > > From stig@venaas.com Mon Apr 26 13:52:47 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 0E0173A6912 for ; Mon, 26 Apr 2010 13:52:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.95 X-Spam-Level: X-Spam-Status: No, score=-1.95 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599, NO_RELAYS=-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 VdvbgcZtDZbK for ; Mon, 26 Apr 2010 13:52:46 -0700 (PDT) Received: from ufisa.uninett.no (ufisa.uninett.no [IPv6:2001:700:1:2:158:38:152:126]) by core3.amsl.com (Postfix) with ESMTP id EEE153A67EF for ; Mon, 26 Apr 2010 13:52:45 -0700 (PDT) Received: from [IPv6:2001:420:1:fff:0:5efe:10.32.214.38] (unknown [IPv6:2001:420:1:fff:0:5efe:a20:d626]) by ufisa.uninett.no (Postfix) with ESMTPSA id 7212180EC; Mon, 26 Apr 2010 22:52:32 +0200 (CEST) Message-ID: <4BD5FCFD.3070608@venaas.com> Date: Mon, 26 Apr 2010 13:52:13 -0700 From: Stig Venaas User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: "Wes Beebee (wbeebee)" Subject: Re: Consensus call on adopting draft-krishnan-ipv6-exthdr References: <4BD58447.9000003@innovationslab.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Brian Haberman , IPv6 WG 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, 26 Apr 2010 20:52:47 -0000 Wes Beebee (wbeebee) wrote: > I support this effort as I think it will "future proof" extension > headers as far as stateful firewalls are concerned - but what I'm > interested in is finding out how much demand for new extension headers > there is out there - and what those new extension headers would be. I can agree that it's good to check demand, but I think it is good to do the "future proofing" anyway. Things can then be implemented today and work correctly (as in ignoring unknown headers and still finding the transport) if new headers are introduced later. An alternative approach could perhaps be to set aside a small range of protocol values for future extension headers? Stig > - Wes > > -----Original Message----- > From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of > Brian Haberman > Sent: Monday, April 26, 2010 8:17 AM > To: IPv6 WG Mailing List > Subject: Consensus call on adopting draft-krishnan-ipv6-exthdr > > All, > The 6MAN chairs would like feedback from the working group on > adopting draft-krishnan-ipv6-exthdr as a WG item. Please send your > comments/opinions to the mailing list (or the chairs) by May 7, 2010. > > Regards, > Brian & Bob > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From vishwas.ietf@gmail.com Mon Apr 26 14:14:11 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 773633A683F for ; Mon, 26 Apr 2010 14:14:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.043 X-Spam-Level: X-Spam-Status: No, score=-2.043 tagged_above=-999 required=5 tests=[AWL=0.556, 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 4-kKMe1EXx-9 for ; Mon, 26 Apr 2010 14:14:10 -0700 (PDT) Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by core3.amsl.com (Postfix) with ESMTP id 646153A68EE for ; Mon, 26 Apr 2010 14:14:10 -0700 (PDT) Received: by pwj2 with SMTP id 2so8840878pwj.31 for ; Mon, 26 Apr 2010 14:13:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=/Bd85fX9lh5f5sfDPWRAoH38nTRYFXYJlemKk1N8k/E=; b=bHcygECpmkjJguABxE/WNt7xhL0DQqwodQIOxXhMVuKHV02XyyVYpmtVsv/dKxd1em 7EWpExTdxy5m7leGxqDDxZlxJZS8GYE1GelmiKQnvLpn3hMnH6i7ccKX2gT+WX6ENMv5 7aKVL5pY2kigFzgt1j9gxLJq+22gOCqRTworg= 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=ib0AdyPoLQl6DGg1dRenzYWRBiWM/csE4FrMVlejuQ26NGthc5ruScEz3QN1i4PTZP zCrXyLKPAPL2hjUT4fN7JRG/R6fuFHHT6KG6S4EBbzH4/Sp2cUVNIG6i0lD+rLHcuTG7 UcHJyeof7sTVFdsNgNRLfibh921Z+VKZb9wMw= MIME-Version: 1.0 Received: by 10.141.15.8 with SMTP id s8mr165182rvi.126.1272316411420; Mon, 26 Apr 2010 14:13:31 -0700 (PDT) Received: by 10.151.27.4 with HTTP; Mon, 26 Apr 2010 14:13:31 -0700 (PDT) In-Reply-To: <4BD5FCFD.3070608@venaas.com> References: <4BD58447.9000003@innovationslab.net> <4BD5FCFD.3070608@venaas.com> Date: Mon, 26 Apr 2010 14:13:31 -0700 Message-ID: Subject: Re: Consensus call on adopting draft-krishnan-ipv6-exthdr From: Vishwas Manral To: Stig Venaas Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: IPv6 WG Mailing List , Brian Haberman 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, 26 Apr 2010 21:14:11 -0000 Hi Stig, > I can agree that it's good to check demand, but I think it is good to > do the "future proofing" anyway. Things can then be implemented today > and work correctly (as in ignoring unknown headers and still finding > the transport) if new headers are introduced later. > > An alternative approach could perhaps be to set aside a small range of > protocol values for future extension headers? I do not think it is an alternative approach. The values tell its an extension header (and are required look at my previous mail) and follows the format defined, but the structure still needs to be defined. Thanks, Vishwas >> - Wes >> >> -----Original Message----- >> From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of >> Brian Haberman >> Sent: Monday, April 26, 2010 8:17 AM >> To: IPv6 WG Mailing List >> Subject: Consensus call on adopting draft-krishnan-ipv6-exthdr >> >> All, >> =A0 =A0 =A0The 6MAN chairs would like feedback from the working group on >> adopting draft-krishnan-ipv6-exthdr as a WG item. =A0Please send your >> comments/opinions to the mailing list (or the chairs) by May 7, 2010. >> >> Regards, >> Brian & Bob >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list >> ipv6@ietf.org >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >> ----------------------------------------------------------