From owner-ipng@sunroof.eng.sun.com Fri Dec 1 00:57:51 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta1+Sun/8.11.2.Beta1) id eB18tRo03208 for ipng-dist; Fri, 1 Dec 2000 00:55:27 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.2.Beta1+Sun/8.11.2.Beta1) with ESMTP id eB18tDr03201 for ; Fri, 1 Dec 2000 00:55:13 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id AAA13214 for ; Fri, 1 Dec 2000 00:55:12 -0800 (PST) Received: from melimelo.enst-bretagne.fr (melimelo.enst-bretagne.fr [192.108.115.36]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id AAA12613 for ; Fri, 1 Dec 2000 00:55:10 -0800 (PST) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by melimelo.enst-bretagne.fr (8.10.1/8.10.1) with ESMTP id eB18sO426408; Fri, 1 Dec 2000 09:54:24 +0100 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id JAA04652; Fri, 1 Dec 2000 09:54:23 +0100 (MET) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.9.3/8.9.3) with ESMTP id JAA10043; Fri, 1 Dec 2000 09:54:31 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200012010854.JAA10043@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Brian E Carpenter cc: itojun@iijlab.net, "'ipng@sunroof.eng.sun.com'" Subject: Re: Usage of IPv6 flow label In-reply-to: Your message of Thu, 30 Nov 2000 10:57:30 CST. <3A2686FA.E7441E7B@hursley.ibm.com> Date: Fri, 01 Dec 2000 09:54:31 +0100 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: - figure out a way to make the other option in Alex's draft: 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0| Server Port Number| H-to-H protocol| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ suitable for use by policy-driven diffserv classifiers. => can you explain why it is not enough to use the SPI in place of higher layer selectors? Francis.Dupont@enst-bretagne.fr -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Dec 1 02:40:38 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta1+Sun/8.11.2.Beta1) id eB1AdBb03466 for ipng-dist; Fri, 1 Dec 2000 02:39:11 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.2.Beta1+Sun/8.11.2.Beta1) with ESMTP id eB1Ad2r03459 for ; Fri, 1 Dec 2000 02:39:02 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id CAA05919 for ; Fri, 1 Dec 2000 02:39:01 -0800 (PST) Received: from givenchy (mailhost.6wind.com [212.234.238.114]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id CAA15914 for ; Fri, 1 Dec 2000 02:38:59 -0800 (PST) Received: from intranet.6wind.com (intranet.6wind.com [10.0.0.113]) by givenchy (Postfix) with ESMTP id 80188A04; Fri, 1 Dec 2000 11:41:48 +0100 (CET) Received: from 6wind.com (intranet [10.0.0.113]) by intranet.6wind.com (Postfix) with ESMTP id 5D545DBB2; Fri, 1 Dec 2000 11:41:00 -0600 (CST) Message-ID: <3A27E2AC.F2362921@6wind.com> Date: Fri, 01 Dec 2000 11:41:00 -0600 From: Alain RITOUX Organization: 6WIND X-Mailer: Mozilla 4.72 [fr] (X11; U; Linux 2.2.14-6.1.1smp i686) X-Accept-Language: en MIME-Version: 1.0 To: itojun@iijlab.net, ettikan@mmu.edu.my Cc: ipng@sunroof.eng.sun.com Subject: Comments on ANYCAST analysis. Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi, Before all, thanks for clarifying the anycast subject ! For TCP connections, or UDP with suspicious clients, it seems to me the pb is quiet the same as for mobile node acces, hence why not use the same solution ? The anycast server (who knows it owns an anycats @) can play the role of a mobile, using its anycats @ as Home-@, and one of its current @ as Co@. By using the Home Address option the UDP client won't know the difference, and if necessary (for TCP), it can also send Binding Update options, to be sure to be the one and onlmy server speaking with this client. Then the client would not have to know wether the @ its using is anycast or not. Does it make sense or did I miss something ? Best regards. Alain. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Dec 1 02:44:58 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta1+Sun/8.11.2.Beta1) id eB1Ai6D03516 for ipng-dist; Fri, 1 Dec 2000 02:44:06 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.2.Beta1+Sun/8.11.2.Beta1) with ESMTP id eB1Ahtr03509 for ; Fri, 1 Dec 2000 02:43:56 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id CAA15379 for ; Fri, 1 Dec 2000 02:43:55 -0800 (PST) Received: from coconut.itojun.org (coconut.itojun.org [210.160.95.97]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA11351 for ; Fri, 1 Dec 2000 02:43:54 -0800 (PST) Received: from kiwi.itojun.org (localhost.itojun.org [127.0.0.1]) by coconut.itojun.org (8.9.3+3.2W/3.7W) with ESMTP id TAA11044; Fri, 1 Dec 2000 19:42:54 +0900 (JST) To: Alain RITOUX cc: ettikan@mmu.edu.my, ipng@sunroof.eng.sun.com In-reply-to: alain.ritoux's message of Fri, 01 Dec 2000 11:41:00 CST. <3A27E2AC.F2362921@6wind.com> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: Comments on ANYCAST analysis. From: itojun@iijlab.net Date: Fri, 01 Dec 2000 19:42:54 +0900 Message-ID: <11042.975667374@coconut.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >Before all, thanks for clarifying the anycast subject ! > >For TCP connections, or UDP with suspicious clients, it seems to me the >pb is quiet the same as for mobile node acces, hence why not use the >same solution ? >The anycast server (who knows it owns an anycats @) can play the role of >a mobile, using its anycats @ as Home-@, and one of its current @ as >Co@. By using the Home Address option the UDP client won't know the >difference, and if necessary (for TCP), the document (01 revision) has a comment about the use of home address option for overriding source address. it was suggested (by Steve Deering and other folks) that, home address option should have the same restriction as the IPv6 source address field, so use of multicast/anycast is discouraged. the problem if we use multicast/anycast as the source is, we cannot identify single node as the source. we need a consensus on this, and also we need explcit notice on spec. >it can also send Binding Update >options, to be sure to be the one and onlmy server speaking with this >client. >Then the client would not have to know wether the @ its using is anycast >or not. it is not mandatory for an IPv6 nodes to have binding cache, so binding update may not work. also, how can you establish IPsec keys while using anycast address? itojun -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Dec 1 03:31:10 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta1+Sun/8.11.2.Beta1) id eB1BTZb03582 for ipng-dist; Fri, 1 Dec 2000 03:29:35 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.2.Beta1+Sun/8.11.2.Beta1) with ESMTP id eB1BTHr03567 for ; Fri, 1 Dec 2000 03:29:17 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id DAA19056 for ; Fri, 1 Dec 2000 03:29:17 -0800 (PST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA13389 for ; Fri, 1 Dec 2000 03:29:16 -0800 (PST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA23313; Fri, 1 Dec 2000 06:29:14 -0500 (EST) Message-Id: <200012011129.GAA23313@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ipng@sunroof.eng.sun.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipngwg-ipaddressassign-01.txt Date: Fri, 01 Dec 2000 06:29:13 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPNG Working Group of the IETF. Title : A method for flexible IPv6 address assignments Author(s) : M. Blanchet Filename : draft-ietf-ipngwg-ipaddressassign-01.txt Pages : 13 Date : 30-Nov-00 This document presents a method that helps organisations that makes addressing plan for IP addresses. The flexibility enables the organisation to postpone the final decision on the number of bits to partition in the address space they have. It does it by keeping the bits around the borders of the partition to be free as long as possible. This scheme is applicable to any bits addressing scheme using bits with partitions in the space, but its first intended use is for IPv6. It is a generalization of RFC1219 and can be used for IPv6 assignments based on RFC2373 and RFC2374. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipngwg-ipaddressassign-01.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipngwg-ipaddressassign-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipngwg-ipaddressassign-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. 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: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20001130114211.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipngwg-ipaddressassign-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipngwg-ipaddressassign-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20001130114211.I-D@ietf.org> --OtherAccess-- --NextPart-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Dec 1 03:31:23 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta1+Sun/8.11.2.Beta1) id eB1BTdj03583 for ipng-dist; Fri, 1 Dec 2000 03:29:39 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.2.Beta1+Sun/8.11.2.Beta1) with ESMTP id eB1BTMr03575 for ; Fri, 1 Dec 2000 03:29:22 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id DAA19064 for ; Fri, 1 Dec 2000 03:29:21 -0800 (PST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA13449 for ; Fri, 1 Dec 2000 03:29:21 -0800 (PST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA23371; Fri, 1 Dec 2000 06:29:19 -0500 (EST) Message-Id: <200012011129.GAA23371@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ipng@sunroof.eng.sun.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipngwg-addrconf-privacy-04.txt Date: Fri, 01 Dec 2000 06:29:18 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPNG Working Group of the IETF. Title : Privacy Extensions for Stateless Address Autoconfiguration in IPv6 Author(s) : T. Narten, R. Draves Filename : draft-ietf-ipngwg-addrconf-privacy-04.txt Pages : 17 Date : 30-Nov-00 Nodes use IPv6 stateless address autoconfiguration to generate addresses without the necessity of a DHCP server. Addresses are formed by combining network prefixes with an interface identifier. On interfaces that contain embedded IEEE Identifiers, the interface identifier is typically derived from it. On other interface types, the interface identifier is generated through other means, for example, via random number generation. This document describes an extension to IPv6 stateless address autoconfiguration for interfaces whose interface identifier is derived from an IEEE identifier. Use of the extension causes nodes to generate global-scope addresses from interface identifiers that change over time, even in cases where the interface contains an embedded IEEE identifier. Changing the interface identifier (and the global-scope addresses generated from it) over time makes it more difficult for eavesdroppers and other information collectors to identify when different addresses used in different transactions actually correspond to the same node. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipngwg-addrconf-privacy-04.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipngwg-addrconf-privacy-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipngwg-addrconf-privacy-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. 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: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20001130114220.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipngwg-addrconf-privacy-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipngwg-addrconf-privacy-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20001130114220.I-D@ietf.org> --OtherAccess-- --NextPart-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Dec 1 07:16:59 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta1+Sun/8.11.2.Beta1) id eB1FDH803735 for ipng-dist; Fri, 1 Dec 2000 07:13:17 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.2.Beta1+Sun/8.11.2.Beta1) with ESMTP id eB1FD8r03728 for ; Fri, 1 Dec 2000 07:13:08 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id HAA18619 for ; Fri, 1 Dec 2000 07:12:57 -0800 (PST) Received: from mail.kebne.se (mail.kebne.se [212.209.134.151]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA05396 for ; Fri, 1 Dec 2000 07:12:56 -0800 (PST) Received: from xelthomase01 (XEL-THOMASE01 [10.0.9.60]) by mail.kebne.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id XXG8H3HV; Fri, 1 Dec 2000 16:12:59 +0100 Reply-To: From: "Thomas Eklund" To: "'Jim Bound'" Cc: "'Ipng \(E-Mail\)'" Subject: RE: Usage of IPv6 flow label Date: Fri, 1 Dec 2000 12:21:16 +0100 Message-ID: <31A473DBB655D21180850008C71E251A029492E6@mail.kebne.se> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) Importance: Normal In-Reply-To: <31A473DBB655D21180850008C71E251A030CFCAF@mail.kebne.se> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Jim, those end-to-end customers you refer do they have a service provider that can deliver their voice/video application all the way from the source to the destination without having to go through a transit provider? (Most of the 3GPP ISP cant) If not I dont see how the flow label could have a unique definition along several service providers. Then you will have to integrate your RSVP signalling from operator a to b and c and d and so forth and then we are back to the old scaling problem with RSVP. What I think they want is a combination of a per flow semantics in the access because a flow label only make sense there where it identifies a flow (TCP/UDP session). In the backbone the service provider wants to control his network and do traffic engineering for protection and restoration issues and to load balance the traffic in the backbone (goeas for both a mesh based or a ring based topology) and the only way to do this today is to use the mpls flow label. But in the backbone the flow label means that the routers have a chance to map incoming traffic onto a mpls tag which is just a traffic trunk - in other words do not confuse it with the session identifier that it represents in the access. So I want a dual semantic - per session identifier in the access - per traffic trunk identifier in the core And regarding diffserv and mpls. mpls optimizes the resources in a domain and do traffic engineering and load balancing etc depending on how flashy implementation you have. Diffserv on the other hand is per hop which is more a tool to optimize the router buffers according to the Qos model you chosse to you configure in your router. Diffserv though is a very nice QoS mechanism that is so generic that anything can me mapped onto it (mpls, intserv etc). But it is very unclear how you use diffserv over an entire domain (some people might clame that COPS is a solution - other do not)... Someone might ask whats the relationship between DSCP (per traffic trunk, 2^6) and flow label (per traffic class, 2^20) etc... -- thomas > -----Original Message----- > From: owner-ipng@sunroof.eng.sun.com > [mailto:owner-ipng@sunroof.eng.sun.com]On Behalf Of Jim Bound > Sent: den 27 november 2000 15:00 > To: Francis Dupont > Cc: Jim Bound; Alex Conta; Steve Deering; Michael Thomas; Jun-ichiro > itojun Hagino; Hesham Soliman (EPA); Metzler Jochen; Ipng (E-Mail); > bound@zk3.dec.com > Subject: Re: Usage of IPv6 flow label > > > > > > >=> I agree but in the real word IntServ stuff (then flow > label marking) > >is done by an edge router. If doesn't matter if the LAN > is fast enough > >(and it can be without too much money) and if clients and > edge routers > >collaborate. > > I don't agree. > > >=> What do you not agree about? I agree about the should but > not the will. > >Technical there is no reason to set the flow label in the > edge router but > >it is very common for not technical reason to see the edge > router doing > >the *Serv stuff on the behalf of the real source. > > There is no flowlabel to set today so don't tell me the real world is > using it. What they are using is the diffserv bits and other > mechanisms > for switching etc... > > This is a wide open option and discussion. As I said in prior mail > we may need to take a bit to define if the flow is rewritable. > > The cell phone or audio server will set the flowlabel. > > >=> it is not what happens today then we should not fordid > that the edge > >router rewrites the flow label. > > This is discussable and you must not have read my mail to > Thomas Eklund. > > Which is a good piece of work and I agree with Itojun's > presentation of > the flowlabel. Its set by the end node. > > >=> don't confuse the real and the ideal worlds. > > Excuse me. But lets go offline with this I will match the > customers in > the real world building real products who want the flowlabel > e2e and we > are talking 3GPP, Military Operations, and Video/Audio apps. > > The bottom line is many folks want to use this flowlabel and one of > those folks are those who want it from one client to another client > across the Internet and to NOT BE TOUCHED by a router. > > You should not confuse what exists today in IPv4 what can > exist in IPv6 > tomorrow. > > regards, > /jim > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Dec 1 07:37:37 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta1+Sun/8.11.2.Beta1) id eB1Fa8f03801 for ipng-dist; Fri, 1 Dec 2000 07:36:08 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.2.Beta1+Sun/8.11.2.Beta1) with ESMTP id eB1FZxr03794 for ; Fri, 1 Dec 2000 07:35:59 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id HAA03307 for ; Fri, 1 Dec 2000 07:35:56 -0800 (PST) Received: from cisco.com (jindo.cisco.com [171.69.11.73]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA15097 for ; Fri, 1 Dec 2000 08:35:55 -0700 (MST) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by cisco.com (8.8.8/2.5.1/Cisco List Logging/8.8.8) with ESMTP id HAA19919; Fri, 1 Dec 2000 07:35:54 -0800 (PST) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id HAA10766; Fri, 1 Dec 2000 07:35:53 -0800 (PST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14887.50521.704758.143316@thomasm-u1.cisco.com> Date: Fri, 1 Dec 2000 07:35:53 -0800 (PST) To: Cc: "'Jim Bound'" , "'Ipng \(E-Mail\)'" Subject: RE: Usage of IPv6 flow label In-Reply-To: <31A473DBB655D21180850008C71E251A029492E6@mail.kebne.se> References: <31A473DBB655D21180850008C71E251A030CFCAF@mail.kebne.se> <31A473DBB655D21180850008C71E251A029492E6@mail.kebne.se> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Thomas Eklund writes: > Jim, > those end-to-end customers you refer do they have a service provider that > can deliver their voice/video application all the way from the source to the > destination without having to go through a transit provider? (Most of the > 3GPP ISP cant) > > If not I dont see how the flow label could have a unique definition along > several service providers. Then you will have to integrate your RSVP > signalling from operator a to b and c and d and so forth and then we are > back to the old scaling problem with RSVP. 1) RSVP across multiple providers doesn't require write access to the five-tuple, so I don't see why it would require access to the flow label either. Sounds like you're conflating it with DSCP rewriting 2) Check out the RSVP aggregation work. Mike -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Dec 1 08:25:39 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta1+Sun/8.11.2.Beta1) id eB1GO5G03923 for ipng-dist; Fri, 1 Dec 2000 08:24:05 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.2.Beta1+Sun/8.11.2.Beta1) with ESMTP id eB1GNur03916 for ; Fri, 1 Dec 2000 08:23:57 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id IAA01777 for ; Fri, 1 Dec 2000 08:23:55 -0800 (PST) Received: from zcamail02.zca.compaq.com (zcamail02.zca.compaq.com [161.114.32.102]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA27221 for ; Fri, 1 Dec 2000 08:23:55 -0800 (PST) Received: by zcamail02.zca.compaq.com (Postfix, from userid 12345) id 97BB57544; Fri, 1 Dec 2000 08:23:58 -0800 (PST) Received: from anw.zk3.dec.com (wasted.zk3.dec.com [16.140.32.3]) by zcamail02.zca.compaq.com (Postfix) with ESMTP id 09A26746B; Fri, 1 Dec 2000 08:23:58 -0800 (PST) Received: from localhost by anw.zk3.dec.com (8.9.3/1.1.22.2/08Sep98-0251PM) id LAA0000699149; Fri, 1 Dec 2000 11:23:09 -0500 (EST) From: Jim Bound Message-Id: <200012011623.LAA0000699149@anw.zk3.dec.com> To: Brian E Carpenter Cc: itojun@iijlab.net, "Ipng (E-Mail)" , bound@zk3.dec.com Subject: Re: Usage of IPv6 flow label In-reply-to: Your message of "Wed, 29 Nov 2000 13:40:01 CST." <3A255B91.E6092614@hursley.ibm.com> Date: Fri, 01 Dec 2000 11:23:09 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk brian, just as a note I don't believe we need to know port numbers and this should have never been done except for ALGs. I do not think we should keep such nonsense continued in IPv6. /jim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Dec 1 08:42:17 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta1+Sun/8.11.2.Beta1) id eB1Gemx03977 for ipng-dist; Fri, 1 Dec 2000 08:40:48 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.2.Beta1+Sun/8.11.2.Beta1) with ESMTP id eB1Gedr03970 for ; Fri, 1 Dec 2000 08:40:40 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id IAA18893 for ; Fri, 1 Dec 2000 08:40:40 -0800 (PST) Received: from mailhub1.almaden.ibm.com (mailhub1.almaden.ibm.com [198.4.83.44]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA27583 for ; Fri, 1 Dec 2000 08:40:38 -0800 (PST) Received: from maui.almaden.ibm.com (maui.almaden.ibm.com [9.1.24.92]) by mailhub1.almaden.ibm.com (8.8.8/8.8.8) with ESMTP id IAA17508; Fri, 1 Dec 2000 08:41:29 -0800 Received: from hursley.ibm.com (gsine02.us.sine.ibm.com [9.14.6.42]) by maui.almaden.ibm.com (AIX4.3/8.9.3/8.7) with ESMTP id IAA27588; Fri, 1 Dec 2000 08:40:31 -0800 Message-ID: <3A27D3F0.C0995AE7@hursley.ibm.com> Date: Fri, 01 Dec 2000 10:38:08 -0600 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en,fr MIME-Version: 1.0 To: thomas.eklund@xelerated.com CC: "'Jim Bound'" , "'Ipng (E-Mail)'" Subject: Re: Usage of IPv6 flow label References: <31A473DBB655D21180850008C71E251A029492E6@mail.kebne.se> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Thomas Eklund wrote: .. > > But it is very unclear how you use diffserv over an entire domain (some > people might clame that COPS is a solution - other do not)... Someone might > ask whats the relationship between DSCP (per traffic trunk, 2^6) and flow > label (per traffic class, 2^20) etc... There are several misunderstandings of diffserv here. There is nothing about "traffic trunks" in the diffserv model. At a stretch, you can think of a DSCP as labelling a "service class", but formally it simply labels a "traffic aggregate", i.e. all the traffic that receives the same QOS treatment on a given hop. However, we *do* assume in the model that DSCP values are invariant across an entire domain, with the routers in the domain being centrally configured. That configuration may be done using COPS, or SNMP, or HTTP, or telnet, or by telefax for that matter - it's of no importance for this discussion. DSCP mutability applies at diffserv domain boundaries, which will typically be ISP/ISP boundaries or customet/ISP boundaries. As of today, there is *no* defined relationship between DSCP and Flow Label. But I tend to agree with Jim that defining the Flow Label as immutable across domain boundaries (as well as being visible in encrypted packets) has distinct advantages. Brian -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Dec 1 08:48:33 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta1+Sun/8.11.2.Beta1) id eB1GlZb04008 for ipng-dist; Fri, 1 Dec 2000 08:47:35 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.2.Beta1+Sun/8.11.2.Beta1) with ESMTP id eB1GlIr03993 for ; Fri, 1 Dec 2000 08:47:19 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id IAA24830 for ; Fri, 1 Dec 2000 08:47:18 -0800 (PST) Received: from ztxmail02.ztx.compaq.com (ztxmail02.ztx.compaq.com [161.114.1.206]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA02180 for ; Fri, 1 Dec 2000 08:47:17 -0800 (PST) Received: by ztxmail02.ztx.compaq.com (Postfix, from userid 12345) id 7182F1CC7; Fri, 1 Dec 2000 10:47:17 -0600 (CST) Received: from anw.zk3.dec.com (wasted.zk3.dec.com [16.140.32.3]) by ztxmail02.ztx.compaq.com (Postfix) with ESMTP id 087A01DD4; Fri, 1 Dec 2000 10:47:17 -0600 (CST) Received: from localhost by anw.zk3.dec.com (8.9.3/1.1.22.2/08Sep98-0251PM) id LAA0000702696; Fri, 1 Dec 2000 11:47:16 -0500 (EST) From: Jim Bound Message-Id: <200012011647.LAA0000702696@anw.zk3.dec.com> To: Metzler Jochen Cc: "'Elwyn Davies'" , "'ipng@sunroof.eng.sun.com'" , bound@zk3.dec.com Subject: Re: AW: Usage of IPv6 flow label In-reply-to: Your message of "Thu, 30 Nov 2000 11:18:08 +0100." <158669A6D0F5D3119B940060086D94F55006F0@ULML202E> Date: Fri, 01 Dec 2000 11:47:16 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk i think the first battleground for ipv6 and the wg is what problem are we trying to solve and the different agendas/paradigms folks are wanting. Right now I see 3 camps me/itojun/jochen - e2e flowlabel initiated by the client/api brian/others - I want layer 4 information in the flowlabel alex/other - integrate mpls labels and some of brian above no one is ahead, none are cast in stone, no one has anything over the other...or more influence as to what the IETF consensus will be.... hmmm let the games begin but no one should think they are winning this and I think we need to hear from real customers and users too. /jim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Dec 1 08:52:47 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta1+Sun/8.11.2.Beta1) id eB1GpKs04046 for ipng-dist; Fri, 1 Dec 2000 08:51:20 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.2.Beta1+Sun/8.11.2.Beta1) with ESMTP id eB1GpAr04036 for ; Fri, 1 Dec 2000 08:51:11 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id IAA07842 for ; Fri, 1 Dec 2000 08:51:10 -0800 (PST) Received: from porsta.cs.Helsinki.FI (porsta.cs.Helsinki.FI [128.214.48.124]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA08288 for ; Fri, 1 Dec 2000 08:51:09 -0800 (PST) Received: from tiirakari.cs.Helsinki.FI (amlaukka@tiirakari.cs.Helsinki.FI [128.214.10.167]) by porsta.cs.Helsinki.FI (8.8.8/8.8.8) with ESMTP id SAA03190 for ; Fri, 1 Dec 2000 18:51:08 +0200 Date: Fri, 1 Dec 2000 18:51:13 +0200 (EET) From: Aki M Laukkanen To: Ipng Subject: Q: Negative acknowledgement in neighbor advertisements Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Just a small question, why is there not an option/flag for negative acknowledgements in the neighbor advertisements? It could be used to significantly shorten the delay for DAD in some link layers. Or is it expected that link-layers guarantee the uniqueness of the interface identifiers on the link so there is no need to perform DAD? Other uses would be faster feedback for applications etc. Aki -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Dec 1 09:04:04 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta1+Sun/8.11.2.Beta1) id eB1H2XT04119 for ipng-dist; Fri, 1 Dec 2000 09:02:33 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.2.Beta1+Sun/8.11.2.Beta1) with ESMTP id eB1H2Or04112 for ; Fri, 1 Dec 2000 09:02:24 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id JAA10773 for ; Fri, 1 Dec 2000 09:02:23 -0800 (PST) Received: from ztxmail02.ztx.compaq.com (ztxmail02.ztx.compaq.com [161.114.1.206]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA09848 for ; Fri, 1 Dec 2000 09:02:21 -0800 (PST) Received: by ztxmail02.ztx.compaq.com (Postfix, from userid 12345) id 142FF1EAA; Fri, 1 Dec 2000 11:02:21 -0600 (CST) Received: from anw.zk3.dec.com (wasted.zk3.dec.com [16.140.32.3]) by ztxmail02.ztx.compaq.com (Postfix) with ESMTP id A154C1ECB; Fri, 1 Dec 2000 11:02:20 -0600 (CST) Received: from localhost by anw.zk3.dec.com (8.9.3/1.1.22.2/08Sep98-0251PM) id MAA0000704626; Fri, 1 Dec 2000 12:02:20 -0500 (EST) From: Jim Bound Message-Id: <200012011702.MAA0000704626@anw.zk3.dec.com> To: Brian E Carpenter Cc: itojun@iijlab.net, "'ipng@sunroof.eng.sun.com'" , bound@zk3.dec.com Subject: Re: Usage of IPv6 flow label In-reply-to: Your message of "Thu, 30 Nov 2000 10:57:30 CST." <3A2686FA.E7441E7B@hursley.ibm.com> Date: Fri, 01 Dec 2000 12:02:19 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk brian, I like this better. if leftmost bit is set in flowlabel then it can be used for diffsv and alex strategy or port numbers or whatever you want for layer 4 switch/diff/etc... if leftmost bit is not set then client sets it and is used as itojuns api suggests and jochen. and the orginal intention in SIP and IPv6. fred baker proposed this sometime ago when thoughts generated using it for mpls. /jim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Dec 1 09:11:12 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta1+Sun/8.11.2.Beta1) id eB1HAEB04153 for ipng-dist; Fri, 1 Dec 2000 09:10:14 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.2.Beta1+Sun/8.11.2.Beta1) with ESMTP id eB1HA5r04146 for ; Fri, 1 Dec 2000 09:10:05 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id JAA13472 for ; Fri, 1 Dec 2000 09:10:05 -0800 (PST) Received: from mailhub1.almaden.ibm.com (mailhub1.almaden.ibm.com [198.4.83.44]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA13824 for ; Fri, 1 Dec 2000 09:10:02 -0800 (PST) Received: from maui.almaden.ibm.com (maui.almaden.ibm.com [9.1.24.92]) by mailhub1.almaden.ibm.com (8.8.8/8.8.8) with ESMTP id JAA27942; Fri, 1 Dec 2000 09:10:52 -0800 Received: from hursley.ibm.com (gsine02.us.sine.ibm.com [9.14.6.42]) by maui.almaden.ibm.com (AIX4.3/8.9.3/8.7) with ESMTP id JAA32430; Fri, 1 Dec 2000 09:09:59 -0800 Message-ID: <3A27DAD0.A11AD7F8@hursley.ibm.com> Date: Fri, 01 Dec 2000 11:07:28 -0600 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en,fr MIME-Version: 1.0 To: Francis Dupont CC: itojun@iijlab.net, "'ipng@sunroof.eng.sun.com'" Subject: Re: Usage of IPv6 flow label References: <200012010854.JAA10043@givry.rennes.enst-bretagne.fr> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Francis, Francis Dupont wrote: > > In your previous mail you wrote: > > - figure out a way to make the other option in Alex's draft: > > 0 1 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |0| Server Port Number| H-to-H protocol| > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > suitable for use by policy-driven diffserv classifiers. > > => can you explain why it is not enough to use the SPI in place of > higher layer selectors? The SPI doesn't have the semantics. A QOS classifier needs to *know* the port and protocol numbers; that's how it takes its decisions. For example you might put traffic with protocol number 30 in a different class from traffic with protocol number 41. Alex's idea of using "server port number" is in fact interesting, since it would allow you to classify traffic on its original well-known port #, without having to rely on dynamically assigned port #s for classification. I'm beginning to think he may be right. But I suggest allocating 11 bits to the port number and 8 to the protocol number, so that we can cover at least some of the registered ports (up to 2047). But the flow label isn't long enough for everything we need. Brian -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Dec 1 09:49:36 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta1+Sun/8.11.2.Beta1) id eB1Hm2E04219 for ipng-dist; Fri, 1 Dec 2000 09:48:02 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.2.Beta1+Sun/8.11.2.Beta1) with ESMTP id eB1Hlrr04212 for ; Fri, 1 Dec 2000 09:47:53 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id JAA24733 for ; Fri, 1 Dec 2000 09:47:53 -0800 (PST) Received: from melimelo.enst-bretagne.fr (melimelo.enst-bretagne.fr [192.108.115.36]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA02538 for ; Fri, 1 Dec 2000 09:47:52 -0800 (PST) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by melimelo.enst-bretagne.fr (8.10.1/8.10.1) with ESMTP id eB1HlJ418951; Fri, 1 Dec 2000 18:47:19 +0100 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id SAA25387; Fri, 1 Dec 2000 18:47:18 +0100 (MET) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.9.3/8.9.3) with ESMTP id SAA13773; Fri, 1 Dec 2000 18:47:29 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200012011747.SAA13773@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Aki M Laukkanen cc: Ipng Subject: Re: Q: Negative acknowledgement in neighbor advertisements In-reply-to: Your message of Fri, 01 Dec 2000 18:51:13 +0200. Date: Fri, 01 Dec 2000 18:47:29 +0100 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: Just a small question, why is there not an option/flag for negative acknowledgements in the neighbor advertisements? => who is supposed to send this? If the link is point-to-point then DAD is not issue because the link-layer (PPP) is supposed to guarantee no interface ID collision. If the link is not point-to-point then no neighbor should answer on the behalf of others. Other uses would be faster feedback for applications etc. => on a point-to-point link most neighbor discovery functions are not used... Francis.Dupont@enst-bretagne.fr -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Dec 1 09:55:09 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta1+Sun/8.11.2.Beta1) id eB1Hs8N04241 for ipng-dist; Fri, 1 Dec 2000 09:54:08 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.2.Beta1+Sun/8.11.2.Beta1) with ESMTP id eB1Hrxr04234 for ; Fri, 1 Dec 2000 09:53:59 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id JAA07355 for ; Fri, 1 Dec 2000 09:53:54 -0800 (PST) Received: from zcamail01.zca.compaq.com (zcamail01.zca.compaq.com [161.114.32.101]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA08784 for ; Fri, 1 Dec 2000 09:53:54 -0800 (PST) Received: by zcamail01.zca.compaq.com (Postfix, from userid 12345) id A515517C3; Fri, 1 Dec 2000 09:55:16 -0800 (PST) Received: from anw.zk3.dec.com (wasted.zk3.dec.com [16.140.32.3]) by zcamail01.zca.compaq.com (Postfix) with ESMTP id 1E236148C; Fri, 1 Dec 2000 09:55:16 -0800 (PST) Received: from localhost by anw.zk3.dec.com (8.9.3/1.1.22.2/08Sep98-0251PM) id MAA0000710526; Fri, 1 Dec 2000 12:53:52 -0500 (EST) From: Jim Bound Message-Id: <200012011753.MAA0000710526@anw.zk3.dec.com> To: Cc: "'Jim Bound'" , "'Ipng (E-Mail)'" , bound@zk3.dec.com Subject: Re: Usage of IPv6 flow label In-reply-to: Your message of "Fri, 01 Dec 2000 12:21:16 +0100." <31A473DBB655D21180850008C71E251A029492E6@mail.kebne.se> Date: Fri, 01 Dec 2000 12:53:52 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Thomas, >those end-to-end customers you refer do they have a service provider that >can deliver their voice/video application all the way from the source to the >destination without having to go through a transit provider? (Most of the >3GPP ISP cant) Some yes as they control completely their Internet (which is also mobile and an interesting property). But most have the $$$$$$$$ to force the SLAs yes. /jim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Dec 1 10:08:38 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta1+Sun/8.11.2.Beta1) id eB1I6wN04291 for ipng-dist; Fri, 1 Dec 2000 10:06:58 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.2.Beta1+Sun/8.11.2.Beta1) with ESMTP id eB1I6nr04284 for ; Fri, 1 Dec 2000 10:06:49 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id KAA29007 for ; Fri, 1 Dec 2000 10:06:49 -0800 (PST) Received: from mail2.microsoft.com (mail2.microsoft.com [131.107.3.124]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id KAA13001 for ; Fri, 1 Dec 2000 10:06:47 -0800 (PST) Received: from 157.54.9.104 by mail2.microsoft.com (InterScan E-Mail VirusWall NT); Fri, 01 Dec 2000 10:06:46 -0800 (Pacific Standard Time) Received: by inet-imc-02.redmond.corp.microsoft.com with Internet Mail Service (5.5.2651.58) id ; Fri, 1 Dec 2000 10:06:25 -0800 Message-ID: From: Christian Huitema To: "'Brian E Carpenter'" , Francis Dupont Cc: itojun@iijlab.net, "'ipng@sunroof.eng.sun.com'" Subject: RE: Usage of IPv6 flow label Date: Fri, 1 Dec 2000 09:56:46 -0800 X-Mailer: Internet Mail Service (5.5.2651.58) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Brian Carpenter wrote: > > Francis Dupont wrote: > > > > In your previous mail you wrote: > > > > - figure out a way to make the other option in Alex's draft: > > > > 0 1 > > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > |0| Server Port Number| H-to-H protocol| > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > suitable for use by policy-driven diffserv classifiers. > > > > => can you explain why it is not enough to use the SPI in place of > > higher layer selectors? > > The SPI doesn't have the semantics. A QOS classifier needs to *know* > the port and protocol numbers; that's how it takes its decisions. > For example you might put traffic with protocol number 30 in a > different class from traffic with protocol number 41. > > Alex's idea of using "server port number" is in fact > interesting, since it would allow you to classify traffic > on its original well-known port #, without having to rely > on dynamically assigned port #s for classification. > I'm beginning to think he may be right. But I suggest > allocating 11 bits to the port number and 8 to the > protocol number, so that we can cover at least > some of the registered ports (up to 2047). But the flow > label isn't long enough for everything we need. What is useful for the policy decision is to have an indication of the user priviledges and then an indication of the application. Most policy decisions are about given some users some guaranties that they can run some applications. Addresses are only approximative indications of the users -- think about proxies, mobility, etc. -- and ports are only approximative indications of the application -- think about floating ports, applications multiplexed over HTTP, etc. Having a protocol + port indication in the flow id is a way to provide an indication about the indication. But we can do better than having a protocol + port tuple. What we really want is some registry of applications, into which we could fold the registered ports; then, once the registration becomes well known, it becomes easy to write rules that allow for packet classification. If we start from this registration perspective, then we want a format that allows for several classes: * Inherit registration from current registration of TCP and UDP ports -- probably two classes, * One class registration of new applications, e.g. provide codes for those applications that currently work on floating ports, * One class for non-registered applications, allowing for experimentation, * A null label for users who don't want to disclose what application they are running. If we do that, then the end system can easily set the application code, and the intermediate routers can easily use them. -- Christian Huitema -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Dec 1 10:24:18 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta1+Sun/8.11.2.Beta1) id eB1IMWC04326 for ipng-dist; Fri, 1 Dec 2000 10:22:32 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.2.Beta1+Sun/8.11.2.Beta1) with ESMTP id eB1IMNr04319 for ; Fri, 1 Dec 2000 10:22:23 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id KAA04351 for ; Fri, 1 Dec 2000 10:22:23 -0800 (PST) Received: from melimelo.enst-bretagne.fr (melimelo.enst-bretagne.fr [192.108.115.36]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA00231 for ; Fri, 1 Dec 2000 11:22:20 -0700 (MST) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by melimelo.enst-bretagne.fr (8.10.1/8.10.1) with ESMTP id eB1ILh426867; Fri, 1 Dec 2000 19:21:43 +0100 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id TAA26762; Fri, 1 Dec 2000 19:21:42 +0100 (MET) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.9.3/8.9.3) with ESMTP id TAA13934; Fri, 1 Dec 2000 19:21:54 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200012011821.TAA13934@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Brian E Carpenter cc: itojun@iijlab.net, "'ipng@sunroof.eng.sun.com'" Subject: Re: Usage of IPv6 flow label In-reply-to: Your message of Fri, 01 Dec 2000 11:07:28 CST. <3A27DAD0.A11AD7F8@hursley.ibm.com> Date: Fri, 01 Dec 2000 19:21:54 +0100 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: > => can you explain why it is not enough to use the SPI in place of > higher layer selectors? The SPI doesn't have the semantics. => I disagree, the SPI has the semantics we'd like to give to it. A QOS classifier needs to *know* the port and protocol numbers; that's how it takes its decisions. => I can't see a deep difference between a QoS classifier and a SPD entry. For example you might put traffic with protocol number 30 in a different class from traffic with protocol number 41. => and you might use a different SPI... I can't see why it is possible to associate to some kind of flow a 24 bit pseudo-random number (the flow label) and not a 32 bit pseudo-random number (the SPI). Alex's idea of using "server port number" is in fact interesting, since it would allow you to classify traffic on its original well-known port #, without having to rely on dynamically assigned port #s for classification. => I don't like the idea to have an official cover-channel with the flow label: security people won't buy this. They'd like to hide things then they can express their policy (ie. what they accept to reveal) into the SPD then the choice of SPIs... But the flow label isn't long enough for everything we need. => the SPI is 32 bit long (:-)! Regards Francis.Dupont@enst-bretagne.fr PS: I am in no camp. I believe Jim/Itojun/... are right but the flow label is not protected by AH then a router may rewrite it. As it is not a stack it should be rewritten only closed to the source (ie. if you want to rewrite it anywhere you should encapsulate packets before, the decapsulation will restore the original flow label). In the future I can see two cases: - the flow label is set by the source (first camp) - the flow label is set by an edge router (with the DiffServ definition of what is an edge router) because the source box (or its user) is too dumb to deal with QoS/..., according to the edge router manager. I think we'll get a mixed situation. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Dec 1 10:27:58 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta1+Sun/8.11.2.Beta1) id eB1IQi304369 for ipng-dist; Fri, 1 Dec 2000 10:26:44 -0800 (PST) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.11.2.Beta1+Sun/8.11.2.Beta1) with ESMTP id eB1IQdr04362 for ; Fri, 1 Dec 2000 10:26:39 -0800 (PST) Received: (from jrh@localhost) by stinker.eng.sun.com (8.11.0+Sun/8.11.0) id eB1IPQD09218 for ipng@sunroof.eng.sun.com; Fri, 1 Dec 2000 10:25:26 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.2.Beta1+Sun/8.11.2.Beta1) with ESMTP id eB1AeYr03468 for ; Fri, 1 Dec 2000 02:40:34 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id CAA14924 for ; Fri, 1 Dec 2000 02:40:34 -0800 (PST) Received: from un.cct.ydc.co.jp (ydcspingw.ydc.co.jp [202.33.211.252]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA07491 for ; Fri, 1 Dec 2000 02:40:32 -0800 (PST) Received: from odin.akisada.tahi.org (IDENT:akisada@[10.21.0.198]) by un.cct.ydc.co.jp (8.9.1+3.1W/3.7W) with SMTP id TAA12817 for ; Fri, 1 Dec 2000 19:43:20 +0900 (JST) Message-Id: <200012011043.TAA12817@un.cct.ydc.co.jp> Date: Fri, 1 Dec 2000 19:40:50 +0900 From: Yukiyo Akisada To: ipng@sunroof.eng.sun.com Subject: TAHI IPv6 Conformance Test Packages X-Mailer: Sylpheed version 0.4.6 (GTK+ 1.2.8; Linux 2.4.0-test11; i686) Organization: YDC Corporation Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi there, TAHI Project has released the IPv6 Conformance Test Packages at the following web site: http://www.tahi.org/ Changes from the previous release of the IPv6 Conformance Test Packages: The Test Tool (Release-1.2): - support MIP6 The Test Program (Release-1.2): - some bug fix Thanks, --- Yukiyo Akisada @ TAHI Project -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Dec 1 11:50:29 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta1+Sun/8.11.2.Beta1) id eB1Jn0704488 for ipng-dist; Fri, 1 Dec 2000 11:49:00 -0800 (PST) Received: from eastmail1.East.Sun.COM (eastmail1.East.Sun.COM [129.148.1.240]) by sunroof.eng.sun.com (8.11.2.Beta1+Sun/8.11.2.Beta1) with ESMTP id eB1Jmmr04481 for ; Fri, 1 Dec 2000 11:48:49 -0800 (PST) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail1.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id OAA01362; Fri, 1 Dec 2000 14:48:47 -0500 (EST) Received: from thunk (localhost [127.0.0.1]) by thunk.east.sun.com (8.11.1+Sun/8.10.2) with ESMTP id eB1Jm6a105457; Fri, 1 Dec 2000 14:48:06 -0500 (EST) Message-Id: <200012011948.eB1Jm6a105457@thunk.east.sun.com> From: Bill Sommerfeld To: Francis Dupont cc: Brian E Carpenter , itojun@iijlab.net, "'ipng@sunroof.eng.sun.com'" Subject: Re: Usage of IPv6 flow label In-reply-to: Your message of "Fri, 01 Dec 2000 19:21:54 +0100." <200012011821.TAA13934@givry.rennes.enst-bretagne.fr> Reply-to: sommerfeld@east.sun.com Date: Fri, 01 Dec 2000 14:48:06 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > The SPI doesn't have the semantics. > > => I disagree, the SPI has the semantics we'd like to give to it. When reasonable key management protocols are in use, IPSEC SPI's are pseudo-random, chosen by the receiver, and securely communicated to the sender via the key management protocol. The use of random spi's is one of the defenses against off-path denial-of-service attacks.. an off-path attacker forging source addresses cannot easily guess a valid SPI, and so packets with invalid SPI's can be quickly discarded without requiring any cryptographic processing. What semantics do you think you can impose on something like that? - Bill -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Dec 1 12:27:10 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta1+Sun/8.11.2.Beta1) id eB1KPfx04525 for ipng-dist; Fri, 1 Dec 2000 12:25:41 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.2.Beta1+Sun/8.11.2.Beta1) with ESMTP id eB1KPTr04518 for ; Fri, 1 Dec 2000 12:25:29 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id MAA14071 for ; Fri, 1 Dec 2000 12:25:28 -0800 (PST) Received: from mailhub1.almaden.ibm.com (mailhub1.almaden.ibm.com [198.4.83.44]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA18857 for ; Fri, 1 Dec 2000 12:25:25 -0800 (PST) Received: from maui.almaden.ibm.com (maui.almaden.ibm.com [9.1.24.92]) by mailhub1.almaden.ibm.com (8.8.8/8.8.8) with ESMTP id MAA35874; Fri, 1 Dec 2000 12:26:13 -0800 Received: from hursley.ibm.com (gsine02.us.sine.ibm.com [9.14.6.42]) by maui.almaden.ibm.com (AIX4.3/8.9.3/8.7) with ESMTP id MAA27644; Fri, 1 Dec 2000 12:25:22 -0800 Message-ID: <3A28084A.EB1265DD@hursley.ibm.com> Date: Fri, 01 Dec 2000 14:21:30 -0600 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en,fr MIME-Version: 1.0 To: Christian Huitema CC: Francis Dupont , itojun@iijlab.net, "'ipng@sunroof.eng.sun.com'" Subject: Re: Usage of IPv6 flow label References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Christian, see below... Christian Huitema wrote: > > Brian Carpenter wrote: > > > > Francis Dupont wrote: > > > > > > In your previous mail you wrote: > > > > > > - figure out a way to make the other option in Alex's draft: > > > > > > 0 1 > > > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > |0| Server Port Number| H-to-H protocol| > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > > > suitable for use by policy-driven diffserv classifiers. > > > > > > => can you explain why it is not enough to use the SPI in place of > > > higher layer selectors? > > > > The SPI doesn't have the semantics. A QOS classifier needs to *know* > > the port and protocol numbers; that's how it takes its decisions. > > For example you might put traffic with protocol number 30 in a > > different class from traffic with protocol number 41. > > > > Alex's idea of using "server port number" is in fact > > interesting, since it would allow you to classify traffic > > on its original well-known port #, without having to rely > > on dynamically assigned port #s for classification. > > I'm beginning to think he may be right. But I suggest > > allocating 11 bits to the port number and 8 to the > > protocol number, so that we can cover at least > > some of the registered ports (up to 2047). But the flow > > label isn't long enough for everything we need. > > What is useful for the policy decision is to have an indication of the user > priviledges and then an indication of the application. Most policy decisions > are about given some users some guaranties that they can run some > applications. Addresses are only approximative indications of the users -- > think about proxies, mobility, etc. -- and ports are only approximative > indications of the application -- think about floating ports, applications > multiplexed over HTTP, etc. > > Having a protocol + port indication in the flow id is a way to provide an > indication about the indication. But we can do better than having a protocol > + port tuple. What we really want is some registry of applications, into > which we could fold the registered ports; then, once the registration > becomes well known, it becomes easy to write rules that allow for packet > classification. If we start from this registration perspective, then we want > a format that allows for several classes: > * Inherit registration from current registration of TCP and UDP ports -- > probably two > classes, > * One class registration of new applications, e.g. provide codes for those > applications that > currently work on floating ports, > * One class for non-registered applications, allowing for experimentation, > * A null label for users who don't want to disclose what application they > are running. > If we do that, then the end system can easily set the application code, and > the intermediate routers can easily use them. Yes, some of these thoughts ran through my mind when I saw Alex's "IANA Assigned" field. But this amounts to proposing a whole new QOS classification mechanism, in addition to the existing one, which is only needed for the case of encrypted IPv6 packets. If we can do something like Alex's port/protocol proposal, we can trivially map the flow label into existing classification rules (with a wild card or two). Brian -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Dec 1 12:28:51 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta1+Sun/8.11.2.Beta1) id eB1KRnW04543 for ipng-dist; Fri, 1 Dec 2000 12:27:49 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.2.Beta1+Sun/8.11.2.Beta1) with ESMTP id eB1KRer04536 for ; Fri, 1 Dec 2000 12:27:40 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id MAA23902 for ; Fri, 1 Dec 2000 12:27:39 -0800 (PST) Received: from mailhub1.almaden.ibm.com (mailhub1.almaden.ibm.com [198.4.83.44]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA19929 for ; Fri, 1 Dec 2000 12:27:39 -0800 (PST) Received: from maui.almaden.ibm.com (maui.almaden.ibm.com [9.1.24.92]) by mailhub1.almaden.ibm.com (8.8.8/8.8.8) with ESMTP id MAA36758; Fri, 1 Dec 2000 12:28:27 -0800 Received: from hursley.ibm.com (gsine02.us.sine.ibm.com [9.14.6.42]) by maui.almaden.ibm.com (AIX4.3/8.9.3/8.7) with ESMTP id MAA24442; Fri, 1 Dec 2000 12:27:36 -0800 Message-ID: <3A2808CF.85E91EE6@hursley.ibm.com> Date: Fri, 01 Dec 2000 14:23:43 -0600 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en,fr MIME-Version: 1.0 To: Francis Dupont CC: itojun@iijlab.net, "'ipng@sunroof.eng.sun.com'" Subject: Re: Usage of IPv6 flow label References: <200012011821.TAA13934@givry.rennes.enst-bretagne.fr> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Francis, The bits used by a QOS classifier are *not* pseudo-random. They are actual port numbers and protocol numbers. You are comparing apples amd oranges. Brian Francis Dupont wrote: > > In your previous mail you wrote: > > > => can you explain why it is not enough to use the SPI in place of > > higher layer selectors? > > The SPI doesn't have the semantics. > > => I disagree, the SPI has the semantics we'd like to give to it. > > A QOS classifier needs to *know* > the port and protocol numbers; that's how it takes its decisions. > > => I can't see a deep difference between a QoS classifier and > a SPD entry. > > For example you might put traffic with protocol number 30 in a > different class from traffic with protocol number 41. > > => and you might use a different SPI... I can't see why it is > possible to associate to some kind of flow a 24 bit pseudo-random > number (the flow label) and not a 32 bit pseudo-random number > (the SPI). > > Alex's idea of using "server port number" is in fact > interesting, since it would allow you to classify traffic > on its original well-known port #, without having to rely > on dynamically assigned port #s for classification. > > => I don't like the idea to have an official cover-channel > with the flow label: security people won't buy this. > They'd like to hide things then they can express their policy > (ie. what they accept to reveal) into the SPD then the choice > of SPIs... > > But the flow label isn't long enough for everything we need. > > => the SPI is 32 bit long (:-)! > > Regards > > Francis.Dupont@enst-bretagne.fr > > PS: I am in no camp. I believe Jim/Itojun/... are right but the > flow label is not protected by AH then a router may rewrite it. > As it is not a stack it should be rewritten only closed to the source > (ie. if you want to rewrite it anywhere you should encapsulate packets > before, the decapsulation will restore the original flow label). > In the future I can see two cases: > - the flow label is set by the source (first camp) > - the flow label is set by an edge router (with the DiffServ definition > of what is an edge router) because the source box (or its user) is > too dumb to deal with QoS/..., according to the edge router manager. > I think we'll get a mixed situation. > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Dec 1 12:41:23 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta1+Sun/8.11.2.Beta1) id eB1Kdis04582 for ipng-dist; Fri, 1 Dec 2000 12:39:44 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.2.Beta1+Sun/8.11.2.Beta1) with ESMTP id eB1KdZr04575 for ; Fri, 1 Dec 2000 12:39:35 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id MAA17658 for ; Fri, 1 Dec 2000 12:39:34 -0800 (PST) Received: from mailhub1.almaden.ibm.com (mailhub1.almaden.ibm.com [198.4.83.44]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA18591 for ; Fri, 1 Dec 2000 12:39:33 -0800 (PST) Received: from maui.almaden.ibm.com (maui.almaden.ibm.com [9.1.24.92]) by mailhub1.almaden.ibm.com (8.8.8/8.8.8) with ESMTP id MAA22470; Fri, 1 Dec 2000 12:40:21 -0800 Received: from hursley.ibm.com (gsine02.us.sine.ibm.com [9.14.6.42]) by maui.almaden.ibm.com (AIX4.3/8.9.3/8.7) with ESMTP id MAA09618; Fri, 1 Dec 2000 12:39:31 -0800 Message-ID: <3A280B96.540D2E56@hursley.ibm.com> Date: Fri, 01 Dec 2000 14:35:34 -0600 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en,fr MIME-Version: 1.0 To: Jim Bound CC: itojun@iijlab.net, "Ipng (E-Mail)" Subject: Re: Usage of IPv6 flow label References: <200012011623.LAA0000699149@anw.zk3.dec.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk But Jim, this is how QOS works. Diffserv was carefully designed to be identical for IPv4 and IPv6 (we thought you'd be pleased :-) Brian Jim Bound wrote: > brian, > > just as a note I don't believe we need to know port numbers and this > should have never been done except for ALGs. I do not think we should > keep such nonsense continued in IPv6. > > /jim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Dec 1 14:14:51 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta1+Sun/8.11.2.Beta1) id eB1MDGu04753 for ipng-dist; Fri, 1 Dec 2000 14:13:16 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.2.Beta1+Sun/8.11.2.Beta1) with ESMTP id eB1MD7r04746 for ; Fri, 1 Dec 2000 14:13:07 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id OAA24906 for ; Fri, 1 Dec 2000 14:13:07 -0800 (PST) Received: from porsta.cs.Helsinki.FI (porsta.cs.Helsinki.FI [128.214.48.124]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA25890 for ; Fri, 1 Dec 2000 14:13:06 -0800 (PST) Received: from tiirakari.cs.Helsinki.FI (amlaukka@tiirakari.cs.Helsinki.FI [128.214.10.167]) by porsta.cs.Helsinki.FI (8.8.8/8.8.8) with ESMTP id AAA01115; Sat, 2 Dec 2000 00:13:02 +0200 Date: Sat, 2 Dec 2000 00:13:09 +0200 (EET) From: Aki M Laukkanen To: Francis Dupont cc: Ipng Subject: Re: Q: Negative acknowledgement in neighbor advertisements In-Reply-To: <200012011747.SAA13773@givry.rennes.enst-bretagne.fr> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Fri, 1 Dec 2000, Francis Dupont wrote: > Just a small question, why is there not an option/flag for negative > acknowledgements in the neighbor advertisements? > => who is supposed to send this? If the link is point-to-point then > DAD is not issue because the link-layer (PPP) is supposed to guarantee > no interface ID collision. If the link is not point-to-point then > no neighbor should answer on the behalf of others. Sorry, I should have been more specific and now I understand why this has not been addressed. There are links, I am not sure how to characterise them with one term, one-way shared links perhaps? These are multicast capable but have a central point of control i.e. the base station. Most wireless links could be modelled this way but few are in practice. Hiperlan (/2) is one such link. Most wireless links could be made to look like one. In this case, negative acknowledgement, no neighbor is going to answer on behalf of others but since the base station (Access Point) has knowledge of all the attached hosts, it could provide a negative acknowledgement. Aki -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Dec 1 14:57:41 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta1+Sun/8.11.2.Beta1) id eB1MuBG04810 for ipng-dist; Fri, 1 Dec 2000 14:56:11 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.2.Beta1+Sun/8.11.2.Beta1) with ESMTP id eB1Mu2r04803 for ; Fri, 1 Dec 2000 14:56:02 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id OAA25557 for ; Fri, 1 Dec 2000 14:56:03 -0800 (PST) Received: from melimelo.enst-bretagne.fr (melimelo.enst-bretagne.fr [192.108.115.36]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA26370; Fri, 1 Dec 2000 14:56:02 -0800 (PST) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by melimelo.enst-bretagne.fr (8.10.1/8.10.1) with ESMTP id eB1Mtx421611; Fri, 1 Dec 2000 23:55:59 +0100 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id XAA06417; Fri, 1 Dec 2000 23:55:58 +0100 (MET) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.9.3/8.9.3) with ESMTP id XAA17005; Fri, 1 Dec 2000 23:56:10 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200012012256.XAA17005@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: sommerfeld@east.sun.com cc: Brian E Carpenter , itojun@iijlab.net, "'ipng@sunroof.eng.sun.com'" Subject: Re: Usage of IPv6 flow label In-reply-to: Your message of Fri, 01 Dec 2000 14:48:06 EST. <200012011948.eB1Jm6a105457@thunk.east.sun.com> Date: Fri, 01 Dec 2000 23:56:10 +0100 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: > The SPI doesn't have the semantics. > > => I disagree, the SPI has the semantics we'd like to give to it. When reasonable key management protocols are in use, IPSEC SPI's are pseudo-random, chosen by the receiver, and securely communicated to the sender via the key management protocol. => the only problem is "chosen by the receiver" because the first packet will reveal the SPI to on-path attackers. The use of random spi's is one of the defenses against off-path denial-of-service attacks.. an off-path attacker forging source addresses cannot easily guess a valid SPI, and so packets with invalid SPI's can be quickly discarded without requiring any cryptographic processing. => they can be only discarded if you know valid SPIs, ie. by the receiving node (which can be overloaded just by a big number of packets) or if a firewall has the needed knowledge (ie. there is a protocol which gives new SPIs to it). What semantics do you think you can impose on something like that? => just associate a QoS to a SPI and send the information (ie. how to classify packets (addresses, ..., SPI) and the QoS) to the classifier (which is by definition on-path). Another solution is to ask the receiver to be less random (again the info will be spread only on-path). Regards Francis.Dupont@enst-bretagne.fr PS: I assumed in my previous mail than the trade-off was between flow labels and SPIs. If we considered that flow labels *can't* replace a part of famous 5-tuples then of course the same consideration applies to SPIs. PPS: Bill, as a IPsec person, would you like to have upper layer protocol and port revealed in flow labels? -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Dec 1 15:14:00 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta1+Sun/8.11.2.Beta1) id eB1NCYZ04853 for ipng-dist; Fri, 1 Dec 2000 15:12:34 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.2.Beta1+Sun/8.11.2.Beta1) with ESMTP id eB1NCPr04846 for ; Fri, 1 Dec 2000 15:12:25 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id PAA11556 for ; Fri, 1 Dec 2000 15:12:26 -0800 (PST) Received: from melimelo.enst-bretagne.fr (melimelo.enst-bretagne.fr [192.108.115.36]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA28609 for ; Fri, 1 Dec 2000 15:12:25 -0800 (PST) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by melimelo.enst-bretagne.fr (8.10.1/8.10.1) with ESMTP id eB1NBq426852; Sat, 2 Dec 2000 00:11:52 +0100 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id AAA06959; Sat, 2 Dec 2000 00:11:51 +0100 (MET) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.9.3/8.9.3) with ESMTP id AAA17095; Sat, 2 Dec 2000 00:12:04 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200012012312.AAA17095@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Aki M Laukkanen cc: Ipng Subject: Re: Q: Negative acknowledgement in neighbor advertisements In-reply-to: Your message of Sat, 02 Dec 2000 00:13:09 +0200. Date: Sat, 02 Dec 2000 00:12:04 +0100 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: Sorry, I should have been more specific and now I understand why this has not been addressed. There are links, I am not sure how to characterise them with one term, one-way shared links perhaps? These are multicast capable but have a central point of control i.e. the base station. Most wireless links could be modelled this way but few are in practice. Hiperlan (/2) is one such link. Most wireless links could be made to look like one. => these link-layers have no knowledge of the network addresses. In this case, negative acknowledgement, no neighbor is going to answer on behalf of others but since the base station (Access Point) has knowledge of all the attached hosts, it could provide a negative acknowledgement. => no because it knows only the MAC addresses of attached nodes. In order to provide what you describe you have to change the base station in a NHS (NHRP server if you don't know the acronym)... Regards Francis.Dupont@enst-bretagne.fr -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Dec 1 15:30:12 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta1+Sun/8.11.2.Beta1) id eB1NScT04904 for ipng-dist; Fri, 1 Dec 2000 15:28:38 -0800 (PST) Received: from eastmail2.East.Sun.COM (eastmail2.East.Sun.COM [129.148.1.241]) by sunroof.eng.sun.com (8.11.2.Beta1+Sun/8.11.2.Beta1) with ESMTP id eB1NSTr04897 for ; Fri, 1 Dec 2000 15:28:29 -0800 (PST) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail2.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id SAA06248; Fri, 1 Dec 2000 18:28:29 -0500 (EST) Received: from thunk (localhost [127.0.0.1]) by thunk.east.sun.com (8.11.1+Sun/8.10.2) with ESMTP id eB1NRna106997; Fri, 1 Dec 2000 18:27:50 -0500 (EST) Message-Id: <200012012327.eB1NRna106997@thunk.east.sun.com> From: Bill Sommerfeld To: Francis Dupont cc: sommerfeld@east.sun.com, Brian E Carpenter , itojun@iijlab.net, "'ipng@sunroof.eng.sun.com'" Subject: Re: Usage of IPv6 flow label In-reply-to: Your message of "Fri, 01 Dec 2000 23:56:10 +0100." <200012012256.XAA17005@givry.rennes.enst-bretagne.fr> Reply-to: sommerfeld@east.sun.com Date: Fri, 01 Dec 2000 18:27:49 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > What semantics do you think you can impose on something like that? > > => just associate a QoS to a SPI and send the information (ie. how to > classify packets (addresses, ..., SPI) and the QoS) to the classifier > (which is by definition on-path). That could be brute-forced into working if someone invented such a protocol. However, it seems that you could accomplish the same goal by having the originator of the traffic mark the diffserv bits of the packet "appropriately", with the classifier merely having some policy saying which nodes are allowed to send ipsec traffic with various markings, possibly translating the markings appropriately. > Another solution is to ask the receiver to be less random (again the > info will be spread only on-path). I doubt that this option would be acceptable to the ipsec community. > PPS: Bill, as a IPsec person, would you like to have upper layer protocol > and port revealed in flow labels? No, that leaks information useful to someone doing traffic analysis; I'd rather let the node doing the ipsec encapsulation mark it with a much coarser-grained QoS class. (besides, I'd just hack my implementation to let you configure the "most favorable treatment" port number in the flow label..) - Bill -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Dec 1 15:37:54 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta1+Sun/8.11.2.Beta1) id eB1NapB04948 for ipng-dist; Fri, 1 Dec 2000 15:36:51 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.2.Beta1+Sun/8.11.2.Beta1) with ESMTP id eB1Nagr04941 for ; Fri, 1 Dec 2000 15:36:42 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id PAA18375 for ; Fri, 1 Dec 2000 15:36:38 -0800 (PST) Received: from mailhub1.almaden.ibm.com (mailhub1.almaden.ibm.com [198.4.83.44]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id QAA06534; Fri, 1 Dec 2000 16:36:35 -0700 (MST) Received: from maui.almaden.ibm.com (maui.almaden.ibm.com [9.1.24.92]) by mailhub1.almaden.ibm.com (8.8.8/8.8.8) with ESMTP id PAA09814; Fri, 1 Dec 2000 15:37:20 -0800 Received: from hursley.ibm.com (gsine02.us.sine.ibm.com [9.14.6.42]) by maui.almaden.ibm.com (AIX4.3/8.9.3/8.7) with ESMTP id PAA24500; Fri, 1 Dec 2000 15:36:32 -0800 Message-ID: <3A2834A7.CDDCFD6C@hursley.ibm.com> Date: Fri, 01 Dec 2000 17:30:47 -0600 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en,fr MIME-Version: 1.0 To: Francis Dupont CC: sommerfeld@east.sun.com, itojun@iijlab.net, "'ipng@sunroof.eng.sun.com'" Subject: Re: Usage of IPv6 flow label References: <200012012256.XAA17005@givry.rennes.enst-bretagne.fr> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Francis Dupont wrote: ... > => just associate a QoS to a SPI and send the information (ie. how to > classify packets (addresses, ..., SPI) and the QoS) to the classifier > (which is by definition on-path). Wrong model. That requires signalling; diffserv doesn't have signalling. This works for RSVP as itojun explained, but it doesn't work for diffserv. Brian -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Dec 1 16:15:22 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta1+Sun/8.11.2.Beta1) id eB20Dig05016 for ipng-dist; Fri, 1 Dec 2000 16:13:44 -0800 (PST) Received: from jurassic.eng.sun.com (jurassic [129.146.82.166] (may be forged)) by sunroof.eng.sun.com (8.11.2.Beta1+Sun/8.11.2.Beta1) with ESMTP id eB20DXr05009 for ; Fri, 1 Dec 2000 16:13:33 -0800 (PST) Received: from lillen (awe174-18.AWE.Sun.COM [192.29.174.18]) by jurassic.eng.sun.com (8.11.2.Beta1+Sun/8.11.2.Beta1) with SMTP id eB20DXd592449; Fri, 1 Dec 2000 16:13:33 -0800 (PST) Date: Fri, 1 Dec 2000 16:13:02 -0800 (PST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: Q: Negative acknowledgement in neighbor advertisements To: Aki M Laukkanen Cc: Francis Dupont , Ipng In-Reply-To: "Your message with ID" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > In this case, negative acknowledgement, no neighbor is going to answer on > behalf of others but since the base station (Access Point) has knowledge of > all the attached hosts, it could provide a negative acknowledgement. I understand that in such cases the base station would know the link-layer addresses assigned to all the attached hosts. But how does it manage to track all the IPv6 addresses assigned to the hosts? The IPv6 addresses could be assigned using - stateless addrconf (based on the link layer address) - dhcpv6 (not necessarily based on the link layer address) - manually configured (not necessarily based on the lla) Since DAD doesn't know how the address was assigned and your optimization can't possible work for anything but statelessly configured addresses, I don't see how this can work. *IF* there will be a link-layer (called "foo") where the base station can ensure that the link layer addresses (actually, the 64 bit tokens) are unique on the link, it would be possible to specify in the IPv6-over-foo RFC that DAD isn't required for the statelessly configured IPv6 addresses (but required for all other addresses). Erik -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sat Dec 2 01:22:02 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta1+Sun/8.11.2.Beta1) id eB29KDv05487 for ipng-dist; Sat, 2 Dec 2000 01:20:13 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.2.Beta1+Sun/8.11.2.Beta1) with ESMTP id eB29K3r05480 for ; Sat, 2 Dec 2000 01:20:04 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id BAA15878; Sat, 2 Dec 2000 01:20:02 -0800 (PST) Received: from porsta.cs.Helsinki.FI (porsta.cs.Helsinki.FI [128.214.48.124]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id BAA03060; Sat, 2 Dec 2000 01:19:54 -0800 (PST) Received: from tiirakari.cs.Helsinki.FI (amlaukka@tiirakari.cs.Helsinki.FI [128.214.10.167]) by porsta.cs.Helsinki.FI (8.8.8/8.8.8) with ESMTP id LAA18780; Sat, 2 Dec 2000 11:19:53 +0200 Date: Sat, 2 Dec 2000 11:19:55 +0200 (EET) From: Aki M Laukkanen To: Erik Nordmark cc: Ipng Subject: Re: Q: Negative acknowledgement in neighbor advertisements In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Fri, 1 Dec 2000, Erik Nordmark wrote: Erik, > Since DAD doesn't know how the address was assigned and your optimization > can't possible work for anything but statelessly configured addresses, > I don't see how this can work. You are of course correct. > that DAD isn't required for the statelessly configured IPv6 addresses (but > required for all other addresses). Not requiring DAD for link-local addresses is a win already. Upon reception of a new IP address, the client MUST perform Duplicate Address Detection (DAD) as specified in RFC 2462 [19]. If the IP address has already been allocated to the How about if all hosts are required to set the 'I' and 'Q' flags in the IP address extension? In effect suggest addresses configured using SAA or other mechanisms. DAD has already been done for these addresses if needed. Then the server can either grant or deny the request. It is not explicitly said in there but why would DAD be needed in that case? Aki -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sat Dec 2 15:06:54 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta1+Sun/8.11.2.Beta1) id eB2N5B805964 for ipng-dist; Sat, 2 Dec 2000 15:05:11 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.2.Beta1+Sun/8.11.2.Beta1) with ESMTP id eB2N51r05957 for ; Sat, 2 Dec 2000 15:05:01 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id PAA09885 for ; Sat, 2 Dec 2000 15:05:02 -0800 (PST) Received: from mailhub1.almaden.ibm.com (mailhub1.almaden.ibm.com [198.4.83.44]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA28347; Sat, 2 Dec 2000 15:05:00 -0800 (PST) Received: from maui.almaden.ibm.com (maui.almaden.ibm.com [9.1.24.92]) by mailhub1.almaden.ibm.com (8.8.8/8.8.8) with ESMTP id PAA08042; Sat, 2 Dec 2000 15:05:28 -0800 Received: from hursley.ibm.com (gsine04.us.sine.ibm.com [9.14.6.44]) by maui.almaden.ibm.com (AIX4.3/8.9.3/8.7) with ESMTP id PAA24794; Sat, 2 Dec 2000 15:04:57 -0800 Message-ID: <3A297FE9.40229385@hursley.ibm.com> Date: Sat, 02 Dec 2000 17:04:09 -0600 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en,fr MIME-Version: 1.0 To: sommerfeld@east.sun.com CC: Francis Dupont , itojun@iijlab.net, "'ipng@sunroof.eng.sun.com'" Subject: Re: Usage of IPv6 flow label References: <200012012327.eB1NRna106997@thunk.east.sun.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Bill Sommerfeld wrote: > > > What semantics do you think you can impose on something like that? > > > > => just associate a QoS to a SPI and send the information (ie. how to > > classify packets (addresses, ..., SPI) and the QoS) to the classifier > > (which is by definition on-path). > > That could be brute-forced into working if someone invented such a > protocol. However, it seems that you could accomplish the same goal > by having the originator of the traffic mark the diffserv bits of the > packet "appropriately", with the classifier merely having some policy > saying which nodes are allowed to send ipsec traffic with various > markings, possibly translating the markings appropriately. This doesn't necessarily work when you cross an ISP/ISP boundary. We can't assume that appropriate SLAs exist at all ISP boudaries; the only method that is sure to work is if each ISP can re-classify the traffic at its ingress. Believe me, we have thought about this *a lot* in diffserv. Brian -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sun Dec 3 08:05:49 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta1+Sun/8.11.2.Beta1) id eB3G4KX06412 for ipng-dist; Sun, 3 Dec 2000 08:04:21 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.2.Beta1+Sun/8.11.2.Beta1) with ESMTP id eB3G4Br06405 for ; Sun, 3 Dec 2000 08:04:12 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id IAA24498 for ; Sun, 3 Dec 2000 08:04:11 -0800 (PST) Received: from melimelo.enst-bretagne.fr (melimelo.enst-bretagne.fr [192.108.115.36]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA17247 for ; Sun, 3 Dec 2000 08:04:10 -0800 (PST) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by melimelo.enst-bretagne.fr (8.10.1/8.10.1) with ESMTP id eB3G44438015; Sun, 3 Dec 2000 17:04:04 +0100 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id RAA08614; Sun, 3 Dec 2000 17:04:03 +0100 (MET) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.9.3/8.9.3) with ESMTP id RAA25645; Sun, 3 Dec 2000 17:04:23 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200012031604.RAA25645@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Vida Rolland cc: ipng@sunroof.eng.sun.com, ssm-interest@external.cisco.com, Supratik Bhattacharyya Subject: Re: MLDv3 - Internet Draft In-reply-to: Your message of Wed, 08 Nov 2000 18:30:19 +0100. <3A098DAB.52FD42BD@rp.lip6.fr> Date: Sun, 03 Dec 2000 17:04:23 +0100 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: Here is the abstract of an Internet Draft proposal, called "Multicast Listener Discovery Version 3 (MLDv3) for IPv6" () => was this I-D proposed to the Internet Draft Editor (I can't find it in the repository)? Regards Francis.Dupont@enst-bretagne.fr -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sun Dec 3 20:26:34 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta1+Sun/8.11.2.Beta1) id eB44PAQ06835 for ipng-dist; Sun, 3 Dec 2000 20:25:10 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.2.Beta1+Sun/8.11.2.Beta1) with ESMTP id eB44P0r06828 for ; Sun, 3 Dec 2000 20:25:01 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id UAA09726 for ; Sun, 3 Dec 2000 20:24:59 -0800 (PST) Received: from ztxmail02.ztx.compaq.com (ztxmail02.ztx.compaq.com [161.114.1.206]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA12015 for ; Sun, 3 Dec 2000 20:24:59 -0800 (PST) Received: by ztxmail02.ztx.compaq.com (Postfix, from userid 12345) id 0266A1E80; Sun, 3 Dec 2000 22:24:58 -0600 (CST) Received: from anw.zk3.dec.com (wasted.zk3.dec.com [16.140.32.3]) by ztxmail02.ztx.compaq.com (Postfix) with ESMTP id 7608B1E25; Sun, 3 Dec 2000 22:24:58 -0600 (CST) Received: from localhost by anw.zk3.dec.com (8.9.3/1.1.22.2/08Sep98-0251PM) id XAA0000826769; Sun, 3 Dec 2000 23:24:30 -0500 (EST) From: Jim Bound Message-Id: <200012040424.XAA0000826769@anw.zk3.dec.com> To: Brian E Carpenter Cc: Jim Bound , itojun@iijlab.net, "Ipng (E-Mail)" , bound@zk3.dec.com Subject: Re: Usage of IPv6 flow label In-reply-to: Your message of "Fri, 01 Dec 2000 14:35:34 CST." <3A280B96.540D2E56@hursley.ibm.com> Date: Sun, 03 Dec 2000 23:24:30 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Brian, >But Jim, this is how QOS works. Diffserv was carefully designed to be >identical for IPv4 and IPv6 (we thought you'd be pleased :-) I am pleased with the diff serv bits and that they work with IPv4 and IPv6. Its the assumptions after the bits are set that may have me concerned. I think QOS is an over used and abused term. I think discussing diff serv and int serv is goodness. int serv is my agenda not messing up diff serv. But if diff serv depends on extracting layer 4 information as a manner of standard then I think they went off the edge, "literally" :---). Another option for products that want to look at layer 4 information is to define a new destination option. One can put whatever they want in those. /jim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Dec 4 01:05:04 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta1+Sun/8.11.2.Beta1) id eB493kv06948 for ipng-dist; Mon, 4 Dec 2000 01:03:46 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.2.Beta1+Sun/8.11.2.Beta1) with ESMTP id eB493ar06941 for ; Mon, 4 Dec 2000 01:03:37 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id BAA11796 for ; Mon, 4 Dec 2000 01:03:35 -0800 (PST) Received: from melimelo.enst-bretagne.fr (melimelo.enst-bretagne.fr [192.108.115.36]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id CAA04766 for ; Mon, 4 Dec 2000 02:03:34 -0700 (MST) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by melimelo.enst-bretagne.fr (8.10.1/8.10.1) with ESMTP id eB492b421443; Mon, 4 Dec 2000 10:02:38 +0100 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id KAA04598; Mon, 4 Dec 2000 10:02:37 +0100 (MET) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.9.3/8.9.3) with ESMTP id KAA29887; Mon, 4 Dec 2000 10:03:01 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200012040903.KAA29887@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Jim Bound cc: Brian E Carpenter , itojun@iijlab.net, "Ipng (E-Mail)" Subject: Re: Usage of IPv6 flow label In-reply-to: Your message of Sun, 03 Dec 2000 23:24:30 EST. <200012040424.XAA0000826769@anw.zk3.dec.com> Date: Mon, 04 Dec 2000 10:03:01 +0100 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: Another option for products that want to look at layer 4 information is to define a new destination option. One can put whatever they want in those. => this idea is not so silly if this destination option is at the new position, ie. between the routing header and the fragment header. This will solve the fragment classification issue (to keep some state works only if fragments are in the suitable order, at least one common OS sends to last fragment first). Of course an encapsulation device can repeat it in the outer header (like tunnel encapsulation limit option). Francis.Dupont@enst-bretagne.fr PS: I prefer this solution than to hack some bits in the flowlabel. I'd like to have Thomas Eklund's opinion (ie. is to chase for this option easy enough?) -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Dec 4 01:15:13 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta1+Sun/8.11.2.Beta1) id eB49Dti06978 for ipng-dist; Mon, 4 Dec 2000 01:13:55 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.2.Beta1+Sun/8.11.2.Beta1) with ESMTP id eB49Dir06971 for ; Mon, 4 Dec 2000 01:13:44 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id BAA28036 for ; Mon, 4 Dec 2000 01:13:43 -0800 (PST) Received: from coconut.itojun.org (coconut.itojun.org [210.160.95.97]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA14942 for ; Mon, 4 Dec 2000 01:13:37 -0800 (PST) Received: from kiwi.itojun.org (localhost.itojun.org [127.0.0.1]) by coconut.itojun.org (8.9.3+3.2W/3.7W) with ESMTP id SAA19786; Mon, 4 Dec 2000 18:11:17 +0900 (JST) To: Francis Dupont cc: Jim Bound , Brian E Carpenter , "Ipng (E-Mail)" In-reply-to: Francis.Dupont's message of Mon, 04 Dec 2000 10:03:01 +0100. <200012040903.KAA29887@givry.rennes.enst-bretagne.fr> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: Usage of IPv6 flow label From: itojun@iijlab.net Date: Mon, 04 Dec 2000 18:11:17 +0900 Message-ID: <19784.975921077@coconut.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Another option for products that want to look at layer 4 information is > to define a new destination option. One can put whatever they want in > those. >=> this idea is not so silly if this destination option is at the new >position, ie. between the routing header and the fragment header. >This will solve the fragment classification issue (to keep some state >works only if fragments are in the suitable order, at least one common OS >sends to last fragment first). Of course an encapsulation device can >repeat it in the outer header (like tunnel encapsulation limit option). the option was explored a bit in ipsec working group (NAT-friendly ipsec proposal). not sure about the current status, or security implication/threat model (for example, if I were an attacker, I'd try to sniff/decrypt traffic with a port # for banking transaction!). itojun -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Dec 4 01:23:24 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta1+Sun/8.11.2.Beta1) id eB49MYj07028 for ipng-dist; Mon, 4 Dec 2000 01:22:34 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.2.Beta1+Sun/8.11.2.Beta1) with ESMTP id eB49MPr07021 for ; Mon, 4 Dec 2000 01:22:25 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id BAA03686 for ; Mon, 4 Dec 2000 01:22:25 -0800 (PST) Received: from melimelo.enst-bretagne.fr (melimelo.enst-bretagne.fr [192.108.115.36]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA27544 for ; Mon, 4 Dec 2000 01:22:24 -0800 (PST) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by melimelo.enst-bretagne.fr (8.10.1/8.10.1) with ESMTP id eB49Lk435172; Mon, 4 Dec 2000 10:21:46 +0100 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id KAA05326; Mon, 4 Dec 2000 10:21:45 +0100 (MET) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.9.3/8.9.3) with ESMTP id KAA30231; Mon, 4 Dec 2000 10:22:10 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200012040922.KAA30231@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: itojun@iijlab.net cc: Jim Bound , Brian E Carpenter , "Ipng (E-Mail)" Subject: Re: Usage of IPv6 flow label In-reply-to: Your message of Mon, 04 Dec 2000 18:11:17 +0900. <19784.975921077@coconut.itojun.org> Date: Mon, 04 Dec 2000 10:22:10 +0100 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: > Another option for products that want to look at layer 4 information is > to define a new destination option. One can put whatever they want in > those. >=> this idea is not so silly if this destination option is at the new >position, ie. between the routing header and the fragment header. >This will solve the fragment classification issue (to keep some state >works only if fragments are in the suitable order, at least one common OS >sends to last fragment first). Of course an encapsulation device can >repeat it in the outer header (like tunnel encapsulation limit option). the option was explored a bit in ipsec working group (NAT-friendly ipsec proposal). not sure about the current status, or security implication/threat model (for example, if I were an attacker, I'd try to sniff/decrypt traffic with a port # for banking transaction!). => a security gateway can or copy the header or hide it. It can apply its policy with the whole information (ie. it has the header then it knows what information it will reveal). I think it is the best compromise between security and classification... Of course I assume the security gateway is clever (if it is dumb you can remove the security :-). Regards Francis.Dupont@enst-bretagne.fr PS: in fact the security issue is the same than with flow label hacking, but an option is cleaner then should be better from any point of view... -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Dec 4 08:29:08 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta1+Sun/8.11.2.Beta1) id eB4GRbd07319 for ipng-dist; Mon, 4 Dec 2000 08:27:37 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.2.Beta1+Sun/8.11.2.Beta1) with ESMTP id eB4GRRr07312 for ; Mon, 4 Dec 2000 08:27:28 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id IAA24816 for ; Mon, 4 Dec 2000 08:27:25 -0800 (PST) Received: from cisco.com (ups.cisco.com [171.69.18.21]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA15884; Mon, 4 Dec 2000 08:27:25 -0800 (PST) Received: from [10.19.130.188] (deering-dsl3.cisco.com [10.19.130.188]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id IAA24426; Mon, 4 Dec 2000 08:27:02 -0800 (PST) Mime-Version: 1.0 X-Sender: deering@ups (Unverified) Message-Id: In-Reply-To: <3A2834A7.CDDCFD6C@hursley.ibm.com> References: <200012012256.XAA17005@givry.rennes.enst-bretagne.fr> <3A2834A7.CDDCFD6C@hursley.ibm.com> Date: Mon, 4 Dec 2000 08:27:00 -0800 To: Brian E Carpenter From: Steve Deering Subject: Re: Usage of IPv6 flow label Cc: Francis Dupont , sommerfeld@east.sun.com, itojun@iijlab.net, "'ipng@sunroof.eng.sun.com'" Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At 5:30 PM -0600 12/1/00, Brian E Carpenter wrote: >Francis Dupont wrote: >... > > => just associate a QoS to a SPI and send the information (ie. how to > > classify packets (addresses, ..., SPI) and the QoS) to the classifier > > (which is by definition on-path). > >Wrong model. That requires signalling; diffserv doesn't have signalling. > >This works for RSVP as itojun explained, but it doesn't work for diffserv. I'm getting confused. The Flow label is intended for intserv, so why are you talking about subverting it (or the SPI) for diffserv? If diffserv requires en-route inspection of the 5-tuple in order to set the DSCP bits (and therefore you are trying to overload the Flow Label with port semantics in order to avoid the cost of finding the ports), that ought only to be done near the source edge (where parsing multiple headers is less onerous), if at all, because of the ease with which one could lie about one's port numbers to obtain better service. Are core routers really going to provide different qualities of service to packets based on an easily "forged" 8-bit integer? I thought core routers classified packets for diffserv packets according to the arrival interface and the arriving DSCP bits, *not* the 5-tuple. Steve -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Dec 4 08:35:24 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta1+Sun/8.11.2.Beta1) id eB4GYSI07366 for ipng-dist; Mon, 4 Dec 2000 08:34:28 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.2.Beta1+Sun/8.11.2.Beta1) with ESMTP id eB4GYJr07359 for ; Mon, 4 Dec 2000 08:34:19 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id IAA05423 for ; Mon, 4 Dec 2000 08:34:19 -0800 (PST) Received: from cisco.com (ups.cisco.com [171.69.18.21]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA21096 for ; Mon, 4 Dec 2000 08:34:18 -0800 (PST) Received: from [10.19.130.188] (deering-dsl3.cisco.com [10.19.130.188]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id IAA25183; Mon, 4 Dec 2000 08:33:36 -0800 (PST) Mime-Version: 1.0 X-Sender: deering@ups Message-Id: In-Reply-To: <200012011821.TAA13934@givry.rennes.enst-bretagne.fr> References: <200012011821.TAA13934@givry.rennes.enst-bretagne.fr> Date: Mon, 4 Dec 2000 08:33:33 -0800 To: Francis Dupont From: Steve Deering Subject: Re: Usage of IPv6 flow label Cc: Brian E Carpenter , itojun@iijlab.net, "'ipng@sunroof.eng.sun.com'" Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At 7:21 PM +0100 12/1/00, Francis Dupont wrote: >In the future I can see two cases: > - the flow label is set by the source (first camp) > - the flow label is set by an edge router (with the DiffServ definition > of what is an edge router) because the source box (or its user) is > too dumb to deal with QoS/..., according to the edge router manager. If the Flow Label is set by something other than the source node, how do you guarantee its uniqueness, over the topological scope in which it must be unique? Do you need to invent a protocol between the routers on a LAN to divvy up the Flow label space? What happens when the LAN partitions, then routers in the different partitions assign duplicate Flow Labels, and then the partition heals? Steve -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Dec 4 08:40:22 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta1+Sun/8.11.2.Beta1) id eB4Gcvx07404 for ipng-dist; Mon, 4 Dec 2000 08:38:57 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.2.Beta1+Sun/8.11.2.Beta1) with ESMTP id eB4Gcmr07397 for ; Mon, 4 Dec 2000 08:38:48 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id IAA18707 for ; Mon, 4 Dec 2000 08:38:47 -0800 (PST) Received: from cisco.com (ups.cisco.com [171.69.18.21]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA23250; Mon, 4 Dec 2000 08:38:46 -0800 (PST) Received: from [10.19.130.188] (deering-dsl3.cisco.com [10.19.130.188]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id IAA25883; Mon, 4 Dec 2000 08:38:27 -0800 (PST) Mime-Version: 1.0 X-Sender: deering@ups Message-Id: In-Reply-To: References: <200012012256.XAA17005@givry.rennes.enst-bretagne.fr> <3A2834A7.CDDCFD6C@hursley.ibm.com> Date: Mon, 4 Dec 2000 08:38:25 -0800 To: Brian E Carpenter From: Steve Deering Subject: Re: Usage of IPv6 flow label Cc: Francis Dupont , sommerfeld@east.sun.com, itojun@iijlab.net, "'ipng@sunroof.eng.sun.com'" Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At 8:27 AM -0800 12/4/00, Steve Deering wrote: >Are core routers really going to provide different qualities of service >to packets based on an easily "forged" 8-bit integer? Oops, that was supposed to be 16-bit integer (a port number). Steve -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Dec 4 09:38:07 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta1+Sun/8.11.2.Beta1) id eB4Haai07487 for ipng-dist; Mon, 4 Dec 2000 09:36:36 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.2.Beta1+Sun/8.11.2.Beta1) with ESMTP id eB4HaRr07480 for ; Mon, 4 Dec 2000 09:36:27 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id JAA11161 for ; Mon, 4 Dec 2000 09:36:26 -0800 (PST) Received: from mail.kebne.se (mail.kebne.se [212.209.134.151]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA22637 for ; Mon, 4 Dec 2000 09:36:25 -0800 (PST) Received: from xelthomase01 (XEL-THOMASE01 [10.0.9.60]) by mail.kebne.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id XXG8HYKS; Mon, 4 Dec 2000 18:36:29 +0100 Reply-To: From: "Thomas Eklund" To: "'Brian E Carpenter'" Cc: "'Jim Bound'" , "'Ipng \(E-Mail\)'" Subject: RE: Usage of IPv6 flow label Date: Mon, 4 Dec 2000 18:36:22 +0100 Message-ID: <31A473DBB655D21180850008C71E251A029492EF@mail.kebne.se> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) In-reply-to: <31A473DBB655D21180850008C71E251A031427F3@mail.kebne.se> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Brian, > There are several misunderstandings of diffserv here. > There is nothing about "traffic trunks" in the diffserv > model. At a stretch, > you can think of a DSCP as labelling a "service class", but formally > it simply labels a "traffic aggregate", i.e. all the traffic > that receives > the same QOS treatment on a given hop. so if you call your traffic aggregates something else thats fine with me. > owever, we *do* assume in the > model that DSCP values are invariant across an entire domain, with the > routers in the domain being centrally configured. That configuration > may be done using COPS, or SNMP, or HTTP, or telnet, or by telefax > for that matter - it's of no importance for this discussion. Well I think its VERY relevant, and I'm not the only one that thinks that it has to be more clear how diffserv is managed over a domain. > > DSCP mutability applies at diffserv domain boundaries, which will > typically be ISP/ISP boundaries or customet/ISP boundaries. Which is exactly what I have said. > As of today, there is *no* defined relationship between DSCP and > Flow Label. But I tend to agree with Jim that defining the Flow Label > as immutable across domain boundaries (as well as being visible > in encrypted packets) has distinct advantages. And who had said anything else that not having it visible? The flowlabel is visible since it is part of the basic header. But then one might ask - what happen when we use IP sec in tunneling mode? Is it a MUST to copy the flow label into the new tunnel header or not? etc. All I said was that it is very nice on paper - but in reality it will have problem with acceptence from the service providers! And to say that there is no relationship between MPLS and diffserv is strange because they represent two different aproaches to achieve QoS in you network which has many overlaps and many things that differs them (dont get me wrong here I love diffserv). Today I know many operators using mpls and not many that uses diffserv. What I was speaking about was to have a QoS model that include intserv, diffserv and mpls into an optimal ipv6 arhitechure... -- thomas -- thomas -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Dec 4 09:42:22 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta1+Sun/8.11.2.Beta1) id eB4HfLk07513 for ipng-dist; Mon, 4 Dec 2000 09:41:21 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.2.Beta1+Sun/8.11.2.Beta1) with ESMTP id eB4HfCr07506 for ; Mon, 4 Dec 2000 09:41:13 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id JAA12412 for ; Mon, 4 Dec 2000 09:41:12 -0800 (PST) Received: from ztxmail01.ztx.compaq.com (ztxmail01.ztx.compaq.com [161.114.1.205]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA20839 for ; Mon, 4 Dec 2000 10:41:11 -0700 (MST) Received: by ztxmail01.ztx.compaq.com (Postfix, from userid 12345) id C0DB643FB; Mon, 4 Dec 2000 11:41:10 -0600 (CST) Received: from anw.zk3.dec.com (wasted.zk3.dec.com [16.140.32.3]) by ztxmail01.ztx.compaq.com (Postfix) with ESMTP id B1DBA4432; Mon, 4 Dec 2000 11:41:06 -0600 (CST) Received: from localhost by anw.zk3.dec.com (8.9.3/1.1.22.2/08Sep98-0251PM) id MAA0000887797; Mon, 4 Dec 2000 12:40:46 -0500 (EST) From: Jim Bound Message-Id: <200012041740.MAA0000887797@anw.zk3.dec.com> To: Steve Deering Cc: Francis Dupont , Brian E Carpenter , itojun@iijlab.net, "'ipng@sunroof.eng.sun.com'" , bound@zk3.dec.com Subject: Re: Usage of IPv6 flow label In-reply-to: Your message of "Mon, 04 Dec 2000 08:33:33 PST." Date: Mon, 04 Dec 2000 12:40:46 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>In the future I can see two cases: >> - the flow label is set by the source (first camp) >> - the flow label is set by an edge router (with the DiffServ definition >> of what is an edge router) because the source box (or its user) is >> too dumb to deal with QoS/..., according to the edge router manager. >If the Flow Label is set by something other than the source node, how >do you guarantee its uniqueness, over the topological scope in which >it must be unique? Do you need to invent a protocol between the routers >on a LAN to divvy up the Flow label space? What happens when the LAN >partitions, then routers in the different partitions assign duplicate >Flow Labels, and then the partition heals? Obviously I agree with Steve and this is a killer point. Recall in dec when we pushed the CE bit and it would only work exactly as Steve states won't work above. It never got used or deployed. It needs to come from the source and honored by the routers. /jim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Dec 4 09:44:22 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta1+Sun/8.11.2.Beta1) id eB4HhMO07534 for ipng-dist; Mon, 4 Dec 2000 09:43:22 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.2.Beta1+Sun/8.11.2.Beta1) with ESMTP id eB4HhBr07527 for ; Mon, 4 Dec 2000 09:43:11 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id JAA26777 for ; Mon, 4 Dec 2000 09:43:11 -0800 (PST) Received: from ztxmail01.ztx.compaq.com (ztxmail01.ztx.compaq.com [161.114.1.205]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA21904 for ; Mon, 4 Dec 2000 10:43:10 -0700 (MST) Received: by ztxmail01.ztx.compaq.com (Postfix, from userid 12345) id 801EE46B0; Mon, 4 Dec 2000 11:43:09 -0600 (CST) Received: from anw.zk3.dec.com (wasted.zk3.dec.com [16.140.32.3]) by ztxmail01.ztx.compaq.com (Postfix) with ESMTP id CA707467D; Mon, 4 Dec 2000 11:43:08 -0600 (CST) Received: from localhost by anw.zk3.dec.com (8.9.3/1.1.22.2/08Sep98-0251PM) id MAA0000888129; Mon, 4 Dec 2000 12:43:08 -0500 (EST) From: Jim Bound Message-Id: <200012041743.MAA0000888129@anw.zk3.dec.com> To: Steve Deering Cc: Brian E Carpenter , Francis Dupont , sommerfeld@east.sun.com, itojun@iijlab.net, "'ipng@sunroof.eng.sun.com'" , bound@zk3.dec.com Subject: Re: Usage of IPv6 flow label In-reply-to: Your message of "Mon, 04 Dec 2000 08:27:00 PST." Date: Mon, 04 Dec 2000 12:43:07 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >I thought core routers classified packets for diffserv packets according >to the arrival interface and the arriving DSCP bits, *not* the 5-tuple. This was my "impression" too. And why I stated to Brian I am happy with the DCSP bits but not what I am hearing else can be done???? thanks Steve for saying this more clearly. /jim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Dec 4 09:49:41 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta1+Sun/8.11.2.Beta1) id eB4Hm9j07585 for ipng-dist; Mon, 4 Dec 2000 09:48:09 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.2.Beta1+Sun/8.11.2.Beta1) with ESMTP id eB4Hlqr07573 for ; Mon, 4 Dec 2000 09:47:53 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id JAA28118 for ; Mon, 4 Dec 2000 09:47:46 -0800 (PST) Received: from zmamail02.zma.compaq.com (zmamail02.zma.compaq.com [161.114.64.102]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA29369 for ; Mon, 4 Dec 2000 09:47:45 -0800 (PST) Received: by zmamail02.zma.compaq.com (Postfix, from userid 12345) id 19D9A5B8A; Mon, 4 Dec 2000 12:47:45 -0500 (EST) Received: from anw.zk3.dec.com (wasted.zk3.dec.com [16.140.32.3]) by zmamail02.zma.compaq.com (Postfix) with ESMTP id C66455AE4; Mon, 4 Dec 2000 12:47:44 -0500 (EST) Received: from localhost by anw.zk3.dec.com (8.9.3/1.1.22.2/08Sep98-0251PM) id MAA0000888248; Mon, 4 Dec 2000 12:47:39 -0500 (EST) From: Jim Bound Message-Id: <200012041747.MAA0000888248@anw.zk3.dec.com> To: Cc: "'Brian E Carpenter'" , "'Jim Bound'" , "'Ipng (E-Mail)'" , bound@zk3.dec.com Subject: Re: Usage of IPv6 flow label In-reply-to: Your message of "Mon, 04 Dec 2000 18:36:22 +0100." <31A473DBB655D21180850008C71E251A029492EF@mail.kebne.se> Date: Mon, 04 Dec 2000 12:47:39 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk thomas, yes the tunnel endpoints would copy the flow label. on MPLS what do you want to do with MPLS and diff serv and why did you not bring this up in diff serv? thanks /jim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Dec 4 11:48:22 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta1+Sun/8.11.2.Beta1) id eB4JkeY07842 for ipng-dist; Mon, 4 Dec 2000 11:46:40 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.2.Beta1+Sun/8.11.2.Beta1) with ESMTP id eB4JkVr07835 for ; Mon, 4 Dec 2000 11:46:31 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id LAA10763 for ; Mon, 4 Dec 2000 11:46:29 -0800 (PST) Received: from mail.kebne.se (mail.kebne.se [212.209.134.151]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA19686 for ; Mon, 4 Dec 2000 11:46:28 -0800 (PST) Received: from xelthomase01 (XEL-THOMASE01 [10.0.9.60]) by mail.kebne.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id XXG8HYVZ; Mon, 4 Dec 2000 20:46:32 +0100 Reply-To: From: "Thomas Eklund" To: "'Francis Dupont'" , "'Brian E Carpenter'" Cc: , Subject: RE: Usage of IPv6 flow label Date: Mon, 4 Dec 2000 20:46:28 +0100 Message-ID: <31A473DBB655D21180850008C71E251A029492F5@mail.kebne.se> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) In-reply-to: <31A473DBB655D21180850008C71E251A03142BAD@mail.kebne.se> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Francis, I actually agree with you on the semantics of a SPI. > The SPI doesn't have the semantics. > > => I disagree, the SPI has the semantics we'd like to give to it. > > A QOS classifier needs to *know* > the port and protocol numbers; that's how it takes its decisions. > > PS: I am in no camp. I believe Jim/Itojun/... are right but the > flow label is not protected by AH then a router may rewrite it. > As it is not a stack it should be rewritten only closed to the source > (ie. if you want to rewrite it anywhere you should encapsulate packets > before, the decapsulation will restore the original flow label). > In the future I can see two cases: > - the flow label is set by the source (first camp) > - the flow label is set by an edge router (with the DiffServ > definition > of what is an edge router) because the source box (or its user) is > too dumb to deal with QoS/..., according to the edge > router manager. > I think we'll get a mixed situation. Which Is what I support too. -- thomas -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Dec 4 12:23:16 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta1+Sun/8.11.2.Beta1) id eB4KLou07922 for ipng-dist; Mon, 4 Dec 2000 12:21:50 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.2.Beta1+Sun/8.11.2.Beta1) with ESMTP id eB4KLer07915 for ; Mon, 4 Dec 2000 12:21:40 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id MAA23317 for ; Mon, 4 Dec 2000 12:21:39 -0800 (PST) Received: from mail.kebne.se (mail.kebne.se [212.209.134.151]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA16267 for ; Mon, 4 Dec 2000 12:21:38 -0800 (PST) Received: from xelthomase01 (XEL-THOMASE01 [10.0.9.60]) by mail.kebne.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id XXG8HYX8; Mon, 4 Dec 2000 21:21:42 +0100 Reply-To: From: "Thomas Eklund" To: "'Steve Deering'" , "'Francis Dupont'" Cc: "'Brian E Carpenter'" , , Subject: RE: Usage of IPv6 flow label Date: Mon, 4 Dec 2000 21:21:25 +0100 Message-ID: <31A473DBB655D21180850008C71E251A029492F6@mail.kebne.se> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) In-reply-to: <31A473DBB655D21180850008C71E251A03142C77@mail.kebne.se> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi steve, > >In the future I can see two cases: > > - the flow label is set by the source (first camp) > > - the flow label is set by an edge router (with the > DiffServ definition > > of what is an edge router) because the source box (or its user) is > > too dumb to deal with QoS/..., according to the edge > router manager. > > If the Flow Label is set by something other than the source node, how > do you guarantee its uniqueness, over the topological scope in which > it must be unique? Do you need to invent a protocol between > the routers > on a LAN to divvy up the Flow label space? It could be set as the MPLS protocol sets its traffic flows and distributed to how MPLS distributes its flow info in its domain (RSVP-TE, LDP). This was what I have had in mind. And you would utilize the flow label inside the ip header and get rid of the intemediate L2.5 protocol (MPLS). The intention was of course to map the traffic onto a LSP in the edge router inside your domain.. This could be done i a label stacked approach to which we will need the dest. option Jim was talking about. The host sets the flow label for the session as propose by Itojun and Jochen's approach. Into the backbone/core of your network we might want to do traffic engineering and to use the flow label for that purpose. And if we have one bit telling that the flow label should be distributed to the other end, we need a dest option for the original flow (which had a semantic in the access) that needs to be swapped back at the egress of your domain. Then we have the "new" flow label in the core that we do TE on. > What happens when the LAN > partitions, then routers in the different partitions assign duplicate > Flow Labels, and then the partition heals? It is solved exatcly as it is solved in mpls in the core and in the access we would need to integrate admission control in the access router. So the host signals for a flowlabel to the access router that do admission control and also verifies the uniqueness of the flow-label in the access... -- thomas -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Dec 4 12:37:12 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta1+Sun/8.11.2.Beta1) id eB4KZgj07981 for ipng-dist; Mon, 4 Dec 2000 12:35:42 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.2.Beta1+Sun/8.11.2.Beta1) with ESMTP id eB4KZWr07974 for ; Mon, 4 Dec 2000 12:35:33 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id MAA09054 for ; Mon, 4 Dec 2000 12:35:27 -0800 (PST) Received: from mail.kebne.se (mail.kebne.se [212.209.134.151]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA22233 for ; Mon, 4 Dec 2000 12:35:26 -0800 (PST) Received: from xelthomase01 (XEL-THOMASE01 [10.0.9.60]) by mail.kebne.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id XXG8HYYS; Mon, 4 Dec 2000 21:35:30 +0100 Reply-To: From: "Thomas Eklund" To: "'Steve Deering'" , "'Brian E Carpenter'" Cc: "'Francis Dupont'" , , , Subject: RE: Usage of IPv6 flow label Date: Mon, 4 Dec 2000 21:35:25 +0100 Message-ID: <31A473DBB655D21180850008C71E251A029492F7@mail.kebne.se> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) In-reply-to: <31A473DBB655D21180850008C71E251A03142C8B@mail.kebne.se> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Steve, > I thought core routers classified packets for diffserv > packets according > to the arrival interface and the arriving DSCP bits, *not* > the 5-tuple. You are reffering to a BA classification that is done inside a diffserv domain. If you sit on a diffserv edge you must be able to do a full MF classification that could include (src/dst MAC addresses, VLAN ID, 802.1 P priority, src/dst IP address, src/dst subnetmask, DSCP, Protocolfield, src/dst port TCP, src/dst UDP, TCP flags etc..) and map it into a DSCP. -- thomas -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Dec 4 12:42:13 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta1+Sun/8.11.2.Beta1) id eB4KfMb08021 for ipng-dist; Mon, 4 Dec 2000 12:41:22 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.2.Beta1+Sun/8.11.2.Beta1) with ESMTP id eB4KfCr08014 for ; Mon, 4 Dec 2000 12:41:12 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id MAA26074 for ; Mon, 4 Dec 2000 12:41:11 -0800 (PST) Received: from mail.kebne.se (mail.kebne.se [212.209.134.151]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA21021 for ; Mon, 4 Dec 2000 13:41:10 -0700 (MST) Received: from xelthomase01 (XEL-THOMASE01 [10.0.9.60]) by mail.kebne.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id XXG8HYY8; Mon, 4 Dec 2000 21:41:14 +0100 Reply-To: From: "Thomas Eklund" To: "'Jim Bound'" , "'Steve Deering'" Cc: "'Francis Dupont'" , "'Brian E Carpenter'" , , Subject: RE: Usage of IPv6 flow label Date: Mon, 4 Dec 2000 21:41:11 +0100 Message-ID: <31A473DBB655D21180850008C71E251A029492F8@mail.kebne.se> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) In-reply-to: <31A473DBB655D21180850008C71E251A03142CB6@mail.kebne.se> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Jim whats CE bits? -- thomas > -----Original Message----- > From: owner-ipng@sunroof.eng.sun.com > [mailto:owner-ipng@sunroof.eng.sun.com]On Behalf Of Jim Bound > Sent: den 4 december 2000 18:41 > To: Steve Deering > Cc: Francis Dupont; Brian E Carpenter; itojun@iijlab.net; > 'ipng@sunroof.eng.sun.com'; bound@zk3.dec.com > Subject: Re: Usage of IPv6 flow label > > > > >>In the future I can see two cases: > >> - the flow label is set by the source (first camp) > >> - the flow label is set by an edge router (with the > DiffServ definition > >> of what is an edge router) because the source box (or > its user) is > >> too dumb to deal with QoS/..., according to the edge > router manager. > > >If the Flow Label is set by something other than the source node, how > >do you guarantee its uniqueness, over the topological scope in which > >it must be unique? Do you need to invent a protocol between > the routers > >on a LAN to divvy up the Flow label space? What happens when the LAN > >partitions, then routers in the different partitions assign duplicate > >Flow Labels, and then the partition heals? > > Obviously I agree with Steve and this is a killer point. > Recall in dec > when we pushed the CE bit and it would only work exactly as > Steve states > won't work above. It never got used or deployed. It needs > to come from > the source and honored by the routers. > > /jim > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Dec 4 13:25:03 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta1+Sun/8.11.2.Beta1) id eB4LNHj08063 for ipng-dist; Mon, 4 Dec 2000 13:23:17 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.2.Beta1+Sun/8.11.2.Beta1) with ESMTP id eB4LN8r08056 for ; Mon, 4 Dec 2000 13:23:08 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id NAA21195 for ; Mon, 4 Dec 2000 13:23:07 -0800 (PST) Received: from mailhub1.almaden.ibm.com (mailhub1.almaden.ibm.com [198.4.83.44]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA15206 for ; Mon, 4 Dec 2000 13:23:06 -0800 (PST) Received: from maui.almaden.ibm.com (maui.almaden.ibm.com [9.1.24.92]) by mailhub1.almaden.ibm.com (8.8.8/8.8.8) with ESMTP id NAA16432; Mon, 4 Dec 2000 13:22:57 -0800 Received: from hursley.ibm.com (ss8.pok.socks.ibm.com [9.14.3.73]) by maui.almaden.ibm.com (AIX4.3/8.9.3/8.7) with ESMTP id NAA24688; Mon, 4 Dec 2000 13:23:01 -0800 Message-ID: <3A2BD35B.AD80C3CA@hursley.ibm.com> Date: Mon, 04 Dec 2000 11:24:43 -0600 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en,fr MIME-Version: 1.0 To: Francis Dupont CC: itojun@iijlab.net, Jim Bound , "Ipng (E-Mail)" Subject: Re: Usage of IPv6 flow label References: <200012040922.KAA30231@givry.rennes.enst-bretagne.fr> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Yes, I agree that this is interesting and it would allow us to treat the flow label as an opaque binary string in all cases. Brian Francis Dupont wrote: > > In your previous mail you wrote: > > > Another option for products that want to look at layer 4 information is > > to define a new destination option. One can put whatever they want in > > those. > >=> this idea is not so silly if this destination option is at the new > >position, ie. between the routing header and the fragment header. > >This will solve the fragment classification issue (to keep some state > >works only if fragments are in the suitable order, at least one common OS > >sends to last fragment first). Of course an encapsulation device can > >repeat it in the outer header (like tunnel encapsulation limit option). > > the option was explored a bit in ipsec working group (NAT-friendly > ipsec proposal). not sure about the current status, or security > implication/threat model (for example, if I were an attacker, I'd > try to sniff/decrypt traffic with a port # for banking transaction!). > > => a security gateway can or copy the header or hide it. It can apply > its policy with the whole information (ie. it has the header then it knows > what information it will reveal). I think it is the best compromise > between security and classification... Of course I assume the security > gateway is clever (if it is dumb you can remove the security :-). > > Regards > > Francis.Dupont@enst-bretagne.fr > > PS: in fact the security issue is the same than with flow label hacking, > but an option is cleaner then should be better from any point of view... > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Dec 4 17:33:24 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta1+Sun/8.11.2.Beta1) id eB51Vp108226 for ipng-dist; Mon, 4 Dec 2000 17:31:51 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.2.Beta1+Sun/8.11.2.Beta1) with ESMTP id eB51Vfr08219 for ; Mon, 4 Dec 2000 17:31:41 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id RAA25669 for ; Mon, 4 Dec 2000 17:31:40 -0800 (PST) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id SAA26007 for ; Mon, 4 Dec 2000 18:31:38 -0700 (MST) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id RAA28264 for ; Mon, 4 Dec 2000 17:31:38 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id eB51VbK08899 for ; Mon, 4 Dec 2000 17:31:37 -0800 X-Virus-Scanned: Mon, 4 Dec 2000 17:31:37 -0800 Nokia Silicon Valley Email Exploit Scanner Received: from spruce.iprg.nokia.com (205.226.1.63) by darkstar.iprg.nokia.com(WTS.12.69) smtpdO0dbjr; Mon, 04 Dec 2000 17:31:33 PST Message-Id: <4.3.2.7.2.20001204172737.020589a8@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 04 Dec 2000 17:29:14 -0800 To: ipng@sunroof.eng.sun.com From: Bob Hinden Subject: Updated IPv6 web pages Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk As part of changing the name of the IPng working group to the IPv6 working group, I have updated the web pages at http://playground.sun.com/ipv6 The old URL http://playground.sun.com/ipng also works. We are expecting the IESG to approve the revised charter in the near future. Besides the name change, the update includes new drafts, standards, and implementations. Please send me updates, changes, corrections, etc. Thanks, Bob -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Dec 4 18:04:23 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta1+Sun/8.11.2.Beta1) id eB5233M08282 for ipng-dist; Mon, 4 Dec 2000 18:03:03 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.2.Beta1+Sun/8.11.2.Beta1) with ESMTP id eB522sr08274 for ; Mon, 4 Dec 2000 18:02:54 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id SAA25806 for ; Mon, 4 Dec 2000 18:02:53 -0800 (PST) Received: from ztxmail02.ztx.compaq.com (ztxmail02.ztx.compaq.com [161.114.1.206]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id TAA05206 for ; Mon, 4 Dec 2000 19:02:51 -0700 (MST) Received: by ztxmail02.ztx.compaq.com (Postfix, from userid 12345) id 197061E66; Mon, 4 Dec 2000 20:02:51 -0600 (CST) Received: from anw.zk3.dec.com (wasted.zk3.dec.com [16.140.32.3]) by ztxmail02.ztx.compaq.com (Postfix) with ESMTP id 5DEC81DD6; Mon, 4 Dec 2000 20:02:50 -0600 (CST) Received: from localhost by anw.zk3.dec.com (8.9.3/1.1.22.2/08Sep98-0251PM) id VAA0000930145; Mon, 4 Dec 2000 21:01:59 -0500 (EST) From: Jim Bound Message-Id: <200012050201.VAA0000930145@anw.zk3.dec.com> To: Cc: "'Jim Bound'" , "'Steve Deering'" , "'Francis Dupont'" , "'Brian E Carpenter'" , , , bound@zk3.dec.com Subject: Re: Usage of IPv6 flow label In-reply-to: Your message of "Mon, 04 Dec 2000 21:41:11 +0100." <31A473DBB655D21180850008C71E251A029492F8@mail.kebne.se> Date: Mon, 04 Dec 2000 21:01:59 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk thomas, It was the Congestion Experienced bits defined by Raj Jain at Digital. Close to the ECN bits from Sally but not as robust. /jim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Dec 4 19:47:31 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta1+Sun/8.11.2.Beta1) id eB53k4b08354 for ipng-dist; Mon, 4 Dec 2000 19:46:04 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.2.Beta1+Sun/8.11.2.Beta1) with ESMTP id eB53jrr08347 for ; Mon, 4 Dec 2000 19:45:53 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id TAA02666 for ; Mon, 4 Dec 2000 19:45:51 -0800 (PST) Received: from newdev.harvard.edu (newdev.eecs.harvard.edu [140.247.60.212]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id UAA04315 for ; Mon, 4 Dec 2000 20:45:50 -0700 (MST) Received: (from sob@localhost) by newdev.harvard.edu (8.9.3/8.9.3) id WAA07080; Mon, 4 Dec 2000 22:44:58 -0500 (EST) Date: Mon, 4 Dec 2000 22:44:58 -0500 (EST) From: Scott Bradner Message-Id: <200012050344.WAA07080@newdev.harvard.edu> To: bound@zk3.dec.com, thomas.eklund@xelerated.com Subject: Re: Usage of IPv6 flow label Cc: brian@hursley.ibm.com, deering@cisco.com, Francis.Dupont@enst-bretagne.fr, ipng@sunroof.eng.sun.com, itojun@iijlab.net Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > It was the Congestion Experienced bits defined by Raj Jain at Digital. > Close to the ECN bits from Sally but not as robust. teh "DEC Bit" also had different semantics but was trying to geach the same goal Scott -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Dec 4 20:15:57 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta1+Sun/8.11.2.Beta1) id eB54Ee708406 for ipng-dist; Mon, 4 Dec 2000 20:14:40 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.2.Beta1+Sun/8.11.2.Beta1) with ESMTP id eB54EUr08399 for ; Mon, 4 Dec 2000 20:14:30 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id UAA16032 for ; Mon, 4 Dec 2000 20:14:29 -0800 (PST) Received: from coconut.itojun.org (coconut.itojun.org [210.160.95.97]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA17109 for ; Mon, 4 Dec 2000 20:14:28 -0800 (PST) Received: from kiwi.itojun.org (localhost.itojun.org [127.0.0.1]) by coconut.itojun.org (8.9.3+3.2W/3.7W) with ESMTP id NAA03912; Tue, 5 Dec 2000 13:14:16 +0900 (JST) To: Bob Hinden cc: ipng@sunroof.eng.sun.com In-reply-to: hinden's message of Mon, 04 Dec 2000 17:29:14 PST. <4.3.2.7.2.20001204172737.020589a8@mailhost.iprg.nokia.com> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: Updated IPv6 web pages From: itojun@iijlab.net Date: Tue, 05 Dec 2000 13:14:16 +0900 Message-ID: <3910.975989656@coconut.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >As part of changing the name of the IPng working group to the IPv6 working >group, I have updated the web pages at > > http://playground.sun.com/ipv6 > >The old URL > > http://playground.sun.com/ipng > >also works. We are expecting the IESG to approve the revised charter in >the near future. as far as I remember the old URL was: http://playground.sun.com/pub/ipng/ am I wrong? itojun -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Dec 4 22:56:54 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta1+Sun/8.11.2.Beta1) id eB56tXu08462 for ipng-dist; Mon, 4 Dec 2000 22:55:33 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.2.Beta1+Sun/8.11.2.Beta1) with ESMTP id eB56tOr08455 for ; Mon, 4 Dec 2000 22:55:24 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id WAA29771 for ; Mon, 4 Dec 2000 22:55:24 -0800 (PST) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id WAA05104 for ; Mon, 4 Dec 2000 22:55:24 -0800 (PST) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id WAA13517; Mon, 4 Dec 2000 22:55:24 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id eB56tLF32543; Mon, 4 Dec 2000 22:55:21 -0800 X-Virus-Scanned: Mon, 4 Dec 2000 22:55:21 -0800 Nokia Silicon Valley Email Exploit Scanner Received: from Ihinden-3.iprg.nokia.com (205.226.22.76, claiming to be "spruce.iprg.nokia.com") by darkstar.iprg.nokia.com(WTS.12.69) smtpdRnKdTK; Mon, 04 Dec 2000 22:55:16 PST Message-Id: <4.3.2.7.2.20001204225003.02290470@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 04 Dec 2000 22:53:01 -0800 To: itojun@iijlab.net From: Bob Hinden Subject: Re: Updated IPv6 web pages Cc: Bob Hinden , ipng@sunroof.eng.sun.com In-Reply-To: <3910.975989656@coconut.itojun.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Itojun, > as far as I remember the old URL was: > > http://playground.sun.com/pub/ipng/ > > am I wrong? There were a couple of old ones set up, I think I made a mistake in an article I wrote. The other main URL was http://playground.sun.com/pub/ipng/html/ipng-main.html Bob -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Dec 5 03:10:20 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta1+Sun/8.11.2.Beta1) id eB5B91V08704 for ipng-dist; Tue, 5 Dec 2000 03:09:01 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.2.Beta1+Sun/8.11.2.Beta1) with ESMTP id eB5B8qr08697 for ; Tue, 5 Dec 2000 03:08:52 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id DAA17594 for ; Tue, 5 Dec 2000 03:08:51 -0800 (PST) Received: from isis.lip6.fr (isis.lip6.fr [132.227.60.2]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA00354 for ; Tue, 5 Dec 2000 03:08:50 -0800 (PST) Received: from rp.lip6.fr (tibre.lip6.fr [132.227.74.2]) by isis.lip6.fr (8.9.3/jtpda-5.3.2) with ESMTP id LAA02145 ; Tue, 5 Dec 2000 11:42:17 +0100 Received: from rp.lip6.fr (otos.lip6.fr [132.227.61.47]) by rp.lip6.fr (8.8.8/jtpda-5.2) with ESMTP id LAA09664 ; Tue, 5 Dec 2000 11:42:16 +0100 (MET) Message-ID: <3A2CC688.10A0BD6A@rp.lip6.fr> Date: Tue, 05 Dec 2000 11:42:16 +0100 From: Vida Rolland Organization: Laboratoire Lip6 X-Mailer: Mozilla 4.75 [fr] (WinNT; U) X-Accept-Language: fr MIME-Version: 1.0 To: Francis Dupont CC: ipng@sunroof.eng.sun.com, ssm-interest@external.cisco.com Subject: Re: MLDv3 - Internet Draft References: <200012031604.RAA25645@givry.rennes.enst-bretagne.fr> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk The MLDv3 draft was not proposed to the Internet Draft Editor as it was a preliminary version. We were waiting for the new version of the IGMPv3 draft, that actually came out a few days ago. We are working now on adapting MLDv3 to the changes that were made in the new IGMPv3 version. A new version of the MLDv3 draft will be available in a couple of days. Regards, Rolland Vida, LIP6, Paris Francis Dupont a écrit : > In your previous mail you wrote: > > Here is the abstract of an Internet Draft proposal, called "Multicast > Listener Discovery Version 3 (MLDv3) for IPv6" > () > > => was this I-D proposed to the Internet Draft Editor (I can't find it > in the repository)? > > Regards > > Francis.Dupont@enst-bretagne.fr -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Dec 5 10:41:28 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta1+Sun/8.11.2.Beta1) id eB5Idlw09032 for ipng-dist; Tue, 5 Dec 2000 10:39:47 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.2.Beta1+Sun/8.11.2.Beta1) with ESMTP id eB5Idcr09025 for ; Tue, 5 Dec 2000 10:39:38 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id KAA19454 for ; Tue, 5 Dec 2000 10:39:37 -0800 (PST) Received: from mailrelay1.chek.com (gutmans.chek.com [208.197.227.23]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id LAA27477 for ; Tue, 5 Dec 2000 11:39:36 -0700 (MST) Received: (qmail 10163 invoked from network); 5 Dec 2000 18:39:07 -0000 Received: from whitfield.chek.com (208.197.227.143) by mailrelay1.chek.com with SMTP; 5 Dec 2000 18:39:07 -0000 Received: (qmail 20282 invoked by uid 99); 5 Dec 2000 18:34:24 -0000 Date: 5 Dec 2000 18:34:24 -0000 Message-ID: <20001205183424.20281.qmail@whitfield.chek.com> From: "Emanuel Moreira" To: ipng@sunroof.eng.sun.com, msripv6-users@list.research.microsoft.com, users@ipv6.org Content-Type: text/html; X-MASSMAIL: 1.0 X-Originating-IP: [193.137.173.132] Subject: Multicast group Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I have a lan with 3 Pc's and I want to creat a multicast group so that I can make a ping6 from one Pc to the other's two. Is'nt there an easy way than working with sockets? Thank's Emanuel Moreira _____________________________________________________________ O e-mail preferido dos portugueses http://www.portugalmail.pt -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Dec 6 05:42:46 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta1+Sun/8.11.2.Beta1) id eB6DfEw09624 for ipng-dist; Wed, 6 Dec 2000 05:41:14 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.2.Beta1+Sun/8.11.2.Beta1) with ESMTP id eB6Df4r09617 for ; Wed, 6 Dec 2000 05:41:05 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id FAA17861 for ; Wed, 6 Dec 2000 05:41:01 -0800 (PST) Received: from melimelo.enst-bretagne.fr (melimelo.enst-bretagne.fr [192.108.115.36]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA09082 for ; Wed, 6 Dec 2000 05:41:00 -0800 (PST) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by melimelo.enst-bretagne.fr (8.10.1/8.10.1) with ESMTP id eB6DeI416811; Wed, 6 Dec 2000 14:40:18 +0100 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id OAA29611; Wed, 6 Dec 2000 14:40:17 +0100 (MET) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.9.3/8.9.3) with ESMTP id OAA42177; Wed, 6 Dec 2000 14:40:54 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200012061340.OAA42177@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Steve Deering cc: Brian E Carpenter , itojun@iijlab.net, "'ipng@sunroof.eng.sun.com'" Subject: Re: Usage of IPv6 flow label In-reply-to: Your message of Mon, 04 Dec 2000 08:33:33 PST. Date: Wed, 06 Dec 2000 14:40:54 +0100 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: At 7:21 PM +0100 12/1/00, Francis Dupont wrote: >In the future I can see two cases: > - the flow label is set by the source (first camp) > - the flow label is set by an edge router (with the DiffServ definition > of what is an edge router) because the source box (or its user) is > too dumb to deal with QoS/..., according to the edge router manager. If the Flow Label is set by something other than the source node, how do you guarantee its uniqueness, over the topological scope in which it must be unique? => is a pseudo-random value enough? It is very expensive to get an absolute guarantee even on the source node itself... Do you need to invent a protocol between the routers on a LAN to divvy up the Flow label space? What happens when the LAN partitions, then routers in the different partitions assign duplicate Flow Labels, and then the partition heals? => this can happen. I didn't say the edge router stuff is the best or even good, just this has happened for IPv4/IntServ and this would happen for flow labels too, and this is not (IMHO) bad enough to prohibit this. Thanks Francis.Dupont@enst-bretagne.fr PS: this is a maginal sub-thread, the important one is how to reclassify (and remark) packets in the core between two domains... -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Dec 6 06:26:05 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta1+Sun/8.11.2.Beta1) id eB6EOgQ09681 for ipng-dist; Wed, 6 Dec 2000 06:24:42 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.2.Beta1+Sun/8.11.2.Beta1) with ESMTP id eB6EOXr09674 for ; Wed, 6 Dec 2000 06:24:33 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id GAA21269 for ; Wed, 6 Dec 2000 06:24:34 -0800 (PST) Received: from melimelo.enst-bretagne.fr (melimelo.enst-bretagne.fr [192.108.115.36]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA08152 for ; Wed, 6 Dec 2000 06:24:33 -0800 (PST) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by melimelo.enst-bretagne.fr (8.10.1/8.10.1) with ESMTP id eB6EOO431298; Wed, 6 Dec 2000 15:24:24 +0100 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id PAA02126; Wed, 6 Dec 2000 15:24:23 +0100 (MET) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.9.3/8.9.3) with ESMTP id PAA42463; Wed, 6 Dec 2000 15:25:01 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200012061425.PAA42463@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Jim Bound cc: thomas.eklund@xelerated.com, "'Brian E Carpenter'" , "'Ipng (E-Mail)'" Subject: Re: Usage of IPv6 flow label In-reply-to: Your message of Mon, 04 Dec 2000 12:47:39 EST. <200012041747.MAA0000888248@anw.zk3.dec.com> Date: Wed, 06 Dec 2000 15:25:01 +0100 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: yes the tunnel endpoints would copy the flow label. => I agree this is reasonnable thing to do (copy the flow label or any information that can be useful and should not be hiden accounding to the security policy) but this makes the unicity guarantee impossible (because the encapsulator hasn't the choice of the flow label). IMHO it doesn't really matter but according to your previous mail (and Steve's one) this is an issue. Thanks Francis.Dupont@enst-bretagne.fr PS: I believe the flow label should be reserved for IntServ stuff then SHOULD be set by the source, MAY be copied over tunnels, SHOULD NOT be rewritten by routers. If we agree about the default behaviour (ie. default value is zero or random) then we can be a bit stronger, for instance MUST NOT be rewritten if the value is not zero/default. Things we cannot ask for are: - a MUST for copying (security) - a MUST NOT for rewriting (not protected by IPsec) - a strong guarantee for unicity (we'll get only a best effort unicity) -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Dec 6 07:13:11 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta1+Sun/8.11.2.Beta1) id eB6FAfY09732 for ipng-dist; Wed, 6 Dec 2000 07:10:41 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.2.Beta1+Sun/8.11.2.Beta1) with ESMTP id eB6FAPr09725 for ; Wed, 6 Dec 2000 07:10:25 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id HAA25696 for ; Wed, 6 Dec 2000 07:10:26 -0800 (PST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA23558 for ; Wed, 6 Dec 2000 07:10:20 -0800 (PST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26702; Wed, 6 Dec 2000 10:10:12 -0500 (EST) Message-Id: <200012061510.KAA26702@ietf.org> To: IETF-Announce: ; Cc: RFC Editor , IANA Cc: Internet Architecture Board Cc: ipng@sunroof.eng.sun.com From: The IESG Subject: Protocol Action: Privacy Extensions for Stateless Address Autoconfiguration in IPv6 to Proposed Standard Date: Wed, 06 Dec 2000 10:10:11 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk The IESG has approved the Internet-Draft 'Privacy Extensions for Stateless Address Autoconfiguration in IPv6' as a Proposed Standard. This document is the product of the IPNG Working Group. The IESG contact persons are Erik Nordmark and Thomas Narten. Technical Summary Nodes use IPv6 stateless address autoconfiguration to generate addresses without the necessity of a DHCP server. Addresses are formed by combining network prefixes with an interface identifier. On interfaces that contain embedded IEEE Identifiers, the interface identifier is typically derived from it. On other interface types, the interface identifier is generated through other means, for example, via random number generation. This document describes an extension to IPv6 stateless address autoconfiguration for interfaces whose interface identifier is derived from an IEEE identifier. Use of the extension causes nodes to generate global-scope addresses from interface identifiers that change over time, even in cases where the interface contains an embedded IEEE identifier. Changing the interface identifier (and the global-scope addresses generated from it) over time makes it more difficult for eavesdroppers and other information collectors to identify when different addresses used in different transactions actually correspond to the same node. Working Group Summary There was WG consensus to advance this. Protocol Quality The specification has been reviewed for the IESG by Erik Nordmark. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Dec 6 08:50:23 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta1+Sun/8.11.2.Beta1) id eB6GmiO09862 for ipng-dist; Wed, 6 Dec 2000 08:48:44 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.2.Beta1+Sun/8.11.2.Beta1) with ESMTP id eB6GmZr09855 for ; Wed, 6 Dec 2000 08:48:36 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id IAA10917 for ; Wed, 6 Dec 2000 08:48:35 -0800 (PST) Received: from relay1.nce.smtp.psi.net (relay1.nce.smtp.psi.net [38.9.152.2]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA15250 for ; Wed, 6 Dec 2000 08:48:32 -0800 (PST) Received: from [198.138.94.6] (helo=smtp.txc.com) by relay1.nce.smtp.psi.net with smtp (Exim 3.13 #3) id 143hjv-0005UV-00; Wed, 06 Dec 2000 11:48:19 -0500 Received: from jade.txc.com by smtp.txc.com (4.1/SMI-4.1) id AA11120; Wed, 6 Dec 00 11:43:15 EST Received: from txc.com by jade.txc.com (SMI-8.6/SMI-SVR4) id LAA05079; Wed, 6 Dec 2000 11:48:13 -0500 Message-Id: <3A2E6DCE.34A209AE@txc.com> Date: Wed, 06 Dec 2000 11:48:14 -0500 From: Alex Conta X-Mailer: Mozilla 4.72 [en] (Win98; I) X-Accept-Language: en Mime-Version: 1.0 To: Christian Huitema Cc: "'Brian E Carpenter'" , "'ipng@sunroof.eng.sun.com'" Subject: Re: Usage of IPv6 flow label References: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------msF75B8446DCA2B6E1773847C3" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This is a cryptographically signed message in MIME format. --------------msF75B8446DCA2B6E1773847C3 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit The capture of the type of application is in fact the idea behind the IANA reserved/defined value of the "flow label type' in my "flow-label" related recent draft. The first bit of the redefined "flow label type" would indicate that it is a IANA number as opposed to a "protocol/server-port". This "reserved/IANA defined" value is a better indication than the "protocol/server-port". Alex Christian Huitema wrote: > > Brian Carpenter wrote: > > > > Francis Dupont wrote: > > > > > > In your previous mail you wrote: > > > > > > - figure out a way to make the other option in Alex's draft: > > > > > > 0 1 > > > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > |0| Server Port Number| H-to-H protocol| > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > > > suitable for use by policy-driven diffserv classifiers. > > > > > > => can you explain why it is not enough to use the SPI in place of > > > higher layer selectors? > > > > The SPI doesn't have the semantics. A QOS classifier needs to *know* > > the port and protocol numbers; that's how it takes its decisions. > > For example you might put traffic with protocol number 30 in a > > different class from traffic with protocol number 41. > > > > Alex's idea of using "server port number" is in fact > > interesting, since it would allow you to classify traffic > > on its original well-known port #, without having to rely > > on dynamically assigned port #s for classification. > > I'm beginning to think he may be right. But I suggest > > allocating 11 bits to the port number and 8 to the > > protocol number, so that we can cover at least > > some of the registered ports (up to 2047). But the flow > > label isn't long enough for everything we need. > > What is useful for the policy decision is to have an indication of the user > priviledges and then an indication of the application. Most policy decisions > are about given some users some guaranties that they can run some > applications. Addresses are only approximative indications of the users -- > think about proxies, mobility, etc. -- and ports are only approximative > indications of the application -- think about floating ports, applications > multiplexed over HTTP, etc. > > Having a protocol + port indication in the flow id is a way to provide an > indication about the indication. But we can do better than having a protocol > + port tuple. What we really want is some registry of applications, into > which we could fold the registered ports; then, once the registration > becomes well known, it becomes easy to write rules that allow for packet > classification. If we start from this registration perspective, then we want > a format that allows for several classes: > * Inherit registration from current registration of TCP and UDP ports -- > probably two > classes, > * One class registration of new applications, e.g. provide codes for those > applications that > currently work on floating ports, > * One class for non-registered applications, allowing for experimentation, > * A null label for users who don't want to disclose what application they > are running. > If we do that, then the end system can easily set the application code, and > the intermediate routers can easily use them. > > -- Christian Huitema > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- --------------msF75B8446DCA2B6E1773847C3 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIKBgYJKoZIhvcNAQcCoIIJ9zCCCfMCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC B70wggSHMIID8KADAgECAhBmfn1HDi4lGwF60JV5IuR7MA0GCSqGSIb3DQEBBAUAMIHMMRcw FQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5 IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRp dmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAwMDkyNjAwMDAw MFoXDTAxMDkyNjIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UE CxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9y ZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMV UGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBO ZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNVBAMUCkFsZXggQ29udGExHTAbBgkqhkiG9w0B CQEWDmFjb250YUB0eGMuY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC+BilF+LEo x0rhxqMsHXVa+gyHyrH2EtFEzHpahyckngPWpr7Qs84/urQzbXrfENmUFceQwz0Vgy2pu4/h 6IdnwspvjPpN5TIsFb+zE4+3FnFfiBCjO/lLk4I55n7s6xGuHh6ndOm57diHpLYg5x/xVbLI 4UFfkNiF0zCHPd5qjQIDAQABo4IBJjCCASIwCQYDVR0TBAIwADBEBgNVHSAEPTA7MDkGC2CG SAGG+EUBBwEIMCowKAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEw EQYJYIZIAYb4QgEBBAQDAgeAMIGGBgpghkgBhvhFAQYDBHgWdmQ0NjUyYmQ2M2YyMDQ3MDI5 Mjk4NzYzYzlkMmYyNzUwNjljNzM1OWJlZDFiMDU5ZGE3NWJjNGJjOTcwMTc0N2RhNWQzZjIx NDFiZWFkYjJiZDJlODkyMTZhYjYyZjFkNDExNDk5Y2EzYmU0N2ZkZjNlYTQ1MGMwMwYDVR0f BCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDANBgkqhkiG 9w0BAQQFAAOBgQBrO9RNDzCcKmFVXb2puL1VbHA0VqjhaD4Gm10zfjihYsLx2XzTWdvd8tBR 29HcF4WYOaw4r3Kbp2rttSCIbei8OgDOCPZcsGZEvLYho0PsocJV4saVsPEWq8n0Xxoz5qkV rBHXl0X4CvFYvbdjZiPJs2Gs4DwTe3AFi9WhFDyiJDCCAy4wggKXoAMCAQICEQDSdi6NFAw9 fbKoJV2v7g11MA0GCSqGSIb3DQEBAgUAMF8xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJp U2lnbiwgSW5jLjE3MDUGA1UECxMuQ2xhc3MgMSBQdWJsaWMgUHJpbWFyeSBDZXJ0aWZpY2F0 aW9uIEF1dGhvcml0eTAeFw05ODA1MTIwMDAwMDBaFw0wODA1MTIyMzU5NTlaMIHMMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFG MEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJl Zi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlk dWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMIGfMA0GCSqGSIb3DQEBAQUA A4GNADCBiQKBgQC7WkSKBBa7Vf0DeootlE8VeDa4DUqyb5xUv7zodyqdufBou5XZMUFweoFL uUgTVi3HCOGEQqvAopKrRFyqQvCCDgLpL/vCO7u+yScKXbawNkIztW5UiE+HSr8Z2vkV6A+H thzjzMaajn9qJJLj/OBluqexfu/J2zdqyErICQbkmQIDAQABo3wwejARBglghkgBhvhCAQEE BAMCAQYwRwYDVR0gBEAwPjA8BgtghkgBhvhFAQcBATAtMCsGCCsGAQUFBwIBFh93d3cudmVy aXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBMA8GA1UdEwQIMAYBAf8CAQAwCwYDVR0PBAQDAgEG MA0GCSqGSIb3DQEBAgUAA4GBAIi4Nzvd2pQ3AK2qn+GBAXEekmptL/bxndPKZDjcG5gMB4Zb hRVqD7lJhaSV8Rd9Z7R/LSzdmkKewz60jqrlCwbe8lYq+jPHvhnXU0zDvcjjF7WkSUJj7MKm Fw9dWBpJPJBcVaNlIAD9GCDlX4KmsaiSxVhqwY0DPOvDzQWikK5uMYICETCCAg0CAQEwgeEw gcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBO ZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29y cC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENB IEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEGZ+fUcOLiUb AXrQlXki5HswCQYFKw4DAhoFAKCBhjAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG SIb3DQEJBTEPFw0wMDEyMDYxNjQ4MTVaMCMGCSqGSIb3DQEJBDEWBBRSFJYZN3jj68hAK2Tn 9OWkDkFNIzAnBgkqhkiG9w0BCQ8xGjAYMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMA0GCSqG SIb3DQEBAQUABIGABfugxpvng26hpiu9b6n0JWjzLXLKNaiuRrbNcDcQf/wfqmCo6EAnOHGb pCf+ypdqSxu4Zc0IvabWGLatVIbCigZfm23PksWMejJRODdKyYrkp7m8EmlosZmtVPyDpRk/ Kvbv3S8qeym4atxR+epZzPhLwOR+vScos8iGXcBlaBw= --------------msF75B8446DCA2B6E1773847C3-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Dec 6 08:56:25 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta1+Sun/8.11.2.Beta1) id eB6GtSY09888 for ipng-dist; Wed, 6 Dec 2000 08:55:28 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.2.Beta1+Sun/8.11.2.Beta1) with ESMTP id eB6GtJr09881 for ; Wed, 6 Dec 2000 08:55:19 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id IAA12721 for ; Wed, 6 Dec 2000 08:55:20 -0800 (PST) Received: from relay1.nce.smtp.psi.net (relay1.nce.smtp.psi.net [38.9.152.2]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA15134 for ; Wed, 6 Dec 2000 08:55:19 -0800 (PST) Received: from [198.138.94.6] (helo=smtp.txc.com) by relay1.nce.smtp.psi.net with smtp (Exim 3.13 #3) id 143hqO-0006is-00; Wed, 06 Dec 2000 11:55:12 -0500 Received: from jade.txc.com by smtp.txc.com (4.1/SMI-4.1) id AA11248; Wed, 6 Dec 00 11:49:56 EST Received: from txc.com by jade.txc.com (SMI-8.6/SMI-SVR4) id LAA05357; Wed, 6 Dec 2000 11:54:54 -0500 Message-Id: <3A2E6F5E.15358BF6@txc.com> Date: Wed, 06 Dec 2000 11:54:54 -0500 From: Alex Conta X-Mailer: Mozilla 4.72 [en] (Win98; I) X-Accept-Language: en Mime-Version: 1.0 To: Francis Dupont Cc: Brian E Carpenter , "'ipng@sunroof.eng.sun.com'" Subject: Re: Usage of IPv6 flow label References: <200012011821.TAA13934@givry.rennes.enst-bretagne.fr> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------msAC49AF4A39F9636A61D354C0" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This is a cryptographically signed message in MIME format. --------------msAC49AF4A39F9636A61D354C0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Francis Dupont wrote: > > [...] > > Alex's idea of using "server port number" is in fact > interesting, since it would allow you to classify traffic > on its original well-known port #, without having to rely > on dynamically assigned port #s for classification. > > => I don't like the idea to have an official cover-channel > with the flow label: security people won't buy this. > They'd like to hide things then they can express their policy > (ie. what they accept to reveal) into the SPD then the choice > of SPIs... > Francis, If I understand you correctly, you think it is not good to have the flow-label carry "in clear" information which is also carried in parts of the transport header, which is hidden through encryption. Well, the source and destination, are in clear.... But, if one wants to protect the flow label, then the packet can be encrypted in tunnel mode, to hide everything in the IPv6 maim header. Alex --------------msAC49AF4A39F9636A61D354C0 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIKBgYJKoZIhvcNAQcCoIIJ9zCCCfMCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC B70wggSHMIID8KADAgECAhBmfn1HDi4lGwF60JV5IuR7MA0GCSqGSIb3DQEBBAUAMIHMMRcw FQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5 IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRp dmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAwMDkyNjAwMDAw MFoXDTAxMDkyNjIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UE CxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9y ZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMV UGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBO ZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNVBAMUCkFsZXggQ29udGExHTAbBgkqhkiG9w0B CQEWDmFjb250YUB0eGMuY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC+BilF+LEo x0rhxqMsHXVa+gyHyrH2EtFEzHpahyckngPWpr7Qs84/urQzbXrfENmUFceQwz0Vgy2pu4/h 6IdnwspvjPpN5TIsFb+zE4+3FnFfiBCjO/lLk4I55n7s6xGuHh6ndOm57diHpLYg5x/xVbLI 4UFfkNiF0zCHPd5qjQIDAQABo4IBJjCCASIwCQYDVR0TBAIwADBEBgNVHSAEPTA7MDkGC2CG SAGG+EUBBwEIMCowKAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEw EQYJYIZIAYb4QgEBBAQDAgeAMIGGBgpghkgBhvhFAQYDBHgWdmQ0NjUyYmQ2M2YyMDQ3MDI5 Mjk4NzYzYzlkMmYyNzUwNjljNzM1OWJlZDFiMDU5ZGE3NWJjNGJjOTcwMTc0N2RhNWQzZjIx NDFiZWFkYjJiZDJlODkyMTZhYjYyZjFkNDExNDk5Y2EzYmU0N2ZkZjNlYTQ1MGMwMwYDVR0f BCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDANBgkqhkiG 9w0BAQQFAAOBgQBrO9RNDzCcKmFVXb2puL1VbHA0VqjhaD4Gm10zfjihYsLx2XzTWdvd8tBR 29HcF4WYOaw4r3Kbp2rttSCIbei8OgDOCPZcsGZEvLYho0PsocJV4saVsPEWq8n0Xxoz5qkV rBHXl0X4CvFYvbdjZiPJs2Gs4DwTe3AFi9WhFDyiJDCCAy4wggKXoAMCAQICEQDSdi6NFAw9 fbKoJV2v7g11MA0GCSqGSIb3DQEBAgUAMF8xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJp U2lnbiwgSW5jLjE3MDUGA1UECxMuQ2xhc3MgMSBQdWJsaWMgUHJpbWFyeSBDZXJ0aWZpY2F0 aW9uIEF1dGhvcml0eTAeFw05ODA1MTIwMDAwMDBaFw0wODA1MTIyMzU5NTlaMIHMMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFG MEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJl Zi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlk dWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMIGfMA0GCSqGSIb3DQEBAQUA A4GNADCBiQKBgQC7WkSKBBa7Vf0DeootlE8VeDa4DUqyb5xUv7zodyqdufBou5XZMUFweoFL uUgTVi3HCOGEQqvAopKrRFyqQvCCDgLpL/vCO7u+yScKXbawNkIztW5UiE+HSr8Z2vkV6A+H thzjzMaajn9qJJLj/OBluqexfu/J2zdqyErICQbkmQIDAQABo3wwejARBglghkgBhvhCAQEE BAMCAQYwRwYDVR0gBEAwPjA8BgtghkgBhvhFAQcBATAtMCsGCCsGAQUFBwIBFh93d3cudmVy aXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBMA8GA1UdEwQIMAYBAf8CAQAwCwYDVR0PBAQDAgEG MA0GCSqGSIb3DQEBAgUAA4GBAIi4Nzvd2pQ3AK2qn+GBAXEekmptL/bxndPKZDjcG5gMB4Zb hRVqD7lJhaSV8Rd9Z7R/LSzdmkKewz60jqrlCwbe8lYq+jPHvhnXU0zDvcjjF7WkSUJj7MKm Fw9dWBpJPJBcVaNlIAD9GCDlX4KmsaiSxVhqwY0DPOvDzQWikK5uMYICETCCAg0CAQEwgeEw gcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBO ZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29y cC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENB IEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEGZ+fUcOLiUb AXrQlXki5HswCQYFKw4DAhoFAKCBhjAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG SIb3DQEJBTEPFw0wMDEyMDYxNjU0NTZaMCMGCSqGSIb3DQEJBDEWBBS2kXeWhRXHgFVn17hL CmKmTrKlUjAnBgkqhkiG9w0BCQ8xGjAYMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMA0GCSqG SIb3DQEBAQUABIGAhT8fi3FbHrUinp09Zjkh682fJxMtl471iK3BtWUXvg0jMkmYccvAEWfZ 0iTV4t3SJ6RRtLb6dJPnovz1FJS0kYxwSI/BHqT5LcxzKr9EOEGygUFHhb1Myl9c5mJn29u+ vIgnrvTgjdkbpr6FNLoHE+40zC+jGzgqcVUrvCu0N5Y= --------------msAC49AF4A39F9636A61D354C0-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Dec 6 09:14:37 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta1+Sun/8.11.2.Beta1) id eB6HCxB09923 for ipng-dist; Wed, 6 Dec 2000 09:12:59 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.2.Beta1+Sun/8.11.2.Beta1) with ESMTP id eB6HCor09916 for ; Wed, 6 Dec 2000 09:12:50 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id JAA16647 for ; Wed, 6 Dec 2000 09:12:49 -0800 (PST) Received: from relay1.nce.smtp.psi.net (relay1.nce.smtp.psi.net [38.9.152.2]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA22195 for ; Wed, 6 Dec 2000 10:12:48 -0700 (MST) Received: from [198.138.94.6] (helo=smtp.txc.com) by relay1.nce.smtp.psi.net with smtp (Exim 3.13 #3) id 143i76-0002Qt-00; Wed, 06 Dec 2000 12:12:16 -0500 Received: from jade.txc.com by smtp.txc.com (4.1/SMI-4.1) id AA11508; Wed, 6 Dec 00 12:07:06 EST Received: from txc.com by jade.txc.com (SMI-8.6/SMI-SVR4) id MAA06005; Wed, 6 Dec 2000 12:12:04 -0500 Message-Id: <3A2E7364.A52A29E3@txc.com> Date: Wed, 06 Dec 2000 12:12:04 -0500 From: Alex Conta X-Mailer: Mozilla 4.72 [en] (Win98; I) X-Accept-Language: en Mime-Version: 1.0 To: Jim Bound Cc: Steve Deering , Francis Dupont , Brian E Carpenter , itojun@iijlab.net, "'ipng@sunroof.eng.sun.com'" Subject: Re: Usage of IPv6 flow label References: <200012041740.MAA0000887797@anw.zk3.dec.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms04FD2128DB9DDD3F7CA6436B" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This is a cryptographically signed message in MIME format. --------------ms04FD2128DB9DDD3F7CA6436B Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit If I recall correctly, the DEC bit didn't need allocation, so I do not follow the analogy you're making to the "flow label" allocation. Alex P.S. the DEC bit was used by early DECNET versions, but I am not sure if it was not dropped in DECnet Phase 5, when OSI network protocols replaced the proprietary DECnet ones. A similar, but somewhat extended mechanism exists in Frame Relay networks: BECN & FECN. Jim Bound wrote: > > >>In the future I can see two cases: > >> - the flow label is set by the source (first camp) > >> - the flow label is set by an edge router (with the DiffServ definition > >> of what is an edge router) because the source box (or its user) is > >> too dumb to deal with QoS/..., according to the edge router manager. > > >If the Flow Label is set by something other than the source node, how > >do you guarantee its uniqueness, over the topological scope in which > >it must be unique? Do you need to invent a protocol between the routers > >on a LAN to divvy up the Flow label space? What happens when the LAN > >partitions, then routers in the different partitions assign duplicate > >Flow Labels, and then the partition heals? > > Obviously I agree with Steve and this is a killer point. Recall in dec > when we pushed the CE bit and it would only work exactly as Steve states > won't work above. It never got used or deployed. It needs to come from > the source and honored by the routers. > > /jim > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- --------------ms04FD2128DB9DDD3F7CA6436B Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIKBgYJKoZIhvcNAQcCoIIJ9zCCCfMCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC B70wggSHMIID8KADAgECAhBmfn1HDi4lGwF60JV5IuR7MA0GCSqGSIb3DQEBBAUAMIHMMRcw FQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5 IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRp dmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAwMDkyNjAwMDAw MFoXDTAxMDkyNjIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UE CxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9y ZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMV UGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBO ZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNVBAMUCkFsZXggQ29udGExHTAbBgkqhkiG9w0B CQEWDmFjb250YUB0eGMuY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC+BilF+LEo x0rhxqMsHXVa+gyHyrH2EtFEzHpahyckngPWpr7Qs84/urQzbXrfENmUFceQwz0Vgy2pu4/h 6IdnwspvjPpN5TIsFb+zE4+3FnFfiBCjO/lLk4I55n7s6xGuHh6ndOm57diHpLYg5x/xVbLI 4UFfkNiF0zCHPd5qjQIDAQABo4IBJjCCASIwCQYDVR0TBAIwADBEBgNVHSAEPTA7MDkGC2CG SAGG+EUBBwEIMCowKAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEw EQYJYIZIAYb4QgEBBAQDAgeAMIGGBgpghkgBhvhFAQYDBHgWdmQ0NjUyYmQ2M2YyMDQ3MDI5 Mjk4NzYzYzlkMmYyNzUwNjljNzM1OWJlZDFiMDU5ZGE3NWJjNGJjOTcwMTc0N2RhNWQzZjIx NDFiZWFkYjJiZDJlODkyMTZhYjYyZjFkNDExNDk5Y2EzYmU0N2ZkZjNlYTQ1MGMwMwYDVR0f BCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDANBgkqhkiG 9w0BAQQFAAOBgQBrO9RNDzCcKmFVXb2puL1VbHA0VqjhaD4Gm10zfjihYsLx2XzTWdvd8tBR 29HcF4WYOaw4r3Kbp2rttSCIbei8OgDOCPZcsGZEvLYho0PsocJV4saVsPEWq8n0Xxoz5qkV rBHXl0X4CvFYvbdjZiPJs2Gs4DwTe3AFi9WhFDyiJDCCAy4wggKXoAMCAQICEQDSdi6NFAw9 fbKoJV2v7g11MA0GCSqGSIb3DQEBAgUAMF8xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJp U2lnbiwgSW5jLjE3MDUGA1UECxMuQ2xhc3MgMSBQdWJsaWMgUHJpbWFyeSBDZXJ0aWZpY2F0 aW9uIEF1dGhvcml0eTAeFw05ODA1MTIwMDAwMDBaFw0wODA1MTIyMzU5NTlaMIHMMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFG MEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJl Zi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlk dWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMIGfMA0GCSqGSIb3DQEBAQUA A4GNADCBiQKBgQC7WkSKBBa7Vf0DeootlE8VeDa4DUqyb5xUv7zodyqdufBou5XZMUFweoFL uUgTVi3HCOGEQqvAopKrRFyqQvCCDgLpL/vCO7u+yScKXbawNkIztW5UiE+HSr8Z2vkV6A+H thzjzMaajn9qJJLj/OBluqexfu/J2zdqyErICQbkmQIDAQABo3wwejARBglghkgBhvhCAQEE BAMCAQYwRwYDVR0gBEAwPjA8BgtghkgBhvhFAQcBATAtMCsGCCsGAQUFBwIBFh93d3cudmVy aXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBMA8GA1UdEwQIMAYBAf8CAQAwCwYDVR0PBAQDAgEG MA0GCSqGSIb3DQEBAgUAA4GBAIi4Nzvd2pQ3AK2qn+GBAXEekmptL/bxndPKZDjcG5gMB4Zb hRVqD7lJhaSV8Rd9Z7R/LSzdmkKewz60jqrlCwbe8lYq+jPHvhnXU0zDvcjjF7WkSUJj7MKm Fw9dWBpJPJBcVaNlIAD9GCDlX4KmsaiSxVhqwY0DPOvDzQWikK5uMYICETCCAg0CAQEwgeEw gcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBO ZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29y cC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENB IEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEGZ+fUcOLiUb AXrQlXki5HswCQYFKw4DAhoFAKCBhjAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG SIb3DQEJBTEPFw0wMDEyMDYxNzEyMDZaMCMGCSqGSIb3DQEJBDEWBBSb58XR7zGmwj8YoPa+ a+gC6mEcTTAnBgkqhkiG9w0BCQ8xGjAYMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMA0GCSqG SIb3DQEBAQUABIGApQvIOZbuWVyHLiTphJhml2cv0YvSPaFDAElvy+Bw8HixsDa0ZPk2iYNo EPagLncuKR4Kj0wmXX9DkvRlSRkwCyb5AkJfxiOycxF3cHxCbH9PikQP4QrmL3Pd/LTxOcIC YnGGHjoKPBbx1ZdBjIA6eYJSWPDPVWfQNNeFALIrRGc= --------------ms04FD2128DB9DDD3F7CA6436B-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Dec 6 09:18:11 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta1+Sun/8.11.2.Beta1) id eB6HGvo09949 for ipng-dist; Wed, 6 Dec 2000 09:16:57 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.2.Beta1+Sun/8.11.2.Beta1) with ESMTP id eB6HGmr09942 for ; Wed, 6 Dec 2000 09:16:49 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id JAA18909 for ; Wed, 6 Dec 2000 09:16:48 -0800 (PST) Received: from mailrelay1.chek.com (gutmans.chek.com [208.197.227.23]) by saturn.sun.com (8.9.3+Sun/8.9.3) with SMTP id JAA28963 for ; Wed, 6 Dec 2000 09:16:48 -0800 (PST) Received: (qmail 17926 invoked from network); 6 Dec 2000 17:16:46 -0000 Received: from ninelives.chek.com (208.197.227.14) by mailrelay1.chek.com with SMTP; 6 Dec 2000 17:16:46 -0000 Received: (qmail 22027 invoked by uid 99); 6 Dec 2000 17:16:15 -0000 Date: 6 Dec 2000 17:16:15 -0000 Message-ID: <20001206171615.22026.qmail@ninelives.chek.com> From: "Emanuel Moreira" To: ipng@sunroof.eng.sun.com, msripv6-users@list.research.microsoft.com, users@ipv6.org Content-Type: text/html; X-MASSMAIL: 1.0 X-Originating-IP: [193.137.173.132] Subject: RAT and SDR Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I'm trying to use RAT and SDR applications but when I try to run them the following message appears: for SDR.exe "The procedure entry point getnodebyname could not be located in the dynamic link library WSHIP6.dll." for RAT.exe "The procedure entry point inet6_addr could not be located in the dynamic link library WSHIP6.dll." What does this mean? Thanks Emanuel Moreira _____________________________________________________________ O e-mail preferido dos portugueses http://www.portugalmail.pt -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Dec 6 09:50:07 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta1+Sun/8.11.2.Beta1) id eB6HmUI10016 for ipng-dist; Wed, 6 Dec 2000 09:48:30 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.2.Beta1+Sun/8.11.2.Beta1) with ESMTP id eB6HmLr10009 for ; Wed, 6 Dec 2000 09:48:22 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id JAA27234 for ; Wed, 6 Dec 2000 09:48:22 -0800 (PST) Received: from relay1.nce.smtp.psi.net (relay1.nce.smtp.psi.net [38.9.152.2]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA11084 for ; Wed, 6 Dec 2000 10:48:20 -0700 (MST) Received: from [198.138.94.6] (helo=smtp.txc.com) by relay1.nce.smtp.psi.net with smtp (Exim 3.13 #3) id 143ify-0000t3-00; Wed, 06 Dec 2000 12:48:18 -0500 Received: from jade.txc.com by smtp.txc.com (4.1/SMI-4.1) id AA11837; Wed, 6 Dec 00 12:43:16 EST Received: from txc.com by jade.txc.com (SMI-8.6/SMI-SVR4) id MAA07247; Wed, 6 Dec 2000 12:48:16 -0500 Message-Id: <3A2E7BDF.D45163B9@txc.com> Date: Wed, 06 Dec 2000 12:48:15 -0500 From: Alex Conta X-Mailer: Mozilla 4.72 [en] (Win98; I) X-Accept-Language: en Mime-Version: 1.0 To: Steve Deering Cc: "'ipng@sunroof.eng.sun.com'" Subject: Re: Usage of IPv6 flow label References: <200012011821.TAA13934@givry.rennes.enst-bretagne.fr> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------msAC0BF88FE1BE4308BC094E78" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This is a cryptographically signed message in MIME format. --------------msAC0BF88FE1BE4308BC094E78 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit If the topological space on which a label is unique is reduced, ala MPLS, to a one-hop link, and the label distribution is using TCP, ala MPLS, the collision of the label space in case of LAN partioning/healing is an interesting problem. It can be handled, I think, assuming, the first and the last hop of a communication, in several ways: a. there is no collision because - the label allocation continues undisturbed after partitioning/healing, and - only the originally LAN designated router does the allocation. The "one-hop" TCP connection for Label Distribution that exists between each host and the LAN router in the pre-partioning stage, becomes a "two or more hops" connection during the "partioned" stage, to come back to the "one-hop" form after "healing". b. at partitioning, the newly designated routers and their dependent hosts do, ala MPLS: - break old peering, with deallocation of labels - create new peering, with reallocation of labels at healing, the process is repeated. This process affects only the next-hop to the host, and thus does not affect the rest of the path. c. designated routers divide the label space, as you said, to prevent collision after potential partioning/healing. Alex Steve Deering wrote: > > At 7:21 PM +0100 12/1/00, Francis Dupont wrote: > >In the future I can see two cases: > > - the flow label is set by the source (first camp) > > - the flow label is set by an edge router (with the DiffServ definition > > of what is an edge router) because the source box (or its user) is > > too dumb to deal with QoS/..., according to the edge router manager. > > If the Flow Label is set by something other than the source node, how > do you guarantee its uniqueness, over the topological scope in which > it must be unique? Do you need to invent a protocol between the routers > on a LAN to divvy up the Flow label space? What happens when the LAN > partitions, then routers in the different partitions assign duplicate > Flow Labels, and then the partition heals? > > Steve > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- --------------msAC0BF88FE1BE4308BC094E78 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIKBgYJKoZIhvcNAQcCoIIJ9zCCCfMCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC B70wggSHMIID8KADAgECAhBmfn1HDi4lGwF60JV5IuR7MA0GCSqGSIb3DQEBBAUAMIHMMRcw FQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5 IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRp dmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAwMDkyNjAwMDAw MFoXDTAxMDkyNjIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UE CxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9y ZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMV UGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBO ZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNVBAMUCkFsZXggQ29udGExHTAbBgkqhkiG9w0B CQEWDmFjb250YUB0eGMuY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC+BilF+LEo x0rhxqMsHXVa+gyHyrH2EtFEzHpahyckngPWpr7Qs84/urQzbXrfENmUFceQwz0Vgy2pu4/h 6IdnwspvjPpN5TIsFb+zE4+3FnFfiBCjO/lLk4I55n7s6xGuHh6ndOm57diHpLYg5x/xVbLI 4UFfkNiF0zCHPd5qjQIDAQABo4IBJjCCASIwCQYDVR0TBAIwADBEBgNVHSAEPTA7MDkGC2CG SAGG+EUBBwEIMCowKAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEw EQYJYIZIAYb4QgEBBAQDAgeAMIGGBgpghkgBhvhFAQYDBHgWdmQ0NjUyYmQ2M2YyMDQ3MDI5 Mjk4NzYzYzlkMmYyNzUwNjljNzM1OWJlZDFiMDU5ZGE3NWJjNGJjOTcwMTc0N2RhNWQzZjIx NDFiZWFkYjJiZDJlODkyMTZhYjYyZjFkNDExNDk5Y2EzYmU0N2ZkZjNlYTQ1MGMwMwYDVR0f BCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDANBgkqhkiG 9w0BAQQFAAOBgQBrO9RNDzCcKmFVXb2puL1VbHA0VqjhaD4Gm10zfjihYsLx2XzTWdvd8tBR 29HcF4WYOaw4r3Kbp2rttSCIbei8OgDOCPZcsGZEvLYho0PsocJV4saVsPEWq8n0Xxoz5qkV rBHXl0X4CvFYvbdjZiPJs2Gs4DwTe3AFi9WhFDyiJDCCAy4wggKXoAMCAQICEQDSdi6NFAw9 fbKoJV2v7g11MA0GCSqGSIb3DQEBAgUAMF8xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJp U2lnbiwgSW5jLjE3MDUGA1UECxMuQ2xhc3MgMSBQdWJsaWMgUHJpbWFyeSBDZXJ0aWZpY2F0 aW9uIEF1dGhvcml0eTAeFw05ODA1MTIwMDAwMDBaFw0wODA1MTIyMzU5NTlaMIHMMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFG MEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJl Zi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlk dWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMIGfMA0GCSqGSIb3DQEBAQUA A4GNADCBiQKBgQC7WkSKBBa7Vf0DeootlE8VeDa4DUqyb5xUv7zodyqdufBou5XZMUFweoFL uUgTVi3HCOGEQqvAopKrRFyqQvCCDgLpL/vCO7u+yScKXbawNkIztW5UiE+HSr8Z2vkV6A+H thzjzMaajn9qJJLj/OBluqexfu/J2zdqyErICQbkmQIDAQABo3wwejARBglghkgBhvhCAQEE BAMCAQYwRwYDVR0gBEAwPjA8BgtghkgBhvhFAQcBATAtMCsGCCsGAQUFBwIBFh93d3cudmVy aXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBMA8GA1UdEwQIMAYBAf8CAQAwCwYDVR0PBAQDAgEG MA0GCSqGSIb3DQEBAgUAA4GBAIi4Nzvd2pQ3AK2qn+GBAXEekmptL/bxndPKZDjcG5gMB4Zb hRVqD7lJhaSV8Rd9Z7R/LSzdmkKewz60jqrlCwbe8lYq+jPHvhnXU0zDvcjjF7WkSUJj7MKm Fw9dWBpJPJBcVaNlIAD9GCDlX4KmsaiSxVhqwY0DPOvDzQWikK5uMYICETCCAg0CAQEwgeEw gcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBO ZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29y cC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENB IEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEGZ+fUcOLiUb AXrQlXki5HswCQYFKw4DAhoFAKCBhjAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG SIb3DQEJBTEPFw0wMDEyMDYxNzQ4MTZaMCMGCSqGSIb3DQEJBDEWBBQK54SwNSlTtFiFeMII op8SjEiCETAnBgkqhkiG9w0BCQ8xGjAYMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMA0GCSqG SIb3DQEBAQUABIGAB8sMdJLipI/QqV4AQLbttx1y4hX/6AejYvl0qVbWfseZVfPaFLQQTsNs iiNg9cE2ZjydNLpA0EX8xPuWMxsuF5FGx9xhG42dE771YUR2ipILhOGoBgBA8tPmZJi43bU3 SwNG9BQwnjIUpScYeBETmrHaeFt5DItNMLayP4UCkf4= --------------msAC0BF88FE1BE4308BC094E78-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Dec 6 10:10:40 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta1+Sun/8.11.2.Beta1) id eB6I7eX10104 for ipng-dist; Wed, 6 Dec 2000 10:07:40 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.2.Beta1+Sun/8.11.2.Beta1) with ESMTP id eB6I7Tr10097 for ; Wed, 6 Dec 2000 10:07:31 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id KAA01615 for ; Wed, 6 Dec 2000 10:07:24 -0800 (PST) Received: from melimelo.enst-bretagne.fr (melimelo.enst-bretagne.fr [192.108.115.36]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA17714 for ; Wed, 6 Dec 2000 10:07:23 -0800 (PST) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by melimelo.enst-bretagne.fr (8.10.1/8.10.1) with ESMTP id eB6I7B413345; Wed, 6 Dec 2000 19:07:11 +0100 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id TAA14087; Wed, 6 Dec 2000 19:07:10 +0100 (MET) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.9.3/8.9.3) with ESMTP id TAA44746; Wed, 6 Dec 2000 19:07:49 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200012061807.TAA44746@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Alex Conta cc: Brian E Carpenter , "'ipng@sunroof.eng.sun.com'" Subject: Re: Usage of IPv6 flow label In-reply-to: Your message of Wed, 06 Dec 2000 11:54:54 EST. <3A2E6F5E.15358BF6@txc.com> Date: Wed, 06 Dec 2000 19:07:49 +0100 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: If I understand you correctly, you think it is not good to have the flow-label carry "in clear" information which is also carried in parts of the transport header, which is hidden through encryption. => I am afraid that the paranoic security guy (and usually he is) will simply say: flow label is supposed to be a pseudo-random number, someone is using it as a cover channel, just reset it to zero. I agree this will be a silly attitude but in fact the flow label was not designed to do that (for years we don't use it and now we fight for keeping it for us :-). Well, the source and destination, are in clear.... But, if one wants to protect the flow label, then the packet can be encrypted in tunnel mode, to hide everything in the IPv6 maim header. => I am not a IPsec == VPN person. My real concern is I'd like to keep the flow label for IntServ, and to give to DiffServ more flexibility (ie. more/enough bits). I have no opinion about MPLS... Thanks Francis.Dupont@enst-bretagne.fr -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Dec 6 17:56:45 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta1+Sun/8.11.2.Beta1) id eB71tGB10481 for ipng-dist; Wed, 6 Dec 2000 17:55:16 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.2.Beta1+Sun/8.11.2.Beta1) with ESMTP id eB71t7r10474 for ; Wed, 6 Dec 2000 17:55:07 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id RAA06906 for ; Wed, 6 Dec 2000 17:55:06 -0800 (PST) Received: from zcamail01.zca.compaq.com (zcamail01.zca.compaq.com [161.114.32.101]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA09953 for ; Wed, 6 Dec 2000 17:55:06 -0800 (PST) Received: by zcamail01.zca.compaq.com (Postfix, from userid 12345) id DE4DC1556; Wed, 6 Dec 2000 17:56:32 -0800 (PST) Received: from anw.zk3.dec.com (wasted.zk3.dec.com [16.140.32.3]) by zcamail01.zca.compaq.com (Postfix) with ESMTP id 15CB314A3; Wed, 6 Dec 2000 17:56:32 -0800 (PST) Received: from localhost by anw.zk3.dec.com (8.9.3/1.1.22.2/08Sep98-0251PM) id UAA0000641890; Wed, 6 Dec 2000 20:54:53 -0500 (EST) From: Jim Bound Message-Id: <200012070154.UAA0000641890@anw.zk3.dec.com> To: Alex Conta Cc: Jim Bound , Steve Deering , Francis Dupont , Brian E Carpenter , itojun@iijlab.net, "'ipng@sunroof.eng.sun.com'" , bound@zk3.dec.com Subject: Re: Usage of IPv6 flow label In-reply-to: Your message of "Wed, 06 Dec 2000 12:12:04 EST." <3A2E7364.A52A29E3@txc.com> Date: Wed, 06 Dec 2000 20:54:53 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >If I recall correctly, the DEC bit didn't need allocation, so I do not >follow the analogy you're making to the "flow label" allocation. My analogy was that unless all nodes along the path support the method it does not work. regards, /jim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Dec 7 05:26:32 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta1+Sun/8.11.2.Beta1) id eB7DP3s10797 for ipng-dist; Thu, 7 Dec 2000 05:25:03 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.2.Beta1+Sun/8.11.2.Beta1) with ESMTP id eB7DOrr10790 for ; Thu, 7 Dec 2000 05:24:53 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id FAA06087 for ; Thu, 7 Dec 2000 05:24:54 -0800 (PST) Received: from mail-gw1.hursley.ibm.com (mail-gw1.hursley.ibm.com [194.196.110.15]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id FAA09871; Thu, 7 Dec 2000 05:24:51 -0800 (PST) Received: from sp15en17.hursley.ibm.com (sp15at17.hursley.ibm.com [9.20.45.103]) by mail-gw1.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id NAA10582; Thu, 7 Dec 2000 13:24:45 GMT Received: from hursley.ibm.com (gsine04.us.sine.ibm.com [9.14.6.44]) by sp15en17.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id NAA23366; Thu, 7 Dec 2000 13:24:37 GMT Message-ID: <3A2E953B.B9EF1DF1@hursley.ibm.com> Date: Wed, 06 Dec 2000 13:36:27 -0600 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en,fr MIME-Version: 1.0 To: Steve Deering CC: Francis Dupont , sommerfeld@east.sun.com, itojun@iijlab.net, "'ipng@sunroof.eng.sun.com'" Subject: Re: Usage of IPv6 flow label References: <200012012256.XAA17005@givry.rennes.enst-bretagne.fr> <3A2834A7.CDDCFD6C@hursley.ibm.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Catching up after some delay and being able to discuss this in person with Francis yesterday... Steve Deering wrote: > > At 5:30 PM -0600 12/1/00, Brian E Carpenter wrote: > >Francis Dupont wrote: > >... > > > => just associate a QoS to a SPI and send the information (ie. how to > > > classify packets (addresses, ..., SPI) and the QoS) to the classifier > > > (which is by definition on-path). > > > >Wrong model. That requires signalling; diffserv doesn't have signalling. > > > >This works for RSVP as itojun explained, but it doesn't work for diffserv. > > I'm getting confused. The Flow label is intended for intserv, so why > are you talking about subverting it (or the SPI) for diffserv? Because diffserv has a problem if it needs to re-classify encrypted traffic, since the port & protocol #s are hidden. However, the idea of an extension header is *much* better than subverting the flow label. > > If diffserv requires en-route inspection of the 5-tuple in order to set > the DSCP bits (and therefore you are trying to overload the Flow Label > with port semantics in order to avoid the cost of finding the ports), > that ought only to be done near the source edge (where parsing multiple > headers is less onerous), if at all, because of the ease with which one > could lie about one's port numbers to obtain better service. Are core > routers really going to provide different qualities of service to packets > based on an easily "forged" 8-bit integer? No, as has been said this will happen (if at all) in border routers. Theft of service is an issue - we don't want to pay authentication overhead in a real-time classifier. But traffic policing can take care of most cases. See RFC 2474 and 2475. > I thought core routers classified packets for diffserv packets according > to the arrival interface and the arriving DSCP bits, *not* the 5-tuple. Absolutely. It's only at the borders. So the model that probably works is an optional extension header that can be used for encrypted packets where the source doesn't mind exposing the port and protocol #s. However, people building classifier hardware may have something to say about this in terms of real time efficiency. Brian -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Dec 7 06:22:33 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta1+Sun/8.11.2.Beta1) id eB7ELDu10829 for ipng-dist; Thu, 7 Dec 2000 06:21:13 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.2.Beta1+Sun/8.11.2.Beta1) with ESMTP id eB7EL4r10822 for ; Thu, 7 Dec 2000 06:21:04 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id GAA18975 for ; Thu, 7 Dec 2000 06:21:04 -0800 (PST) Received: from ulexite.lion-access.net (ulexite.lion-access.net [212.19.217.2]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA18580 for ; Thu, 7 Dec 2000 07:21:03 -0700 (MST) Received: from xtreme (1Cust202.tnt23.rtm1.nl.uu.net [213.116.140.202]) by ulexite.lion-access.net (I-Lab) with SMTP id 98F7FFAF85; Thu, 7 Dec 2000 13:20:53 -0100 (GMT) From: "Joris Dobbelsteen" To: "'Emanuel Moreira'" Cc: "IPng WG (E-mail)" , , Subject: RE: RAT and SDR Date: Thu, 7 Dec 2000 15:22:57 +0100 MIME-Version: 1.0 Message-ID: <000001c06059$32a98460$01ff1fac@Thuis.local> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0000_01C06061.92E52980" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 In-Reply-To: <20001206171615.22026.qmail@ninelives.chek.com> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0000_01C06061.92E52980 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0001_01C06061.92E6B020" ------=_NextPart_001_0001_01C06061.92E6B020 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit You are probably running "Windows 2000" with "IPv6 Technology Preview for Windows 2000". A error like this occured also on my system with the same config, when trying to run ncFTP, obtained from Microsoft Research. Probably you need the version released at Microsoft Research and not the Technology Preview. MSR also states these are different releases. Please look at Microsoft research : www.research.microsoft.com -> Current Research -> Network -> IPv6. Download the MSR IPv6 kit from there (also suitable for Windows NT).... Please don't contact me about future problems with this issue, I don't know whether it works or something, just a feeling about this issue... - Joris -----Original Message----- From: owner-ipng@sunroof.eng.sun.com [mailto:owner-ipng@sunroof.eng.sun.com]On Behalf Of Emanuel Moreira Sent: Wednesday 06 December, 2000 18:16 To: ipng@sunroof.eng.sun.com; msripv6-users@list.research.microsoft.com; users@ipv6.org Subject: RAT and SDR I'm trying to use RAT and SDR applications but when I try to run them the following message appears: for SDR.exe "The procedure entry point getnodebyname could not be located in the dynamic link library WSHIP6.dll." for RAT.exe "The procedure entry point inet6_addr could not be located in the dynamic link library WSHIP6.dll." What does this mean? Thanks Emanuel Moreira _____________________________________________________________ O e-mail preferido dos portugueses http://www.portugalmail.pt -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- ------=_NextPart_001_0001_01C06061.92E6B020 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
You=20 are probably running "Windows 2000" with "IPv6 Technology Preview for = Windows=20 2000". A error like this occured also on my system with the same config, = when=20 trying to run ncFTP, obtained from Microsoft = Research.
 
Probably you need the version released at = Microsoft=20 Research and not the Technology Preview. MSR also states these are = different=20 releases.
 
Please=20 look at Microsoft research : www.research.microsoft.com= ->=20 Current Research -> Network -> IPv6. Download the MSR IPv6 kit = from there=20 (also suitable for Windows NT)....
Please=20 don't contact me about future problems with this issue, I don't know = whether it=20 works or something, just a feeling about this = issue...
 
-=20 Joris
-----Original Message-----
From:=20 owner-ipng@sunroof.eng.sun.com = [mailto:owner-ipng@sunroof.eng.sun.com]On=20 Behalf Of Emanuel Moreira
Sent: Wednesday 06 December, = 2000=20 18:16
To: ipng@sunroof.eng.sun.com;=20 msripv6-users@list.research.microsoft.com; = users@ipv6.org
Subject:=20 RAT and SDR

I'm trying to use RAT and SDR = applications but=20 when I try to run them the following message appears: for SDR.exe "The = procedure entry point getnodebyname could not be located in the = dynamic link=20 library WSHIP6.dll." for RAT.exe "The procedure entry point inet6_addr = could=20 not be located in the dynamic link library WSHIP6.dll." What does this = mean?=20 Thanks Emanuel Moreira=20 _____________________________________________________________ O e-mail = preferido dos portugueses http://www.portugalmail.pt=20 -------------------------------------------------------------------- = IETF IPng=20 Working Group Mailing List IPng Home Page: = http://playground.sun.com/ipng FTP=20 archive: ftp://playground.sun.com/pub/ipng Direct all administrative = requests=20 to majordomo@sunroof.eng.sun.com=20 --------------------------------------------------------------------=20 ------=_NextPart_001_0001_01C06061.92E6B020-- ------=_NextPart_000_0000_01C06061.92E52980 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIILpjCCAo4w ggH3oAMCAQICAwN9vzANBgkqhkiG9w0BAQQFADCBkjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdl c3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsT FENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAw MC44LjMwMB4XDTAwMTAyNjEyMjEwNVoXDTAxMTAyNjEyMjEwNVowTDEfMB0GA1UEAxMWVGhhd3Rl IEZyZWVtYWlsIE1lbWJlcjEpMCcGCSqGSIb3DQEJARYaam9yaXMuZG9iYmVsc3RlZW5AbWFpbC5j b20wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAMZAYuacHTm+k4rimibWE055OY6EUiJeWsny TfqfhYszNEtORJuGD3ZOxR4M/nGvuftXzx0lhCnLB9O3SCEedTOqZIOIbN388N2t1yul3HgfAgY/ HZtfJKKJsGOL6qJqufOxeCflkdTG9yKZUhMYmh+2ZGCJ1/fPMhwwkc05wqKLAgMBAAGjNzA1MCUG A1UdEQQeMByBGmpvcmlzLmRvYmJlbHN0ZWVuQG1haWwuY29tMAwGA1UdEwEB/wQCMAAwDQYJKoZI hvcNAQEEBQADgYEAys9KrmhwWCsNVwPxZyN179OeiiPeJMrtcGZ9MaEQt53Km59eeKVSrjXbimFK k07q9FkUi1pH2NmsrskqdY7e42wDL/hbbJ15mGIGm49fsQjK6hnrEuiiGGmiEf6ebzsjy2q0qtth 1fqEuBnvZA9z/exutdiA8e4keAEkosq0HmIwggKyMIICG6ADAgECAgMDfb4wDQYJKoZIhvcNAQEE BQAwgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUg VG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYG A1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMDAeFw0wMDEwMjYxMjIxMDFaFw0w MTEwMjYxMjIxMDFaMEwxHzAdBgNVBAMTFlRoYXd0ZSBGcmVlbWFpbCBNZW1iZXIxKTAnBgkqhkiG 9w0BCQEWGmpvcmlzLmRvYmJlbHN0ZWVuQG1haWwuY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCB iQKBgQC/DGszqHm6R+DXJwRbo11Yyic4B8JZRd3Qw4AKBqghFc0joji5QCJt+2ehun+dnNenCh1Q mVeduABQ519t1ax+KTxDJcAVeyflZBdN53KtWHpjhrLoyhJWx8CvQ+xpM5MnQApUnVkelrawmE9W BLU+KgEzRMsrsNoNUXPoMJiXlwIDAQABo1swWTAPBgNVHQ8BAf8EBQMDB/mAMBEGCWCGSAGG+EIB AQQEAwIFIDAlBgNVHREEHjAcgRpqb3Jpcy5kb2JiZWxzdGVlbkBtYWlsLmNvbTAMBgNVHRMBAf8E AjAAMA0GCSqGSIb3DQEBBAUAA4GBAGQ9qreO/VYg+OVqfsDaykzgFPixo8221fZX8mbxM+FBW8Bq sO9zKFCPbL0SaymQvPTa2IKto54WXOOKIQgGwBlEvF1ZMOp4CuaDDeKecS8aIsHce6Wa6P1wRQxP tej2PKf+wvfrS/zaqh0ouIRpn/cgjqtuSeI0Rxrps6UiMXjTMIIDKTCCApKgAwIBAgIBDDANBgkq hkiG9w0BAQQFADCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UE BxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlm aWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAw MDgzMDAwMDAwMFoXDTAyMDgyOTIzNTk1OVowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0 ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRD ZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAu OC4zMDCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA3jMypmPHCSVFPtJueCdngcXaiBmClw7j RCmKYzUqbXA8+tyu9+50bzC8M5B/+TRxoKNtmPHDT6Jl2w36S/HW3WGl+YXNVZo1Gp2Sdagnrthy +boC9tewkd4c6avgGAOofENCUFGHgzzwObSbVIoTh/+zm51JZgAtCYnslGvpoWkCAwEAAaNOMEww KQYDVR0RBCIwIKQeMBwxGjAYBgNVBAMTEVByaXZhdGVMYWJlbDEtMjk3MBIGA1UdEwEB/wQIMAYB Af8CAQAwCwYDVR0PBAQDAgEGMA0GCSqGSIb3DQEBBAUAA4GBAHMbbyZli/8VNEtZYortRL5Jx+gN u4+5DWomKmKEH7iHY3QcbbfPGlORS+HN5jjZ7VD0Omw0kqzmkpxuwSMBwgmn70uuct0GZ/VQby5Y uLYLwVBXtewc1+8XttWIm7eiiBrtOVs5fTT8tpYYJU1q9J3Fw5EvqZa4BTxS/N3pYgNIMIIDLTCC ApagAwIBAgIBADANBgkqhkiG9w0BAQQFADCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rl cm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEo MCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3Rl IFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0 aGF3dGUuY29tMB4XDTk2MDEwMTAwMDAwMFoXDTIwMTIzMTIzNTk1OVowgdExCzAJBgNVBAYTAlpB MRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhh d3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24x JDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVy c29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA1GnX 1LCUZFtx6UfYDFG26nKRsIRefS0Nj3sS34UldSh0OkIsYyeflXtL734Zhx2G6qPduc6WZBrCFG5E rHzmj+hND3EfQDimAKOHePb5lIZererAXnbr2RSjXW56fAylS1V/Bhkpf56aJtVquzgkCGqYx7Ha o5iR/Xnb5VrEHLkCAwEAAaMTMBEwDwYDVR0TAQH/BAUwAwEB/zANBgkqhkiG9w0BAQQFAAOBgQDH 7JJ+Tvj1lqVnYiqk8E0RYNBvjWBYYawmu1I1XAjPMPuoSpaKH2JCI4wXD/S6ZJwXrEcp352YXtJs YHFcoqzceePnbgBHH7UNKOgCneSa/RP0ptl8sfjcXyMmCZGAc9AUG95DqYMl8uacLxXK/qarigd1 iwzdUYRr5PjRzneigTGCApowggKWAgEBMIGaMIGSMQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2Vz dGVybiBDYXBlMRIwEAYDVQQHEwlDYXBlIFRvd24xDzANBgNVBAoTBlRoYXd0ZTEdMBsGA1UECxMU Q2VydGlmaWNhdGUgU2VydmljZXMxKDAmBgNVBAMTH1BlcnNvbmFsIEZyZWVtYWlsIFJTQSAyMDAw LjguMzACAwN9vzAJBgUrDgMCGgUAoIIBVTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG SIb3DQEJBTEPFw0wMDEyMDcxNDIyNTVaMCMGCSqGSIb3DQEJBDEWBBTS2jwjhPp8ojtp5OOcYnSr mGrLJjBIBgkqhkiG9w0BCQ8xOzA5MAoGCCqGSIb3DQMHMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEo MAcGBSsOAwIaMAoGCCqGSIb3DQIFMIGrBgkrBgEEAYI3EAQxgZ0wgZowgZIxCzAJBgNVBAYTAlpB MRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhh d3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJl ZW1haWwgUlNBIDIwMDAuOC4zMAIDA32+MA0GCSqGSIb3DQEBAQUABIGAIjjK6HdP6pb8aXAeWBy0 Okq34xJ0lBJxbRTfIwEh6E6ldAq+vPF9wb1JiE7q1qp6fk0fCTSKtgmyAT+B7P0HlI0P4ofA7TSi q3l7XP7yOBoHicJbxisWxMgdwLKMaPEqGm6mc/+Sb5fDSJ5Xk68N1c9nqnxXJJQGM6+ihX0p+/QA AAAAAAA= ------=_NextPart_000_0000_01C06061.92E52980-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Dec 7 06:45:06 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta1+Sun/8.11.2.Beta1) id eB7EggW10863 for ipng-dist; Thu, 7 Dec 2000 06:42:42 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.2.Beta1+Sun/8.11.2.Beta1) with ESMTP id eB7EgUr10856 for ; Thu, 7 Dec 2000 06:42:30 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id GAA26219 for ; Thu, 7 Dec 2000 06:42:29 -0800 (PST) Received: from mail.ipf.es (mail.ipf.es [62.164.0.20]) by patan.sun.com (8.9.3+Sun/8.9.3) with SMTP id GAA22968 for ; Thu, 7 Dec 2000 06:42:22 -0800 (PST) Received: (qmail 5546 invoked from network); 7 Dec 2000 14:45:06 -0000 Received: from consulintel.customer.pool4.infovia.gigabell.es (HELO consulintel.es) (62.164.5.2) by mail.ipf.es with SMTP; 7 Dec 2000 14:45:06 -0000 Received: from consulintel02 [10.0.0.135] by consulintel.es [127.0.0.1] with SMTP (MDaemon.v3.1.0.R) for ; Thu, 07 Dec 2000 15:40:51 +0100 Message-ID: <003801c0605b$b1846c30$8700000a@consulintel02> Reply-To: "JORDI PALET MARTINEZ" From: "JORDI PALET MARTINEZ" To: , , , , "IPv6 Forum Board" , Subject: IPv6 Articles & reports for Madrid Summit Date: Thu, 7 Dec 2000 15:40:49 +0100 Organization: Consulintel MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0035_01C06064.12F33A20" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 X-MDaemon-Deliver-To: ipng@sunroof.eng.sun.com X-Return-Path: jordi@consulintel.es X-MDRcpt-To: ipng@sunroof.eng.sun.com X-MDRemoteIP: 10.0.0.135 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0035_01C06064.12F33A20 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable As part of the press coverage that we will get before, during and after = the Madrid Global IPv6 Summit, the IT magazine producer IDG, is = preparing a special edition that will be included during January (2001) = with the Spanish edition of Communications World Magazine (monthly = edition) and Computerworld (weekly edition). The total coverage will = reach about 50.000 readers, plus the Portugal editions. This special "insert" will be 32 pages, and that means a lot of space = for our information, articles, white papers, reports, ... that we will = translate, if necessary, to Spanish. To be successful, your cooperation. All the documents will include, = unless you indicate it, the author name and the company/organization. We will like to get documents non larger than 12.000 characters = (including spaces), and of course, with some graphics, to make more = attractive the reading. If possible, we will prefer all the documents in Word format. Let us = know if this is a problem for you, and we will look for an alternative. You can write or propose any existing document related to any IPv6 = issue, including your own products/services, projects, protocols, = technologies, experiences, future, ISP aspects, mobility, = infrastructures, wireless, VPN, QoS, security, VoIP6, .... Due to the Christmas season, the edition need to be closed before 20th = of December, and that means YOU will need to deliver to us your article = or document BEFORE 12th, in order to be in time for the translation. If you agree, we plan to get all the articles, both, English and Spanish = versions, in the conference and IPv6 Forum web site. Thanks and best regards, Jordi Palet Consulintel http://www.consulintel.es Tel: 91 484 18 21 - Fax: 91 484 18 22 ********************************************** GLOBAL IPv6 SUMMIT - Madrid - 29/01/2001-01/02/2001 http://www.consulintel.es/ipv6.htm ********************************************** ------=_NextPart_000_0035_01C06064.12F33A20 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
As part of the press coverage that we = will get=20 before, during and after the Madrid Global IPv6 Summit, the IT = magazine producer IDG, is preparing a special edition that will be = included=20 during January (2001) with the Spanish edition of Communications World = Magazine=20 (monthly edition) and Computerworld (weekly edition). The total coverage = will=20 reach about 50.000 readers, plus the Portugal = editions.
 
This special "insert" will be 32 = pages, and=20 that means a lot of space for our information, articles, white papers, = reports,=20 ... that we will translate, if necessary, to Spanish.
 
To be successful, your = cooperation. All the=20 documents will include, unless you indicate it, the author name and the=20 company/organization.
 
We will like to get documents non = larger than=20 12.000 characters (including spaces), and of course, with some graphics, = to=20 make more attractive the reading.
 
If possible, we will prefer all the = documents in=20 Word format. Let us know if this is a problem for you, and we will look = for an=20 alternative.
 
You can write or propose any existing=20 document related to any IPv6 issue, including your own = products/services,=20 projects, protocols, technologies, experiences, future, ISP aspects, = mobility,=20 infrastructures, wireless, VPN, QoS, security, VoIP6, ....
 
Due to the Christmas season, the = edition need to be=20 closed before 20th of December, and that means YOU will need to deliver = to us=20 your article or document BEFORE 12th, in order to be in time for the=20 translation.
 
If you agree, we plan to get all the = articles,=20 both, English and Spanish versions, in the conference and IPv6 Forum web = site.
 
Thanks and best regards,
 
Jordi Palet
Consulintel
 
http://www.consulintel.es
Tel: 91 = 484 18 21 -=20 Fax: 91 484 18 22
 

**********************************************
GLOBAL IPv6 SUMMIT - Madrid - 29/01/2001-01/02/2001
http://www.consulintel.es/ipv6.htm
**********************************************
------=_NextPart_000_0035_01C06064.12F33A20-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Dec 7 07:12:54 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta1+Sun/8.11.2.Beta1) id eB7FAXp10899 for ipng-dist; Thu, 7 Dec 2000 07:10:33 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.2.Beta1+Sun/8.11.2.Beta1) with ESMTP id eB7FALr10892 for ; Thu, 7 Dec 2000 07:10:21 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id HAA19012 for ; Thu, 7 Dec 2000 07:10:21 -0800 (PST) Received: from mail-blue.research.att.com (mail-blue.research.att.com [135.207.30.102]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA25931 for ; Thu, 7 Dec 2000 07:10:20 -0800 (PST) Received: from postal.research.att.com (postal.research.att.com [135.207.23.30]) by mail-blue.research.att.com (Postfix) with ESMTP id 626D04CE19; Thu, 7 Dec 2000 10:10:19 -0500 (EST) Received: from smb.research.att.com (postal.research.att.com [135.207.23.30]) by postal.research.att.com (8.8.7/8.8.7) with ESMTP id KAA17685; Thu, 7 Dec 2000 10:10:17 -0500 (EST) Received: from smb.research.att.com (localhost.research.att.com [127.0.0.1]) by smb.research.att.com (Postfix) with ESMTP id 82B8735DC2; Thu, 7 Dec 2000 09:05:04 -0500 (EST) X-Mailer: exmh version 2.2 06/23/2000 with version: MH 6.8.3 #1[UCI] From: "Steven M. Bellovin" To: Brian E Carpenter Cc: Steve Deering , Francis Dupont , sommerfeld@east.sun.com, itojun@iijlab.net, "'ipng@sunroof.eng.sun.com'" Subject: Re: Usage of IPv6 flow label Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 07 Dec 2000 09:05:04 -0500 Message-Id: <20001207140504.82B8735DC2@smb.research.att.com> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In message <3A2E953B.B9EF1DF1@hursley.ibm.com>, Brian E Carpenter writes: >Catching up after some delay and being able to discuss this >in person with Francis yesterday... > >Steve Deering wrote: >> >> At 5:30 PM -0600 12/1/00, Brian E Carpenter wrote: >> >Francis Dupont wrote: >> >... >> > > => just associate a QoS to a SPI and send the information (ie. how to >> > > classify packets (addresses, ..., SPI) and the QoS) to the classifier >> > > (which is by definition on-path). >> > >> >Wrong model. That requires signalling; diffserv doesn't have signalling. >> > >> >This works for RSVP as itojun explained, but it doesn't work for diffserv. >> >> I'm getting confused. The Flow label is intended for intserv, so why >> are you talking about subverting it (or the SPI) for diffserv? > >Because diffserv has a problem if it needs to re-classify encrypted >traffic, since the port & protocol #s are hidden. However, the idea >of an extension header is *much* better than subverting the flow >label. > Apart from the fact that I don't understand why diffserv would need to reclassify something that has already been classified, I don't think that we can manage an extension header. I tried -- the tf-esp effort -- but there was too much opposition, including several IAB and IESG members, and a lot of the IPsec community. --Steve Bellovin -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Dec 7 07:51:13 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta1+Sun/8.11.2.Beta1) id eB7FnoU10949 for ipng-dist; Thu, 7 Dec 2000 07:49:50 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.2.Beta1+Sun/8.11.2.Beta1) with ESMTP id eB7Fnfr10942 for ; Thu, 7 Dec 2000 07:49:41 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id HAA03509 for ; Thu, 7 Dec 2000 07:49:40 -0800 (PST) Received: from melimelo.enst-bretagne.fr (melimelo.enst-bretagne.fr [192.108.115.36]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA02545; Thu, 7 Dec 2000 07:49:36 -0800 (PST) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by melimelo.enst-bretagne.fr (8.10.1/8.10.1) with ESMTP id eB7FnO438335; Thu, 7 Dec 2000 16:49:25 +0100 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id QAA05031; Thu, 7 Dec 2000 16:49:24 +0100 (MET) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.9.3/8.9.3) with ESMTP id QAA52900; Thu, 7 Dec 2000 16:50:08 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200012071550.QAA52900@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: "Steven M. Bellovin" cc: Brian E Carpenter , Steve Deering , sommerfeld@east.sun.com, itojun@iijlab.net, "'ipng@sunroof.eng.sun.com'" Subject: Re: Usage of IPv6 flow label In-reply-to: Your message of Thu, 07 Dec 2000 09:05:04 EST. <20001207140504.82B8735DC2@smb.research.att.com> Date: Thu, 07 Dec 2000 16:50:08 +0100 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: >Because diffserv has a problem if it needs to re-classify encrypted >traffic, since the port & protocol #s are hidden. However, the idea >of an extension header is *much* better than subverting the flow >label. > Apart from the fact that I don't understand why diffserv would need to reclassify something that has already been classified, I don't think that we can manage an extension header. => reclassification will occur when a domain boundary is crossed because it is not easy/possible to get a SLA with all the crossed ISPs... According to Brian, this was discussed in the DiffServ community and is accepted as a fact (even if many believe this is *not* the best thing). I tried -- the tf-esp effort -- but there was too much opposition, including several IAB and IESG members, and a lot of the IPsec community. => the context is a bit different because there is a real advantage to reveal/give some infos. In the previous attempt the argument was or you say what is in your packet or we'll drop it on the floor, of course this was very hard to accept by the IPsec community... My concern is more about our hardware colleagues, is this kind of solutions enough easy and cheap to implement? Thanks Francis.Dupont@enst-bretagne.fr -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Dec 7 08:08:43 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta1+Sun/8.11.2.Beta1) id eB7G6oQ10976 for ipng-dist; Thu, 7 Dec 2000 08:06:50 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.2.Beta1+Sun/8.11.2.Beta1) with ESMTP id eB7G6fr10969 for ; Thu, 7 Dec 2000 08:06:41 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id IAA27772 for ; Thu, 7 Dec 2000 08:06:41 -0800 (PST) Received: from mailhub1.almaden.ibm.com (mailhub1.almaden.ibm.com [198.4.83.44]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA24221 for ; Thu, 7 Dec 2000 08:06:40 -0800 (PST) Received: from maui.almaden.ibm.com (maui.almaden.ibm.com [9.1.24.92]) by mailhub1.almaden.ibm.com (8.8.8/8.8.8) with ESMTP id IAA37050; Thu, 7 Dec 2000 08:05:35 -0800 Received: from hursley.ibm.com (gsine04.us.sine.ibm.com [9.14.6.44]) by maui.almaden.ibm.com (AIX4.3/8.9.3/8.7) with ESMTP id IAA20734; Thu, 7 Dec 2000 08:06:32 -0800 Message-ID: <3A2FB549.5FD1A078@hursley.ibm.com> Date: Thu, 07 Dec 2000 10:05:29 -0600 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en,fr MIME-Version: 1.0 To: Alex Conta CC: Christian Huitema , "'ipng@sunroof.eng.sun.com'" Subject: Re: Usage of IPv6 flow label References: <3A2E6DCE.34A209AE@txc.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Alex Conta wrote: > > The capture of the type of application is in fact the idea behind the > IANA reserved/defined value of the "flow label type' in my "flow-label" > related recent draft. The first bit of the redefined > "flow label type" would indicate that it is a IANA number as opposed to > a "protocol/server-port". This "reserved/IANA defined" value is a better > indication than the "protocol/server-port". I think that's debatable, but you need to debate it over in the Transport and Management areas with all the QOS and QOS management experts. It's clearly out of this WG's core competence to take that decision. Brian -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Dec 7 10:40:14 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta1+Sun/8.11.2.Beta1) id eB7IcFH11092 for ipng-dist; Thu, 7 Dec 2000 10:38:15 -0800 (PST) Received: from eastmail2.East.Sun.COM (eastmail2.East.Sun.COM [129.148.1.241]) by sunroof.eng.sun.com (8.11.2.Beta1+Sun/8.11.2.Beta1) with ESMTP id eB7Ic6r11085 for ; Thu, 7 Dec 2000 10:38:06 -0800 (PST) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail2.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id NAA26139; Thu, 7 Dec 2000 13:38:04 -0500 (EST) Received: from thunk (localhost [127.0.0.1]) by thunk.east.sun.com (8.11.1+Sun/8.10.2) with ESMTP id eB7IbOa115140; Thu, 7 Dec 2000 13:37:24 -0500 (EST) Message-Id: <200012071837.eB7IbOa115140@thunk.east.sun.com> From: Bill Sommerfeld To: Brian E Carpenter cc: Steve Deering , Francis Dupont , sommerfeld@east.sun.com, itojun@iijlab.net, "'ipng@sunroof.eng.sun.com'" Subject: Re: Usage of IPv6 flow label In-reply-to: Your message of "Wed, 06 Dec 2000 13:36:27 CST." <3A2E953B.B9EF1DF1@hursley.ibm.com> Reply-to: sommerfeld@east.sun.com Date: Thu, 07 Dec 2000 13:37:24 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I haven't seen a convincing case why even inter-ISP classifiers need to know the inner port numbers or inner ip addresses for encrypted traffic. If I were implementing the hypothetical extension header, I'd have to provide policy knobs which determine whether it gets added to outbound traffic; while i'm there, in the interests of reducing traffic analysis, I might as well add a knob which lets the policy rule specify what goes in the extension header (independant of the actual inner traffic), and naturally, in the interest of interoperability, there's no way that the receiver would enforce a relationship between the extension header and the actual packet traffic (because it doesn't actually matter to the end system and flies in the face of the "be liberal in what you accept" principle). Given that, I don't see what the extension header actually buys you.. The inter-ISP classifier can still reclassify based on a 3-tuple (outer-src,outer-dst,outer-proto=ESP), and at the ISP boundary can still deliver differentiated services to customers who want (and pay for) priority handling of encrypted traffic based on the destination address of a packet received from a peer using an unknown diffserv tagging scheme; and, even if you do know the tagging scheme, you still likely have to use the inbound tag in conjunction with other selectors to determine the tag used within your network.. If there's demand for multiple classes of handling for encrypted traffic between a single pair of hosts, then both customers will be in a position to pressure their ISP's to play nice together and agree how to label traffic on the inter-ISP link. - Bill -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Dec 7 11:42:30 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta1+Sun/8.11.2.Beta1) id eB7Jf1Q11139 for ipng-dist; Thu, 7 Dec 2000 11:41:01 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.2.Beta1+Sun/8.11.2.Beta1) with ESMTP id eB7Jeqr11132 for ; Thu, 7 Dec 2000 11:40:52 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id LAA21158 for ; Thu, 7 Dec 2000 11:40:51 -0800 (PST) Received: from mailhub1.almaden.ibm.com (mailhub1.almaden.ibm.com [198.4.83.44]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA04943; Thu, 7 Dec 2000 12:40:46 -0700 (MST) Received: from maui.almaden.ibm.com (maui.almaden.ibm.com [9.1.24.92]) by mailhub1.almaden.ibm.com (8.8.8/8.8.8) with ESMTP id LAA17702; Thu, 7 Dec 2000 11:39:44 -0800 Received: from hursley.ibm.com (gsine04.us.sine.ibm.com [9.14.6.44]) by maui.almaden.ibm.com (AIX4.3/8.9.3/8.7) with ESMTP id LAA27354; Thu, 7 Dec 2000 11:40:42 -0800 Message-ID: <3A2FE74F.662E16C9@hursley.ibm.com> Date: Thu, 07 Dec 2000 13:38:55 -0600 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en,fr MIME-Version: 1.0 To: sommerfeld@east.sun.com CC: Steve Deering , Francis Dupont , itojun@iijlab.net, "'ipng@sunroof.eng.sun.com'" Subject: Re: Usage of IPv6 flow label References: <200012071837.eB7IbOa115140@thunk.east.sun.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Bill, You describe accurately what we get by changing nothing: encrypted traffic will be subject to a less rich set of QOS policy options than unencrypted traffic. Brian Bill Sommerfeld wrote: > > I haven't seen a convincing case why even inter-ISP classifiers need > to know the inner port numbers or inner ip addresses for encrypted > traffic. > > If I were implementing the hypothetical extension header, I'd have to > provide policy knobs which determine whether it gets added to outbound > traffic; while i'm there, in the interests of reducing traffic > analysis, I might as well add a knob which lets the policy rule > specify what goes in the extension header (independant of the actual > inner traffic), and naturally, in the interest of interoperability, > there's no way that the receiver would enforce a relationship between > the extension header and the actual packet traffic (because it doesn't > actually matter to the end system and flies in the face of the "be > liberal in what you accept" principle). > > Given that, I don't see what the extension header actually buys you.. > > The inter-ISP classifier can still reclassify based on a 3-tuple > (outer-src,outer-dst,outer-proto=ESP), and at the ISP boundary can > still deliver differentiated services to customers who want (and pay > for) priority handling of encrypted traffic based on the destination > address of a packet received from a peer using an unknown diffserv > tagging scheme; and, even if you do know the tagging scheme, you still > likely have to use the inbound tag in conjunction with other selectors > to determine the tag used within your network.. > > If there's demand for multiple classes of handling for encrypted > traffic between a single pair of hosts, then both customers will be in > a position to pressure their ISP's to play nice together and agree how > to label traffic on the inter-ISP link. > > - Bill > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Dec 7 22:03:21 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta1+Sun/8.11.2.Beta1) id eB861ug11404 for ipng-dist; Thu, 7 Dec 2000 22:01:56 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.2.Beta1+Sun/8.11.2.Beta1) with ESMTP id eB861lr11397 for ; Thu, 7 Dec 2000 22:01:47 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id WAA19306 for ; Thu, 7 Dec 2000 22:01:46 -0800 (PST) Received: from aphelion.csl.sony.co.jp (aphelion.csl.sony.co.jp [133.138.1.94]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id WAA00332 for ; Thu, 7 Dec 2000 22:01:45 -0800 (PST) Received: from leo (leo.csl.sony.co.jp [43.27.100.62]) by aphelion.csl.sony.co.jp (8.9.3/3.7W) with ESMTP id PAA99345; Fri, 8 Dec 2000 15:01:43 +0900 (JST) Message-Id: <4.2.0.58.J.20001208140322.01f87ea8@aphelion.csl.sony.co.jp> X-Sender: tera@aphelion.csl.sony.co.jp X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58.J Date: Fri, 08 Dec 2000 15:06:52 +0900 To: ipng@sunroof.eng.sun.com From: Fumio Teraoka Subject: mobility support based on e2e model Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In the last slot of the thursday ipng session of the Dan Diego IETF meeting, we give a short talk on "LIN6: Mobility Support in IPv6 based on End-to-End Communication Model". i-d is available at the following URL: ftp://ftp.csl.sony.co.jp/CSL/tera/draft-teraoka-mobility-lin6-00.txt LIN6 has several advantages in comparison with Mobile IPv6 as follows: o LIN6 has no header overhead because it does not use any extension headers of IPv6 while Mobile IPv6 uses the Destination Options Header for the Home Address Option and the Routing Header. o LIN6 is more fault tolerant than Mobile IPv6. In Mobile IPv6, the Home Agent cannot be replicated to the subnet other than the home link of the mobile node. LIN6 introduces the Mapping Agent which can be replicated anywhere in the Internet. o LIN6 keeps end-to-end communication model, that is, LIN6 does not use any packet intercepter/forwarder such as the Home Agent of Mobile IPv6. There is no tunneling in LIN6. Fumio Teraoka Sony Computer Science Labs., Inc. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Dec 7 23:34:14 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta1+Sun/8.11.2.Beta1) id eB87Wtc11440 for ipng-dist; Thu, 7 Dec 2000 23:32:55 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.2.Beta1+Sun/8.11.2.Beta1) with ESMTP id eB87Wir11433 for ; Thu, 7 Dec 2000 23:32:44 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id XAA02464 for ; Thu, 7 Dec 2000 23:32:44 -0800 (PST) Received: from hoteldns02.stsn.com (p214.usslc13.stsn.com [208.32.226.214]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id AAA05094 for ; Fri, 8 Dec 2000 00:32:42 -0700 (MST) Received: from starfruit.itojun.org ([10.0.58.117]) by hoteldns02.stsn.com (8.9.3/8.8.7) with SMTP id AAA11440 for ; Fri, 8 Dec 2000 00:31:55 -0700 Received: from itojun.org (localhost [127.0.0.1]) by starfruit.itojun.org (Postfix) with ESMTP id C80717E23; Fri, 8 Dec 2000 15:59:10 +0900 (JST) To: Fumio Teraoka Cc: ipng@sunroof.eng.sun.com In-reply-to: tera's message of Fri, 08 Dec 2000 15:06:52 +0900. <4.2.0.58.J.20001208140322.01f87ea8@aphelion.csl.sony.co.jp> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: mobility support based on e2e model From: Jun-ichiro itojun Hagino Date: Fri, 08 Dec 2000 15:59:10 +0900 Message-Id: <20001208065910.C80717E23@starfruit.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >In the last slot of the thursday ipng session of the Dan Diego >IETF meeting, we give a short talk on "LIN6: Mobility Support >in IPv6 based on End-to-End Communication Model". >i-d is available at the following URL: > ftp://ftp.csl.sony.co.jp/CSL/tera/draft-teraoka-mobility-lin6-00.txt the draft needs to answer number of (IMHO critical) questions, including the following. correct me if i'm wrong about these. caveat: i have never used LIN6 myself. itojun - scalability. how will we assign LIN6-ID to people? if we do it in hierarchical manner, what is the expected H ratio for LIN6-ID assignment under EUI64/MAC prefix 00-01-4a? how many nodes are to be supported by 48bit (or 24bit?) open space in LIN6-ID? - lack of extensibility in LIN6-ID. once we ship LIN6 products with hardcoded LIN6-ID EUI64/MAC prexix 00-01-4a, we cannot introduce any new LIN6-ID prefix. - header processing order when we use IPsec with LIN6 packet. we need something like draft-ietf-mobileip-ipv6-13.txt section 10.2. for example, - should we lookup SAs with LIN6 generalized ID, or LIN6 address? - when should we apply mapping? is it before AH crypto checksum computation or afterwards? - processing order in ipsec tunnel cases can be more trickier than mobile-ip6 case. - what are we supposed to do with routing header and other address-in-header? - apparently we must not advertise LIN6 prefix using RA. - suppose we have a LIN6-enabled http client, and a LIN6-enabled http server. how can the server send a reply to the client? the server will see, on the wire, the following packet: src = (network prefix for client, LIN6 ID for client) dst = (network prefix for server, LIN6 ID for server) tcp layer then sees: src = (LIN6 prefix, LIN6 ID for client) dst = (LIN6 prefix, LIN6 ID for server) tcp layer will reply to the packet with: src = (LIN6 prefix, LIN6 ID for server) dst = (LIN6 prefix, LIN6 ID for client) now, how can the server map (LIN6 prefix, LIN6 ID for client), into (network prefix for client, LIN6 ID for client)? note that Mapping Agent cannot be used, as we need to know the FQDN of the client to know the Mapping Agent for the client. if we need to cache every mapping we have seen in inbound processing, we need to mention how we need to update Mapping Cache, in section 7.2. (also note that, the server will never be able to recover the mapping if Mapping Cache entry is lost/purged due to starvation, as the server do not necessarily have the FQDN of the client!) - what is the recommended Mapping Cache size? apparently we need to keep the number of possible Mapping Cache entries larger than the number of TCP connections. - behavior of nodes if there's no reachability to the Mapping Agents. - details about the patent (section 8) and licensing twists. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Dec 8 01:49:10 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta1+Sun/8.11.2.Beta1) id eB89liV11632 for ipng-dist; Fri, 8 Dec 2000 01:47:44 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.2.Beta1+Sun/8.11.2.Beta1) with ESMTP id eB89lZr11625 for ; Fri, 8 Dec 2000 01:47:35 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id BAA01541 for ; Fri, 8 Dec 2000 01:47:35 -0800 (PST) Received: from aphelion.csl.sony.co.jp (aphelion.csl.sony.co.jp [133.138.1.94]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA19020 for ; Fri, 8 Dec 2000 01:47:34 -0800 (PST) Received: from leo (leo.csl.sony.co.jp [43.27.100.62]) by aphelion.csl.sony.co.jp (8.9.3/3.7W) with ESMTP id SAA99765; Fri, 8 Dec 2000 18:47:31 +0900 (JST) Message-Id: <4.2.0.58.J.20001208174254.01f49f00@aphelion.csl.sony.co.jp> X-Sender: tera@aphelion.csl.sony.co.jp X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58.J Date: Fri, 08 Dec 2000 18:52:38 +0900 To: Jun-ichiro itojun Hagino From: Fumio Teraoka Subject: Re: mobility support based on e2e model Cc: ipng@sunroof.eng.sun.com In-Reply-To: <20001208065910.C80717E23@starfruit.itojun.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Itojun, Thank you for your prompt comments. At 00/12/08 15:59 +0900, Jun-ichiro itojun Hagino wrote: >- scalability. how will we assign LIN6-ID to people? if we do it in > hierarchical manner, what is the expected H ratio for LIN6-ID assignment > under EUI64/MAC prefix 00-01-4a? how many nodes are to be supported by > 48bit (or 24bit?) open space in LIN6-ID? >- lack of extensibility in LIN6-ID. once we ship LIN6 products with > hardcoded LIN6-ID EUI64/MAC prexix 00-01-4a, we cannot introduce any > new LIN6-ID prefix. 00-01-4a is used for just a test of LIN6 on the current IPv6 backbone. Any EUI64 can be used as LIN6-ID. Method for notifying new OUI for LIN6-ID is under discussion. >- header processing order when we use IPsec with LIN6 packet. we need > something like draft-ietf-mobileip-ipv6-13.txt section 10.2. for example, > - should we lookup SAs with LIN6 generalized ID, or LIN6 address? LIN6 generalized ID. > - when should we apply mapping? is it before AH crypto checksum > computation or afterwards? after AH calculation. > - processing order in ipsec tunnel cases can be more trickier than > mobile-ip6 case. >- what are we supposed to do with routing header and other address-in-header? further study. >- apparently we must not advertise LIN6 prefix using RA. That's right. >- suppose we have a LIN6-enabled http client, and a LIN6-enabled http > server. how can the server send a reply to the client? CN (server) will learn the MA address for MN (client) by reverse lookup with the generalized ID of MN, and then CN (server) will learn the current network prefix of MN (client) by query to the MA. CN does not need to know the FQDN of MN. >- what is the recommended Mapping Cache size? apparently we need to > keep the number of possible Mapping Cache entries larger than the number > of TCP connections. >- behavior of nodes if there's no reachability to the Mapping Agents. further study. >- details about the patent (section 8) and licensing twists. futher study :P Fumio Teraoka Sony Computer Science Labs., Inc. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Dec 8 03:45:00 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta1+Sun/8.11.2.Beta1) id eB8Bhhg11729 for ipng-dist; Fri, 8 Dec 2000 03:43:43 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.2.Beta1+Sun/8.11.2.Beta1) with ESMTP id eB8BhYr11722 for ; Fri, 8 Dec 2000 03:43:34 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id DAA12955 for ; Fri, 8 Dec 2000 03:43:33 -0800 (PST) Received: from smtp2.kolumbus.fi (smtp2.kolumbus.fi [193.229.0.37]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id EAA19592 for ; Fri, 8 Dec 2000 04:43:32 -0700 (MST) Received: from jariws1 (aa103d3hel.dial.kolumbus.fi [212.54.17.103]) by smtp2.kolumbus.fi (8.9.0/8.9.0) with SMTP id NAA19944; Fri, 8 Dec 2000 13:43:28 +0200 (EET) Message-ID: <008e01c0610c$16237c20$8a1b6e0a@arenanet.fi> From: "Jari Arkko" To: , Subject: IPv6 Neighbour Solicitation messages and IPsec Date: Fri, 8 Dec 2000 13:43:30 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-Mimeole: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I'm wondering if there are any documents that specify rules regarding the use of IPsec in the context of IPv6 Neighbor Solicitations and possibly other ICMPv6 messages. As defined by http://www.ietf.org/rfc/rfc2461.txt, and http://www.ietf.org/rfc/rfc2462.txt such IPv6 messages are needed to perform the address resolution, address autoconfiguration, and duplicate address detection tasks. It seems that in some cases these messages can be unicast messages between the two nodes. (When the messages are multicast, IPsec doesn't apply.) It also seems that regular packets can't flow until the ICMPv6 packets have been exchanged, making sure the nodes know the link layer addresses and that no duplicate addresses are in use. I've run in to an interesting chicken-and-egg problem in this area as I'm developing an IPv6 IPsec implementation. If I set my policies in a way that all traffic in a LAN/WLAN should be protected with IPsec, then even some of these ICMPv6 messages are trapped by IPsec. In order to establish a security association, IKE needs to exchange a few UDP packets. However, if normal traffic can't flow until the ICMPv6 messages are exchanged, how can the UDP packets get through? In IPv4, this problem doesn't exist as either the corresponding functionality does not exist (duplicate address detection) or runs at a lower layer (ARP). http://www.ietf.org/rfc/rfc2401.txt talks a lot of IPv6 and ICMP, but doesn't seem to help in this matter. Also, the SPD requirements outlined in this RFC do not seem to be general enough to distinguish e.g. Neighbour Solicitations from Echo Requests, making it hard to define the policies in a suitable way. Can some folks who have done this before let me know how this should work, point to some existing documentation, or perhaps correct my understanding of the ICMPv6 operations. Thanks, Jari Arkko Ericsson -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Dec 8 08:08:49 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta1+Sun/8.11.2.Beta1) id eB8G7Aw11894 for ipng-dist; Fri, 8 Dec 2000 08:07:10 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.2.Beta1+Sun/8.11.2.Beta1) with ESMTP id eB8G71r11887 for ; Fri, 8 Dec 2000 08:07:01 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id IAA03039 for ; Fri, 8 Dec 2000 08:07:02 -0800 (PST) Received: from melimelo.enst-bretagne.fr (melimelo.enst-bretagne.fr [192.108.115.36]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA21211 for ; Fri, 8 Dec 2000 08:07:00 -0800 (PST) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by melimelo.enst-bretagne.fr (8.10.1/8.10.1) with ESMTP id eB8G3e413545; Fri, 8 Dec 2000 17:03:41 +0100 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id RAA19966; Fri, 8 Dec 2000 17:03:40 +0100 (MET) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.9.3/8.9.3) with ESMTP id RAA58587; Fri, 8 Dec 2000 17:04:29 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200012081604.RAA58587@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: "Jari Arkko" cc: ipsec@lists.tislabs.com, ipng@sunroof.eng.sun.com Subject: Re: IPv6 Neighbour Solicitation messages and IPsec In-reply-to: Your message of Fri, 08 Dec 2000 13:43:30 +0200. <008e01c0610c$16237c20$8a1b6e0a@arenanet.fi> Date: Fri, 08 Dec 2000 17:04:29 +0100 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: I'm wondering if there are any documents that specify rules regarding the use of IPsec in the context of IPv6 Neighbor Solicitations and possibly other ICMPv6 messages. => there was a nice presentation by Dan McDonald at a previous IETF about this (Adelaide, 47th, "Link shared secrets for ND") but no draft... I've run in to an interesting chicken-and-egg problem in this area as I'm developing an IPv6 IPsec implementation. => yes, ND should bypass the IPsec policy in some cases, for instance if the policy applies to any protocol, including ICMPv6. Also, the SPD requirements outlined in this RFC do not seem to be general enough to distinguish e.g. Neighbour Solicitations from Echo Requests, making it hard to define the policies in a suitable way. => there is a discussion about the PF_KEY API in order to solve this issue (is this API good for SPD setup is another point). Can some folks who have done this before let me know how this should work, point to some existing documentation, or perhaps correct my understanding of the ICMPv6 operations. => open issue, near no work about it! Regards Francis.Dupont@enst-bretagne.fr -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Dec 8 08:51:18 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta1+Sun/8.11.2.Beta1) id eB8GnY211944 for ipng-dist; Fri, 8 Dec 2000 08:49:34 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.2.Beta1+Sun/8.11.2.Beta1) with ESMTP id eB8GnNr11937 for ; Fri, 8 Dec 2000 08:49:23 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id IAA23591 for ; Fri, 8 Dec 2000 08:49:22 -0800 (PST) Received: from basto.stsn.com (p5.usslc14.stsn.com [12.23.74.5] (may be forged)) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA02336 for ; Fri, 8 Dec 2000 08:49:17 -0800 (PST) Received: from starfruit.itojun.org ([10.0.58.117]) by basto.stsn.com (8.9.3/8.8.7) with SMTP id JAA28548 for ; Fri, 8 Dec 2000 09:50:09 -0700 Received: from itojun.org (localhost [127.0.0.1]) by starfruit.itojun.org (Postfix) with ESMTP id D68437E23; Sat, 9 Dec 2000 01:48:51 +0900 (JST) To: Fumio Teraoka Cc: ipng@sunroof.eng.sun.com In-reply-to: tera's message of Fri, 08 Dec 2000 18:52:38 +0900. <4.2.0.58.J.20001208174254.01f49f00@aphelion.csl.sony.co.jp> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: mobility support based on e2e model From: Jun-ichiro itojun Hagino Date: Sat, 09 Dec 2000 01:48:51 +0900 Message-Id: <20001208164851.D68437E23@starfruit.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >At 00/12/08 15:59 +0900, Jun-ichiro itojun Hagino wrote: >>- scalability. how will we assign LIN6-ID to people? if we do it in >> hierarchical manner, what is the expected H ratio for LIN6-ID assignment >> under EUI64/MAC prefix 00-01-4a? how many nodes are to be supported by >> 48bit (or 24bit?) open space in LIN6-ID? >>- lack of extensibility in LIN6-ID. once we ship LIN6 products with >> hardcoded LIN6-ID EUI64/MAC prexix 00-01-4a, we cannot introduce any >> new LIN6-ID prefix. >00-01-4a is used for just a test of LIN6 on the current IPv6 >backbone. Any EUI64 can be used as LIN6-ID. Method for notifying >new OUI for LIN6-ID is under discussion. and how do you plan to handle the assignment? note that, (1) there are devices without MAC/EUI64 number, (2) there are ethernet cards shipped with unique/local bit set to "local" on MAC address, (3) there are multiple ethernet cards shipped with exactly the same MAC address. we can't rely upon its worldwide uniqueness. >>- suppose we have a LIN6-enabled http client, and a LIN6-enabled http >> server. how can the server send a reply to the client? >CN (server) will learn the MA address for MN (client) by reverse >lookup with the generalized ID of MN, and then CN (server) will >learn the current network prefix of MN (client) by query to the MA. >CN does not need to know the FQDN of MN. how can we manage the reverse lookup table? it looks close to impossible to handle reverse DNS delegation for generalized ID. itojun -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Dec 8 09:42:27 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta1+Sun/8.11.2.Beta1) id eB8Hf0w12061 for ipng-dist; Fri, 8 Dec 2000 09:41:00 -0800 (PST) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.11.2.Beta1+Sun/8.11.2.Beta1) with ESMTP id eB8Hetr12054 for ; Fri, 8 Dec 2000 09:40:55 -0800 (PST) Received: (from jrh@localhost) by stinker.eng.sun.com (8.11.0+Sun/8.11.0) id eB8HdaJ13036 for ipng@sunroof.eng.sun.com; Fri, 8 Dec 2000 09:39:36 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.2.Beta1+Sun/8.11.2.Beta1) with ESMTP id eB8BYTr11700 for ; Fri, 8 Dec 2000 03:34:30 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id DAA12339 for ; Fri, 8 Dec 2000 03:34:29 -0800 (PST) Received: from un.cct.ydc.co.jp (ydcspingw.ydc.co.jp [202.33.211.252]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id DAA19820 for ; Fri, 8 Dec 2000 03:34:26 -0800 (PST) Received: from odin.akisada.tahi.org (IDENT:akisada@[10.21.0.195]) by un.cct.ydc.co.jp (8.9.1+3.1W/3.7W) with SMTP id UAA16793 for ; Fri, 8 Dec 2000 20:37:18 +0900 (JST) Message-Id: <200012081137.UAA16793@un.cct.ydc.co.jp> Date: Fri, 8 Dec 2000 20:34:51 +0900 From: Yukiyo Akisada To: ipng@sunroof.eng.sun.com Subject: IPv6 Conformance Test Results X-Mailer: Sylpheed version 0.4.7 (GTK+ 1.2.8; Linux 2.4.0-test11; i686) Organization: YDC Corporation Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi there, TAHI Project has opened the IPv6 Conformance Test Results to the public at the following web site: http://www.tahi.org/ This target is kame-20001204-freebsd35-snap. Thanks, --- Yukiyo Akisada @ TAHI Project -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sat Dec 9 03:59:51 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta1+Sun/8.11.2.Beta1) id eB9BwOH12515 for ipng-dist; Sat, 9 Dec 2000 03:58:24 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.2.Beta1+Sun/8.11.2.Beta1) with ESMTP id eB9BwFr12508 for ; Sat, 9 Dec 2000 03:58:15 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id DAA13904 for ; Sat, 9 Dec 2000 03:58:13 -0800 (PST) Received: from aphelion.csl.sony.co.jp (aphelion.csl.sony.co.jp [133.138.1.94]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA29767 for ; Sat, 9 Dec 2000 03:58:12 -0800 (PST) Received: from vega ([133.138.197.2]) by aphelion.csl.sony.co.jp (8.9.3/3.7W) with ESMTP id UAA04733; Sat, 9 Dec 2000 20:58:02 +0900 (JST) Message-Id: <4.2.0.58.J.20001209204032.00a419d8@aphelion.csl.sony.co.jp> X-Sender: tera@aphelion.csl.sony.co.jp X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58.J Date: Sat, 09 Dec 2000 20:54:12 +0900 To: Jun-ichiro itojun Hagino From: Fumio Teraoka Subject: Re: mobility support based on e2e model Cc: ipng@sunroof.eng.sun.com In-Reply-To: <20001208164851.D68437E23@starfruit.itojun.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At 00/12/09 01:48 +0900, Jun-ichiro itojun Hagino wrote: > and how do you plan to handle the assignment? LIN6-ID should be allocated by registries as IP addresses. > how can we manage the reverse lookup table? it looks close to > impossible to handle reverse DNS delegation for generalized ID. For reverse lookup, LIN6-ID should have hierarchical structure. If we use upper 24 bits of EUI-64 for hierarchical structure, we can support 2^48 (= 2.8x10^13) nodes by a single EUI-64. If the half of the 48-bit space is practically available, 1.4x10^13 nodes can be supported by a single EUI-64. If a single EUI-64 space is exhausted, another EUI-64 can be allocated. Fumio Teraoka Sony Computer Science Labs., Inc. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sat Dec 9 07:58:37 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta1+Sun/8.11.2.Beta1) id eB9Fttd12616 for ipng-dist; Sat, 9 Dec 2000 07:55:55 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.2.Beta1+Sun/8.11.2.Beta1) with ESMTP id eB9Fthr12609 for ; Sat, 9 Dec 2000 07:55:44 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id HAA16914 for ; Sat, 9 Dec 2000 07:55:42 -0800 (PST) Received: from basto.stsn.com (p5.usslc14.stsn.com [12.23.74.5]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA04096 for ; Sat, 9 Dec 2000 07:55:40 -0800 (PST) Received: from starfruit.itojun.org ([10.0.58.117]) by basto.stsn.com (8.9.3/8.8.7) with SMTP id IAA05332 for ; Sat, 9 Dec 2000 08:56:35 -0700 Received: from itojun.org (localhost [127.0.0.1]) by starfruit.itojun.org (Postfix) with ESMTP id 7D0A87E2A; Sun, 10 Dec 2000 00:55:30 +0900 (JST) To: Fumio Teraoka Cc: ipng@sunroof.eng.sun.com In-reply-to: tera's message of Sat, 09 Dec 2000 20:54:12 +0900. <4.2.0.58.J.20001209204032.00a419d8@aphelion.csl.sony.co.jp> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: mobility support based on e2e model From: Jun-ichiro itojun Hagino Date: Sun, 10 Dec 2000 00:55:30 +0900 Message-Id: <20001209155530.7D0A87E2A@starfruit.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >> and how do you plan to handle the assignment? >LIN6-ID should be allocated by registries as IP addresses. >> how can we manage the reverse lookup table? it looks close to >> impossible to handle reverse DNS delegation for generalized ID. >For reverse lookup, LIN6-ID should have hierarchical structure. >If we use upper 24 bits of EUI-64 for hierarchical structure, >we can support 2^48 (= 2.8x10^13) nodes by a single EUI-64. If the >half of the 48-bit space is practically available, 1.4x10^13 nodes >can be supported by a single EUI-64. If a single EUI-64 space is >exhausted, another EUI-64 can be allocated. if we do hierarchical LIN6-ID assignment, allocation efficiency will follow RFC1715 H-ratio. if we annotate the table in RFC1715 section 3 for 48bit case, it should be like follows ("half of the 48-bit space is available" looks too optimistic). thank you for all the clarifications. itojun Pessimistic (0.14) Optimistic (0.26) 32 bits 3 E+4 (!) 2 E+8 48 bits 5 E+6 3 E+12 <-- 64 bits 9 E+8 4 E+16 80 bits 1.6 E+11 2.6 E+20 <-- RFC has a typo 128 bits 8 E+17 2 E+33 -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Dec 12 07:56:06 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta1+Sun/8.11.2.Beta1) id eBCFsd014483 for ipng-dist; Tue, 12 Dec 2000 07:54:39 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.2.Beta1+Sun/8.11.2.Beta1) with ESMTP id eBCFsUr14476; Tue, 12 Dec 2000 07:54:30 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id HAA20443; Tue, 12 Dec 2000 07:54:30 -0800 (PST) Received: from hygro.adsl.duke.edu (ietf.207.137.72.111.tx.verio.net [207.137.72.111]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA10415; Tue, 12 Dec 2000 08:54:29 -0700 (MST) Received: from hygro.adsl.duke.edu (narten@localhost) by hygro.adsl.duke.edu (8.11.0/8.9.3) with ESMTP id eBCFrNh00953; Tue, 12 Dec 2000 10:53:23 -0500 Message-Id: <200012121553.eBCFrNh00953@hygro.adsl.duke.edu> To: ietf@ietf.org cc: ngtrans@sunroof.eng.sun.com, ipng@sunroof.eng.sun.com, nanog@merit.edu Subject: IETF Multi-homing in IPv6 BOF Date: Tue, 12 Dec 2000 10:53:23 -0500 From: Thomas Narten Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Folks, There is a multi6 BOF scheduled for Today, Tuesday at 1PM in Marina5. The topic is "How should we multihome in IPv6". The original plans for this BOF did not solidify as intended and the BOF was canceled (as announced in Monday's ngtrans meeting). Due to the overall importance and interest level on the topic, however, there will be an informal meeting on multihoming in IPv6 in Marina5 during this time. Thomas -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Dec 12 17:48:32 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta1+Sun/8.11.2.Beta1) id eBD1kwS14872 for ipng-dist; Tue, 12 Dec 2000 17:46:58 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.2.Beta1+Sun/8.11.2.Beta1) with ESMTP id eBD1klr14865 for ; Tue, 12 Dec 2000 17:46:48 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id RAA21821 for ; Tue, 12 Dec 2000 17:46:47 -0800 (PST) Received: from necom830.hpcl.titech.ac.jp (necom830.hpcl.titech.ac.jp [131.112.32.132]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA12196 for ; Tue, 12 Dec 2000 17:46:46 -0800 (PST) From: Masataka Ohta Message-Id: <200012130140.KAA14572@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id KAA14572; Wed, 13 Dec 2000 10:40:40 +0900 Subject: Re: mobility support based on e2e model In-Reply-To: <20001209155530.7D0A87E2A@starfruit.itojun.org> from Jun-ichiro itojun Hagino at "Dec 10, 2000 00:55:30 am" To: Jun-ichiro itojun Hagino Date: Wed, 13 Dec 2000 10:40:39 +0859 () CC: Fumio Teraoka , ipng@sunroof.eng.sun.com X-Mailer: ELM [version 2.4ME+ PL68 (25)] Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk itojun; > >> and how do you plan to handle the assignment? > >LIN6-ID should be allocated by registries as IP addresses. > >> how can we manage the reverse lookup table? it looks close to > >> impossible to handle reverse DNS delegation for generalized ID. > >For reverse lookup, LIN6-ID should have hierarchical structure. > >If we use upper 24 bits of EUI-64 for hierarchical structure, > >we can support 2^48 (= 2.8x10^13) nodes by a single EUI-64. If the > >half of the 48-bit space is practically available, 1.4x10^13 nodes > >can be supported by a single EUI-64. If a single EUI-64 space is > >exhausted, another EUI-64 can be allocated. > > if we do hierarchical LIN6-ID assignment, allocation efficiency will > follow RFC1715 H-ratio. No, not at all. ID space needs no hierarchy for routing nor allginment for CIDR. The space will have a few levels of organizaional hierarchy (say, country/local_goverment/site). In each level, assignments can be tighntly packed and returned ID may be filled. All such points were discussed in my draft in March 1995. Masataka Ohta -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Dec 12 23:21:26 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta1+Sun/8.11.2.Beta1) id eBD7Jxa14971 for ipng-dist; Tue, 12 Dec 2000 23:19:59 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.2.Beta1+Sun/8.11.2.Beta1) with ESMTP id eBD7Jmr14964 for ; Tue, 12 Dec 2000 23:19:48 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id XAA25918 for ; Tue, 12 Dec 2000 23:19:48 -0800 (PST) Received: from starfruit.itojun.org (ietf.207.137.72.36.tx.verio.net [207.137.72.36]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id XAA29116 for ; Tue, 12 Dec 2000 23:19:48 -0800 (PST) Received: from itojun.org (localhost [127.0.0.1]) by starfruit.itojun.org (Postfix) with ESMTP id 6CC387E23; Wed, 13 Dec 2000 16:19:16 +0900 (JST) To: Masataka Ohta Cc: Fumio Teraoka , ipng@sunroof.eng.sun.com In-reply-to: mohta's message of Wed, 13 Dec 2000 10:40:39 +0859. <200012130140.KAA14572@necom830.hpcl.titech.ac.jp> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: mobility support based on e2e model From: Jun-ichiro itojun Hagino Date: Wed, 13 Dec 2000 16:19:16 +0900 Message-Id: <20001213071916.6CC387E23@starfruit.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >> if we do hierarchical LIN6-ID assignment, allocation efficiency will >> follow RFC1715 H-ratio. >No, not at all. ID space needs no hierarchy for routing nor allginment >for CIDR. >The space will have a few levels of organizaional hierarchy (say, >country/local_goverment/site). In each level, assignments can be >tighntly packed and returned ID may be filled. well, if you assign it hierarchical manner, you cannot pack it that well. imagine: - a company asks for IDs, - one-layer-up entity assigns it 8 bit space (for 256 machines), - the company actually has only 200 machines and 56 IDs are wasted. the situation looks exactly the same as the current IPv4 assignment. itojun -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Dec 13 02:47:52 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta1+Sun/8.11.2.Beta1) id eBDAkVC15103 for ipng-dist; Wed, 13 Dec 2000 02:46:31 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.2.Beta1+Sun/8.11.2.Beta1) with ESMTP id eBDAkLr15096 for ; Wed, 13 Dec 2000 02:46:21 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id CAA17749 for ; Wed, 13 Dec 2000 02:46:20 -0800 (PST) Received: from necom830.hpcl.titech.ac.jp (necom830.hpcl.titech.ac.jp [131.112.32.132]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA13430 for ; Wed, 13 Dec 2000 02:46:19 -0800 (PST) From: Masataka Ohta Message-Id: <200012131035.TAA15903@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id TAA15903; Wed, 13 Dec 2000 19:35:40 +0900 Subject: Re: mobility support based on e2e model In-Reply-To: <20001213071916.6CC387E23@starfruit.itojun.org> from Jun-ichiro itojun Hagino at "Dec 13, 2000 04:19:16 pm" To: Jun-ichiro itojun Hagino Date: Wed, 13 Dec 2000 19:35:40 +0859 () CC: Fumio Teraoka , ipng@sunroof.eng.sun.com X-Mailer: ELM [version 2.4ME+ PL68 (25)] Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk itojun; > >> if we do hierarchical LIN6-ID assignment, allocation efficiency will > >> follow RFC1715 H-ratio. > >No, not at all. ID space needs no hierarchy for routing nor allginment > >for CIDR. > >The space will have a few levels of organizaional hierarchy (say, > >country/local_goverment/site). In each level, assignments can be > >tighntly packed and returned ID may be filled. > > well, if you assign it hierarchical manner, you cannot pack it that > well. imagine: > - a company asks for IDs, OK. > - one-layer-up entity assigns it 8 bit space (for 256 machines), Huh? As I wrote: > >No, not at all. ID space needs no hierarchy for routing nor allginment > >for CIDR. There is no need to make the figure a power of 2. > - the company actually has only 200 machines and 56 IDs are wasted. If the company request 200 IDs, the one-layer-up entity can delegate exactly 200 IDs. Or, if the the one-layer-up entity think 200/256 large enough (I think this is the case), it can delegate 256 IDs. > the situation looks exactly the same as the current IPv4 assignment. No. Read the following sentense, again and again. > >No, not at all. ID space needs no hierarchy for routing nor allginment ^^^^^^^^^^ > >for CIDR. ^^^^^^^^^ Masataka Ohta -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Dec 13 07:09:55 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta1+Sun/8.11.2.Beta1) id eBDF7DX15220 for ipng-dist; Wed, 13 Dec 2000 07:07:13 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.2.Beta1+Sun/8.11.2.Beta1) with ESMTP id eBDF73r15213 for ; Wed, 13 Dec 2000 07:07:03 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id HAA29574 for ; Wed, 13 Dec 2000 07:06:48 -0800 (PST) Received: from mail.ipf.es (mail.ipf.es [62.164.0.20]) by saturn.sun.com (8.9.3+Sun/8.9.3) with SMTP id HAA09756 for ; Wed, 13 Dec 2000 07:06:45 -0800 (PST) Received: (qmail 16534 invoked from network); 13 Dec 2000 15:09:38 -0000 Received: from consulintel.customer.pool4.infovia.gigabell.es (HELO consulintel.es) (62.164.5.2) by mail.ipf.es with SMTP; 13 Dec 2000 15:09:38 -0000 Received: from consulintel02 [10.0.0.135] by consulintel.es [127.0.0.1] with SMTP (MDaemon.v3.1.0.R) for ; Wed, 13 Dec 2000 16:02:49 +0100 Message-ID: <00da01c06515$c0758620$8700000a@consulintel02> Reply-To: "JORDI PALET MARTINEZ" From: "JORDI PALET MARTINEZ" To: , , <6bone@ISI.EDU>, Subject: Madrid Global IPv6 Summit *** 29th January-1th February 2001 Date: Wed, 13 Dec 2000 16:02:46 +0100 Organization: Consulintel MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 X-MDaemon-Deliver-To: ipng@sunroof.eng.sun.com X-Return-Path: jordi@consulintel.es X-MDRcpt-To: msripv6-users@list.research.microsoft.com X-MDRemoteIP: 10.0.0.135 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id eBDF74r15214 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Dear IPv6 user, The Madrid Global IPv6 Summit is on the air ! You can register on the web site, on line at www.consulintel.es/ipv6.htm Register before 15th January 2001, not only to enjoy a lower rate, too because up to date, we have already 80% of the seats covered ! We recommend booking your room at the Convention Center, not only for your commodity, too because the excellent price (40 Euros), and extras that you will get (gym, sauna, and free drinks at night time). We will keep you updated, in a few days, about directions and transport instructions from the Airport (Madrid-Barajas) to the Convention Center. Our travel agency can get low fares on most international flights, alternative hotels, and other tourist activities. Proceed with the registrations steps to get the related information. Thanks and best regards, Jordi Palet IPv6 FORUM ********************************************** GLOBAL IPv6 SUMMIT - Madrid - 29/01/2001-01/02/2001 http://www.consulintel.es/ipv6.htm ********************************************** -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Dec 13 07:21:02 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta1+Sun/8.11.2.Beta1) id eBDFHpv15258 for ipng-dist; Wed, 13 Dec 2000 07:17:51 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.2.Beta1+Sun/8.11.2.Beta1) with ESMTP id eBDFHer15251 for ; Wed, 13 Dec 2000 07:17:40 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id HAA02078 for ; Wed, 13 Dec 2000 07:17:40 -0800 (PST) Received: from starfruit.itojun.org (ietf.207.137.73.138.tx.verio.net [207.137.73.138]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA15483 for ; Wed, 13 Dec 2000 07:17:40 -0800 (PST) Received: from itojun.org (localhost [127.0.0.1]) by starfruit.itojun.org (Postfix) with ESMTP id 08BFA7E23; Thu, 14 Dec 2000 00:17:11 +0900 (JST) To: Masataka Ohta Cc: Fumio Teraoka , ipng@sunroof.eng.sun.com In-reply-to: mohta's message of Wed, 13 Dec 2000 19:35:40 +0859. <200012131035.TAA15903@necom830.hpcl.titech.ac.jp> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: mobility support based on e2e model From: Jun-ichiro itojun Hagino Date: Thu, 14 Dec 2000 00:17:11 +0900 Message-Id: <20001213151711.08BFA7E23@starfruit.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >> - one-layer-up entity assigns it 8 bit space (for 256 machines), >Huh? >As I wrote: >> >No, not at all. ID space needs no hierarchy for routing nor allginment >> >for CIDR. >There is no need to make the figure a power of 2. >> - the company actually has only 200 machines and 56 IDs are wasted. >If the company request 200 IDs, the one-layer-up entity can delegate >exactly 200 IDs. >Or, if the the one-layer-up entity think 200/256 large enough (I think >this is the case), it can delegate 256 IDs. well, think about reality. can you really handle ID assignment requests, if they do not ask for ID by bulk? it was my mistake that I implied 2^n boundary, it was not my intention. what I was trying to mean was that there will be lots of wasted space. itojun -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Dec 13 08:39:53 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta1+Sun/8.11.2.Beta1) id eBDGc7s15331 for ipng-dist; Wed, 13 Dec 2000 08:38:07 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.2.Beta1+Sun/8.11.2.Beta1) with ESMTP id eBDGbwr15324 for ; Wed, 13 Dec 2000 08:37:58 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id IAA16470 for ; Wed, 13 Dec 2000 08:37:57 -0800 (PST) Received: from mailrelay1.chek.com (gutmans.chek.com [208.197.227.23]) by saturn.sun.com (8.9.3+Sun/8.9.3) with SMTP id IAA11094 for ; Wed, 13 Dec 2000 08:37:56 -0800 (PST) Received: (qmail 3951 invoked from network); 13 Dec 2000 16:37:51 -0000 Received: from meowmix.chek.com (208.197.227.10) by mailrelay1.chek.com with SMTP; 13 Dec 2000 16:37:51 -0000 Received: (qmail 17127 invoked by uid 99); 13 Dec 2000 16:36:34 -0000 Date: 13 Dec 2000 16:36:34 -0000 Message-ID: <20001213163634.17124.qmail@meowmix.chek.com> From: "Emanuel Moreira" To: jinmei@isl.rdc.toshiba.co.jp, ipng@sunroof.eng.sun.com, msripv6-users@list.research.microsoft.com, users@ipv6.org X-MASSMAIL: 1.0 X-Originating-IP: [193.136.173.40] Subject: Re: Multicast group Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I have a lan with 3 Pc's and I want to creat a multicast group so that I can make a ping6 from one Pc to the other's two using the multicast address as destination. How can I create this multicast group? Someone said to me that I would have to use sockets to make a multicast group. But can't I just give an multicast address to the three PC's and make a ping6 to that address. Is'nt this possible? Thanks Emanuel Moreira _____________________________________________________________ O e-mail preferido dos portugueses http://www.portugalmail.pt -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Dec 13 09:48:27 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta1+Sun/8.11.2.Beta1) id eBDHkgf15408 for ipng-dist; Wed, 13 Dec 2000 09:46:42 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.2.Beta1+Sun/8.11.2.Beta1) with ESMTP id eBDHkXr15401 for ; Wed, 13 Dec 2000 09:46:33 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id JAA03451 for ; Wed, 13 Dec 2000 09:46:32 -0800 (PST) Received: from necom830.hpcl.titech.ac.jp (necom830.hpcl.titech.ac.jp [131.112.32.132]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA01934 for ; Wed, 13 Dec 2000 09:46:30 -0800 (PST) From: Masataka Ohta Message-Id: <200012131734.CAA16751@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id CAA16751; Thu, 14 Dec 2000 02:34:43 +0900 Subject: Re: mobility support based on e2e model In-Reply-To: <20001213151711.08BFA7E23@starfruit.itojun.org> from Jun-ichiro itojun Hagino at "Dec 14, 2000 00:17:11 am" To: Jun-ichiro itojun Hagino Date: Thu, 14 Dec 2000 02:34:42 +0859 () CC: Fumio Teraoka , ipng@sunroof.eng.sun.com X-Mailer: ELM [version 2.4ME+ PL68 (25)] Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk itojun; > >> - one-layer-up entity assigns it 8 bit space (for 256 machines), > >Huh? > >As I wrote: > >> >No, not at all. ID space needs no hierarchy for routing nor allginment > >> >for CIDR. > >There is no need to make the figure a power of 2. > >> - the company actually has only 200 machines and 56 IDs are wasted. > >If the company request 200 IDs, the one-layer-up entity can delegate > >exactly 200 IDs. > >Or, if the the one-layer-up entity think 200/256 large enough (I think > >this is the case), it can delegate 256 IDs. > > well, think about reality. can you really handle ID assignment > requests, if they do not ask for ID by bulk? The reality is that we have a lot of IDs (social security number in US, for example) assigned individually. As I mentioned, a local goverment would ask country for IDs by bulk. > it was my mistake that > I implied 2^n boundary, it was not my intention. what I was trying to > mean was that there will be lots of wasted space. Where can I see "lots of wasted space" in your example? If you are saying an abstract nonsense that any scheme can be used unwisely to waste a lot of space, you are right. Masataka Ohta -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Dec 13 09:48:33 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta1+Sun/8.11.2.Beta1) id eBDHl6g15417 for ipng-dist; Wed, 13 Dec 2000 09:47:06 -0800 (PST) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.11.2.Beta1+Sun/8.11.2.Beta1) with ESMTP id eBDHl0r15410 for ; Wed, 13 Dec 2000 09:47:01 -0800 (PST) Received: (from jrh@localhost) by stinker.eng.sun.com (8.11.0+Sun/8.11.0) id eBDHjau16094 for ipng@sunroof.eng.sun.com; Wed, 13 Dec 2000 09:45:36 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.2.Beta1+Sun/8.11.2.Beta1) with ESMTP id eBDCnDr15185 for ; Wed, 13 Dec 2000 04:49:13 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id EAA17732 for ; Wed, 13 Dec 2000 04:49:11 -0800 (PST) Received: from short.adgrafix.com (short.adgrafix.com [63.79.128.2]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id FAA01726 for ; Wed, 13 Dec 2000 05:49:10 -0700 (MST) Received: from desktop (aah179.alshamil.net.ae [195.229.199.179]) by short.adgrafix.com (8.9.3/8.9.3) with SMTP id HAA16997; Wed, 13 Dec 2000 07:46:53 -0500 (EST) From: "Faisal Al-Jundi" To: "Masataka Ohta" Cc: Subject: RE: mobility support based on e2e model Date: Wed, 13 Dec 2000 16:43:13 +0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="windows-1256" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 In-Reply-To: <200012131035.TAA15903@necom830.hpcl.titech.ac.jp> Importance: Normal Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi, I'm new here. I just want to ask a question. All of us know that all networking companies running to wireless technology, and as I understand there is lot of electronic machines will have IPv6 address in the future like TV, ....etc. and the most important is the Future GSM, if all mobiles have IPv6 address so we can not think about hierarchy levels at all. Also PALM. because if I travel with my mobile from one country to another, I need a roaming in current technology, but in the future there is no roaming I think there will be like just register this IPv6 address with Telco. company in the country i went and it maybe automatically because of new features in the IPv6 [auto addressing]!!. I just ask because I dont have a complete answer for this. Regards Faisal Al-Jundi -----Original Message----- From: owner-ipng@sunroof.eng.sun.com [mailto:owner-ipng@sunroof.eng.sun.com]On Behalf Of Masataka Ohta Sent: Wednesday, December 13, 2000 2:37 PM To: Jun-ichiro itojun Hagino Cc: Fumio Teraoka; ipng@sunroof.eng.sun.com Subject: Re: mobility support based on e2e model itojun; > >> if we do hierarchical LIN6-ID assignment, allocation efficiency will > >> follow RFC1715 H-ratio. > >No, not at all. ID space needs no hierarchy for routing nor allginment > >for CIDR. > >The space will have a few levels of organizaional hierarchy (say, > >country/local_goverment/site). In each level, assignments can be > >tighntly packed and returned ID may be filled. > > well, if you assign it hierarchical manner, you cannot pack it that > well. imagine: > - a company asks for IDs, OK. > - one-layer-up entity assigns it 8 bit space (for 256 machines), Huh? As I wrote: > >No, not at all. ID space needs no hierarchy for routing nor allginment > >for CIDR. There is no need to make the figure a power of 2. > - the company actually has only 200 machines and 56 IDs are wasted. If the company request 200 IDs, the one-layer-up entity can delegate exactly 200 IDs. Or, if the the one-layer-up entity think 200/256 large enough (I think this is the case), it can delegate 256 IDs. > the situation looks exactly the same as the current IPv4 assignment. No. Read the following sentense, again and again. > >No, not at all. ID space needs no hierarchy for routing nor allginment ^^^^^^^^^^ > >for CIDR. ^^^^^^^^^ Masataka Ohta -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Dec 13 10:05:00 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta1+Sun/8.11.2.Beta1) id eBDI3Aa15519 for ipng-dist; Wed, 13 Dec 2000 10:03:10 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.2.Beta1+Sun/8.11.2.Beta1) with ESMTP id eBDI2wr15505 for ; Wed, 13 Dec 2000 10:02:59 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id KAA07716 for ; Wed, 13 Dec 2000 10:02:58 -0800 (PST) Received: from hiroshi0.nc.u-tokyo.ac.jp (ietf.207.137.73.15.tx.verio.net [207.137.73.15]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id LAA21978 for ; Wed, 13 Dec 2000 11:02:57 -0700 (MST) Received: from ESAKI-T20 [127.0.0.1] by hiroshi0.nc.u-tokyo.ac.jp [127.0.0.1] with SMTP (MDaemon.v2.7.SP4.R) for ; Thu, 14 Dec 2000 03:02:03 +0900 Message-Id: <4.1-J.20001214025605.01bb9808@127.0.0.1> X-Sender: hiroshi@130.69.251.25 Reply-To: hiroshi@wide.ad.jp X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1-J Date: Thu, 14 Dec 2000 03:01:57 +0900 To: "Faisal Al-Jundi" , "Masataka Ohta" From: Hiroshi ESAKI Subject: RE: mobility support based on e2e model Cc: In-Reply-To: References: <200012131035.TAA15903@necom830.hpcl.titech.ac.jp> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-MDaemon-Deliver-To: ipng@sunroof.eng.sun.com X-Return-Path: hiroshi@wide.ad.jp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi, just a clarification, regarding the I-D (draft-teraoka-mobility-lin6-00.txt), though we will try to mention briefly in the presentation on Thu session. LIN6 is not only focusing on the wireless and mobility, rather trying to solve some technological issues (e.g., multihoming) around us. regards, Hiroshi Esaki At 16:43 00/12/13 +0400, Faisal Al-Jundi wrote: > Hi, > > I'm new here. > > I just want to ask a question. > > All of us know that all networking companies running to wireless technology, > and as I understand there is lot of electronic machines will have IPv6 > address in the future like TV, ....etc. and the most important is the Future > GSM, if all mobiles have IPv6 address so we can not think about hierarchy > levels at all. Also PALM. because if I travel with my mobile from one > country to another, I need a roaming in current technology, but in the > future there is no roaming I think there will be like just register this > IPv6 address with Telco. company in the country i went and it maybe > automatically because of new features in the IPv6 [auto addressing]!!. > > I just ask because I dont have a complete answer for this. > > Regards > > Faisal Al-Jundi > > -----Original Message----- > From: owner-ipng@sunroof.eng.sun.com > [mailto:owner-ipng@sunroof.eng.sun.com]On Behalf Of Masataka Ohta > Sent: Wednesday, December 13, 2000 2:37 PM > To: Jun-ichiro itojun Hagino > Cc: Fumio Teraoka; ipng@sunroof.eng.sun.com > Subject: Re: mobility support based on e2e model > > > itojun; > > > >> if we do hierarchical LIN6-ID assignment, allocation efficiency will > > >> follow RFC1715 H-ratio. > > >No, not at all. ID space needs no hierarchy for routing nor allginment > > >for CIDR. > > >The space will have a few levels of organizaional hierarchy (say, > > >country/local_goverment/site). In each level, assignments can be > > >tighntly packed and returned ID may be filled. > > > > well, if you assign it hierarchical manner, you cannot pack it that > > well. imagine: > > - a company asks for IDs, > > OK. > > > - one-layer-up entity assigns it 8 bit space (for 256 machines), > > Huh? > > As I wrote: > > > >No, not at all. ID space needs no hierarchy for routing nor allginment > > >for CIDR. > > There is no need to make the figure a power of 2. > > > - the company actually has only 200 machines and 56 IDs are wasted. > > If the company request 200 IDs, the one-layer-up entity can delegate > exactly 200 IDs. > > Or, if the the one-layer-up entity think 200/256 large enough (I think > this is the case), it can delegate 256 IDs. > > > the situation looks exactly the same as the current IPv4 assignment. > > No. > > Read the following sentense, again and again. > > > >No, not at all. ID space needs no hierarchy for routing nor allginment > ^^^^^^^^^^ > > >for CIDR. > ^^^^^^^^^ > > Masataka Ohta > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- > > > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- ======================================= Hiroshi ESAKI, Ph.D Associate Professor, Information Technology Center, University of Tokyo, 2-11-16 Yayoi, Bunkyo-ku, Tokyo, 113-8658, Japan. Email hiroshi@wide.ad.jp TEL: +81-3-5684-7303 FAX: +81-3-5684-7775 http://www.itc.u-tokyo.ac.jp http://hiroshi1.nc.u-tokyo.ac.jp/hiroshi/index.html -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Dec 14 10:55:43 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta1+Sun/8.11.2.Beta1) id eBEIs4e16113 for ipng-dist; Thu, 14 Dec 2000 10:54:04 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.2.Beta1+Sun/8.11.2.Beta1) with ESMTP id eBEIrtr16106 for ; Thu, 14 Dec 2000 10:53:55 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id KAA23584 for ; Thu, 14 Dec 2000 10:53:54 -0800 (PST) Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA03965 for ; Thu, 14 Dec 2000 11:53:51 -0700 (MST) Received: from localhost ([2001:240:ff:0:260:1dff:fe1f:3773]) by shuttle.wide.toshiba.co.jp (8.9.1+3.1W/8.9.1) with ESMTP id DAA17646 for ; Fri, 15 Dec 2000 03:35:41 +0900 (JST) Date: Fri, 15 Dec 2000 03:53:37 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: ipng@sunroof.eng.sun.com Subject: Re: default router selection based on network topology In-Reply-To: In your message of "Fri, 17 Nov 2000 14:28:31 +0900" References: <12908.974410211@coconut.itojun.org> <4.3.1-J.20001117141757.02e7c6a8@ff.iij4u.or.jp> User-Agent: Wanderlust/2.3.0 (Roam) Emacs/21.0 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.13.7 - "Awazu") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 20000414(IM141) Lines: 57 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> On Fri, 17 Nov 2000 14:28:31 +0900, >>>>> JINMEI Tatuya said: >>> i'm still having fuzzy feeling about ICMPv6 redirects - if we have >>> famous web server in our network, and the web server picked >>> wrong (downstream) router as its default router, i'm not sure if >>> the amount of ICMPv6 redirects will be acceptable for us. >> I don't have any data to say how much it will be in such a case. >> The worst case is clearly something that exchanges exactly one packet >> with every IPv6 address on the planet where you'll see one redirect >> per sent IP packet. A web server typically sends a lot more than >> one IP packet per destination. But as I said I don't have any hard data >> here. > So, how about letting all routers in the segment where our "famous" > web server is located advertise RA, and checking the ratio of outgoing > TCP (or IP6) packets to incoming redirects on the server? (Maybe no one remembered the context...) I've taken some statistics on www.kame.net, which should be one of famous IPv6 web servers, for two weeks. The network topology is as follows: to the 6bone | router1 | |---+-----+-------+--| | | www.kame.net router2 | (leaf segment) I configured both two routers so that redirection always happened when the web server sent packets toward the 6bone. The web server is based on FreeBSD 2.2.8, which keeps a host route for redirection at least one hour. Here are the results: number of incoming redirects: 24,779 number of outgoing IPv6 packets: 1,020,239 number of outgoing TCP/IPv6 packets: 334,724 number of established TCP connections: 3863 --- (rough) average of outgoing TCP packets per connection: 86.6 ratio of incoming redirects to outgoing IPv6 packets: 2.4% (rough) ratio of incoming redirects to outgoing TCP packets: 7.4% I'm not sure whether the ratio is high or low at this moment, though. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Dec 14 14:58:41 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta1+Sun/8.11.2.Beta1) id eBEMuHY16288 for ipng-dist; Thu, 14 Dec 2000 14:56:17 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.2.Beta1+Sun/8.11.2.Beta1) with ESMTP id eBEMu8r16281 for ; Thu, 14 Dec 2000 14:56:08 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id OAA04472 for ; Thu, 14 Dec 2000 14:56:06 -0800 (PST) Received: from zmamail03.zma.compaq.com (zmamail03.zma.compaq.com [161.114.64.103]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA17021 for ; Thu, 14 Dec 2000 14:56:05 -0800 (PST) Received: by zmamail03.zma.compaq.com (Postfix, from userid 12345) id 5410B4EDF; Thu, 14 Dec 2000 17:56:05 -0500 (EST) Received: from ucxaxp.ucx.lkg.dec.com (unknown [16.20.208.53]) by zmamail03.zma.compaq.com (Postfix) with SMTP id 22A974D81 for ; Thu, 14 Dec 2000 17:56:05 -0500 (EST) Received: from unknown.hostname (16.47.50.149) by ucxaxp.ucx.lkg.dec.com (V5.0A-1F, OpenVMS V7.1-1H2 Alpha); Thu, 14 Dec 2000 17:56:03 -0500 (EST) Message-ID: <041f01c06620$b2c6bf10$e44989cf@ucx.lkg.dec.com> From: "M. T. Hollinger" To: Subject: Remaining MUSTs in default-addr-select-02 Date: Thu, 14 Dec 2000 17:53:31 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Rich, thanks for putting so much work into this draft. I generally like it, and think this is an important area to work on. I have some concerns about the details, primarily because my years of working on a "strong host model" network layer have led me to really question that model. It's probably too late, for the protocol stack I work on, but I'd like to make sure it's easy for other implementers to use a weak host model. Also, I want to make sure applications are empowered to select their own addresses with minimal second-guessing at the network layer. > All IPv6 nodes, including both hosts and routers, must implement > default address selection as defined in this specification. It seems funny to have a "must" (different from a "MUST"?) in the abstract, and since half the draft talks about destination address selection (typically not an issue for routers, which may not even include a BIND resolver or host table), I don't see why routers are required to implement it. > The IPv6 > addressing architecture defines scope field values for node-local > (0x1), link-local (0x2), site-local (0x5), ... > ... > IPv4 loopback addresses [11, section 4.2.2.11], which > have the prefix 127/8, are assigned link-local scope. Why not node-local, since you went to the trouble of mentioning it earlier? I see from the revision history that you changed this to link-local in an earlier version of the draft, but I wasn't following the discussion at that time. Maybe a parenthetical expression like "node-local (0x1, not used in this draft)" would be appropriate, if you're really sure you don't want to use that scope here. Still, it might be handy. If we're sending to a link-local destination address, and we're trying to select a source address, then I would think a link-local source address would be more appropriate than a loopback address. Rule 2 (Prefer appropriate scope) would ensure selection of a link-local address, except that you've defined loopback as also being link-local. Rule 3 (Avoid deprecated addresses) won't avoid the loopback, because you've defined loopback addresses as preferred (sec 2.4). Rule 5 (prefer outgoing interface) may save us here, but some implementations may just add the loopback address to another interface, rather than having a separate loopback interface. Rule 6 (prefer matching label) or Rule 8 (longest match) will save us, at least for the IPv6 case (and IPv4 source address selection is out-of-scope anyway), if we get that far. Consider this source address selection problem: Destination: fe80::2 Sources: fe80::1 (deprecated) vs ::1 Result: ::1 (avoid deprecated address) Is it legal to have a deprecated link-local address? If so, this configuration is valid, and the result is non-intuitive. Rule 2 could have saved us, but again, sec 2.4 says: > The loopback address should be treated as having link-local scope > and "preferred" configuration status. As an aside, if loopback addresses were defined as having node-local scope, then perhaps the first (::1/128) rule of your default policy table would become redundant. Alternatively, perhaps the cleanest solution would be to add something like this to sec 3: For non-loopback destination addresses, the set of candidate source addresses MUST NOT include any loopback addresses. > It is RECOMMENDED that the candidate source addresses be the set of > unicast addresses assigned to the interface that will be used to > send to the destination. (The "outgoing" interface.) Whoa! That's pretty restrictive. Keep this in mind, as many of my other concerns stem from the possibility that some implementors may follow this RECOMMENDATION. > On routers, the > candidate set MAY include unicast addresses assigned to any > interface that could forward the destination address to the outgoing > interface. This wording presumes a lot about the implementation, and seems to imply that only routers MAY deviate from your RECOMMENDATION. As you know, "weak host model" protocol stacks don't consider it "forwarding" to send a locally-originating packet out an interface other than the one its source address is associated with. (Some stacks even let you have a local address not associated with any interface.) > For multicast ... destination addresses, the set of > candidate source addresses MUST only include addresses assigned to > interfaces belonging to the same link as the outgoing interface. Hmm. What if I'm a multicast router? I'm specifically concerned about the case of a node which is sending a multicast stream, where the node's owners have gone to great lengths to achieve reliability. They may have some application-specific reason why all the packets in this multicast stream need to have the same source address (to be granted preferred routing treatment, perhaps, or to traverse firewalls). That means the application will bind to a particular global address -- say, one associated with interface A. If the ISP for interface A fails, we now need to send multicast packets with A's source address out interface B, switching to our backup ISP, with whom we have presumably made advance arrangements to carry the traffic. For that matter, if the first ISP happens to be down at the moment our application comes up, binds to A's global address (in anticipation of that ISP coming back soon), and sends its very first packet, it should in my opinion still be allowed. On UDP traffic flows, I'm not sure whether the complete source address selection algorithm should be repeated each time a packet is transmitted, or whether the previously-used address should be cached. If the application has explicitly bound to a source address and successfully sent some traffic in the past, how frequently should the network layer re-validate that specified address? Every time routing information changes, perhaps? If we check it on every packet, that's a big performance hit, but if we don't, we can't fully enforce all these "candidate set" rules -- which I mostly don't think should be enforced anyway, if the application has explicitly chosen an address. To keep hammering on the multicast cases, what if I find myself sending to a global multicast destination address via an interface with only a link-local address? Assuming the application hasn't bound to a particular address, is it better to use the global address from some other interface as the source, or to go ahead and send the packet with the link-local source address? If I use an address from another interface, my local routers may drop it rather than forwarding it off the link. Of course, they'll do that anyway if I select the link-local source address. Now, what if the application has explicitly bound to a certain global address and now sends multicast traffic that will be routed via some other interface? This is an unusual thing to do (since the router will probably not forward such multicast traffic), but maybe the folks running my application configured it that way because they had made special arrangements with the router operator to act as a backup in case of another router's failure. This is similar to my previous example, except that in this case, I'm just a multi-homed host, not actually a router. Here again, we need the packets to go out with a consistent global source address, regardless of the routing decisions. > If an application or upper-layer specifies a source address that is > not in the candidate set for the destination, then the network layer > MUST treat this is an error. Again, this is what gives me heartburn, particularly in light of that earlier RECOMMENDATION that the candidate set include only those source addresses associated with the outgoing interface. If the application has gone to the trouble of binding to a particular local address, then I think the network layer should go ahead and use that source address, even if the routing table happens to dictate that the packet gets transmitted out a different interface. This is particularly true if the routing table changes during a particular information flow (UDP application dialog or TCP connection). At that point, we can't change the source address, even though we are suddenly sending the packets out a different interface which may well have available addresses of its own. In general, perhaps the set of source addresses which can be specified explicitly by an application should be larger than the set of addresses which might be automatically selected by the network layer. Don't try so hard to protect the network from misbehaving applications. In the summary the changes for the -02 draft, it says: > Clarified that an implementation should prevent an application or > upper-layer from choosing a source address that is not in the > candidate set and not prevent an application or upper-layer from > choosing a source address that is in the candidate set. I like the summary ("should") more than what the draft actually says ("the network layer MUST treat this as an error"), particularly given the narrow way the candidate set has been defined. Reflecting upon the title of this draft, I can't see how a statement that the network layer MUST prevent applications from choosing particular addresses fits the topic of DEFAULT address selection. Even SHOULD is a stretch; my preference would be somewhere between MAY and SHOULD NOT. > Rule 2: Prefer appropriate scope. > If Scope(SA) < Scope(SB). If Scope(SA) < Scope(D), then choose SB > and otherwise choose SA. I found this rule quite hard to understand. I had to keep going through and plugging in specific examples. To paraphrase: if the scope of SA is narrower than the scope of SB, and also too narrow for the given destination, then choose SB. Now that I understand the phrasing, I agree. > Rule 5: Prefer outgoing interface. > If SA is assigned to the interface that will be used to send to D > and SB is assigned to a different interface, then prefer SA. Yes! I agree with this rule. This is a good way to prefer addresses associated with the outgoing interface. Of course, it only comes into play when an implementation deviates from your RECOMMENDATION that only addresses assigned to the outgoing interface be considered. It's rather telling that when you had to rank this rule, you put it down at number 5, while the RECOMMENDATION would effectively make it number 0. > In this approach, the implementation may not have > knowledge of the outgoing interface for each destination, so it MAY > use a looser definition of the candidate set during destination > address ordering. OK, but let's make sure the network layer doesn't enforce its own definition of the candidate set at transmit time. If getaddrinfo() comes up with a destination address that the network layer can't actually reach (because the selected outgoing interface doesn't have a global address, for example), then this inconsistency might prevent communication -- yet another reason why the network layer should not, in my opinion, be enforcing the interface-matching rule on outgoing source addresses. > ...no more than one second out > of date. For example, an implementation might make a system call to > check if any routing table entries or source address assignments > that might affect these algorithms have changed. Well, that would probably take several system calls, so doing it every 1 second sounds too frequent, to me. I'd think 5 or 10 seconds would be appropriate. Bearing in mind that the output from this selection process should be a list of address pairs to try, I can't help observing that the results are sometimes suboptimal. As written, this design will lead well-behaved applications to try a list of *destination* addresses, in some reasonable order. However, for each destination address, we'll try only a single source address. Suppose we want to reach a distant host with 7 different global IPv6 addresses and 1 IPv4 address. Suppose further that we ourselves have 2 global IPv6 addresses and an IPv4 address. This algorithm will lead our application to try all 7 of the remote IPv6 addresses before ever trying the IPv4 address. The network layer may well use the same IPv6 source address in all 7 attempts, if the bits happen to fall in such a way that it represents the longest match. If there is some routing problem with that address, then we won't get through until the 8th try, at which point we'll finally fall back to IPv4, never having tried our other IPv6 global source address at all. It would seem to me like a better bet to cycle through the local addresses, and perhaps incorporate other feedback between routing, destination address selection, and source address selection. When we talked about this in Pittsburgh, I heard substantial support for the notion of changing the API so that a typical application would no longer have to handle IP addresses at all. Instead of calling getaddrinfo() and then connect(), a client of the future might call connectbyname() and let the protocol stack take care of all the details. Such a routine could sequence the retries intelligently, and of course it could also handle all parsing of the specified string which might be a hostname, an IPv4 address, or an IPv6 address (with optional scope identifier). Is anyone actually working on such an approach? This draft is limited by its assumption of an unchanged sockets API -- which is great for near-term deployment, but I'd also like to see a longer-term effort to improve the API. Anyone for connectbyname() ? - Mark -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Dec 14 17:19:46 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta1+Sun/8.11.2.Beta1) id eBF1Hwx16431 for ipng-dist; Thu, 14 Dec 2000 17:17:58 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.2.Beta1+Sun/8.11.2.Beta1) with ESMTP id eBF1Hnr16424 for ; Thu, 14 Dec 2000 17:17:49 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id RAA07729 for ; Thu, 14 Dec 2000 17:17:49 -0800 (PST) Received: from melimelo.enst-bretagne.fr (melimelo.enst-bretagne.fr [192.108.115.36]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA01631 for ; Thu, 14 Dec 2000 17:17:48 -0800 (PST) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by melimelo.enst-bretagne.fr (8.10.1/8.10.1) with ESMTP id eBF1Hl434810 for ; Fri, 15 Dec 2000 02:17:47 +0100 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id CAA22762 for ; Fri, 15 Dec 2000 02:17:47 +0100 (MET) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.9.3/8.9.3) with ESMTP id CAA87412 for ; Fri, 15 Dec 2000 02:19:13 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200012150119.CAA87412@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: ipng@sunroof.eng.sun.com Subject: destination option update Date: Fri, 15 Dec 2000 02:19:12 +0100 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk The working group has just decided the flawn is not in the specs but in the advanced API then either: - or we found a good way to encode positions (I have no idea of how) - or we arbitrary restrict the advanced API expressiveness to some common cases (as it is done today but we already need to add a new position for destination option headers). As I don't know if the first goal is possible to archieve I suggest to go to the second if no progress is done before a reasonnable delay. Regards Francis.Dupont@enst-bretagne.fr PS: I believe my proposal will be still useful for the names (not of headers but for positions). Of course other points are still valid (and according to Steve Deering, it is legitimate for a new application to use an existing header in a new position, so mobile IPv6 doesn't violate RFC 2460). PPS: current advanced API uses IPV6_[RECV]DSTOPTS/IPV6_[RECV]RTHDRDSTOPTS. According to Steve this is wrong but he has not yet proposed something else. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Dec 14 18:07:55 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta1+Sun/8.11.2.Beta1) id eBF26PZ16574 for ipng-dist; Thu, 14 Dec 2000 18:06:25 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.2.Beta1+Sun/8.11.2.Beta1) with ESMTP id eBF26Cr16567 for ; Thu, 14 Dec 2000 18:06:13 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id SAA17107 for ; Thu, 14 Dec 2000 18:06:11 -0800 (PST) Received: from shaku.v6.linux.or.jp (shaku.sfc.wide.ad.jp [203.178.143.49]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA18126 for ; Thu, 14 Dec 2000 18:06:10 -0800 (PST) Received: from YUMIKO.sfc.wide.ad.jp ([2001:240:ff:0:260:1dff:fe1e:dbb9]) by shaku.v6.linux.or.jp (8.11.0/3.7W) with ESMTP id eBF24ha20042 for ; Fri, 15 Dec 2000 11:04:50 +0900 Date: Fri, 15 Dec 2000 11:05:07 +0900 Message-ID: From: Yuji Sekiya To: ipng@sunroof.eng.sun.com Subject: Presentation materials of USAGI Project in IETF49 IPng User-Agent: Wanderlust/1.1.1 (Purple Rain) REMI/1.14.1 (=?ISO-8859-4?Q?Mus?= =?ISO-8859-4?Q?higawa=F2sugi?=) Chao/1.14.0 (Momoyama) APEL/10.2 Emacs/20.7 (i386-*-nt5.0.2195) MULE/4.1 (AOI) Meadow/IPv6-1.13 Beta1++ (TANAHASHI:61) Organization: Keio University MIME-Version: 1.0 (generated by REMI 1.14.1 - =?ISO-8859-4?Q?=22Mushigawa=F2?= =?ISO-8859-4?Q?sugi=22?=) Content-Type: text/plain; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Because I have no time to perform all presentation in IPng slot, I have put the sildes on the following URL. Overview of USAGI Project Linux IPv6 Development. http://www.linux-ipv6.org/IETF49/ Thanks. -- Yuji Sekiya @ USAGI Project -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Dec 14 19:02:39 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta1+Sun/8.11.2.Beta1) id eBF2xsL16641 for ipng-dist; Thu, 14 Dec 2000 18:59:54 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.2.Beta1+Sun/8.11.2.Beta1) with ESMTP id eBF2xjr16634 for ; Thu, 14 Dec 2000 18:59:45 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id SAA04299 for ; Thu, 14 Dec 2000 18:59:45 -0800 (PST) Received: from shio.csl.sony.co.jp (shio.csl.sony.co.jp [133.138.1.157]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA00306 for ; Thu, 14 Dec 2000 18:59:44 -0800 (PST) Received: from SONY-VUFTD77IW4.csl.sony.co.jp (shio.csl.sony.co.jp [43.27.100.157]) by shio.csl.sony.co.jp (8.9.3/3.7Ws3/03/09/00) with ESMTP id LAA04422 for ; Fri, 15 Dec 2000 11:58:58 +0900 (JST) Message-Id: <4.3.1-J.20001215115647.03a90b08@127.0.0.1> X-Sender: shio@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 4.3.1-J Date: Fri, 15 Dec 2000 11:58:46 +0900 To: ipng@sunroof.eng.sun.com From: Atsushi Shionozaki Subject: LIN6 presentation at IETF49 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk For those who left on time and were not at the last presentation, the ppt slides are available at: http://www.csl.sony.co.jp/LIN6/ regards, shio -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Dec 15 08:11:01 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta1+Sun/8.11.2.Beta1) id eBFG9RS16959 for ipng-dist; Fri, 15 Dec 2000 08:09:27 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.2.Beta1+Sun/8.11.2.Beta1) with ESMTP id eBFG9Hr16952 for ; Fri, 15 Dec 2000 08:09:18 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id IAA08296 for ; Fri, 15 Dec 2000 08:09:17 -0800 (PST) Received: from bob.dera.gov.uk (bob.dera.gov.uk [192.5.29.90]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA03612 for ; Fri, 15 Dec 2000 08:09:16 -0800 (PST) Received: by bob.dera.gov.uk; (8.8.8/1.3/10May95) id QAA15533; Fri, 15 Dec 2000 16:09:45 GMT Received: (qmail 9460 invoked from network); 15 Dec 2000 17:04:26 -0000 Received: from gauntlet.mail.dera.gov.uk (172.16.9.10) by baton.dera.gov.uk with SMTP; 15 Dec 2000 17:04:26 -0000 Received: by gauntlet.mail.dera.gov.uk; id QAA00500; Fri, 15 Dec 2000 16:59:02 GMT Received: from unknown(10.71.64.31) by gauntlet.mail.dera.gov.uk via smap (3.2) id xma000448; Fri, 15 Dec 00 16:58:36 GMT Received: from frn-gold-1.dera.gov.uk (unverified) by mailguard.dera.gov.uk (Content Technologies SMTPRS 4.1.5) with ESMTP id for ; Fri, 15 Dec 2000 16:10:30 +0000 Received: by FRN-GOLD-1 with Internet Mail Service (5.0.1460.8) id ; Fri, 15 Dec 2000 16:08:43 -0000 Message-ID: From: Southcote-Want Edward To: "'ipng@sunroof.eng.sun.com'" Subject: Merry Christmas... Date: Fri, 15 Dec 2000 16:08:41 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1460.8) Content-Type: text/plain Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk ...and a Happy and Prosperous New Year to you all. -- The Information contained in this E-Mail and any subsequent correspondence is private and is intended solely for the intended recipient(s). For those other than the recipient any disclosure, copying, distribution, or any action taken or omitted to be taken in reliance on such information is prohibited and may be unlawful. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Dec 15 14:10:12 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta1+Sun/8.11.2.Beta1) id eBFM8Vb17320 for ipng-dist; Fri, 15 Dec 2000 14:08:31 -0800 (PST) Received: from jurassic.eng.sun.com (jurassic [129.146.85.31] (may be forged)) by sunroof.eng.sun.com (8.11.2.Beta1+Sun/8.11.2.Beta1) with ESMTP id eBFM8Kr17313 for ; Fri, 15 Dec 2000 14:08:21 -0800 (PST) Received: from lillen (lillen.Eng.Sun.COM [129.146.86.161]) by jurassic.eng.sun.com (8.11.2.Beta1+Sun/8.11.2.Beta1) with SMTP id eBFM8Jm690069; Fri, 15 Dec 2000 14:08:19 -0800 (PST) Date: Fri, 15 Dec 2000 14:08:03 -0800 (PST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: destination option update To: Francis Dupont Cc: ipng@sunroof.eng.sun.com Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > The working group has just decided the flawn is not in the specs but > in the advanced API then either: > - or we found a good way to encode positions (I have no idea of how) > - or we arbitrary restrict the advanced API expressiveness to > some common cases (as it is done today but we already need to > add a new position for destination option headers). > As I don't know if the first goal is possible to archieve I suggest > to go to the second if no progress is done before a reasonnable delay. Adding a 3rd set of options to receive a 3rd placement of destination options in the advanced API probably isn't too hard. However, I'm a bit concerned on how to define the semantics when there are 1 or 2 destopt headers in the packet. The current semantics is that IPV6_RTHDRDSTOPTS contains the destination options before a routing header, which only make sense when there is a routing header and a destopts header that preceeds the routing header. When there is no routing header IPV6_DSTOPTS contains the destination options header, and when there is a routing header IPV6_DSTOPTS contains the destination options header after the routing header. So basically this separates out the destination options header into those that appear before and after a routing header. I don't think rfc2292bis says anything about the case when there are multiple destination options headers in each of these two logical locations. The above is quite complex to describe to the user of the API. Adding another IPV6_DSTOPTSAFTERIPSEC(?) concept that is conditional would make it even harder to describe. So ... perhaps it would be easier if we instead passed these routing headers to the application in the order they where received with all of them being tagged with the same ancillary data type (IPV6_DSTOPTS)? This would still have some problems since certain extension headers (fragmentation, AH, ESP) aren't passed up to the application. Thus if the packet has IP header dstopt frag hdr dstopt ESP dstopt or if it has IP header dstopt frag hdr dstopt dstopt ESP the application would in both cases see 3 IPV6_DSTOPT ancillary data items with no intervening ancillary data items, so the application can't tell the important difference. The upshot of this is that either way we go the receive side interface will be quite complex, unless we somehow can represent the location of the extension headers (especially AH and ESP) that have been removed as part of processing the packet. Is that the path we should take or are there better suggestions? Erik -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Dec 15 14:44:14 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta1+Sun/8.11.2.Beta1) id eBFMgb717379 for ipng-dist; Fri, 15 Dec 2000 14:42:37 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.2.Beta1+Sun/8.11.2.Beta1) with ESMTP id eBFMgQr17372 for ; Fri, 15 Dec 2000 14:42:26 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id OAA19962; Fri, 15 Dec 2000 14:42:25 -0800 (PST) Received: from roll.mentat.com ([192.88.122.129]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA05367; Fri, 15 Dec 2000 14:42:24 -0800 (PST) Received: from leo.mentat.com (leo [192.88.122.132]) by roll.mentat.com (8.9.1b+Sun/8.9.1) with ESMTP id OAA22954; Fri, 15 Dec 2000 14:42:23 -0800 (PST) Received: from feller.mentat.com (feller [192.88.122.144]) by leo.mentat.com (8.9.1b+Sun/8.9.1) with ESMTP id OAA18205; Fri, 15 Dec 2000 14:42:23 -0800 (PST) Received: (from tim@localhost) by feller.mentat.com (8.9.3+Sun/8.9.3) id OAA02954; Fri, 15 Dec 2000 14:45:29 -0800 (PST) Date: Fri, 15 Dec 2000 14:45:29 -0800 (PST) From: Tim Hartrick Message-Id: <200012152245.OAA02954@feller.mentat.com> To: Francis.Dupont@enst-bretagne.fr, Erik.Nordmark@eng.sun.com Subject: Re: destination option update Cc: ipng@sunroof.eng.sun.com X-Sun-Charset: US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Erik, > > The above is quite complex to describe to the user of the API. > Adding another IPV6_DSTOPTSAFTERIPSEC(?) concept that is conditional > would make it even harder to describe. > I am generally against this proliferation of new option types and extension headers. Processing and packing all this ancillary data is hairy enough as it is. > So ... > perhaps it would be easier if we instead passed these routing headers > to the application in the order they where received with all of them > being tagged with the same ancillary data type (IPV6_DSTOPTS)? > I believed before and believe now that this is the better way to go. I never really liked the IPV6_RTHDRDSTOPTS option. > This would still have some problems since certain extension headers > (fragmentation, AH, ESP) aren't passed up to the application. > Thus if the packet has > IP header > dstopt > frag hdr > dstopt > ESP > dstopt > > or if it has > IP header > dstopt > frag hdr > dstopt > dstopt > ESP > > the application would in both cases see 3 IPV6_DSTOPT ancillary data items > with no intervening ancillary data items, so the application can't tell > the important difference. > I don't know that the receiving application needs to know any of this. It merely needs to know that the appropriate security was applied by the system. That would seem to be understood given that the application is receiving the datagram. If appropriate security wasn't applied the datagram should have been discarded before it reached the application. I think that the problem is on the send side for things like the home address option and the encapsulation limit option. In those cases the application wants to send: IP header dstopt upper layer but the application wants the dstopt to be in the *non-fragmentable* part of the datagram. Given the current API and partially because of the fragmentation algorithm in the IPv6 base specification that isn't possible. In these cases the "application" may be a kernel tunneling driver or something. If we can enhance the API to allow the application to specify where it wants the non-fragmentable part of the datagram to end that would fix the problem(s) as I currently understand them. > The upshot of this is that either way we go the receive side interface > will be quite complex, unless we somehow can represent the location of > the extension headers (especially AH and ESP) that have been removed as > part of processing the packet. > As I said, I don't believe that this is necessary. Of course I may be completely misunderstanding the nature of the problems. tim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sat Dec 16 06:22:33 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta1+Sun/8.11.2.Beta1) id eBGELBe17714 for ipng-dist; Sat, 16 Dec 2000 06:21:11 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.2.Beta1+Sun/8.11.2.Beta1) with ESMTP id eBGEL1r17707 for ; Sat, 16 Dec 2000 06:21:02 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id GAA03912 for ; Sat, 16 Dec 2000 06:21:02 -0800 (PST) Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id GAA03783 for ; Sat, 16 Dec 2000 06:21:01 -0800 (PST) Received: from localhost (shuttle.wide.toshiba.co.jp [202.249.10.124]) by shuttle.wide.toshiba.co.jp (8.9.1+3.1W/8.9.1) with ESMTP id XAA29439 for ; Sat, 16 Dec 2000 23:02:58 +0900 (JST) Date: Sat, 16 Dec 2000 23:20:50 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: ipng@sunroof.eng.sun.com Subject: Re: IPV6_USEMTU socket option In-Reply-To: In your message of "Tue, 14 Nov 2000 10:18:30 +0900" References: User-Agent: Wanderlust/2.3.0 (Roam) Emacs/21.0 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.13.7 - "Awazu") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 20000414(IM141) Lines: 77 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> On Tue, 14 Nov 2000 10:18:30 +0900, >>>>> JINMEI Tatuya said: > I'm now considering UDP applications that are sensitive to path MTU > (toward the destinations). I recalled a discussion about a new socket > option "IPV6_USEMTU", which allowed an application to specify an > appropriate path MTU for packets sent from the application. I checked > the archive of this list in April 2000, and, to my suprise, the > discussion suddenly disappeared without any consensus. > I think it is a good idea, and even essential for such UDP > applications. What was wrong with the option? Or can we raise the > option again as a clarification for rfc2292bis? My original motiviation to support this (ancillary data item and/or socket option) was as follows: at one time, NetBSD and OpenBSD introduced a strict rule to validate incoming ICMPv6 too big error messages; a too big error messages is accepted (and the path MTU is adjusted accordingly) only when - there exists a connected socket corresponding to the source and destination addresses of the inner IPv6 header contained in the error message, or - there exists an IPsec security association corresponding to the source and destination addresses of the inner IPv6 header contained in the error message. The objective of the rule is to avoid a DoS attack that tries to make the target's memory exhausted by sending a massive number of forged TOO BIG error messages for different paths. The rule is okay for TCP connections. However, since some UDP applications use unconnected sockets, such a strict rule is even harmful for those applications; path MTU discovery does not work, and when the applications send a large packet, the packet never reaches the destination. In order to overcome the situation as well as respecting the security concerns, the only solution is to let applications perform path MTU discovery by themselves. Thus, I thought IPV6_USEMTU was essential. However, as I mentioned in the ipngwg session yesterday, the latest versions of NetBSD and OpenBSD (basically) always perform path MTU discovery, regardless of the existence of corresponding connected sockets or security associations. In order to avoid the DoS attack, the latest versions introduced an upper limit of number of path MTU cache entries (host route entries, actually), instead of the previous strict validation. So, for now, there's no strong reason to support the IPV6_USEMTU ancillary data item and socket option, at least for me. Additionally, if we can assume that every kernel accepts incoming TOO_BIG errors (and perform path MTU discovery) regardless of the content of the inner IPv6 headers, IPV6_USEMTU would totally be unnecessary. However, I still think the ancillary data/socket option is not a bad idea, because - it is a natural generalization of IPV6_USE_MIN_MTU. - we do not have to worry about the kernel's behavior by introducing IPV6_USEMTU. - if we added a knob to disable kernel-level path MTU discovery, IPV6_USEMTU would be necessary. - IPV6_USEMTU does not require the super user privilege, because it only affects transmission from the corresponding socket. - IPV6_USEMTU does not need require administrator privilege. So, I'd like to hear others' opinions. Is it a good idea to introduce IPV6_USEMTU (instead of IPV6_USE_MIN_MTU)? Thanks, JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sat Dec 16 07:02:54 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta1+Sun/8.11.2.Beta1) id eBGF1GZ17758 for ipng-dist; Sat, 16 Dec 2000 07:01:16 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.2.Beta1+Sun/8.11.2.Beta1) with ESMTP id eBGF15r17751 for ; Sat, 16 Dec 2000 07:01:06 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id HAA10089 for ; Sat, 16 Dec 2000 07:01:06 -0800 (PST) Received: from starfruit.itojun.org (ny-ppp017.iij-us.net [216.98.99.17]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA03184 for ; Sat, 16 Dec 2000 07:01:01 -0800 (PST) Received: from itojun.org (localhost [127.0.0.1]) by starfruit.itojun.org (Postfix) with ESMTP id 256217E23 for ; Sun, 17 Dec 2000 00:00:10 +0900 (JST) To: ipng@sunroof.eng.sun.com In-reply-to: jinmei's message of Sat, 16 Dec 2000 23:20:50 +0900. X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: IPV6_USEMTU socket option From: Jun-ichiro itojun Hagino Date: Sun, 17 Dec 2000 00:00:10 +0900 Message-Id: <20001216150010.256217E23@starfruit.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >So, I'd like to hear others' opinions. Is it a good idea to introduce >IPV6_USEMTU (instead of IPV6_USE_MIN_MTU)? I tried to come up with three scenarios, with different availability of standards. hope it is correct. discussion points would be: - can we assume that the kernel will always fragment outgoing datagrams? i believe there's no clear wording in spec so far. i do remember there was some discussion in the past, about if path MTU discovery works for UDP or not. - IPV6_USE_MTU changes situation very little, while it require certain amount of user code to take advantage of it. is it really worthwhile? - do we need to inform of new path MTU value, with IPV6_RECVPATHMTU? (depends on the 2nd bullet) itojun in the world with IPV6_USE_MIN_MTU only: - to avoid path MTU discovery, user application will use MTU of 1280, by IPV6_USE_MIN_MTU. - otherwise, kernel will automatically fragment the packet (it is assumed). - for L4 without retransmit (UDP), user application needs to resend the packet. however, there's no notification even when we need a retransmission. in the world with IPV6_USE_MIN_MTU + IPV6_RECVPATHMTU: - to avoid path MTU discovery, user application will use MTU of 1280, by IPV6_USE_MIN_MTU. - otherwise, kernel will automatically fragment the packet (it is assumed). - for L4 without retransmit (UDP), user application needs to resend the packet. with IPV6_RECVPATHMTU, user application can know when it needs to resend. - do we need to include current path MTU information to IPV6_RECVPATHMTU? it depends on application. (1) can use the information, (2) cannot. (1) if the application can use arbitrary packet size, it can adapt to the current path MTU, and try to use path MTU > 1280 effectively. (2) if the applicaiton cannot use arbitrary packet size (like NFS/DNS), it will need to rely upon kernel fragmentation, or need to fragment to 1280. in the world with IPV6_USE_MIN_MTU + IPV6_RECVPATHMTU + IPV6_USE_MTU: - to avoid path MTU discovery, user application will use MTU of 1280, by IPV6_USE_MIN_MTU. - otherwise, kernel will automatically fragment the packet. even if the kernel does not fragment it, we can fragment it by IPV6_USE_MTU. - for L4 without retransmit (UDP), user application needs to resend the packet. with IPV6_RECVPATHMTU, user application can know when it needs to resend. - do we need to include current path MTU information to IPV6_RECVPATHMTU? it depends on application. (1) and (2c) can take advantage of it, others cannot. (1) if the application can use arbitrary packet size, it can adapt to the current path MTU, and try to use path MTU > 1280 effectively. (2) if the applicaiton cannot use arbitrary packet size (like NFS/DNS), it has three options: (2a) rely upon kernel fragmentation, (2b) fragment to 1280, or (2c) specify fragmentation size with IPV6_USE_MTU. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sun Dec 17 21:59:52 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta1+Sun/8.11.2.Beta1) id eBI5wRf18803 for ipng-dist; Sun, 17 Dec 2000 21:58:27 -0800 (PST) Received: from jurassic.eng.sun.com (jurassic [129.146.85.31] (may be forged)) by sunroof.eng.sun.com (8.11.2.Beta1+Sun/8.11.2.Beta1) with ESMTP id eBI5wGr18796 for ; Sun, 17 Dec 2000 21:58:16 -0800 (PST) Received: from blixten-dsl (awe174-18.AWE.Sun.COM [192.29.174.18]) by jurassic.eng.sun.com (8.11.2.Beta1+Sun/8.11.2.Beta1) with SMTP id eBI5vxm885854; Sun, 17 Dec 2000 21:58:00 -0800 (PST) Date: Sun, 17 Dec 2000 21:56:22 -0800 (PST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: destination option update To: Tim Hartrick Cc: Francis.Dupont@enst-bretagne.fr, Erik.Nordmark@eng.sun.com, ipng@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <200012152245.OAA02954@feller.mentat.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > I don't know that the receiving application needs to know any of this. It > merely needs to know that the appropriate security was applied by the system. > That would seem to be understood given that the application is receiving the > datagram. If appropriate security wasn't applied the datagram should have > been discarded before it reached the application. But the application might very well want to know what destination options were protected by ESP. The security checks will presumably only tell the application that, in the case of transport mode, that the tranport header and data was protected. Thus the application can't tell if the destination options where covered by ESP or not using the APIs. > I think that the problem is on the send side for things like the home address > option and the encapsulation limit option. In those cases the application > wants to send: > > IP header > dstopt > upper layer > > but the application wants the dstopt to be in the *non-fragmentable* part > of the datagram. Given the current API and partially because of the > fragmentation algorithm in the IPv6 base specification that isn't possible. > In these cases the "application" may be a kernel tunneling driver or > something. > > If we can enhance the API to allow the application to specify where it > wants the non-fragmentable part of the datagram to end that would fix the > problem(s) as I currently understand them. Any suggestions on how to specify this on the send side? Erik -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Dec 18 09:39:28 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta1+Sun/8.11.2.Beta1) id eBIHbpc19287 for ipng-dist; Mon, 18 Dec 2000 09:37:51 -0800 (PST) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.11.2.Beta1+Sun/8.11.2.Beta1) with ESMTP id eBIHbkr19280 for ; Mon, 18 Dec 2000 09:37:46 -0800 (PST) Received: (from jrh@localhost) by stinker.eng.sun.com (8.11.0+Sun/8.11.0) id eBIHaHi18334 for ipng@sunroof.eng.sun.com; Mon, 18 Dec 2000 09:36:17 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.2.Beta1+Sun/8.11.2.Beta1) with ESMTP id eBGHUVr17847 for ; Sat, 16 Dec 2000 09:30:31 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id JAA06352 for ; Sat, 16 Dec 2000 09:30:31 -0800 (PST) Received: from dr-evil.shagadelic.org ([208.176.2.162]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA13283 for ; Sat, 16 Dec 2000 09:30:31 -0800 (PST) Received: by dr-evil.shagadelic.org (Postfix, from userid 7518) id CB4ABD203; Sat, 16 Dec 2000 09:30:30 -0800 (PST) Date: Sat, 16 Dec 2000 09:30:30 -0800 From: Jason R Thorpe To: "JINMEI Tatuya / ?$B?@L@C#:H?(B" Cc: ipng@sunroof.eng.sun.com Subject: Re: IPV6_USEMTU socket option Message-ID: <20001216093030.I3862@dr-evil.shagadelic.org> Reply-To: thorpej@zembu.com Mail-Followup-To: Jason R Thorpe , "JINMEI Tatuya / ?$B?@L@C#:H?(B" , ipng@sunroof.eng.sun.com References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from jinmei@isl.rdc.toshiba.co.jp on Sat, Dec 16, 2000 at 11:20:50PM +0900 Organization: Zembu Labs, Inc. Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Sat, Dec 16, 2000 at 11:20:50PM +0900, JINMEI Tatuya / ?$B?@L@C#:H?(B wrote: > However, I still think the ancillary data/socket option is not a bad > idea, because > > - it is a natural generalization of IPV6_USE_MIN_MTU. > - we do not have to worry about the kernel's behavior by introducing > IPV6_USEMTU. > - if we added a knob to disable kernel-level path MTU discovery, > IPV6_USEMTU would be necessary. > - IPV6_USEMTU does not require the super user privilege, because it > only affects transmission from the corresponding socket. > - IPV6_USEMTU does not need require administrator privilege. > > So, I'd like to hear others' opinions. Is it a good idea to introduce > IPV6_USEMTU (instead of IPV6_USE_MIN_MTU)? Note that for IPv4, NetBSD has a way to fetch path MTU information for raw IP sockets. If an application gets an EMSGSIZE, it can do a getsockopt() on the IP_ERRORMTU option to fetch the MTU that it should have used. -- -- Jason R. Thorpe -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Dec 18 10:01:18 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta1+Sun/8.11.2.Beta1) id eBIHxbk19340 for ipng-dist; Mon, 18 Dec 2000 09:59:37 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.2.Beta1+Sun/8.11.2.Beta1) with ESMTP id eBIHxSr19333 for ; Mon, 18 Dec 2000 09:59:28 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id JAA25457; Mon, 18 Dec 2000 09:59:26 -0800 (PST) Received: from melimelo.enst-bretagne.fr (melimelo.enst-bretagne.fr [192.108.115.36]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA24476; Mon, 18 Dec 2000 09:59:21 -0800 (PST) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by melimelo.enst-bretagne.fr (8.10.1/8.10.1) with ESMTP id eBIHxJ434165; Mon, 18 Dec 2000 18:59:20 +0100 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id SAA25316; Mon, 18 Dec 2000 18:59:19 +0100 (MET) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.9.3/8.9.3) with ESMTP id TAA11535; Mon, 18 Dec 2000 19:01:05 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200012181801.TAA11535@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Erik Nordmark cc: ipng@sunroof.eng.sun.com Subject: Re: destination option update In-reply-to: Your message of Fri, 15 Dec 2000 14:08:03 PST. Date: Mon, 18 Dec 2000 19:01:05 +0100 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: Adding a 3rd set of options to receive a 3rd placement of destination options in the advanced API probably isn't too hard. => I agree but I can intepret Steve's comment as this is not the good solution. But I don't know a good way to denote the position for individual header. I don't think rfc2292bis says anything about the case when there are multiple destination options headers in each of these two logical locations. => merge them??? The above is quite complex to describe to the user of the API. Adding another IPV6_DSTOPTSAFTERIPSEC(?) concept that is conditional would make it even harder to describe. => intermediate and final should give better names... So ... perhaps it would be easier if we instead passed these routing headers to the application in the order they where received with all of them being tagged with the same ancillary data type (IPV6_DSTOPTS)? => this is the solution I use in my current code: a big buffer with the whole option array but: - this is less flexible than individual header management (for instance the good way to insert a header is to pickup the current array before). - this doesn't work well with "transparent" headers like fragmentation or IPsecs. This would still have some problems since certain extension headers (fragmentation, AH, ESP) aren't passed up to the application. => exactly my second concern. Is that the path we should take or are there better suggestions? => I have followed this path then I can say we should look for a better idea... Thanks Francis.Dupont@enst-bretagne.fr PS: the issue is for the API itself, in the kernel you can add zero length place holders in the header chain (you should do it according to RFC 2401 for incomming IPsec headers). Perhaps the good solution is to manage a stack of headers directly (pop/push/gettop) with transparent headers too (ie. to push a fragmentation header will only indicate the relative position of adjacent headers)? -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Dec 18 10:09:55 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta1+Sun/8.11.2.Beta1) id eBII8gv19399 for ipng-dist; Mon, 18 Dec 2000 10:08:42 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.2.Beta1+Sun/8.11.2.Beta1) with ESMTP id eBII8Xr19392 for ; Mon, 18 Dec 2000 10:08:33 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id KAA09315; Mon, 18 Dec 2000 10:08:30 -0800 (PST) Received: from melimelo.enst-bretagne.fr (melimelo.enst-bretagne.fr [192.108.115.36]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA03620; Mon, 18 Dec 2000 10:08:29 -0800 (PST) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by melimelo.enst-bretagne.fr (8.10.1/8.10.1) with ESMTP id eBII8O413674; Mon, 18 Dec 2000 19:08:24 +0100 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id TAA25654; Mon, 18 Dec 2000 19:08:24 +0100 (MET) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.9.3/8.9.3) with ESMTP id TAA11585; Mon, 18 Dec 2000 19:10:10 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200012181810.TAA11585@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Tim Hartrick cc: Erik.Nordmark@eng.sun.com, ipng@sunroof.eng.sun.com Subject: Re: destination option update In-reply-to: Your message of Fri, 15 Dec 2000 14:45:29 PST. <200012152245.OAA02954@feller.mentat.com> Date: Mon, 18 Dec 2000 19:10:10 +0100 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: I believed before and believe now that this is the better way to go. I never really liked the IPV6_RTHDRDSTOPTS option. => I understand your opinion but we have to provide a way to denote the position for the sending side. As I said, I don't believe that this is necessary. Of course I may be completely misunderstanding the nature of the problems. => if you have both note 1 and note 3 destination option headers to send you need a way to code this. The kernel should not have to parse headers in order to understand what you want according to options. Francis.Dupont@enst-bretagne.fr PS: at ETSI bake-off an implementor panel asked for this (summary: ok to add a new position but please cleanup this, two are already too many, three will be a real mess). PPS: more I think about this, more the stack API seems to good path... -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Dec 18 11:06:15 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta1+Sun/8.11.2.Beta1) id eBIJ4SW19470 for ipng-dist; Mon, 18 Dec 2000 11:04:28 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.2.Beta1+Sun/8.11.2.Beta1) with ESMTP id eBIJ4Hr19463 for ; Mon, 18 Dec 2000 11:04:17 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id LAA03502; Mon, 18 Dec 2000 11:04:16 -0800 (PST) Received: from roll.mentat.com ([192.88.122.129]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA29465; Mon, 18 Dec 2000 11:04:13 -0800 (PST) Received: from leo.mentat.com (leo [192.88.122.132]) by roll.mentat.com (8.9.1b+Sun/8.9.1) with ESMTP id LAA03909; Mon, 18 Dec 2000 11:04:24 -0800 (PST) Received: from feller.mentat.com (feller [192.88.122.144]) by leo.mentat.com (8.9.1b+Sun/8.9.1) with ESMTP id LAA21968; Mon, 18 Dec 2000 11:04:25 -0800 (PST) Received: (from tim@localhost) by feller.mentat.com (8.9.3+Sun/8.9.3) id LAA01011; Mon, 18 Dec 2000 11:07:31 -0800 (PST) Date: Mon, 18 Dec 2000 11:07:31 -0800 (PST) From: Tim Hartrick Message-Id: <200012181907.LAA01011@feller.mentat.com> To: Erik.Nordmark@eng.sun.com Subject: Re: destination option update Cc: Francis.Dupont@enst-bretagne.fr, ipng@sunroof.eng.sun.com X-Sun-Charset: US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Erik, > > > I don't know that the receiving application needs to know any of this. It > > merely needs to know that the appropriate security was applied by the system. > > That would seem to be understood given that the application is receiving the > > datagram. If appropriate security wasn't applied the datagram should have > > been discarded before it reached the application. > > But the application might very well want to know what destination options > were protected by ESP. The security checks will presumably only tell the > application that, in the case of transport mode, that the tranport > header and data was protected. > Thus the application can't tell if the destination options where covered > by ESP or not using the APIs. > So the problem is that we have a node which is receiving control information in destination options. This control information must, at a minimum, be authenticated using AH. There are implementators that want to have the processing of this control information in user space or in some kernel driver which uses a kernel sockets API. The current API has no way to inform the application whether the extension header passed in ancillary data has been authenticated. Am I stating the problem correctly? If so it seems like we could define a new ancillary data item which would simply indicated whether a datagram did or did not have AH coverage. We could also define an additional ancillary data item which could mark where in the extension headers the ESP header had been located. For example, lets say we have a UDP datagram that looked like the following: IPv6 header Hop-by-hop options header Destination options header AH header ESP header Destination options header UDP payload Assuming that all the relevent IPV6_RECVxxx options had been enabled the ancillary data would look like. IPV6_HOPOPTS IPV6_DSTOPTS IPV6_AUTH IPV6_ESP IPV6_DSTOPTS The IPV6_AUTH and IPV6_ESP ancillary data items would have zero length data. They do nothing but mark where the respective headers are located in the datagram. Ugly with lots of overhead but given the requirement and the API we have I don't see much in the way of choices. Passing out the entire datagram might be easier except for the information leaking that would occur because of the inclusion of the ESP and AH headers. > > I think that the problem is on the send side for things like the home address > > option and the encapsulation limit option. In those cases the application > > wants to send: > > > > IP header > > dstopt > > upper layer > > > > but the application wants the dstopt to be in the *non-fragmentable* part > > of the datagram. Given the current API and partially because of the > > fragmentation algorithm in the IPv6 base specification that isn't possible. > > In these cases the "application" may be a kernel tunneling driver or > > something. > > > > If we can enhance the API to allow the application to specify where it > > wants the non-fragmentable part of the datagram to end that would fix the > > problem(s) as I currently understand them. > > Any suggestions on how to specify this on the send side? > Heh.... Well given the limited fidelity of ancillary data there aren't a lot of choices other than defining a new ancillary data type (IPV6_FRAGDSTOPTS for example). I haven't tried to think about other possibilities yet. I would hope that if we define something like IPV6_FRAGDSTOPTS that we could retire IPV6_RTHDRDSTOPTS since IPV6_RTHDRDSTOPTS, as I envision it, is a subset of IPV6_FRAGDSTOPTS. tim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Dec 18 13:59:13 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta1+Sun/8.11.2.Beta1) id eBILvbg19582 for ipng-dist; Mon, 18 Dec 2000 13:57:37 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.2.Beta1+Sun/8.11.2.Beta1) with ESMTP id eBILvSr19575 for ; Mon, 18 Dec 2000 13:57:28 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id NAA00127 for ; Mon, 18 Dec 2000 13:57:26 -0800 (PST) Received: from mail.lysator.liu.se (mail.lysator.liu.se [130.236.254.3]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA25249 for ; Mon, 18 Dec 2000 13:57:25 -0800 (PST) Received: from sture.lysator.liu.se (sture.lysator.liu.se [130.236.254.21]) by mail.lysator.liu.se (Postfix) with ESMTP id 582752402D3D; Mon, 18 Dec 2000 21:57:20 +0000 (GMT) Received: (from nisse@localhost) by sture.lysator.liu.se (8.9.0/8.8.7) id WAA28937; Mon, 18 Dec 2000 22:57:19 +0100 (MET) To: Tim Hartrick Cc: Erik.Nordmark@eng.sun.com, Francis.Dupont@enst-bretagne.fr, ipng@sunroof.eng.sun.com Subject: Re: destination option update References: <200012181907.LAA01011@feller.mentat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit From: nisse@lysator.liu.se (Niels Möller) Date: 18 Dec 2000 22:57:19 +0100 In-Reply-To: Tim Hartrick's message of "Mon, 18 Dec 2000 11:07:31 -0800 (PST)" Message-ID: Lines: 36 X-Mailer: Gnus v5.7/Emacs 20.7 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Tim Hartrick writes: > For example, lets say we have a UDP datagram that looked like the following: > > IPv6 header > Hop-by-hop options header > Destination options header > AH header > ESP header > > Destination options header > UDP payload > > Assuming that all the relevent IPV6_RECVxxx options had been enabled the > ancillary data would look like. > > IPV6_HOPOPTS > IPV6_DSTOPTS > IPV6_AUTH > IPV6_ESP > IPV6_DSTOPTS > > The IPV6_AUTH and IPV6_ESP ancillary data items would have zero length data. > They do nothing but mark where the respective headers are located in the > datagram. To me it would make sense to have associated data that is the index of the security association used (is that the right term? I'm not really up to date on IPSEC terminology). Would it make sense to use the same ancillary data on the sending side, for applications that want full control of IPSEC and other headers? I'm imagining an application that makes creative use of nested ESP and source routing headers for hiding traffic. /Niels -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Dec 18 14:09:43 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta1+Sun/8.11.2.Beta1) id eBIM8BK19647 for ipng-dist; Mon, 18 Dec 2000 14:08:11 -0800 (PST) Received: from eastmail1.East.Sun.COM (eastmail1.East.Sun.COM [129.148.1.240]) by sunroof.eng.sun.com (8.11.2.Beta1+Sun/8.11.2.Beta1) with ESMTP id eBIM82r19640 for ; Mon, 18 Dec 2000 14:08:02 -0800 (PST) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail1.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id RAA27928; Mon, 18 Dec 2000 17:08:02 -0500 (EST) Received: from thunk (localhost [127.0.0.1]) by thunk.east.sun.com (8.11.1+Sun/8.10.2) with ESMTP id eBIM5LX101416; Mon, 18 Dec 2000 17:05:51 -0500 (EST) Message-Id: <200012182205.eBIM5LX101416@thunk.east.sun.com> From: Bill Sommerfeld To: nisse@lysator.liu.se (Niels M ller) cc: Tim Hartrick , Erik.Nordmark@eng.sun.com, Francis.Dupont@enst-bretagne.fr, ipng@sunroof.eng.sun.com Subject: Re: destination option update In-reply-to: Your message of "18 Dec 2000 22:57:19 +0100." Reply-to: sommerfeld@east.sun.com Date: Mon, 18 Dec 2000 17:05:21 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > To me it would make sense to have associated data that is the index of > the security association used (is that the right term? I'm not really > up to date on IPSEC terminology). The actual spi value is not likely to be very useful to the application (when key management is in use, it's a random number which lasts as long as the sa does, and sa's are, in the long run, ephemeral). On the other hand, other metadata associated with the SA would be (the authenticated peer identity, for one). - Bill -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Dec 18 14:38:31 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta1+Sun/8.11.2.Beta1) id eBIMalO19687 for ipng-dist; Mon, 18 Dec 2000 14:36:47 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.2.Beta1+Sun/8.11.2.Beta1) with ESMTP id eBIMaWr19679 for ; Mon, 18 Dec 2000 14:36:33 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id OAA11770; Mon, 18 Dec 2000 14:36:31 -0800 (PST) Received: from roll.mentat.com (mentat.com [192.88.122.129]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA22656; Mon, 18 Dec 2000 14:36:31 -0800 (PST) Received: from leo.mentat.com (leo [192.88.122.132]) by roll.mentat.com (8.9.1b+Sun/8.9.1) with ESMTP id OAA04739; Mon, 18 Dec 2000 14:36:39 -0800 (PST) Received: from feller.mentat.com (feller [192.88.122.144]) by leo.mentat.com (8.9.1b+Sun/8.9.1) with ESMTP id OAA27461; Mon, 18 Dec 2000 14:36:39 -0800 (PST) Received: (from tim@localhost) by feller.mentat.com (8.9.3+Sun/8.9.3) id OAA00517; Mon, 18 Dec 2000 14:39:46 -0800 (PST) Date: Mon, 18 Dec 2000 14:39:46 -0800 (PST) From: Tim Hartrick Message-Id: <200012182239.OAA00517@feller.mentat.com> To: nisse@lysator.liu.se Subject: Re: destination option update Cc: Erik.Nordmark@eng.sun.com, Francis.Dupont@enst-bretagne.fr, ipng@sunroof.eng.sun.com X-Sun-Charset: US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Niels, > > To me it would make sense to have associated data that is the index of > the security association used (is that the right term? I'm not really > up to date on IPSEC terminology). > > Would it make sense to use the same ancillary data on the sending > side, for applications that want full control of IPSEC and other > headers? I'm imagining an application that makes creative use of > nested ESP and source routing headers for hiding traffic. > I question the utility and security of these additional facilities but I am not a sear nor a security expert. I would prefer to keep it simple and opague unless absolutely required. Other's opinions may vary. tim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Dec 18 14:38:35 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta1+Sun/8.11.2.Beta1) id eBIMabv19686 for ipng-dist; Mon, 18 Dec 2000 14:36:37 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.2.Beta1+Sun/8.11.2.Beta1) with ESMTP id eBIMaOr19671 for ; Mon, 18 Dec 2000 14:36:24 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id OAA29283 for ; Mon, 18 Dec 2000 14:36:25 -0800 (PST) Received: from mail.lysator.liu.se (mail.lysator.liu.se [130.236.254.3]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA15877 for ; Mon, 18 Dec 2000 14:36:24 -0800 (PST) Received: from sture.lysator.liu.se (sture.lysator.liu.se [130.236.254.21]) by mail.lysator.liu.se (Postfix) with ESMTP id 0D6D22402D41; Mon, 18 Dec 2000 22:36:22 +0000 (GMT) Received: (from nisse@localhost) by sture.lysator.liu.se (8.9.0/8.8.7) id XAA25079; Mon, 18 Dec 2000 23:36:21 +0100 (MET) To: sommerfeld@east.sun.com Cc: Tim Hartrick , Erik.Nordmark@eng.sun.com, Francis.Dupont@enst-bretagne.fr, ipng@sunroof.eng.sun.com Subject: Re: destination option update References: <200012182205.eBIM5LX101416@thunk.east.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit From: nisse@lysator.liu.se (Niels Möller) Date: 18 Dec 2000 23:36:21 +0100 In-Reply-To: Bill Sommerfeld's message of "Mon, 18 Dec 2000 17:05:21 -0500" Message-ID: Lines: 24 X-Mailer: Gnus v5.7/Emacs 20.7 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Bill Sommerfeld writes: > > To me it would make sense to have associated data that is the index of > > the security association used (is that the right term? I'm not really > > up to date on IPSEC terminology). > > The actual spi value is not likely to be very useful to the > application (when key management is in use, it's a random number which > lasts as long as the sa does, and sa's are, in the long run, > ephemeral). It would be useful to the appliction if either (i) the application is doing its own key management, and it installed a bunch of values into the ipsec engine earlier, or (ii) there's some mechanism to map the value to other useful information. > On the other hand, other metadata associated with the SA > would be (the authenticated peer identity, for one). It still seems reasonable to provide a (short) index with the ancillary data, and use some other mechanism to look up its properties. /Niels -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Dec 18 15:40:34 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta1+Sun/8.11.2.Beta1) id eBINctO19814 for ipng-dist; Mon, 18 Dec 2000 15:38:55 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.2.Beta1+Sun/8.11.2.Beta1) with ESMTP id eBINcir19807 for ; Mon, 18 Dec 2000 15:38:44 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id PAA13224 for ; Mon, 18 Dec 2000 15:38:44 -0800 (PST) Received: from starfruit.itojun.org (dhcp214.inetweek2000.nic.ad.jp [61.113.177.214]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id QAA14015 for ; Mon, 18 Dec 2000 16:38:41 -0700 (MST) Received: from itojun.org (localhost [127.0.0.1]) by starfruit.itojun.org (Postfix) with ESMTP id 7F6117E5C; Tue, 19 Dec 2000 08:34:52 +0900 (JST) To: Francis Dupont Cc: Erik Nordmark , ipng@sunroof.eng.sun.com In-reply-to: Francis.Dupont's message of Mon, 18 Dec 2000 19:01:05 +0100. <200012181801.TAA11535@givry.rennes.enst-bretagne.fr> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: destination option update From: Jun-ichiro itojun Hagino Date: Tue, 19 Dec 2000 08:34:52 +0900 Message-Id: <20001218233452.7F6117E5C@starfruit.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >> This would still have some problems since certain extension headers >> (fragmentation, AH, ESP) aren't passed up to the application. >=> exactly my second concern. one question - maybe i have lost some context. we are talking about socket API. is it really necessary for user applications to be able to transmit arbitrary AH/ESP/fragment header? even for raw IP socket, i think it reasonable to forbid users from attaching arbitrary AH/ESP/fragment header (i.e. to say that they are "kernel" thingie). itojun -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Dec 18 16:48:17 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta1+Sun/8.11.2.Beta1) id eBJ0fvi19901 for ipng-dist; Mon, 18 Dec 2000 16:41:57 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.2.Beta1+Sun/8.11.2.Beta1) with ESMTP id eBJ0eur19890 for ; Mon, 18 Dec 2000 16:41:07 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id QAA25082; Mon, 18 Dec 2000 16:38:58 -0800 (PST) Received: from coconut.itojun.org (coconut.itojun.org [210.160.95.97]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id RAA16802; Mon, 18 Dec 2000 17:38:56 -0700 (MST) Received: from kiwi.itojun.org (localhost.itojun.org [127.0.0.1]) by coconut.itojun.org (8.9.3+3.2W/3.7W) with ESMTP id JAA17656; Tue, 19 Dec 2000 09:38:44 +0900 (JST) To: Tim Hartrick cc: Francis.Dupont@enst-bretagne.fr, Erik.Nordmark@eng.sun.com, ipng@sunroof.eng.sun.com In-reply-to: tim's message of Mon, 18 Dec 2000 16:39:55 PST. <200012190039.QAA00603@feller.mentat.com> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: destination option update From: itojun@iijlab.net Date: Tue, 19 Dec 2000 09:38:44 +0900 Message-ID: <17654.977186324@coconut.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >> >> This would still have some problems since certain extension headers >> >> (fragmentation, AH, ESP) aren't passed up to the application. >> >=> exactly my second concern. >> one question - maybe i have lost some context. >> we are talking about socket API. is it really necessary >> for user applications to be able to transmit arbitrary AH/ESP/fragment >> header? also i should note that, if you need to transmit arbitrary packet to the wire, there are other ways like BPF writes. itojun -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Dec 18 16:48:19 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta1+Sun/8.11.2.Beta1) id eBJ0bq319888 for ipng-dist; Mon, 18 Dec 2000 16:37:52 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.2.Beta1+Sun/8.11.2.Beta1) with ESMTP id eBJ0bXr19881 for ; Mon, 18 Dec 2000 16:37:37 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id QAA15192; Mon, 18 Dec 2000 16:37:31 -0800 (PST) Received: from roll.mentat.com (mentat.com [192.88.122.129]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id RAA15872; Mon, 18 Dec 2000 17:37:17 -0700 (MST) Received: from leo.mentat.com (leo [192.88.122.132]) by roll.mentat.com (8.9.1b+Sun/8.9.1) with ESMTP id QAA05263; Mon, 18 Dec 2000 16:36:49 -0800 (PST) Received: from feller.mentat.com (feller [192.88.122.144]) by leo.mentat.com (8.9.1b+Sun/8.9.1) with ESMTP id QAA00253; Mon, 18 Dec 2000 16:36:49 -0800 (PST) Received: (from tim@localhost) by feller.mentat.com (8.9.3+Sun/8.9.3) id QAA00603; Mon, 18 Dec 2000 16:39:55 -0800 (PST) Date: Mon, 18 Dec 2000 16:39:55 -0800 (PST) From: Tim Hartrick Message-Id: <200012190039.QAA00603@feller.mentat.com> To: Francis.Dupont@enst-bretagne.fr, itojun@iijlab.net Subject: Re: destination option update Cc: Erik.Nordmark@eng.sun.com, ipng@sunroof.eng.sun.com X-Sun-Charset: US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > From owner-ipng@sunroof.eng.sun.com Mon Dec 18 15:41:56 2000 > Received: from roll.mentat.com (roll [192.88.122.129]) > by leo.mentat.com (8.9.1b+Sun/8.9.1) with ESMTP id PAA28833 > for ; Mon, 18 Dec 2000 15:41:47 -0800 (PST) > Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) > by roll.mentat.com (8.9.1b+Sun/8.9.1) with ESMTP id PAA05049 > for ; Mon, 18 Dec 2000 15:41:44 -0800 (PST) > Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) > by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA29883; > Mon, 18 Dec 2000 15:41:12 -0800 (PST) Itojun, > > >> This would still have some problems since certain extension headers > >> (fragmentation, AH, ESP) aren't passed up to the application. > >=> exactly my second concern. > > one question - maybe i have lost some context. > we are talking about socket API. is it really necessary > for user applications to be able to transmit arbitrary AH/ESP/fragment > header? > I certainly don't think so. Sounds like any easy way to open the door for kiddies to do DoS attacks and not a lot more. > even for raw IP socket, i think it reasonable to forbid users > from attaching arbitrary AH/ESP/fragment header (i.e. to say that > they are "kernel" thingie). > I agree. tim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Dec 19 06:11:39 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta1+Sun/8.11.2.Beta1) id eBJEAAw20453 for ipng-dist; Tue, 19 Dec 2000 06:10:10 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.2.Beta1+Sun/8.11.2.Beta1) with ESMTP id eBJEA1r20446 for ; Tue, 19 Dec 2000 06:10:02 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id GAA19776; Tue, 19 Dec 2000 06:10:01 -0800 (PST) Received: from melimelo.enst-bretagne.fr (melimelo.enst-bretagne.fr [192.108.115.36]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id GAA22920; Tue, 19 Dec 2000 06:09:59 -0800 (PST) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by melimelo.enst-bretagne.fr (8.10.1/8.10.1) with ESMTP id eBJE9g423118; Tue, 19 Dec 2000 15:09:42 +0100 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id PAA28192; Tue, 19 Dec 2000 15:09:41 +0100 (MET) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.9.3/8.9.3) with ESMTP id PAA16348; Tue, 19 Dec 2000 15:11:32 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200012191411.PAA16348@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: nisse@lysator.liu.se (Niels Möller) cc: Tim Hartrick , Erik.Nordmark@eng.sun.com, ipng@sunroof.eng.sun.com Subject: Re: destination option update In-reply-to: Your message of 18 Dec 2000 22:57:19 +0100. Date: Tue, 19 Dec 2000 15:11:32 +0100 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: To me it would make sense to have associated data that is the index of the security association used (is that the right term? I'm not really up to date on IPSEC terminology). => I agree, the SPI is the useful key to metadata. Would it make sense to use the same ancillary data on the sending side, for applications that want full control of IPSEC and other headers? I'm imagining an application that makes creative use of nested ESP and source routing headers for hiding traffic. => this should be managed by policies, not directly by the header API. Francis.Dupont@enst-bretagne.fr -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Dec 19 08:34:45 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta1+Sun/8.11.2.Beta1) id eBJGX8620577 for ipng-dist; Tue, 19 Dec 2000 08:33:08 -0800 (PST) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.11.2.Beta1+Sun/8.11.2.Beta1) with ESMTP id eBJGX4r20570 for ; Tue, 19 Dec 2000 08:33:04 -0800 (PST) Received: (from jrh@localhost) by stinker.eng.sun.com (8.11.0+Sun/8.11.0) id eBJGVa219390 for ipng@sunroof.eng.sun.com; Tue, 19 Dec 2000 08:31:36 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.2.Beta1+Sun/8.11.2.Beta1) with ESMTP id eBJ9EQr20287 for ; Tue, 19 Dec 2000 01:14:26 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id BAA29082 for ; Tue, 19 Dec 2000 01:14:25 -0800 (PST) Received: from ws2.piuha.net (ws2.piuha.net [195.165.196.2]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id BAA03486 for ; Tue, 19 Dec 2000 01:14:19 -0800 (PST) Received: from piuha.net (ws4.piuha.net [195.165.196.4]) by ws2.piuha.net (Postfix) with ESMTP id C2EE47642A for ; Tue, 19 Dec 2000 11:14:12 +0200 (EET) Message-ID: <3A3F2730.4875B79@piuha.net> Date: Tue, 19 Dec 2000 11:15:28 +0200 From: Jari Arkko Reply-To: jarkko@piuha.net Organization: None X-Mailer: Mozilla 4.73 [en] (X11; U; Linux 2.2.17-icclin i686) X-Accept-Language: en MIME-Version: 1.0 To: ipng@sunroof.eng.sun.com Subject: Denial of Service attacks and ICMPv6 Packet Too Big Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hello. RFC 2463 section 2.4 (e) specifies that Packet Too Big can be sent as a reply to a multicast message. Is this a source of a DoS problem? I.e. send a message with a large MTU to a large multicast group, lie about the source address, and flood real node with the forged source address with lots of traffic. All this with the cost of sending a single packet. Rate limitations are discussed in part (f) but I don't think that helps in this situation as each individual recipient would only be sending one ICMP message. The same situation exists also for the Parameter Problem ICMP message. Jari Arkko Ericsson -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Dec 19 08:34:52 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta1+Sun/8.11.2.Beta1) id eBJGXcf20586 for ipng-dist; Tue, 19 Dec 2000 08:33:38 -0800 (PST) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.11.2.Beta1+Sun/8.11.2.Beta1) with ESMTP id eBJGXVr20579 for ; Tue, 19 Dec 2000 08:33:32 -0800 (PST) Received: (from jrh@localhost) by stinker.eng.sun.com (8.11.0+Sun/8.11.0) id eBJGW3u19420 for ipng@sunroof.eng.sun.com; Tue, 19 Dec 2000 08:32:03 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.2.Beta1+Sun/8.11.2.Beta1) with ESMTP id eBJ9Ffr20308 for ; Tue, 19 Dec 2000 01:15:42 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id BAA27480 for ; Tue, 19 Dec 2000 01:15:30 -0800 (PST) Received: from ws2.piuha.net (ws2.piuha.net [195.165.196.2]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA10069 for ; Tue, 19 Dec 2000 01:15:29 -0800 (PST) Received: from piuha.net (ws4.piuha.net [195.165.196.4]) by ws2.piuha.net (Postfix) with ESMTP id 94BEA7642B; Tue, 19 Dec 2000 11:15:16 +0200 (EET) Message-ID: <3A3F276E.D84D9839@piuha.net> Date: Tue, 19 Dec 2000 11:16:30 +0200 From: Jari Arkko Reply-To: jarkko@piuha.net Organization: None X-Mailer: Mozilla 4.73 [en] (X11; U; Linux 2.2.17-icclin i686) X-Accept-Language: en MIME-Version: 1.0 To: Stephen Kent Cc: Stefan Schlott , ipsec@lists.tislabs.com, steve.hanna@east.sun.com, aidan.williams@motorola.com, ipng@sunroof.eng.sun.com Subject: Re: IPv6 Neighbour Solicitation messages and IPsec References: <008e01c0610c$16237c20$8a1b6e0a@arenanet.fi> <20001211082557.A2125@orca.informatik.uni-ulm.de> <3A362BA2.D7EF1481@piuha.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Stephen Kent wrote: > > * Path MTU discovery. Consider the following case: > > > > (N1)----(VPNGW1)----(R1)----(VPNGW2)-----(R2)----(N2) > > > > Assume N1 wants to send traffic to N2, part of the path > > goes through an insecure network part, secured using > > VPNGWs 1 and 2. And now Path MTU discovery is in > > progress between N1 and N2. Assume the smallest MTU > > is at R2. Then an ICMPv6 Packet Too Big message must be > > sent back towards the VPNGW2. Should that message > > go to the tunnel? I think it should. > > There is nothing to prohibit transmission of this ICMP message via > the security gateways, if appropriate SPD entries exist. You are right, but the context of the discussion was that a proposal was made that all ICMPv6 messages should bypass IPsec processing in order to avoid chicken-and-egg problems with some ICMPv6 messages. I was trying to make the point that _some_ ICMPv6 messages at least in _some_ situations have to go through IPsec. Hence, the "ignore ICMPv6 in IPsec" solution doesn't fly. It was also suggested that perhaps the difference lies in tunnel mode vs transport mode. However, that distinction doesn't solve the problems either... two nodes on the same link could well have tunnel mode policies for all traffic, which would then prevent e.g. duplicate address detection to work, which in turn would prevent all communications. Also, as per RFC 2401 we do not in general have the possibility to specify policies for individual ICMP message types. Finally, one might have expected multicast / unicast addresses to have a significance such that we could say only unicast traffic gets IPsec protection, but apparently this isn't always the case. For instance, when the Neighbour Advertisement message is used as a reply in an address resolution situation, it is a unicast message. Instead, I think we need something else. What was previously lower layer thing such as ARP, is now a proper IP packet in v6. In addition, there is completely new functionality. These must be considered when thinking about which messages should get IPsec protection, and how. The ICMPv6 messages can be classified as follows: No RFC Name End-to-End Required Before UDP works 1 2463 Dest unreach Yes No 2 2463 Packet too big Yes No 3 2463 Time exceeded Yes No 4 2463 Parameter problem Yes No 128 2463 Echo request Yes No 129 2463 Echo reply Yes No 137 2461 Redirect No Yes 133 2461 Router solicit No Yes 134 2461 Router adv No Yes 135 2461 NeighSol/Resol No Yes 136 2461 NeighAdv/Resol No Yes 135 2461 NeighSol/Unreach No No 136 2461 NeighAdv/Unreach No No 135 2462 NeighSol/Autoconf No Yes 136 2462 NeighAdv/Autoconf No Yes Note that Neihbour Solicitation and Advertisement play multiple roles, address resolution, unreachability detection, and autoconfiguration. The crucial thing in the above table is to note which messages are necessary before two IPv6 nodes can exchange packets. For IPsec, the relevant issue is if SAs can be negotiated using IKE which runs on top of UDP. If not, such messages simply can not be protected with dynamic SAs; for instance we can't send UDP messages before address autoconfiguration has determined the suitable addresses to be used and ensured that no duplicate addresses exist on the link. So, what I would propose is that the ICMPv6 messages Redirect, Router Solicitation/Advertisement, and Neighbour Solicitation/Advertisement (except for reachbility detection) are never given normal IPsec treatment. I.e., if I define my policies as always requiring IKE & IPsec for all traffic, then these exceptional messages still go in the clear and without IKE. Furthermore, I would suggest that if protection is needed for the exceptional ICMPv6 message set, then manually configured IPsec SAs be used, enabling also the protection of multicast traffic. However, in order to do things like this, the SPD must have sufficient expressive power to distinguish ICMP messages types and roles. Finally, I would propose that everywhere in the ICMPv6 specifications where it says "AH", tunnel mode ESP would suffice as well. Jari -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Dec 19 10:57:12 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta1+Sun/8.11.2.Beta1) id eBJItSA20756 for ipng-dist; Tue, 19 Dec 2000 10:55:28 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.2.Beta1+Sun/8.11.2.Beta1) with ESMTP id eBJItGr20749 for ; Tue, 19 Dec 2000 10:55:17 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id KAA21525 for ; Tue, 19 Dec 2000 10:55:16 -0800 (PST) Received: from gungnir.fnal.gov (gungnir.fnal.gov [131.225.80.1]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA29742 for ; Tue, 19 Dec 2000 10:55:15 -0800 (PST) Received: from gungnir.fnal.gov (localhost [127.0.0.1]) by gungnir.fnal.gov (8.9.1/8.9.1) with ESMTP id MAA08694; Tue, 19 Dec 2000 12:54:36 -0600 (CST) Message-Id: <200012191854.MAA08694@gungnir.fnal.gov> To: jarkko@piuha.net Cc: ipsec@lists.tislabs.com, ipng@sunroof.eng.sun.com From: "Matt Crawford" Subject: Re: IPv6 Neighbour Solicitation messages and IPsec In-reply-to: Your message of Tue, 19 Dec 2000 11:16:30 +0200. <3A3F276E.D84D9839@piuha.net> Date: Tue, 19 Dec 2000 12:54:36 -0600 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > which in turn would prevent all communications. Also, as per RFC > 2401 we do not in general have the possibility to specify policies > for individual ICMP message types. This passed the IESG in RFC 2894 (so it must be true): Note that for the SPD to distinguish Router Renumbering from other ICMP packets requires the use of the ICMP Type field as a selector. This is consistent with, although not mentioned by, the Security Architecture specification [IPSEC]. It's no contradiction with what you said, though. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Dec 19 11:12:08 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta1+Sun/8.11.2.Beta1) id eBJJALv20787 for ipng-dist; Tue, 19 Dec 2000 11:10:21 -0800 (PST) Received: from eastmail2.East.Sun.COM (eastmail2.East.Sun.COM [129.148.1.241]) by sunroof.eng.sun.com (8.11.2.Beta1+Sun/8.11.2.Beta1) with ESMTP id eBJJABr20780 for ; Tue, 19 Dec 2000 11:10:12 -0800 (PST) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail2.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id OAA05806; Tue, 19 Dec 2000 14:10:10 -0500 (EST) Received: from thunk (localhost [127.0.0.1]) by thunk.east.sun.com (8.11.1+Sun/8.10.2) with ESMTP id eBJJ9TX104061; Tue, 19 Dec 2000 14:09:29 -0500 (EST) Message-Id: <200012191909.eBJJ9TX104061@thunk.east.sun.com> From: Bill Sommerfeld To: "Matt Crawford" cc: jarkko@piuha.net, ipsec@lists.tislabs.com, ipng@sunroof.eng.sun.com Subject: Re: IPv6 Neighbour Solicitation messages and IPsec In-reply-to: Your message of "Tue, 19 Dec 2000 12:54:36 CST." <200012191854.MAA08694@gungnir.fnal.gov> Reply-to: sommerfeld@east.sun.com Date: Tue, 19 Dec 2000 14:09:29 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > which in turn would prevent all communications. Also, as per RFC > > 2401 we do not in general have the possibility to specify policies > > for individual ICMP message types. > > This passed the IESG in RFC 2894 (so it must be true): > > > Note that for the SPD to distinguish Router Renumbering from other > ICMP packets requires the use of the ICMP Type field as a selector. > This is consistent with, although not mentioned by, the Security > Architecture specification [IPSEC]. > > It's no contradiction with what you said, though. It should also be said that many ipsec implementors recognize the need to have special support for icmp in ipsec policy; besides icmp type, there's also the matter of protecting icmp errors using the "same" policy as the traffic that generated them.. - Bill -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Dec 19 14:48:33 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta1+Sun/8.11.2.Beta1) id eBJMksM21012 for ipng-dist; Tue, 19 Dec 2000 14:46:54 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.2.Beta1+Sun/8.11.2.Beta1) with ESMTP id eBJMkjr21005 for ; Tue, 19 Dec 2000 14:46:45 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id OAA23754 for ; Tue, 19 Dec 2000 14:46:46 -0800 (PST) Received: from wodc7mr4.ffx.ops.us.uu.net (wodc7mr4.ffx.ops.us.uu.net [192.48.96.29]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA08603 for ; Tue, 19 Dec 2000 15:46:44 -0700 (MST) Received: from D555F501 by wodc7mr4.ffx.ops.us.uu.net with SMTP (peer crosschecked as: [63.119.86.41]) id QQjuhn09501 for ; Tue, 19 Dec 2000 22:46:43 GMT Message-ID: <004d01c06a0e$03899ad0$2956773f@D555F501> From: "Radha Gowda" To: Subject: Commercial IPv6 implementations Date: Tue, 19 Dec 2000 17:49:58 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Are there any commercially available "IPv6 core and extensions" implementations in the market? If not, anyone with plans to make them available sometime next year? Thanks, Radha -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Dec 19 15:45:43 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta1+Sun/8.11.2.Beta1) id eBJNi6M21055 for ipng-dist; Tue, 19 Dec 2000 15:44:06 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.2.Beta1+Sun/8.11.2.Beta1) with ESMTP id eBJNhtr21048 for ; Tue, 19 Dec 2000 15:43:55 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id PAA17206 for ; Tue, 19 Dec 2000 15:43:55 -0800 (PST) Received: from starfruit.itojun.org (pc3.royal-internet-unet.ocn.ne.jp [211.6.236.211]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA11865 for ; Tue, 19 Dec 2000 15:43:54 -0800 (PST) Received: from itojun.org (localhost [127.0.0.1]) by starfruit.itojun.org (Postfix) with ESMTP id 2B6DD7E23; Wed, 20 Dec 2000 08:40:09 +0900 (JST) To: "Radha Gowda" Cc: ipng@sunroof.eng.sun.com In-reply-to: Radha's message of Tue, 19 Dec 2000 17:49:58 EST. <004d01c06a0e$03899ad0$2956773f@D555F501> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: Commercial IPv6 implementations From: Jun-ichiro itojun Hagino Date: Wed, 20 Dec 2000 08:40:09 +0900 Message-Id: <20001219234009.2B6DD7E23@starfruit.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >Are there any commercially available "IPv6 core and extensions" >implementations in the market? If not, anyone with plans to make them >available sometime next year? I'm not sure wht you mean by "commercial", but there are a lot of them, with official support (you can call up help desk). to give you an example: Solaris 2.8. try http://playground.sun.com/ipng/. itojun -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Dec 19 20:39:06 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta2+Sun/8.11.2.Beta2) id eBK4bde21301 for ipng-dist; Tue, 19 Dec 2000 20:37:39 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.2.Beta2+Sun/8.11.2.Beta2) with ESMTP id eBK4bUH21294 for ; Tue, 19 Dec 2000 20:37:30 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id UAA18135 for ; Tue, 19 Dec 2000 20:37:29 -0800 (PST) Received: from mail3.microsoft.com (mail3.microsoft.com [131.107.3.123]) by patan.sun.com (8.9.3+Sun/8.9.3) with SMTP id UAA18403 for ; Tue, 19 Dec 2000 20:37:29 -0800 (PST) Received: from 157.54.9.100 by mail3.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 19 Dec 2000 20:36:24 -0800 (Pacific Standard Time) Received: by inet-imc-03.redmond.corp.microsoft.com with Internet Mail Service (5.5.2651.58) id ; Tue, 19 Dec 2000 20:37:02 -0800 Message-ID: <7695E2F6903F7A41961F8CF888D87EA81C9C03@red-msg-06.redmond.corp.microsoft.com> From: Richard Draves To: "'M. T. Hollinger'" Cc: ipng@sunroof.eng.sun.com Subject: RE: Remaining MUSTs in default-addr-select-02 Date: Tue, 19 Dec 2000 20:37:10 -0800 X-Mailer: Internet Mail Service (5.5.2651.58) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > I have some concerns about the details, primarily because my years of > working on a "strong host model" network layer have led me to really > question that model. It's probably too late, for the > protocol stack I work > on, but I'd like to make sure it's easy for other > implementers to use a weak > host model. Also, I want to make sure applications are > empowered to select > their own addresses with minimal second-guessing at the network layer. You get into these issues in more detail below, but the quick summary is that applications can select their own addresses (by binding to a specific source address) and the draft recommends but does not require the strong host model, per WG consensus. > > All IPv6 nodes, including both hosts and routers, must implement > > default address selection as defined in this specification. > > It seems funny to have a "must" (different from a "MUST"?) > in the abstract, > and since half the draft talks about destination address selection > (typically not an issue for routers, which may not even include a BIND > resolver or host table), I don't see why routers are required > to implement > it. When routers are forwarding packets, the draft doesn't apply since they are not performing source or destination address selection. But when routers do perform source or destination address selection, then I believe the draft should apply. So I think it is appropriate for the scope of the draft to be all IPv6 nodes. > > The IPv6 > > addressing architecture defines scope field values for node-local > > (0x1), link-local (0x2), site-local (0x5), ... > > ... > > IPv4 loopback addresses [11, section 4.2.2.11], which > > have the prefix 127/8, are assigned link-local scope. > > Why not node-local, since you went to the trouble of > mentioning it earlier? draft-ietf-ipngwg-scoping-arch-01.txt also says that the loopback address has link-local scope. One reason for not using node-local is that this would introduce a big exception, because all other unicast addresses are link-local, site-local, or global. > Consider this source address selection problem: > > Destination: fe80::2 > Sources: fe80::1 (deprecated) vs ::1 > Result: ::1 (avoid deprecated address) > > Is it legal to have a deprecated link-local address? If so, this > configuration is valid, and the result is non-intuitive. Yes, it is legal to have a deprecated link-local address. Although the situation will never arise as a result of address autoconfiguration, it can happen with manual configuration. I assume in your scenario, you mean that fe80::1 is assigned to eg an ethernet interface and ::1 is assigned to the loopback interface. And fe80::2 is a neighbor on the ethernet interface. In this case, the candidate set will include fe80::1 but not ::1, because the candidate set can only include link-local addresses assigned to interfaces on the same link as the originating interface. So ::1 will be excluded from the candidate set. So the result is fe80::1, which I think is the answer you want. Actually, the ethernet interface would usually have a non-deprecated link-local address which would get chosen instead. > become redundant. Alternatively, perhaps the cleanest > solution would be to > add something like this to sec 3: > > For non-loopback destination addresses, the set of > candidate source addresses MUST NOT include any > loopback addresses. I think the above analysis shows that additional text is not needed. > > It is RECOMMENDED that the candidate source addresses be the set of > > unicast addresses assigned to the interface that will be used to > > send to the destination. (The "outgoing" interface.) > > Whoa! That's pretty restrictive. Keep this in mind, as many > of my other > concerns stem from the possibility that some implementors may > follow this > RECOMMENDATION. It might be helpful to review the RFC 2119 definition: 3. SHOULD This word, or the adjective "RECOMMENDED", mean that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course. In discussions last year, it seemed the WG consensus was to prefer the strong host model but allow use of the weak host model - I'm trying to reflect that consensus with this wording. > > On routers, the > > candidate set MAY include unicast addresses assigned to any > > interface that could forward the destination address to > the outgoing > > interface. > > This wording presumes a lot about the implementation, and > seems to imply > that only routers MAY deviate from your RECOMMENDATION. It does not imply that only routers may deviate from the recommendation. It does outline one specific deviation that routers may want to implement. (This stems from the discussions last year about the strong vs weak question - some of the examples from weak proponents involved routers.) > > For multicast ... destination addresses, the set of > > candidate source addresses MUST only include addresses assigned to > > interfaces belonging to the same link as the outgoing interface. > > Hmm. What if I'm a multicast router? I'm specifically > concerned about the > case of a node which is sending a multicast stream, where the > node's owners > have gone to great lengths to achieve reliability. They may have some > application-specific reason why all the packets in this > multicast stream > need to have the same source address (to be granted preferred routing > treatment, perhaps, or to traverse firewalls). That means > the application > will bind to a particular global address -- say, one associated with > interface A. If the ISP for interface A fails, we now need to send > multicast packets with A's source address out interface B, > switching to our > backup ISP, with whom we have presumably made advance > arrangements to carry > the traffic. Steve Deering (I think it was) said that some multicast routing protocols break if packets are sent with a source address that is assigned to a different interface. (I don't know enough about multicast routing to vouch for this myself.) Hence this requirement for multicast destinations. > router. Here again, > we need the packets to go out with a consistent global source address, > regardless of the routing decisions. Implementations that want to use a weak host model can do so, if the consequences have been understood and weighed. One of the consequences is that Redirects will not work properly if a host uses the weak model. > > If an application or upper-layer specifies a source address that is > > not in the candidate set for the destination, then the > network layer > > MUST treat this is an error. > > Again, this is what gives me heartburn, particularly in light of that > earlier RECOMMENDATION that the candidate set include only > those source > addresses associated with the outgoing interface. If the > application has > gone to the trouble of binding to a particular local address, > then I think > the network layer should go ahead and use that source > address, even if the > routing table happens to dictate that the packet gets > transmitted out a > different interface. This is particularly true if the > routing table changes > during a particular information flow (UDP application dialog or TCP > connection). At that point, we can't change the source > address, even though > we are suddenly sending the packets out a different interface > which may well > have available addresses of its own. Again, this is the same strong vs weak argument. > In general, perhaps the set of source addresses which can be specified > explicitly by an application should be larger than the set of > addresses > which might be automatically selected by the network layer. > Don't try so > hard to protect the network from misbehaving applications. I disagree with this. An application must not send a packet with an anycast or multicast or unspecified source address. An application must not send a packet out one interface with a link-local source address that is assigned to an interface on another link. And if my network layer implements the strong model, then an application must not send a packet out one interface with a global source address that is assigned to a different interface. But if your implementation uses the weak model, then you will allow this. The draft allows it. > > Rule 2: Prefer appropriate scope. > > If Scope(SA) < Scope(SB). If Scope(SA) < Scope(D), then choose SB > > and otherwise choose SA. > > > I found this rule quite hard to understand. Would it help if I added some explanation, say Rule 2: Prefer appropriate scope. This rule selects the source address that is closest in scope to the destination. ??? > > Rule 5: Prefer outgoing interface. > > If SA is assigned to the interface that will be used to send to D > > and SB is assigned to a different interface, then prefer SA. > > Yes! I agree with this rule. This is a good way to prefer addresses > associated with the outgoing interface. Of course, it only > comes into play > when an implementation deviates from your RECOMMENDATION that > only addresses > assigned to the outgoing interface be considered. It's > rather telling that > when you had to rank this rule, you put it down at number 5, while the > RECOMMENDATION would effectively make it number 0. Actually I'm not sure where to rank rule 5. Since my implementation follows the recommendation, rule 5 doesn't get used. I put it after the mobility rule because some implementations might assign home addresses to a pseudo interface or something. Since you've thought a lot about weak host model implementations, I'd appreciate your feedback on the ranking of rule 5 in a weak host model implementation. > > ...no more than one second out > > of date. For example, an implementation might make a system call to > > check if any routing table entries or source address assignments > > that might affect these algorithms have changed. > > Well, that would probably take several system calls, so doing > it every 1 > second sounds too frequent, to me. I'd think 5 or 10 seconds would be > appropriate. Several system calls once a second is negligible. Especially for a process that is doing network IO. In practice, I expect most implementations will just have getaddrinfo() call down to the network layer to do the address sorting. But the draft allows for other designs. > Bearing in mind that the output from this selection process > should be a list > of address pairs to try, I can't help observing that the results are > sometimes suboptimal. As written, this design will lead well-behaved > applications to try a list of *destination* addresses, in > some reasonable > order. However, for each destination address, we'll try only a single > source address. First, the connect() API might try multiple source addresses before failing, or try multiple source addresses in parallel. (If the application has not bound a specific source address.) I don't know if anyone does this. As you noted, a connect-to-name API (or giving connect a list of addresses) would get the best results. The idea has certainly been discussed often enough. I believe MacOS in fact has such an API. The draft could be extended to give more guidance to such implementations, but at this point it hasn't seemed to be an important goal. Rich -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Dec 19 20:44:26 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta2+Sun/8.11.2.Beta2) id eBK4heE21331 for ipng-dist; Tue, 19 Dec 2000 20:43:40 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.2.Beta2+Sun/8.11.2.Beta2) with ESMTP id eBK4hVH21324 for ; Tue, 19 Dec 2000 20:43:31 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id UAA24726 for ; Tue, 19 Dec 2000 20:43:30 -0800 (PST) Received: from munnari.OZ.AU (munnari.OZ.AU [128.250.1.21]) by patan.sun.com (8.9.3+Sun/8.9.3) with SMTP id UAA20632 for ; Tue, 19 Dec 2000 20:43:25 -0800 (PST) Received: from mundamutti.cs.mu.OZ.AU ([128.250.1.5]) by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.59) id EA16335; Wed, 20 Dec 2000 15:42:53 +1100 (from kre@munnari.OZ.AU) From: Robert Elz To: Francis Dupont Cc: Erik Nordmark , ipng@sunroof.eng.sun.com Subject: Re: destination option update In-Reply-To: Your message of "Mon, 18 Dec 2000 19:01:05 BST." <200012181801.TAA11535@givry.rennes.enst-bretagne.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 20 Dec 2000 15:42:50 +1100 Message-Id: <4496.977287370@mundamutti.cs.mu.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Mon, 18 Dec 2000 19:01:05 +0100 From: Francis Dupont Message-ID: <200012181801.TAA11535@givry.rennes.enst-bretagne.fr> | when there are multiple destination options headers in each of these two | logical locations. | | => merge them??? Ugh! | => this is the solution I use in my current code: a big buffer with the | whole option array but: Good. | - this is less flexible than individual header management (for instance | the good way to insert a header is to pickup the current array before). It is more flexible, but perhaps more complex to handle. | - this doesn't work well with "transparent" headers like fragmentation | or IPsecs. | | This would still have some problems since certain extension headers | (fragmentation, AH, ESP) aren't passed up to the application. | | => exactly my second concern. Why? I don't mean why is it a problem, but why are those headers not passed up to the application? Or perhaps more directly, why should they not be passed up to the application? Sure, in general they (the frag header in particular) doesn't supply much in the way of information, and because the different frag headers on the different frags all contain different data there's no way or reason to send all of that - but the fact that a frag header was present, and where it occurred in the chain of headers seems like useful information to me (to those comparatively few processes that actually care about any of this and aren't just doing read/write down a TCP stream anyway). I would think that much the same would be true of AH & ESP (though those headers are beyond where I usually venture into the dark side...) - at the very least knowing that onet was present, and where it occurred, ought be useful. Similarly for sending - the kernel interface might well ignore whatever the application stuck in one of these headers (frag, AH, ESP - perhaps others) but it could use the presence of such a header to indicate where it should place a header of equivalent type, constructed however it would have been constructed without this method of determining its location. The "I might be able to use this for DOS attacks" is nonsense - there are plenty of easier ways to generate arbitrary packets on a wire than worrying about how to make some arbitrary IPv6 stack do what you want via its API. kre -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Dec 19 21:17:32 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta2+Sun/8.11.2.Beta2) id eBK5GEn21406 for ipng-dist; Tue, 19 Dec 2000 21:16:14 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.2.Beta2+Sun/8.11.2.Beta2) with ESMTP id eBK5G5H21399 for ; Tue, 19 Dec 2000 21:16:05 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id VAA27250 for ; Tue, 19 Dec 2000 21:16:04 -0800 (PST) Received: from munnari.OZ.AU (munnari.OZ.AU [128.250.1.21]) by saturn.sun.com (8.9.3+Sun/8.9.3) with SMTP id VAA07813 for ; Tue, 19 Dec 2000 21:15:57 -0800 (PST) Received: from mundamutti.cs.mu.OZ.AU ([128.250.1.5]) by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.59) id FA15933; Wed, 20 Dec 2000 16:15:38 +1100 (from kre@munnari.OZ.AU) From: Robert Elz To: Richard Draves Cc: "'M. T. Hollinger'" , ipng@sunroof.eng.sun.com Subject: Re: Remaining MUSTs in default-addr-select-02 In-Reply-To: Your message of "Tue, 19 Dec 2000 20:37:10 -0800." <7695E2F6903F7A41961F8CF888D87EA81C9C03@red-msg-06.redmond.corp.microsoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 20 Dec 2000 16:15:37 +1100 Message-Id: <4678.977289337@mundamutti.cs.mu.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Tue, 19 Dec 2000 20:37:10 -0800 From: Richard Draves Message-ID: <7695E2F6903F7A41961F8CF888D87EA81C9C03@red-msg-06.redmond.corp.microsoft.com> | You get into these issues in more detail below, but the quick summary is | that applications can select their own addresses (by binding to a specific | source address) and the draft recommends but does not require the strong | host model, per WG consensus. Would it not be nicer for an application that wants the strong model to bind to an interface, rather than (or in addition do) binding to an address? All kinds of strong model problems (like handling separate transmit/receive interfaces - the application would bind to the receive interface, and dealing with multiple interfaces with the same local address) get sorted out comparatively easily that way. All it leaves open is the method by which an application binds to an interface. Note, this question is directed more to the WG in general than to the draft authors. Also note that perhaps this reflects my general preference against using the strong host model for much at all. | When routers are forwarding packets, the draft doesn't apply since they are | not performing source or destination address selection. But when routers do | perform source or destination address selection, then I believe the draft | should apply. So I think it is appropriate for the scope of the draft to be | all IPv6 nodes. yes, though when operating in that mode it is also possible to consider that the "router" is really a "host". | Steve Deering (I think it was) said that some multicast routing protocols | break if packets are sent with a source address that is assigned to a | different interface. (I don't know enough about multicast routing to vouch | for this myself.) Hence this requirement for multicast destinations. Yes, multicast reverse path routing has some strange effects in the unusual cases - strong model sending is almost certainly a requirement there (unless a different modem of multicast routing is invented sometime). | One of the consequences is that Redirects will not work properly if a host | uses the weak model. If it uses the weak model, and the address chosen doesn't match what would have been used for the strong model. Sometime or other someone probably needs to do some more work on redirect - the redirect mechanisms, and rules, basically haven't changed for 20 years now. There ought be a reasonable way that we can have redirect and have the weak model (and perhaps even have redirect to another interface). But all that is for sometime far far away. | > the network layer should go ahead and use that source | > address, even if the | > routing table happens to dictate that the packet gets | > transmitted out a | > different interface. | Again, this is the same strong vs weak argument. Yes, though in this case (with the strong model) the address selection should win, rather than the routing selection, and the packet should continue to get sent via the "wrong" interface. That might mean it can no longer be delivered of course. But a host "routing" system is rarely going to be complete enough to know this for sure without actually trying it. kre -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Dec 19 21:27:59 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta2+Sun/8.11.2.Beta2) id eBK5Qgl21437 for ipng-dist; Tue, 19 Dec 2000 21:26:42 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.2.Beta2+Sun/8.11.2.Beta2) with ESMTP id eBK5QXH21430 for ; Tue, 19 Dec 2000 21:26:33 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id VAA22541 for ; Tue, 19 Dec 2000 21:26:32 -0800 (PST) Received: from mail3.microsoft.com (mail3.microsoft.com [131.107.3.123]) by patan.sun.com (8.9.3+Sun/8.9.3) with SMTP id VAA04429 for ; Tue, 19 Dec 2000 21:26:32 -0800 (PST) Received: from 157.54.9.100 by mail3.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 19 Dec 2000 21:25:28 -0800 (Pacific Standard Time) Received: by inet-imc-03.redmond.corp.microsoft.com with Internet Mail Service (5.5.2651.58) id ; Tue, 19 Dec 2000 21:26:06 -0800 Message-ID: <7695E2F6903F7A41961F8CF888D87EA80130CA9B@red-msg-06.redmond.corp.microsoft.com> From: Richard Draves To: "'Robert Elz'" Cc: "'M. T. Hollinger'" , ipng@sunroof.eng.sun.com Subject: RE: Remaining MUSTs in default-addr-select-02 Date: Tue, 19 Dec 2000 21:26:22 -0800 X-Mailer: Internet Mail Service (5.5.2651.58) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > | When routers are forwarding packets, the draft doesn't > apply since they are > | not performing source or destination address selection. > But when routers do > | perform source or destination address selection, then I > believe the draft > | should apply. So I think it is appropriate for the scope > of the draft to be > | all IPv6 nodes. > > yes, though when operating in that mode it is also possible > to consider that > the "router" is really a "host". The requirement is the same either way, and I think it's clearer to just say that the draft applies to both hosts & routers. > | > the network layer should go ahead and use that source > | > address, even if the > | > routing table happens to dictate that the packet gets > | > transmitted out a > | > different interface. > | Again, this is the same strong vs weak argument. > > Yes, though in this case (with the strong model) the address selection > should win, rather than the routing selection, and the packet should > continue to get sent via the "wrong" interface. That might mean > it can no longer be delivered of course. But a host "routing" system > is rarely going to be complete enough to know this for sure without > actually trying it. Yes, thanks for the clarification. Rich -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Dec 20 01:57:20 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta2+Sun/8.11.2.Beta2) id eBK9tqV21593 for ipng-dist; Wed, 20 Dec 2000 01:55:52 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.2.Beta2+Sun/8.11.2.Beta2) with ESMTP id eBK9thH21586 for ; Wed, 20 Dec 2000 01:55:43 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id BAA18035; Wed, 20 Dec 2000 01:55:41 -0800 (PST) Received: from melimelo.enst-bretagne.fr (melimelo.enst-bretagne.fr [192.108.115.36]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id CAA16666; Wed, 20 Dec 2000 02:55:40 -0700 (MST) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by melimelo.enst-bretagne.fr (8.10.1/8.10.1) with ESMTP id eBK9qd430634; Wed, 20 Dec 2000 10:52:39 +0100 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id KAA03372; Wed, 20 Dec 2000 10:52:38 +0100 (MET) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.9.3/8.9.3) with ESMTP id KAA22857; Wed, 20 Dec 2000 10:54:33 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200012200954.KAA22857@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Robert Elz cc: Erik Nordmark , ipng@sunroof.eng.sun.com Subject: Re: destination option update In-reply-to: Your message of Wed, 20 Dec 2000 15:42:50 +1100. <4496.977287370@mundamutti.cs.mu.OZ.AU> Date: Wed, 20 Dec 2000 10:54:33 +0100 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: | - this doesn't work well with "transparent" headers like fragmentation | or IPsecs. | | This would still have some problems since certain extension headers | (fragmentation, AH, ESP) aren't passed up to the application. | | => exactly my second concern. Why? => mostly because an application cannot do something useful with them... But the positions of these "transparent" headers are important then I believe a stack is the best data structure. I don't mean why is it a problem, but why are those headers not passed up to the application? => because they have a functional meaning, they doesn't carry information by themselves. Or perhaps more directly, why should they not be passed up to the application? => it is more an usage than other (ie. no deep reason for a "should not") but the fact that a frag header was present, and where it occurred in the chain of headers seems like useful information to me. => we agree about what the API should provide. We have just to find the best (ie. simplest) way to do this. I would think that much the same would be true of AH & ESP (though those headers are beyond where I usually venture into the dark side...) - at the very least knowing that onet was present, and where it occurred, ought be useful. => yes Similarly for sending - the kernel interface might well ignore whatever the application stuck in one of these headers (frag, AH, ESP - perhaps others) but it could use the presence of such a header to indicate where it should place a header of equivalent type, constructed however it would have been constructed without this method of determining its location. => we agree. The "I might be able to use this for DOS attacks" is nonsense - there are plenty of easier ways to generate arbitrary packets on a wire than worrying about how to make some arbitrary IPv6 stack do what you want via its API. => someone (Itojun?) mentioned BPF (:-)... Thanks Francis.Dupont@enst-bretagne.fr PS: we need: - a way to get the header stack as it is received - a way to get the header stack to use for replies (ie. with only bidirectional items, mostly authenticated routing header). Should we do this in the kernel (this function exists for TCP). - pop/push operations - a set/get for the top of the stack (pop/push can do this too?) - the structure describing the header can be the header with its type, its length in the stack (zero for transparent headers). The effective length is a parameter of set/getsockopt() or ancillary data. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Dec 20 04:49:34 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta2+Sun/8.11.2.Beta2) id eBKCmFC21709 for ipng-dist; Wed, 20 Dec 2000 04:48:15 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.2.Beta2+Sun/8.11.2.Beta2) with ESMTP id eBKCm6H21702 for ; Wed, 20 Dec 2000 04:48:06 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id EAA14792 for ; Wed, 20 Dec 2000 04:48:05 -0800 (PST) Received: from theory.cs.uni-bonn.de (theory.cs.uni-bonn.de [131.220.4.211]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA24893 for ; Wed, 20 Dec 2000 04:48:04 -0800 (PST) Received: (from ignatios@localhost) by theory.cs.uni-bonn.de (8.9.1a/8.9.1) id NAA26317; Wed, 20 Dec 2000 13:48:01 +0100 (MET) Date: Wed, 20 Dec 2000 13:48:00 +0100 From: Ignatios Souvatzis To: Radha Gowda Cc: ipng@sunroof.eng.sun.com Subject: Re: Commercial IPv6 implementations Message-ID: <20001220134800.A24572@theory.cs.uni-bonn.de> References: <004d01c06a0e$03899ad0$2956773f@D555F501> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="5vNYLRcllDrimb99" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <004d01c06a0e$03899ad0$2956773f@D555F501>; from Radha@AvianCommunications.com on Tue, Dec 19, 2000 at 05:49:58PM -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk --5vNYLRcllDrimb99 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Tue, Dec 19, 2000 at 05:49:58PM -0500, Radha Gowda wrote: > Are there any commercially available "IPv6 core and extensions" > implementations in the market? If not, anyone with plans to make them > available sometime next year? Excerpts from the ipv6.org listings: AIX 4.3 ships with an IPv6 implementation built in. BSDI's BSD/OS v4.0 ships with an IPv6 implementation built in. Compaq Tru64 UNIX V5.1 contains Internet Protocol Version 6 Solaris 8 ships with an IPv6 implementation built in. In addition, some commercial OS vendors offer IPv6 add-ons. There are also Router vendors that ship with v6, e.g., Telebit, Hitachi, Nortel. Note that this information is necessarily incomplete. Regards, -is --5vNYLRcllDrimb99 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: 2.6.i iQEVAgUBOkCqejCn4om+4LhpAQESrggAulw2/FZfLYZ43JbZk5p0hPAwogut2jl7 LG7uLtT0p8nUyHHZtxeNP/wjptqcJzuh2LH8HVYgDoJDlGFjwjCPu/98c6fDgFse LFz1l1QJ/2BuueIFmNVysGOsk/1+nk5QcTAUON1ASBogMChckkGO1/B4p6ylCNZs Gr5forcHz7tImYd0b/eTdfRX6iLBTMDzb84+nc3LJz7shbs+eu8QWoq2v89N+dDn dkzb0ljeTvyJZ22LT/SfSiWKT5iQCBJJRZXEcmv0Z2r1rs6JBJNLNf/Zf19KiJwG uB2Ih+E2hEDj0DYesF+6kbI+u8d4CZce+4O0zTHi43yufQs/7eSsPQ== =cNJT -----END PGP SIGNATURE----- --5vNYLRcllDrimb99-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Dec 20 06:43:55 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta2+Sun/8.11.2.Beta2) id eBKEbSL21753 for ipng-dist; Wed, 20 Dec 2000 06:37:28 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.2.Beta2+Sun/8.11.2.Beta2) with ESMTP id eBKEbIH21746 for ; Wed, 20 Dec 2000 06:37:19 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id GAA15793 for ; Wed, 20 Dec 2000 06:37:18 -0800 (PST) Received: from wodc7mr4.ffx.ops.us.uu.net (paleoalterdial.UU.NET [192.48.96.22]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id GAA09950 for ; Wed, 20 Dec 2000 06:37:17 -0800 (PST) Received: from D555F501 by wodc7mr4.ffx.ops.us.uu.net with SMTP (peer crosschecked as: [63.119.86.41]) id QQjujy23729; Wed, 20 Dec 2000 14:37:09 GMT Message-ID: <003f01c06a92$c9b362c0$2956773f@D555F501> From: "Radha Gowda" To: "Jun-ichiro itojun Hagino" Cc: References: <20001219234009.2B6DD7E23@starfruit.itojun.org> Subject: Re: Commercial IPv6 implementations Date: Wed, 20 Dec 2000 09:40:24 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > I'm not sure wht you mean by "commercial", but there are a lot of > them, with official support (you can call up help desk). > to give you an example: Solaris 2.8. > try http://playground.sun.com/ipng/. Thanks for all the responses. I should have been more clear. We are looking to purchase an IPv6 stack along with routing protocol extensions that we can port to our platform. We were looking for a commercial implementation so we can get the technical and maintenace support. I'd looked into IPv6 forum prior to posting on this mailing list. Most of the publicly available ones seemed like host implementations. Perhaps I did not do my homework right! -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Dec 20 06:58:42 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta2+Sun/8.11.2.Beta2) id eBKEu3r21782 for ipng-dist; Wed, 20 Dec 2000 06:56:03 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.2.Beta2+Sun/8.11.2.Beta2) with ESMTP id eBKEtYH21775 for ; Wed, 20 Dec 2000 06:55:38 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id GAA17585 for ; Wed, 20 Dec 2000 06:55:34 -0800 (PST) Received: from mailhub1.almaden.ibm.com (mailhub1.almaden.ibm.com [198.4.83.44]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA22080 for ; Wed, 20 Dec 2000 06:55:29 -0800 (PST) Received: from maui.almaden.ibm.com (maui.almaden.ibm.com [9.1.24.92]) by mailhub1.almaden.ibm.com (8.8.8/8.8.8) with ESMTP id GAA62986; Wed, 20 Dec 2000 06:50:29 -0800 Received: from hursley.ibm.com (gsine04.us.sine.ibm.com [9.14.6.44]) by maui.almaden.ibm.com (AIX4.3/8.9.3/8.7) with ESMTP id GAA20962; Wed, 20 Dec 2000 06:55:28 -0800 Message-ID: <3A40C811.335D7BD@hursley.ibm.com> Date: Wed, 20 Dec 2000 08:54:09 -0600 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en,fr MIME-Version: 1.0 To: Richard Draves CC: "'Robert Elz'" , "'M. T. Hollinger'" , ipng@sunroof.eng.sun.com Subject: Re: Remaining MUSTs in default-addr-select-02 References: <7695E2F6903F7A41961F8CF888D87EA80130CA9B@red-msg-06.redmond.corp.microsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Richard Draves wrote: > > > | When routers are forwarding packets, the draft doesn't > > apply since they are > > | not performing source or destination address selection. > > But when routers do > > | perform source or destination address selection, then I > > believe the draft > > | should apply. So I think it is appropriate for the scope > > of the draft to be > > | all IPv6 nodes. > > > > yes, though when operating in that mode it is also possible > > to consider that > > the "router" is really a "host". > > The requirement is the same either way, and I think it's clearer to just say > that the draft applies to both hosts & routers. I believe this is why "node" is defined the way it is in RFC 2460. It's an inclusive term and all you need to say is that the address selection mechanisms apply to all nodes. Brian -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Dec 20 07:40:36 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta2+Sun/8.11.2.Beta2) id eBKFcTv21865 for ipng-dist; Wed, 20 Dec 2000 07:38:29 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.2.Beta2+Sun/8.11.2.Beta2) with ESMTP id eBKFcKH21858 for ; Wed, 20 Dec 2000 07:38:20 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id HAA11892; Wed, 20 Dec 2000 07:38:20 -0800 (PST) Received: from cisco.com (jindo.cisco.com [171.69.11.73]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA17909; Wed, 20 Dec 2000 08:38:18 -0700 (MST) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by cisco.com (8.8.8/2.5.1/Cisco List Logging/8.8.8) with ESMTP id HAA05470; Wed, 20 Dec 2000 07:31:31 -0800 (PST) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id HAA16921; Wed, 20 Dec 2000 07:31:31 -0800 (PST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14912.53459.526171.317018@thomasm-u1.cisco.com> Date: Wed, 20 Dec 2000 07:31:31 -0800 (PST) To: Francis Dupont Cc: Robert Elz , Erik Nordmark , ipng@sunroof.eng.sun.com Subject: Re: destination option update In-Reply-To: <200012200954.KAA22857@givry.rennes.enst-bretagne.fr> References: <4496.977287370@mundamutti.cs.mu.OZ.AU> <200012200954.KAA22857@givry.rennes.enst-bretagne.fr> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Francis Dupont writes: > Similarly for sending - the kernel interface might well ignore whatever the > application stuck in one of these headers (frag, AH, ESP - perhaps others) > but it could use the presence of such a header to indicate where it should > place a header of equivalent type, constructed however it would have been > constructed without this method of determining its location. > > => we agree. I tend to doubt that sending the AH or ESP headers up the stack is especially useful. What the application needs to know that I can think of is: 1) What security policy was applied in receiving the packet 2) What IPsec credentials were bound to #1 The first one allows an application to know pertinent information like whether or not the packet was encrypted/authenticated so that it could perhaps reject unencrypted packets. More generally, the application may want to place finer grain control based on application layer knowledge than the SDP allows, or can express. The second is to stop a forgery attack; if there is no way for an application to query about an incoming packet/flow as to which credentials were used, a trivial application layer forgery attack could be mounted by just changing an application layer identifier which is not bound to a cryptographic identity (eg, the From: address in SMTP). I'm pretty much at a loss as to what seeing the actual headers would gain for run of the mill (read: non-packet sniffers :-) applications. Mike -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Dec 20 18:13:24 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta2+Sun/8.11.2.Beta2) id eBL2BuF22314 for ipng-dist; Wed, 20 Dec 2000 18:11:56 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.2.Beta2+Sun/8.11.2.Beta2) with ESMTP id eBL2BjH22307 for ; Wed, 20 Dec 2000 18:11:46 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id SAA04575 for ; Wed, 20 Dec 2000 18:11:45 -0800 (PST) Received: from mail4.microsoft.com (mail4.microsoft.com [131.107.3.122]) by patan.sun.com (8.9.3+Sun/8.9.3) with SMTP id SAA05850 for ; Wed, 20 Dec 2000 18:11:44 -0800 (PST) Received: from 157.54.9.103 by mail4.microsoft.com (InterScan E-Mail VirusWall NT); Wed, 20 Dec 2000 18:11:41 -0800 (Pacific Standard Time) Received: by inet-imc-04.redmond.corp.microsoft.com with Internet Mail Service (5.5.2651.58) id ; Wed, 20 Dec 2000 17:22:44 -0800 Message-ID: <7695E2F6903F7A41961F8CF888D87EA80130CAA0@red-msg-06.redmond.corp.microsoft.com> From: Richard Draves To: "'Brian E Carpenter'" Cc: "'Robert Elz'" , "'M. T. Hollinger'" , ipng@sunroof.eng.sun.com Subject: RE: Remaining MUSTs in default-addr-select-02 Date: Wed, 20 Dec 2000 10:12:23 -0800 X-Mailer: Internet Mail Service (5.5.2651.58) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > I believe this is why "node" is defined the way it is in RFC > 2460. It's an > inclusive term and all you need to say is that the address selection > mechanisms apply to all nodes. The current text in the draft is: All IPv6 nodes, including both hosts and routers, must implement default address selection as defined in this specification. Rich -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Dec 20 20:32:12 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta2+Sun/8.11.2.Beta2) id eBL4Ufl22406 for ipng-dist; Wed, 20 Dec 2000 20:30:41 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.2.Beta2+Sun/8.11.2.Beta2) with ESMTP id eBL4UTH22399 for ; Wed, 20 Dec 2000 20:30:30 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id UAA04004 for ; Wed, 20 Dec 2000 20:30:29 -0800 (PST) Received: from starfruit.itojun.org (dhcp231.inetweek2000.nic.ad.jp [61.113.177.231]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA22195 for ; Wed, 20 Dec 2000 20:30:28 -0800 (PST) Received: from itojun.org (localhost [127.0.0.1]) by starfruit.itojun.org (Postfix) with ESMTP id F17757E5C; Thu, 21 Dec 2000 13:26:36 +0900 (JST) To: jarkko@piuha.net Cc: ipng@sunroof.eng.sun.com In-reply-to: jari.arkko's message of Tue, 19 Dec 2000 11:15:28 +0200. <3A3F2730.4875B79@piuha.net> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: Denial of Service attacks and ICMPv6 Packet Too Big From: Jun-ichiro itojun Hagino Date: Thu, 21 Dec 2000 13:26:36 +0900 Message-Id: <20001221042637.F17757E5C@starfruit.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >RFC 2463 section 2.4 (e) specifies that Packet Too Big can be sent as a >reply to a multicast message. Is this a source of a DoS problem? I.e. >send a message with a large MTU to a large multicast group, lie about the source >address, and flood real node with the forged source address with lots of traffic. >All this with the cost of sending a single packet. > >Rate limitations are discussed in part (f) but I don't think that helps >in this situation as each individual recipient would only be sending >one ICMP message. Yes, there is DoS possibility with ICMPv6 too big messages. There are two possible meaning for "DoS using ICMPv6 too big". - victim node cannot use larger MTU size for destinations, because of forged ICMPv6 too big from a bad guy. since IPv6 minimum MTU is 1280, the situation is much better than IPv4 case. - if the victim node is careless, the node will cache path MTU discovery results as many as possible. bad guy can inject lots of forged ICMPv6 too big messages, to chew up memory space on the victim node. the attack is easy and the problem is real. (from here, i'll use UNIX-oriented terms) there are two workarounds possible: - we can verify ICMPv6 too big messages by using information left in pcb (address/port pair), and the original packet presented in ICMPv6 too big message. note that this works for conneted pcb only (tcp socket is okay, udp/raw socket is harder). - to remedy the latter problem, we can set an upper limit to the number of routing entries generated by ICMPv6 too big messages. for netbsd/openbsd and recent KAME code (bsdi/netbsd/openbsd), we do have DoS prevention code. not sure if it is complete - we need some torture-tests. >The same situation exists also for the Parameter Problem ICMP message. ICMPv6 redirect has similar issue as ICMPv6 too big, and we can remedy the problem by using similar "upper limit" technique. could you please give some more detail with parameter problem? itojun -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Dec 21 00:32:29 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta2+Sun/8.11.2.Beta2) id eBL8V0s22506 for ipng-dist; Thu, 21 Dec 2000 00:31:00 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.2.Beta2+Sun/8.11.2.Beta2) with ESMTP id eBL8UpH22499 for ; Thu, 21 Dec 2000 00:30:51 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id AAA06003 for ; Thu, 21 Dec 2000 00:30:52 -0800 (PST) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id AAA10731 for ; Thu, 21 Dec 2000 00:30:51 -0800 (PST) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id AAA11081; Thu, 21 Dec 2000 00:30:51 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id eBL8UoB20739; Thu, 21 Dec 2000 00:30:50 -0800 X-Virus-Scanned: Thu, 21 Dec 2000 00:30:50 -0800 Nokia Silicon Valley Email Exploit Scanner Received: from UNKNOWN (139.92.151.70, claiming to be "spruce.iprg.nokia.com") by darkstar.iprg.nokia.com(WTS.12.69) smtpd05p5N5; Thu, 21 Dec 2000 00:30:45 PST Message-Id: <4.3.2.7.2.20001221002650.0234a8f8@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 21 Dec 2000 00:28:04 -0800 To: ipng@sunroof.eng.sun.com From: Bob Hinden Subject: Minutes for San Diego IPng Meeting Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk The minutes for last weeks IPng meeting can be found at: http://playground.sun.com/pub/ipng/html/minutes/ipng-minutes-dec2000.txt Please send corrections to me. Happy Holidays, Bob -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Dec 21 01:07:25 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta2+Sun/8.11.2.Beta2) id eBL95cq22536 for ipng-dist; Thu, 21 Dec 2000 01:05:38 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.2.Beta2+Sun/8.11.2.Beta2) with ESMTP id eBL95TH22529 for ; Thu, 21 Dec 2000 01:05:30 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id BAA09968 for ; Thu, 21 Dec 2000 01:05:29 -0800 (PST) Received: from munnari.OZ.AU (munnari.OZ.AU [128.250.1.21]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id CAA12557 for ; Thu, 21 Dec 2000 02:05:24 -0700 (MST) Received: from mundamutti.cs.mu.OZ.AU ([128.250.1.5]) by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.59) id JA02579; Thu, 21 Dec 2000 20:04:43 +1100 (from kre@munnari.OZ.AU) From: Robert Elz To: Michael Thomas Cc: Francis Dupont , Erik Nordmark , ipng@sunroof.eng.sun.com Subject: Re: destination option update In-Reply-To: Your message of "Wed, 20 Dec 2000 07:31:31 -0800." <14912.53459.526171.317018@thomasm-u1.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 21 Dec 2000 20:04:42 +1100 Message-Id: <17015.977389482@mundamutti.cs.mu.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Wed, 20 Dec 2000 07:31:31 -0800 (PST) From: Michael Thomas Message-ID: <14912.53459.526171.317018@thomasm-u1.cisco.com> | I tend to doubt that sending the AH or ESP headers up the | stack is especially useful. I think what you mean is that applications are unlikely to find the contents of those options (as they would be sent on the wire) useful - and I'm not going to argue about that, I don't know nearly enough about them. However, something needs to inform the application that the header was present - for applications that actually need to know, as distinct from a "dumb" TCP application that just wants non authenticated packets, or packets not correctly encrypted, dropped, and after that simply assumes that the relevant option(s) appear correctly in all packets. On easy way to do that is to leave the header in the (ancillary) data passed up to the application - then it is obvious to the application that the header was there - further, it is also obvious what other headers were encrypted in the case of ESP (the ones that follow the ESP header, and not the ones that precede it). What is in the data part of those headers may well be totally irrelevant to the application (I don't know) - if that is the case, then in the header passed back to the application could be the information that the application does want to know (or at least, that is one possible API). That is ... | 1) What security policy was applied in receiving the packet | 2) What IPsec credentials were bound to #1 The stack could delete the original contents of the header, and instead place that (kind of) information there. Similarly, when sending, the application could pass its requirements in the data segment of those headers, which the stack would use to know where in the header sequence the header should be inserted, and what security policies to apply to the packet - then it would replace the application's supplied headers with ones formatted as they're supposed to be transmitted over the wire. Now I'm certainly not saying that that's the only reasonable API, not even that it would be a good choice for the API - but it is one possibility (on the assumption that the wire format content of the headers isn't useful to the vast majority of those applications which would be using this API at all). Please, don't get stuck with the assumption that the interface between the application and the stack needs to be an almost bit for bit analog of the wire interface - the two of them are achieving quite different objectives. The point of the API is to pass information to the stack (and retrieve it from incoming packets) so that the stack can then generate the packets that cause the protocol to effect the intent of the application. kre -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Dec 21 07:21:58 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta2+Sun/8.11.2.Beta2) id eBLFKKH22735 for ipng-dist; Thu, 21 Dec 2000 07:20:20 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.2.Beta2+Sun/8.11.2.Beta2) with ESMTP id eBLFKBH22728 for ; Thu, 21 Dec 2000 07:20:11 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id HAA05258 for ; Thu, 21 Dec 2000 07:20:10 -0800 (PST) Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA11892 for ; Thu, 21 Dec 2000 07:20:09 -0800 (PST) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with ESMTP id eBLFK7G19776; Thu, 21 Dec 2000 16:20:07 +0100 (MET) Received: from lmf.ericsson.se (lmf4ws450.lmf.ericsson.se [131.160.27.159]) by fogerty.lmf.ericsson.se (8.9.3+Sun/8.9.3) with ESMTP id RAA24862; Thu, 21 Dec 2000 17:20:05 +0200 (EET) Message-ID: <3A421FA5.6701A92D@lmf.ericsson.se> Date: Thu, 21 Dec 2000 17:20:05 +0200 From: Jari Arkko Organization: Oy L M Ericsson Ab X-Mailer: Mozilla 4.76 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: itojun@iijlab.net CC: jarkko@piuha.net, ipng@sunroof.eng.sun.com Subject: Re: Denial of Service attacks and ICMPv6 Packet Too Big Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >There are two possible meaning for "DoS using ICMPv6 too big". > - victim node cannot use larger MTU size for destinations, because of > forged ICMPv6 too big from a bad guy. > since IPv6 minimum MTU is 1280, the situation is much better > than IPv4 case. > - if the victim node is careless, the node will cache path MTU > discovery results as many as possible. bad guy can inject lots of > forged ICMPv6 too big messages, to chew up memory space on the victim > node. >the attack is easy and the problem is real. Aah, I see... but I didn't actually even think yet of the problems you mention. Those seem bad as well, but here's what I was thinking: A multicast group X contains the receivers R1, R2, ... RN. The victim node is V - not necessarily anything to do with X. The attacker is A. All nodes are different. Now, attacker A sends a multicast packet with source = V and destination = X. As the receivers R1 to RN or routers close to them receive the messages, they complain about the message and ALL respond using ICMPv6 Packet Too Big or Parameter Problem, causing V to be flooded with messages. In the above, the "complaining" has to do with either MTU size or with a parameter problem as outlined in the exception to rule e.2 in section 2.4 of RFC 2463. The MTU size then has to be really too large, meaning that the attack can be launched only if the receivers have smaller MTUs than what the networks from A can carry. The parameter problem can be caused simply by adding Destination Option header with an option 10xxxxxx where xxxxxx is an unknown option number. I'm not sure if I've missed something that prevents an attacker from doing this. But if they can do this, it is very hard to prevent the consequences since (a) there is amplification involved, (b) each ICMPv6 sender sends just one packet so rate limitation won't help, and (c) the victim's pipe may be full because of the messages and therefore any policies the victim may have on throwing out them won't help. What isn't clear to me though is for instance, which nodes can send such multicast traffic like this. I would assume at least those who are on the same network with the real sender of the group, and at least when the V is the same as the real sender. But how far beyond this you can take the attack? Jari ---- Jari Arkko, Oy L M Ericsson Ab, 02420 Jorvas, Finland. Tel +358 9 2992480 Fax +358 9 2993052. GSM +358 40 5079256. E-Mail: Jari.Arkko@ericsson.com Private WWW: http://www.iki.fi/jar. Standard disclaimers apply. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Dec 21 07:44:18 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta2+Sun/8.11.2.Beta2) id eBLFgwU22755 for ipng-dist; Thu, 21 Dec 2000 07:42:58 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.2.Beta2+Sun/8.11.2.Beta2) with ESMTP id eBLFgnH22748 for ; Thu, 21 Dec 2000 07:42:49 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id HAA09862 for ; Thu, 21 Dec 2000 07:42:49 -0800 (PST) Received: from multicasttech.com (ns2.multicasttech.com [63.105.122.8]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA10762 for ; Thu, 21 Dec 2000 07:42:48 -0800 (PST) Received: from [63.105.122.193] (HELO 21rst-century.com) by multicasttech.com (CommuniGate Pro SMTP 3.3) with ESMTP id 635328; Thu, 21 Dec 2000 10:44:03 -0500 Message-ID: <3A422443.D9BD1BC1@21rst-century.com> Date: Thu, 21 Dec 2000 10:39:46 -0500 From: Marshall Eubanks Reply-To: tme@21rst-century.com X-Mailer: Mozilla 4.7C-CCK-MCD {C-UDP; EBM-APPLE} (Macintosh; I; PPC) X-Accept-Language: en,pdf MIME-Version: 1.0 To: Jari Arkko CC: itojun@iijlab.net, jarkko@piuha.net, ipng@sunroof.eng.sun.com Subject: Re: Denial of Service attacks and ICMPv6 Packet Too Big References: <3A421FA5.6701A92D@lmf.ericsson.se> Content-Type: text/plain; charset=us-ascii; x-mac-type="54455854"; x-mac-creator="4D4F5353" Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Jari Arkko wrote: > >There are two possible meaning for "DoS using ICMPv6 too big". > > - victim node cannot use larger MTU size for destinations, because of > > forged ICMPv6 too big from a bad guy. > > since IPv6 minimum MTU is 1280, the situation is much better > > than IPv4 case. > > - if the victim node is careless, the node will cache path MTU > > discovery results as many as possible. bad guy can inject lots of > > forged ICMPv6 too big messages, to chew up memory space on the victim > > node. > >the attack is easy and the problem is real. > > Aah, I see... but I didn't actually even think yet of > the problems you mention. Those seem bad as well, but > here's what I was thinking: > > A multicast group X contains the receivers R1, R2, ... RN. > The victim node is V - not necessarily anything to do with > X. The attacker is A. All nodes are different. Now, attacker A > sends a multicast packet with source = V and destination = X. > As the receivers R1 to RN or routers close to them receive the > messages, they complain about the message and ALL respond using > ICMPv6 Packet Too Big or Parameter Problem, causing V to be > flooded with messages. > Hello; Why SHOULD they respond ? Having all recipient of a multicast stream respond to something is not a good idea - you don't need an attack, as you would be always only one bad packet away from disaster. In IPv4, multicast packet errors generally are not responded to, and I do not see why things should be different here. Regards Marshall Eubanks > > In the above, the "complaining" has to do with either MTU > size or with a parameter problem as outlined in the exception > to rule e.2 in section 2.4 of RFC 2463. The MTU size then > has to be really too large, meaning that the attack can be > launched only if the receivers have smaller MTUs than what > the networks from A can carry. The parameter problem can > be caused simply by adding Destination Option header with an > option 10xxxxxx where xxxxxx is an unknown option number. > > I'm not sure if I've missed something that prevents an > attacker from doing this. But if they can do this, > it is very hard to prevent the consequences since (a) > there is amplification involved, (b) each ICMPv6 sender > sends just one packet so rate limitation won't help, and > (c) the victim's pipe may be full because of the messages > and therefore any policies the victim may have on throwing > out them won't help. > > What isn't clear to me though is for instance, which > nodes can send such multicast traffic like this. I > would assume at least those who are on the same network > with the real sender of the group, and at least when > the V is the same as the real sender. But how far beyond > this you can take the attack? > > Jari > ---- > Jari Arkko, Oy L M Ericsson Ab, 02420 Jorvas, Finland. Tel +358 9 2992480 > Fax +358 9 2993052. GSM +358 40 5079256. E-Mail: Jari.Arkko@ericsson.com > Private WWW: http://www.iki.fi/jar. Standard disclaimers apply. > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- T.M. Eubanks Multicast Technologies, Inc 10301 Democracy Lane, Suite 410 Fairfax, Virginia 22030 Phone : 703-293-9624 Fax : 703-293-9609 e-mail : tme@on-the-i.com tme@multicasttech.com http://www.on-the-i.com http://www.buzzwaves.com -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Dec 21 09:58:25 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta2+Sun/8.11.2.Beta2) id eBLHude22826 for ipng-dist; Thu, 21 Dec 2000 09:56:39 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.2.Beta2+Sun/8.11.2.Beta2) with ESMTP id eBLHuTH22819 for ; Thu, 21 Dec 2000 09:56:29 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id JAA09905 for ; Thu, 21 Dec 2000 09:56:29 -0800 (PST) Received: from smtp1.kolumbus.fi (smtp1.kolumbus.fi [193.229.0.36]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA10389 for ; Thu, 21 Dec 2000 09:56:28 -0800 (PST) Received: from jariws1 (aa103d3hel.dial.kolumbus.fi [212.54.17.103]) by smtp1.kolumbus.fi (8.9.0/8.9.0) with SMTP id TAA06127; Thu, 21 Dec 2000 19:56:02 +0200 (EET) Message-ID: <004001c06b77$4ef170a0$8a1b6e0a@arenanet.fi> From: "Jari Arkko" To: Cc: , , "Jari Arkko" References: <3A421FA5.6701A92D@lmf.ericsson.se> <3A422443.D9BD1BC1@21rst-century.com> Subject: Re: Denial of Service attacks and ICMPv6 Packet Too Big Date: Thu, 21 Dec 2000 19:56:08 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Why SHOULD they respond ? Having all recipient of a multicast stream respond > to something is not a good idea - you don't need an attack, as you would be always only Well... because RFC 2463 section 2.4 point (e.2) wants you to? The RFC names two exceptions to the never-respond-to-multicast rule: Packet Too Big and Parameter Problem code 2. For the former there is a justification that in this manner Path MTU selection may work for multicast as well. Note the difference to v4, where longer packets would just have been fragmented For Parameter Problem, no justification is given. But I agree, it is a dangerous business... Interestingly enough, for anycast the system can't support Path MTU selection since point e.5 in the same RFC prohibits it. Jari -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Dec 21 10:18:33 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta2+Sun/8.11.2.Beta2) id eBLIGvf22923 for ipng-dist; Thu, 21 Dec 2000 10:16:57 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.2.Beta2+Sun/8.11.2.Beta2) with ESMTP id eBLIGkH22916 for ; Thu, 21 Dec 2000 10:16:46 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id KAA14665 for ; Thu, 21 Dec 2000 10:16:46 -0800 (PST) Received: from roll.mentat.com ([192.88.122.129]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA28891 for ; Thu, 21 Dec 2000 10:16:46 -0800 (PST) Received: from leo.mentat.com (leo [192.88.122.132]) by roll.mentat.com (8.9.1b+Sun/8.9.1) with ESMTP id KAA19637; Thu, 21 Dec 2000 10:16:21 -0800 (PST) Received: from feller.mentat.com (feller [192.88.122.144]) by leo.mentat.com (8.9.1b+Sun/8.9.1) with ESMTP id KAA20543; Thu, 21 Dec 2000 10:16:21 -0800 (PST) Received: (from tim@localhost) by feller.mentat.com (8.9.3+Sun/8.9.3) id KAA02454; Thu, 21 Dec 2000 10:19:30 -0800 (PST) Date: Thu, 21 Dec 2000 10:19:30 -0800 (PST) From: Tim Hartrick Message-Id: <200012211819.KAA02454@feller.mentat.com> To: jarkko@piuha.net, itojun@iijlab.net Subject: Re: Denial of Service attacks and ICMPv6 Packet Too Big Cc: ipng@sunroof.eng.sun.com X-Sun-Charset: US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Itojun, > > ICMPv6 redirect has similar issue as ICMPv6 too big, and we can remedy > the problem by using similar "upper limit" technique. could you please > give some more detail with parameter problem? > I am not sure how ICMPv6 redirects could be used in such a DoS attack unless the attacker was willing to be caught. Because redirects can't be forwarded from off-link (the hop limit must be 255 when received) there is no way for an attacker to mount a redirect based attack unless the attacking system is on the same link as the target. The requirement that all ND/RD messages be received with a hop limit of 255 is the only thing that makes it possible for ND to be minimally safe from DoS attacks in the absence of real AH based authentication. Absent that requirement there are many DoS attacks that can be mounted using any of the ND/RD messages. tim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Dec 21 12:43:56 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta2+Sun/8.11.2.Beta2) id eBLKfis23058 for ipng-dist; Thu, 21 Dec 2000 12:41:44 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.2.Beta2+Sun/8.11.2.Beta2) with ESMTP id eBLKfYH23051 for ; Thu, 21 Dec 2000 12:41:34 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id MAA23546 for ; Thu, 21 Dec 2000 12:41:33 -0800 (PST) Received: from smtp2.kolumbus.fi (smtp2.kolumbus.fi [193.229.0.37]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA16079 for ; Thu, 21 Dec 2000 13:41:31 -0700 (MST) Received: from jariws1 (aa103d3hel.dial.kolumbus.fi [212.54.17.103]) by smtp2.kolumbus.fi (8.9.0/8.9.0) with SMTP id WAA00837; Thu, 21 Dec 2000 22:41:20 +0200 (EET) Message-ID: <00ce01c06b8e$6573f480$8a1b6e0a@arenanet.fi> From: "Jari Arkko" To: "Tim Hartrick" , Cc: References: <200012211819.KAA02454@feller.mentat.com> Subject: Re: Denial of Service attacks and ICMPv6 Packet Too Big Date: Thu, 21 Dec 2000 22:41:28 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > the attacker was willing to be caught. Because redirects can't be forwarded > from off-link (the hop limit must be 255 when received) there is no way for > an attacker to mount a redirect based attack unless the attacking system > is on the same link as the target. Correct. And like you say, it applies to the ND/RD messages as well. However, Packet Too Big and Parameter Problem are end-to-end messages, not local link messages. Hence, if spoofed multicast messages can be replied with ICMPs, the hop limit check won't help that. Jari -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Dec 21 13:52:14 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta2+Sun/8.11.2.Beta2) id eBLLoZr23159 for ipng-dist; Thu, 21 Dec 2000 13:50:35 -0800 (PST) Received: from eastmail2.East.Sun.COM (eastmail2.East.Sun.COM [129.148.1.241]) by sunroof.eng.sun.com (8.11.2.Beta2+Sun/8.11.2.Beta2) with ESMTP id eBLLoOH23152 for ; Thu, 21 Dec 2000 13:50:25 -0800 (PST) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail2.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id QAA29246; Thu, 21 Dec 2000 16:50:22 -0500 (EST) Received: from thunk (localhost [127.0.0.1]) by thunk.east.sun.com (8.11.1+Sun/8.10.2) with ESMTP id eBLLndX108764; Thu, 21 Dec 2000 16:49:39 -0500 (EST) Message-Id: <200012212149.eBLLndX108764@thunk.east.sun.com> From: Bill Sommerfeld To: Jari Arkko cc: itojun@iijlab.net, jarkko@piuha.net, ipng@sunroof.eng.sun.com Subject: Re: Denial of Service attacks and ICMPv6 Packet Too Big In-reply-to: Your message of "Thu, 21 Dec 2000 17:20:05 +0200." <3A421FA5.6701A92D@lmf.ericsson.se> Reply-to: sommerfeld@east.sun.com Date: Thu, 21 Dec 2000 16:49:39 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk rfc1122 (host requirements) says: An ICMP error message MUST NOT be sent as the result of receiving: ... * a datagram destined to an IP broadcast or IP multicast address, or * a datagram sent as a link-layer broadcast, or ... however, rfc2463 (icmpv6) weakens this: (e) An ICMPv6 error message MUST NOT be sent as a result of receiving: ... (e.2) a packet destined to an IPv6 multicast address (there are two exceptions to this rule: (1) the Packet Too Big Message - Section 3.2 - to allow Path MTU discovery to work for IPv6 multicast, and (2) the Parameter Problem Message, Code 2 - Section 3.4 - reporting an unrecognized IPv6 option that has the Option Type highest-order two bits set to 10), or (e.3) a packet sent as a link-layer multicast, (the exception from e.2 applies to this case too), or (e.4) a packet sent as a link-layer broadcast, (the exception from e.2 applies to this case too), or The path mtu discovery case almost makes sense, and topologies which could be abused into being "smurf" amplifiers may well be very rare in practice. [I do it odd that there's no rationale given for responding with a "parameter problem"..] - Bill -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Dec 27 05:49:36 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta2+Sun/8.11.2.Beta2) id eBRDmDI25640 for ipng-dist; Wed, 27 Dec 2000 05:48:13 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.2.Beta2+Sun/8.11.2.Beta2) with ESMTP id eBRDm4H25633 for ; Wed, 27 Dec 2000 05:48:04 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id FAA16145 for ; Wed, 27 Dec 2000 05:48:05 -0800 (PST) Received: from warp.seabridge.co.il (warp.seabridgenetworks.com [212.25.127.242]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id GAA01137 for ; Wed, 27 Dec 2000 06:48:00 -0700 (MST) Received: from tiger.seabridge.co.il (tiger.seabridge.co.il [172.30.10.101]) by warp.seabridge.co.il (8.9.3/8.9.3) with ESMTP id RAA03701 for ; Wed, 27 Dec 2000 17:08:07 +0200 Received: by tiger.seabridge.co.il with Internet Mail Service (5.5.2650.21) id <45GL3S3W>; Wed, 27 Dec 2000 15:44:51 +0200 Message-ID: From: Doron Hirsch To: "'ipng@sunroof.eng.sun.com'" Subject: IPv6 Routing Date: Wed, 27 Dec 2000 15:44:53 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0700B.2F3EC86E" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C0700B.2F3EC86E Content-Type: text/plain; charset="windows-1255" Greetings, Please excuse my ignorance as I am new to IPv6. I am puzzled about the following two issues and would appreciate your help. 1) Where can I find information regarding IPv6 routing? 2) Where are the Hop-by-Hop & Destination options defined? [I could not find references in 2460] Kind regards, Hirsch Doron. ------_=_NextPart_001_01C0700B.2F3EC86E Content-Type: text/html; charset="windows-1255" IPv6 Routing

Greetings,

Please excuse my ignorance as I am new to IPv6.
I am puzzled about the following two issues and would appreciate your help.

1) Where can I find information regarding IPv6 routing?
2) Where are the Hop-by-Hop & Destination options defined? [I could not find references in 2460]

Kind regards,
Hirsch Doron.

------_=_NextPart_001_01C0700B.2F3EC86E-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Dec 27 06:23:32 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta2+Sun/8.11.2.Beta2) id eBREMA325676 for ipng-dist; Wed, 27 Dec 2000 06:22:10 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.2.Beta2+Sun/8.11.2.Beta2) with ESMTP id eBREM1H25669 for ; Wed, 27 Dec 2000 06:22:01 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id GAA03663 for ; Wed, 27 Dec 2000 06:22:01 -0800 (PST) Received: from mel.alcatel.fr (mel.alcatel.fr [212.208.74.132]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id GAA27003 for ; Wed, 27 Dec 2000 06:22:00 -0800 (PST) Received: from aifhs2.alcatel.fr (mailhub.alcatel.fr [155.132.180.80]) by mel.alcatel.fr (ALCANET/SMTP) with ESMTP id PAA10749; Wed, 27 Dec 2000 15:20:26 +0100 Received: from mail.bsf.alcatel.fr (mail.dit.sxb.bsf.alcatel.fr [155.132.205.115]) by aifhs2.alcatel.fr (ALCANET/SMTP2) with ESMTP id PAA06035; Wed, 27 Dec 2000 15:17:51 +0100 (MET) Received: from mail (mail-bsf-alcatel-fr.dit.sxb.bsf.alcatel.fr [155.132.205.91]) by mail.bsf.alcatel.fr (8.8.8+Sun/8.9.3) with ESMTP id PAA07937; Wed, 27 Dec 2000 15:20:59 +0100 (MET) Received: from cerbere (cerbere [172.25.48.4]) by mail (8.8.8+Sun/) with ESMTP id PAA07933; Wed, 27 Dec 2000 15:20:58 +0100 (MET) Received: from angora by cerbere (8.8.8+Sun/ABS1.5) id PAA00850; Wed, 27 Dec 2000 15:20:56 +0100 (MET) Received: from sxb.bsf.alcatel.fr by angora (8.8.8+Sun/ABS1.5) id PAA10331; Wed, 27 Dec 2000 15:20:55 +0100 (MET) Message-ID: <3A49FAC7.765B833A@sxb.bsf.alcatel.fr> Date: Wed, 27 Dec 2000 15:20:55 +0100 From: Frederic SOULIER X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Doron Hirsch CC: "'ipng@sunroof.eng.sun.com'" Subject: Re: IPv6 Routing References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Dear Doron, > Doron Hirsch wrote: [snip] > 1) Where can I find information regarding IPv6 routing? All the routing processes are explained in RFC-2460. If you are not experienced with IPv4 routing may be you have to begin with related documentations too. > 2) Where are the Hop-by-Hop & Destination options defined? [I could > not find references in 2460] RFC-2460 : Specifications of the hop-by-hop and the destination options header are respectively in 4.3 and 4.6. RFC-2292 may help you too (respectively section 6 and 7). Best wishes, Frederic. -- Frederic SOULIER - OS Engineer - Alcatel Telecom 1, rue du docteur Albert Schweitzer Phone: +33 3 90 67 68 50 - F-67400 Illkirch (FRANCE) -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Dec 27 10:06:40 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta2+Sun/8.11.2.Beta2) id eBRI53A25747 for ipng-dist; Wed, 27 Dec 2000 10:05:03 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.2.Beta2+Sun/8.11.2.Beta2) with ESMTP id eBRI4qH25740 for ; Wed, 27 Dec 2000 10:04:52 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id KAA19526 for ; Wed, 27 Dec 2000 10:04:51 -0800 (PST) Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA28332 for ; Wed, 27 Dec 2000 11:04:50 -0700 (MST) Received: from [171.78.30.107] (comsec.bbn.com [171.78.30.107]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id NAA02586; Wed, 27 Dec 2000 13:04:29 -0500 (EST) Mime-Version: 1.0 X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <3A3F276E.D84D9839@piuha.net> References: <008e01c0610c$16237c20$8a1b6e0a@arenanet.fi> <20001211082557.A2125@orca.informatik.uni-ulm.de> <3A362BA2.D7EF1481@piuha.net> <3A3F276E.D84D9839@piuha.net> Date: Wed, 27 Dec 2000 13:00:49 -0500 To: jarkko@piuha.net From: Stephen Kent Subject: Re: IPv6 Neighbour Solicitation messages and IPsec Cc: ipsec@lists.tislabs.com, aidan.williams@motorola.com, ipng@sunroof.eng.sun.com Content-Type: multipart/alternative; boundary="============_-1234182169==_ma============" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk --============_-1234182169==_ma============ Content-Type: text/plain; charset="us-ascii" ; format="flowed" Jari, >Stephen Kent wrote: > > > > * Path MTU discovery. Consider the following case: > > > > > > (N1)----(VPNGW1)----(R1)----(VPNGW2)-----(R2)----(N2) > > > > > > Assume N1 wants to send traffic to N2, part of the path > > > goes through an insecure network part, secured using > > > VPNGWs 1 and 2. And now Path MTU discovery is in > > > progress between N1 and N2. Assume the smallest MTU > > > is at R2. Then an ICMPv6 Packet Too Big message must be > > > sent back towards the VPNGW2. Should that message > > > go to the tunnel? I think it should. > > > > There is nothing to prohibit transmission of this ICMP message via > > the security gateways, if appropriate SPD entries exist. > >You are right, but the context of the discussion was that a proposal >was made that all ICMPv6 messages should bypass IPsec processing in >order to avoid chicken-and-egg problems with some ICMPv6 messages. I >was trying to make the point that _some_ ICMPv6 messages at least >in _some_ situations have to go through IPsec. Hence, the "ignore >ICMPv6 in IPsec" solution doesn't fly. It was also suggested that >perhaps the difference lies in tunnel mode vs transport mode. However, >that distinction doesn't solve the problems either... two nodes on >the same link could well have tunnel mode policies for all traffic, >which would then prevent e.g. duplicate address detection to work, >which in turn would prevent all communications. Also, as per RFC >2401 we do not in general have the possibility to specify policies >for individual ICMP message types. Finally, one might have expected >multicast / unicast addresses to have a significance such that >we could say only unicast traffic gets IPsec protection, but apparently >this isn't always the case. For instance, when the Neighbour >Advertisement message is used as a reply in an address resolution >situation, it is a unicast message. > >Instead, I think we need something else. What was previously lower >layer thing such as ARP, is now a proper IP packet in v6. In addition, >there is completely new functionality. These must be considered >when thinking about which messages should get IPsec protection, >and how. > >The ICMPv6 messages can be classified as follows: > > No RFC Name End-to-End Required Before UDP works > 1 2463 Dest unreach Yes No > 2 2463 Packet too big Yes No > 3 2463 Time exceeded Yes No > 4 2463 Parameter problem Yes No >128 2463 Echo request Yes No >129 2463 Echo reply Yes No >137 2461 Redirect No Yes >133 2461 Router solicit No Yes >134 2461 Router adv No Yes >135 2461 NeighSol/Resol No Yes >136 2461 NeighAdv/Resol No Yes >135 2461 NeighSol/Unreach No No >136 2461 NeighAdv/Unreach No No >135 2462 NeighSol/Autoconf No Yes >136 2462 NeighAdv/Autoconf No Yes > >Note that Neihbour Solicitation and Advertisement play multiple roles, >address resolution, unreachability detection, and autoconfiguration. >The crucial thing in the above table is to note which messages are >necessary before two IPv6 nodes can exchange packets. For IPsec, the >relevant issue is if SAs can be negotiated using IKE which runs on >top of UDP. If not, such messages simply can not be protected with >dynamic SAs; for instance we can't send UDP messages before address >autoconfiguration has determined the suitable addresses to be used >and ensured that no duplicate addresses exist on the link. > >So, what I would propose is that the ICMPv6 messages Redirect, >Router Solicitation/Advertisement, and Neighbour Solicitation/Advertisement >(except for reachbility detection) are never given normal IPsec >treatment. I.e., if I define my policies as always requiring >IKE & IPsec for all traffic, then these exceptional messages still >go in the clear and without IKE. I'm not an IPv6 expert, but it seems that the issue here is who emits the message, not just what ICMP message is being emitted. An IPsec implementation (gateway or host) has an ability to bypass control traffic that it emits, irrespective of SPD contents. So, I would expect that ICMP messages used for neighbor solicitation, advertisement, and autoconfig, etc. would fall into this category. But, such traffic emitted by a host behind a security gateway ought not be bypass in all cases, since doing so creates significant covert channel opportunities. >Furthermore, I would suggest that if protection is needed for the >exceptional ICMPv6 message set, then manually configured IPsec SAs >be used, enabling also the protection of multicast traffic. However, >in order to do things like this, the SPD must have sufficient expressive >power to distinguish ICMP messages types and roles. Today we provide port-level controls, for UDP and TCP traffic, so adding ICMP-specific controls represents a significant change. We'll have to evaluate the requirement for this sort of change very carefully. > >Finally, I would propose that everywhere in the ICMPv6 specifications >where it says "AH", tunnel mode ESP would suffice as well. This last suggestion is a topic for a different debate, and I would suggest not including it in this discussion. Steve --============_-1234182169==_ma============ Content-Type: text/enriched; charset="us-ascii" Jari, Stephen Kent wrote: > > * Path MTU discovery. Consider the following case: > > > > (N1)----(VPNGW1)----(R1)----(VPNGW2)-----(R2)----(N2) > > > > Assume N1 wants to send traffic to N2, part of the path > > goes through an insecure network part, secured using > > VPNGWs 1 and 2. And now Path MTU discovery is in > > progress between N1 and N2. Assume the smallest MTU > > is at R2. Then an ICMPv6 Packet Too Big message must be > > sent back towards the VPNGW2. Should that message > > go to the tunnel? I think it should. > > There is nothing to prohibit transmission of this ICMP message via > the security gateways, if appropriate SPD entries exist. You are right, but the context of the discussion was that a proposal was made that all ICMPv6 messages should bypass IPsec processing in order to avoid chicken-and-egg problems with some ICMPv6 messages. I was trying to make the point that _some_ ICMPv6 messages at least in _some_ situations have to go through IPsec. Hence, the "ignore ICMPv6 in IPsec" solution doesn't fly. It was also suggested that perhaps the difference lies in tunnel mode vs transport mode. However, that distinction doesn't solve the problems either... two nodes on the same link could well have tunnel mode policies for all traffic, which would then prevent e.g. duplicate address detection to work, which in turn would prevent all communications. Also, as per RFC 2401 we do not in general have the possibility to specify policies for individual ICMP message types. Finally, one might have expected multicast / unicast addresses to have a significance such that we could say only unicast traffic gets IPsec protection, but apparently this isn't always the case. For instance, when the Neighbour Advertisement message is used as a reply in an address resolution situation, it is a unicast message. Instead, I think we need something else. What was previously lower layer thing such as ARP, is now a proper IP packet in v6. In addition, there is completely new functionality. These must be considered when thinking about which messages should get IPsec protection, and how. The ICMPv6 messages can be classified as follows: No RFC Name End-to-End Required Before UDP works 1 2463 Dest unreach Yes No 2 2463 Packet too big Yes No 3 2463 Time exceeded Yes No 4 2463 Parameter problem Yes No 128 2463 Echo request Yes No 129 2463 Echo reply Yes No 137 2461 Redirect No Yes 133 2461 Router solicit No Yes 134 2461 Router adv No Yes 135 2461 NeighSol/Resol No Yes 136 2461 NeighAdv/Resol No Yes 135 2461 NeighSol/Unreach No No 136 2461 NeighAdv/Unreach No No 135 2462 NeighSol/Autoconf No Yes 136 2462 NeighAdv/Autoconf No Yes Note that Neihbour Solicitation and Advertisement play multiple roles, address resolution, unreachability detection, and autoconfiguration. The crucial thing in the above table is to note which messages are necessary before two IPv6 nodes can exchange packets. For IPsec, the relevant issue is if SAs can be negotiated using IKE which runs on top of UDP. If not, such messages simply can not be protected with dynamic SAs; for instance we can't send UDP messages before address autoconfiguration has determined the suitable addresses to be used and ensured that no duplicate addresses exist on the link. So, what I would propose is that the ICMPv6 messages Redirect, Router Solicitation/Advertisement, and Neighbour Solicitation/Advertisement (except for reachbility detection) are never given normal IPsec treatment. I.e., if I define my policies as always requiring IKE & IPsec for all traffic, then these exceptional messages still go in the clear and without IKE. I'm not an IPv6 expert, but it seems that the issue here is who emits the message, not just what ICMP message is being emitted. An IPsec implementation (gateway or host) has an ability to bypass control traffic that it emits, irrespective of SPD contents. So, I would expect that ICMP messages used for neighbor solicitation, advertisement, and autoconfig, etc. would fall into this category. But, such traffic emitted by a host behind a security gateway ought not be bypass in all cases, since doing so creates significant covert channel opportunities. Furthermore, I would suggest that if protection is needed for the exceptional ICMPv6 message set, then manually configured IPsec SAs be used, enabling also the protection of multicast traffic. However, in order to do things like this, the SPD must have sufficient expressive power to distinguish ICMP messages types and roles. Today we provide port-level controls, for UDP and TCP traffic, so adding ICMP-specific controls represents a significant change. We'll have to evaluate the requirement for this sort of change very carefully. Finally, I would propose that everywhere in the ICMPv6 specifications where it says "AH", tunnel mode ESP would suffice as well. This last suggestion is a topic for a different debate, and I would suggest not including it in this discussion. Steve --============_-1234182169==_ma============-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com --------------------------------------------------------------------